稀饭

AI-Native SDLC 实战手册：当软件开发生命周期被 AI 重写

Claude Academy 的 AI-Native SDLC Playbook 全解析：为什么瓶颈不再是写代码、六个阶段各自落到哪个版本化产物、intent.md / spec.md / plan.md / CLAUDE.md / skills / hooks 怎么串成一条可审计的闭环，以及治理即代码与全程度量。

  • AI
  • SDLC
  • Claude
  • Agent
  • 工程实践
  • 方法论

本站一直在讲怎么和 AI 一起干活：Agent 的 Harness 决定它怎么动手，推理引擎决定它怎么把 token 吐得够快。 但还有一个更上游的问题——当模型能几秒钟写出一段能跑的代码，真正的瓶颈其实早就不是「写」了。

Claude Academy 最近上线的 AI-Native SDLC Playbook 把这件事讲得很透：传统软件开发生命周期（SDLC） 是为「写代码最耗时间」那个时代设计的；现在代码几乎免费，卡住生产力的，是规划、评审、测试、部署这些围着代码转、却还按人类节奏跑的环节。这篇把它拆成一份能直接用的中文手册。

一、先说清楚：瓶颈早就不是写代码了

核心论点只有一句话：代码不再是瓶颈，卡住的是代码周围那些还按人类速度运转的流程。

阶段传统 SDLCAI-Native SDLC
Plan委员会收集需求、开 workshop、层层签字，最后人手写文档Claude 直接从源头把痛点综合成 intent.md，人读得懂、机器也能用
Design分析师写需求，设计师再解析成设计，两层团队交接易失真需求与设计在一次会话里压缩完成，规范以 skills 编码、进 Git 版本化
Build测试与代码手写，文档事后补测试与代码由 AI 生成，机构知识沉淀为版本化的 CLAUDE.md 与 skills
Test阶段边界上的人工 QA 闸评估（evals）编织进实现全过程
Deploy人逐行 review，治理散落在不一致的评审周期多层 agentic 评审，人只审受监管 / 关键代码；治理作为 AI 行动时强制生效，hook 当审批闸
Maintain人盯生产环境找 bugagent 监控线上部署，任何被突破的控制带都会被诊断并写回成新的 intent.md

注意一个贯穿全局的设计：每个阶段结束时往版本库提交一个产物，下一阶段开头先读它。 产物链就是审计链——谁要了什么、agent 产出了什么、谁批的，全在提交历史里。

二、六个阶段，每段落一个版本化产物

把整条流水线摊开看，产物链条是这样的：

intent.md  →  spec.md  →  plan.md  →  PR  →  事故记录
  (Plan)      (Design)    (Build)    (Deploy)   (Maintain → 写回 intent.md)

下面按阶段过一遍关键动作。

三、Plan：把意图写成 intent.md

变了什么：一个想法传统上要穿过 backlog、用户故事、故事点、refinement 会议才能被人执行， 每交一次手就离原创者的本意远一点。AI-Native 里，发起者直接和 Claude 头脑风暴， 结果写成 intent.md——用发起者自己的话写成的「原型规格」，包含要什么、为什么、在什么约束下。

怎么做：

  1. 发起者用自己的话把问题讲给 Claude（不需要正式术语）；
  2. 脑暴到想法具体为止，Claude 会像分析师一样追问范围、用户、约束、成功标准；
  3. 让 Claude 按组织模板输出 intent.md；
  4. 发起者修正 Claude 误解的地方；
  5. 把 intent.md 提交到仓库里的 intent/ 目录。

一个真实的 intent.md 长这样：

# Intent: 理赔状态自助查询
Author: J. Ortiz (claims operations). Status: draft.

## Problem
客户打电话到客服中心问理赔到哪了。
坐席约三分之一的通话时间花在「只查状态」的查询上。

## Proposed outcome
客户在门户里直接看到理赔状态、下一步和预计日期。

## 受影响用户与系统
理赔坐席、门户团队、claims-core API。

## Constraints
门户会话不引入新 PII。仅用现有鉴权。

## Open questions
第三方公估人是否也需要访问？

度量：先行指标是「从第一次对话到提交 intent.md 的时间」 （通常从数周降到数小时）；滞后指标是「存活率」——产品负责人收进下一阶段的 intent.md 占比。

四、Design + Build：规范即代码，知识即技能

Design 阶段把 intent.md 在一会话里压成 spec.md，并受组织 skills 约束， 把矛盾政策在写规格时就标出来——而不是几周后的评审才发现。

Build 阶段有三个最该记住的构件：

  • Plan Mode 起步：工程师先用 plan mode 让 Claude 读代码库（不改任何东西）产出 plan.md， 批准后再实现。好计划往往让实现一遍过；当护栏成熟（调好的 CLAUDE.md、skills、hooks、测试套件），常规工作可默认开 auto 模式。
  • CLAUDE.md：把「新人第一天该知道什么」写进文件——命令、约定、架构、团队最常踩的坑。 铁律是「Claude 犯两次的错，就写进 CLAUDE.md」。控制在「不到一页」，因为它每次会话开头都会被全读。
  • Skills：把机构知识变成可执行的技能——显式、版本化、广覆盖、政策变了集中改。 和 CLAUDE.md 的分工是：必须被一致执行的知识写成 skill，项目级约定放进 CLAUDE.md。

一个最小 CLAUDE.md：

## Commands
- Build: `make build`
- Test:  `make test`  (跑单测与集成)
- Lint:  `make lint`

## Conventions
- Java 21, Spring Boot 3
- 未经安全评审不得引入新依赖
- 金额用 BigDecimal，绝不用 double

## Common mistakes
- 新控制器必须在 /itest 加集成测试
- 核心服务不得 import web 层

