今年八月，软件工程领域有两份重要文件先后落地，一份来自学术圈，一份来自产业界，彼此没有互相引用，却几乎在同一时间给出了同一个诊断。
一份是 8 月初挂上 arXiv 的技术报告《SDAD: Spec-Driven Agentic Development for the AI-Native SDLC》（arXiv:2608.20341），我上周写过一篇精读。另一份是 8 月 21 日 Anthropic 官方博客发布的《The AI-Native SDLC Playbook》，出自 Applied AI 团队的 Louis Claxton 之手，篇幅 46 分钟阅读量，副标题直白得很：如何一个阶段一个阶段地改造你的软件开发生命周期。
我把两份都读完了，越读越觉得这件事值得单独写一篇——不是因为它们观点相近，而是因为论证路径完全不同的两份文件，从两端撞出了同一个结构性结论。这种收敛本身就是信号。
同一个诊断：瓶颈从写代码，移到了写代码的两侧
SDAD 论文的表述是：当智能体能吞下整仓库和完整需求文档，「写代码」不再稀缺，「把意图写清楚」成为新瓶颈，所以生命周期要围绕规约重组。
Anthropic 手册的开篇标题就叫 "Code is no longer the bottleneck"，然后给出了更具体的版图：Build 塌缩到小时级，但左右两侧的 Plan、Review、Test、Deploy 还在以人类速度运转；逐行 review 在人类写代码的时代是合理的控制手段，智能体写掉大部分 diff 之后就跟不上了；治理成本不降反升，异常处理还在走周会和月度委员会。
诊断一致，开出的药方也同构。
处方同构：一根「工件链」，两种表述
SDAD 的核心资产是形式化规约：意图记录 → 机器可读蓝图 → 智能体合成 → 独立验证，人类上游化为 Spec Architect（规约架构师）。
Anthropic 的做法是把这句话落成了具体的文件名。每个阶段以提交一个版本化工件结束、以下一阶段读取它开始：
intent.md → spec.md → plan.md → diff + tests → review findings → incident recordintent.md 记录要解决的问题和约束，产品负责人签发；spec.md 由智能体根据组织级 skills（品牌、安全、合规、UX 政策全部写成技能文件）生成，产品负责人审核但不执笔；plan.md 拆解成有依赖关系的步骤清单；最后到 diff、测试、评审发现、事故记录，每个工件都进版本控制。
手册里有一句很硬的话：这条工件链本身就是审计轨迹。哪个阶段、哪个人、用哪个版本的技能文件批准了什么，git 时间戳全部记得清清楚楚。
再对照角色：SDAD 说工程师要变成「写规约的人」，Anthropic 说产品负责人写 intent.md 和审核 spec.md、技术负责人写 REVIEW.md 和设人工阈值、平台工程师管理技能文件和 hook——双方都在把人类从实现层抽走，钉在门禁上。
三处细节，看出手册比论文更「带血」
论文给框架，手册给的是踩过坑之后的工程细节。三处值得单独说。
第一处：配置也要做回归测试。
CLAUDE.md、skills、hooks 这些「智能体的配置」，一有改动 CI 就自动跑一套 20 到 50 个真实任务的 eval 套件，通过率跌了就不许合并。思路是把给智能体的配置当成代码对待——配置会过时（模型一升级，旧的判别用例就失效了），所以 eval 必须是活的套件，持续从生产监控里补新 case。甚至规定每出一次生产事故，处理团队要把它写成一条永久 eval。事故不是复盘完就翻篇，而是变成回归测试资产。
第二处：组织级学习闭环。
review 发现同类错误第二次出现，修正直接写进 CLAUDE.md——因为评审也读这个文件，下个 PR 开始这个错误就会被自动拦截。错误处理从「人长了记性」变成「组织长了记性」，而且这个记性是版本控制的。
第三处：看门狗刻意不用模型。
Stage 6 的生产监控，检测脚本完全确定性——滚动窗口均值加标准差，套 Western Electric 规则，一个模型都不调用。分级响应写在配置文件里：1 个标准差偏离只记日志；2 个标准差 Claude 以只读身份进场诊断；3 个标准差才允许行动，而且行动路线只有两条白名单——开一个进评审门禁的 PR，或者触发一个预先批准过的 runbook。
为什么检测层要刻意「笨」？手册没明说，但答案很明显：确定性脚本不会幻觉、不会漏报、行为可复现。该笨的地方笨，该聪明的地方聪明——这是把 AI 用在刀刃上的克制。
门禁哲学：两个文本，同一句话
SDAD 论文的结尾是：智能体的速度不会消灭工程纪律，它只是把纪律上游化——转移到规约的精确性、显式的门禁和可审计的溯源里。
Anthropic 手册的收尾是：The loop keeps running. Human judgement stays above it.（循环不停，人类判断悬于其上。）
展开看手册对「门禁」的执行强度：生产部署 hook 在指定发布经理授权前硬阻塞；agent 每次无交互运行用独立身份，流水线日志里「智能体干的」和「工程师触发的」分得清清楚楚；rollback 要求是在 staging 定期演练过的最熟练路径——理由是闭环运行时真的会调用它，必须提前验证过。
手册里还有个细节颇有些微妙的坦白：Stage 5 提到 review 发现本身不批准也不阻塞 PR，分支保护仍然只认 code owner 的批准——但平台工程师如果想在发现数量上设门槛，check run 会输出机器可读的严重度计数。措辞谨慎，留了口子，但方向已经很清楚：人类审批是唯一硬门禁，其他一切是软信号。
差异与短板
两份文件的差异也很清楚。SDAD 停在理论框架和经济学估算——那张 99% 成本塌缩的表数字大胆但来路是作者自估；Anthropic 给的是可执行清单，每个打法都配了能直接从 git 时间戳和 PR metadata 取数的度量指标，比如「intent.md 提交到 spec.md 提交的间隔，对比旧的的需求-设计周期」「首次 CI 通过即合并的占比」。
但手册也不是没有盲区。全篇假设读者已经在 Claude Code 生态里，工件链绑定的是 intent.md 这些 Anthropic 格式；46 分钟的篇幅里，对「工件本身过期怎么办」着墨很少——1000 页规约账本和演进了的现实系统之间的一致性，SDAD 论文里那个语焉不详的「规约考古学」问题，在手册里同样没有答案。
为什么说收敛本身是信号
方法论文写作里有个现象：当一个问题真正成熟时，不同出发点的解会趋同。1990 年代末，IEEE 和 ACM 从教育和产业两侧各自定义软件工程知识体系，最后大量重叠——那说明软件工程作为学科成立了。
这一次，学术报告和厂商手册从两端撞出同一句话：代码生成不再是竞争壁垒，工件链和门禁设计的质量才是。
对做智能体开发的人，这两份文件建议都读，顺序无所谓：论文给骨架，手册给肌肉。对准备动手改造团队流程的管理者，直接从手册抄作业，但记住它的隐含前提——你得先把组织政策写成机器可读的技能文件，这一步没有捷径，而且这一步恰好就是 SDAD 说的「新瓶颈」。
钟摆从敏捷摆向规约，这次是学术和产业一起按的手。
参考：
- SDAD: Spec-Driven Agentic Development for the AI-Native SDLC（arXiv，CC BY-SA 4.0）
- The AI-Native SDLC Playbook（Anthropic 官方博客，2026-08-21）
Views: 0