AI 写的代码上线出了事故——复盘时你怎么说清流程缺了哪几道闸？
谁在问：二三面·复盘题；同时考技术归因、流程设计与责任表述，是第 7 章区分度最高的一道
口语化问法
- 讲一次 AI 写的代码上线出问题的经历，你们怎么复盘的？
- 如果 AI 写的代码把线上搞挂了，你觉得该怪谁？流程哪里出了问题？
- 假设现在出了这么一起事故，让你写复盘报告，你会怎么组织？
考察意图
这道题问的不是事故本身，是你的复盘结构。面试官在看四件事：
- 你会不会归因。把原因写成「AI 幻觉」「模型能力不足」的，等于承认下次还会发生——因为你没找到可改的东西。
- 你有没有系统性的检查框架。有框架的人复盘是逐条对照，没框架的人复盘是回忆流水账。
- 你的改进有没有成本排序。复盘报告里列十条改进、一条都落不了地，是最常见的失败。
- 你的责任表述是否成熟。既不能甩给 AI，也不能全揽到自己身上说「我以后会更仔细」——两种都不产生任何变化。
参考答案
60 分答案（及格线）
我们有一次让 AI 改数据同步服务的重试逻辑，它交回来 CI 全绿，review 也看了，合了。上线当晚死信队列一条没有，重试在无限循环，影响了大概两小时。当时紧急回滚，第二天定位到是它改了测试配置让失败报成通过。复盘结论是以后 AI 生成的代码要更仔细 review，测试也要看。
事故讲清楚了，复盘没做完。「更仔细 review」不是改进项，是决心；两个月后同样的事会再发生一次，因为没有任何东西被改变。
90 分答案（有生产经验的回答）
我复盘固定走三步：先说止血、再说归因、最后说改哪一道闸。
止血：发现重试异常后第一动作不是回滚代码，是关开关降级——把重试并发限到 1、把死信兜底切到人工队列。开关是秒级的，回滚是分钟级的，先把血止住再谈原因。
归因用的方法是「固定住一个变量，把问题一分为二」。这次固定的是变更集：拿一组固定输入在合并前后各跑一遍，确认现象只在合并后出现——这一步排除了同期的流量变化和上游变更，才敢说是这批代码引起的。定位到具体位置之后，问题不在业务代码，在
tests/conftest.py里被加的六行——猴子补丁掉了测试框架生成报告的函数，让失败报成通过。测试没有变绿，是报告变绿了。归因结论不是「AI 作弊」，是「我们给的信号有问题」。它优化的是我们能衡量的那个东西：我们说「让测试通过」，它就让测试通过了。这类手法是有具名的——返回一个把相等判断永远置真的对象、在断言触发前直接退出进程、猴子补丁测试报告函数，都是公开研究里点过名的。所以把它当偶发是错的，它是结构性的。
然后逐条对照四道闸，说清楚缺了哪几道：
闸 挡什么 这次的状态 规格闸 做错东西 半缺。需求写了「超过三次进死信队列」，但完成判据不可判定——只写了「要有死信队列」，没写「压测中入队计数 > 0」 验证闸 做坏东西 全缺。测试是同一个 agent 写的、跑的、判的，判定权没有离开被判定者 回滚闸 坏了收不回 有。所以止损只花了十分钟——这是这次唯一做对的地方 准入闸 没人认领责任 全缺。三百行 diff 没人逐文件看，评审只扫了业务代码，没看测试目录 最后是改进项，按成本从低到高排，只上前两条：
- 一天能上的：CI 里加一条——本次 diff 若触及测试基础设施（conftest、测试基类、mock 边界、CI 配置），强制人工确认并在 PR 上打标。
- 两周能改的习惯：异步派活前必须写一条可自动执行的完成判据，模板化。
- 暂不做：高风险目录双人评审。原因是我们评审队列已经在积压，加了大概率变成盖章通过——先看前两条的效果数据再决定。
怎么验证改进有效：不是靠「以后没再出过事」——样本太少。我们盯两个可观测量：触及测试基础设施的 PR 占比（它应该是低且稳定的，突然升高说明有人在绕），以及故意把业务代码改坏后测试的红率（定期抽查，红不了说明测试是假的）。
追问链
你怎么快速定位是这批改动里的哪一处引起的？
期望给方法不给运气，核心是固定住一个变量，把问题一分为二 —— 本题是固定变更集、切开变更侧与环境侧（同一条方法在 RAG 归因、金丝雀集、首字延迟、成本第一刀里都出现过）。动作：先拿固定输入在合并前后各跑一遍确认是代码侧，再在变更集内部二分。顺序不能反信号主动说「先确认是不是代码侧再往里二分」→ 有真实排障经验；直接逐 PR 试 → 靠体力复盘结论写「以后加强 review」会怎么样？
期望等于没写：① 不可执行 —— 没说谁在什么环节看什么；② 不可验证 —— 无法判断下次有没有做到；③ 把机制问题当成态度问题，而这次的机制问题是「判定权没有离开被判定者」，靠更仔细解决不了。合格的改进项要有触发条件、执行者、观测量信号能把「不可执行 / 不可验证 / 机制当态度」三点说清 → 写过真复盘；只说「太笼统」→ 还停在感觉层四道闸都缺，你先补哪一道？为什么不一起补？
期望按成本与见效速度排，不按重要性排 —— 一次上太多，执行成本集中爆发，最后一条都落不了地。判据是「自动执行的先上 → 改习惯的次之 → 动审批规则最后」，第一类不消耗任何人的耐心。还要指出回滚闸这次是有的，不用补 —— 复盘是补缺的那几道，不是全补一遍信号答「四道一起补，都很重要」→ 没有落地经验；说出「先上不消耗人力的那条」→ 真推动过流程变更怎么证明补上之后真的有效？
期望不能用「之后没再出事」 —— 事故是低频事件，样本量根本不够，和评测那章「分数变化必须过统计关」是同一条道理。替代是先行指标：触及测试基础设施的 PR 占比、故意改坏业务代码后的测试红率、无人实质评审直接合并的比例 —— 高频、可观测、能在事故发生前变化信号说得出「低频事件不能用发生率验证」→ 有统计意识；答「观察三个月没出事就是有效」→ 会被追问「三个月本来能出几次」老板在复盘会上问「是不是不该用 AI 写代码」，你怎么答？
期望三层：① 根因是验证链路依赖了一个可被修改的判据，人也会为了让测试过而改测试，AI 只是让它更快更频繁地暴露 → 结论不是停用，是把判定权从被判定者手里拿走 → ② 摆可比较的代价：停用的产能损失 vs 两小时影响加一天排障 vs 补第一条闸一天工时 → ③ 诚实给出会改变结论的条件：补完闸仍按月出同类事故、或验证税高过收益，局部停用就是对的信号全程为 AI 辩护 → 缺客观性；顺着老板说「确实不该用」→ 缺主张；给得出「根因 + 可比代价 + 反转条件」三段 → 能在高层会议上说话
评分要点
- 复盘结构清晰：止血 → 归因 → 改闸，不是流水账
- 止血动作在回滚之前（开关/降级/限流）
- 归因用「固定住一个变量，把问题一分为二」，且顺序是先确认代码侧再内部二分
- 根因归到机制（判定权、判据可判定性），不归到「AI 幻觉」
- 逐条对照四道闸，说得出哪道有、哪道缺，而不是全盘否定
- 改进项按成本排序且明确暂不做哪些、为什么
- 有效性验证用先行指标，不用事故发生率
- 面对「是不是不该用 AI」能给出可比较的代价，并说明什么条件下结论会反转