AI 编程真的能实现 10 倍效率的提升么?

AI 编程真的能实现 10 倍效率的提升么?

最近读到了几篇文章，不约而同地指向了如何高效利用 AI 工具编程。我一直对用 AI 编程实现效率飞升（编程自动化）很感兴趣。但我在个人实践中遇到了很多阻力，感觉最先进的一批人向你传输着有些疯狂的方法论，号称效率能提升 10 倍，但我拿到公司里时在这套方法论的最开始几步就卡住了，最终我的效率可能提升了 1.2 到 1.5 倍，但绝对没有 10 倍。我在思考这中间到底出现了哪些问题，有哪些改进的方式。

目前先进的 AI 编程方法论是什么

在讨论阻力之前，先对齐一下目前先进的方法论是什么。这里推荐直接看影响到我的原文：

微信公众号文章：胡渊鸣 | 我给 10 个 Claude Code 打工

Steve Yegge: Welcome to Gas Town

这两篇文章都在描述他们目前是怎么使用 AI 工具编程的，我从中看到了许多共性。两位作者都不是泛泛之辈，所以他们的话对我来说是有分量的。当这些人不约而同地描述了一种十分类似的方法，我认为这可能代表了未来自动化编程的范式，值得深入剖析。
先简述一下他们二人使用 AI 编程工具的进化路线：

Figure 1: 古法编程
Figure 2: 用 Cursor 等 IDE 工具写 prompt 编程，但还是把主要精力放到阅读和审查代码本身
Figure 3: 用 Cursor 等 IDE 工具写 prompt 编程，十分相信 AI 输出的结果，但依然浏览代码
Figure 4: 用 Cursor 等 IDE 工具写 prompt 编程，彻底相信 AI 输出的结果，且几乎不看代码
Figure 5: 弃用 Cursor，改用 Claude Code (CC)。由于 Claude Code 是 CLI 工具，天生不太支持看代码，这背后象征着对 AI 结果的彻底信任，并完全放弃看代码
Figure 6: 发现只 prompt 一个 CC 不够高效，开始多开 CC， 通过 git worktree 等方式同时完成多个项目，或者一个项目的多个 feature。
Figure 7: 发现只开几个 CC 依然有些保守，开始探索最多能并发多少个 CC，但依然保持对项目的掌控力。
Figure 8: 发现人工掌控 8 个甚至 10 个 CC 已经不现实，需要一个工程解决方案。第一篇文章里胡渊鸣设计了一个 UI，作者可以发布任务，系统每次自动生成一个 CC 实例接取一个任务，自主编码、测试、提交，并在 ui 上更新项目状态。从而管理 10 个 CC。而第二篇文章里 steve yegge 设计了一套十分复杂的名为 gastown 的系统，里面有各种角色的 agent，但归根结底思路还是有 worker agent 具体去做 task，有 orchestrator 组织跟进项目进度，从而实现了更高程度的自主化。

两篇文章沿着相近的路径走到了看类似的终点，可以概括为：

• 完全相信并使用 AI 写的代码，且着重强调人类不能再做代码审核。
• 强调对 prompt 的设计，不能简单地说"帮我写个 XX 软件"。而是和 AI 把 XX 软件拆分成非常细颗粒度的任务。
• 用类似 Rough Loop 的技巧确保 AI 能完成每个非常细颗粒度的任务，并能自己验收
• 解决了单个 coding agent 能完成一个细颗粒度任务后，设计任务分发系统，让多个 coding agent 并发领任务，写代码，测试，迭代，提 pr，解决 merge conflict，上生产。
  

只要实现了 Figure 8，人类只需要在宏观层面对项目有所把控（i.e. 有能力提出项目构想，并把项目和 AI 一起拆细），剩下的都给 AI 完成。理论上一个人脑和尽量多的 token 就可以十分迅速地完成一个项目，听起来十分美好。

恰好我所在的公司也眼馋自动化编程的效率飞升，并极力推进。方法论层面先进的开源社区都已经帮你想好了，似乎只要沿着这个方案落地就行了。公司尽量提供最好的 coding agent，对 token 用量也不设限制，看起来已经万事俱备。

阻碍与陷阱

尽管如此，我的观察是公司里大部分人依然停留在 Figure 2。他们可能已经在用 CC 这类 CLI 工具，但依然无法完全相信 AI 输出的结果，还是要在编辑器里审核代码。也确实能发现 AI 写的代码时不时出问题，并以此为例证不能完全相信 AI，人工审核是必须的。尤其我们的代码都要进生产，一旦出了什么问题必须为其负责。

