从直线流程到闭环流水线：AI 原生 SDLC 的原理与实践

本文基于 QoderCN 内置 ai-native-sdlc skill 整理，内容源自 Anthropic《The AI-Native SDLC Playbook》(2026-08-21)。

一、背景：为什么传统 SDLC 在 AI 时代失效了

传统软件交付流程（SDLC）是"重"的，因为它诞生于代码最贵、最慢的年代。PRD、估点、安全评审，都是为了让数周到数月的开发过程"强行对齐"。但当 AI 把写代码的时间压缩到小时级之后，三件事同时成立：

1. 瓶颈转移到构建两侧：规划、评审/测试、部署仍按人的速度运行，构建却塌缩了；人速阶段与机器速阶段严重失衡。
2. 控制手段与现实脱节：逐行手工审查在人写代码时是合理的，但当智能体写掉绝大部分 diff 之后，人类评审根本追不上。
3. 治理成本上升：例外事项仍要等每周/每月的会与委员会裁定，成了新的瓶颈。

一个典型场景是安全团队：按人类产出量配员的评审队列，在 AI 倍增代码产出后要么越积越长，要么代码没审够就上线。安全与策略检查必须跟上 AI 的节奏——这正是 AI 原生 SDLC 要解决的问题。

二、核心原理：把交付变成"环"

AI 原生 SDLC 的核心思想非常朴素：把软件交付从直线流程变成一个闭环，以小时而非周为单位运转，人在环上发起、指挥和治理。

计划 → 设计 → 构建 → 测试 → 部署 → 维护
  ↑                                    │
  └──────────── 回到计划 ←─────────────┘

六个阶段，每个阶段以提交一份版本化产物结束，下一阶段读取它开始。环的运转逻辑是：

• 被接受的 intent.md（意图）触发设计
• 被批准的 spec.md（规格）触发构建计划
• 被合并的 PR 触发部署流水线
• 生产环境的控制带突破写下新的 intent.md，回到计划

四个治理原则

1. 制品即证据：所有产物、技能、钩子全部进 git。提交历史就是审计链——谁提出的问题、AI 产出了什么、谁批准的，全程可追溯。
2. 两层防护：约定与 skill 是"建议性控制"，提升合规概率；红线用 hook 等确定性手段强制拦截。建议有余，强制兜底。
3. 人守在判断位：AI 负责生成、执行、机械校验；高风险动作与最终批准永远归人。一句话——智能体可以做到生产门前，绝不能越过上线闸门。
4. 不推翻现有工具：Jira、Figma、GitHub 继续用；仓库内的 Markdown 是真相源，两边互记 ID 关联，平滑演进。

三、产物链：一份文件点燃下一环

阶段	产物	点燃下一环的条件
计划	intent.md	被接受 → 进入设计
设计	spec.md	被批准 → 进入构建计划
构建	plan.md → 代码 + 测试 → PR	PR 被合并 → 触发部署流水线
维护	诊断 → 新的 intent.md	回到计划

前几个阶段刻意使用 Markdown，因为产品负责人和 AI 能读同一份文件并各自据此行动。产物存放在仓库内（单产品用 intent/ 目录；只有意图跨很多仓库时才单独开意图仓库）。需要判断的决定，责任在人。

四、六阶段用法详解

阶段 1：计划（捕获意图）

1. 让提出者用自己的话描述问题：今天做不了什么、谁受影响、更好的样子是什么、什么不在范围内——不需要正式措辞。
2. 追问分析师式问题（范围、用户、约束、成功长什么样），直到想法足够具体。
3. 按模板写成 intent.md 并提交，作者与时间戳进入 git 记录。
4. 产品负责人做接受/驳回决定（记录为合并或关闭评审）；接受即触发阶段 2。

intent.md 模板：

# <标题>
作者: <姓名> | 来源: <团队> | 状态: 草稿/已接受/已驳回

## 问题
## 期望结果
## 涉及的人和系统
## 约束
## 待定问题

衡量指标：首次对话 → 提交的时间（目标从数周降到数小时）；产品负责人接受率。

阶段 2：设计（需求与规格，一次会话搞定）

1. 读取被接受的 intent.md，加载组织标准（品牌、安全、合规、UX——应写成 skill 供 AI 加载）。
2. 产出 spec.md：落地方案 + 所有需要警惕的地方，尤其是无法同时满足两条冲突策略之处。
3. 产品负责人对照 intent.md 评审：是否解决所陈述的问题？待定问题被回答还是被带到下一环？关注点逐条路由给具名策略负责人。
4. spec.md 与 intent.md 并排提交，记录"当初要求了什么、最后决定了什么"。
5. 是否推进到构建由人决定；高风险咨询技术负责人。

典型提示词范式：

"读取 intent.md，为它在现有代码库中的落地产出需求与设计规格；应用全部组织标准（品牌、安全、UX）；完整写成 spec.md；清楚写出所有需要警惕的地方。"

演进路径：手动跑 → 固化为组织级斜杠命令 → 把"intent.md 被接受"设为触发器，自动产出 spec.md PR，产品负责人的第一次介入从"撰写"变成"评审"。

