我用 AI Agent 替换了整个开发工作流——以下是真正有效的部分

我原本的目标并不是“用 AI 替换我的工作流”，而是想回答一个更具体、更诚实的问题：我的工作中，哪些部分真正需要打字（执行），哪些部分其实是我一直在假装是打字的判断？

于是，我把自己正常的流程——规划、编写、测试、审查、调试、发布——每个阶段逐一交给 Agent 处理，持续了几周。我保留了那些行之有效的环节，砍掉了那些行不通的。

以下是分阶段的成果总结。没有评分表，也没有“我提交了 40 个 PR”这种数字——只有哪些赢了、哪些悄无声息地失败的形态描述。

第一阶段：规划 —— Agent 擅长写计划，但不擅长做计划

我原以为规划会是 Agent 最弱的环节。它只对了一半。

把一个模糊的需求丢给 Agent——比如“用户抱怨结账速度慢”——然后让它制定计划，你会得到一份看起来像计划的文档：编号的步骤、需要修改的文件、回滚说明。读起来很顺畅，但它往往是为错误问题制定的计划，因为 Agent 用统计上最可能的解释填补了模糊性，而不是真实的意图。

真正起作用的是反其道而行之。我不再让 Agent 决定计划，而是让它根据我已经确定的规范起草计划。判断力——即我们究竟在解决什么问题——保留在我手中；打字工作——将其转化为验收标准、边界情况和文件列表——交给了 Agent，在这方面它确实比我快得多。

原则：Agent 能完美地将决策转化为文档。但它无法为你做出决策——而且它自信满满的草稿会掩盖这一点。

第二阶段：编写代码 —— 在你预期的领域获胜

这是大家脑海中浮现的阶段，也是结果最不令人意外的阶段，因为它就是能正常工作。

在以下方面，Agent 干净利落地获胜了，这些工作的难点在于执行而非决策：

• 具有清晰模式的 CRUD 接口
• 带有书面规范的迁移脚本
• 将表单连接到我已经设计好的 API
• 跨 30 个文件的机械式重构——关键在于，它在第 27 个文件时不会感到厌倦，而这恰恰是我容易引入拼写错误的地方
• 依赖项升级及随后的修复工作

在以下方面，它失败了：当代码本身很简单，但决策隐藏在其中的时候。例如：“为什么这一列允许为空？”、“这应该是一个服务还是两个？”、“这个边界情况是真实存在的还是理论上的？”。Agent 会对这三个问题都自信地给出答案，有时甚至是错的，而基于错误答案编写的代码看起来却是干净的、经过测试的、可以发布的。

原则：Agent 在处理那些建立在已有决策之后的代码时速度最快。危险在于，它们也会毫不犹豫地自行做出决策，而你无法从代码差异中看出这一点。

第三阶段：测试 —— 这才是真正的惊喜，也是真正的陷阱

编写测试是高执行、低荣耀的工作，所以我本以为它是纯粹的收益。大部分情况下确实如此——Agent 以零自我意识和零反驳地写出了堆积如山的“以后再说”的测试用例。这部分是个礼物。

但底下藏着一个陷阱，花了我一周时间才看清：

如果同一个 Agent 既写代码又写测试，测试就会通过——但它们毫无价值。它们测试的不是代码是否正确，而是代码是否做了它自己做的事。Agent 阅读了自己的实现，并写出了编码了其自身假设（包括错误假设）的测试。绿灯亮起，零信号。

解决方案是结构性的，而非提示词层面的：测试 Agent 必须是另一个不同的 Agent，它只获取规范，而不获取实现。现在，测试编码的是事物应该做什么，当测试与代码不一致时，这种不一致正是关键所在。

原则：来自同一 Agent 的代码和测试彼此一致，而不是与现实一致。分离作者和审查者，否则你只是在要求模型给自己的作业打分。

第四阶段：审查 —— 在这里我发现工作流实际上并没有变短

这是我犯错最久的一个阶段。

我在自己审查之前，添加了一个审查代理来阅读每一个差异。这很好——它能快速捕捉机械性的问题：未处理错误路径、缺失的空值检查、断言无效的测试。对于这类 bug，它比我晚上 6 点疲惫不堪时的初审效果更好。

