考察点
这是 2026 年 AI 编程面试的核心工程题，面试官自己团队就在被这个问题折磨，想听你有没有实战答案而不是「我会认真 review」这种空话。深层考察点是：你理解 AI 产出和人类产出的质量风险结构不同，防护手段也要跟着变。追问常往「测试也是 AI 写的怎么保证测试可信」「review 跟不上产出速度怎么办」走。
参考答案
先想清楚风险结构变了
人类工程师的代码缺陷大多来自疏忽和认知盲区，分布比较随机；AI 代码的缺陷有鲜明的模式：它几乎不写明显跑不通的代码，但会在边界条件、错误处理、并发场景上给出「看起来合理实则错误」的实现；它会引入你没要求的依赖和抽象；它会在长任务后半段偏离开头定的约定。所以质量保障的目标不是泛泛地「多检查」，而是针对这些特定失败模式设卡。
第一道闸：约束前置
最便宜的质量手段是让错误不发生。把项目约定写进 CLAUDE.md / AGENTS.md 这类项目记忆文件：分层结构、禁止引入的库、错误处理规范（比如「不允许裸 catch 吞异常」）、命名风格、必须走的路径（「所有 DB 访问走 repository 层」）。AI 每次会话都会读到这些，比事后 review 纠错有效得多。复杂任务再补一份任务级 spec，把验收标准写成可检查的形式。约束写得越具体，AI 的自由发挥空间越小，质量方差越小。
第二道闸：机器验证兜底
AI 说「完成了」一个字都不能信，信机器：类型检查和 lint 必须先过，编译型语言这层免费；测试要分层——改动模块的单元测试必跑，涉及接口契约的跑集成测试，核心链路改动补一遍 e2e 冒烟。我的习惯是让 AI 自己执行这些并把输出贴出来，工具结果比它的总结可靠。
测试本身也要防 AI 注水：它为了让测试通过，可能写出断言形同虚设的用例（assert result is not None 这种），甚至改实现去迎合测试。所以关键路径的测试用例我会自己写或者逐条审，验收标准里明确「测试必须覆盖这几个边界」。
第三道闸：小步提交，逐段验收
质量失控几乎都是因为步子太大。一次让 AI 改三十个文件，review 必然流于形式——人脑一次性审不了那么多 diff，看着像就放行了。正确节奏是：任务拆小，每个可独立验证的单元一个 commit，diff 控制在几百行内，逐段看完再推进。这样 review 认知负荷可控，出问题 git revert 一步就行。这条看起来是流程问题，实际是质量问题：验收粒度决定缺陷逃逸率。
第四道闸：责任归人
最后也是最重要的：合并按钮在人手里，责任就在人身上。团队里要明确「AI 写的代码出问题，算提交人的」，这条规则会自然逼出前面三道闸——没人敢为自己没读过的代码负责。反过来说，任何「AI 生成、免 review」的绿色通道都是在积累技术债和事故隐患。
落地优先级
如果团队什么都没有，按这个顺序补：先上 CI 静态检查和测试门禁（一天能做），再建项目记忆文件沉淀约定（一周），然后规范小步提交的工作流（靠评审文化，最难），最后把 AI 产出的缺陷单独统计，badcase 反哺约束文件，形成闭环。
可能的追问
- 测试也是 AI 写的，怎么保证测试可信？——验收标准人定：关键路径用例人工写或逐条审；看变异测试或刻意改坏实现看测试是否真的红；警惕「为了绿而绿」的注水断言。
- AI 产出速度远超 review 能力怎么办？——说明任务粒度太粗，回退到更小步提交；同时把 review 重点从逐行正确性（交给测试）转向设计意图、边界处理和安全面，这三处是 AI 缺陷高发区。
- 怎么衡量 AI 代码质量到底行不行？——分开统计 AI 产出的缺陷率、返工率、线上事故归因，和人类产出对比；没有数据时团队对 AI 质量的争论全是立场之争。