阶段 3：构建（先审计划，再动代码）

1. 读取 intent.md + spec.md，先产出 plan.md：改哪些文件、什么顺序、有什么风险、怎么验证。
2. 人批准 plan.md 后才动代码——审计划比等写完几十个文件再返工便宜一个量级。
3. 反馈闭环：交人审之前 AI 先自己跑构建、单测、lint、UI 截图，错了自己改（如 make build、make test、make lint）。
4. 组织知识沉淀进 CLAUDE.md（仓库根目录）。原则：同样的错犯两次，纠正就写进 CLAUDE.md。
5. 执行容易走样的机构知识（安全标准、API 设计约定）写成版本化 skill。
6. 并行会话从 2–3 个起步。

治理红线：分支保护要求 code owner 批准——写代码的 agent 没有权限批准自己的代码；plan.md 进版本控制，构成审计链。

阶段 4：测试（持续 evals 替代阶段门禁）

1. 收集 20–50 个真实历史任务，每个附预期结果，写成评测项（一条 prompt + 一条通过判定）。
2. 套件在 CI 非交互运行；CLAUDE.md、skill、hook 任何配置变动都触发。
3. 设门禁：通过率下降的配置改动必须复审，不得合并。
4. 每出一次生产事故，沉淀一个评测项——同类问题在 CI 里被拦下，不会第二次上线。
5. QA 职责从手动测试转为维护评估用例；人的验收标准仍是最终依据，不过度依赖 LLM-as-a-judge。

阶段 5：部署（智能体评审 + hook 审批门）

1. 每个 PR 先过智能体评审：缺陷、安全、合规三轮；意见必须附证据、按严重度排序；每次审查最多报 5 个小问题，保证人读得完。
2. 评审是双向的：AI 评审别人的 PR，也处理别人对自己 PR 的意见。
3. 人只回答两个问题：这改动是不是计划里想要的？风险能不能接受？人工评审留给受监管代码与关键路径。
4. hook 就是审批门，三种行为：阻止（block）、询问审批（ask）、放行（allow）。改生产配置、跑迁移脚本等高风险动作强制人工授权（如 production-gate.sh 检查发布授权签名）。
5. 构建失败由 claude -p 在 CI 里分诊：先诊断，给出修复 PR 或人工介入建议。
6. 底线：开发环境放开让智能体跑，生产环境必须人工授权，回滚提前演练。

一个有意思的量化结果：评审要求附证据后，带实质评审意见的 PR 占比从 16% 提升到 54%。

阶段 6：维护（控制带闭环）

1. 用统计学控制带盯指标：bands.yaml 定义指标与分档阈值（如 citestfailurerate），用 Western Electric 规则，基线取滚动 30 天。
2. 分级响应：1σ 记日志只观察；2σ 持续越界做只读诊断找原因；3σ 严重越界提修复 PR 或触发预设回滚。
3. 诊断结果写成标准 intent.md 回到阶段 1；值班工程师分诊：修、排期、或调太敏感的阈值。
4. 聊天工具（Slack/Teams）里的告警可直接转成工单或 intent.md，聊天记录留作审计证据。

衡量：MTTD/MTTR；控制带误报率；事故 → 新 intent.md → 修复上线的闭环时长（目标小时级）。

五、采用顺序：分阶段改造，别想一次重构

依赖图（注意这不是阶段排列）：

层级	内容
可直接开工（无前置）	捕获意图、CLAUDE.md、反馈闭环、hook、计划模式
第二层	skill、子智能体、evals
第三层	需求与设计、PR 评审
第四层	CI/CD
最后	把环闭上

落地建议：先上最轻的 intent.md 与 CLAUDE.md 模板，再逐步加技能、钩子、评估、闭环。 终态是每份被接受的产物自动点燃下一道门，人的注意力集中在各道门评审智能体标记出来的东西上。

六、关键记忆点（数字速查）

指标	数值
传统需求周期 → AI 原生	数周 → 几小时
合理并行会话起点	2–3 个
评测套件规模	20–50 个真实任务
每次审查小问题上限	5 个
监控分级	1σ 记日志 / 2σ 诊断 / 3σ 提方案
监控基线	滚动 30 天
评审质量提升（附证据后）	16% → 54%

七、文件与工具约定

类型	名称
配置文件	CLAUDE.md、SKILL.md、REVIEW.md、intent.md、spec.md、plan.md
目录	.claude/skills、.claude/agents、.claude/settings.json、.claude/hooks
命令	make build、make test、make itest、make lint
协作工具	GitHub、GitLab、Jira、ServiceNow、Figma、Prometheus
基础能力	MCP、Agent SDK、OpenTelemetry 等

八、总结

AI 原生 SDLC 的本质是一次控制策略的迁移：不靠"开会对齐 + 事后审查"来治理，而是靠"版本化产物 + 自动化闸门 + 人守判断位"来治理。它不推翻你现有的工具链，只改变工作形态——AI 负责跑圈，人负责拍板；圈越转越快，审计链越来越完整。

如果只记住一句话，那就是：

AI 可以做到通往生产的所有步骤，但绝不能越过上线这道闸门。