北京
最近一种在 AI 辅助开发团队中反复出现的失败模式，正在引起越来越多的注意。大致路径是：一个团队开始认真引入 AI 代码生成工具，开发速度明显提高——从进度图上看，增长大概持续两个季度之久，所有人都很满意。但紧接着，事故率开始攀升，而且从速度提升到事故增多这两件事之间的关联，要花相当长的时间才被识别出来，因为出事的地方分散在各种细微之处：比如一个原本该加却始终没加的空值检查，权限验证被放在了错误的调用层，或者一条在几千行数据量下毫无问题的 SQL 查询，当行数增长后就因为没有索引而直接拖垮服务。
追根溯源，这并非工具本身出了故障，真正的原因是：代码生成的通量提升了，而人对代码的理解通量并没有同步提升，同时团队也没有针对新的约束去调整流程。换句话说，以前写作代码的人天然会理解这段代码，因为“写”本身就是他们理解的过程。可现在，当大量代码由模型生成，审查就成了第一次有人真正去理解那个逻辑的时刻，这完全是另一种性质的任务，而且每一行代码所需的审查时间不是更短，而是更长。
需要正视的现实是：代码审查承载力已经成了当前 AI 辅助开发流程中最吃紧的瓶颈。两条曲线正朝着相反的方向移动——到达审查环节的代码量在增加，审查者逐行理解这些代码的效率却反而在下降。
一些明显可以观察到的症状包括：拉取请求的体积越来越大，审查延迟不断拉长，在排队的压力下审批质量开始稀释。更关键的一个变化是，审查者不再是在验证行为是否正确，而是在依赖“看起来对不对”的模式匹配。AI 生成的代码长得非常像正确代码：命名规矩，结构合理，错误处理也看上去有板有眼。但真正出问题的，恰恰是那些只有熟悉系统的人才能察觉的地方——一个驻留在另一个服务里的不变量、某张表为什么没建索引的原因、或者在拉取数据之前就必须完成的那次权限校验。
要应对这一状况，有六项实践调整，大致按其付出的努力回报排序。第一项，也是杠杆作用最高的，是对拉取请求的体积设置硬性上限。AI 生成的代码可以毫不费力地堆出超大 PR，但这并没有让审查变得更容易。设定一个硬性的变更行数上限（例如排除锁定文件和自动生成模式后 400 行变更，是个还不错的起点），可以强迫在最方便拆分的阶段就完成拆解。这项约束应当落实在持续集成流水线里，而不是依赖团队文化，因为在截止日期的压力下，任何文化约束都会失效。
第二项，要求在 PR 中注明来源说明，只需一行字段：这段代码主要是 AI 生成的、主要是手写的、还是混合的。听起来像一种流程上的负担，但实际上不是。它改变的，是审查者审视代码的基准。一个熟悉系统的同事所提交的手写代码，默认携带的信任前提，与 AI 生成的代码截然不同。审查者知道自己在审查哪种来源的代码后，就会对两者采取不同的审慎程度。如果没有这个信号，面对两种代码只能套用同一套标准，不管怎么审，方向都可能是错的。同时，这个字段也能产出一套数据，团队六个月后再回头看，就可以在自己的代码库内部去比对来源和缺陷率，而不必再拿着外部的案例来回争论。第三项，要让代码生成与系统上下文更早地绑定，而不是等审查阶段再去发现漏洞。第四项，增加对行为验证的自动化测试投入，用测试把那些“看起来对但系统逻辑错”的隐患挡在前面。第五项，在团队内明确地重新定义“代码理解”的责任——在模型写出代码后，必须有人明确地认领理解的责任，并且不能默认这份责任已经在写作环节完成。第六项，定期回头检查这些措施是否还在起作用，因为生成模型的换代速度很快，今天有效的约束，在模型能力进一步改变后需要重新评估。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
