Anthropic重构代码审查机制：PR合并量翻倍且线上回滚骤降40%

AI 写得比你读得快，code review 要怎么做？ — grapeot

grapeot

AI生成代码必须解耦挑错、对齐与担责，由机器多轮对抗初筛，人类仅凭业务嗅觉交叉核验并承担最终签字责任。

AI-assisted summary of AI 写得比你读得快，code review 要怎么做？ — original source. Check the original for full context.

Source published:

Key ideas

  • 传统 Code Review 包含挑错、对齐上下文与担责三重属性，AI 时代吞吐量暴增使逐行审阅失效，必须将三者剥离并用不同机制分别承接。 (0:00)
  • Anthropic 将代码挑错全面移交机器，采用全新上下文的子 Agent 复查与交叉投票机制，并设定 3 轮审查迭代上限以遏制代码范围无序膨胀。 (5:00)
  • 代码表面合理但破坏隐性业务假设的事故无法靠肉眼 Diff 识别，需依靠跨业务背景的 Cross Check，并逐步将隐性知识文档化为机器可巡检的规则。 (8:00)
  • Anthropic 实行严苛的人类签字铁律与分级审批制度，依托 Scion 工具的极速回滚能力，在 PR 合并量翻倍的同时将线上紧急回滚率降低了 40%。 (11:58)

Detailed notes

## Background 该视频由 grapeot 于 2026 年 10 月 21 日发布在 Bilibili 平台。视频简介指出，AI 极高的代码生成速度让传统逐行 Code Review 陷入两难，作者通过剖析一次会话超时逻辑导致的线上事故与 Anthropic 的内部工程实践，将审代码拆解为挑错、对齐上下文与担责三件事，并给出了工程团队可立即实践的落地建议。

## TL;DR 随着 AI 代码吞吐量呈指数级暴增，传统逐行审查代码不仅效率低下，且极易漏掉深层业务缺陷。本期内容将传统的 Code Review 拆解为挑错、对齐上下文和担责三个维度，提出将挑错交由独立子 Agent 进行 Double Check，将上下文对齐交由人类凭借业务经验进行 Cross Check，并将隐性知识显性化为文档。结合 Anthropic 的分级审批与极速回滚实践，节目最终总结出建立验收标准、拒绝 AI 自审、沉淀嗅觉测试集与保障秒级回滚四项团队立即可落地的行动指南。

## Atmosphere & style 整期视频呈现出资深架构师在白板前复盘推演的从容与理性，语调冷静、克制而又极具洞见。讲解风格深入浅出，善于用管理学中的汇报比喻与真实事故复盘击碎虚幻的直觉，将抽象的软件工程难题转化为高度可执行的系统架构方案。观看过程如同经历一次认知洗礼，既能感受到对 AI 代码洪流冲击工程师职责的紧迫思考，又能在严密的逻辑推导中获得明确的方向感与踏实感。

## Bulletin - [00:00](https://www.bilibili.com/video/BV1mRn66JERc?t=0s) 传统 Code Review 包含挑错、对齐上下文与担责三重属性，AI 时代吞吐量暴增使逐行审阅失效，必须将三者剥离并用不同机制分别承接。 - [05:00](https://www.bilibili.com/video/BV1mRn66JERc?t=300s) Anthropic 将代码挑错全面移交机器，采用全新上下文的子 Agent 复查与交叉投票机制，并设定 3 轮审查迭代上限以遏制代码范围无序膨胀。 - [08:00](https://www.bilibili.com/video/BV1mRn66JERc?t=480s) 代码表面合理但破坏隐性业务假设的事故无法靠肉眼 Diff 识别，需依靠跨业务背景的 Cross Check，并逐步将隐性知识文档化为机器可巡检的规则。 - [11:58](https://www.bilibili.com/video/BV1mRn66JERc?t=718s) Anthropic 实行严苛的人类签字铁律与分级审批制度，依托 Scion 工具的极速回滚能力，在 PR 合并量翻倍的同时将线上紧急回滚率降低了 40%。

## Key takeaways - [00:00](https://www.bilibili.com/video/BV1mRn66JERc?t=0s) AI 编写代码速度远超人类阅读极限，且生成的代码表面工整、Bug 隐蔽，传统逐行肉眼 Review 模式已彻底不可持续。 - [00:00](https://www.bilibili.com/video/BV1mRn66JERc?t=0s) 传统 Code Review 底层混杂了挑错（工程缺陷）、对齐上下文（业务与架构意图）和担责（线上签字扛锅）三件事，AI 时代必须将其解耦治理。 - [05:00](https://www.bilibili.com/video/BV1mRn66JERc?t=300s) 算力边际成本极低使机器 Double Check 成为可能，可通过独立子 Agent 或多 AI 并行赛马比对差异，让人类仅聚焦于核心分歧。 - [05:00](https://www.bilibili.com/video/BV1mRn66JERc?t=300s) 执行机器初审的 Agent 必须拥有全新的独立上下文（Fresh Context Window），避免因先验信息与思维惯性给自身 Bug 找合理化借口。 - [05:00](https://www.bilibili.com/video/BV1mRn66JERc?t=300s) 放任多 Agent 互相挑刺会导致代码范围无限膨胀，必须设立硬性轮次上限（如最多 3 轮），无法收敛时由人类介入重新设计。 - [08:00](https://www.bilibili.com/video/BV1mRn66JERc?t=480s) 仅看当前 PR 代码无法发现与历史变更相关的隐性假设冲突，审查必须从 Double Check 升级为结合上下游与业务嗅觉的 Cross Check。 - [08:00](https://www.bilibili.com/video/BV1mRn66JERc?t=480s) 人类的 Cross Check 经验一旦沉淀为书面文档，便会转化为机器可自动化执行的 Double Check，从而持续外推人类负责的效能边界。 - [11:58](https://www.bilibili.com/video/BV1mRn66JERc?t=718s) 法律与组织责任无法推卸给 AI，Anthropic 规定 Agent 严禁充当 Approver，且人类批准仅与具体 Commit 强绑定。 - [11:58](https://www.bilibili.com/video/BV1mRn66JERc?t=718s) AI 时代的签字含义发生改变：从确认逐行语法正确，转向认可整体业务意图、前置假设与架构设计，并承担上线责任。 - [11:58](https://www.bilibili.com/video/BV1mRn66JERc?t=718s) 应对海量提交需建立代码分级审批机制，低风险变更依托自动化免签直上，中高风险核心路径则要求单人或双人联合签字。 - [11:58](https://www.bilibili.com/video/BV1mRn66JERc?t=718s) 减少人工审核的前提是拥有极速回滚兜底能力，通过定位异常变更快速撤回，方能在高吞吐发布下维持系统 SLA。 - [15:35](https://www.bilibili.com/video/BV1mRn66JERc?t=935s) 普通团队应落地验收先行、禁止 AI 自审、沉淀嗅觉测试用例集以及构建秒级回滚与灰度机制四项实战动作。 - [15:35](https://www.bilibili.com/video/BV1mRn66JERc?t=935s) 人类工程师在系统演进中不可替代的三大底线：事前定义什么是正确、交付时签字担责、持续把隐性业务直觉与规则显性化为文档。