这些担心都是有道理的，也是开源社区流出的这些理论落地时的难点。我不确定是因为这些方法论文章已经解决了代码质量问题，只是篇幅有限没法说清所有细节，还是他们的实践和在公司环境里写代码有差距。无论如何，我认为在目前的企业系统里，大家对 AI 编程的种种顾虑导致效率只提升了 1.2 倍到 1.5 倍，甚至有文章质疑效率可能下降了。问题究竟出在哪？

我想具体分析一下目前的所有挑战，以及探索解决方法：
最大的挑战：如何相信 AI 产出的代码？

首先明确"信任"的定义：在无需人为/用 prompt 反复修改代码的情况下，将 AI 产出的代码部署到生产。

Code Review 的本质是什么？

要理解为什么人类不信任 AI 代码，先要理解为什么人类信任别人的代码，而要理解人类如何信任别人的代码，需要先理解 Code Review 。
我们先假定一个场景，团队里有 10 年经验的高级工程师正在 review 只有 2 年经验的初级工程师的某个 pr，他挑出了很多问题，比如变量的命名不规范，测试不齐全，一些 external request 没有用 async 导致堵塞进程，config 设置了许多默认值，导致从文件里读取失败了也不报错，等等等等。最本质发生的事情是：高级工程师脑子里有大量关于代码该怎么写，这么做不好因为会有 XX 问题的知识和经验，而他在通过 code review 提 comment 的方式，和缺少这些知识的人做一次对齐。

这些知识可以分为两类：

客观的 Best Practice：来自多年的实践和经验，有明确对错之分。比如 Python 的 Context Manager 应该正确实现 __exit__ 来释放资源；错误处理应该覆盖所有分支；switch 语句需要一个兜底的 default。这类知识的体量非常庞大，杂乱，难以像教科书一般有序的作为一个个章节供人学习，也可能没被写进任何文档，但在社区里是有一定共识的。

主观的 Preference：在这里共识程度进一步减少，更多只是个人偏好。比如一个表示连接状态的变量，叫 is_connected、connected 还是 connection_active 应当都可以接受。这类问题可能没有社区共识，但可以有团队共识。

Code Review 的本质，是让这两类知识从高级工程师的脑子里流向初级工程师以及代码库。问题在于这些知识中的大部分从未被写下来。

隐性知识显性化

一个资深工程师在 PR comment 里写的，只是他脑内知识的冰山一角。他发现了问题，留下几句反馈，但他心里有一套完整的推理过程，那套推理过程大概率没有出现在任何文档里，甚至在 comment 里也只留下了你该这么做，而不一定有你为什么要这么做。随着 review 次数和线下讨论次数的增多，初级工程师逐渐理解了什么是好的代码，以及什么是高级工程师的 preference。代码质量也因此不断提升——这个过程本质上是知识在人与人之间的缓慢传播。

我们应该已经有共识现在顶尖的 AI 模型起码能和初级工程师做的一样好，如果你能教好初级工程师，那应该也能教好 AI。将这些隐性知识显性化，便是让人类能够信任 AI 代码的核心关键。

根据我个人的观察，AI 代码被驳回的原因和初级工程师被驳回的原因是出奇一致的：

• 30%：小 bug——注意这里说的是"小"bug。目前的 AI 写代码基本能确保项目跑起来，不会出现低级的编译错误或逻辑错误。这里指的是更隐蔽的问题：比如异步请求没有正确处理异常导致进程静默失败、分页逻辑里的 off-by-one 错误只在边界数据时触发、对 NONE 和空列表没有区分处理等。这类 bug 在正常测试中不易发现，但在生产环境的真实数据下会暴露。
• 25%：细节处理问题——违反了有明确对错的最佳实践（错误处理不完整、资源未释放等）。
• 25%：团队偏好问题——规模较大的主观约定，比如"当同类的 class 超过一定数量时应该抽象成基类"、"外部 API 调用统一封装在 service 层而不是直接在 handler 里调用"。
• 10%：命名与风格的 nitpick——更小粒度的偏好，比如函数命名风格、变量命名是否语义清晰、注释的详略程度等。
• 10%：不认同解决方案——这是最高层次的否定：reviewer 认为整个解决思路从一开始就走错了方向，哪怕具体代码写得再好也毫无意义。比如接口响应慢，AI 选择在应用层加缓存，但 reviewer 认为根本原因是 N+1 查询，应该在数据库层用 eager loading 解决；或者需要限流，AI 在业务代码里实现，reviewer 认为这种横切关注点应该在 API gateway 层统一处理。代码本身可能没有任何问题，但整条路走偏了。
  

