《The AI-Native SDLC Playbook》万字拆解

第 0 章：开始之前

这一章是给「没写过代码、没用过 git」的读者的如果你是工程师，可以直接跳到第 1 章

第 0.1 节：预备知识

软件团队的日常协作方式，和「多人共同编辑一份超大的共享文档」非常像。用这个类比，六个词一次讲清：

仓库（repo）和 git 。可以把全组的代码想成一个共享文件夹，git 是管理这个文件夹的工具。它最重要的作用是记录每一次提交：谁改的、什么时候改的、改了哪几行、为什么改，都会留下记录，需要时也能恢复到以前的版本。所以工程师说「进了 git」「在版本库里」，意思是这份内容从此有记录可查。
提交（commit）。在共享文件夹里的一次「保存并署名」。每次提交都附一句说明（比如「加了理赔状态查询接口」）。类比：在线文档的版本历史里的一个存档点，但每个存档点都有作者和留言。
PR（Pull Request，可以理解成「改动申请单」） 。受保护的正式分支不允许直接修改。你要先在自己的分支里改好，然后发一张申请单：「我改了这几处，改动内容如下，请过目。」别人逐条查看改动并提出意见，这个过程叫评审（review） ；意见处理完、有权限的人同意后，改动才会并入正式版，这一步叫合并（merge）。
CI（自动检查流水线）。每当有人发出改动申请单，一台机器会自动把改动拿去跑一遍检查：程序还能不能正常构建？已有的测试还全过吗？像一个自动查作业的机器人，几分钟出结果。CI 是 Continuous Integration（持续集成）的缩写，日常口语里就是「自动检查」。
分支保护（branch protection）。给正式版上的锁：没有任何人（包括 AI）能绕过申请单和审批直接修改正式版。这是代码平台（比如 GitHub）提供的强制规则，不是靠自觉。
编码 agent（比如 Claude Code） 。它不是只能对话的聊天机器人，而是能自己读代码、改文件、跑命令、查看运行结果的 AI 程序。你给它一个任务，它会像工程师一样在仓库里完成工作，再把改动整理出来交给人检查。本文里的 agent 都指这类程序。

把六个词串起来，就是软件团队日常工作的基本流程：大家在仓库里各自工作，改完后提交，再发起一张改动申请单（PR） 。CI 先自动检查，同事再评审并提出意见；全部通过后，改动才会合并进正式版。分支保护保证任何人都不能跳过这套流程。

这篇文章讨论的，就是 agent 参与开发后，这套流程应该怎样调整。

第 0.2 节：原文是什么

这是 Anthropic（Claude 的出品公司）应用 AI 团队写的一份实操手册（playbook），2026 年 8 月发表，面向企业工程团队。

背景是：过去一年多，用 AI 写代码的速度提升得非常快，但围绕代码的流程 ------ 需求怎么提、方案怎么审、代码怎么验、什么时候能上线 ------ 基本没变。

文章要回答的问题是：流程该怎么跟着改，才能既拿到 AI 的速度，又不失控。

SDLC（Software Development Lifecycle，软件开发生命周期）是行业通用词，指软件从「有人提出一个想法」到「上线运行、持续维护」的完整过程。

几乎所有公司采用的都是这六个阶段的某种变体：计划（想清楚要做什么）→ 设计（想清楚怎么做）→ 构建（把代码写出来）→ 测试（验证是否做对）→ 部署（发布上线）→ 维护（监控线上运行情况并处理问题）。

传统做法中，每个阶段由不同角色负责：

产品经理写需求
架构师做设计
工程师写代码
测试团队负责验证
发布团队完成上线
运维团队监控生产环境

各阶段通过文档、工单和审批记录完成交接。

文章的核心可以概括为一句话：这套流程里的每一次审批和交接，都是按照「写代码最慢、成本最高」这个前提设计的；现在这个前提已经改变，流程也必须随之调整。

文章给出了 15 个具体做法并称它们为 play，也就是篮球战术手册里的「战术」，这些做法合在一起便称为 playbook。

每个做法都写明了前置条件、具体步骤、示例文件、如何保留可追溯记录，以及配套的先行、滞后两类指标。

第 0.3 节：【加深理解】拿后厨做个比喻

把开发团队想成一家餐厅的后厨。

以前 炒菜（写代码） 是最慢的环节：一道菜要炒几十分钟。

所以点单、配菜、传菜、验菜怎么慢都无所谓，反正都在等炒菜。

现在后厨装上了炒菜机器人，一道菜几十秒出锅------这时你会发现：点单员还在手写菜单（写需求）、传菜员一次只端一盘（交接靠开会）、验菜员坚持每道菜尝一口（逐行人工评审）。

菜出得越快，堵在前后环节的越多。

文章的解法不是取消验菜，而是重新安排整个后厨：

统一菜单格式（把需求写成采用统一模板的文件）
在灶台边放置操作规范（agent 每次工作前必须阅读的规则）
用脚本强制限制危险操作
由 AI 先检查一遍再让人判断关键风险，并让顾客的差评自动变成新菜单（线上发现问题后，自动写成新需求送回队列）

人的职责从「亲手完成每件事」变成「在几个关键环节作决定」。

第 0.4 节：解决什么问题

文章开头列出了三个正在发生的现象，它们都源于「写代码变快了，其他环节没有变化」：

瓶颈移位。 代码几小时就能写完，但需求评审、代码评审、上线审批还是按周运转。队伍不再堵在「等开发」，而是堵在开发的前后两头。
控制手段不再适用。 「每一行代码都由人看过」这条规则，建立在代码原本由人逐行编写的前提上。当 agent 一天就能产出过去一周的代码量时，要么评审队列越来越长，要么代码在检查不充分的情况下上线。这两种结果都不能接受。
处理特批和例外越来越耗时。 特批和例外仍然要等每周或每月开一次的委员会。开发以小时计、审批以周计，差距被放得越来越大。