## Detailed walkthrough ### [00:00](https://www.bilibili.com/video/BV1mRn66JERc?t=0s) AI 时代的 Code Review 困境与三大本质拆解

在当下的技术教学和企业咨询过程中，一个被频繁提及的难题是：AI 写代码的速度实在是太快了，团队到底还要不要做、以及怎样去做 Code Review？如果仍然沿用传统的审查方式，让人类工程师一行一行地逐行阅读，开发者很快就会被海量的 Pull Request（PR）彻底淹没，因为 AI 生成代码的速度已经远远超越了人类的阅读极限。更棘手的是这里存在一个悖论：AI 编写的代码在表面上看起来极其工整、质量极高，尤其是当 AI 写完自己再审一遍之后，代码挑不出任何明显的破绽，其潜在的 Bug 往往隐蔽得更深。人类要想对其进行有效制衡，反而需要耗费比以前多得多的时间去深度审阅。面对这种两难，有人提出“干脆彻底不读了，出了问题直接线上回滚”，但这在技术上或许可行，在职场与组织政治上却行不通——因为线上一旦发生故障，最终承担后果、因 Performance Review（绩效考核）被降级而背锅的依然是人类工程师自己。

要破解这个死结，首先必须厘清问题的症结。平时人们常说的“读代码（Code Review）”，实际上在底层同时混杂着三件性质完全不同的事情： 1. **挑错（Bug Finding）**：属于纯技术与工程层面的排错，例如排查空指针（Null Pointer）、逻辑漏洞或未覆盖的极端边界情况（Edge Cases）。 2. **对齐上下文（Context Alignment）**：这并非单纯的工程实现问题，而是业务与产品逻辑问题。用 AI 的语言来说就是“对齐上下文”，例如核验本次代码改动与系统的全局架构是否保持一致，改动能否准确对齐真实的业务诉求。 3. **担责（Accountability）**：在人事与管理层面上“签字画押”，写下“Ship it”，承诺如果上线出了事故由自己来扛。

在过去，人类软件工程师的代码产出速率较低，将这三件事捆绑在单一的 Code Review 环节中运转得十分顺畅。然而在 AI 吞吐量暴增的当下，这三者已经无法继续捆绑在一起。原先开发者的三类核心抱怨与死结，恰恰精准对应着 Code Review 的这三个不同侧面： - **抱怨“读不过来”**：是因为代码吞吐量巨大，依靠肉眼逐行挑错早已超出人类生理极限。 - **抱怨“读了也看不出错误”**：是因为 AI 无法处理的缺陷根本不在当下的 Diff 代码之中，而是深埋在工程师的记忆、团队隐性知识（Tribal Knowledge）或潜移默化的惯例里。 - **抱怨“不读我要背锅”**：是因为代码由 AI 生成，但签字授权与法律/组织责任依然绑定在具体的人身上。

出路绝不是去幻想某种神奇的单一 Review 技巧，而是应该把“挑错”、“核对上下文”和“担责”彻底剥离，用三种截然不同的机制去分别承接。

> “真正的出路应该是把这三件事情拆开，比如讲我找 code 里面的错误，我去核对上下文，我去担责任，因为他们性质不一样，咱就分开处理，用三种不同的机制去保证 ownership。” —— grapeot

```mermaid flowchart TD accTitle: Code Review 三大职责拆解架构图 accDescr: 展示将传统混杂的 Code Review 拆解为挑错、对齐上下文和担责三个不同维度的应对机制。

subgraph Problem["传统 Code Review 混合职责"] T["Code Review"] T --> F["挑错 (Bug / Edge Cases)"] T --> C["对齐上下文 (架构 / 业务意图)"] T --> A["担责 (签字 / 线上扛锅)"] end

subgraph Solution["AI 时代的解耦应对机制"] F --> M1["机器承担: Double Check (子 Agent 独立复查 / 交叉投票)"] C --> M2["人类主导: Cross Check (业务嗅觉 / 隐性知识显性化)"] A --> M3["制度保障: 责任重塑 (分级签字 / 快速回滚体系)"] end ```

---

