AI 编程助手在真实仓库跑了两周：补全接受率 62%，净省下来的只有 8.4 小时

周二凌晨的那次回滚

一次 40 行的工具方法重构，AI 生成的版本单测全绿，但它把返回 null 改成了返回 Collections.emptyList()。下游 7 个调用方里有 2 个靠 != null 走分支，灰度 3 小时后订单状态同步错了 41 条记录，凌晨两点回滚。

测试没拦住，因为测试只覆盖了「有值」和「空集合」两个 case，没人给 null 写用例。这类「能跑、能过 CI、但语义变了」的改动，两周里我们数出来 9 次。所以我决定不再凭感觉评价这个工具，改成把两周的数据全部记下来。

先说清楚这两周是怎么统计的

• 环境：Java 12.4 万行、Python 3.6 万行，6 人团队，两条通道——IDE 行内补全，以及对话式改码（把文件或报错贴进去让它改）。
• 接受率的定义：IDE 弹出建议后被采纳的次数 ÷ 实际展示的次数。不采纳但自己敲的，不计入分子。
• 返工怎么扣：改动在 review 或测试阶段被推翻、需要人工重写的，一律记为返工，并把重写耗时从收益里减掉。
• 时间怎么计：以 15 分钟为粒度记工时，同时对照 IDE 操作日志和提交记录，避免凭回忆估算。
• 统计结果：补全实际展示 6,800 次、接受 4,216 次（62%）；对话式改码 61 次，平均往返 2.4 轮。两周结束后按上述口径轧账，净节省 8.4 小时，人均每周不到 45 分钟。

补全通道：真正吃到红利的是样板代码

把接受的 4,216 次按改动内容分了五类，接受率和返工率差得离谱：

• DTO、字段映射、getter/setter 类：接受率 78%，返工率 4%。这类代码有明确答案，模型几乎不会猜错，而且改错了一眼能看出来。
• 日志、异常包装、参数校验：接受率 71%，返工率 6%。模板性强，补全直接省掉抄上一段的动作。
• 单测骨架（空断言、Mock 结构）：接受率 66%，返工率 12%。骨架能用，但断言的期望值几乎每次都要人工改，这部分省的是打字不是思考。
• 业务分支逻辑：接受率 21%，返工率 31%。看着合理，细节全错——漏掉一个状态、少一个边界条件，review 时要从头读一遍。
• 并发、事务、缓存相关：接受率 9%，返工率 0（因为基本没人采纳）。模型写出来的加锁顺序和事务边界，比不写更危险。

结论很直接：补全的性价比和「这段代码有没有唯一正确答案」强相关。单条补全平均 11 行，越短的改动越容易对，超过 30 行的补全我们后来直接关掉不看了。

对话式改码：上下文塞得越多，结果越差

61 次请求按「给了多少上下文」分三档，看一次通过率（review 无需重写）：

• 只给 1 个文件 + 完整报错栈：一次通过 64%，平均 1.8 轮往返。这是唯一值得推荐的用法，报错栈里已经包含了模型最缺的信息。
• 给 3 到 5 个相关文件：一次通过 38%，平均 2.7 轮。模型的注意力被摊薄，经常改对 A 文件、改错 B 文件的调用。
• 给 8 个文件或整包：一次通过 12%，还出现过改了 3 个不该改的文件。此后我们规定单次最多贴 2 个文件。

另一个改动收益比预期大得多：在仓库根目录放一份 200 字以内的项目约定（命名风格、异常基类、禁止使用的工具类、测试框架），一次通过率从 30% 抬到 52%，这是这两周投入产出最高的一件事，成本是写 200 个字。

三类必须人工兜底的改动

• 把 null 换成空集合。就是开头那次回滚。模型天然偏好"优雅"的空值处理，但老代码里 null 往往承载了业务语义。现在 review 清单里加了一条：空值语义变更必须列出全部调用方。
• 重载方法签名变更导致调用方漏改。它给一个方法加了默认参数，编译期因为存在同名重载全部通过，运行时走错了分支。能编译通过不代表调用点正确，这类问题 CI 拦不住。
• 异步改同步、或反过来。为了"修掉"一个超时，它把异步调用改成了阻塞调用，接口延迟从 P99 800ms 变成均值 1.2 秒。性能类问题我们后来一律禁止交给它，只让它定位不改代码。

我们最后定下的五条规则

• 样板代码放开用：DTO、映射、日志、参数校验，接受率高、返工低，是纯赚。
• 业务逻辑只当草稿：可以让它写第一版，但 review 标准按新人对齐，逐行读，不省这一步。
• 单次上下文不超 2 个文件：宁可多问两轮，也不要塞整包。
• 性能、并发、事务问题只准定位不准改：让它分析堆栈和链路，改动由人写。
• 空值、签名、异步语义三类改动强制人工复核：写进 review 模板，不靠自觉。

小结

两周下来，这个工具不是没用，而是收益分布极度不均：样板代码那块是 78% 的接受率配 4% 的返工，业务逻辑那块是 21% 配 31%，净收益接近零甚至为负。8.4 小时的净节省听着不多，但它集中在最枯燥的部分，团队对这段工作的抱怨明显少了，这部分价值没法折算成工时。

真正该做的不是买不买，而是把「什么交给它、什么不给」写成规则，并且把 review 的注意力从"写得对不对"移到"语义有没有变"。前面那 9 次语义变更里，有 8 次是 review 时人工抓回来的——工具没变差，是我们终于知道该盯哪里了。

*（内容由AI生成，仅供参考）*