对策可以概括为一句话：保留原有的控制目标，改用新的控制手段。

必要的审批仍然保留，但从「开会签字」变成「版本库里的一次合并」，谁批准、何时批准都会自动留下记录；必要的规范仍然保留，但从「记在老员工脑子里」变成「agent 每次工作前都会读取的文件」；不可违反的规则也仍然保留，但从「依靠自觉」变成「每次动作前自动运行的检查脚本」。

第 0.5 节：六阶段的变化

阶段	以前怎么干	文章主张怎么干
计划 Plan	想法要排队等产品经理写成需求文档，中间还要经过待办事项整理、用户故事和工作量估算会，传到工程师手里时已经走样	提出想法的人直接和 Claude 交谈，谈完写成 intent.md（意图文件，用一页说明问题、期望结果、涉及对象、约束和疑问），提交进仓库，由产品负责人审核
设计 Design	需求分析和设计由两组人分两个阶段完成，文档来回传递	在一场会话中完成：Claude 读取 intent.md ，按照公司的规范生成 spec.md（规格文件），标出无法满足的要求，由人负责审核
构建 Build	工程师读完设计直接动手，怎么改只在他脑子里；文档事后补	先让 Claude 生成一份书面计划 plan.md（改哪些文件、按什么顺序、怎样证明改对了），人确认后才写代码
测试 Test	测试团队在阶段末尾检查，反馈来得较晚	agent 工作时自行检查（运行测试、执行构建、比较截图），没有通过就继续修改；人看到的结果已经完成基本检查
部署 Deploy	人逐行评审、逐项审批，执行标准容易因人而异	AI 按书面政策对每个 PR 进行标准一致的多轮检查，人只判断「意图是否正确、风险能否接受」；上线流程由脚本暂停，等待发布经理批准
维护 Maintain	告警等人查看，工单等人领取，复盘中确定的行动常常没有后续	脚本监控线上指标，发现异常后自动调用 agent 诊断，诊断结果写成新的 intent.md，回到计划阶段，流程由此首尾相接并持续运行

每个阶段完成后，向仓库中保存一份文件；下一个阶段的人或 agent 读取这份文件后开始工作。 文件代替了会议和口头交接。

第 0.6 节：名词表

前六个是 0.1 介绍过的基础词，其余按正文出现顺序排列。行业通用术语保留英文。

名词	意思
仓库 / git	带完整修改历史的共享代码文件夹及其管理工具；「进 git」= 从此有据可查（见第 0.1 节）
提交（commit）	一次带作者和说明的存档（见第 0.1 节）
PR / 评审 / 合并	改动申请单 / 别人过目提意见 / 并进正式版（见第 0.1 节）
CI	每张申请单都自动跑一遍的机器检查（见第 0.1 节）
分支保护	正式版上锁，谁都不能绕过申请单直接改（见第 0.1 节）
编码 agent	能自己读代码、改文件、跑命令的 AI 程序（见第 0.1 节）
SDLC	软件开发生命周期：从想法到上线运维的完整流程，六阶段（见第 0.2 节）
play / playbook	play 是一个可独立采纳的具体做法；playbook 是这些做法的合集，词源是球队战术手册
产物（artifact）	每个阶段结束时存进仓库的那份文件或记录。上一阶段存文件，下一阶段读文件开工
intent.md	意图文件：问题是什么、期望什么结果、涉及谁、有什么约束、还有什么没想清楚。提出想法的人和 Claude 一起编写
spec.md	规格文件：Claude 根据 intent.md 生成，应用公司规范并标出疑点，供工程团队制订计划
plan.md	实现计划：修改哪些文件、按什么顺序、风险在哪里、怎样证明结果正确。写代码前由工程师认可
CLAUDE.md	放在仓库根目录、agent 每次工作前必须读取的文件：常用命令、团队惯例、架构要点和 agent 经常犯的错误。相当于给新同事的第一天须知
REVIEW.md	评审政策文件：说明 AI 审核 PR 时要检查哪些问题、什么属于严重问题、哪些内容不需要报告
skill	一份写给 agent 的操作指引文件，说明什么时候使用、具体怎样操作。它把「公司的制度知识」写成 agent 可以执行的步骤。属于指导性规则：能提高 agent 正确执行的概率，但不强制
hook	agent 每次执行动作（改文件、运行命令）前自动运行的小脚本，可以放行、询问指定的人或直接拦下。属于强制控制，用来保证关键规则得到执行
subagent（子 agent）	一个 agent 会话内部派出的帮手，干反复出现的活（比如独立验证改动是否可用）
并行会话 / worktree	一个工程师同时开几个互不知情的 agent，各自在仓库的独立副本（worktree）里干不同任务，互不干扰
plan mode	Claude Code 的一种模式：只能读代码不能改，专门用来先产出计划；人接受计划后才允许动手
auto mode	计划被认可后，Claude 逐个改动不再逐次请示。防护规则成熟后，例行工作的默认方式
自检循环（feedback loop）	给 agent 一个自己验证工作的手段（跑测试、跑构建、截图比对），没过自己修
eval	对 agent 配置的「考试」：拿几十个真实任务当考题，CLAUDE.md、skills、hooks 或模型一变就重考，看 agent 是否还能做到原来的水准
MCP	让 agent 以受控方式调用外部系统（部署、查状态、回滚）的协议；agent 能碰什么是一份白名单
managed settings	公司平台团队统一下发、工程师改不掉的配置：权限清单、沙箱、网络和插件白名单、最低版本要求
control band（控制区间）	根据均值和标准差，为线上指标划定正常波动范围。超出范围称为「越界」
σ（sigma）	标准差，用来衡量数据偏离正常水平的程度。文中采用分级响应：越界 1σ 只记录日志，2σ 让 agent 进行只读诊断，3σ 允许 agent 提交 PR 或触发预先批准的回滚
DORA 指标	衡量软件交付水平的四个通用指标（发布频率、从改完到上线的时长、变更失败率、故障恢复时长）
Claude Tag	让 Claude 以自己的身份常驻 Slack 频道，事故消息出现后先由它响应
可追溯记录（audit trail）	能回答「谁提出的要求、agent 做了什么、谁批准的」的完整记录。文章的答案是：阶段产物的提交历史就是可追溯记录
权威记录（source of truth）	同一份信息存在于多个位置时，明确以哪一处为准
runbook	预先写好并批准的操作步骤（如回滚），agent 只能触发已批准的 runbook，不能临场发明操作
回滚（rollback）	上线出问题时，把系统退回上一个正常版本的操作