[05:00](https://www.bilibili.com/video/BV1mRn66JERc?t=300s) 挑错交给机器：Double Check 与 Anthropic 的实践

如果只看“读不过来”这个找错层面的难题，最纯粹的解法其实就是“人类彻底不要去逐行读了”。grapeot 用管理场景打了个比方：当你把工作成果交给 Manager 汇报时，Manager 绝不会把你所有的工作从头到尾重新做一遍；如果 Manager 亲自做一遍（即 Double Check），他立刻就会沦为整个团队的最大瓶颈。人类管理者不能逐行复做，但面对 AI 时，Double Check 却应当成为标准范式——因为调用算力让机器重新跑一遍的边际成本极低，近乎免费。比如在数据报表场景中，完全可以采用“A/B 赛马”机制：让两个独立的 AI 分别计算一遍，再拉入第三个 AI 比对差异，双边结果对齐的部分直接放行，人类只需要过问存在分歧的部分。

近期 Anthropic 团队公开了他们开发 Claude Code 时内部执行 Code Review 的三道工序，其核心理念正是将挑错完全移交给机器做 Double Check： - **第一道工序（提 PR 前的独立复查）**：在提交 PR 之前，系统必须先跑通完整的本地测试，接着立刻唤起一个拥有全新上下文（Fresh Context Window）的子 Agent（Sub-agent）进行独立复查。为什么必须是全新的上下文？这就像企业中财务与审计必须分离、不能自己审自己一样。刚刚写完代码的 Agent，其所有先验信息和推理偏好都充斥在当前的 Context Window 中，在思维惯性下它会不自觉地为自己写出的 Bug 找合理化借口；只有引入一个完全干净的上下文，才能冷酷客观地揪出潜在问题。 - **第二道工序（提交 PR 后的并行审查与投票）**：PR 提交之后，Claude Code 会派发多组 Agent 从架构、安全、规范等不同视角并行扫描找茬，然后再引入一组独立的 Agent 进行交叉投票与二次筛选，把绝大部分假阳性（False Positives）过滤掉，最终仅将极少数确凿存疑的问题递交给人类。

然而，完全把 Double Check 交给 Agent 也会滋生新的次生灾害。使用过 GPT 类工具的人都知道，若放任多个 AI 互相挑刺、互扣极端 Corner Cases，它们很容易不停地编写 Hash 校验或拼命堆砌 Guardrails，导致项目的 Scope（范围）无限膨胀，代码变得极为臃肿且根本无法收敛。针对这一现象，Anthropic 设立了严格的硬性阈值：机器 Code Review 上限最多迭代 3 轮。如果经过 3 轮辩论仍无法收敛，就说明该方案的初始设计本身存在缺陷，系统会强制要求人类作者停下来重新设计。

在这道关口中，人类工程师的角色彻底发生了位移：人不再需要充当人肉代码扫描仪去帮机器找语法和逻辑漏洞，人类的核心职责转变成了“踩刹车”——对 AI 没完没了的 Scope Expansion 果断说“不”，并设计好由机器多轮对抗、初筛代码的过滤机制，人类只对过滤后沉淀下来的关键分歧做决策。

---

[08:00](https://www.bilibili.com/video/BV1mRn66JERc?t=480s) 对齐上下文：从 Double Check 走向 Cross Check

当机器完成了扫描与互相辩论后，代码中可能依然潜藏着致命问题，而这些问题光靠“读代码”是无论如何也看不出来的。grapeot 列举了业内某公司的一起真实线上事故：该团队深度依赖 AI 辅助写代码与做 Code Review，期间合并了一个修改后台“会话超时逻辑（Session Timeout）”的 PR。该 PR 顺利通过了所有的 CI/CD 自动化流水线，AI 审查未报异常，人类工程师看代码表面很合理也顺手点击了 Approve 并完成 Merge。然而上线之后系统立刻发生严重故障：大量企业客户的数据导出 Job 频繁崩溃，后台长时间运行的任务跑到一半全部被强制中断。

事后排查发现，该 PR 的实现逻辑中包含一个隐含假设（Implicit Assumption）——它假设所有后台任务都能在常规计划窗口内执行完毕。但在 6 周之前，产品团队刚刚上线了一个针对头部企业客户的专属定制需求，该需求打破了任务运行周期的常规规律。AI 之所以查不出问题，是因为那项 6 周前的产品改动根本不在当前 PR 的 Git Diff（代码补丁差异）里面。光看眼前的这几行代码，哪怕人类反复精读 100 遍，也绝不可能看出漏洞。

针对这种深水区的问题，依靠 Double Check 毫无意义，团队需要的是 **Cross Check（交叉核验）**。审查者必须跳脱出代码本身的实现，从外部独立的业务与系统视角进行核对： - **业务数字的嗅觉测试（Sniff Test）**：正如经验丰富的 Manager 审视报表时，一线员工觉得数据很顺眼，但 Manager 扫一眼就能立刻凭借直觉反应“这个数字的数量级不对，与历史经验不符”，一眼闻出异样。 - **关联业务背景与上下游动态**：去追溯这个模块近期改动过什么、产品历史上有过哪些特殊规则、上下游服务动了哪里的数据。一旦带入这些宏观背景，就能立刻意识到超时逻辑会击穿大客户的数据导出任务。

AI 无法捕捉到这些问题，本质上是因为人类没有向它输入足够的 Context（上下文），只给了它当下的 Code，而内部产品演进文档、变更日志或历史故障复盘（Postmortem）均未同步给它。但是，想要把这些背景信息喂给 AI，前提是这些资产已经被文字化、文档化。如果信息仅仅作为“Tribal Knowledge（隐性知识）”储存在老员工的脑子里，AI 无论如何也看不见。因此，这不仅是一个纯技术改造，更是一场组织协同制度（Policy）的变革：团队必须在制度上强制要求所有决策全面留档，把逻辑落实在明面文档中，坚决避免将关键决策分散在私密 Slack 消息、非公开 Channel 或缺乏会议纪要的口头沟通里。

把 Double Check 和 Cross Check 放在一起审视，会展现出一个极其深刻的组织演化规律：**人类的 Cross Check 一旦被书面沉淀下来，就会顺理成章地退化为机器的 Double Check。**

> “今天你凭着脑子里的记忆去核对六周前的产品，对吧？这是人的 cross check。但是但凡你把六周前的产品改动写到了文档里面，下次机器巡检的时候，它这么一照着一查，这就变成了机器的 double check。对它来说这是一个确定性的东西。所以其实人负责的那条边界它不是静态的，它是不断的往外推的。” —— grapeot

在真正的 AI Native 组织中，人类负责的边界应当不断外推，人类工程师不再需要固守在原地紧盯细节，而是负责把高维规则与边界写成文档交由 AI 执行，由 AI 去包揽繁重的细节体力活，从而实现组织效能的指数级扩张。

---

[11:58](https://www.bilibili.com/video/BV1mRn66JERc?t=718s) 签字担责与 Anthropic 的三条铁律

然而，无论人类负责的技术边界向外推多远，始终存在一项绝对无法推给 AI 的核心事项，那就是“签字担责（Accountability）”。当生产环境遭遇重大事故、业务瘫痪或需要向客户公开致歉赔偿时，任何组织都绝不可能把一个虚拟的 AI 或 Agent 推出去替罪，事后的复盘事故会（Postmortem）上机器也无法承担扣奖金、降职或法律惩戒的实体后果。

为了在 AI 时代明确责任链路，Anthropic 在“签字上线”这道最终闸门上制定了极其严苛的“三条规矩”： 1. **Agent 绝不允许充当 Code Reviewer 或 Approver**：任何智能体都不得替代人类行使最终的合并批准权。 2. **人类的 Approve 动作仅对当前特定的某一个 Commit 强绑定有效**：只要 AI 随后又提交了包含修改的新 Commit，之前的所有审批自动作废，必须由人类重新审阅核准。 3. **指挥该 Agent 编写代码的当事工程师，其本人必须出现在最终的签字批准名单之中**。

这套机制极其微妙地彻底重塑了“签字（Sign-off）”在现代工程中的定义。过去工程师点击 Approve，代表的是“我已经逐行研读了这几百行代码并确认实现无误”；而在 AI 时代，签字的真实内涵变成了“我已充分核实过本次改动的真实业务意图、背后的前置假设以及架构设计，我认可其方向并且愿意为此承担上线责任”。

Anthropic 近期为了适配 Agent 的极高吞吐量，甚至重写了 Git 并开发了名为 **Scion** 的内部工具。在日常工作中，资深工程师不再去逐行扣细节语法，而是站在全局视角审视：本次改动究竟想干什么？是否符合系统的设计惯例与演进方向？是否存在危险的 Corner Cases？至于代码底层的具体语法实现与逻辑闭环，统统下放给自动化测试体系与高保真仿真环境去兜底。

```mermaid flowchart TD accTitle: Anthropic 代码分级审批与保障流水线 accDescr: 展示低风险、常规业务与核心高危路径的分级签名机制及快速回滚保障。

In["代码变更提交"] --> Risk{"风险等级判定"}

subgraph Tiering["代码分级审批体系"] Risk -->|"低风险 (纯文档 / Feature Flags)"| Low["测试全通 + 作者在可信名单<br/>➜ 零人工签字直接上线"] Risk -->|"中风险 (常规业务逻辑 / 统计词逻辑)"| Mid["单人签字 (1 Approver)"] Risk -->|"高风险 (核心高危路径 / 关键配置)"| High["双人联签 (2 Approvers)"] end

Low --> Infra["底层工程保障 (快速回滚体系)"] Mid --> Infra High --> Infra

subgraph InfraSys["Scion 吞吐与容灾体系"] Infra --> Opt["跳过逐个排队<br/>直接先 Merge 上线"] Opt --> Rollback{"CI / 生产异常?"} Rollback -->|"是"| Bi["利用二维定位<br/>极速自动化精准回滚"] Rollback -->|"否"| Success["平稳运行"] end ```

针对代码吞吐量爆炸的现实（Anthropic 的 Monorepo 巨型代码仓库每天有多达 3 万次代码变更），人的注意力终究是有限的稀缺资源。为此他们引入了精细的**代码分级审批机制**： - **低风险代码**（如纯文档更新、Feature Flag 功能开关等）：只要所有的自动化测试全部绿灯通过，且代码作者处于特定的可信名单内部，便完全免除人工签字，直接全自动上线。 - **常规业务逻辑与中等敏感代码**（如普通的业务数据流转、统计词逻辑修改）：必须由 1 名人类工程师核准签字。 - **核心高危路径与不可逆配置**（如历史故障高发区、核心资产流转、损坏后极难在线恢复的关键配置）：必须由至少 2 名资深人类工程师联合签字确认。

这套分级审查机制之所以能够成立，核心前提在于拥有极其强大的工程系统作为安全网兜底。想要做到减少人工审核，团队必须具备“极速回滚（Rollback）”的能力，确保在线上炸穿的第一时间毫秒级止血，否则严苛的 SLA（服务级别协议）指标根本无法维持。在 Scion 的实际运行中，Anthropic 甚至取消了代码合并前漫长排队等待全套 CI 跑完的机制，而是允许代码直接先行 Merge；一旦后续 CI 或探针报警报错，底层系统能够在二维坐标系中快速定位是哪个具体的变更引入了异常，并在极短时间内将其精准剔除撤回。

通过这三道工序的严密配合，Anthropic 团队在 Claude Code 代码库中实操运转了 4 个月，交出了一份惊人的成绩单：**该 Repo 合并的 PR 总量提升了一倍以上（>100%），然而合入代码后需要线上紧急回滚的事故比例反而骤降了 40%。**

---

[15:35](https://www.bilibili.com/video/BV1mRn66JERc?t=935s) 团队立即可落地的四件事与人类不可替代的底线

结合 Anthropic 的实战策略与 AI Native 团队的演进规律，普通开发团队无需直接自研庞大的类似 Scion 的系统，当下就可以在日常工作中无痛落地四项具体行动：

1. **建立“验收先行”的心智模型（Evaluation-First Mindset）**：在把任何开发任务派发给 AI 之前，人类工程师必须先白纸黑字写清楚验收标准（什么是对的、什么是预期的交付物）。定义“什么是正确”是人类的核心价值所在，AI 永远无法代劳。 2. **禁止写代码的 AI“自己审自己”，必须引入干净上下文或赛马机制**：严禁让刚生成完代码的同一个上下文去负责 Review。要么唤起一个拥有全新独立 Context 的 Sub-agent / 新 Job 进行双重检查，要么派发给两个不同的 AI 独立计算进行 A/B 赛马核验。 3. **刻意构建个人与团队的“嗅觉测试用例集（Sniff Test Set）”**：针对自己日常负责的高频业务领域，主动总结模式认知。比如审阅数据报表时优先比对哪两张基表口径、面对特定逻辑注入何种极端反直觉的输入能快速验证边界，把直觉转化为可复用的探测习惯。 4. **梳理交付流水线，确保具备极速回滚能力**：全面体检现有的 CI/CD 与部署发布机制（包括代码与配置文件），确保出事时具备秒级回滚的能力。交付非代码类产物（如核心报表）时同样遵循渐进式策略：先灰度暴露给小范围用户核验反馈，有了确定性的容错垫底后，再逐步降低对传统“逐行阅读代码”的依赖。

只要在组织内部践行这一套循环，人类负责的系统边界就会不断自然地向外推进：每一次通过 Cross Check 排查出的隐性经验，只要被文档化、结构化沉淀下来，下一次就会立即无缝转化为机器执行的 Double Check 巡检规则。

> “不管这个边界推得有多远，有三样东西始终是必须要由人来负责的，也就是第一：动手之前搞清楚什么叫正确；第二：交付的时候签上我们的名字背锅；第三是：如果还有哪些比如说规则、直觉还没写下来的，我们要把它写下来。” —— grapeot

- **任务派发前**：建立 Evaluation-First 机制，定义正确的判定标准； - **任务交付时**：坚守最终防线，由人类 Approver 承担系统责任并签字担责； - **认知沉淀时**：主动把深埋在脑海中的直觉、隐性规则与业务约束显性化为文档，持续喂养给智能体系统，以此驱动组织效能的持续进化。

## Notable quotes > [15:35](https://www.bilibili.com/video/BV1mRn66JERc?t=935s) 有三样东西始终是必须要由人来负责的，也就是第一：动手之前搞清楚什么叫正确；第二：交付的时候签上我们的名字背锅；第三是：如果还有哪些比如说规则、直觉还没写下来的，我们要把它写下来。 — grapeot

> [00:00](https://www.bilibili.com/video/BV1mRn66JERc?t=0s) 真正的出路应该是把这三件事情拆开，比如讲我找 code 里面的错误，我去核对上下文，我去担责任，因为他们性质不一样，咱就分开处理，用三种不同的机制去保证 ownership。 — grapeot

## Mentioned grapeot, Anthropic, Claude Code, Scion, Git, Superlinear Academy

## 弹幕氛围 (Danmaku mood) — 51 条 观众整体氛围偏向理性和深度讨论，兼具少量调侃与争议。大家主要就 AI 辅助编程、Code Review、Token 消耗及上下文窗口限制等技术细节展开了专业交流与实操质疑；同时对 UP 主夹杂英文的说话习惯产生了短暂争论，开场也有对主播外貌耳机的趣味吐槽。

**整体情绪**：😊 正面 15% · 😐 中性 60% · 😞 负面 25%

**热议点** - **用 AI 替代人工进行 Code Review 的探讨与调侃** —— “懂了deepseek写完，豆包审查” - **吐槽 Token 成本爆炸与多 Agent 模式的消耗** —— “token 大爆炸” - **关于说话夹杂英文单词的争论与辩护** —— “为啥要总掺杂说英文单词？” - **深入探讨 AI 编程的上下文窗口、记忆与工程经验缺陷** —— “工程直觉，coding agent最缺的东西” - **对 UP 主造型或视频形式的外貌调侃与建议** —— “这耳机好搞笑哈哈哈”

**代表弹幕** > 这耳机好搞笑哈哈哈

> 懂了deepseek写完，豆包审查

> token滞销，帮帮我们

> 为啥要总掺杂说英文单词？

> 因为你文化水平不足以支持你听懂他说话

> 工程直觉，coding agent最缺的东西

> 可以用记忆模块，类似RAG，不只是简单的压缩。

> 就得把ai推出来，让ai去道歉

## Video description AI 写代码的速度太快，很多团队在 code review 上陷入了两难。一行一行读会被 PR 淹没，何况 AI 写的代码表面工整，问题反而更隐蔽，读了也看不出来。有人说那就不读，出事回滚，技术上可以，但出了事背锅的还是人。

平时说的读代码，其实同时混着三件事：挑错、对齐上下文、担责。以前代码产量小，捆在一起没问题，现在 AI 写得太快，捆不住了。这期视频从一次线上事故聊起，起因是一个改后台会话超时逻辑的 PR，再结合 Anthropic 团队公开的做法，把三件事拆开讲：挑错交给机器做 double check，比如用全新上下文的子 agent 独立复查；对齐上下文光看代码看不出来，得靠 cross check 从和代码无关的角度核对，比如凭经验一眼看出数量级不对，或者对照产品历史和上下游最近改过什么；至于担责，在 PR 上点 approve 就是签字，签字的含义和规矩也得跟着改。最后还会聊聊马上能做的四件事。另外，这期视频大量用了 AI 生成，算是一次实验。我也想听听大家看下来的感受，比如看着有没有 AI 味、自然不自然，看这类视频会不会觉得不舒服。

Superlinear Academy 社区：https://www.superlinear.academy/?utm_source=bilibili&amp;utm_medium=video_desc&amp;utm_campaign=ai-code-review

[Source](https://www.bilibili.com/video/BV1mRn66JERc)

中文简报

Anthropic重构代码审查机制：PR合并量翻倍且线上回滚骤降40% AI生成代码必须解耦挑错、对齐与担责，由机器多轮对抗初筛，人类仅凭业务嗅觉交叉核验并承担最终签字责任。 随着 AI 代码吞吐量呈指数级暴增，传统逐行审查代码不仅效率低下，且极易漏掉深层业务缺陷。本期内容将传统的 Code Review 拆解为挑错、对齐上下文和担责三个维度，提出将挑错交由独立子 Agent 进行 Double Check，将上下文对齐交由人类凭借业务经验进行 Cross Check，并将隐性知识显性化为文档。结合 Anthropic 的分级审批与极速回滚实践，节目最终总结出建立验收标准、拒绝 AI 自审、沉淀嗅觉测试集与保障秒级回滚四项团队立即可落地的行动指南。 传统 Code Review 包含挑错、对齐上下文与担责三重属性，AI 时代吞吐量暴增使逐行审阅失效，必须将三者剥离并用不同机制分别承接。 (0:00) Anthropic 将代码挑错全面移交机器，采用全新上下文的子 Agent 复查与交叉投票机制，并设定 3 轮审查迭代上限以遏制代码范围无序膨胀。 (5:00) 代码表面合理但破坏隐性业务假设的事故无法靠肉眼 Diff 识别，需依靠跨业务背景的 Cross Check，并逐步将隐性知识文档化为机器可巡检的规则。 (8:00) Anthropic 实行严苛的人类签字铁律与分级审批制度，依托 Scion 工具的极速回滚能力，在 PR 合并量翻倍的同时将线上紧急回滚率降低了 40%。 (11:58)

Reading summary

grapeot 指出，面对 AI 生成代码吞吐量的暴增，传统将挑错、对齐上下文与签字担责捆绑的人工 Code Review 机制已难以为继。破解困局的核心在于将三者解耦：通过机器 Double Check 消化语法与逻辑挑错，由人类凭借业务隐性知识进行 Cross Check，并依托分级签字与快速回滚制度兜底责任。 Code Review 的三大本质解耦 (0:00) AI 编写代码速度远超人类阅读极限，且生成的代码表面工整、隐蔽缺陷深，依赖人类逐行肉眼审阅必然导致 PR 堆积。与此同时，若完全放弃审查直接上线，事故发生后的绩效责任与人事风险依旧由人类承担。grapeot 分析认为，传统的审查在底层混杂了三项不同维度的职责：技术层面的挑错（Bug 与边界条件）、业务与架构层面的上下文对齐，以及管理与人事层面的签字担责。以往低吞吐时代三者可以捆绑进行，但在 AI 时代，必须通过不同的机制将其分别承接以重塑工作流。 挑错下放机器与 Double Check 机制 (5:00) 针对“读不过来”的代码挑错环节，人类应停止逐行肉眼排查，转而利用极低边际成本的算力进行 Double Check。例如在数据报表场景中利用两个独立的 AI 互相计算、第三个比对分歧的 A/B 赛马模式；或者参考 Anthropic 开发 Claude Code 时的实践：在提交 PR 前强制调起具有纯净上下文（Fresh Context Window）的子 Agent 进行客观审计，提交后由多组 Agent 并行扫描与投票过滤假阳性。为避免多 Agent 互相辩论导致代码 Scope 无限膨胀，Anthropic 设置了最多迭代 3 轮的硬性阈值，人类工程师的角色因而转变为规则设计与关键时刻“踩刹车”。 业务上下文核验与隐性知识显性化 (8:00) 许多严重事故往往源于当前代码 Diff 之外的隐性假设。例如某团队合并修改会话超时逻辑的 PR 时顺利通过自动化测试与常规审查，上线后却导致长任务中断崩溃，原因是代码未能兼顾 6 周前针对大客户定制的需求。针对此类超出代码界面的问题，必须由人类进行 Cross Check，依靠对业务数据的嗅觉测试与全局演进背景进行交叉核验。此类缺陷本质上源于 AI 缺乏未文档化的组织隐性知识（Tribal Knowledge）。一旦团队通过制度将决策与业务逻辑全面文档化，原本依赖人类直觉的 Cross Check 即可顺理成章地沉淀为机器可执行的 Double Check 规则，动态扩展组织效能边界。 重塑签字担责与工程兜底系统 (11:58) 无论技术边界如何扩展，线上事故的组织与法律责任绝无法由 AI 代替。Anthropic 建立了严苛的签字铁律：严禁 Agent 充当 Approver、审批与单次 Commit 强绑定、且调度 Agent 的当事工程师必须亲自签字。同时，团队引入了代码分级审批体系：低风险代码在测试全通且作者在可信名单内时可零人工签字自动上线，常规业务需 1 人签字，核心高危路径则需 2 人联合签署。该分级机制依赖极速回滚能力兜底，Anthropic 通过内部工具 Scion 实现先行 Merge 与二维定位快速剔除，在 Monorepo 日均 3 万次变更的体量下，达成 PR 合并量翻倍、回滚事故率下降 40% 的效果。 团队落地该模式需践行四项举措：任务前建立“验收先行”（Evaluation-First）标准、禁止 AI 自审并引入干净上下文或赛马机制、建立高频业务的嗅觉测试用例集，以及梳理极速回滚与容错流水线。无论技术演进多远，人类始终需坚守三道底线：事前定义何为正确、事后签字承担责任，以及持续将业务规则与直觉转化为书面文档。

Source quotes

[15:35] grapeot: 有三样东西始终是必须要由人来负责的，也就是第一：动手之前搞清楚什么叫正确；第二：交付的时候签上我们的名字背锅；第三是：如果还有哪些比如说规则、直觉还没写下来的，我们要把它写下来。 [0:00] grapeot: 真正的出路应该是把这三件事情拆开，比如讲我找 code 里面的错误，我去核对上下文，我去担责任，因为他们性质不一样，咱就分开处理，用三种不同的机制去保证 ownership。

Original transcript

[0:00] 我们在教学和跟企业咨询的过程中间经常被问到一个问题就是说AI写代码实在是太快了那我们到底要不要或者说怎么去做code review这个问题其实蛮常见的一般大家会觉得如果还照传统的方法我们就一行一行看那很快就会被PR淹没因为它写的真的是太快了比我读代码的速度还快而且这里面有一个悖论就是说AI写的代码其实至少从表面上来看它是特别工整特别高质量的尤其是要是他自己写完之后再审一遍更难看出问题所以如果希望人对他进行有效的克制与恶化是需要我们花更多的时间去看的但是很显然他写的又那么快他的bug又更隐蔽了这是一个非常两难的问题有人问那我干脆不读了行不行我大不了回滚但是呢从技术上来说这是一个正确的东西但从政治上来说这个不太正确因为除了事还得我背锅啊我performance review因为这件事情给降低了那背锅的还是我呀然后所以这件事情到底要怎么分析呢我就在想其实要想找到一个解决方法首先第一步得先搞清楚问题的真结到底在哪里当我们说读代码code的时候其实我们在干三件不一样的事情第一件事情是挑错比如说这有个控制针这有个bug这个edge case你没考虑到然后第二个其实它不是一个技术或者说工程问题而是一个产品问题就从如果你用AI的语言来说叫做对齐上下文比如说我们看它改动跟我们全局的架构是不是一样它跟我们业务的需求能不能对得上然后第三个是真的单则就是我把我名字签在这里我说ship it出了事我来扛以前大家说code review其实指的是同时做这三件事情因为代码它产量小所以其实没什么问题但现在你看AI写代码那么快就没办法再捆在一起了所以我觉得问题的关键是你得先想清楚code review到底是干什么的在这个基础上把它拆开来看指责或者说侧面用不同的解法他可能就可以work了这时候你再回头看刚才的那三种抱怨或者说死结其实正好就对应着Code Reveal的三个侧面你看你觉得读不过来是因为现在这个吞吐量实在是太大了你靠人眼一行一行找错已经找不过来了然后你觉得读了又看不出来错是因为真正AI搞不定的那部分那部分根本就不在这个代码里面你需要去穷尽你的记忆Triple Knowledge甚至组里的一些潜移默化的一些规则才知道而你觉得不读我要背锅是因为代码虽然是归AI写了但是签字单责任这件事情还是人事上的所以呢那既然这本来就是三方面不同的事情那它的解决方法就不应该是幻想特别牛逼的扣除于右的方式一下把三件事情都解决了还跟原来一样真正的出路应该是把这三件事情拆开比如讲我找code里面的错误我去核对上下文我去担责任因为他们性质不一样咱就分开处理用三种不同的机制去保证ownership我们先看第一件事如果我读不过来怎么办如果只看这一个任务的话其实不要读了那就是正确的解决方法我经常跟人打一个比方是你想想看你把你的工作交给你的manager的时候你的manager会从头到尾把你的活重新做一遍吗不会的因为他把你重新做一遍本质上这个是double check但凡他这么干他就会迅速成为整个team的瓶颈但是呢虽然这件事情对人来说不能这么干但到AI手里面其实他就应该double check因为你让机器重新做一遍基本上是免费的所以呢既然特别便宜我们就应该把这件事情交给机器比如说AB赛马对吧你做一个报表你完全可以让两个AI各自算一遍然后呢派第三个AI去找有没有差异啊那基本上两面都对得上的你就基本上可以放心你就只要管那些对不上的地方就可以那具体的说放到写代码上面呢就是Anthopic最近刚发一篇文章讲做Clock Code的团队最近公开了他们内部是怎么 [5:00] 做code review的一共分三道工序其中的第一道工序呢就是在提PR之前先跑完一个本地测试然后再去用一个全新的上下文的子agent做独立复查也就是double check这里有一点需要注意就为什么要用全新的上下文这是因为有点像是你财务和审计要分开你不能自己审自己一样刚写完的代码的agent它所有的信息全都在context window里面它思维上有一种惯性它就很容易给自己写的bug找理由这时候你就要换另外一个干净的context window来看才能把问题给找到我们交了皮以后Clock Code还有另一道工序是说我让多组agent从不同的视角并行找问题然后找出来问题之后再拉一组agent去交叉投票再筛选最后就只把那些真的有问题的东西留下来让人来管不过你把double check这件事情交给agent其实也有一个问题就是大家如果用过GBT的话会知道他互相挑刺到最后各种edge case他就写hash去搞guardreal就根本就收敛不了他会把一个很小的project不停的加scope停不下来所以SRB一个解决方法是专门给机器code review设了一个上限就最多改三轮如果改了三轮还不收敛那就说明设计有问题你就要把PR让它的作者停下来重新设计所以在这一关里面人的角色就不是说盯着代码去帮机器找错了人的一大职责其实踩刹车我们能让机器做的就让机器做哪怕特别复杂臃肿你让机器做好几轮让机器互相debate都没问题但是人的核心职责是第一踩刹车对AI没完没了的那种scope expansion说不然后第二个是去设计这样一个mechanism让机器先把代码筛过好几遍漏下来的问题我们再去做决策上面讲的是第一个code review的第一个角色那现在这个第二个角色呢是有时候啊机器做完debate做完扫描之后还留下了一些问题这些问题啊你光看代码还是看不出来比如说之前有另外一个公司报告了一个事故啊就是说他们依赖AI去做code review写代码然后呢merge了一个修改后台绘画超时逻辑的一个PL这个东西其实当时也过了CICD然后AI也没看出来问题人也没看出来问题当时就Approve Merge了然后Merge上线以后大家就发现企业客户数据导出很多job都挂了他那些尤其是后台的任务跑着跑着就中断了所以他就去查查了之后发现是这个代码它有一个紧盘的假设它假设是所有的后台任务都在一个常规计划里面跑完但是呢他们上线了一个针对企业客户的特殊定制所以他就把这个影团的假设给break了而且为什么AI当时没有发现这点是因为六周前的产品改动它不在这个PR的DIF里面所以AI光看这个PR的code你哪怕把代码读上100遍你也读不出来这个漏洞所以对于这种情况我们需要的就不是double check你double check是check不出来的你需要的是cross check你写代码的人要从一个跟代码没有关系的独立的角度去核对我举几个例子大家如果跟manager合作的话经常会遇到这样的情况第一种是你可能看业务的数字你觉得看得挺顺眼的但是manager一看觉得不对这里这个数字数量级不对跟我的经验不一样所以这个就是我们叫sniff test就凭着你的嗅觉就能闻出来这里不对然后或者还有一种是要结合业务背景是什么他最近改过什么上下文上下游动过哪里看到这里尤其是像刚才那个例子你就会知道这里不太对里头肯定有问题所以我们回头看刚才那个事故就是AI他们没有抓出问题这是因为他们有足够多的context你只给了他这次的code他不知道之前的内部文档或者是产品更根记录或者是历史故障复盘这些都没有所以他看不出来但如果你把这些context都给他有可能发现这个问题的但是呢要把这些东西给AI的前提是这些东西得是一个document的如果它是一个trible [10:00] 你记在人脑子里面的话AI会不会读清所以他还是看不见对吧所以这个不仅是一个技术问题而且是一个组织问题比如我们就需要在构建组织政策policy的时候去要求把所有的决定都要留档要留成文字写在明面上不要去把这些决策藏在slack message这种私信不是channel里面或者是没有记录的会议里面就一旦这些东西AI看不见那它就会出错所以你把这两件事情放在一起看就是double check跟cross check就会发现一个规律就是人一个很有意思的地方是人的cross check他一旦写下来他就会变成机器的Double Check你看今天你凭着脑子里的记忆去核对六周前的产品对吧这是人的cross track但是但凡你把六周前的产品改动写到了文档里面下次机器巡检的时候它这么一照着一查这就变成了机器的double check对它来说这是一个确定性的东西所以其实人负责的那条边界它不是静态的它是不断的往外推的你的团队你的AI native org不断的把东西写下来人负责的边界就会不断外推你就可以把越来越多的东西交给AI换言之这种情况下人就不用在原地盯细节了你只要把细节写给AIAI就能帮你盯细节体力活就他来干这条边界你就可以一直往外推组织的效率也可以越来越高那有没有什么东西是你怎么推都推不走的呢其实也是有的就是前面说的第三件事你把签字来背锅为什么这件事情推不走呢是因为出了事啊你总是得有人来对业务啊对客户负责你拿去道歉的时候你不能把AI推出去对吧你不论是机器还是agent也没办法在事后的postmodem上面说我来赔钱或者我来降值扣钱对吧所以Anthropic在这道关口啊就是签字上线这道关口定了三条规矩第一条呢就是agent他不算code you or approver你都不能代替人类来签字第二个是人的批准人的Approve这个动作只对那一个特定的Commit有效只要AI提交了另一个Commit他就必须要重新再看第三是指挥agent的写代码的那个人他自己必须在签字的名单上面这个设计有意思的地方在他其实非常微妙的把签字的含义给变了以前我签字代表彻底研读过这几百行代码我觉得没有毛病但是现在我们签字其实表示我核实过这次代码改动的意图改动的假设改动的设计我都核对过了没有问题上线吧其实Anthorpec他最近不是把Git给重写成了Scian吗是给Agent用的一个High throughput Git不会主行去读AI写的实现而是从更高层的角度看这个改动想要干什么它从设计上面符不符合我们的惯例它会不会碰到一些奇怪的conner case主要是核对这些意图至于底层对不对implementation对不对这些东西你去交给测试交给仿真去做那不是人干的事情而且如果我们真的去把这套东西给它scale up的话又会遇到另一个问题人的注意力毕竟有限现在AI比如Anthropic它的大仓库它的Monorepo每天会有三万个变更你人再高也看不过来所以它又做了一个分级就是说像纯文档或者是功能开关这样的低风险的代码你只要是测试全过而且作者是一个特定的可信名单里面的人就不用签字了直接上线如果是常规业务逻辑统齐式词像这种比较敏感的地方就要一个人签字如果是核心高危路径经常挂的或者是关键配置很难恢复的就必须要两个人签字在这个技术上它不仅在机制上面设置了机制它同时还有一个工程系统来支持比如说你至少得能快速回滚你才能讲我少省一些代码要真挂了你得很快把代码回滚恢复损失不然你的SLAAnthorberg在这里在Science特定的例子上面他甚至不让每一个CI排队等CI跑完而是先mergemerge完了他要是挂了他再用二维 [15:00] 再找到这个改动再撤回他呢把这三道工序跑了四个月发现Cloud Code这一个特定的report合的PR多了一倍还不止但是呢合进去以后需要回滚的这个比例反而降了40%所以如果我们去用Anthropic这个团队去看怎么样去做code review怎么样去构建AI Native Organization的话其实有几个经验我觉得特别有意思我们其实马上就能用我们其实并不是说你立马就要用Science其实它也没开源了或者自己搭一套非常大的系统而是有四件事情立刻就能做第一件事情是你把一个活派给AI之前我们要先把验收标准写下来我管它叫evaluation first mindset你得先自己想清楚什么叫做对了这个是我们的核心价值AI没办法代替然后第二件事情就是你不要让刚写完code的AI自己审查自己而是应该让他新开一个fresh context的either subagent or新的job或者你让两个AI赛马各自算一遍看能不能对得上第三个呢就是我们要有意识的去构建自己的sniff test set尤其是你经常干的活啊你就故意想一想这个东西看着对不对那个东西常见的pattern是哪些比如说你看报表的时候你主要看哪两张表口径对不对啊你看代码的时候你可以故意买一个什么样的输入去看它会不会挂第四件事情呢是检查我们的CICD这种交付流程不管是代码还是配置要首先保证出了问题能快速回轨报表其实也是一样的你要先给小范围的人看然后让大家能够发现了什么问题能够迅速改正有了这个系统兜底以后我们再逐渐去减少逐行阅读这种code review如果你真的这么做起来以后你就发现人负责的边界一直在往外推因为只要你把一次这种上下文这种核对的经验写下来下一次机器立马就能用上但是不管这个边界推得有多远有三样东西始终是必须要由人来负责的也就是第一动手之前搞清楚什么叫正确第二交付的时候签上我们的名字背锅第三是如果还有哪些比如说规则直觉还没写下来的我们要把它写下来