和会"反思"的 AI 编程助手相处两个月，我学到了什么

说实话，一开始我只是想试试那些能自我审视和改进的 AI 编程工具，期待的是感受一下技术有多厉害。

结果呢？技术确实厉害，但我收获的远不止于此。

这两个月每天都在用这些工具，看它们怎么复盘自己的推理过程、怎么发现错误规律、怎么一步步优化方法论……我重新理解了很多东西：怎么写提示词、怎么设计开发流程，甚至怎么看待 human 和 AI 的协作关系。

镜子里的自己

最让我意外的一点：

会自我改进的 AI 工具，不只是在提升自己的编程能力。它们更像一面镜子，照出了我们一直没意识到的那些问题。

当一个 AI 工具审视自己最近产出的代码，问"我为什么用这种方式处理"的时候，它经常会挖出一些我们自己都没意识到的假设。

我见过一个例子：AI 发现某个 bug 反反复复出现，追踪下去发现根源是一种微妙的变量命名不一致。然后它指出——其实我自己在整个项目里的命名风格也不一致，这种模式太根深蒂固了，我自己根本没注意到。

这个"镜子效应"在写提示词的时候也适用。那些会反思的 AI 工具经常能揭示：我们的指令里其实藏着隐藏的矛盾或者默认假设。

你看着一个 AI 工具卡在某个任务上，然后分析它为什么会卡——十有八九会发现，困惑的源头其实是你自己以为写清楚了、但实际上表述模糊的指令。

反馈决定成长速度

自我改进的 AI 工具本质上是干什么的？就是回顾自己的历史——成功案例、失败案例——然后用这些分析来指导下一步决策。

这个循环模式里有个很有意思的点：改进的质量很大程度上取决于反馈的质量。

那些收到精准、有上下文反馈的 AI 工具——不只是告诉你"对了"或"错了"，而是解释清楚"为什么对"或"为什么错"——它们的进步速度远超那些只收到成功/失败信号的。

这让我反思自己的团队实践：

好的反馈应该是具体的、有因果关系的。与其说"这样不对"，不如说"这里出问题是因为在 Y 场景下没有考虑到 X 这个边界情况"。

收到这种因果反馈的 AI 工具，对同类问题的直觉会好很多。

这道理其实跟带新人一样。谁都是从"这样看起来不太对"走过来的，但真正让人成长的是把标准背后的原因讲清楚。

抽象这道坎

我观察到的另一个明显规律：AI 工具怎么对付抽象这件事——或者说，在这个方面它们怎么翻车的。

当 AI 处理请求的时候，它们往往是在具体 token 和见过的 pattern 层面操作，而不是真正提炼出底层原理。

一个会自我改进的 AI 工具可能注意到"这类情况我见过 47 次了"，但它没能建立那个概念框架，让它在遇到第 48 次——稍微有点不同的那种——的时候也能搞定。

这跟很多初级开发者的困境一模一样：学了一堆模式，但不理解原理。

这也给所有重度依赖 AI 辅助的开发者提了个醒：pattern 匹配能带你走很远，但真正让你能 handle 没见过的场景的，是抽象能力。

对于开发者来说，这意味着什么？AI 编程助手越强大，人类能发挥的比较优势就越集中在抽象思维上——看到不同具体案例背后的通用原则。

给 AI 留个好项目结构

观察这些会反思的 AI 工具，我学到的最实用的一个教训是关于项目结构的。

有些代码库对人类协作很友好，但换成 AI 协作就不太行，反过来也一样。

AI 工具在这种情况下表现最好：

• 命名规范清晰一致
• 依赖关系有良好文档
• 文件结构可预测
• 错误处理有明确模式

AI 工具在这种情况就容易出问题：高度依赖隐性上下文——理解某段代码为什么这样写，需要知道那些没写在代码里的历史决策。

这说明项目架构需要考虑一个新维度：除了人机界面，还要设计"AI 界面"。

如果你要做一个重度依赖 AI 辅助的项目，有些传统做法可能需要调整了。显式优于隐式。文档不只是给未来的开发人员看的，也是给未来的 AI 看的。

关于 Vibe Coding

在 NameOcean，我们经常聊"vibe coding"这个概念——用 AI 加速开发，同时保持对创意的掌控。

用过这些会反思的 AI 工具之后，我更清楚 vibe coding 为什么能 work 了。

Vibe coding 不是让 AI 全程代劳。而是在人类判断力和 AI 能力之间找到合适的分工。

这些反思型 AI 工具让我看到，这种分工最好的形态是这样的：

1. 人类负责抽象和原则。我们定义指导项目的概念框架。

2. AI 负责实现和模式执行。把我们定的大原则翻译成可运行的代码，按照我们定好的模式走。

3. 双方都参与持续的反馈循环。不管是人还是 AI，都不应该闭门造车。

效果最好的 AI 工具，都是和人类协作者保持良好对话的那些——接收高层指导、执行具体任务、汇报哪些有用哪些没用。

对开发团队的建议

如果从这些会自我改进的 AI 编程工具里只能总结一条，那就是：

开发的未来不是用 AI 能力取代人类判断。而是在人类智慧和机器智能之间建立更好的反馈回路。

对于想采用 AI 辅助工作流的开发团队，我有几个具体的建议：

• 重视反馈质量。团队解释"为什么 work"或"为什么不 work"的能力越强，AI 工具发挥的作用就越大。

• 记录的不只是做了什么，还有为什么。未来的 AI 协作者需要理解决策背后的推理，而不只是结果。

• 设计要考虑清晰度。结构清晰、模式可预测的项目能更好地发挥 AI 辅助的优势。

• 把 AI 工具当协作伙伴，不是魔法盒子。AI 能改进是因为它收到了好的输入。这个原则适用于任何 AI 辅助的工作流。

往大了说

看着一个 AI 系统审视自己的推理过程，还是挺有意思的。它逼我们面对一个事实：这些系统虽然能力强大，但本质上还是在训练数据概率上运行的 pattern 匹配引擎。

但话说回来——人类直觉不也是这样吗？

区别在于我们抽象的能力、因果推理的能力、以及把自己的推理过程讲清楚的能力。这些是即使 AI 工具越来越强大，人类依然保有的独特能力。

从会自我改进的 AI 编程工具身上学到的这些东西，归根结底不是关于 AI 本身的。是关于我们——我们给协作带来什么、从观察 AI 工作的过程中能学到什么、怎么调整我们的做法才能最大化利用手头的工具。

当 AI 辅助开发从例外变成常态，这些洞察会越来越有价值。能脱颖而出的开发者，不只是懂 AI 能做什么，更懂怎么和 AI 一起工作。

有时候，了解这种协作最好的方式，就是看一个 AI 工具怎么了解它自己。