仔细看会发现，前 90%都是针对 pr 本身的实现的质疑。而所有这些问题，无论客观还是主观，都可以被文字化。客观问题有现成的社区规范可以参考；主观偏好只要团队核心贡献者达成共识，写入文档，对 AI 而言就和客观规范没有区别，同样是可以遵守的规则。唯一的例外是这 10% 的"不认同解决方案"——这类问题不能靠 Coding Standard 解决，因为它否定的不是代码质量，而是动笔之前的技术决策。

结论：100% 的 code review feedback 都可以被预先处理，只是处理方式不同。
我在做的尝试与局限

让我们先讨论前 90%，我曾经做过一个简单的实验：把一段被同事驳回的 AI 代码，连同 reviewer 的 feedback，一起发给另一个 AI，问它"这个 feedback 是否合理"。它几乎总会回答"是的，这里确实违反了 X 原则"。

这说明 AI 具备判断能力。它知道规则，只是在写代码时没有被提示去应用规则。

带着这个认识，我尝试为 Coding Agent 建立了一套 Coding Standard——一份描述"这个项目的代码应该怎么写"的文档，并在每次写代码时要求 Agent 读取这份文档。结果是：有改善，但不稳定。尤其当规范涉及多个 category 时，AI 很容易只注意到其中几条，漏掉其他的。所以问题不是 AI 不知道规则，而是规则太多、上下文太长时，它的注意力分散了。

解决方案：两层架构

既然已经定位了问题，解决方案就有了方向。

第一层：打造会不断进化的 Coding Standard

与其试图一次性写出完整的规范文档（几乎不可能），不如让它从实践中生长出来。

我的具体做法是为每个项目维护一套 Coding Standard。在每次 code review 后将收到的 feedback 更新进去。最开始的版本势必很不完整，可以先放一些社区里讨论出来的代码规范，随着 review 次数增多，它会吸收越来越多的团队共识，并逐渐完善。而这个过程本身一定程度上也可以被自动化：给 AI agent 连结到 github 的权限，读取 PR 的 comment，提取 feedback，人工思考要不要接受这个 feedback，最终归类并更新对应的文件。

文档结构上，我按 category 拆分成多个小文件（命名规范、OOP 设计、资源管理、错误处理……）比维护一个臃肿的大文档效果好很多，AI 在需要时可以按需取用。目前的拆分方式是否最合理我还没想清楚，可以再讨论。

第二层：多 Agent 并行 Review Pipeline

光有被拆的很细的规范还不够。上面提到 AI 在写代码时注意力会分散，解决方案是把"写代码"和"review 代码"彻底分开，交给不同的 agent 来做。
写完代码的 AI 在同一个 context 里已经有了一套解释为什么这样写合理的逻辑——就像人类作者一样，它会倾向于为自己辩护。换一个全新 context window 的 reviewer，才能真正做到客观。

更进一步：当规范涉及 5-8 个 category 时，一个 reviewer agent 仍然会顾此失彼。更好的架构是让每个 agent 只负责一个 category，并发进行 review：

人类 + Coding Agent 共同制定 spec.md
（记录解决思路和技术方向，不涉及代码细节）
        ↓
Reviewer 审阅 spec，确认方向可行
        ↓
Writer Agent 根据 spec 写代码
        ↓
提 PR（为了得到清晰的 diff，方便 reviewer 只看改动部分）
        ↓
并行启动 N 个 Specialist Reviewer Agents
（每个 Agent 只检查一个 category，只看当前 PR 的改动，
比如 Agent 1 只检查所有 comment 和 docstring 是否符合规范，
Agent 2 只检查所有 class 有没有被正确抽象成基类，等等）
        ↓
汇总所有 review 结果，生成统一的 Review Report
        ↓
Fix Agent 读取 Review Report，逐条处理每一个 comment
        ↓
运行测试，确保修复后代码仍然可以正常运行，通过 lint
        ↓
更新 PR
        ↓
Reviewer 最后审查一次，此时应该已经不再会有太多 comment

这里有两个细节值得注意。

第一，reviewer agents 产出的不是直接对代码的修改，而是一份 Review Report——每条意见独立列出，注明位置和原因。这样做是因为多个 agent 并发修改同一份代码很可能产生冲突；统一交给一个 Fix Agent 按顺序处理，能确保每次修改都是在最新状态的代码基础上进行的。

