从 AI 编码到 AI 原生研发：SDLC 实践指南

引言：代码已经不再是瓶颈

AI已经让软件代码的生产速度发生了数量级变化，但围绕代码生产建立起来的组织流程，并没有以相同速度改变。

很多工程团队已经开始使用 Claude Code
等智能体式编码工具，但需求审批、设计评审、测试、交接、发布审批、安全审查和治理机制仍然按照”人类手工编写代码”的生产速度运行。

传统 SDLC 通常包含六个阶段：

1. Plan：规划
2. Design：设计
3. Build：构建
4. Test：测试
5. Deploy：部署
6. Maintain：维护

过去，各阶段往往由不同角色负责：产品经理形成需求，架构师和分析人员形成设计，工程师实现代码，QA
负责验证，发布团队完成上线，运维团队观察生产系统。

这种模式并非没有道理。传统 SDLC
的大量流程、文档和审批，本质上是为了在”编码昂贵且耗时”的条件下维持组织协同、责任边界和风险控制。

问题在于，这个基本前提正在改变。

当智能体能够大幅压缩 Build 阶段后，会出现三个直接结果：

• 瓶颈转移到 Build 左右两侧，尤其是规划、评审/测试和部署；
• 传统控制机制难以继续按原来的方式扩展，例如人工逐行审查智能体生成的大量代码；
• 如果异常仍必须等待周会、委员会或人工审批，治理成本反而会随着代码产出增加而上升。

因此，真正的问题不再只是”如何用 AI 写更多代码”，而是：

当代码不再是研发过程中的主要约束时，整个 SDLC 应该如何重新设计？

---

什么是 AI 原生 SDLC？

AI 原生 SDLC 并不是简单地在传统流程中增加几个 AI 助手。

它试图保留传统 SDLC
所追求的控制目标——责任、质量、安全、合规和可审计性——同时改变这些目标的实现方式。

传统 SDLC 更像一条线性流水线：

Plan → Design → Build → Test → Deploy → Maintain

AI 原生 SDLC 则逐渐演化成一个闭环：

Intent
  ↓
Plan → Design → Build → Test → Deploy
 ↑                              ↓
 └──────── Maintain / Observe ──┘

AI
被嵌入每个阶段，各阶段之间的交接也从人工传递文档和工单，逐渐转变为由机器可读的产物自动触发。

Anthropic 将这种方式称为 AI-native SDLC，也可以称为 agentic SDLC、AI
SDLC 或 agentic software development。

---

六个阶段发生了什么变化？

---

阶段 传统 SDLC AI 原生 SDLC

---

Plan 通过会议、访谈、工作坊和人工文档形成需求 AI
从原始问题中提炼意图，形成兼具人类可读性和机器可执行性的
intent.md

Design 分析人员写需求，设计人员再解释需求 AI
在一次协作过程中把意图转化为需求与设计，并应用组织级规则

Build 人工编写代码、测试和文档 AI 生成代码和测试，组织知识沉淀为 CLAUDE.md、Skills
等机器可读资产

Test QA 在阶段边界集中验证 Eval 和反馈循环持续嵌入实现过程

Deploy 人工逐行 Review，治理主要发生在评审环节 多层智能体 Review；人在关键、高风险和受监管环节判断；Hooks
执行确定性控制

Maintain 人工观察生产问题并重新启动研发流程 Agent 监控生产状态，异常被诊断后重新形成新的 intent.md

这里贯穿始终的关键概念是：

Committed Artifact（提交到版本控制的正式产物）。

每个阶段结束时，都留下下一个阶段能够读取和执行的产物，例如：

intent.md
   ↓
spec.md
   ↓
plan.md
   ↓
code + tests
   ↓
PR + review findings
   ↓
deployment records
   ↓
incident record
   ↓
intent.md

这条提交链本身也构成审计链：谁提出了什么、智能体产生了什么、谁进行了批准，都可以被追踪。

人的责任没有消失，只是人的注意力从”亲自执行所有步骤”转移到”对需要判断的关键产物负责”。

---

01 Plan：把想法直接变成 intent.md

传统流程中，一个想法可能需要经过 backlog、用户故事、Story
Point、需求澄清和多轮会议，才能进入工程团队。

每一次交接都可能造成语义损失。

AI 原生方式希望尽可能缩短这条链路。

需求发起者直接用自己的语言描述：

• 当前解决不了什么问题；
• 谁受到影响；
• 希望达到什么结果；
• 有哪些限制；
• 哪些内容明确不在范围内；
• 还有哪些开放问题。