第 1 章：核心论点 ------ 代码不再是瓶颈

以前六个阶段里「写代码」最慢，所以所有流程都围着它转------就像整个后厨都在等炒菜。

现在写代码所需的时间从几周缩短到几小时，前后仍依靠人工推进的环节就成了新瓶颈。

流程不改，AI 带来的速度提升就会被排队等待抵消。

图 1 · 瓶颈转移

打个比方：高速公路中间一段从两车道扩成八车道，但收费站还是两个窗口。整体通行速度不会因此提高，拥堵只会从路面转移到收费站。

文章列出的三个后果也是如此：瓶颈移到构建前后仍依靠人工的环节；逐行人工评审跟不上 agent 的产出；例外事项仍要等待周会或月会，处理这些事项所需的时间也随之增加。

解决办法不是拆掉收费站，审批仍然需要保留，而是改用新的收费方式：保留控制目标，改变控制手段。

这一判断决定了整份手册的结构：15 个做法里只有一小部分在讲「怎么让 AI 写好代码」，大部分在讲怎么改造构建两侧 ------ 把计划和设计变成小时级、把评审分层、把审批变成可以自动执行的规则。

第 2 章：从直线到循环 ------ 阶段产物形成可追溯记录

六个阶段不再排成一条直线、走完即止，而是首尾相接，持续循环。

各阶段不再主要依靠开会交接，而是依靠一份存进仓库的文件：文件保存后，下一个阶段就能开始。

把这些文件的提交记录连起来，正好可以回答审计关心的三个问题------谁提出了要求、agent 做了什么、谁批准了结果。

先看「文件交接」和「开会交接」有什么不同。

以前产品负责人要把一个需求交给开发团队，至少要开三场同步会：先向分析师说明背景，再和工程师核对方案，最后到评审会上重新讲一遍。

每次转述都可能损失信息，会后各方的理解还可能继续产生偏差。

改成文件交接后，意图文件里写清楚的内容不会因转述而变化；有疑问可以直接在文件上提出，修改完成后，所有人看到的都是同一份版本。信息不再经过多人转述，所有人直接查看同一份文件。

图 2 · AI-native SDLC 的循环与产物链

每条箭头都代表一份存进仓库的文件；上一阶段的提交触发下一阶段，阶段文件的提交记录连起来，就形成了可追溯记录。

这里有三点需要说明：

流程先由人触发，成熟后再逐步自动化。 起步阶段，每一步都需要人提示 agent；流程成熟后，「上一份文件被接受」会自动触发下一步，只有需要审批时才由人参与。
前期产物用文本文件是有意的。 产品负责人和 agent 都能直接读写同一份文件，不需要任何专业工具；从构建阶段起，产物换成代码和它的记录。
不必推翻旧系统。 Jira、需求管理工具和变更委员会都可以继续使用，但每类产物必须指定一处权威记录，其余位置只保存副本或链接；最低要求是两边都记录同一个编号，能够互相对应。

第 3 章：一次需求的完整旅程

拿文章自带的例子讲个故事。

场景是一家保险公司，四个人物：小赵（客服中心主管，不懂技术）、老周（产品负责人）、小李（工程师）、王姐（发布经理）。

看完这个故事，前面所有概念就都串起来了。

先用一段话说清楚以前的做法。 小赵统计发现，客服三分之一的通话都在回答「我的理赔到哪一步了」，她想在客户门户里增加自助查询功能。

她先向老周口头提出需求；老周把需求记入待办事项，排进下一季度规划；两个月后，需求通过评审，分析师编写需求文档，设计师完成设计，小李安排三周开发，测试用一周，评审排队一周，再等待两周发布窗口。

四个多月后，功能终于上线。

但需求在中间转手了五次，上线的版本和小赵最初的想法已经有明显差异：她需要的「预计完成日期」没有实现，因为需求文档漏掉了这一项。

再看文章主张的版本，九步。

