前天我写了一篇文章，说 AI 让每个人都变快了，但组织没有变快——个人效率的红利，被交接、等待、审批这些组织摩擦吞掉了。
两天后，Anthropic 发了一份长文：The AI-Native SDLC playbook。第一句话是：
「Organizations have started using AI to write code at a speed unthinkable one year ago, yet the processes around the code haven’t changed at the same pace.」
各组织已经开始用 AI 以一年前无法想象的速度编写代码，但围绕代码的流程并没有以同样的速度改变。
翻译成我们前天讨论的语言：代码产出快了，围绕代码的组织流程没变。一家造出世界上最锋利锤子的大厂，公开承认墙不在锤子上。
这份手册值得每个关心组织效率的人认真读一遍。这篇文章不是翻译，是我读完之后的一份解读笔记：它印证了什么、它给出的工程答案是什么、以及它没覆盖的地方在哪里。
一、Anthropic 的三个承认
手册开篇讲了一个传统软件开发生命周期（SDLC）的基本事实：规划、设计、构建、测试、部署、维护，六个阶段，每个阶段由不同角色负责，工作通过文档、工单和签核在阶段之间流转。
然后说了三句我认为分量很重的话。
第一个承认：瓶颈转移了。
「Build is no longer the constraint — the human-speed steps around it are. Human-speed stages keep their length while build collapses to hours.」
构建不再是约束——围绕它的人类速度步骤才是。人类速度的阶段保持着原来的长度，而构建塌缩到以小时计。
这就是我前天说的「阿姆达尔定律」：系统整体速度取决于最慢的环节。AI 把构建环节压到以小时计，但计划、评审、部署还在以人类速度运行——瓶颈自然就转移到了构建的左右两侧。
第二个承认：控制措施和现实脱节了。
手册里有一个安全团队的例子：安全团队的编制是按人类产出配置的，当 agent 成倍放大代码产出时，要么评审队列堆积，要么代码在评审不足的情况下上线——受监管的组织两种结果都不能接受。
这个例子我在前天的文章里有一个对应物：Faros 的数据显示，AI 采用度高的团队 PR 评审等待时间增加了 91%。两边看到的是同一个现象：上游提速之后，下游的人类关卡成了堰塞湖。
第三个承认：治理成本在上升。
「Governance costs increase because exceptions still route through meetings and committees that meet weekly or monthly.」
治理成本上升，因为例外情况仍然要流经每周或每月才开一次的会议和委员会。
这一条最容易被忽略，但可能最贵。代码一天能改十次，但「改错了怎么办、谁能批、怎么追责」这套治理机制还是按月开会的节奏。频率错配越拉越大，治理要么变成瓶颈，要么变成摆设。
三个承认合起来就是一句话：传统流程是为「写代码最贵的时代」设计的，那个时代结束了，但流程还在原地。
二、工程答案：工件链
承认了问题，手册给出的答案是什么？不是更快的模型，也不是更多的工具，而是一个流程重构方案。核心机制我叫它 工件链（committed artifact chain）。
手册里有一段话是这个机制的完整定义：
贯穿整个方案的主线是 已提交的工件。每个阶段都以向版本控制写入一个工件结束（包括 intent.md、spec.md、plan.md、diff 及其测试、带评审发现的 PR、事故记录），下一阶段从读取它开始。
把六个阶段串起来看：
| 阶段 | 提交的工件 | 下游动作 |
|---|---|---|
| Plan（计划） | intent.md——用提出者自己的话写的需求 | 触发需求与设计 |
| Design（设计） | spec.md——与 agent 同会话产出的规格 | 触发 plan mode |
| Build（构建） | plan.md + diff + 测试 | 合并后触发流水线 |
| Test（测试） | 贯穿实现过程的持续 evals | 守住质量带 |
| Deploy（部署） | 多层 agent 评审后的 PR + 评审发现 | 人类评审留给关键代码 |
| Maintain（维护） | 事故记录 | 写回新的 intent.md，闭环 |
注意最后一行：生产环境里被突破的控制带，会被诊断并写成新的 intent.md 回到流程起点。流程不是线性的，是一个环。
这个设计妙在哪里？我认为妙在三个地方：
第一，交接摩擦被结构性消灭了。 我在前天的文章里说，交接摩擦的本质是「上下文在每次交接时重新装一次」。工件链的做法是：上下文不再装进人的脑子里传递，而是写进版本化的文件里。下一个环节（不管是人还是 agent）从读取文件开始，不需要开对齐会，不需要写交接文档。
第二，审计轨迹是免费的。 手册里说得很直白：提交链本身就是审计轨迹——谁要求了什么、agent 产出了什么、谁批准了它。我在 企业级 AI 必须设计成出错后可以追责到人 里讲过追责需要授权链和审计日志；工件链把这些东西变成了流程的自然产物，而不是额外负担。
第三，人的位置变了，但没有消失。 手册里有一句话我印象很深：「人的注意力随着需要评审的工件而转移。」人不再从零启动每个阶段，而是站在关卡上——评审 agent 标记出来的东西。这和 Agent Spec 是数字员工的劳动合同 里的判断是同一个方向：人管的是契约和验收，不是执行。
三、对照：手册的六个阶段，摩擦的四种类型
把这份手册和我前天拆的四种组织摩擦放在一起看，对应关系很清楚：
| 组织摩擦（#361） | 手册里的对应打法 | 消灭机制 |
|---|---|---|
| 交接摩擦 | intent.md → spec.md → plan.md 工件链 | 上下文写进文件，不再随人传递 |
| 等待摩擦 | hooks 作为构建时护栏、多层 agent 评审 | 检查在 agent 行动时强制执行，不等评审周期 |
| 搬运摩擦 | 需求与设计压缩进同一个工作会话 | 阶段边界被合并，信息不用跨系统搬运 |
| 决策摩擦 | 人类评审只留给受监管和关键代码 | 人的判断力集中花在最高价值的地方 |
最值得注意的是「等待摩擦」那一行。手册里讲 hooks（钩子）：不是代码写完再送去评审，而是 治理在 AI 行动的那一刻就被强制执行——agent 要执行生产部署，钩子先检查授权；不合规的动作在发生时就被拦下，而不是进入一个排队等待的评审队列。
这是对「等待」最彻底的解法：把检查从流程的下游挪到动作的现场。 排队之所以存在，是因为检查是集中式、批处理式的；当检查变成内联的、实时的，队列本身就消失了。
四、手册的边界：它重接了 SDLC，那 SDLC 之外呢
这份手册让我兴奋，也让我警觉。警觉的地方在于它的边界：它覆盖的全部是软件开发流程。
规划、设计、构建、测试、部署、维护——这六个阶段是一个软件团队的生命周期。但一个组织里还有大量流程不在 SDLC 之内：
- 客户投诉从进线到解决，要经过客服、工单、产品、研发
- 一笔采购从申请到付款，要经过需求方、审批链、财务、供应商
- 一个决策从提出到落地，要经过信息收集、会议、签核、执行追踪
这些流程里的摩擦——交接、等待、搬运、决策——比 SDLC 里的只多不少，而且完全没有 agent 化的基础设施：没有 git 可以提交工件，没有 hooks 可以内联治理，没有 evals 可以持续验证。
这恰好是钉钉数字员工的位置。
我在 数字员工的第一准则不是可控性 里推导过：数字员工要进入组织流程，前提是它的行为能挂上问责链。对照这份手册，可以更进一步说：数字员工在组织流程里做的事，本质上就是把手册里的工件链机制从代码仓库搬到业务流程里——
- 代码世界里，intent.md 提交到 git，触发下一阶段
- 组织世界里，数字员工在群里接到任务、产出结果、@相关人确认，审批链和审计日志沉淀在组织图谱里
机制同构，载体不同。Anthropic 用 git 承载工件链，钉钉用组织身份 + 审批链 + 审计日志承载。前者重接的是工程师的工作流，后者重接的是整个组织的协作流。
还有一个细节值得说：手册最后提到用 Claude Tag 让 agent 在 Slack 里值班，回答临时问题、做自助数据分析。这就是我在前天文章里说的「老板 AI」的工程版——决策者不用再等信息层层上报，问一句就能拿到带上下文的答案。区别在于，手册里的值班 agent 服务的是工程团队的即时问答，而组织里那个「上下文负担最重、时间最稀缺」的人，是老板。
五、一个可以今天就做的动作
这份手册最实用的部分，是它给每个打法都配了「如何开始」和「如何衡量」。我不想照搬它的步骤（那更适合工程团队），但想提炼一个对所有组织都成立的检验动作：
找一个你组织里最重要的流程，问三个问题：
- 这个流程每个环节的产物，是写进了一个 机器可读、有版本 的地方，还是散落在聊天记录、邮件和人的脑子里？
- 下一个环节开始工作前，需要 重新收集 多少上一个环节的上下文？
- 这个流程里，有多少检查是 排队等待式 的（等评审、等审批），又有多少是 内联现场式 的（动作发生时即时校验）？
三个问题的答案，就是你组织里的摩擦带地图。第一问的答案越偏后者，交接摩擦越大；第二问的数字越大，搬运摩擦越大；第三问越偏前者，等待摩擦越大。
Anthropic 用这份手册证明了一件事：当 AI 把执行做快之后，组织的流程不是「要不要改」的问题，而是「不改的代价每天都在复利」的问题。 评审队列的堆积、治理成本的上升、控制与现实的脱节，都是复利。
代码不再是瓶颈了。你的组织，准备好成为下一个被改造的对象了吗？
欢迎留言聊聊你组织里那条最慢的流程。