Claude 通过追问帮助发起者把想法具体化，然后按照组织模板生成
intent.md。

最终仍由人检查和修正 AI 的理解，再提交到共享的版本控制位置。

intent.md 的意义

它不是传统意义上的”大而全 PRD”，而更像一种 proto-spec：

原始业务意图
     ↓
结构化 intent.md
     ↓
机器可继续处理
     ↓
人可以审阅
     ↓
Git 可以审计

因此，它同时服务于人和 Agent。

基础设施

对于单一产品，最简单的方式是在产品仓库中建立：

intent/

如果一个意图跨越很多仓库，则可以考虑独立的 intent repository。

没有 Git 使用经验的业务人员，也不一定需要直接操作
Git；可以通过版本控制连接器让 AI 代为提交 Markdown 文件。

治理

治理证据就是已经提交的 intent.md：

• 作者；
• 时间戳；
• 完整修改历史；
• Product Owner 的接受/拒绝决定。

衡量指标

领先指标：

从第一次讨论到正式提交 intent.md 的耗时。

滞后指标：

• intent.md 被接受进入 Design 的比例；
• spec.md 已经开始后，intent.md 又发生多少次重大修改。

---

02 Design：需求与设计合并为一次协作过程

当 intent.md 被接受后，Claude
可以结合组织已经编码的品牌、安全、合规、UX 等 Skills，形成 spec.md。

Product Owner 的角色发生变化：

不再主要负责”从零撰写规格”，而是负责审阅 AI
形成的规格，并对关键判断负责。

AI 需要主动标记：

• 冲突的政策；
• 无法满足的约束；
• 未解决的问题；
• 高风险设计决策。

Product Owner 优先处理这些异常，而不是逐字生产整份规格。

典型链路

intent.md accepted
        ↓
AI + organization skills
        ↓
spec.md
        ↓
flagged concerns
        ↓
Product Owner / Policy Owner
        ↓
approve
        ↓
Build

Governance by construction

一个很重要的变化是：

传统模式往往先完成设计，数周后才在安全、合规或架构评审中发现问题。

AI 原生模式则尝试在 spec.md 形成时，就把最新政策作为约束加入生成过程。

因此治理开始从：

先设计 → 后检查

转向：

带着规则设计

规格、生成规格时使用的 Prompt，以及当时生效的 Skill
版本，都可以进入版本控制。

---

03 Build：先有可审计的 Plan，再写代码

Plan Mode 成为默认入口

工程师不是拿到需求后马上让 Agent 修改代码，而是先让 Agent 读取：

intent.md
spec.md
CLAUDE.md
repository

然后形成明确的 plan.md。

Plan 至少应说明：

• 哪些文件需要修改；
• 实现顺序；
• 风险在哪里；
• 哪些替代方案没有采用；
• 如何证明实现正确。

工程师应主动挑战计划，例如询问：

• 这个改动可能破坏什么？
• 哪一步风险最高？
• 为什么不采用其他方案？

目标是：

一个没有参与前面讨论的工程师，仅阅读 plan.md
就能够理解并实施这个变更。

计划被接受后再进入代码实现。

如果实现过程中偏离了计划，则 plan.md 应同步更新。

这样，设计 Review
被提前到代码产生之前——此时改变方向仍然只是修改文档，而不是推翻大量代码。

---

CLAUDE.md：把团队隐性知识变成 Agent 的工作知识

CLAUDE.md 用于提供类似”新工程师入职第一天必须知道的信息”。

通常包括：

• 构建命令；
• 测试命令；
• Lint 命令；
• 编码约定；
• 架构结构；
• 团队最常见的错误；
• Agent 经常理解错误的地方。

过去存在于 Wiki 和工程师脑中的知识，开始转化成 Agent 每次 Session
都能读取的版本化文件。

Anthropic 给出的一个实用维护原则可以概括为：

如果 Agent 重复犯同一类错误，就应该考虑把纠正规则沉淀到 CLAUDE.md。

同时要控制文件长度，因为过时和冗余内容会占用上下文。

---

Skills：把组织知识变成可执行规则

CLAUDE.md 更偏向具体代码库的工作上下文。

Skills 则适合承载需要在组织中一致应用的知识，例如：

• API 安全标准；
• 品牌规范；
• 数据保护规则；
• API 设计规范；
• 合规要求。

一个 Skill 可以存放在：

.claude/skills/<name>/SKILL.md

并通过版本控制进行管理。

当政策变化时，修改 Skill；政策 Owner 审核后，新规则即可在后续 Session
中统一生效。

但 Anthropic 特别强调：

