AI原生软件开发生命周期
AI-Native SDLC：当 AI 不再只是写代码，软件开发流程将如何重构？
基于 Anthropic《The AI-Native SDLC Playbook》的系统解读
一、AI Coding 真正改变的，不只是写代码的速度
过去几年，AI Coding 最直观的变化是：AI 开始能够直接阅读代码、修改文件、运行测试、提交 Pull Request，甚至完成越来越复杂的软件开发任务。
但 Anthropic 在《The AI-Native SDLC Playbook》中提出了一个更加重要的问题：
如果 AI 已经能够极大幅度压缩“写代码”这个环节，那么为什么软件开发整体效率仍然没有按照同样的速度提升？
答案是：代码已经不再是最大的瓶颈。
传统软件开发生命周期通常包含 Planning、Design、Build、Test、Deploy、Maintain 六个阶段。过去，Build 往往是整个流程中最耗时、最昂贵的环节，因此大量流程设计都是围绕“如何让工程师更高效地写代码”建立起来的。
但是，当 Agent 可以在几个小时甚至更短时间内完成过去需要数天、数周才能完成的代码工作后，瓶颈就发生了转移。
Anthropic 将新的瓶颈概括为三个方面：
- Build 左侧的流程仍然运行在人类速度上——需求澄清、设计、计划仍然需要大量人工沟通。
- Build 右侧的流程仍然运行在人类速度上——测试、Code Review、发布、治理仍然按照传统人工产出速度设计。
- 传统治理机制开始与 AI 产出速度不匹配——如果 Agent 一次生成大量代码，而安全团队、架构师、Reviewer 仍然逐行人工审查，最终一定会形成新的排队瓶颈。
例如，一个安全团队原本按照“工程师每天提交几十行或几百行代码”的速度设计审核能力。但当 Agent 可以同时生成几十个 PR 时，安全审查队列就会迅速积压。
因此，真正需要改变的不是：
“让 Claude 写代码更快。”
而是：
“让整个软件开发生命周期适应 AI 的生产速度。”
这就是 AI-Native SDLC 的出发点。
二、什么是 AI-Native SDLC？
传统 SDLC 更像一条流水线：
Idea
↓
Requirements
↓
Design
↓
Development
↓
Testing
↓
Deployment
↓
Maintenance
每个阶段通常由不同角色负责：
- Product Manager 负责需求
- Architect 负责设计
- Engineer 负责开发
- QA 负责测试
- Release Team 负责发布
- Operations 负责生产运维
阶段之间通过：
- 文档
- Jira Ticket
- PRD
- 设计稿
- 会议
- 审批
- Sign-off
进行交接。
这种模式的核心特征是：
人完成工作，人把工作交给下一个人。
AI-Native SDLC 则试图把它变成：
┌──────────────┐
│ Plan │
└──────┬───────┘
↓
┌──────────────┐
│ Design │
└──────┬───────┘
↓
┌──────────────┐
│ Build │
└──────┬───────┘
↓
┌──────────────┐
│ Test │
└──────┬───────┘
↓
┌──────────────┐
│ Deploy │
└──────┬───────┘
↓
┌──────────────┐
│ Maintain │
└──────┬───────┘
│
└──────────→ 新的 Intent
因此它不再是一条单向流水线，而是一个闭环系统。
最重要的变化是：
每一个阶段结束时，都产生一个下一阶段可以直接读取的、版本化的 committed artifact。
Anthropic 将这些 artifact 串成一条完整的审计链：
intent.md
↓
spec.md
↓
plan.md
↓
Code + Tests
↓
PR + Review Findings
↓
Incident Record
↓
新的 intent.md
这条链既是开发流程，也是组织的 Audit Trail。
三、AI-Native SDLC 的六个阶段
Anthropic 将整个 Playbook 分成六个阶段：
| 阶段 | 核心问题 | 关键 Artifact |
|---|---|---|
| Plan | 我们到底想解决什么问题？ | intent.md |
| Design | 系统应该具体是什么样？ | spec.md |
| Build | 在当前代码库里如何实现？ | plan.md + Code |
| Test | 如何证明 Agent 做对了？ | Tests + Evals |
| Deploy | 如何安全地让代码进入生产？ | PR + Review + Hooks |
| Maintain | 生产问题如何自动重新进入开发流程？ | 新的 intent.md |
这六个阶段不是严格的线性流程，而是一个循环。
下面逐个展开。
四、Stage 1：Plan——从“需求管理”转向“Intent Capture”
4.1 核心思想：不要让一个想法在组织里传递很多次
传统软件开发中，一个人的想法通常会经历：
业务人员
↓
口头描述
↓
需求会议
↓
产品经理
↓
PRD
↓
需求评审
↓
User Story
↓
工程师
问题在于：
每经过一次转述，原始意图都有可能发生变化。
Anthropic 的解决方式是：
让提出想法的人直接和 Claude 对话，把自己的想法形成
intent.md。
这里的 intent.md 是一个 Proto-Spec。
它不需要一开始就写成专业 PRD，也不要求提出需求的人懂技术。
4.2 intent.md 应该记录什么？
典型内容包括：
- Problem：当前有什么问题？
- Proposed outcome：希望得到什么结果？
- Affected users：谁受到影响？
- Affected systems：哪些系统可能涉及？
- Constraints：有哪些约束？
- Open questions：哪些问题尚未确定？
例如：
# Intent: claims status self-service
## Problem
Customers frequently call the contact center
to ask about their claim status.
## Proposed outcome
Customers can see claim status,
next step and expected date in the portal.
## Affected users and systems
Claims handlers
Portal team
Claims API
## Constraints
Existing authentication only.
No new PII in the portal session.
## Open questions
Do third-party loss adjusters need access?
注意：
这里并没有讨论 React、API、数据库、微服务、缓存等技术细节。
因为此时最重要的是保存：
“提出这个需求的人到底想要什么。”
4.3 Plan 阶段的完整流程
Anthropic 建议：
Step 1：Originator 描述问题
提出需求的人用自己的语言告诉 Claude：
- 现在不能做什么
- 谁受到影响
- 什么情况下会更好
- 什么不在范围内
Step 2：Claude 追问
Claude 像一个分析师一样询问：
- 用户是谁？
- 范围是什么？
- 约束是什么？
- 成功标准是什么？
Step 3：Claude 生成 intent.md
使用组织统一模板。
Step 4：Originator 修改
人检查 Claude 有没有理解错误。
Step 5：提交 Git
intent.md 进入版本控制。
Product Owner 在这里做第一次真正的决策：
Accept / Reject
如果接受，就自动进入 Design 阶段。
五、Stage 2：Design——Requirements 和 Design 合并
传统开发通常是：
Requirements
↓
Analyst
↓
Requirements Document
↓
Designer / Architect
↓
Design
Anthropic 希望把这两个阶段压缩成一个 Agent Session。
5.1 从 intent.md 生成 spec.md
当 Product Owner 接受 intent.md 后：
intent.md
↓
Claude
+
Brand Skills
Security Skills
Compliance Skills
UX Skills
↓
spec.md
Claude 不只是“扩写需求”。
它还要同时考虑组织中的各种约束。
例如：
- 品牌规范
- 安全规范
- 合规要求
- UX 规范
- 架构原则
因此 spec.md 是：
经过组织规则约束后的 Requirements + Design。
六、intent.md、spec.md、plan.md 的真正区别
这三个文件是理解整个 Playbook 的关键。
可以把它们理解成三层“编译”。
第一层：Intent
我要解决什么问题？
第二层：Specification
我们决定系统最终应该是什么样。
第三层：Plan
在当前代码库里，我们具体怎么实现。
因此：
intent.md
↓
人的原始意图
spec.md
↓
经过需求分析、设计和组织约束后的系统规格
plan.md
↓
针对当前代码库的具体实施方案
这三个阶段实际上是在不断减少不确定性。
七、Design 阶段的关键机制：把 Policy 前置
传统开发的问题是：
先设计
↓
先开发
↓
最后 Security Review
↓
发现违反政策
↓
返工
AI-Native SDLC 希望变成：
intent
↓
spec
↑
Security Skill
Compliance Skill
UX Skill
Brand Skill
↓
工程师
也就是说：
政策不是在最后检查，而是在 Agent 生成设计的时候就作为约束进入上下文。
这就是 Anthropic 所说的：
Policy is applied while the spec is written, not discovered in a review weeks later.
八、Stage 3：Build——没有批准的 Plan，不应该直接写代码
这是 Claude Code 最核心的一环。
工程师拿到批准后的：
intent.md
spec.md
进入 Claude Code Plan Mode。
此时 Claude 可以：
- 阅读整个代码库
- 分析架构
- 查找相关文件
- 分析依赖关系
- 研究测试
- 判断哪些文件需要修改
但是：
Claude 此时不应该直接修改代码。
它首先生成：
plan.md
九、plan.md 是什么？
一个好的 plan.md 至少需要说明：
- 修改哪些文件
- 修改顺序
- 实现方式
- 风险
- 测试方式
- 验证标准
例如：
# Plan
## Files that change
StatusPanel.tsx
routes/status.py
test_status.py
## Order of work
1. Add status endpoint.
2. Add UI panel.
3. Connect portal navigation.
## Risks
Claims API rate-limits at 50 rps.
## Proof
All four claim states are tested.
Screenshot matches approved mock.
十、Plan Mode 的真正价值：把设计评审提前到写代码之前
传统流程：
工程师开始写代码
↓
写了几百行
↓
提交 PR
↓
Reviewer 才发现方案有问题
AI-Native：
spec.md
↓
Claude 分析代码库
↓
plan.md
↓
Engineer Review
↓
Code
这样做的核心价值是：
设计错误发生在最便宜的时候。
修改 plan.md 很便宜。
修改几百个文件很昂贵。
Anthropic 因此要求：
一个从来没有参与过这次对话的工程师，仅凭
plan.md就应该能够实施这个修改。
如果做不到，就继续迭代 Plan。
十一、代码实施与 Plan 的一致性
还有一个很重要的原则：
如果代码实现偏离了 Plan，就同步更新
plan.md。
也就是说：
plan.md
↓
Code
不是：
plan.md
↓
Code
↓
Plan 被遗忘
而应该始终保持：
plan.md ←→ Code
这样后续 Code Review 才能检查：
实际实现是不是我们原来决定要实现的东西？
十二、Build 阶段的三个关键基础设施
Anthropic 在 Build 阶段进一步提出了三个非常重要的机制：
1. CLAUDE.md
把过去存在于：
- 工程师脑子里
- Wiki
- onboarding 文档
- Slack
- 经验
中的知识变成 Agent 可以直接读取的文件。
例如：
# Payments Service
## Commands
make build
make test
make lint
## Conventions
Java 21
Spring Boot 3
Money always uses BigDecimal.
Every endpoint needs integration tests.
## Architecture
api/
core/
adapters/
## Things Claude gets wrong
Don't modify v1/.
Don't bump dependency versions.
Anthropic 建议 CLAUDE.md 尽量简洁，保持在大约一页以内，并且：
当 Claude 犯了两次同样的错误，就把修正写进
CLAUDE.md。
于是：
Agent犯错
↓
人修复
↓
写入CLAUDE.md
↓
未来Agent不再犯
它逐渐成为团队的“机器可读工程知识库”。
十三、Skills：把组织知识变成可执行规则
CLAUDE.md 适合：
“这个代码库应该怎么工作？”
而 Skill 更适合：
“这条组织规则必须在特定场景反复执行。”
例如：
secure-api-review/SKILL.md
规定：
- API 必须 JWT
- 必须做输入验证
- 状态变化必须产生 Audit Event
- PII 不得进入日志
于是：
组织政策
↓
Skill
↓
Claude
↓
代码
Skill 的价值在于：
把 Institutional Knowledge 从“文档”变成“Agent 能执行的知识”。
十四、Skill 不是绝对安全控制
Anthropic 特别强调：
Skill 本身主要是 Advisory Control。
也就是说：
Skill
↓
提醒 Agent 遵守政策
但 Agent 并不一定百分之百服从。
如果某条规则：
必须始终成立
就应该进一步建立：
Skill
+
Hook
Skill 负责让违规变少。
Hook 负责让违规变得困难甚至不可能。
十五、Hooks：把治理规则变成机器闸门
Hook 是 AI-Native SDLC 非常重要的基础设施。
它可以：
- Block
- Allow
- Ask for approval
例如：
Claude
↓
准备执行 production deploy
↓
Hook
↓
检查 RELEASE_APPROVAL
↓
没有批准 → BLOCK
有批准 → ALLOW
因此治理不再只是：
“请大家遵守规范。”
而变成：
“Agent 每次行动时，系统自动检查。”
例如可以阻止：
- 修改 protected path
- 修改冻结代码
- 修改测试文件
- 访问 secrets
- 生产环境部署
- 未经审批修改 infrastructure
十六、Parallel Sessions：一个工程师管理多个 Agent
当 Agent 的单个任务越来越快后，新的问题出现：
如果一个 Agent 很快完成一个任务，工程师为什么还要一次只做一件事？
Anthropic 因此提出：
Engineer
├── Claude Session A
│ └── feature-auth
│
├── Claude Session B
│ └── rate-limit
│
└── Claude Session C
└── test-fix
每个 Session 使用独立 Git Worktree：
main repo
├── worktree A
├── worktree B
└── worktree C
避免不同 Agent 修改同一工作目录。
十七、Subagent 与 Parallel Session 的区别
这两个概念很容易混淆。
Parallel Session
是：
多个完整的 Claude Code 实例。
适合真正独立的任务。
Subagent
是：
一个 Claude Session 内部的专门助手。
例如：
Main Agent
├── Researcher
├── Verifier
└── Code Simplifier
Anthropic 的建议是：
独立任务 → Parallel Sessions
重复性辅助任务 → Subagents
最终工程师的角色逐渐从：
“写代码的人”
变成：
“管理多个 Agent 工作流的人”。
十八、Stage 4：Test——测试从“阶段”变成“持续反馈回路”
这是整个 Playbook 另一个非常重要的变化。
传统：
Code
↓
QA
↓
Test
AI-Native：
Agent写一点
↓
Test
↓
发现问题
↓
Agent修
↓
Test
↓
再修
↓
……
也就是说：
测试不再是 Build 结束之后的一个独立阶段，而是贯穿整个 Agent Session 的 Feedback Loop。
十九、让 Agent 自己验证自己的工作
Anthropic 给出的原则非常直接：
Always give Claude a way to verify its own work.
可以是：
- Unit Test
- Integration Test
- Build
- Lint
- Screenshot
- Browser Test
- API Test
关键是：
Agent 在把结果交给人之前，先自己证明它是工作的。
例如：
make build
make test
make lint
全部成功后，才报告：
Task completed.
二十、Bug Fix：先写一个失败测试，再让 Agent 修
这是一个非常值得借鉴的实践。
对于 Bug：
Bug
↓
Claude reproduces bug
↓
写 failing test
↓
运行
↓
确认确实失败
↓
commit test
↓
Claude 修改代码
↓
test pass
关键是：
Agent 不能通过修改测试本身来让测试通过。
因此可以使用 Hook：
Fix Task
↓
禁止修改 Test File
这样：
旧测试
+
新代码
↓
PASS
才是真正的证据。
二十一、UI 开发：让 Agent 看自己的结果
对于前端开发，Anthropic 特别强调视觉反馈：
Implement
↓
Screenshot
↓
Compare with Mock
↓
Adjust
↓
Screenshot
↓
Compare
通常迭代两三轮。
这意味着 Agent 不只是：
“写 React。”
而是：
实现 → 观察 → 判断 → 修改。
这实际上已经非常接近 Agentic Development 的基本闭环。
二十二、Continuous Evals：AI Agent 也需要自己的“回归测试”
传统软件：
Code changes
↓
Regression Tests
AI 系统还有一个额外的问题：
模型、Prompt、Skill、CLAUDE.md、Hook 的变化，都可能改变 Agent 行为。
因此 Anthropic 提出了：
Continuous Evals
可以理解为：
Agent Configuration
↓
Evals
↓
Pass / Fail
例如收集最近真实工作的 20～50 个任务：
Task 1 → Expected Result
Task 2 → Expected Result
...
Task 50 → Expected Result
然后每次修改：
CLAUDE.md- Skill
- Hook
- Prompt
- Agent 配置
都重新跑一遍。
于是：
Agent 的配置本身也开始像代码一样拥有 Regression Test。
二十三、Stage 5：Deploy——Code Review 也必须 AI-Native
当 Agent 开始大量写代码之后：
逐行人工 Review 就会成为新的瓶颈。
Anthropic 的解决方案不是取消 Code Review，而是：
让 Agent 先完成机械性 Review，人类把注意力提升到更高层次。
二十四、AI PR Review
Anthropic 建议每个 PR 自动进行多个 Review Pass。
例如：
Pass 1：Bug
检查：
- Logic Error
- Edge Case
- Regression
Pass 2：Security
检查：
- Injection
- Authentication
- PII Leakage
Pass 3：Compliance
检查：
spec.md
plan.md
Design Principles
二十五、人的 Review 重点发生变化
过去：
“这行代码写得对不对？”
现在：
“这个系统到底应该这样工作吗？”
也就是说：
AI Review
↓
Mechanical correctness
↓
Human Review
↓
Intent + Risk
人的注意力从：
Implementation
提升到：
Judgment
这也是 AI-Native SDLC 中最核心的“Human in the Loop”思想。
二十六、Review 发现的问题要反哺 CLAUDE.md
Anthropic 给出了一个非常漂亮的闭环：
PR Review
↓
发现错误
↓
修复
↓
如果同类错误第二次出现
↓
更新 CLAUDE.md
↓
下一次 Agent 工作时自动知道
↓
Review finding减少
因此：
Review 不只是检查代码，也是训练组织工作流的过程。
组织会越来越聪明。
二十七、Hooks：把人类审批变成真正的“闸门”
传统审批：
Agent
↓
问人
↓
人点击确认
在大规模并行 Agent 场景下会非常痛苦。
因此 Anthropic 建议：
只有真正需要人的地方才保留人工 Gate。
例如：
Development
Agent → 自动
Staging
Agent → 有限自动
Production
Agent → 准备好 → Human Approval
因此不是：
Human approves every action
而是：
Human approves high-risk transitions.
二十八、CI/CD：让 Agent 进入流水线
Agent 不应该只能在开发者电脑里运行。
Anthropic 建议：
GitHub / GitLab CI
↓
Claude Code
↓
Sandbox
↓
MCP
↓
Build / Test / Deploy / Rollback
例如：
Build失败
↓
Claude读取日志
↓
判断可能原因
↓
写PR comment
进一步可以：
Lint失败
↓
Claude修复
↓
提交PR
但原则是：
Agent 可以一直工作到 Production Gate，但不能自动越过 Production Gate。
二十九、不同环境应该拥有不同自治等级
Anthropic 给出的原则非常重要：
Development
↓
高自治
Staging
↓
中自治
Production
↓
低自治 + 人工审批
因此：
Autonomy should be tiered by environment.
而不是：
全自动 / 全人工
二选一。
三十、Rollback 必须成为 Agent 最熟练的路径
如果未来 Agent 可以自主部署，那么最重要的问题之一就是：
“如果出问题怎么办？”
Anthropic 的答案是：
Rollback 必须是整个系统中最经过演练的操作。
例如：
deploy
↓
monitor
↓
异常
↓
rollback
而且 Agent 应该可以调用已经验证过的 rollback runbook。
因为 Stage 6 的自动维护机制可能在生产异常时直接触发 rollback。
三十一、Stage 6：Maintain——真正实现闭环
前五个阶段主要解决：
如何让一次开发任务更快完成？
第六阶段开始解决一个更大的问题：
能不能让整个软件开发系统自己持续运行？
这就是：
Closing the Loop
三十二、生产环境成为新的需求来源
传统：
生产出现问题
↓
Alert
↓
人看到
↓
人创建Ticket
↓
Product Manager
↓
需求流程
AI-Native：
Production
↓
Monitoring
↓
Detection
↓
Claude
↓
intent.md
↓
Plan
↓
Design
↓
Build
↓
Test
↓
Review
↓
Deploy
于是：
生产系统本身成为软件开发系统的输入。
三十三、关键原则：检测必须是 Deterministic
这是一个非常重要的工程原则。
Anthropic 并不是让：
LLM 判断什么时候发生异常。
而是：
Monitoring
↓
Deterministic Detection
↓
Threshold / Statistical Rule
↓
Claude
例如：
1σ → 只记录
2σ → Claude 只读诊断
3σ → Claude 可以提出行动
也就是说：
确定性系统负责决定“什么时候叫 Agent”；Agent 负责决定“发现问题以后怎么办”。
这是非常合理的职责划分。
三十四、异常最终重新变成 intent.md
假设：
Post-deploy 5xx
↑
超过控制阈值
Agent 进行诊断：
What happened?
Why?
Which systems?
Evidence?
Potential outcome?
Open questions?
然后写：
intent.md
接着重新进入：
Plan
↓
Design
↓
Build
↓
Test
↓
Deploy
于是整个 SDLC 变成：
┌───────────────────────────┐
│ │
↓ │
intent.md │
↓ │
spec.md │
↓ │
plan.md │
↓ │
Code │
↓ │
Tests │
↓ │
PR │
↓ │
Review │
↓ │
Deploy │
↓ │
Production │
↓ │
Monitoring │
↓ │
Incident ──────────────────────┘
这就是 Anthropic 所说的：
The loop keeps running. Human judgement stays above it.
三十五、定期安全扫描也应该进入这个循环
Anthropic 进一步把这一思想应用到 Security。
传统安全扫描：
发布前扫描
↓
产生报告
↓
人工处理
↓
下一次发布再扫描
问题是：
代码不断变化，模型也不断进化。
所以一次扫描很快就会过时。
AI-Native：
Scheduled Scan
↓
Findings
↓
Validation
↓
Confidence
↓
小问题 → PR
大问题 → intent.md
如果发现的问题可以通过一个 PR 解决：
Security Finding
↓
Claude Code
↓
Patch
↓
PR Review
如果是跨系统、架构级的问题：
Security Finding
↓
intent.md
↓
重新进入完整 SDLC
三十六、Incident 也可以直接从 Slack 等渠道进入闭环
Anthropic 最后展示了更进一步的场景：
Slack Incident Channel
↓
Claude
↓
Diagnose
↓
Investigate
↓
Fix / PR
例如晚上 10 点出现生产故障。
过去：
值班工程师
↓
看消息
↓
登录系统
↓
调查
↓
修改
AI-Native：
Incident Channel
↓
@Claude
↓
Claude读取上下文
↓
通过MCP查询系统
↓
分析
↓
提出方案
↓
执行允许的操作
↓
验证恢复
↓
记录结果
而这个 Channel 本身又成为 Audit Trail。
三十七、整个 AI-Native SDLC 的核心基础设施
如果把文章中出现的所有机制放在一起，可以得到一个非常完整的 Agent Engineering Stack：
┌──────────────────────┐
│ Human │
│ Judgment / Gates │
└──────────┬───────────┘
│
┌──────────────────────┴──────────────────────┐
│ │
↓ ↓
intent.md REVIEW.md
↓
spec.md
↓
plan.md
↓
┌─────────────────────────────────────────────┐
│ Agent Layer │
│ │
│ Claude Code │
│ Skills │
│ Subagents │
│ CLAUDE.md │
│ MCP │
└──────────────────────┬──────────────────────┘
↓
┌─────────────────┐
│ Hooks │
│ Allow / Ask / │
│ Block │
└────────┬────────┘
↓
┌─────────────────┐
│ Sandbox / │
│ Permissions │
└────────┬────────┘
↓
┌─────────────────┐
│ Code / Tests │
└────────┬────────┘
↓
┌─────────────────┐
│ CI/CD / PR │
└────────┬────────┘
↓
┌─────────────────┐
│ Production │
└────────┬────────┘
↓
┌─────────────────┐
│ Monitoring / │
│ Security Scan │
└────────┬────────┘
│
└──────→ intent.md
这已经不是简单的“AI Coding 工具”。
它更接近：
Agent Operating System for Software Engineering
三十八、Artifact 是整个体系真正的“主线”
如果只看 Claude Code、Skills、Hooks，很容易把这篇文章理解成一篇“Claude Code 企业部署指南”。
实际上不是。
文章最深层的设计是：
Artifact-driven SDLC
即：
每个阶段都产生一个明确的、版本化的、下一阶段可以读取的 Artifact。
核心链条：
Intent
↓
Specification
↓
Plan
↓
Implementation
↓
Test Evidence
↓
Review Findings
↓
Deployment
↓
Incident
因此任何一个变更都可以回答：
谁提出的？
为什么提出？
决定做什么？
为什么这样设计？
具体怎么实现？
改了什么？
测试了吗？
谁 Review？
谁批准？
什么时候发布？
上线之后怎么样？
这就是：
AI-Native Audit Trail
三十九、Source of Truth：现实企业不会因为 AI 出现就立刻放弃 Jira
Anthropic 也意识到企业现实非常复杂。
很多企业已经有：
- Jira
- ServiceNow
- Figma
- Requirements Management System
- Change Board
- Compliance System
这些系统不可能因为 Claude 出现就全部删除。
所以文章提出三个模式。
模式一：Repository 是 Source of Truth
Git
↓
intent.md
spec.md
plan.md
其他系统只引用 Git。
模式二：Legacy System 是 Source of Truth
例如：
Jira
↓
Claude
↓
spec.md
↓
Jira / MCP
Markdown 是工作副本。
模式三：至少建立双向 Linkage
例如：
Jira ID
↕
Git Commit SHA
即使暂时存在两个系统，也必须建立关联。
四十、真正的 Governance 不是“少用 AI”，而是“给 AI 建立边界”
这是文章非常重要的一个思想。
很多企业面对 Agent 时的第一反应是：
“AI 会不会乱改东西？”
传统答案可能是：
“那就让 AI 少做一点。”
Anthropic 的思路是：
不要简单限制 Agent，而是建立明确的控制边界。
主要手段包括：
1. Permissions
控制 Agent 能读什么、写什么。
2. Sandbox
控制 Agent 的运行环境。
3. Hooks
控制 Agent 每次行动。
4. Skills
给 Agent 组织规则。
5. CLAUDE.md
给 Agent 项目知识。
6. Review
让 Agent 产生的结果接受自动和人工检查。
7. Branch Protection
避免 Agent 直接进入 Main。
8. Human Approval
保留真正高风险的人工决策。
四十一、一个非常重要的原则：Human in the Loop ≠ Human in Every Step
这是整篇文章最值得总结的一点。
传统：
Human
↓
Approve
↓
Agent
↓
Human
↓
Approve
↓
Agent
↓
Human
如果一个工程师管理十个 Agent，这种模式会直接把人变成瓶颈。
AI-Native 更希望：
Agent
Agent
Agent
Agent
Agent
↓
自动执行
↓
自动测试
↓
自动Review
↓
自动修复
↓
Human
↓
判断 Intent
判断 Risk
判断 Release
也就是说：
人不再负责监视 Agent 的每一个动作，而是负责关键决策。
这就是：
Human Judgment stays above the loop.
四十二、AI-Native SDLC 的本质：从“Human-in-the-loop”走向“Human-on-the-loop”
可以把两者进行一个非常直观的比较。
Human-in-the-loop
Agent → Human → Agent → Human → Agent
人不断介入。
Human-on-the-loop
Human
↓
Rules / Gates
↓
Agent → Agent → Agent → Agent
↓
Result
↓
Human
人设计：
- 规则
- 权限
- Gate
- Policy
- Evaluation
- Exception handling
然后让 Agent 自主运行。
这其实是整篇文章真正想推动的软件工程组织形态。
四十三、如何理解 Anthropic 的最终目标？
如果把整个 Playbook 压缩成一句话：
Anthropic 并不是想让 AI 成为一个更快的程序员，而是想让 AI 成为整个 Software Development Lifecycle 的执行层。
传统：
人 → 人 → 人 → 人 → 人
AI-Native：
Human
↓
Intent
↓
Agent
↓
Agent
↓
Agent
↓
Agent
↓
Human
其中人负责：
Intent
Policy
Judgment
Risk
Approval
Agent 负责：
Research
Design
Coding
Testing
Review
Deployment Preparation
Monitoring
Diagnosis
而系统负责：
Permissions
Hooks
Sandbox
CI/CD
Evaluation
Audit
最终形成：
Human Judgment
↓
Agent Execution
↓
Deterministic Controls
↓
Continuous Feedback
↓
Human Judgment
四十四、我认为这篇文章最值得记住的十个结论
1. Code 不再是 SDLC 最大瓶颈
AI 把 Build 压缩之后，真正的瓶颈转移到了：
Plan、Review/Test、Deploy。
2. SDLC 从 Linear Pipeline 变成 Closed Loop
生产环境产生的新问题可以重新进入：
intent.md
然后重新走完整流程。
3. Artifact 比 Meeting 更重要
真正连接各阶段的不是会议，而是：
intent.md
spec.md
plan.md
Code
Tests
PR
Review
Incident
4. intent.md 保存“人想要什么”
它记录：
What / Why / Who / Constraints
5. spec.md 保存“组织决定做什么”
它是：
Requirements + Design + Policy Constraints
6. plan.md 保存“具体怎么做”
它结合：
Specification + Existing Codebase
7. CLAUDE.md 是机器可读的组织知识
把：
“老员工知道但文档没有写的东西”
逐渐转化成 Agent 可以直接读取的上下文。
8. Skills 是机器可执行的 Institutional Knowledge
把：
“组织要求所有人遵守的规则”
变成 Agent 每次执行任务时可以加载的规则。
9. Hooks 是真正的 Deterministic Control
Skill 只能提醒。
Hook 可以：
Allow / Ask / Block。
因此高风险规则必须落到确定性控制上。
10. Human 的价值从“执行”转向“判断”
未来优秀工程师不一定是：
写代码最快的人。
而更可能是：
最擅长定义问题、设计约束、构建 Agent 工作流、设置 Evaluation、判断风险和管理多个 Agent 的人。
四十五、最终模型：AI-Native SDLC 可以看成一个“软件工程操作系统”
如果让我用一张图总结整篇文章，我会画成：
HUMAN
│
┌────────────┴────────────┐
│ │
Intent Policy
│ │
↓ ↓
┌───────────┐ ┌───────────┐
│ intent.md │ │ Skills │
└─────┬─────┘ └─────┬─────┘
│ │
└──────────┬──────────────┘
↓
┌──────────┐
│ spec.md │
└────┬─────┘
↓
┌──────────┐
│ plan.md │
└────┬─────┘
↓
┌──────────────────┐
│ Agent Runtime │
│ │
│ Claude Code │
│ Subagents │
│ MCP │
│ CLAUDE.md │
└────────┬─────────┘
↓
┌──────────────────┐
│ Hooks / Sandbox │
│ Permissions │
└────────┬─────────┘
↓
Code + Tests
↓
CI / Evals
↓
AI Review
↓
Human Approval
↓
Deploy
↓
Production
↓
Monitoring / Security
↓
Incident
↓
intent.md
│
└───────────────┐
↓
Continuous Loop
这已经不是传统意义上的“AI 辅助开发”。
它是一种新的软件生产模式：
人定义目标和边界，Agent 执行工作，确定性系统负责约束，自动化评估负责验证，生产环境持续提供反馈，而整个过程通过版本化 Artifact 保留下来。
四十六、结语：真正的 AI-Native，不是“用 AI 写代码”
如果只把 AI 用在：
需求
↓
程序员
↓
Claude
↓
代码
那么你得到的只是：
AI-assisted Development
而 Anthropic 所描述的 AI-Native SDLC 是：
Intent
↓
Specification
↓
Plan
↓
Agentic Build
↓
Continuous Test
↓
Agentic Review
↓
Governed Deploy
↓
Autonomous Maintenance
↓
New Intent
↓
……
这两者的区别非常大。
前者只是：
AI 改变了一个环节。
后者则是：
AI 改变了整个软件生产系统。
因此，《The AI-Native SDLC Playbook》最值得关注的并不是某一个 Claude Code 功能，而是它提出的一种新的组织方式：
当代码生成成本急剧下降之后，软件工程的核心竞争力将逐渐从“写代码”转向“定义意图、设计约束、组织 Agent、建立验证体系以及进行高质量的人类判断”。
从这个角度看，intent.md、spec.md、plan.md 并不仅仅是三个 Markdown 文件。它们实际上构成了人与 Agent 之间的逐层编译接口：
人的意图
↓
intent.md
↓
系统规格
↓
spec.md
↓
工程方案
↓
plan.md
↓
代码
↓
运行结果
↓
新的问题
↓
新的 intent.md
而这，可能才是 AI-Native Software Engineering 最值得关注的地方：
未来的软件工程，不再只是“人写代码、AI帮忙”，而可能逐渐变成“人定义目标和边界，Agent运行整个软件生产循环”。
如果这篇文章帮助到了你，你可以请作者喝一杯咖啡
浙公网安备 33010602011771号