Anthropic 发布 AI-Native SDLC 实践手册：代码不再是瓶颈

Anthropic 前不久发布了《AI-Native SDLC Playbook》。其核心论点是“代码不再是瓶颈”——当 Agent 能在几分钟内完成一个实现时，约束就转移到了构建阶段之外的一切：规划、审查、验证、部署和治理。

风险在于，如果组织做错了这件事，产出的变更数量会是原来的十倍，但每次变更的质量不变甚至更差，而且没有办法识别哪些变更是糟糕的。传统答案是由人来逐个审视，而这种方式在如此规模下恰恰会失效。

风险在于，产出的变更数量会是原来的十倍，但每次变更的质量不变甚至更差，而且没有办法识别哪些变更是糟糕的。

这份 Playbook 的基础是正确的。它没有捕捉到的是，一个组织的流程是有细微差别的：它实际上是一族流程，会随变更的性质而变化，而不是每条变更都走同一条路径。

Playbook 是更广泛的 spec 驱动开发工具浪潮的一部分，亚马逊的 Kiro 和 GitHub 的 Spec Kit 也属此类。这些工具有一个共同的形态。书面制品驱动工作：一份 intent 文档变成 spec、计划、diff 和审查结果，所有内容都提交到版本控制中。策略通过钩子等确定性机制来强制执行，而不是靠在 prompt 里写指令。Agent 在人看到之前检查自己的工作。人拥有审批权。

但这些工具每一种也都规定了一个特定的流程：一个固定的阶段序列，产生固定的制品，每条变更都要经历这个过程。采纳这个工具就意味着采纳它的流程。

没有任何一个真实组织会运行单一流程。某一变更该用哪种流程，取决于它携带的风险和所需的问责程度。一处文档修复、一个依赖升级和一笔支付服务中的 Schema 迁移，不应该走同一条路径。它们需要不同级别的验证、不同的审批人、不同的记录。在受监管领域，流程本身就是合规义务的一部分：审计员期望看到每条变更由谁批准、以什么证据为依据的记录。需要记录的内容因变更类型而异。

当一个工具规定了一种流程，团队就会为不适合的变更绕开它——这是最糟糕的结果，因为真正的流程变得不可见了。

当一个工具规定了一种流程，团队就会为不适合的变更绕开它——这是最糟糕的结果，因为真正的流程变得不可见了。又或者供应商不断添加配置，直到工具变成了一套没人能完全理解的工作流引擎。

工具不应该规定一种流程。它应该给组织提供一种定义自己流程的方式。

更好的模型是将每个流程定义为一个状态机。状态是关于变更的事实：已审查、已针对依赖验证、已获批上线生产。这些事实存在于没有一个单独工具拥有的系统中：仓库、CI、集群、追踪器。因此流程不能是一个执行步骤的程序，而是一组对那些系统的观察做出反应的规则。每条规则指定：

• 它在触发前需要的事实。
• 它的门控：自动触发，或等待一个人批准。
• 触发时授予的权限，如合并或部署的权限。

定义就是这组规则，存储为数据并像代码一样审查。一个组织运行多台小型机器，每台对应一个风险类别。

在运行时，这个模型的行为完全不像工作流引擎。没有组件追踪“我们现在在第四步”：流程在某一事实出现在拥有它的系统中时前进，规则对此做出反应。迟到、重复或重启后到达的事件，处理方式与其他任何事件无异，因为规则只对当前状态做出反应。门控是规则的条件之一，因此你可以在事件期间或发布冻结期间暂停触发，而无需修改任何定义。

门控需要 enforcement。以 prompt 指令实现的门控依赖于模型遵循它。Agent harness 可以提供运行状态机并强制执行其门控所需的确定性，在动作之间停止 Agent 直到门控得到答复，而基础设施负责强制执行其余部分。

仓库的单一固定流程定义是不够的：该仓库中的每条变更仍然会走同一条路径，无论其风险如何。变更走的路径应该取决于变更本身是什么，而这种路由来自对变更的分类，而不是由作者选择路径。组织使用已有的信号来定义分类：变更触及的路径、它所在的仓库、追踪 issue 上的标签等。

定义本身也需要随时间变化，而这必须安全。因为流程定义是数据，编辑它本身就是一次变更，它要走自己的门控流程。放宽发布流程上的一个审批门控，其审查方式与 Schema 迁移相同，而不是像编辑配置文件那样随意。

点击放大图片。

具体来说，看同一服务的三个变更：

文档修复由它触及的路径来分类。它的流程只有两个状态：构建通过，以及合并。没有人参与。

依赖升级跳过设计审查，但它的流程需要兼容性证据：升级后的服务针对真实依赖运行集成测试。大版本升级比小版本补丁多一个审批。

支付服务中的 Schema 迁移由它触及的组件来分类，无论它声称是什么类型的变更。它的流程添加了其他变更永远不会见到的状态：支付负责人审查、针对生产形态数据的验证，以及该领域负责人的发布批准。

每条路径中的每个转换，都记录了谁批准了以及以什么证据为依据。

这些流程应遵循的原则：

自主权按动作授予，并随时间增长。每个转换可以设为自动触发、需要批准或暂停。随着 Agent 在某一类变更上证明了自己，该设置会放宽，流程因此吸收了 Agent 的改进而无需重新设计。

人的注意力只花在需要判断的地方。Agent 的成本越来越低；监督工时不会。一条变更只有在决策需要人类判断时才会进入人的循环，并且会给出能快速做决定的上下文。

证据来自 Agent 外部。Agent 自己的报告永远不能让变更前进。转换基于 Agent 无法写入的系统中的事实来触发，如测试结果和在真实环境中的验证。

流程记录就是审计追踪。定义就是书面策略，转换日志显示谁批准了每一步、以什么证据、在哪个版本的策略下。

Playbook 及其同类在基础上是正确的。缺失的是组织定义自己的流程、根据每条变更的风险让流程有所不同、以及安全地演进流程的能力。目标不是减少循环中的人。而是把人类的判断力只花在真正需要它的地方，由 Agent 无法为自己生成的证据所支撑，这样质量才能在吞吐量倍增的同时保持住。

我们正在 Signadot 构建这些想法，并拿自己做实验，让我们的开发过程也跑在这套流程上。如果你也在实验这些想法，我们很乐意交流！