小赵和 Claude 讨论想法（半小时）。 她打开对话，用大白话描述：「客户老打电话问理赔进度，占了坐席三分之一的时间，我想让他们在门户里自己查。」Claude 接着问她一些分析师通常会问的问题：哪些人会用？要显示什么信息？有什么不能做的？什么算成功？谈完后，Claude 按公司模板把结果写成一页 intent.md ：问题、期望结果（客户能看到状态、下一步和预计日期------这次需求由她本人确认，关键的「预计日期」不会在转述中被漏掉）、涉及面、约束（不引入新的个人敏感信息）、待澄清事项（第三方定损员要不要也能看？）。小赵检查一遍、修改两处，然后提交进共享仓库。
老周审核并接受（十分钟）。 老周收到通知，打开 intent.md ，确认内容可行后点击合并。这次合并会在系统中留下记录：谁批准的、什么时候批准的。合并这个动作本身就是审批，不需要另外开会。
Claude 生成规格，老周审核（当天）。 intent 被接受后，Claude 自动读取文件，按照公司预先写进 skills 的安全、合规和界面规范生成 spec.md，并标出无法满足的要求。例如，「预计日期」的算法需要理赔系统提供数据，但现有接口没有这个字段。老周先处理这些疑点，找理赔系统负责人确认，然后决定进入开发。
小李用 plan mode 制订计划（一小时）。 小李把 spec.md 交给 Claude Code 的 plan mode，也就是只能读代码、不能修改的模式。Claude 读完仓库后生成 plan.md，说明要改哪三个文件、按什么顺序修改、用什么测试证明结果。小李逐项追问：「这个改动会不会影响旧的查询页？」「理赔系统接口每秒最多接受 50 次请求，你怎么处理？」Claude 随后修订计划并补上缓存方案。小李认可后，提交计划文件。
Claude 完成实现和自检（几小时）。 小李切换到执行模式，Claude 按计划写代码，完成后运行测试，并用截图和设计稿进行比较。如果没有通过，就继续修改，直到全部通过。期间，Claude 试图修改一个被冻结的旧模块，被 hook（动作前自动运行的检查脚本）直接拦下。小李这段时间可以处理另一项任务。
PR 评审：AI 先审，人再审（当天）。 改动通过 PR 提交。AI 按公司的 REVIEW.md 政策进行三类检查：是否存在逻辑错误、是否存在安全问题，以及改动是否与 spec 和 plan 一致。发现的问题会按严重程度列出。小李处理完 AI 的意见后，另一位工程师只需要判断两件事：**这个改动是否就是计划中所说的改动？风险是否可以接受？**不必再从每一行代码开始查找问题。批准后，改动合并。
发布在生产环境审批前暂停，王姐批准（十分钟）。 流水线自动构建、部署到测试环境并完成验证。流程推进到生产发布时，hook 会将其暂停，因为生产上线必须获得发布授权。王姐查看变更说明和检查结果后批准发布，随后上线。
监控脚本接手监控（此后每天）。 一个不包含任何 AI 的确定性脚本持续监控线上指标，例如接口报错率，并根据最近 30 天的正常波动范围划出「控制区间」。轻微异常（1σ）只记录日志；明显异常（2σ）调用 Claude 进行只读诊断；严重异常（3σ）允许 Claude 提交修复 PR 或触发预先批准的回滚。但无论异常处于哪个级别，负责判定异常的都是脚本，不是 AI。
把发现写成新的 intent.md，回到第 1 步。 两周后，脚本发现查询接口在月底对账日会规律性变慢。Claude 完成诊断后，把发现写成一份新的 intent.md，其中包括现象、证据、建议和涉及的系统，再放进待处理队列。老周决定将它排期处理。循环重新开始，只是这一次，连「提出需求」都不再需要由人启动。

除小赵提出并确认需求外，需要人作出批准或风险判断的环节集中在四类位置：老周批准 intent 和 spec（第 2、3 步）、小李认可计划（第 4 步）、同事批准 PR（第 6 步）、王姐批准上线（第 7 步）。其余步骤要么由 agent 完成，要么由脚本作出判定。这就是文章所说的：人的注意力集中在需要批准和判断风险的节点上，评审 agent 标出的问题，而不是在每个阶段都从头开始。

图 3 · 上面九步的泳道图（每行是一个角色，从上往下就是故事的顺序）

第 4 章：六阶段做法逐条解读

这一节逐个说明 15 个做法。

每个做法先用一两句白话说明用途，再介绍细节、如何保留可追溯记录，以及用哪些指标判断是否有效。

第 3 章的故事已经把这些做法连在一起讲过，这里再逐项说明。

想查看原文操作步骤和示例文件，可以通过第 10 章的链接回到原文。

第 4.1 节：Plan------把想法当场写成 intent.md

想法不再排队等人写成需求文档 ------ 提想法的人自己和 Claude 聊，聊完就是一份能用的需求。

以前，一个想法要变成工程师可以执行的需求，必须经过待办事项整理、用户故事、工作量估算会和需求细化会。内容每转交一次，都可能产生偏差，传到工程师手里时已经走样。第 3 章的故事里漏掉「预计日期」，就是一个典型例子。现在，发起人直接和 Claude 对话，Claude 追问分析师通常会问的问题，包括范围、用户、约束和成功标准，再按公司模板写成一页 intent.md，由发起人修正后提交。产品负责人不再替别人编写需求，而是审核已经整理好的需求。

意图文件的内容如下。它只是普通文本，不懂技术的人也能看懂：

markdown 复制代码

# Intent: 理赔状态自助查询
作者：小赵（客服运营）  状态：草稿
## 问题        客户打电话问理赔进度，占了约三分之一的通话时间
## 期望结果    客户在门户里自己看到状态、下一步和预计日期
## 涉及面      理赔坐席、门户团队、claims-core API
## 约束        会话里不引入新的个人敏感信息；只用现有认证
## 待澄清      第三方定损员要不要也能看？

如何保留可追溯记录：文件的提交历史会记录作者、时间和每一版改动；产品负责人的接受或驳回会体现为合并或关闭，同样会留下记录。
如何衡量：查看「从第一次对话到提交文件」的耗时，预期从数周缩短到数小时；查看被接受并进入设计阶段的比例；查看设计开始后意图文件还要修改几次，修改次数多，说明最初讨论得不够清楚。

第 4.2 节：Design------需求和设计合并成一场会话

不再由分析师写完规格后交给设计师重新解释。Claude 在同一轮对话中生成规格，人负责审核，公司规范在生成时就已经应用。

