Claude Code 团队现在把人留在流程里的位置，缩到了五个决定。
这家团队的产品自己在写自己的代码。按他们 2026 年 10 月 15 日公开的说法，Claude Code 约 90% 的代码由 Claude 写。人要做的事剩下五件：这件事到底要不要做；碰计费、自动更新、CI 流程这类风险代码时怎么办；定下会被别人抄走的架构；读证据；以及为发出去的东西负责。
原文那句表述很干脆，谁打的字不重要，发布的东西有人负责。
五个之外的事，交给七道检查。这套安排跑了一段时间之后，他们给出的数是：6 月到 9 月，合并的改动翻了一倍多，需要回滚的比例反而降了四成以上。
先把这个结果放在这儿，因为它违反所有人的直觉。
人退到最后，只剩五个决定
原文里有一句判断，值得单独拎出来：他们把"人读过这段代码吗"当成一个不精确的代理指标，换成了一个能往下追的问题：这个改动可能出什么错，哪一道检查该拦住它。
代理指标的意思是，它看起来在衡量质量，实际只衡量了一个动作。人读了不等于看懂了，看懂了不等于拦住了。
换成新问题之后，五件事的边界就清楚了。
第一件是方向。要不要做，做到什么范围，什么算好。这是品味问题，机器给不出。
第二件是风险代码。计费、自动更新、CI 流程，这些地方的错不是"改一下再发"，是会直接伤到人或钱的。
第三件是定模式的架构。一个团队里最贵的不是写错一行，是选错一个别人会跟着抄的结构。
第四件是读证据。原文对这一条补了一个判据，是整篇里最能用的一句：如果你说不出这些检查会漏掉什么，就要求一次真正的评审，而不是快速盖章。换句话说，签字的门槛不是"我看过了"，是"我知道它漏什么"。
第五件是拥有结果。原文的说法是 whoever prompted the change is on the hook for it，谁提出这个改动，谁背着它。配套的团队规范叫 you land it, you own it。意思是，你合进去的，出了问题通常你自己修。
这五件事里没有一件是"逐行读完"。原文还有一句更狠的：团队里没有人再在脑子里维护一个完整的 Claude Code 心智模型，而且他们认为没人需要。
想理解某一块代码的时候，他们的做法是让 Claude 针对那一片写一份解释。原文的对比是：改一行文案的 diff 教你几乎为零，你要改的那个模块的解释教你很多。
写下这套流程的三个人里，有一个名字值得单独说。第一作者 Addy Osmani 在谷歌待了 14 年，Chrome DevTools、Lighthouse、Core Web Vitals 都有他的手笔，最后一个职位是 Google Cloud AI 的董事，负责 Gemini 的开发者体验。2026 年 9 月 8 日他宣布离开谷歌，加入 Anthropic 做 Claude Code。
更有意思的是他在 9 月下旬写过一篇《没人读的代码》，把自己两年前"每一行都要读"的主张改了。新说法是：逐行阅读对大多数代码正在消失，阅读原本提供的信任，得改由围绕一个不可信作者的独立检查来提供，而发布的决定仍然归人。
一个人公开推翻自己两年前的规矩，通常意味着他换了位置之后看见了不一样的东西。这篇流程就是他看见之后交的答卷。
第一道关，在评审之前
七道检查里，最该抄的是第一道，因为它在评审之前。
大部分评审现在发生在改动被提交之前。做法很朴素：给 Claude 一个能跑的东西，测试、构建、或者一张能对着比的设计图，然后要它把输出贴出来，而不是说一句"做完了"。之后一个带着全新上下文的子代理去复审这次改动。
团队里很多人还会在提交前跑几个内部技能：一个专门找 bug，一个把改动往简里改，一个把行为从头到尾走一遍。这三个技能全都跑在提交之前，所以它们发现的问题，永远不会变成一条评审意见。
这一层背后是 Boris Cherny 的判断。他创造了 Claude Code，说过给 Claude 一个验证自己工作的方式，可能是拿到好结果最重要的一件事，他估的数是这样能让最终结果好两到三倍。他补了一句：验证在每个领域长得都不一样，可能只是跑一条命令，跑一遍测试，或者在浏览器或手机模拟器里把应用试一遍。
七道关的其余六道，简单过一遍就够，因为它们的形状对内容行业不直接可用：
每个改动都会被 Claude 先看一遍，几个代理同时找问题，另一组独立投票，够多人认为是真的才会发出来，每条都标成重要、小问题、还是本来就存在，而且每一条都必须有回应，要么修，要么带理由关掉。安全评审单独一遍，有未解决的发现就不许合。自动检查拦 lint、类型、各平台测试和构建，提交模板要求填"怎么测的"和"怎么撤"。人工批准按风险分级，低风险在自动检查全绿后不需要人，中等一个，高风险两个。合并队列对着主线重跑全部检查，新行为先挂开关对内部员工开。最后是快速发现和回滚，开关关掉不用重新部署，每周有人值班，事故复盘问的是哪一层本该拦住它。
第五道关有两个细节值得记。风险等级是分类器读改动本身定的，不看作者是谁；而一个代理给出的批准，永远不算人的批准。
同一个改动被审了 50 多轮
这套系统自己会打转。
原文承认了一个案例：一个命令行工具的改动，一夜之间被审了 50 多轮，最后是作者自己叫停的。
跑完之后他们去做了一次归因，对评审者反复挑的那些地方跑 git blame，结果约 59% 是评审者第一轮就已经在的代码。原文的结论是，它很少在找新 bug，只是每轮多找到几个老 bug。
他们也承认这里面有自家的责任：团队习惯了默认多跑几轮，因为每轮都能抓到点新东西。这个习惯在高风险改动上值，但不是每个改动都值。
四条修法都很具体。三轮上限，超过三轮，评审者要求作者退回去重新想方案。头几轮之后只复审新的部分。挑问题的时候标类别而不是标某一行，让作者把所有同类都修了。已经发过的发现不重复发。
还有一条噪音的账，只对代理作者成立，也是全篇最贴内容行业的一句：同一个误报，人两秒就挥掉了；换成代理，它会认真去修，于是多一个提交、多一轮评审。
让 AI 改稿越改越远的人，看到这句大概会点头。它不是在挑刺，它是在执行你的每次反馈，而每执行一次就多一次被审的机会。
两个站不住的地方
这套流程公开之后，Hacker News 上有一轮很不客气的讨论，主帖 428 分、407 条评论。挑两条最硬的。
第一条打的是指标。有人直接说，我每天也能合并三万次改动，三十万次也行，然后写了一段循环，往 README 里追加一行"I am working"，提交，自动合并。另一条更狠：你是在告诉我他们这周上线了十五万个功能，还是把十四万九千九百九十五个自己引入的回归打了地鼠，然后发了五个新东西。
这条质疑打在了要害上：改动数量翻倍，可能是反复修自己弄坏的东西。而回滚率下降这个护栏，在大量改动本身就是修回归的情况下，分母也跟着一起变大了。
第二条打的是安全那道门。我去读了他们用的那个安全评审 GitHub Action 的 README，第 45 行写着这样一句：这个 action 没有针对提示词注入攻击做加固，只应该用来评审可信的 PR，并建议把仓库配置成所有外部贡献者都需要批准。
这里要说准确：不是他们用了一个不安全的工具，是他们自己知道这个限制，并写在了 README 里，而对外讲流程的时候没有把这个前提带到台前。
对比一下另一件事会更清楚。10 月 15 日当天，我写过另一个开源项目 REA，它把"被拆解的目标产生的任何输出都不能升级成指令"写进了四条设计原则里。同一个问题，一边写进设计原则，一边写在 README 的免责段。
两个质疑归成两句：指标可能是虚的；那道最该硬的门，是有前提的。
这不影响这套方法可用，但它决定了你抄的时候该抄哪一层。抄七道关的形状，别抄"回滚率降四成"这个结论。
换成你的活，这五条长什么样
原文是给工程团队的。把它换到内容生产上，几乎每一条都能对上，只是名字不一样。
他们的"改动"，是你的每一版稿、每一张图、每一条片子。他们的"测试和构建"，是你那些能跑的检查：画幅比例对不对、字数够不够、事实核过没有、洗稿比对清没清。他们的"回滚"，是撤稿、改版、下架重发。
五件事也能直接换。
方向与品味换过来是选题和角度，要不要做这条、做到什么程度算好，这一条永远是你的。
风险代码换过来是那几处错了会伤人的地方：价格、合作方名字、产品参数、引用的事实。这些不能靠"AI 说它核过了"。
定模式的架构换过来是你的栏目和文体。一个栏目一旦立住，后面每一篇都会照着它长。
读证据换过来最具体：不是"我看过这版了"，是"我说得出这套检查会漏什么"。说不出，就要一次真正的评审。
拥有结果换过来，是你发出去的每一条。谁写的字不重要，署的是你的名字。
七道关里能直接搬的是第一道。在交付之前，让 agent 自己先跑一遍那些能跑的检查，把输出贴出来，而不是回一句"做好了"。
这一条之所以最值钱，是因为它把返工从"你发现"变成"它自己发现"。生成快了十倍，你看一遍的时间一秒没少，唯一能压缩的就是这一遍之前的那些遍。
还有一条可以直接用：三轮上限。让 AI 改稿，改到第四轮还没收敛，就不是提示词的问题了，是方向的问题，该退回去重新想，而不是继续喂反馈。
最后是五个决定里最容易被忽略的那个判据，值得单独抄下来：如果你说不出这套检查会漏掉什么，就要求一次真正的评审，而不是快速盖章。
盖章很快，代价会在发出去之后出现。
热门跟贴