第二，这个 pipeline 是 recursive 的。Fix Agent 修改代码之后，可能引入新的问题，或者某些修复本身需要再次 review。在实践中，跑完一轮 review-fix 之后，可以再触发一次 reviewer agents 确认没有遗漏，直到 Review Report 为空。

最后，这个 pipeline 通过 pre-commit hook 强制触发，不依赖人的主动操作。

这套做法固然会提高 token 消耗，以及花费更多时间，但在更高质量的代码面前这一切都是值得的。

把眼光再拉高：一个 spec / plan，一个 PR

前面提到的 10% "不认同解决方案"，无法靠 Coding Standard 或 review pipeline 解决——它发生在写代码之前。解决方法因此很直接：在 AI 开始写代码之前，先出一份简短的技术 spec，和 reviewer 对齐方案。

这份 spec 不需要很长，核心是说清楚三件事：要解决什么问题、打算用什么方案、为什么选这个方案而不是别的。比如同样是解决接口响应慢的问题，spec 里写明"确认根本原因是 N+1 查询，用  selecte_related 解决，而非加缓存"——reviewer 一眼就能判断方向对不对，不需要等代码写完再推翻。
spec 和 PR 之间是一一对应的关系：一个 spec，就是一个 PR 的全部改动范围。这意味着在写 spec 的时候，PR 的边界就已经确定了——不存在方案对齐之后还要单独思考"这次该改多大范围"的问题。

因此，spec 的粒度直接决定了 PR 的大小。判断标准只有一个：

spec 描述的改动完成后，系统是否处于一个完全可工作的状态，没有任何过渡性的残留？

举个例子：需要为系统新增用户权限控制，按 user_role 字段区分普通用户和管理员。如果把 spec 拆得过细：

