代码不再是瓶颈之后：AI 原生研发真正稀缺的是可编码的判断

2026年8月，Anthropic 发布《The AI-Native SDLC playbook》。它的核心判断是：组织已能以一年前难以想象的速度用 AI 写代码，但围绕代码的审批、交接和政策并未同步改写。手册仍用 Plan、Design、Build、Test、Deploy、Maintain 六段描述生命周期，并主张用可提交产物——intent.md、spec.md、plan.md、diff 与评审记录——把各段连成闭环。

这一诊断成立。本文的异议不在「要不要改流程」，而在「改什么」。手册把转型单位写成六个 play 和一条 markdown 提交链。真正稀缺的，是组织把不可逆判断编码成机器可检查约束的速率。 没有这一步，所谓 AI-native SDLC 只是文件名更好看的加速瀑布。

手册说对了什么

手册说对了三件事。第一，瓶颈外移：Build 塌缩到小时级后，Plan、评审/测试和 Deploy 仍按人的节奏运行。第二，控制失效：逐行人工审查在「人写每一行」时合理，在 agent 产出大部分 diff 后不可持续。第三，产物即证据：每个阶段提交下一阶段能读的文件，提交历史成为「谁要求了什么、agent 产出了什么、谁批准了」的审计链。

这些观察来自公开手册，不是独立调研。手册给出的控制也具体：CLAUDE.md、skills、hooks、托管权限、生产门禁，以及「写代码的 agent 不能批准自己的变更」。这些都应当保留。

问题在于前提。手册默认组织已经知道自己要强制什么——品牌、安全、合规、发布授权都已写成技能或钩子。多数企业卡在这里：不是不会用 agentic coding，而是政策仍活在会议纪要和个别审查者的脑子里，编码速度跟不上 agent 制造例外的速度。

三种看 SDLC 的方式

可编码判断，而不是更快的阶段

「可编码判断」不是再写一份更长的需求文档。它指：一项一旦做错就难以撤回的决定，被写成 agent 行动时必须遵守、违反时能被确定性拦住的规则，并有具名责任人。手册区分了咨询性控制（skill）和确定性控制（hook）：前者让违规变少，后者让违规接近不可能。这个区分比六阶段图更重要。

判断编码速率衡量的是：从组织发现「这条规则必须成立」到它成为钩子、评测或分支保护的时间。若这一间隔仍以周或月计，而 agent 以小时产出变更，治理成本会上升。手册自己写到，例外仍要排队进入按周或按月开会的委员会。加速的是生成，不是授权。

产物幻觉

提交一份 intent.md，很容易被误认为已经做了产品决策。手册要求产品负责人在提交前审阅并改正 agent 起草的意图，接受或拒绝应记录为合并或关闭评审。这一要求正确，但脆弱：当意图从告警、工单或值班频道自动写入，评审者面对的是格式完整、看起来像已经想清楚的文件。盖章比在空白页上思考更省力。

于是出现产物幻觉：审计轨迹记录了「有过一次批准」，却记录不了「批准者是否理解自己批准了什么」。markdown 对人和机器都可读，这是优点；它并不自动产生判断。手册也写明 skill 是咨询性控制，必须硬性成立的政策还需要钩子或评审回查。把制度知识写成文件是局部最优。文件编码的是昨天的错误，编码不了「何时该打破规则」。

闭环是最后一段，不是定义

手册把 Maintain 写成闭环的完成式：确定性脚本监视生产，控制带越界后无人值守地调用模型，诊断写回 intent.md，工作重新进入管道。在控制已编码、回滚已演练、分层权限已冻结时，这是合理的运维模式。

它不应当被当成「AI-native」的定义，而应是成熟度的最后一小段。检测层保持确定性，是手册里最清醒的句子之一：模型不应参与「是否越界」的判定。但一旦越界就自动开题，组织会得到自我循环——噪声生成意图，意图占用评审带宽，带宽压力训练人们更快地点通过。闭环会放大已经编码的判断，也会放大尚未编码的偏见。

该测授权，而不只是吞吐

手册已经给出了比吞吐更接近约束的指标，只是把它们写成各 play 的附属：intent.md 被产品负责人接受进入 Design 的存活率；同一变更在首份 spec.md 提交后意图仍被改写的次数；政策变更获批到对应 skill 合并的时间；评审发现中引用该政策的数量应趋向零。这些不应排在「每人每周合并数」后面。

若只优化交付频率和并行会话数，组织会得到更多等待批准的 diff。该问的问题是：有多少不可逆决定已经变成门禁？还有多少仍住在会日历里？在后一类清空之前，提高 agent 自主性只是把瓶颈从键盘移到签字。