Skill 本质上仍是 advisory control。

如果某条规则必须百分之百执行，就不能只依赖模型”记得遵守”，而需要确定性的
Hook 或 PR 检查。

因此形成两层：

Skill
  ↓
提高 Agent 主动遵守规则的概率

Hook / deterministic check
  ↓
保证关键规则不能被绕过

---

Hooks：构建阶段的确定性护栏

Hooks 可以在 Agent 执行动作前后运行确定性脚本。

例如：

• 禁止修改生成代码目录；
• 禁止修改冻结模块；
• 文件修改后自动运行 formatter；
• 自动执行 linter；
• 阻止凭据进入 diff。

一个重要原则是：

高频 Build Hook
应尽量快速，并缩小到当前修改文件；完整测试等重操作更适合放在 Commit 或
PR 阶段。

---

Parallel Sessions 与 Subagents

AI 原生开发的另一个变化是工程师不再天然对应”一个人同时做一个任务”。

一个工程师可以：

Engineer
 ├── Claude Session A → feature-auth worktree
 ├── Claude Session B → rate-limit worktree
 └── Claude Session C → documentation worktree

每个 Session 在独立 Git worktree 中运行，减少文件冲突。

Anthropic 建议从两三个并行 Session 开始，而不是无限增加。

真正的上限不是模型能够开多少 Session，而是：

人还能高质量审阅多少条并行工作流。

重复性的工作则可以沉淀成 Subagent，例如：

• verifier；
• code simplifier；
• researcher。

工程师的角色由”执行者”逐步转向：

编写
  ↓
指导
  ↓
编排
  ↓
监控自主循环

---

04 Test：让 Agent 自己形成反馈闭环

Give the agent a feedback loop

AI 原生测试的核心不是”让 AI 生成更多测试用例”。

真正重要的是：

Agent 每次工作都必须拥有验证自己结果的方法。

例如：

• 单元测试；
• Integration Test；
• Build；
• Lint；
• API 响应；
• Screenshot Diff；
• 浏览器自动验证。

传统模式中，错误信号可能在几分钟后的 CI、几天后的
QA，甚至几周后的生产环境才出现。

Agent 的代码生产速度越快，延迟反馈的代价就越高。

因此反馈必须尽可能靠近代码生成。

Bug Fix 的推荐模式

Bug
 ↓
先让 Agent 写出能够稳定复现 Bug 的失败测试
 ↓
确认测试确实失败
 ↓
Commit test
 ↓
禁止 Agent 修改该测试
 ↓
修改业务代码
 ↓
直到测试通过

这里尤其重要的是：

Agent 不应该通过修改验证标准来”证明自己正确”。

因此可以使用 Hook 在 Fix Task 中禁止修改测试文件。

---

UI 也要形成视觉闭环

UI 工作不能只靠代码编译成功判断。

Agent 应获得：

• Browser Tool；
• Screenshot Tool；
• Design Mock。

然后执行：

Implement
   ↓
Screenshot
   ↓
Compare
   ↓
Adjust
   ↓
Screenshot
   ↓
...

视觉验证成为 Agent Runtime 的反馈信号。

---

Continuous Evals in CI

Anthropic 把 Evals 看作 AI 原生时代对应传统阶段式 QA 的重要机制。

当以下内容发生变化：

• Model；
• Prompt；
• CLAUDE.md；
• Skills；
• Hooks；

都可能改变 Agent 的行为。

因此，Agent 配置本身也需要 Regression Testing。

可以从近期真实工作中抽取 20～50 个任务，形成 Eval Suite：

task
+ expected outcome
+ tests
+ lint
+ behavior check
+ policy check

然后在 CI 中持续执行。

一个非常关键的实践是：

每一次生产事故，都应该转化成新的 Eval Case，并永久留在回归集合中。

于是：

Production Incident
        ↓
Root Cause
        ↓
Fix
        ↓
Eval Case
        ↓
Permanent Regression Protection

---

05 Deploy：Agent 做到生产门禁之前，人负责越过关键门禁

AI 进入 PR Review Loop

Claude 既可以：

• Review 别人的 PR；
• 也可以处理自己 PR 上收到的 Review Comment。

所有 PR 可以接受统一的多轮 Review：

Bugs
Security
Compliance
Spec consistency
Plan consistency

发现项按严重程度排序。

人的 Review 重心因此可以上移到：

• 是否符合原始意图；
• 行为是否正确；
• 风险是否可以接受。

而不是把大量时间消耗在机械问题上。

组织可以使用 REVIEW.md 明确：

