AI辅助编程半年复盘：效率涨了40%，但技术债也多了一倍

背景

一个15人的产品研发团队，2025年底全面引入AI编程工具（IDE插件 + 终端Agent），到2026年中做了第一次系统性复盘。这篇记录真实发现，包括不好看的部分。

一、确实变好的地方

1. 事务性编码几乎归零。 写CRUD、改字段名、补类型定义、写单元测试骨架——这些过去占30%时间的活，现在大概只要一成时间。这部分收益是确定的，没有争议。

2. 新人上手速度明显加快。 以前新人要两周才能独立提PR，现在平均一周。原因是他们可以直接问Agent”这个模块的数据流是怎么走的”，不用打扰老同事。

3. 探索性工作的成本降低了。 “试试看用另一种方式实现”变得便宜了。半年里做了4次过去不会做的重构尝试，其中2次成功并保留。

4. 文档和代码的同步变好了。 因为写文档的成本趋近于零，接口变更时更新注释的比例从30%左右上升到了80%以上。

二、变差的地方（这部分更重要）

1. 代码量激增，审阅成为新瓶颈。 合并的代码行数涨了约2.2倍，但PR审阅时间是原来的一倍多。原因很直接：AI写的代码看起来都对，但细节经不起推敲。审阅者不能扫读，必须逐行看。

2. “能跑但没人懂”的模块变多了。 半年后做了一次抽查：随机选10个近三个月AI主导开发的模块，让作者解释实现逻辑，有4个答不上来关键设计决策。这些模块成了事实上的黑盒。

3. 重复实现大量出现。 同一个日期处理逻辑在三个模块里各写了一遍。因为每个Agent只看到自己那一片上下文，不知道仓库里已经有工具函数。

4. 测试数量涨了，测试质量没涨。 AI很擅长生成测试，但它倾向于测”代码做了什么”而不是”业务应该是什么”。很多测试在重构时全都得改，起不到保护作用。

5. 依赖膨胀。 为了省事，Agent会顺手引入一个小库解决问题。半年里新增依赖47个，其中12个是可以用标准库或现有工具替代的。

三、三条真正有效的治理规则

试了很多方法，最后留下来的是这三条。

规则一：AI生成的代码必须能被作者解释。 PR模板加了一栏：“请用三句话说明这个改动的核心设计决策及取舍”。写不出来就不能合。这条规则执行的第一个月，AI代码的合并量下降了30%，但返工率降了一半以上。

规则二：引入新依赖需要单独说明。 PR里出现 package.json / requirements.txt 变更时，必须写明”为什么标准库或现有依赖不行”。这条直接掐掉了大部分顺手引入。

规则三：每周一次”AI代码考古”。 每周四下午，随机抽两个AI主导的模块，由一个不熟悉的人去读，记录”看不懂的地方”。这些地方后续补注释或重构。这一条把黑盒率从40%压到了15%左右。

四、一个反直觉的发现

效率提升和任务类型强相关。

任务类型	效率变化	返工率变化
样板代码/CRUD	+150%	基本不变
单元测试编写	+80%	略升
陌生技术栈探索	+60%	下降
核心业务逻辑改造	+10%	明显上升
跨模块架构调整	-20%	明显上升

最后两行值得注意。在需要全局理解的场景，AI不但没帮忙，反而因为局部最优的改动引入了不一致。 这类任务我们后来明确要求：先用AI做分析，但设计必须人来定。

五、半年后的净收益

客观地说，是正的，但远没有宣传的那么夸张。

• 交付速度：+35%到45%（按功能点数）
• 缺陷密度：基本持平（有AI辅助测试抵消了部分新增风险）
• 技术债：上升约一倍，但其中大部分是”可解释但重复”的低风险债，可通过定期清理消化
• 团队满意度：分化。喜欢的人非常喜欢，觉得被剥夺了”写代码的乐趣”的也有三四个

六、给其他团队的建议

1. 先定规矩再推工具。 没有审阅纪律的团队引入AI编程，会以更快的速度积累技术债。
2. 保留一部分”纯手工”的任务。 让工程师保有对代码的掌控感，这关系到长期士气。
3. 把AI用在你最不擅长的技术上，而不是最擅长的。收益最大的地方往往是你最怕碰的地方。
4. 每季度做一次代码考古。 主动发现黑盒，别等到出事故。

结语

AI编程工具确实改变了工作方式，但它放大的是团队原有的习惯——纪律好的团队变得更快，纪律差的团队变得更乱。工具没有解决问题，它只是让问题更快地暴露出来。