Anthropic 在 《AI-Native SDLC Playbook》 中将软件开发生命周期划分为 6 个连续递进的阶段。整套体系的核心机制在于：以 Git 仓库为中心，上一个阶段生成的 Markdown 规范文件作为下一个阶段 Agent 执行的精确 Prompt 和约束条件（Inputs）。

以下是 Stage 1 至 Stage 6 的全流程详细拆解：

🔄 Stage 1: 捕获意图 (Capture Intent)

• 核心目的：将业务人员或开发者的原始想法/痛点转化为结构化、去模糊化的需求声明。

• 输入文件 (Inputs)：

• 原始诉求：人类用户的自然语言描述（口头想法、客服反馈、Slack 讨论、故障报告等）。

• 需求模板：仓库内置的 templates/intent.md（定义标准字段结构）。

• 输出文件 (Outputs)：

• intent.md：包含问题定义（Problem）、期望结果（Proposed Outcome）、受影响的用户/系统（Scope）、约束条件（Constraints）与待解决问题（Open Questions）。

• Agent 运作机制：

• Brainstorming Agent（头脑风暴 Agent） 充当业务分析师（BA）。它不会直接写代码，而是通过多轮对话引导人类 clarifying 需求边界。

• 补全结构后，Agent 自动格式化并提交 intent.md 至仓库分支，触发人类评审（PO/PM Review）。

📐 Stage 2: 技术设计 (Technical Design)

• 核心目的：探究现有的代码库，确定“在已有代码架构下该如何落地”，将业务意图转化为技术设计规范。

• 输入文件 (Inputs)：

• intent.md（上一阶段通过审查的意图文件）。

• 上下文规范：仓库根目录的 CLAUDE.md（项目架构原则、代码库导航指南、编码规约）。

• 现有代码库：项目所有的源码与配置文件。

• 输出文件 (Outputs)：

• spec.md：包含技术方案、数据模型变更、 API 契约设计、依赖库引入策略以及架构层面的权衡选择（Trade-offs）。

• Agent 运作机制：

• Architect Agent（架构师 Agent） 深度阅读代码库与 intent.md。

• 它通过分析现有的模式与 API，设计出符合项目原有风格的方案，并输出 spec.md。

• 人类资深工程师对 spec.md 进行审查（Upstream Review），确保架构设计合理，避免后期产生不可控的大规模重构。

📝 Stage 3: 实施计划 (Implementation Planning)

• 核心目的：把宏大的技术设计图纸（spec.md）拆解为 Agent 可以一步步无歧义执行的自动化任务清单。

• 输入文件 (Inputs)：

• intent.md & spec.md。

• 相关源码路径：与即将修改的模块直接相关的现有代码文件。

• 输出文件 (Outputs)：

• plan.md：包含由原子化任务（Atomic Tasks）组成的 Markdown 清单。每个 Step 都附带具体的修改目录、验收标准及对应的测试策略。

• Agent 运作机制：

• Planning Agent（计划 Agent） 将技术设计翻译成具体的文件修改步骤。

• Agent 必须遵守 “小步快跑/原子化变更” 原则，将庞大的需求切分为相互独立、可验证的小步骤，以便随后的编码 Agent 能够安全执行。

💻 Stage 4: 代码生成与实现 (Execution & Coding)

• 核心目的：由 Agent 自动化编写代码并持续通过本地测试，直到满足实施计划的要求。

• 输入文件 (Inputs)：

• plan.md（作为指令基准）。

• spec.md & CLAUDE.md。

• 领域/技能库：内置的 Claude Skills（如项目特有的 Linting 规则、脚手架工具生成器等）。

• 输出文件 (Outputs)：

• 代码变更 (Git Diff)：包含修改/新增的业务代码。

• 自动化测试代码：同步生成的单元测试（Unit Tests）与集成测试（Integration Tests）。

• Agent 运作机制：

• Coding Agent（编码 Agent） 按照 plan.md 中的步骤单任务运行。

• 构建-测试-修复循环 (Build-Test-Fix Loop)：Agent 编写完一段代码后，会自动调用终端运行 npm test 或 pytest。若报错，Agent 读取控制台错误栈，自主修改代码，直到测试全绿。

🔍 Stage 5: 验证与评估 (Verification & Evals)

• 核心目的：验证代码不仅“能跑通”，而且符合安全、性能要求并精准满足了最初的意图（Intent）。

• 输入文件 (Inputs)：

• Stage 4 产生的代码 Diff。

• intent.md（做意图对齐）。

• Evals 测评集：仓库中的黑盒/白盒自动化评估脚手架及静态扫描工具。

• 输出文件 (Outputs)：

• eval_results.json 或 review_report.md：测试覆盖率、性能 benchmark 报告、安全静态扫描结果、代码风味评估。

• Agent 运作机制：

• Reviewer / Eval Agent（审查与测评 Agent） 独立于 Coding Agent 运行（避免“自己检查自己”的偏误）。

• 它基于最初的 intent.md 执行语义匹配校验，运行安全扫描与性能 Evals。如果发现违规或遗漏，Agent 将自动在 Pull Request (PR) 上挂载带有上下文信息的 Comment，提示人类或返工。

🚀 Stage 6: 部署与自愈反馈 (Deploy & Feedback Loop)

• 核心目的：部署上线并持续监控运行状况；当产生异常时，自动发起新的反馈循环。

• 输入文件 (Inputs)：

• 已通过验证并被人类批准 Merge 的主干代码。

• 线上监控与日志（Telemetry / Datadog / Sentry Log）。

• 输出文件 (Outputs)：

• 部署产物（如 Docker 镜像、云服务更新）。

• **自动生成的全新 intent.md**（若线上发现崩溃或指标异常）。

• Agent 运作机制：

• CI/CD Agent 触发部署流水线。

• Monitoring Agent（监控自愈 Agent） 持续监听线上运行指标。一旦监控到错误率突破阈值，Agent 抓取 Exception 堆栈日志，自动提炼出诊断报告，并直接**在 Git 中生成一份修复类的 intent.md**，重新喂入 Stage 1，形成全生命周期的自愈闭环。

📊 全流程链条概览 (Artifact Chain Summary)