Claude 读取已被接受的 intent.md ，按照公司预先写进 skills 的品牌、安全、合规和界面规范生成 spec.md ，并且必须标出无法满足的要求 ，尤其要指出不同规范相互冲突的地方。例如，「界面要显示完整证件号」就与「敏感信息必须打码」相冲突。过去，这类疑点往往要由资深分析师发现并上报；现在，它们会自动列在文件末尾。产品负责人不负责编写规格，只负责审核：先逐个处理疑点，找相应规范的负责人确认，再决定是否进入开发；风险较高的变更还要请技术负责人共同审核。是否进入开发，始终由人决定。

如何保留可追溯记录：规范在编写规格时就会应用，不必等到几周后的评审才发现违规；规格文件、生成规格的指令和当时生效的规范版本，都可以在仓库中查询。
如何衡量：查看 intent 和 spec 两次提交之间的时间，并与过去「需求+设计」两个阶段的周期比较；查看开发开始后规格还要修改几次。

第 4.3 节：Build------六个做法

这一阶段重点做三件事：先写书面计划再动手；把老员工掌握的知识写成 agent 能读的文件；让脚本自动拦下危险动作。

（1）把 plan mode 作为默认起点。 agent 会话从「只能读、不能改」的 plan mode 开始：把规格文件交给它，让它生成一份计划，说明要修改哪些文件、按什么顺序修改、用什么测试证明结果。工程师逐项追问计划中的风险和取舍：可能破坏什么？哪一步风险最高？放弃了哪些方案？直到「一个没有看过这段对话的工程师，只根据计划也能完成实现」。计划得到认可并存档后，agent 才开始修改。如果实现中途偏离计划，就在同一次提交中同步修改计划，保持两者一致。这样做的价值在于，方案评审发生在写代码之前。这时改变方向只需要修改文档，成本很低；传统流程中的评审者第一次看到的往往已经是成品，返工成本更高。度量：经过一次评审就能合并的改动占比；合并后的代码与计划文件仍然一致的比例。

（2）用 auto mode 处理常规任务。 计划得到认可后，Claude 进行每项修改时不再逐次请示。前提是相关防护措施已经到位：CLAUDE.md 已经完善，规范已经写进 skills，hooks 能够拦下危险动作，测试也可以自动运行。人的工作从「盯着它每一次编辑」变成「审核它完成一段工作后的结果」。它适用于规格清晰、影响范围小、已有测试覆盖的改动。安全限制尚未建立时就开启 auto mode，就像让机器人在没有栏杆的桥上高速行驶。

（3）CLAUDE.md。 这是一份放在仓库根目录、agent 每次工作前必须读取的文件，内容包括新同事第一天需要知道的事项：如何运行常用命令、团队采用哪些惯例、系统架构是什么样、agent 经常犯哪些错误。有一条很实用的维护规则：同一个错误第二次出现时，就把纠正方法写进这个文件。后续所有会话都会读到这条说明。全文应控制在一页以内，并及时删除过期内容，因为 agent 每次都会读取全文，无关内容会挤占上下文空间。度量：本应通过这个文件避免的错误是否复发；新成员多久能交出第一个合并的改动。

（4）用 skills 保存制度知识。 把「必须由所有人一致执行的公司知识」，例如安全标准、接口设计惯例和品牌规则，写成一份份带有触发条件的指引文件。政策变化时，只需要修改相应文件，所有人的 agent 下次工作时就会读取新版，不必分别通知和培训每个人，也不必等待大家逐渐养成习惯。但要记住，skill 只是「指导性规则」：它能提高 agent 照做的概率，却不能保证每次都得到遵守。必须始终成立的规则，还要由 hook 强制执行或由评审确认。度量：从政策更新到指引文件生效经过了多长时间；评审中还会发现多少违反该政策的问题，这个数字应逐渐接近零。

（5）用 hooks 强制执行防护规则。 skill 像贴在灶台边的操作规范，hook 则像燃气灶的自动熄火装置：前者依靠 agent 遵守，后者由程序强制执行。hook 是 agent 每次动作前自动运行的小脚本，可以拦住对受保护文件的修改、在修改后自动运行格式检查，并防止密码和密钥进入改动。hook 必须运行得快，并且只检查发生变化的部分；耗时较长的检查应放到 PR 环节。需要人批准的 hook 不应放在构建阶段，否则一次「请示」就会让所有并行工作的 agent 同时等待。度量：每次拦截都带时间戳留痕，事后可查。

（6）并行会话与子 agent。 一位工程师可以同时开启两三个 agent，让它们各自在仓库的独立副本中完成互不相关的任务。这就像一个人同时照看三口锅：机器人负责炒菜，人负责尝味和判断结果。反复出现的任务，例如验证改动、简化代码和研究代码库，可以做成「子 agent」供全组使用。并发上限不取决于机器数量，而取决于这个人能够认真评审多少路输出。如果已经无法认真评审，就不应继续增加并发任务。度量：在评审质量不下降的前提下，人均可以同时处理多少个任务；人均每周合并多少项改动。后一个数字需要和返工率一起看，不能只看速度。

补充：旧系统怎么办。 Jira、需求工具、Figma 和变更委员会不会消失，审计和监管体系也已经认可它们。可以按顺序考虑三种共存方式：以仓库为准，旧系统只保存链接；以旧系统为准，agent 工作前读取其中的记录，完成后再写回；至少保证两边都记录同一个编号，能够互相对应。转型初期可以先让两边记录同一个编号，但要清楚，这是「两个位置都可作为依据」的过渡状态，最终仍要明确一处权威记录。

第 4.4 节：Test------两个做法

agent 提交结果前必须完成自检；「指导 agent 工作的配置文件」本身也要接受测试，一旦改坏就能及时发现。

