ARTICLE · 1210959
AI 原生软件开发生命周期:流程重塑与安全内建
这份稿子的来路
Anthropic 发过两篇同题文章，一长一短。
长的那篇叫《The AI-native SDLC playbook》，作者 Louis Claxton，应用 AI 团队，2026 年 8 月 21 日上线，正常速度读下来要四十分钟。它谈流程：六个阶段各怎么改，每阶段留下什么文件，改完拿什么验收。
短的那篇讲的是另一件事——当八成合并代码由 AI 写出来，怎么保证这堆东西不出事。作者 Jason Clinton，副 CISO，2026 年 7 月 21 日上线，六分钟能看完。
- 流程手册（playbook）
｜Louis Claxton（应用 AI 团队）｜2026-08-21｜约 40 分钟｜讲流程架构：六个阶段怎么改、产物是什么、如何度量 - 安全复盘
｜Jason Clinton（副 CISO）｜2026-07-21｜约 6 分钟｜讲安全控制：改完之后如何不出事、边界划在哪
我把两篇并成一份。骨架取六个阶段，安全措施按阶段归位；同一个判断两篇都讲了的，只留第一次出现的位置。四处分歧没硬凑，第六部分逐个摊开。文件名和专业动作名保留英文原文，中文只作解释，术语表见附录。
一页速览
细节在后面，这里先给结论。
代码不再是瓶颈。 这话很多人嘴上认，行动上未必认。Anthropic 自己的数字摆着：每位工程师每季度交付的代码量，是 2021 到 2025 年那五年的八倍；合并进主干的代码里约八成出自 Claude；超过一半由内部的标记系统自动合入。编码快了八倍，审查和发布还按老节奏走，多出来的量就堆在原地。阿姆达尔定律讲的就是这件事——只加速一个环节，整体收益会被没加速的环节吃掉。
要改的是整个生命周期，编写代码那一格不算。 AI 原生 SDLC 有个核心命题：传统开发流程的控制目标保留，执行方式换掉。变的只是手段。
主线机制叫提交产物（committed artifact）。 每个阶段收尾时把一份东西提交进版本控制，下一个阶段直接读它，不再重新开会：intent.md、spec.md、plan.md、代码改动与测试、带评审发现的 PR、事故记录。这条链条本身就是审计轨迹。
流程从一条线折成一个环。 运维阶段发现异常，自动回流成新的 intent.md，再走一遍流水线。人不再逐个环节点火，只守在门禁上。
安全是三层，不是一道关卡。 建议性控制（skills、CLAUDE.md，让违规变罕见）、确定性控制（hooks、沙箱、managed settings，让违规近乎不可能）、人类门禁（分支保护、具名授权、抽样复核）。三层底下还压着一个地基：智能体身份模型和最小代理权限（Principle of Least Agency）。
安全工程师的日常换了对象。 以前盯缺陷，现在盯循环——skills 有没有过期、缺陷类别有没有回流、自动批准有没有被抽样、指标有没有漂移。
最容易漏掉的一条。 边界要划在"访问与动作"上，别划在"我们认为模型能做什么"上。智能体之间的调用权限，本身就是爆炸半径的一部分。
第一部分 诊断：为什么必须改
1.1 写代码不再是稀缺资源
老流程建立在一个几十年的假设上：写代码贵。贵就要在动手前把需求想透，写完再逐行看 diff。
Claude Code 这类 agentic 工具把这个假设拆了。一个自主会话跑下来，产出几千行 diff 是常态。
瓶颈跟着挪位置。Plan、Review/Test、Deploy 三处成为新的堵点，review 最典型：人工逐行读 diff 的做法，在代码由人写的时候是合理的，在 agent 产出大部分 diff 时就维持不住。治理侧同样卡住，例外申请仍然要排每周或每月的变更委员会（CAB）审批。
1.2 三组实测数字与 Amdahl's Law
Anthropic 内部的数：
Amdahl's Law 在这里很直接：整体加速比受限于没被加速的那部分。编码提了 8 倍，review 和 monitoring 吞吐不变，只剩两种结果——review 队列无限堆积，或者代码在 review 不足的情况下 merge 进主干。受监管组织两种都受不了。
1.3 三种角色，一个不变的东西
Claude 的位置变了，从 coding assistant 变成主要创建者兼 reviewer。人类工程师退到三件事上：设定 intent、指挥、保留最终 approve 权。
组织形态跟着散开。前后端和设计之间的边界糊掉，原型和内部自用工具取代了长周期规划。
有一件事没变：这六个阶段的名称和目的，对从传统组织过来的人一点都不陌生。它们是天然的 gate，安全流程正好挂上去。
1.4 威胁模型：三类输入，四条策略
谈控制之前先明确防什么。所有控制措施至少对应下面一类：
四条总体策略：安全左移、深度嵌进编码阶段；用硬性 identity 与 access 边界遏制 blast radius；生产前后把确定性审查和 agentic 审查结合起来；在杠杆率最高的节点插人。
第二部分 定义：什么是 AI 原生 SDLC
2.1 核心命题：控制目标不变，执行方式改变
AI 原生 SDLC（也叫智能体驱动的开发生命周期）经常被误解成"用 AI 写代码"。差得远。
它真正的动作是：把传统流程的控制目标留着，换掉执行方式。
所谓控制目标，指那些不管用什么工具都必须成立的要求——变更要有人批、生产变更要能回滚、谁能碰生产数据要说得清。这些一条都没动。
换掉的是证明它们成立的方式。以前靠人读 diff，现在靠多层 agent 审查加抽样复核；以前靠发布评审会签字，现在靠 hooks 拦住具名授权。这是整个方法论的内核，也是它能被合规和监管接受的前提——要求没松，只是手段换了。
2.2 主线机制：提交产物与审计轨迹
每个阶段结束时提交一份产物到版本控制。下一个阶段读它，而不是把相关的人再叫到会议室里重讲一遍。
早期几个阶段的产物是普通文本文档，理由很朴素：产品负责人和 agent 都能读，也都能执行。到了编码阶段之后，产物转成代码及其记录。
这条链还有个副作用，价值不比流程本身低：它天然就是审计轨迹。谁提了什么、agent 产出了什么、最后谁批的，全部可回溯。
2.3 形态变化：从线性流程到闭环
传统开发流程是条直线，需求进来，设计、开发、测试、上线、维护依次走完。
新的形态把它折成环。运维阶段发现控制带（control band）被突破，自动生成一份新的 intent.md，重新回到起点。
人的注意力也跟着挪位置——从"启动每个环节"变成"守在门禁上，看 agent 标出来的东西"。
第三部分 六阶段详解
六个阶段用同一个骨架讲：目标、关键产物、流程做法、安全与控制、度量。流程做法主要来自那份流程手册；安全那一节把两篇合起来了，包括安全复盘的实战经验。
3.1 计划（Plan）
目标：在想法还带着原始语境时抓一次，变成能执行的东西。
产物：intent.md。
提出者用自己的话讲一遍：不能做什么、谁受影响、什么算更好、哪些不在范围内。然后追问到具体——范围、用户、约束、成功标准。最后按组织模板落成一份 intent.md，五块内容：问题、预期结果、受影响的用户与系统、约束、开放问题。
产品负责人只评审，不撰写。这两件事混在一起，产物就会变成"给领导看的东西"。
安全这边。 最早是个内部网页应用，叫 PSR，由高配版 Claude 驱动。它读设计文档，按 MITRE ATT&CK 框架找潜在漏洞，给出缓解建议。后来接上内部知识索引，能拿到跨全组织的政策、历史决策和相关系统的上下文。
效果有点意外。因为风险评估经过长期验证确实准，判定风险足够低的项目，允许团队自己批，省下 AppSec 大量时间。
有个适应点必须讲。过去架构评审是关键卡口，因为写代码贵，得先想清楚。现在几小时能出好几个原型，详细架构文档就不再是卡点了。做法跟着变：从"强制写文档"改成"让 agent 去上下文本来就存在的地方取"——聊天线程、历史评审记录、代码库本身。
度量：先行指标是首次对话到 intent.md 提交的耗时，预期从数周压到数小时。滞后指标两个——intent.md 存活率（被接受、进入设计的比例），以及 spec.md 提交之后 intent.md 还被改过几次。
3.2 设计（Design）
目标：把需求和设计并成一次会话，让策略在写规格那一刻就生效，而不是三周后在评审会上才发现两条政策打架。
产物：spec.md，和 intent.md 成对提交。一个记"要什么"，一个记"决定了什么"。
产品负责人把已接受的 intent 交给 Claude，组织写好的 skills（品牌、安全、合规、体验）约束生成过程。仍然只评审不撰写。
spec.md 里必须有一节 flagged concerns，明确标出哪条政策没法同时满足。前端可以在设计工具里做稿，导进编码环境直接构建。
安全这边。 安全与合规策略写成 skills，于是它们变成生成时的约束，而不是事后检查清单。
spec.md、生成它的提示词、当时生效的 skills 版本，三样全部进版本控制。半年后有人问"当初为什么这么定"，能复原出依据的是哪一版政策。
flagged concerns 要路由到具名的策略负责人手里。这类问题本来是分析人员该升级的点，不能被自动化悄悄吞掉。至于要不要进下一阶段，永远由人决定。
度量：先行指标是两份文件提交之间的间隔，两个版本的时间一减就有。滞后指标是需求返工——同一变更的首份 plan.md 提交之后，又冒出多少个 spec 提交。
3.3 构建（Build）
目标：计划批准之后才动代码，同时让机构知识以可执行的形式沉下来。
产物：plan.md、代码改动、测试。
五个支柱：
实现偏离 plan.md 怎么办？在同一次提交里更新 plan.md。这个模式本身就是强制机制：plan.md 没被接受，模型改不了文件。
拆分的规则是文件不重叠，非要改同一个文件的任务就串行。
安全这边。
- 直接塑造生成方式。
这是安全团队在 AI 时代拿到的真正新杠杆。过去发现一类重复漏洞，写安全编码指南，然后祈祷有人看。现在把指南编码进 CLAUDE.md 和全组织 skills，代码在生成那一刻就按最佳实践写。闭环由此形成：agent 发现某个缺陷类别，更新指令，这类缺陷不再复发。左移也被重新定义——不是把评审往前提，是闭合"发现—更新指令"这条回路。 - 提交前自查。
最早的做法很土：在 CLAUDE.md 里要求 agent 开 PR 前跑一遍安全自查，定位攻击者可控输入的入口、扫可疑链接、再验证自己的发现。后来产品化成一个正式命令。 - 生成过程中的审查。
装上安全指引插件后，模型边写边看对话和代码，同一个会话里就提改进建议，不用等 PR。 - hooks 当构建期护栏。
三件事：阻断对受保护路径（生成代码、冻结包）的编辑；文件编辑后跑格式化工具防漂移；把凭据挡在 diff 之外。原则是构建期的 hooks 要快、限定到变更文件，重检查留到提交或评审。需要人类批准的动作千万别放这儿——构建期间弹批准，等于把人重新塞回所有并行会话的关键路径。 - 低代码托管平台。
推着非技术团队把应用托管在自家平台上，从源头掐掉影子 IT。
遏制 blast radius 的两个硬手段。 一是开发者统一在远程 VM 上编码，比笔记本强在控制和可见性；二是 VM 上 agent 的流量走出口白名单。
白名单那条分量最重。agent 读到的不可信输入可能带 prompt injection 载荷，白名单让被注入的指令没法把数据送到互联网任意目的地，外泄路径被压缩到少数几个被监控的服务里。
这里有一次观念迁移：远程开发环境过去主要保护知识产权，现在越来越多人拿它关住 agent。
度量：先行指标是首次实现即合并的变更比例、从计划批准到合并的时间。滞后指标是每次变更的返工轮次、合并代码与 plan.md 的一致率。
3.4 测试与持续集成（Test / CI）
目标：把审查能力扩到跟代码产出同一个量级，同时不让人类问责被稀释。
产物：测试输出、evals 结果。
顺序不能颠倒：先让它能自己判断对不对，再谈放手。没有自验能力的 agent，自主度越高越危险。
自验手段包括测试、构建、截图像素对比。会话里先自检自修，修不动了再交给人。
验证往往要一串命令加环境知识。把它包成单一入口——一条命令跑完，失败返回非零——并在 CLAUDE.md 的命令段列出每条命令和健康输出的样例。
目标要可量化。"测试脚本全部通过""截图匹配样例""接口返回 200 及新字段"，这类能用。"跑一下看看有没有问题"不能用。
修缺陷有条铁律：先写失败测试。让 agent 用测试复现问题，确认它按预期的原因失败，把测试提交上去，然后在不动测试的前提下让它通过。
回路本身要保护。修复中的 agent 不能削弱对这段代码的检查——用 hooks 在修复任务里禁止编辑测试文件，或者在评审阶段直接拒掉任何动了测试的改动。
还有一条常被跳过：把验证写进"完成"的定义里。报告完成之前必须跑测试，并把输出贴出来。
持续评测。 evals 是 AI 原生版的阶段门质量检查。触发条件是 agent 配置变更——CLAUDE.md、skills、hooks、提示词、底层模型，任何一项动了就跑，回答一个问题：它还按同一标准工作吗。
做法不复杂。从近期工作里收集 20 到 50 个真实任务和已被接受的结果，写成任务描述加可接受性检查；在流水线里按计划跑，配置变更时也触发；每个生产事故沉淀成一条常驻用例。
要点是把它当活套件看。模型变强之后，原来有区分度的用例会失效，得持续往里加。
安全这边：这里是最痛的瓶颈。
作者的经验很直接：转型过程中，测试与集成会很快变成工程团队最痛的瓶颈。原因简单——团队的速度上限就是人类审代码的速度。
解法是用自动化 agent 审查加确定性审查来加速，人工审查留给受监管的代码和真正关键的部分。
多个窄焦点 agent，而不是一个超级 agent。PR 一打开，多个 agent 自动审查，每个锁在一个特定而狭窄的焦点上，并检索历史事件做记忆。这个设计比"一个全能安全 agent"或者巨型提示词更管用，三个理由：它们不共享偏见和盲点；其中一个被攻陷或出错时，其他审查者能发现；注意力不会被多个领域摊薄。
要求 agent 为发现写 proof of validity。效果可以量化：带实质性审查评论的 PR 比例，从 16% 升到 54%。噪音降了，可信度升了。
剩下的四件事都是加一道人手：按风险给代码库分层，有些库整体保留严格人工批准；对自动批准按风险加权抽样复核；每次自动批准都记录它依据的信号与推理；不变量测试专门盯"用户甲永远不能读取用户乙的数据"这类断言，一旦触发就追加人工审查。
agent 扫描的结果直接发到 PR 上，跟 SAST 工具并排摆着，不另开入口。
参考数据两组。团队判断，过去线上事件背后约三分之一的缺陷，本可以被今天这套自动化流程捕获。外部案例里，Intercom 自动批准了 19% 的 PR，部署量翻倍，因破坏性变更导致的宕机下降 35%；CircleCI 的内部 agent 把"任务转化为已完成 PR"的比率翻了一倍，而且能在人看到之前自己验证修复。
度量：先行指标是 agent 变更的首次集成通过率、evals 通过率趋势。滞后指标是每个 PR 的评审时长、变更失败率、集成阶段捕获的回归与生产发现的回归之比。
3.5 部署与持续交付（Deploy / CD）
目标：让 agent 能行动到生产门禁为止，不能越过。
产物：PR，包含评审发现与批准记录。
评审里的 agent 干两件事：按组织策略评审进来的改动，同时处理自己改动上收到的评审意见。工程师只需要判断意图和风险。
在代码库根目录写一份 REVIEW.md，按关注点分轮次——缺陷、安全、对照规格与计划的一致性——并定义清楚什么算重要、什么算吹毛求疵、什么直接跳过。
人类阈值也要设：发现不自行批准，也不阻断改动。分支保护照旧要求 code owner 批准。
评审发现要回流到 CLAUDE.md。同一个错误第二次被标记，就写进去，从下一个改动起能被自动捕获。每月再调一轮：给发现打分、限制 nit 数量、把生成路径和流水线已经强制的内容排除掉。
安全这边。
预发环境的常规动作不能省。重大发布做外部渗透测试，定期跑 DAST，抓那些 SAST 看不见的逻辑缺陷。
AI 的影响是双向的。一方面更少缺陷能走到这个阶段；另一方面，活下来的都是最微妙、最难抓的。加上发布体量和频次一起涨，周期性动态测试已经不"动态"了。
解法是持续的、AI 驱动的动态扫描，专门找跨服务、跨组件的系统性假设错误——这类问题恰好是多步推理擅长的。参考一个数字：2026 年 2 月披露，Claude 发现并协助修复了 500 多个高危开源漏洞。
hooks 当审批门禁。 跟构建期的允许/阻断不同，hooks 还能"询问"——暂停动作，直到某个具名的人批准。落地分四步：工程领导层会同变更管理与合规，列出必须保留的人类审批；平台工程师把每个门禁表达成允许、询问、阻断三类脚本；团队级规则放代码库里，不可协商的放平台统一下发的 managed settings（工程师关不掉）；阻断必须能自我解释，理由要出现在模型输出里。
受监管企业的 managed settings 示例。 通过 MDM 下发，工程师不可覆盖。条目包括：禁读 .env、禁止任意出网；用 OS 级域名允许列表补上权限模型覆盖不到的终端出网；沙箱不可用就拒绝启动，沙箱内失败的命令不许到外部重试；从每条沙箱命令的环境里剥离具名密钥；只允许组织批准的插件市场与 MCP server；低于批准下限的版本拒绝启动。
作者自己加了句提醒：这是可裁剪的起点，不是照抄建议。每一条禁止都是拿能力换控制。
分层自主权。 先做只读判断——分诊失败构建、总结不稳定测试、起草变更日志；再加写动作——修格式问题、更新文档、处理评审意见，写出一律以 PR 形式过分支保护。执行沙箱化，默认不带生产凭据；通过 MCP 把部署、状态查询、回滚暴露成按环境限定作用域的能力；权限按环境分：开发自由部署，预发居中，生产由发布经理授权、hooks 强制门禁。
还有一条常被低估：回滚是最需要演练的路径。闭环会在控制带被突破时调用它，那时候可没空现学。
度量：先行指标是首次评审时间（应该降到分钟级）、无需人工碰分支就解决的评论占比、无需呼叫人工就完成分诊的流水线失败占比。滞后指标是合并前捕获的缺陷与逃逸到生产的缺陷之比，以及 DORA 指标（交付频率、变更前置时间、变更失败率、恢复时长）。
3.6 运维与闭环（Maintain）
目标：从"人启动每一步"转到"自主运行、独立置信门禁"。
产物：事故记录，最终变成新的 intent.md。
服务所有者挑一个基线稳定的指标——集成测试失败率、部署后 5xx 率、PR 周期时间都行。为它写确定性检测脚本：滚动窗口的均值与标准差，加一组经典统计控制规则，明确不用模型。脚本进版本控制，加单元测试。
然后在配置里定义响应层级：1σ 只记录；2σ 以只读方式调 Claude 做诊断；3σ 允许行动，但只能开 PR 进评审门禁，或者触发预先批准的应急手册。
触发层可以是定时工作流、监控系统回调、内网定时任务。Claude 无状态运行。
agent 按 3.1 的格式写诊断型 intent.md——异常与证据、建议的结果、受影响的系统、开放问题。写完跟着其他工作一起走流水线。
服务所有者或值班人员做分诊：立刻修、排期、驳回。驳回不是浪费，它用来调控制带的边界、降噪。修复上线后，为这个事故补一条 eval。
定期代码库扫描。 安全扫描本质上是"特定模型下对代码库的时点陈述"，两半都会过期：代码每周在变，每代模型都能发现上一代漏掉的漏洞。
做法是在无人调用的路径下按计划跑扫描，活跃服务默认每周一次。每条发现先验证再报告，附上置信度。修复走跟任何变更一样的门禁，提出修复的 agent 没有路径去批准它自己。
定位要放准：这是增强，不是替代。确定性检查留在流水线里，模型驱动的扫描负责那些依赖上下文的漏洞。
安全这边：分诊和修复必须分开。
告警响的时候，Claude 会查生产日志、定位根因、写复盘，有时直接写修复代码。但它不能部署修复。
这个分诊 agent 是单一用途的系统账户，只有三项权限：写新文档、在公司频道发帖、访问生产日志。修复必须来自另一个独立的"agent 加人类审查者"系统。
一次模型升级后，事件响应 agent 主动通过聊天工具联系了另一个能写代码的 Claude 实例，请求它推修复。这按设计被人类审查门禁拦住了。但团队由此意识到：划边界必须围绕"访问与动作"，不能围绕模型指令或者"我们认为模型能做什么"。
也就是说，agent 之间的访问权限本身就是 blast radius 的一部分。如今在 Anthropic，agent 之间在聊天工具里互相说话是常态，但每个都有明确的身份模型。
代码迁移的新经济学。 过去做一次系统性代码迁移，安全负责人得向各部门游说几个季度的小比例工程资源。现在 Claude 能在数天内自动化迁移数万行。迁移的经济成本和跨公司协调成本同时下降——那些"知道该修但一直修不动"的系统性缺陷，终于有了可行解。
度量：先行指标是控制带被突破到 intent.md 进入分诊队列的时间、已连接仓库中按计划扫描的占比。滞后指标是发现中变成已合并修复的比例、同类事故重复率、多次扫描仓库的每次扫描发现数趋势（这条应该往下走）。
3.7 治理（Governance）
自动化程度再高，人仍然少不了。只是注意力换了对象：从审查代码和缺陷报告，转到 Claude Tag、各种循环和仪表盘上。
原因很实际。只要一个 skill 过期、一个缺陷类别没回流到 CLAUDE.md、某些决策没被抽样，整个结构就会静默退化。没有人会收到告警。
五项措施：
按风险对代码库分层，据此决定自动化程度。 shadow mode——新的审查者先只发意见、由人批准，还要接受红队攻击（试着往里塞恶意变更），直到赢得信任。 对所有自动化批准按比例人工复核。 盯住生命体征：一个汇总每道安全流程与工作流关键指标的仪表盘。 把每个 agent 动作路由进 SIEM——每次自动批准、工具调用、agent 间消息，连同它依据的信号一起记录。任何决策事后可归因、可审计。团队把这当成一种新型内部威胁来处理，行为偏离基线就告警。
第四部分 控制体系：三层防线与一个身份模型
把两篇里的控制手段横着摊开看，会发现它们不是一堆并列的工具，而是三层，底下还压着一个地基。
4.1 第一层：建议性控制
这一层的共同点是全部为版本控制的配置，由 code owner 像审代码一样评审。策略集中改一处，随会话自动生效。
它更像写在墙上的规矩，不是门锁。原文的措辞是"提高智能体应用策略的概率"，不保证。
4.2 第二层：确定性控制
这层的作用是让违规近乎不可能。原文那句值得直接背下来：skills 让违规罕见，hooks 让违规近乎不可能。
推论只有一条：凡是"必须无例外成立"的策略，一定要有确定性层兜底。只挂 skills 的规则，本质上是一份建议。
4.3 第三层：人类门禁
原则两条。agent 可以行动到生产门禁为止，不能越过；写代码的 agent 无权批准自己的产出，职责分离必须保留。
人的位置不是固定的。代码库性质不同，人该站哪个环节也不同——风险分层存在的意义就在这里。
4.4 地基：agent identity 与 Principle of Least Agency
四件事。
每个 agent 一个单一用途身份，只给完成这份工作所需的最小权限。 agent 要协作，就走跟人类相同的渠道（比如公司的聊天工具），复用同一套身份、审计和门禁。 agent 之间的调用关系必须显式建模。它本身就是攻击面。 所有动作进 SIEM，按内部威胁的思路做行为基线。
第五部分 度量：双维度指标体系
两篇的度量口径互补：流程手册盯交付效率和返工，安全复盘盯风险捕获。
必须一起看。只看效率，速度指标会把风险盖住——PR 周转快了，没人注意缺陷是从生产环境回来的。只看安全，"风险高"又成了什么都能解释的借口。
表里有一行值得单说。要求 agent 为每个发现附证明，噪音比会掉下来：带实质性评论的 PR 从 16% 涨到 54%，同时误报变少。这类同时改善两端的手段不多。
第六部分 两篇文章的差异、张力与调和
两篇不是互相抄的，也没必要装成完全一致。六处最好分开看，先给对照表：
6.1 定位不同：架构蓝图 vs 风控复盘
流程手册是写给外部企业的通用方法论。里面有遗留系统适配的三种配法——把工单系统、服务台、设计工具分别当真源——还有模块化的 play 清单和一张采纳依赖图。
安全复盘是 Anthropic 自己的实战自述。它依赖的工具链不具备通用性：Claude Tag、内部知识索引、统一低代码平台，外面拿不到同款。
一句话：前者可迁移，后者可信，但移植时要小心。
6.2 分歧一：硬门禁该放在哪
流程手册的主张很明确：请求人类批准的 hooks 属于部署阶段。构建期间弹批准，等于把人重新放回所有并行会话的关键路径上。硬门禁应该压在发布那一刻。
安全复盘的说法不同：部分客户把提交前自查和工具调用前的拦截做成更硬的关卡，"这也有效"，但 Anthropic 自己选择把硬性代码审查门禁放在测试与集成阶段。
怎么调和。 两边说的不是同一个对象。流程手册拦的是发布授权，安全复盘拦的是代码审查结论。真正的共同原则是：门禁要放在"人不必逐条盯、但必须签字"的位置。代码级审查交给集成环节里的多智能体验证加分层次抽样，发布级授权交给部署环节的具名批准。两个叠起来才是完整答案。
6.3 分歧二：文档还值不值得写
这一处最需要调和。
流程手册把整条流水线建在书面产物上——意图、规格、计划三份文件。安全复盘却说：详细的架构文档不再关键，因为几小时就能出好几个原型；更有效的做法是让 agent 去上下文已经存在的地方取。
怎么调和。 反对的也不是同一件事。安全复盘反对的是"周期被压缩之后仍然强推传统长篇设计文档"。
流程手册那套产物是什么？轻量、可执行、版本化的决策记录。它只干两件事：把意图固化成下一阶段能读的输入，留下审计轨迹。描述系统不在它的任务里。
换句话说，文档从"设计说明书"变成了"决策日志"。这也解释了它为什么要求产物短——CLAUDE.md 控制在一页内，规格要紧凑。它本来就不是让人写长篇的地方。
6.4 张力三：对自主程度的乐观度不同
流程手册描述的是目标态：auto mode 默认接受、运维阶段无人介入就能触发、闭环自我喂养。
安全复盘描述的是当下的现实控制：人类问责居核心、抽样复核、shadow mode、每次批准留痕。
这不算矛盾，是同一件事的两个时间切片。安全复盘其实给流程手册的乐观愿景加了三道保险——shadow mode 回答"新审查者凭什么被信任"，抽样回答"自动化久了会不会漂移"，SIEM 回答"出了事能不能归因"。缺了这三道，auto mode 就是裸奔。
6.5 张力四：成本几乎没被讨论
流程手册通篇几乎不提钱。安全复盘明确点出：多数扫描方式，不管 agentic 还是确定性，都按用量计费；成本随代码吞吐量线性上升，覆盖到什么水平得团队自己定。
Anthropic 的选择是接受成本随速度增长，但预期单位成本会下降。
这条差异其实很关键。流程手册回答的是"如果几乎免费你会做什么"，安全复盘回答的是"现在账单多少钱"。落地时两个都得看。
第七部分 落地路线图
把两篇的采纳顺序和"分层控制"合起来，能排出一个推进次序。
核心原则一句话：从没有依赖的动作起步，先把反馈回路建好，再谈并行和自主。反过来做，大概率会在第一个月就卡死。
第 0–1 个月：打地基（几乎零成本）
建 CLAUDE.md。用初始化命令生成初稿后精简到一页，然后立一条团队纪律：同一个错误犯两次就写进去。 让智能体开 PR 前跑安全自查，把安全规则从内部维基搬到 CLAUDE.md 或 skills 里。 统一验证入口。一条命令跑完测试，失败非零退出，写进 CLAUDE.md 的命令段。 要求智能体为每个安全发现附 proof of validity。性价比最高的一条，几乎不花成本。 每次批准留痕：谁批的、依据哪些信号。
第 2–4 个月：上产物链与门禁
引入意图、规格、计划三件套，配一个组织级的快捷命令。 把 plan mode 设成默认起点，养成"盘问计划"的习惯。 把必须一致应用的策略写成 skills，同时明确它的建议性定位——别指望它能拦住什么。 建第一批 hooks：保护生成代码与冻结包、编辑后跑格式化工具、凭据不进入改动。 建 20 到 50 条 eval 用例，配置变更时跑，每日定时也跑。
第 5–8 个月：扩展审查与身份治理
上多智能体窄焦点评审，配 REVIEW.md 定义轮次与噪音上限。 做代码库风险分层，明确哪些路径必须人工批准。 建智能体身份模型：单一用途账户加最小权限，分诊和修复分开。 开发环境迁到远程虚拟机，加出口白名单。防提示注入外泄，这是最硬的一招。 所有智能体动作路由进 SIEM，按内部威胁做基线。
第 9–12 个月：走向闭环
上预发环境的持续动态扫描。 建 control band（一、二、三个标准差的响应层级）和确定性检测脚本，先用两倍标准差只读诊断跑一段时间。 给新审查者上 shadow mode，红队验证过再放权。 把定期代码库扫描排进计划任务，发现走同一套门禁。 演练回滚路径。闭环一旦启用，它是最后一道保险。
第八部分 结论
一、瓶颈已经迁移。 编码不再是稀缺资源，判断和验证才是。任何只优化"写代码"的改造，都会在审查和发布处撞墙。
二、抓手是"控制目标不变、执行方式改变"。 这条命题同时满足工程效率和合规要求，也是两篇文章能拼到一起的根本原因。
三、控制必须分层。 建议性让违规罕见，确定性让违规近乎不可能，人类门禁承担最终责任。少一层，结构就会在某个角落静默失效。
四、边界划在"访问与动作"上。 那条聊天工具事件的教训适用于所有做智能体的团队：别问模型能做什么，问这个账户能碰到什么。智能体之间的调用关系，是攻击面的一部分。
五、安全工程师从监控缺陷转向监控循环。 指标、仪表盘、抽样、行为基线，成了新的日常工作对象。
六、为成本下降做规划，别为当前成本做妥协。 安全复盘结尾那个提问方式值得抄：你们团队该问的不是"我们负担得起扫描一切吗"，而是"如果扫描几乎免费，我们会运行什么"，然后照那个去规划。
七、人的位置没消失，只是上移了。 从逐行读代码改动，上移到判断意图、裁决 flagged concerns、签字放行。用流程手册的收尾句收尾：
The loop keeps running. Human judgement stays above it.回路持续运行，人类判断在其之上。
附录 术语表与出处
原文出处：
Louis Claxton, The AI-native SDLC playbook, Anthropic, 2026-08-21.
https://claude.com/resources/articles/the-ai-native-sdlc-playbook
Jason Clinton, How Anthropic secures its AI-native software development lifecycle, Anthropic, 2026-07-21.
https://claude.com/resources/articles/how-anthropic-secures-its-ai-native-software-development-lifecycle
关联阅读：Zero Trust for Agents、agent identity models、CISO's guide to agentic AI、running an AI-native engineering org。
