AI 编码助手融入团队研发流程的实践

半年过去了，我们团队到底提效了多少

2024 年 10 月我们组 11 个人开始全面用 AI 编码助手，到今年三月底正好半年。这半年里我在各种场合听到的说法从"提效 50%"到"就是个高级补全"都有，差距大到不像在说同一个东西。所以我们拉了数据自己看了一遍，顺便把踩过的坑和定下的规矩记下来。

数据是怎么来的

先看方法，不然数字没有说服力。我们取了两组数据：

• 时间数据：Jira 上 2024 年 4~9 月（使用前）和 2024 年 10 月~2025 年 3 月（使用后）的所有开发任务，看"开始开发 → 提交 CR"的时长。两个半年各约 620 条，剔除了超过 20 人日的超大任务和不到 0.5 人日的琐碎任务；
• 质量数据：测试环境缺陷数、线上缺陷数、CR 平均轮次。

结论是：提速是真的，但远没有宣传的那么夸张，而且分布极不均匀。

规律很清楚：模式固定、有明确范式的活提速明显，需要理解上下文和做判断的活几乎没变化。写 CRUD、写测试、接 SDK 都是模板化的，AI 干得很漂亮。而复杂业务逻辑改动、性能排查这类，AI 能帮忙但帮不了多少，因为瓶颈根本不在敲代码上——在于你得先想清楚要改成什么样。

我们划的三条边界

踩了几次坑之后，组里形成了不成文的规矩，哪些让 AI 写、哪些不让。

放手让它写：样板代码和测试骨架

Controller、DTO、Mapper、枚举转换、单元测试的骨架，这些我们基本全交给 AI。写法是给它一个已有的同类文件当例子，让它照着生成，效果比从零描述好很多。比如：

参考 OrderController.java 的写法，生成 RefundController，包含列表查询、详情、创建、取消四个接口，字段参考 RefundDTO.java。

这类代码生成完自己扫一眼命名和参数校验就行，出问题也容易发现。

让它写但要逐行验：涉及外部依赖和边界条件的代码

这里出过两次事故。第一次是 AI 生成的一段 Redis 分布式锁代码，用了 setIfAbsent 但没设过期时间，也没处理业务超时释放的问题。代码看着很规范，注释都写好了，CR 时三个人都没看出问题，上线后一个死锁卡了两小时。

第二次更隐蔽。AI 写了段调用内部接口的代码，其中用了一个 RetryUtils.exponentialBackoff() 方法——这个方法根本不存在，是它根据命名习惯编出来的。编译阶段就报错了，倒是没跑上线，但如果是个真存在但语义不同的方法呢？

所以现在的规矩：AI 写的代码里，凡是涉及并发、事务、重试、超时、外部调用的，必须人工逐行验证，并且必须验证它调用的方法真实存在。

完全不让它碰：核心算法和权限逻辑

我们的计费规则引擎、权限判定、对账逻辑，一律不让 AI 生成。倒不是不信任质量，而是这些代码的正确性依赖大量业务背景，AI 不知道，写出来看着合理其实是错的，而且这种错误极难在 CR 和测试里发现。

CR 的重点彻底变了

这个变化比效率提升更值得说。以前 CR 评论里最多的是："这个变量可能为 null"、"异常没处理"、"这段可以抽个方法"。现在这些低级问题 AI 生成的代码里几乎没有，反而出现了三类新问题。

我统计了最近三个月 214 条 CR 评论，按类型分：

看得出重点整体后移了。以前是"这代码写得对不对（语法层面）"，现在是"这代码做的事对不对（语义层面）"。后者对 Reviewer 的要求高得多——你得真的懂这块业务，不然 AI 生成的那段"看起来很专业"的代码你根本审不出来。

我们现在的做法是：作者在提交 CR 时必须标注哪些部分是 AI 生成的（提交模板里加了勾选项），Reviewer 对这部分重点看边界和依赖真实性。这个标注不是监督，是帮 Reviewer 分配注意力。

几个不怎么被提到的问题

除了代码本身，还有几个副作用值得说：

• Junior 的成长路径被打断了。以前新人通过写大量样板代码熟悉项目结构和规范，现在 AI 一键生成，他们对代码库的熟悉程度明显不如两年前的同龄人。我们现在的应对是让新人手写前两个月的 CRUD，熟悉了再放开用；
• 代码同质化严重。AI 生成的代码风格高度统一，导致不同模块长得一模一样。表面看是好事，实际上是失去了"不同人写不同模块"带来的隐性多样性——包括错误也是同质的，一个 AI 生成的错误模式会在多个模块重复出现；
• 代码量虚高。我们半年里代码行数涨了 31%，但功能数只涨了 12%。AI 倾向于写"完整"的代码——更多的判空、更多的 try-catch、更多其实用不上的扩展点。这些代码不会出 bug，但会增加维护负担；
• 注释和文档变多了但质量下降。AI 很爱写注释，包括那种"// 设置用户名"这种废话注释。我们后来在 CI 里加了个检查，注释必须解释 why 而不是 what。

我们最后定下的五条规矩

1. AI 生成的代码必须逐行读过才能提交，不接受"跑通了就提交"；
2. 涉及并发、事务、外部调用、权限的代码，AI 只能做草稿，核心逻辑必须人工确认；
3. CR 时标注 AI 生成范围，Reviewer 重点验边界和依赖真实性；
4. 单元测试可以让 AI 写骨架，但断言必须人工写——AI 写的断言经常是"验证它返回了它返回的东西"，毫无意义；
5. 不把 AI 生成的代码作为新人学习材料，反之新人前两个月手写为主。

小结

半年下来我的判断是：AI 编码助手是个非常称职的"高级打字员"，能把你脑子里已经清楚的东西快速敲出来，但没法替你想清楚那些不清楚的东西。对我们组而言，总体开发周期缩短了大约 25%，其中主要来自样板代码和测试这两块。

真正的挑战不在工具，在流程适配。CR 标准要重写、新人培养方式要调整、代码量要控制。这些如果不管，效率提升的部分迟早会被维护成本吃回去。我们组这半年代码行数涨 31% 这件事，我到现在还觉得是个隐患。

参考

• 官方文档：ai-agent
• Baeldung 上的相关实战
• StackOverflow 上的相关讨论