（1）让每个会话都能自检。 始终给 Claude 一种自行验证工作结果的方法：提供一条命令即可完成的测试和构建；处理界面任务时，提供浏览器或截图工具，让它自行与设计稿比较。目标必须写成可以判断是否完成的形式，例如「四种理赔状态的测试全部通过」，而不是「做得更好一点」。修复 bug 时，可以先让它把 bug 复现成一个会失败的测试 并保存，确认测试确实因为预期原因失败，然后才允许它修改代码，同时用 hook 禁止它修改测试文件。一个在修复前就已存在、而且 agent 无法修改的测试，可以更可靠地证明 bug 已经修复，否则 agent 可能只是放宽测试条件来让测试「通过」。报告完成前，必须附上测试运行的原始输出。度量：agent 改动在 CI 中一次通过的比例；每个 PR 的人工评审耗时。测试提前发现过去依靠人工评审发现的问题后，后一个数字应该下降。

（2）把 eval 纳入 CI（测试配置是否有效）。 CLAUDE.md、skills 和 hooks 等文件会影响 agent 的工作方式，它们被改坏的后果不亚于代码出错，但传统流程很少测试这些文件。具体做法是：收集 20--50 个近期的真实任务作为测试用例，每个用例都附上「怎样才算做对」的判断标准。只要这些配置发生变化，或者团队更换了模型，就自动重新测试；如果通过率下降，改动暂时不能合并。每次线上事故都补充一个测试用例，让同类问题从此得到固定的回归保护。度量：通过率的变化趋势；一次事故需要多长时间才能变成固定回归测试；CI 提前发现的配置效果下降次数，与进入生产环境后才发现的配置效果下降次数。

第 4.5 节：Deploy------四个做法

AI 先按相同标准对每个 PR 进行多类检查，人只判断「改动是否符合计划、风险是否可以接受」；上线前的最后一次批准始终由身份明确的人作出。

（1）让 AI 参与 PR 评审。 以前，评审质量会受到评审者当天精力和工作量的影响；现在，所有 PR 都会按相同标准接受多类检查。检查内容写在 REVIEW.md 中：检查逻辑错误、检查安全问题、检查改动是否与规格和计划一致。什么算严重问题、琐碎问题最多报告几条、哪些内容不用报告，例如自动生成的文件，也都有明确规定。AI 的发现不能批准或否决 PR，批准始终由人作出 。评审中第二次出现同类错误时，就把纠正方法写进 CLAUDE.md；从下一个 PR 起，agent 都会读到这条纠正说明。作者还可以在评审意见里点名 Claude 进行修改（@claude），修改完成后自动提交到该 PR；提问和回答都会保留在 PR 记录中。度量：从提出 PR 到收到第一条评审意见需要等待多长时间，这个时间应缩短到分钟级；合并前发现的缺陷数量，与进入生产环境后才暴露的缺陷数量。

（2）用 hooks 实现强制审批。 构建阶段的 hook 只会「放行」或「拦下」，部署阶段的 hook 还可以「询问」：暂停动作，等待指定的人批准后再继续。公司先列出必须保留的人工审批，例如变更签核、发布授权，以及修改某些目录前必须有对应工单，再由平台工程师逐条写成 hook。团队规则写入仓库配置；必须统一执行的规则写入公司统一配置，个人无法关闭。动作被拦下时，系统必须告诉 agent 原因以及应该向谁申请。度量：每个审批节点平均需要等待多长时间。等待过久，说明审批节点过多，或者审批人已经成为瓶颈；比较采用这种方式前后的上线违规次数。

（3）managed settings（公司统一配置）。 前面的规则都在「项目」层面，这一项则属于「公司」层面：平台团队统一下发一整套限制，工程师无法自行修改。例如，agent 不得读取密钥文件、不得随意联网、只能安装公司批准的插件，版本低于要求时不得启动。它类似公司发放的工作电脑，能够安装什么、连接什么网络，由 IT 部门决定。原文强调，这份配置应按实际需要裁剪，不能照搬：每增加一项限制，都会牺牲一部分能力，具体尺度取决于仓库中的数据有多敏感。

（4）CI/CD 集成（让 agent 进入流水线）。 流水线中有些步骤需要作出判断，以前只能等待人来处理：构建失败后由谁查看日志？这个测试是真的失败，还是偶发不稳定？变更说明由谁编写？现在可以让 Claude 在流水线中无人值守地运行。先让它完成只读任务，例如分析失败原因和编写摘要；流程成熟后，再授予它写入权限。但所有写操作都必须通过 PR 提交并接受正常评审，agent 不能直接修改正式版本。部署、查询状态和回滚应做成按环境分级的白名单工具：开发环境允许自动部署，生产环境只能准备部署并等待人工批准。总原则是：agent 可以完成生产审批之前的所有工作，但不能绕过审批。 回滚必须在流水线中反复演练，因为第 6 阶段的自动响应会用到它，不能等真正需要回滚时才发现脚本无法运行。度量：流水线故障中，有多少比例不需要呼叫人工就能完成分析和分类处理；DORA 四项。

第 4.6 节：Maintain------自动循环

前五个阶段仍要由人「启动」，这一阶段连启动也实现了自动化。线上出现异常后，由脚本发现问题、agent 完成诊断并写成新需求放入队列，人只负责决定立即修复、排期处理还是驳回。

具体机制写在下面这份配置文件中：

yaml 复制代码

# bands.yaml ------ 给「CI 测试失败率」这个指标划定控制区间，并分级响应
metric: ci_test_failure_rate
baseline: rolling_30d          # 基线：最近 30 天的正常波动范围
rules: western_electric        # 判定规则：既抓突然飙升，也抓缓慢变坏
tiers:
  1sigma: { action: log }                          # 轻微偏离：只记日志
  2sigma: { action: diagnose,                      # 明显偏离：agent 只读诊断
            tools: "Read,Grep,Bash(gh run view *)" }
  3sigma: { action: propose,                       # 严重偏离：只许提 PR，
            routes: [pull_request, runbook:rollback-deploy] }  # 或触发已批准的回滚