治理的两层：skill 是「建议性控制」——提高合规概率，但不强制；凡「必须永远成立」的政策， 要靠确定性的东西兜底：hook 在动作前拦下违规，或评审在 PR 时再审一遍。

五、Test：给 AI 一个反馈闭环

变了什么：传统上「代码能用」的信号来得很晚——CI 几分钟后、测试几天后、生产几周后。 当 agent 在产代码，晚到的信号意味着人得检查所有产出，人成了瓶颈。AI-Native 让会话在交给你之前先自查： 跑测试、跑构建、截图，Claude 自己迭代到检查通过。

怎么做：把验证包成一个会非零退出的目标（make test），在 CLAUDE.md 里写明 「报告完成前先跑测试并贴输出」；修 bug 时先写失败测试让 Claude 复现，再让它只改代码不改测试； UI 工作用浏览器 / 截图工具关环，让 Claude 实现 → 截图 → 对比 → 调整。

更进一步是 Continuous Evals：把 20–50 个真实任务写成评估集，每次 CLAUDE.md、skills 或 hooks 变更时就在 CI 里非交互跑一遍——换模型或改提示后，评估集立刻告诉你 agent 是否还达标。每起生产事故都该加一条 eval，留在集里当回归测试。

六、Deploy：AI 进 PR 评审，Hook 当审批闸

传统评审容量按人类产出规划，PR 等人读，质量随 reviewer 负载波动。AI-Native 让所有 PR 都过同一套评审，发现按严重度排序，人的注意力上移一层：这个改动是否真做了 plan 里要的事、风险是否可接受。

技术负责人把评审政策写成根目录的 REVIEW.md，分成多遍：Bugs / Security / Compliance； 定义什么是 Important、什么是 Nit、什么不报。CI 里接 claude-code-action 跑，但分支保护仍要求代码所有者批准—— AI 的发现不自行批准或阻塞 PR。被评审第二次抓到的错，又回流进 CLAUDE.md。

而 hook 提供的是 审批闸：构建阶段 hook 是无人的「允许 / 拦截」；它也能「询问」—— 暂停动作直到指定的人批准。比如生产部署必须带具名的 release authorization，否则 hook 直接拦下 （退出码 2，理由进 Claude 的输出）。受监管企业把不可改的 hook 放进托管设置（managed settings），由平台 / IT 团队持有。

七、Maintain：让监控自己写下一轮 intent.md

传统运维是被动的：告警凌晨三点响、可能漏接，事后动作未必回到代码库。AI-Native 里，触发器（控制带突破、工单、定时）直接唤起 Claude，中间不经过人。 Claude 只走带闸的路径行动，把诊断写成 Stage 1 格式的 intent.md，重新进入上面的循环。

具体做法：挑一个有稳定基线的指标，写确定性检测脚本（用滚动窗口的均值 / 标准差，按西电规则之类画带）； 在 bands.yaml 里分档——1σ 只记录、2σ 唤起 Claude 只读诊断、3σ 才允许行动 （且只能开 PR 或触发预批 runbook）；触发层是定时任务或监控栈的 webhook； Claude 无状态跑在沙箱里，诊断写成 intent.md 进队列，人只做分拣与复核。

metrics:
  - name: ci_failure_rate
    baseline: 0.05
    bands:
      - sigma: 1
        action: log
      - sigma: 2
        action: diagnose
      - sigma: 3
        action: act
        max_action: pr

闭环就此合上：生产监控发现的异常，变成下一轮 intent.md。Stage 6 可以无头跑， 阶段之间有独立的置信闸（确定性检查或对抗式评审 agent）决定上一段产物继续还是升级给人。

八、贯穿全程的两件事

把六个阶段收拢，有两件事从头到尾都在发生：

  • 治理即代码（Governance as Code）：skills 让违规变少，hooks 让违规变不可能。 前者建议性，后者确定性，二者都版本化、可评审。再加上托管设置（权限拒绝、沙箱、凭据隔离、仅允许托管 hook / MCP）， 把 agent 的工具面收口到平台团队手里。
  • 每阶段都度量：每个 play 都配了先行指标（预测性、实时）和滞后指标（结果性）。 这不是装饰——你得靠它判断转型是否真的在起作用。

另外两条值得记牢：人的判断向闸口集中——不是人做所有事，而是人评审 agent 标记的疑点， 注意力从「做」上移到「判断意图与风险」；平台工程拥有这套体系——这不是每个团队各搞一套的工具 rollout， 而是平台团队搭好「上下文 + 治理 + 编排」的 harness，让 agent 在全组织里行为一致。

小结

把这篇收成三句话：

瓶颈不再是写代码，而是围着代码、还按人类节奏跑的流程。 AI-Native SDLC 把六个阶段各自落成一个版本化产物（intent / spec / plan / PR / 事故）， 用 CLAUDE.md + skills + hooks 把治理写进代码，用 evals 与度量把质量织进全过程。 终点是一条自喂的闭环：生产监控发现的异常，自己写回成下一轮 intent.md。

  1. 产物驱动循环，而非文档驱动汇报。每段提交一个机器可读的产物，提交链就是审计链； 人不再从零理解「到底要了什么」，直接读上一阶段的产出。
  2. 治理分两层：skills 劝、hooks 拦。必须永远成立的政策不能靠建议，要有确定性兜底； 受监管场景把不可改的 hook 与权限收进托管设置。
  3. 转型是平台工程的事，不是团队各自探索。从 intent.md 到 bands.yaml，整套机制都是 「上下文 + 治理 + 编排」的 harness——搭好它，agent 才会在全组织里行为一致，人也才能把判断力留给真正要紧的闸口。

想按模块深挖，官方课程在academy.claude.com/zh-CN/courses/ai-native-sdlc-playbook（共 14 课、6 阶段）。