• Review Pass；
• 什么叫 Important；
• 什么只是 Nit；
• 哪些目录无需报告；
• 哪些问题 CI 已经负责。

Separation of Duties

AI 原生并不意味着取消职责分离。

相反：

写代码的 Agent 不应该有权批准自己产生的代码。

最终批准仍通过 Branch Protection 等机制由人完成。

PR History 则成为：

• Agent Findings；
• Fix；
• Human Approval；
• Audit Evidence

的统一记录。

---

Hooks as Approval Gates

Hook 不仅可以 Allow / Block，也可以 Ask。

因此它可以把传统审批规则变成代码化门禁。

例如生产部署：

Agent requests production deploy
           ↓
Hook
           ↓
Release approval exists?
      ┌────┴────┐
     Yes       No
      ↓         ↓
    allow      block

团队级 Hook 可以进入仓库配置。

不可妥协的企业级 Hook，则应该通过 Managed Settings
管理，使普通工程师无法关闭。

这实际上是在把：

Governance by meeting

逐步转变为：

Governance as executable policy

---

受监管企业的 Managed Settings

对于大型受监管企业，Anthropic 强调通过集中式设置控制：

• Agent 可以读取哪些文件；
• 可以执行哪些 Shell 命令；
• 是否允许网络访问；
• Sandbox 是否强制；
• 是否可以读取凭据；
• 哪些 Hooks 可以运行；
• 哪些 MCP Server 可以使用；
• 哪些插件和 Skills 可以安装；
• Claude Code 最低允许版本。

核心思想是：

Agent 的能力边界应该是显式
Allowlist，而不是默认拥有整个工程环境的权限。

---

CI/CD Integration

Claude Code 可以 Non-interactive 方式运行在 Pipeline 中。

建议逐级增加自治程度。

第一阶段：

read-only judgment

例如：

• 分析失败 Build；
• 总结 Flaky Test；
• 生成 Changelog。

第二阶段：

write behind existing gates

例如：

• 修复 Lint；
• 更新生成文档；
• 自动响应 Review Comment。

所有写操作仍然通过 PR 和 Branch Protection。

Sandbox

长时间运行的 Agent Job 应：

• 在 Container / Sandbox 中运行；
• 使用短生命周期 Token；
• 使用最小权限；
• 默认不持有生产凭据。

MCP for Deployment

部署能力不应只是给 Agent 一个拥有生产凭据的 Shell。

更好的方式是把：

deploy
status
rollback

作为有权限范围的 MCP Tools 暴露。

Autonomy by Environment

不同环境拥有不同自治级别：

Development → 高自治
Staging     → 中等自治
Production  → 人工授权

一个非常值得强调的原则是：

Rollback 应该成为整个 Pipeline 中演练最充分的路径之一。

因为真正的自主闭环最终一定依赖可靠回滚。

---

06 Maintain：真正闭合 SDLC 循环

前五个阶段仍然主要讨论”人在某个位置启动 Claude”。

Maintain 阶段则进一步：

让 Trigger 自主启动 Agent。

例如：

• Control Band Breach；
• Bug Ticket；
• Channel Message；
• Schedule；
• Security Finding。

传统维护：

Alert
 ↓
等人看到
 ↓
分析
 ↓
建 Ticket
 ↓
排期
 ↓
重新进入 SDLC

AI 原生维护：

Trigger
 ↓
Agent diagnosis
 ↓
gated action
 ↓
intent.md
 ↓
Plan
 ↓
Design
 ↓
Build
 ↓
Test
 ↓
Review
 ↓
Deploy

人的角色变成对自动形成的工作进行 Triage 和
Review，而不再必须亲自启动每一个流程。

---

Closing the Loop：确定性检测 + Agent 响应

Anthropic 特别强调：

检测异常本身最好保持 deterministic。

例如监控：

• CI Test Failure Rate；
• 发布后 5xx Rate；
• PR Cycle Time。

使用滚动窗口、均值、标准差和 Western Electric 等规则形成 Control Bands。

示意：

metric: ci_test_failure_rate
baseline: rolling_30d
rules: western_electric
tiers:
  1sigma:
    action: log
  2sigma:
    action: diagnose
  3sigma:
    action: propose

模型不负责决定”有没有越线”。

确定性系统先判断越线，再决定是否调用 Agent。

例如：

1σ → 记录
2σ → Claude 只读诊断
3σ → Claude 可以提出 PR 或执行预批准 Runbook

这形成了非常重要的架构边界：

Deterministic Detection
        ↓
AI Diagnosis / Reasoning
        ↓
Deterministic Permission Boundary
        ↓
