考察点
这道题出自字节跳动智能体应用开发岗社招面试，紧跟 Vibe Coding 话题。面试官想确认你不是「AI 写完就敢合」的人：有没有建立针对 AI 生成代码的审查纪律，知不知道 AI 代码的典型翻车模式。后半句「是否发生过线上事故」是压力测试，诚实回答并讲清事后改进比硬说「没有」更加分。追问会往具体故障模式、CI 防线、责任界定走。
参考答案
总原则：把 AI 当成手速极快的初级工程师
AI 生成的代码有一个稳定特征：表面质量远高于内在可靠性。命名规范、注释齐全、风格统一，review 时一滑就过去了——但它可能调用了一个不存在的库函数、用了三年前就废弃的 API、把边界条件处理得似是而非。所以审查标准不但不能降，反而要针对它的失败模式加几道专门的关。
四道审查纪律
第一道：小 PR，强制拆分。 AI 一次性生成几百行很正常，但几百行的 PR 没人能认真看完。要求按功能点拆小，单个 PR 控制在一屏能读完的量级。这条是性价比最高的纪律——大部分 AI 代码事故都发生在「太长没人看」的 PR 里。
第二道：作者必须能讲清每一段的逻辑。 Review 时让提交者口述关键分支为什么这么写。讲不清的，说明他自己也没读，直接打回。AI 写的代码合入仓库，责任人就是提交者，「AI 写的」不是免责理由。
第三道：CI 硬门槛前置。 单测覆盖率不低于项目基线、lint 和静态分析全过、依赖安全扫描（AI 爱引入不必要甚至不存在的包，「幻觉依赖」已经是真实的供应链攻击面——攻击者注册 AI 常编造的包名投毒）。这些全部自动化，不占人力。
第四道：重点盯 AI 的典型翻车模式。 人工 review 的注意力要花在机器扫不出来的地方：
- 幻觉 API：函数名、参数签名看着合理但库里根本没有，或者版本对不上。
- 静默吞错：AI 特别喜欢写
try: ... except: pass，异常被吞，故障延迟到下游才爆。 - 边界条件：空列表、超时、并发竞态，AI 默认走 happy path。
- 配置与密钥：把示例密钥、写死的环境值带进代码。
关于事故：诚实讲，重点讲补救
我在项目里真实遇到过：AI 生成的一段缓存刷新逻辑用了它「以为存在」的过期删除接口，测试环境数据量小没暴露，上线后缓存清不干净，旧数据脏读了两小时才发现。复盘后补的不是「以后小心点」，而是三条流程：
- 涉及数据写、缓存、配置的 AI 生成代码必须双人 review；
- CI 加了接口契约测试，调用的外部接口签名和真实服务对齐校验；
- 灰度发布时缓存类变更强制观察期从 10 分钟提到 1 小时。
面试官问事故，想听的就是这个闭环：出了什么、根因是 AI 代码的哪个特性、流程上堵了什么洞。说「没出过」反而显得要么没深度用过 AI，要么不敢复盘。
最后一句话立场
AI Coding 提效是真的，但它移动的是瓶颈不是消除瓶颈——写代码快了，验证和理解代码成了新的瓶颈。审查体系的作用就是把团队的注意力重新分配到瓶颈上。
可能的追问
1. 有没有适合「不 review 直接合」的 AI 代码？
有：纯脚手架（测试数据构造、一次性迁移脚本、内部小工具），前提是影响面隔离、可随时回滚。判断标准是爆炸半径，不是代码来源。
2. 怎么防止 AI 引入幻觉依赖？
锁版本 + 私有源代理，新引入的包必须存在于白名单仓库；CI 对新增依赖做存在性和下载量检查，刚注册几天、下载量个位数的同名包直接拦截。
3. AI 写的测试代码可信吗？
要打折扣：AI 有让测试「配合实现通过」的倾向——断言写得很松甚至测的是 mock 本身。关键路径的测试要求人工确认断言强度，必要时补变异测试（故意改坏实现看测试是否真的会红）。