Anthropic 放出一份题为 AI 原生软件开发生命周期的手册，把公司内部围绕 Claude 重排的开发流程拆成六个阶段公开。文档的出发点写得直白：代码生成已经不再是瓶颈，传统流程按人手写代码的速度设计，卡点因此换了位置。
六个阶段依次是规划、设计、构建、测试、部署、维护，每个阶段的做法都被重写过一遍。规划从需求会议加手写文档，改成与 Claude 对话后产出 intent.md，文档给的口径是周期从数周压到数小时；设计在一次会话里产出 spec.md 并跑策略检查；构建先出 plan.md 再进入实现；测试不再守在阶段边界，持续评估被并进实现过程；部署换成分层自动审查加 Hook 把关；维护则从被动响应告警，改成自动检测后生成新的 intent.md 回到起点。
串起这六段的是文件，不是会议。intent.md 交给 spec.md，spec.md 交给 plan.md，再往下是 PR 与审查结果，最后事件记录绕回 intent.md。文档把这条链概括成一句承诺：每个阶段提交一件工件，供下一阶段读取。
四件治理件
Skills 承担制度化知识。API 安全标准、品牌规范这类东西被写进 .claude/skills/，策略变更时中央改一次，工程师下次会话自动拿到新版。文中的例子是一个叫 secure-api-review 的 skill，负责盯认证、入参校验和审计日志。
Hooks 负责确定性控制，没有人工绕行的路径。构建阶段拦住对冻结依赖包的编辑、强制跑格式化；部署阶段的生产发布需要 release manager 授权，未授权直接以 exit 2 阻断。
CLAUDE.md 是团队记忆，篇幅控制在一页：构建命令、约定、架构、常犯的错。文档给的维护规则很务实——同一个错犯到第二次，就写进去。
evals 当回归测试用。20 到 50 个真实任务组成评估集，配置一改就跑，另有每晚定时跑一轮；每次生产事故都被固化成一条永久 eval，通过率直接作为合并条件。
一个理赔查询功能怎么走完全程
文档举的案例是理赔状态自助查询。运营侧先写 intent.md，说明问题、用户和约束，产品负责人审查批准后进入设计阶段；Claude 应用 UX 与安全 skills 生成 spec.md；工程师进入 plan mode 拿到 plan.md，随后由 Claude Code 实现、PR 过 review hook 后合并。
约束被显式写进计划里：claims-core 接口限 50 rps，所以 plan.md 标注了需要缓存；会话过程中不得新增个人身份信息；认证走既有方案。另一个支付服务团队的 CLAUDE.md 则写着 Java 21、Spring Boot 3、禁用 Lombok、金额必须用 BigDecimal 而非 double、依赖版本由平台团队管不许动。
维护阶段的自动化按三档阈值分级。以 CI 测试失败率为例，基线取滚动 30 天，1σ 只记录，2σ 让 Claude 带只读权限做诊断，3σ 才允许它开 PR 或触发预先批准的 runbook。异常检测脚本本身是确定性的，用 Western Electric 规则判定，不交给模型。
指标清单暴露了读者是谁
前置指标包括首次对话到提交 intent.md 的时长、提交到首次审查的时长、并发 agent 会话数、CI 通过率；滞后指标包括 intent.md 的通过率、首次实现通过率、PR 审查发现数的趋势、生产事件重复率、每工程师每周合并的 PR 数。
配套的还有两条合规路径：一条以 Jira 或 ServiceNow 为权威记录、markdown 当工作副本，通过 MCP 连接器同步回旧系统；另一条以仓库为唯一事实源，旧系统只引用 commit SHA。审计线索靠 Git 历史、PR 线程、OpenTelemetry 导出的 agent 行为记录和 Hook 的放行/阻断日志四路拼齐。
这套东西不面向个人开发者。粗算一下，一个两三百人的工程组织若照文中口径把评估集铺开，每次配置变更加每日定时各跑一轮，光推理开销就是一笔常年账单，再加上 skills 和 hooks 需要专人维护——治理件本身要钱要人，收益却往往要几个季度才显形。这也是这类流程改造在中型公司通常推不下去的地方。愿意为审计线索付这笔钱的组织，才是这份手册真正瞄准的客户。
参考来源：Anthropic 官方工程文档、CocoLoop、Claude Code 产品文档；核验六阶段工件命名、三档阈值配置与评估集数量口径。