合并请求被拦下了。
事情不是审美问题，也不是注释写得不够温柔，而是代码里藏了安全隐患，还有好几处逻辑分支没把边界条件处理干净。单靠那种只看风格的自动检查工具，根本发现不了这些问题，差点就被误导放行了。审查员往下掀开看了几层，才发现两处容易被利用的漏洞，加上三处边界分支没处理好——这些都是在异常流或极端输入下会炸锅的点。起初看着一切“格式良好”，所以差点放过，幸好有人多问了一句，作者才老实交代：这段代码是 AI 生成的，没把所有分支跑一遍就合了。
这事儿不是个例。团队对比了一下，发现人工 review 更偏向查风格、命名、是否符合团队规范。AI 生成的代码表面合格：语法没毛病、结构挺规整，但逻辑漏洞、用到的假数据或没连通的接口，常常被忽视。简短说，就是 AI 很会把“看起来对”的东西吐出来，但不必定能在真实环境里顶得住边界条件和异常场景。为了解决这个问题，大家把检查清单做成了合并请求的模板，凡是 MR 都要自动带上这套检查项，把安全放在最高优先级。
模板里不只是几行提醒，还是具体的把关流程。审查员目前得把注意力从“样子对不对”转到“这段逻辑能不能跑通”。列如，遇到不确定的地方，直接问提交人：你是不是把每个分支都跑过了？写了哪些单元测试？异常会怎么传播？后端如果改返回格式，这条路会不会崩？这些问题把责任挪回给提交者，不让 AI 当最终的背书。团队里有人打趣，说这就像让作者给 AI 的答卷签个字——签了才算数。
具体怎么做，流程也细化了。每次合并前要看测试覆盖率报告，不允许只有“正常路径”的测试通过。要抽查关键用例，模拟异常输入和边界条件，看异常是不是被优雅处理，还是直接往上抛炸掉服务。安全相关改动要额外走流程：至少两位有安全经验的同事按 checklist 再复核一次。遇到怀疑的实现，审查员要直接要求提交者提供复现步骤和本地验证记录，必要时要有本地运行的日志截图或者单测结果。
这套规则的出发点很简单：把 AI 当成草稿工具，而不是最终交付。过去团队引入生成式工具，是为了把重复性活儿交给机器，提速明显，大家都乐得轻松。可等到几次小故障发生之后，才意识到问题真正的来源：AI 对上下文、系统隐性契约的把握不到位。那几次故障大多发生在边界或异常流，排查耗时比人手写的代码还久，弄得大家又爱又怕。
所以目前 MR 里默认带着一套问题清单，提交人必须回答安全影响、失败模式、测试覆盖情况这些“硬问题”。审查员如果有疑虑，会直接把 MR 打回，要求补上单元测试、异常用例，或把关键路径在本地复现并把结果贴上来。模板还提醒：别被美丽的接口描述骗了，AI 有时会一本正经地编造接口或返回格式，表面上合规，实际上根本没连接后端，或者没有处理失败路径。这类问题放任不管，时间一长就是技术债务高筑。
团队里流传一句话，大家也把它写进规约里：审查员不能盲信 AI 生成的内容，除非把每一个逻辑分支都亲自走通。把“LGTM”还原成它该有的意思——不是看着样子可以放行，而是已经理解并验证过逻辑。谁提的改动，就要对改动负责，AI 只是工具，结果得有人担着。有人笑称，这相当于让提交人在 AI 的产物上签个字，签字才算认账。
操作细节上还包含许多务实的小条目。列如，遇到接口调用的代码，审查员会要求提交者列出依赖的上游服务、返回格式的变更风险、以及如果上游返回异常或格式不匹配时的降级策略。对数据库操作，要求列出事务边界、并发场景下的竞态问题、和回滚策略。对外部依赖，要有连接失败的重试策略和熔断限流设计。每一项都不是空话，有问题就要贴出本地的测试截图或 CI 的失败日志，证明不是“我想当然”。
团队还把测试和文档提到了跟代码同样重大的位置。AI 生成的实现常常缺少充分覆盖，或者把测试只写到最容易通过的路径。目前每次合并前，都会看覆盖率报告，重点抽查“异常路径”、“边界输入”和“错误码处理”等用例。安全改动会触发额外的评审流程，做到至少两名有安全经验的人确认通过。
背景上说清楚，大家并不是要把 AI 的便利全盘否定。目标是把责任链补齐，用制度避免未来更多麻烦。工具能提效，但最后的质量关必须有人担着跑通。于是团队制定了默认 MR 模板、明确了问答清单、强化了测试要求，并把安全放在首位。有人会继续乐观使用生成式工具，有人对这类产物持审慎态度，但规则统一下来后，提交和审查的节奏反而更有章法。
在日常里，这些改变看起来像是给流程添了点负担，但也像给团队装了个保险带：别让“看起来对”的东西偷偷把坑埋进代码库。谁提交谁负责，AI 交出的只是草稿，最终那份答卷还是得有人签字背书，签了才算数。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
相关文章
暂无评论...