判定异常的始终是脚本，不是 AI。 这个脚本是普通程序，受版本管理，也有测试，因此行为可以预测。AI 只会在脚本判定指标越界后被调用，而且异常级别决定它可以做什么：2σ 时只能查看信息，不能修改；3σ 时也只能「提交 PR 并接受评审」或「触发预先批准的回滚」，没有其他路径。
agent 的诊断会写成 intent.md，内容包括现象、证据、建议、涉及的系统和待澄清事项，格式与第 1 阶段小赵使用的文件完全相同，后续也遵循正常流程。人不必再「半夜起床处理告警」，而是在白天查看待处理队列，决定立即修复、排期处理或驳回。驳回结果还可以用于调整控制区间，减少误报。
Claude Tag 处理另一类问题来源。 并非所有问题都来自监控，也可能来自晚上十点 Slack 事故频道里的一条「线上挂了！」。Claude Tag 让 Claude 以自己的身份常驻频道，在事故出现后先负责响应：先诊断并贴出证据，频道中的人可以随时让它验证假设；确认指标恢复后，它会在线程中报告结果，并把复盘写进仓库的经验文件。小问题直接提交 PR 并接受评审，大问题写成 intent.md，进入待处理队列。整个过程都会保留在频道中，频道记录本身就是可追溯记录。
度量：从指标越界到新的 intent 进入队列需要多长时间，并与过去从事故发生到形成复盘行动的时间比较；自动发现的问题中，有多少最终形成并合并了修复；同类事故的复发率，这个数字应随着回归测试用例的积累而下降。

第 5 章：三层控制模型

15 个做法采用的控制方式，可以归纳为同一个三层结构。

用公司报销作比方：

报销制度文件，依靠员工自觉遵守；
报销系统中的强制规则，超出额度就无法提交；
规则的管理权限，只有财务部门能够修改，普通员工无法接触。

人工审批不属于这三层；人只负责决定「是否批准这张单」。

层	手段	报销类比	说明
第 1 层 · 指导	CLAUDE.md · skills	制度文件	写给 agent 的惯例和政策，提高它正确执行的概率；不强制，可能没有触发或没有遵守
第 2 层 · 强制	hooks（防护 + 审批）	系统里超额提交不了	每个动作前自动运行的脚本：放行 / 询问指定的人 / 拦下；必须始终成立的规矩放这层
第 3 层 · 组织	managed settings	规则只有财务能改	公司统一下发：权限清单、沙箱、网络和插件白名单、版本下限；工程师改不掉

自上而下，约束强度逐渐增加，能够修改规则的人逐渐减少：skill 负责提示，hook 负责强制执行；项目成员不应修改的规则，再由组织级配置锁定。

人负责什么：审批阶段产物，包括 intent、spec、plan 和 PR；批准生产发布，只有发布经理同意后才能上线；处理维护阶段自动发现的问题，决定立即修复、排期处理还是驳回。

两条贯穿全文的设计原则，也是这份手册最重要的两条原则：

判定用脚本，诊断才用模型。 「出没出问题」由确定性程序说了算，AI 只负责「问题是什么、怎么办」。
写代码的 agent 没有任何途径批准自己的代码。 批准权限始终受到分支保护规则控制，而且只能由人行使。

一种错误做法：在构建阶段加入人工审批。一次「请示」会同时暂停所有并行工作的 agent。人工审批应集中放在部署阶段的审批节点。

第 6 章：采纳顺序与依赖

15 个做法不需要同时采用，也不应该同时采用。

文章写明了每个做法的前置条件：其中五项不需要任何前置条件，今天就能开始；第二批建立在第一批的基础上；最后才采用自动化程度最高的一批。顺序不对很容易出问题，最典型的情况就是防护措施尚未建立，便直接开启 auto mode。

批次	内容	特征
第一批 · 无需前置条件，今天就能开始	intent.md 模板 + 共享存放处；CLAUDE.md（生成后裁剪）；第一个 skill（选择一条执行最不一致的政策）；第一个 hook（选择一条必须始终执行的规则）；自检循环（用一条命令运行测试和构建）	全是文件和脚本，不改变组织流程，试错成本低
第二批 · 建立在第一批之上	spec.md 生成（要 intent + skills）；plan mode 常态化；并行会话（要 CLAUDE.md + 自检循环）；eval 进 CI；AI PR 评审 + REVIEW.md；审批 hooks	开始改评审和交接的方式，需要团队共识
第三批 · 自动化（检查与审批机制必须已经建立）	在流水线中无人值守地运行 agent（评审和审批机制必须到位）；向全公司下发 managed settings；监控指标越界后自动诊断并重新启动流程（回滚必须已经演练）；由 Claude Tag 值守事故频道	人工只负责处理待办问题和批准上线

原文的原则是：「用自动化加速任何事情之前，必须先建立检查和审批机制。」 先把审批与强制检查建好，再用自动化提速。

第 7 章：度量指标汇总

怎样判断这套方法是否真的有效，而不只是感觉有效？要看数字。

这份手册与一般宣传稿不同的地方在于，每个做法都配有可以直接从 git、PR 和 CI 中读取的先行、滞后两类指标。

「先行指标」可以立即测量，用来观察趋势；
「滞后指标」需要积累一段时间，用来判断最终结果。

采用任何做法之前，都要先记录相应指标的当前值。没有对照，之后的判断就只能依靠感觉。