• spec 1：给 User 表加  user_role 字段（数据库有了这列，但没有任何代码读它）
• spec 2：在 User 模型和 API 序列化里暴露 user_role (字段出现了，但权限逻辑还没接入）
• spec 3：在权限检查里使用 user_role 功能终于完整）
  

spec 1 和 spec 2 合并之后，线上会出现一个毫无意义的数据库字段，读了但不用；spec 2 合并之后，有 API 返回了  user_role，但它对任何行为都没有影响。这些都是"过渡性残留"——代码在生产环境里跑着，但功能是残缺的。

正确的做法是把三件事写进同一个 spec：migration、模型更新、权限逻辑一并完成。PR 合并之后， user_role 立刻生效，系统处于完整可用的状态。
当然，有些功能天然涉及多个组件——比如一个新 feature 同时需要改数据库 schema、后端 API 和前端展示。这时可以先有一份宏观的技术方案，梳理清楚三个组件各自要做什么，但落地时每个组件单独出一份 spec，分别对应一个 PR。把前后端改动打包进同一个 PR，只会让 review 更难、风险更高。

spec 太小的信号：完成后线上出现未被使用的数据库字段、没有接入的接口、或功能残缺的中间状态。
spec 太大的信号：改动横跨多个相互独立的组件，改动动辄十几个文件，修改几千行。

让 AI 拥有和人类一样的工具

还有一件严格意义上不在 code review 范畴里的事情：哪怕是初级工程师，在提 PR 之前，也一定会先把代码跑一遍，确保它起码能正常运行、基本逻辑没有问题。比如我改了后端逻辑，会影响前端展示的样式，那我会把前后端都在本地拉起来，自己跑一遍，有足够的信心后才让他人来 review。

如何让 AI 在基础的单元测试之外，也能像人类一样进行集成测试甚至 UAT，也是让 AI 自我审查代码的关键。关于这一点，目前主流的方案是给 coding agent 独立的 sandbox 环境，让它自己能够跑自己的代码。可一旦验证环境比较复杂，比如改动需要别的上游依赖，比如需要几轮繁琐的 ui 操作才能复现，那简单的 sandbox 可能就不够了，还需要诸如浏览器操作，写入数据库等工具和对应的权限。

这一点在公司环境可能尤其难办，只能说简单跑一遍自己写的代码确保能够编译大多数时候还是能做到的，进一步靠 UAT 验证正确性可能就有些挑战了。

Figure 2 → Figure 3

有了 Coding Standard 加上多 agent review pipeline，AI 写出来的代码质量会大幅提升并符合团队规范。这时人类再 review 一遍，也不会花多少时间。因为绝大多数问题在提 PR 之前就已经被自动修复了。人工 review 从"逐行审查、频繁打回"变成了"快速确认、偶尔补充"。

当然，这是一个逐渐完善的过程。一开始 Coding Standard 肯定是不完整的，不可能覆盖所有情况。但每一次人工 review 发现的新问题，都会被沉淀进 Coding Standard，让下一次的 AI review 覆盖得更全面。随着时间推移，这份文档趋于收敛，AI 代码的质量也会随之稳定提升。

Figure 2 里，人类的认知工作在于审查代码——需要深入技术细节，理解 AI 的实现逻辑，成本很高，且严重拖慢了整体效率。

Figure 3 里，人类的认知工作转移到两件事：一是在项目开始前定义清楚 task 的边界；二是在迭代过程中把 feedback 持续沉淀进 Coding Standard。这些工作需要业务理解和系统思维，但不需要逐行审查代码，使得速度有很大提升。

不过有一点不得不承认：在企业环境里，我们可能暂时无法完全淘汰人工 Review。即便有了 Coding Standard 加上多 agent review pipeline，依然会有人出于责任心、合规要求、或者对 AI 的根本性不信任，坚持过一遍代码。

这没有问题。我们追求的不是"人类再也不看代码"，而是"人类不需要花大量时间改代码"。当 AI 在提 PR 之前已经把代码质量问题处理得七七八八，人工 Review 变成了快速确认，而不是逐行批注的审查，推翻重做。这个差别，足以带来 2 倍的效率提升，已经是一个非常可观的改进。

Figure 3 → Figure 7

跨过 Figure 2 → Figure 3 这道最难的坎之后，Figure 4 到 Figure 7 其实没有本质上的新障碍。

在技术层面，支撑并发工作的关键工具是 Git worktree。它允许在同一个 repo 里同时 checkout 多个工作目录，每个 Coding Agent 在自己独立的 worktree 里工作，互不干扰。不需要反复 stash、切换分支，每个 agent 的修改在 merge 之前都是完全隔离的。这个技巧本身没什么门槛，只是一条不太为人所知的 git 命令。

Figure 7 → Figure 8

在此基础上，当我们同时推进多个 spec、并发多个 Coding Agent 工作时，就来到了 Figure 8 的领域，如何集中管理这些 agent。
胡渊鸣和 Steve Yegge 各自搭建了相当复杂的系统，但我认为完全可以做一个极简版本，把核心跑通：

• 把一个大项目拆成若干个小 task，每个 task 的粒度满足前文提到的标准——完成后系统处于可独立部署的状态
• 每个 task 生成一份 spec 文件，经人审核签字后进入待执行队列
• 空闲的 Coding Agent 从队列里领取一个 task，在独立的 git worktree 里开始工作
• 代码完成后，自动触发前文描述的 review pipeline：specialist reviewer agents 并发检查、生成 Review Report、Fix Agent 逐条处理、跑测试
• pipeline 跑完后提 PR，人工做最后的轻量确认
• 所有 PR 合并时统一处理 merge conflict
  

这个极简版本不需要复杂的 gas town，也不需要专门的任务分发 UI——一个共享的 task 列表加上一套约定好的工作流，就能让多个 agent 有序地并发推进。

即便受制于企业环境里必须保留人工 Review 这个约束，同时运行 3 到 5 个 Coding Agent 在技术上是完全可行的。3 到 5 倍的效率提升，在高质量代码要求和严格合规要求并存的企业环境里，已经是一个相当现实且可以达成的目标。当然，我不得不承认，因为我在这一领域还没有太多机会开始探索，在实际中遇到的问题也不够多，所以想法可能还不够成熟。

结语

回到最开始的问题：自动化编程真的能实现 10 倍效率的提升吗？

在个人项目或小型团队里，按照胡渊鸣和 Steve Yegge 描述的方法论走到 Figure 8，10 倍也许并不遥远。但在企业环境里，我认为更诚实的答案是 3 到 5 倍——哪怕人工 Review 依然存在、AI 无法完整运行自己的改动、仍需人工介入，这也是一个可以系统性达成的目标。

这中间最关键的一步，是本文着重讨论的 Figure 2 → Figure 3：建立一套让人类能够合理信任 AI 代码的质量保障体系。没有这个基础，后续的一切并发和编排都是空中楼阁。

解决了这个问题，剩下的才是可以用工程方案去解决的 Figure 7 → Figure 8。由于目前还没有足够的探索，可能在之后会遇到更多的问题，并进行更多的讨论。