Human / Automated Gate

---

生产异常重新成为 intent.md

Agent 完成诊断后，把结果写成新的 intent.md，其中包括：

• 异常；
• 证据；
• 建议结果；
• 受影响系统；
• 未解决问题。

于是生产运行数据真正回到了研发起点：

Production
   ↓
Observe
   ↓
Anomaly
   ↓
Diagnosis
   ↓
intent.md
   ↓
SDLC
   ↓
Production

SDLC 从线性 Pipeline 变成持续运行的 Loop。

---

Recurring Codebase Scans

安全扫描同样可以从”发布前的一次活动”变成持续运行的能力。

代码一直变化，模型能力也一直变化，因此一次安全扫描很快就会过期。

AI 原生方式是：

Scheduled Scan
     ↓
Finding
     ↓
Confidence / Validation
     ↓
small fix → PR
large issue → intent.md
     ↓
Review Gate
     ↓
Fix
     ↓
Eval

确定性的 SAST、依赖扫描等机制仍然保留。

模型驱动扫描用于补充传统规则难以覆盖的上下文相关漏洞。

---

Claude on Call

事故还可能来自 Slack、Teams 等协作渠道。

Agent 可以作为具有独立身份的参与者加入事故 Channel：

Incident message
      ↓
Agent investigates
      ↓
reads channel context
      ↓
queries systems through MCP
      ↓
proposes / performs gated action
      ↓
verifies recovery
      ↓
writes post-mortem

Channel History 本身成为事故审计记录的一部分。

小而边界明确的问题可以直接形成 PR。

更大的问题则进入：

intent.md → Stage 1

循环由此再次启动。

---

核心结论

Anthropic 的 AI-Native SDLC Playbook 并不是简单提出：

“让 Claude 参与软件研发的每一个阶段。”

它真正描绘的是研发生产方式的几次结构性迁移。

1. 从 Human-driven 转向 Artifact-driven

过去：

人 → 人 → 人 → 人

未来：

Artifact → Agent → Artifact → Gate → Agent

人集中处理需要判断的地方。

---

2. 从 Documentation for Humans 转向 Context for Agents

传统知识：

Wiki
Document
人的经验

开始转化为：

CLAUDE.md
Skills
REVIEW.md
Hooks
Agent definitions
Evals

组织知识第一次成为直接影响 Agent 行为的运行时资产。

---

3. 从阶段式测试转向 Continuous Feedback + Evals

测试不再只是 Build 之后的一个阶段。

它成为 Agent 每一次执行中的反馈信号：

Generate
 ↓
Verify
 ↓
Feedback
 ↓
Repair
 ↓
Verify

而 Agent 本身的配置也需要 Eval。

---

4. 从人工治理转向 Policy as Code

治理没有消失。

变化的是治理方式：

Policy
 ↓
Skill
 ↓
Hook
 ↓
Permission
 ↓
Sandbox
 ↓
PR Gate
 ↓
Human Judgment

确定性的事情尽可能机器执行，需要判断的事情留给人。

---

5. 从线性 SDLC 转向 Autonomous Loop

最终形态不是：

Plan → Design → Build → Test → Deploy → Maintain

而是：

                 ┌───────────────┐
                 │               │
                 ▼               │
Intent → Spec → Plan → Build → Test
  ▲                              │
  │                              ▼
Observe ← Production ← Deploy ← Review

生产系统不断产生新的信号。

信号经过确定性检测、Agent 分析、权限门禁和人工判断，又重新形成新的
Intent。

---

结语

随着模型和 Agent Harness 能力持续提升，AI
的影响范围正在从”如何生产代码”扩大到”如何组织整个软件研发生命周期”。

但这并不意味着 Human-in-the-loop 会消失。

相反，人的位置正在上移：

Execution
   ↓
Supervision
   ↓
Judgment
   ↓
Governance

未来高效的软件工程体系，很可能不是”让人和 AI
一起写更多代码”，而是建立一套能够让 Agent
持续运行，同时让人的判断、责任、治理和审计始终位于其上的研发系统。

循环持续运行，而人的判断始终位于循环之上。

---

参考资料

• Anthropic, The AI-Native SDLC Playbook, Louis Claxton, 2026-08-21
• 原文：https://claude.com/blog/the-ai-native-sdlc-playbook

版权说明

本文依据 Anthropic 于 2026 年 8 月 21 日发布的《The AI-Native SDLC Playbook》整理。

原文作者：Louis Claxton
原文标题：The AI-Native SDLC Playbook
原文地址：https://claude.com/blog/the-ai-native-sdlc-playbook