做法	先行指标	滞后指标
intent.md	首次对话到提交的耗时	被接受进设计的比例；spec 之后 intent 回改次数
spec.md	intent 到 spec 两次提交的间隔	构建开始后的需求返工次数
plan mode	一次评审即可合并的比例；从计划获得认可到代码合并的时长	每次变更的返工轮数；代码与 plan.md 的一致率
CLAUDE.md	本应通过这个文件避免的错误是否复发	新成员到第一个合并 PR 的时间
skills	政策更新到 skill 合并的时长	评审中发现的、违反该政策的问题数（应趋零）
并行会话	评审质量不降时的人均并发数	人均每周合并数，对照返工率读
自检循环	agent 改动的 CI 一次通过率	每 PR 评审耗时；变更失败率
eval 进 CI	通过率趋势；事故转化为固定回归测试用例所需的时间	CI 提前发现的配置效果下降，与进入生产环境后才发现的配置效果下降
AI PR 评审	首次评审等待时间；不需要作者手动修改、可由 Claude 直接解决的评审意见比例	合并前发现的缺陷，与进入生产环境后才暴露的缺陷
审批 hooks	每个审批节点的等待时长	采用审批 hooks 前后，进入生产环境的违规次数对比
CI/CD 集成	不需要呼叫人工便可完成分析和分类处理的流水线故障比例	DORA 四项
自动循环	从指标越界到 intent.md 进入队列的时长	自动发现的问题最终形成并合并修复的比例；同类事故复发率

第 8 章：我们团队已经做到哪一步

这一节是笔者所在团队的一些情况，不是原文内容。

文章第一、二批的做法，我们大多已经有相应做法，只是名称不同。

差距主要集中在第三批：我们还没有配置回归测试、公司级强制配置，也没有让监控结果自动写回需求。

文章的做法	我们	对应现状
intent/spec/plan 产物链	已有	GitHub Issue 记录工作项，方案写入 docs/specs/ 和 docs/baseline/，team-flow 第 2 步要求「先确认方案再动手」。差别在于：权威记录保存在 Issue 和 baseline 中，而不是单独的 intent.md 文件。这属于原文所说的「由旧系统保存权威记录」
CLAUDE.md	已有	AGENTS.md 采用全局、项目、目录三级分层，并通过 git 评审
skills 保存制度知识	已有	以 ae- 开头的系列技能覆盖需求、架构、拆分、验收、运维；命名与注释规范也是 skill
hooks 防护 + 审批	已有	before-action hook 会拦截可能写入主分支的 push；提交 PR 前，系统会要求确认此次改动是否影响 baseline；本机另有 git-push-guard。目前覆盖范围还窄：凭据自检仍需手动启用
自检循环	已有	scripts/check.sh --base origin/main 加上与改动直接相关的测试，是 PR 前必须完成的检查
AI PR 评审 + REVIEW.md	部分	团队约定由未参与实现的人使用 Codex 独立评审，并固定待审代码版本。目前没有 REVIEW.md 这样的书面评审政策文件，每次评审仍依靠团队约定，缺少统一的书面标准
eval 进 CI	没有	AGENTS.md、skills、hooks 的变更没有任何回归测试，改坏了只能靠人事后发现
managed settings	没有	各人自行管理机器；必须遵守的规则目前只写在文档中（AGENTS.md 第 3 条），而不是由程序强制执行
监控自动写回需求	后续	SA（异步分析提案）和 SRH（响应执行）的规划方向与此一致；但我们自己的研发流程目前完全没有这项能力

我们的产品本身，包括身份管理、策略执行和证据生成，做的正是文章第 5、6 阶段针对 agent 的管理工作。

文章讨论「怎样管理写代码的 agent」，我们则在做「怎样管理生产环境中运行业务的 agent」。

两者要解决的问题相同：由确定性程序作出判定，按风险分级授权，并用过程记录满足审计要求。

第 9 章：审慎评价的一些内容

这是厂商围绕自家产品编写的最佳实践。其中不少方法写得具体，也很有参考价值，但阅读时要分清哪些原则可以独立采用，哪些内容是在推广 Claude 产品。

厂商视角贯穿全文。 Code Review、Claude Tag、Cowork 和 Claude Design 都是 Anthropic 自家的产品，其中一些仍处于 beta 阶段。但文章的核心方法------产物链、三层控制、确定性检测和分级授权------不依赖具体厂商，换成其他 agent 也同样适用。
度量指标要求现有记录完整、规范、方便查询。 十几个指标都假设 PR 记录、git 历史和 CI 日志可以被完整查询。多数组织首先要做的不是计算指标，而是整理好这些现有记录。
「人只判断意图与风险」的前提是前面的测试和强制检查足够可靠。 文章自己承认 skill 属于指导性控制，会话可能不遵守；分层评审之所以能够成立，是因为测试、eval 和 hook 等基础措施已经真正建立。如果跳过这些基础检查，直接省掉逐行评审，风险会很高。
目标读者是大企业的平台团队。 受监管行业的示例，例如保险理赔，以及 managed settings、变更委员会兼容方案，都说明了这一点。小团队可以先采用第 6 章的第一、二批做法；第三批需要组织层面的投入，未必划算。
最值得直接采用的两条原则：「判定用确定性脚本，模型只做诊断和提议」和「写代码的 agent 没有途径批准自己的代码」。这两条原则与工具无关，也是这份手册中最有普遍价值的内容。

第 10 章：来源

原文：The AI-Native SDLC Playbook，Anthropic 官方博客，2026-08-21。本文所有「文章说 / 原文」均指它；第 8 章、第 9 章为解读者观点；第 3 章的人物为讲解虚构，情节对应原文的理赔示例与各做法步骤。
原稿所在目录另有《AI-Native-SDLC-Playbook-原文逐节要点-2026-08-24.md》：按原文章节顺序的逐节要点，查证细节用。
原文引用的产品文档：plan mode / hooks / skills / sub-agents / worktrees / settings / MCP 见 code.claude.com/docs。

整理与解读：threerocks、刘多肉