但它无法做到真正重要的审查：这个更改是否解决了正确的问题？它是否会破坏距离三个文件之外、且不在差异中的某些东西？这正是代码代理产生的确切失败模式——每一行单独看都正确，但决策是错误的，而差异中没有任何地方看起来有问题，因为差异中的局部内容都没有问题。

因此，审查代理进行分类筛选；它并不能免除我的责任。判断性审查仍然落在我身上。正是在那一刻我明白了：我并没有从一周的工作中移除工作，我只是转移了它。输入代码的时间更少，而在前期编写规范和像对待恶意陌生人写的代码那样阅读差异的时间则多得多。

规则：第二个代理审查第一个代理的工作，能捕捉拼写错误，而非决策。判断性审查不可委托，假装它可以，是导致带有错误决策的干净差异被合并的原因。

阶段 5：调试——循环闭合时获胜，需要直觉时失败

调试清晰地分成了两类。

当存在封闭的反馈循环时——失败的测试、堆栈跟踪、可复现的错误——代理非常出色。它运行测试，读取失败信息，形成假设，打补丁，然后重新运行。这种循环是拥有终端的代理的本能，它会比我更快、更有耐心地完成这个过程。

当 bug 需要直觉时——“它在生产环境中很慢，但仅在特定情况下”、“只有那些在迁移前注册的用户才会遇到这个问题”——代理就会手足无措。它缺少它没有的东西：八个月前做出的、从未写入代码的那个决策的半记忆。这就是在那里经历过的人胜过任何上下文窗口大小的地方。

规则：代理闭合循环；它们不形成直觉。给它们复现步骤，它们就很棒。让它们在一个模糊的生产环境报告中寻找复现步骤，那你最好还是亲自开车去（意指亲自处理）。

阶段 6：无聊的粘合剂——纯粹、明确的胜利

PR 描述。变更日志。提交信息。发布说明。回填文档字符串。编写我总是跳过的“为什么”注释。

这是高打字量、低判断力的工作，没有人对此抱有自我意识。这是讨论最少但回报最清晰的阶段。如果你明天要在你的工作流程中加入一个代理，就选这个——零风险，立即收回时间，并且它会默默地让其他人的代码更易读。

规则：最安全、投资回报率最高的代理是编写你代码周围文本的那个，而不是编写代码本身。

诚实的总结：瓶颈移动了，并没有消失

如果绘制我前后一周的时间图表，总工作量并没有减少多少。变化的是时间的去向：

代理确实赢得了输入代码的部分。但它们从我身上收回的每一小时输入代码的时间，都以编写规范和阅读差异的形式还给了我——因为这些是他们自信的错误必须由我的判断来捕捉的两个地方。

这不是抱怨。这才是现在真正的工作，而且是一份更好的工作。但它是一份不同的工作，而那些感到痛苦的人是那些认为“AI 编写代码”意味着“AI 完成了工作”的人。代码从来不是工作。它只是恰好看起来像工作的部分。

我实际上会告诉你要做什么

1. 从胶水代码开始**（第6阶段）。零风险，即时回报，建立你对工具链的信任。
2. 然后是高频打字代码**（第2阶段）——但仅在你已经做出决策的地方使用。先手写规范。
3. 将测试代理与代码代理分离**（第3阶段）。这是整个设置中杠杆效应最高的结构性选择。
4. 让人类保留最终判断权。**使用审查代理作为初筛，绝不让它成为最终决定者。
5. 像对待陌生人写的代码一样审视每一个差异**——因为确实如此，而且这个“陌生人”不知疲倦，也永远不会说“我不确定这部分。”

披露：我在 xenition 上构建工作区助手，它能构建和运行代理——因此我让许多流程在我们的代理上针对我们的积压任务进行测试。请将我“始终在差异审查中保持怀疑态度”的立场视为构建者的偏见；我宁愿直言不讳也不愿隐瞒。

如果你已将部分工作流程迁移到代理上：哪个阶段表现良好，哪个阶段悄悄让你吃亏？我最感兴趣的是那些你以为安全实则不然的阶段。