AI编程实测:写代码只占20%时间,剩下的时间花在验收上

“AI让程序员效率提升3倍”——这句话的问题不在于真假,而在于它是拿编码时间算的。而编码从来不是研发的瓶颈。

我们用四周时间,对一个5人小组的12个需求做了完整的时间归因记录,结论值得每个技术负责人看一眼。

实测时间去哪了

单需求平均工时从18.4小时降到14.9小时,整体提升19%。但拆开看每一段的耗时变化:

环节	用AI前	用AI后	变化
需求理解与拆解	2.1h	2.3h	+10%
编码	7.8h	3.1h	-60%
代码审查	1.4h	3.6h	+157%
测试与验证	2.6h	3.4h	+31%
调试与返工	2.3h	1.7h	-26%
联调与部署	2.2h	0.8h	-64%

编码确实被吃掉了六成。但这部分省下的4.7小时,有3.4小时被审查和验证吃掉了。

为什么审查变重了

三个直接原因:

第一,代码量涨了。 AI倾向于把简单逻辑写得更“完备”——多一层封装、多一个兜底、多做一次校验。单PR平均行数从180涨到310。更多代码意味着更多的阅读负担,而不是更少。

第二,风格不统一带来的心力损耗。 同一个模块里,AI生成的风格随prompt措辞漂移:一会儿用可选链,一会儿用显式判断;一会儿抽helper,一会儿内联。审查者需要判断“这段写法是否合理”,而不是“这段写法是否一致”。前者成本高得多。

第三,责任感的错位。 人写的代码,审查者心里有底:“他大概想清楚了。”AI写的代码,审查者必须假设每一行都可能是幻觉,尤其是边界条件、并发、异常路径。信任成本远高于理解成本。

三个真正有效的调整

把约束前置成文件,而不是每次写进prompt

团队建了一个 AGENTS.md,固定写清:命名规范、不允许的库、错误处理约定、测试框架、目录结构。AI工具每次自动读取。这一条让PR行数平均下降了22%,风格抖动基本消失。

用“验收标准先行”替代“需求描述”

改法很朴素:在让AI动手前,先由人写下三条可执行的验收条件,比如“空列表时返回[]而非null”“超过1000条自动分页”。这些条件直接变成测试用例,AI生成实现后先跑测试,人后看代码。

效果:测试与验证环节的返工率从31%降到9%。因为判断标准在编码前就锚定了,不在审查时才争“这样做对不对”。

把审查拆成两遍,别混在一起

第一遍只做逻辑审查(这段是否做了它声称的事、边界对不对),不看风格;第二遍由linter和格式化工具自动处理形式审查。两遍混在一起时,人会在格式噪音里耗尽注意力,漏掉真正的逻辑缺陷。

算账要算到交付

如果只看编码环节,你会得出“提升60%”的结论,进而给出不切实际的排期承诺。而实际端到端提升是19%,其中相当一部分来自联调和部署的自动化,而不是代码生成。

更诚实的指标是:

• 每需求返工次数(而不是生成速度)
• PR平均审查时长
• 线上缺陷密度(AI代码的缺陷密度在首两周通常更高,因为边界场景想得少)

AI编程工具值得买,但它不是一个加速器,而是把工作从键盘转移到眼睛的置换器。你的团队里,眼睛够用吗?