Anthropic AI原生SDLC缺第四控制点

Anthropic 上周发布了一份 AI-Native SDLC（AI 原生软件交付生命周期） playbook。其核心论点是：代码生成不再是交付过程中的瓶颈。围绕代码生成的其他阶段——规划、review、安全审批、发布——仍然以人类的速度运行。一旦 Agent 写出了大部分 diff，这种速度差就必然以两种方式之一爆发：review 队列不断堆积直到速度优势消失殆尽，或者代码在未经充分审查的情况下发布。对于受监管的行业来说，这两种结果都不可接受；对于非受监管场景，也都不是什么好选择。

他们的解决方案是结构性的，而非流程性的。每一个阶段都会提交一个供下一阶段读取的产物：intent.md、spec.md、plan.md、diff 及其测试、附有 review 结果的 PR、事故记录。这条提交链成为审计轨迹。人类注意力集中在各阶段之间的关卡上，而不是在每个阶段开始时浪费精力重新推导上下文。

我认为这个模型是正确的。但我认为它少了一个控制面，而这份 playbook 自身的逻辑恰恰指向了这个缺口。

advisory 层与确定性层

这份 playbook 最实用的部分，是它几乎不经意间展开的一个递进机制。机构知识通过四种机制传递，一种比一种更强：

CLAUDE.md —— 版本化管理、在 PR 中 review、每个会话必读。约定、命令、已知失败模式都沉淀在这里。

Skills —— 策略写一次，应用范围广。用 playbook 原话来说："skill 是一种控制手段，尽管是 advisory（建议性）的。"

Hooks —— 确定性层。"一条必须始终成立的策略，需要在 skill 背后有确定性机制支撑，比如一个在动作执行前将其阻断的 hook。"

Evals 和 CI —— 配置本身也要做回归测试；在延迟不敏感的地方运行更重的检查。

Skills 使违规变得罕见。Hooks 使违规接近不可能。这就是两者的全部区别，也是很多"治理"工具混淆的那条线。检索和引导提高 Agent 做正确事情的概率。确定性检查则在动作落地之前决定它是否被允许。当这个领域最大的 Agent 供应商告诉企业：任何必须始终成立的策略都需要一个确定性后盾时，这已经不再是一个有争议的主张了。

Hook 模型在哪里触及边界

Playbook 中的 hook 示例都是路径作用域的：阻止对生成代码目录的编辑、编辑后运行格式化工具、将凭证排除在 diff 之外。这些之所以有效，是因为规则和触发条件是同一个东西。"永远不要编辑这个目录"是对路径的谓词。快速 hook 可以完美地执行它。

架构决策无法归结为路径。以下是真正治理成熟代码库的几类例子：

这项服务使用 PostgreSQL 而不是 SQLite，因为后者的并发配置不适合。

领域代码不依赖适配器；依赖关系只能向内指向。

认证流经一个边界模块；其他模块不得发放令牌。

此废弃规则适用于 checkout，暂不适用于 billing，billing 下一季度迁移。

以上每一条都同时依赖三样东西：决策本身、其作用域、以及提议的动作。一条规则可以在一个子系统中是绝对的，在另一个子系统中则无关紧要。一条较新的决策可以取代较旧的决策，但只针对部分代码库而非全部。这已经不是指令执行了，而是评估：给定这个变更，哪些已记录的决策适用，它们要求什么？

ADR 已经是正确的产物

大多数团队已经把这些决策写成 ADR（Architecture Decision Records，架构决策记录）。Playbook 的产物链给它们提供了一个自然的归宿，它们和其他环节一样是提交产物。真正把 ADR 从文档变成治理的手段，是将其编译成机器可以对提议变更进行评估的东西。

有两件事比流水线步骤本身更重要：

检索服务于 Agent，不做裁决。 在生成之前将相关架构指导浮现出来确实有用，skills 也擅长此道。但相似性搜索不是判断适用性的正确仲裁者。如果两条 ADR 涉及同一子系统，且一条取代了另一条，那么新的那条必须始终胜出，而不是仅当其 embedding 恰好排名更高时才优胜。适用性必须被确定性解析，包含优先级，检索只是将上下文输入到那个解析过程中，而不是投出决定性的一票。

每个裁决都产生证据。 因为检查运行在动作之后而非之前，记录会显示评估了哪条决策、变更提议了什么、以及为何被允许或阻止。这就是将漂移预防从愿景变成机制的关键：漂移在提议阶段就被捕获，而不是在三个 sprint 之后的事后复盘中才被发现。

Hook 是执行点，不是策略

Playbook 的执行原语是正确的。Hook 在动作完成前触发，可以允许、询问或阻止，并且应该保持快速和作用域限制。这正是执行应该归属的位置。但一个回答"这是否被允许"的 hook，其上游仍然需要一个回答"哪条规则适用，为什么"的实体。

这个上游层无法存在于单个 prompt、session 或 Agent 产品中，原因有三：

持久性。 编码在 prompt 中的规则随 session 消亡。以结构化策略编码的规则在每个后续 session 中都存活。

工具链独立性。 没有人的 Agent 会用一辈子。如果你的架构策略耦合到某一工具链的 hook 格式，每次迁移都会悄然让你的决策被遗弃。

治理语义。 取代、作用域、带有效期的例外、可查询的记录（追踪哪条决策产生了哪个裁决）—— 这些是真实存在的建模问题，而不是 shell 脚本里的字符串匹配。

把它和其他三条并列，AI-Native SDLC 就多了一个目前缺失的控制面：

Intent 控制应该构建什么。

Tests 控制变更是否有效。

Security 控制变更是否安全。

Architecture 控制实现是否仍然匹配系统的预期结构。

Playbook 甚至暗示了为什么这不能停留在非正式层面：在其关于并行 session 的章节中，它指出控制越来越必须来自仓库中的共享配置，因为没有任何工程师能够亲自监督每一条并行的 Agent 流。对于运营策略来说，这是很好的起点。架构策略加上确定性适用性和优先级机制，则是同一个理念的完成形态。

这不是对这份 playbook 的否定，它是外部视角对"在循环中嵌入执行"这一模式最有力的认可之一。它承认了架构控制所需的每一个前提：有些策略必须始终成立、 advisory 机制无法单独保证这一点、确定性检查属于动作之前、而且控制必须通过共享配置而非个人监督来扩展。

因此，采纳此模型的团队应该采取加法而非对抗的方式。保留产物循环。用 skills 传递机构知识，用 hooks 建立运营护栏。然后将你的 ADR 语料库编译成结构化的、有作用域的、有优先级意识的约束，对每个提议变更确定性解析它们，让裁决驱动你的工具链所提供的任何执行点。生命周期已经被围绕提交意图重建。Architecture 是这批意图中还没有人完成执行的那部分——我们正在围绕填补这个具体缺口构建 Mneme。

完整原文含图：The Architecture Layer the AI-Native SDLC Needs