夜雨聆风大家好，我是鲁工。
今早我在一个临时目录里放了一个10行的shell脚本，用claude -p起了一个worker，让它执行 ./deploy.sh production。它回来报告说脚本一次都没有运行，收到的报错信息如下：
PreToolUse:Bash hook error: [${CLAUDE_PROJECT_DIR}/.claude/hooks/production-gate.sh]: Production deploys need a release authorization.它在报告末尾还补了一句：我没有尝试设置RELEASE_APPROVAL或以其他方式绕过授权，这是部署授权的门禁，是否放行应由你决定。
这个shell脚本，来自Anthropic上周五在Claude Blog上发布的一篇技术长文，The AI-Native SDLC playbook，全都是干货。内容上他们的Applied AI团队把给企业客户做落地时的做法整理成了一本手册，按软件开发生命周期的六个阶段排开，每个阶段两三个play，每个play都按同一个格式写：传统做法、AI-native做法、前置条件、执行步骤、一份能直接copy的配置样例、治理考量、用什么指标衡量效果。
原文地址：
https://claude.com/blog/the-ai-native-sdlc-playbook
先说这本手册的立论。传统的软件开发生命周期（Software Development Lifecycle，SDLC） 一般包括六个阶段，计划、设计、构建、测试、部署、维护，每个阶段有相应固定的角色，靠文档、工单和签字等开发合规流程往下传递。这套流程是为写代码最贵最慢的年代设计的，PRD、工时评估、安全评审这些流程，本来是为了在长达数月的开发期里强行对齐。现在Agent把构建这一段压缩到小时级，而对应瓶颈转移到构建的左右两边，计划、评审、部署还是人的速度；逐行看代码这种古法手段，在AI Coding时代明显不合时宜了。Agent把代码产量放大数倍之后，要么待人工评审等任务堆积如山，要么就是代码没审够就匆忙上线。
这个手册的思路是把旧的控制目标留下来，换一套执行手段，线性流程改成循环。贯穿六个阶段的是一条artifact链，计划阶段产出intent.md，设计阶段产出spec.md，构建阶段先出plan.md再出diff和测试，部署阶段是带评审记录的PR，维护阶段是事故记录，事故记录再写成新的intent.md回到计划阶段。每个阶段以提交一个文件到版本控制收尾，下一个阶段以读取它开始，commit链就是审计轨迹。下面我们按照这六个阶段过一遍。
01 计划：把想法写成intent.md
这一步面向的不是程序员和工程师（当然，现在开发与非开发的岗位界限在逐渐模糊）。有想法的人直接跟Claude聊，Claude像专业的产品专家一样追问范围、用户、约束和成功标准，然后按组织的模板写成一份proto-spec，提出者改掉理解偏差后提交到一个共享的intent目录，甚至不需要懂git，用GitHub connector让Claude代为提交就行。
文中给出了一家保险公司的理赔运营案例：客户打电话问理赔进度，大约三分之一的通话时间耗在纯状态查询上，期望是客户在门户里自己看到状态和预计日期，约束是门户会话不新增PII（个人身份信息），开放问题是第三方定损员要不要访问。传统流程里同样一个想法要经过backlog、user story、估点、refinement会议，每次转手换一个人，需求到真正干活的工程师那里可能已经跑偏了。
# Intent: claims status self-serviceAuthor: J. Ortiz (claims operations). Status: draft.## ProblemCustomers phone the contact center to ask where their claim is.Handlers spend roughly a third of call time on status-only queries.## Proposed outcomeCustomers see claim status, next step and expected date in the portal.## Affected users and systemsClaims handlers, portal team, claims-core API.## ConstraintsNo new PII in the portal session. Existing authentication only.## Open questionsDo third-party loss adjusters need access too?
计划阶段的评测指标非常实在且具体。领先指标是从第一次对话到intent.md提交的时间，原文里预期能从之前的数周降到小时级；滞后指标是产品负责人接受进入设计阶段的比例。
02 设计：需求和设计都在会话中完成
Claude Code读取已接受的intent.md，在组织的内部skills（品牌、安全、合规、UX各一份）约束下产出spec.md，产品负责人审阅但不动手写。前端拿intent.md在Claude Design里出mock，迭代满意后直接交给Claude Code实现。
手册中给的示例prompt写法：
请阅读附带的intent.md文件，并制定一份集成到我们现有代码库中的需求与设计规范。请运用你所拥有的技能来编写这份文档，确保它符合我们的品牌指南、安全政策以及用户体验标准。请将这份规范详细整理成 spec.md文件，以便提交给工程团队。同时，请明确指出任何可能存在的问题点，尤其是相互冲突、无法同时满足的政策要求。
03 构建：只有计划接受才动手写代码
正式写代码的起点是plan mode。给Claude的追问要具体，这个变更会破坏什么、哪一步风险最高、还有哪些方案你没选，迭代到一个没看过对话的工程师也能照着实现为止。plan.md提交进仓库，PR评审阶段拿diff对照它检查；实现偏离了计划，同一个commit里更新plan.md，可以用hook强制同步。护栏成熟之后，例行工作模式可以默认切换成auto mode，监督方式从监控每一次编辑，改成长自主会话结束后只review它交付的artifact即可。
手册在这里插了一个sidebar讲遗留系统，有一定的参考价值。开发工单在Jira，需求在带监管追溯的工具里，审批在变更委员会，这些都已经是系统审计员确认过了，动不了。处理办法是每种产物指定唯一的source of truth：仓库为准，遗留系统引用commit；或者遗留系统为准，markdown只是工作副本，Claude Code会话开始时读记录、结束时通过MCP写回；最低标准是互相链接，artifact记工单ID，工单记commit SHA。把Jira换成飞书，三种配置同样能跑通。
CLAUDE.md和skills是构建阶段的机构知识载体和组织过程资产，相关概念我之前写过不少，这里只看手册里怎么说的。CLAUDE.md削减到新人第一天需要的内容，保持一页以内；Claude同一个错误犯第二次，纠正写进CLAUDE.md。必须一致执行的内部知识才整理成skills，写完换几种问法测它是否触发，政策变更时修改skill并由政策负责人签字。
CLAUDE.md示例：
# Payments service## Commands- Build: make build- Test: make test (unit), make itest (integration, needs docker)- Lint: make lint (runs in CI; fix before pushing)## Conventions- Java 21, Spring Boot 3. No new Lombok.- Money is always BigDecimal, never double.- Every endpoint needs an integration test in src/itest.## Architecture- api/ holds REST controllers, core/ holds domain logic,adapters/ talks to external systems.- Kafka events are defined in schemas/; never edit generated classes.## Things Claude gets wrong- Do not bump dependency versions; the platform team owns them.- The legacy v1/ package is frozen; changes go in v2/.
文中也提到：skill是一种控制，但是advisory的，没有什么东西强制会话遵守它。必须要始终执行的动作，需要一个确定性的东西附加在skill后面，要么hook直接阻断动作，要么PR阶段再检查一遍。skill让违规变少，hook让违规近乎不可能。构建期的hook手册列了三类用途，阻止编辑受保护路径，文件编辑后跑formatter和linter，把凭证挡在diff之外。构建期hook要快，只盯改动的那个文件；需要人点头的hook不放在构建期，因为一个审批提示会把人重新放回所有并行会话的关键路径上。
并行会话两三个起步，但上限是一个人能认真评审的数量（这跟我之前说单人能深度介入的并行项目最好不多于2个是一个道理）。跨任务重复出现、只需要拿结果不用盯过程的活，做成Subagents交出去。
04 测试：会话先检查自己，配置也要过回归
第一条是给Claude反馈回路，测试、构建、截图diff至少一样，会话自己检查自己的工作，修复完自己的错误再交给人。手册区分了反馈回路和verifier subagent，前者贯穿整个任务反复跑，后者是任务自认为完成后开一个全新的上下文做终检，判断不受写代码时那些假设的影响。bug修复的做法是先让Claude把bug复现成一个失败的测试再提交，然后才让它在不动测试文件的前提下进行修复，改动测试文件用hook拦截。一个修复之前就存在、Agent又改不了的测试，才是bug消失的证据。
第二条是CI里的agent evals，手册把这个叫做AI-native版本的阶段门QA。从近期工作里收集20到50个真实任务和可接受的结果，每个写成prompt加检查项。套件按计划跑，CLAUDE.md、skills、hooks任何一个文件改动也要evals，因为这些配置在操纵agent的行为，理应和代码一样过回归，一次skill改动让通过率下降就得先评审再合并。每次生产事故由事故所属团队写一个eval留在套件里。
05 部署：Agent做到生产门为止
PR评审两个方向都有Claude。评审政策写成仓库根目录的REVIEW.md，分bug、安全、合规三个pass，合规对照的就是前面的spec.md和plan.md，Important只留会破坏行为、泄露数据、违反政策的发现，每次最多报5个nit，其余汇总成一个数字。发现本身不批准也不阻断PR，分支保护仍然要求code owner批准，写代码的agent没有任何途径批准自己的代码。评论里@claude，Claude修完推送上去；Claude自己开的PR可以让它一直照看到合并，有团队把这个包成一个slash command，扫未解决的评论和失败的检查，直到PR全绿只等code owner。
审批门就是开头那个production-gate.sh：jq读出tool_input.command，命令里同时出现deploy和production且环境变量RELEASE_APPROVAL为空，就往stderr写一句理由，exit 2。exit 2在Claude Code的hook协议里就是阻断，理由会回给模型，手册要求阻断必须自解释，我开头拿到的那行报错就是这么来的。我第二次运行时导出了RELEASE_APPROVAL，worker顺利执行，输出 deploying to production ... done。要说明的是，这个样例匹配的只是命令子串，脚本改名叫release.sh就能绕过去，真上生产得按组织自己的门条件来写，手册也建议deploy这类能力通过MCP暴露成按环境限定的工具，而不是一个带凭证的shell脚本。
团队级的hook放在.claude/settings.json进git，不可协商的放managed settings，由平台团队通过 MDM（企业统一管理员工设备的系统）或admin console下发，工程师改不了。手册给了一份受监管企业的样板：拒绝读取.env和secrets目录，禁掉WebFetch、curl、wget，只放行git和make build/test/lint，沙箱强制开启，网络只允许内网git和npm registry，~/.ssh和GITHUB_TOKEN对agent不可见，插件只能安装公司批准的marketplace。
CI/CD集成的推进顺序手册写得很稳健。先做只读的判断类步骤，用claude -p在流水线里分诊失败的构建、总结flaky test、起草changelog；然后在既有的门后面加写操作，agent写的一切以PR形式经分支保护进入，没有直推main的路；执行放在沙箱里，短期限定的token，默认不持有生产凭证。自治程度按环境分层，开发环境随便部署，生产环境agent准备好发布由发布经理授权，staging居中。回滚要是流水线里演练最多的一条路径，一条命令，在staging定期演练，因为维护阶段的最高自治档会调用它。
06 维护：把Loop合上
手册里提到，软件部署上线后，线上检测层可以完全不用模型。一个版本控制、带单测的脚本监控一个指标，比如CI测试失败率或部署后5xx率，滚动窗口计算均值和标准差，套用Western Electric 规则（一套判断统计过程是否失控的SPC规则）。响应按偏离基线几个标准差分三档写在bands.yaml里，1σ只记日志，2σ调用Claude做只读诊断，3σ允许行动，但行动路径只有两条，开一个PR进评审门，或者触发一条预先批准的回滚runbook。Claude的诊断写成intent.md格式回到计划阶段，由on-call分诊，修复、排期或者驳回，驳回的记录反过来用于调整带宽。
手册给了三个例子。CI测试失败率破3σ，agent隔离flaky test或者开一个revert PR，评审门决定；部署后5xx率破3σ且窗口内有过部署，agent触发既有的回滚流水线；PR cycle time触发漂移规则，agent给工程领导写一份报告，同一套机制对流程指标同样有效。
线上事故还可以从Slack进来。Claude Tag让Claude以自己的身份成为事故频道的成员，晚上十点的紧急消息立刻有第一响应者，频道里任何人都能引导它，Claude通过MCP核实指标回到基线并在线程里确认，post-mortem写进版本控制的lessons文件，频道本身就是审计轨迹。
这样一来凌晨三点的告警不再依赖有人24小时盯着，人工也没有从路径上缺位，只是从每个阶段的起点转移到了每道门的后面。
这份手册面向的是有成熟开发规范、需要使用Agent Coding提效的大厂开发团队，个人的话其实很难用上。但AI参与融入软件工程的环节与细节，值得所有做AI Coding的读者参考。强烈推荐去看这篇blog的原文。
如果觉得有用，点个赞或者在看，也方便更多朋友看到。
感谢您阅读我的文章。我是鲁工，九年AI算法老兵，AI全栈开发者，深耕AI编程赛道与AI科研赛道。
