AI Coding 方法论调研

调研时间：2026-03 目标：梳理业界 AI 辅助软件开发的成熟方法论，为搭建全链路工作流（产品→设计→研发→测试）提供决策参考。

一、成熟方法论详细分析

1. BMAD-METHOD（Breakthrough Method for Agile AI-Driven Development）

出品方： 开源社区（visrow / Vishal Mysore） 协议： 免费开源 GitHub： bmad-code-org/BMAD-METHOD文档： docs.bmad-method.org

四阶段流程：

探索分析 → 规划 → 架构设计 → 实现

阶段	产出物	说明
探索分析	brainstorming-report.md, research-findings.md, project-brief.md	问题空间探索，1页项目简报
规划	PRD.md, ux-spec.md	功能需求、非功能需求、用户故事、验收标准、MVP 范围
架构设计	architecture.md, ADR-.md, epic-.md, story-*.md	组件图、数据流、架构决策记录、分片 Epic、超详细 Story
实现	代码 + 测试	按 Story 迭代交付，含代码审查和 QA 验证

9 个 Agent 角色：

角色	职责
Analyst (Mary)	头脑风暴、调研、创建项目简报
Product Manager (John)	简报→PRD，定义 Epic
Architect	系统架构设计、技术栈选择、ADR
Product Owner	文档对齐、大规格分片
Scrum Master	Epic→超详细 Story 文件（含完整上下文和验收测试）
Developer (Amelia)	按 Story 实现代码+测试
QA Engineer (Quinn)	自动生成测试、需求验证
Technical Writer (Paige)	部署指南、图表生成
BMad Master	协调器，按消息选择相关角色

Claude Code 集成：

bash

npx bmad-method install  # 自动在 .claude/skills/ 创建 30+ Skills

安装后可用：/bmad-analyst、/bmad-pm、/bmad-architect、/bmad-create-prd、/bmad-quick-dev 等。

Quick Flow 快速通道： 小任务可跳过前 3 阶段，用 /bmad-quick-dev 直接开发（< 5 分钟）。

优势：

文档即真相，减少 AI 幻觉
角色互审，结构化质量门禁
企业级数据：68% 开发提速、73% 减少 Bug（15+ 团队）
从 Bug 修复到企业系统均可适配

劣势：

小项目过重（文档开销大）
学习曲线中高（9 个角色需要理解）
Agent 间协调有时断档（跳过角色→后续缺上下文）
对老项目（brownfield）支持尚在完善
大型 PRD + 架构文档可能超过 50,000 token

2. Spec-Driven Development (SDD)

出品方： GitHub / 微软 工具： github/spec-kit参考： Martin Fowler 评测

四阶段流程：

Specify（规格） → Plan（计划） → Tasks（拆分） → Implement（实现）

阶段	产出物	说明
Specify	specification.md	用户旅程、工作流、成功指标（不含底层代码细节）
Plan	technical-plan.md	技术架构、依赖、设计模式、约束
Tasks	tasks.md	原子级、可并行的编码任务清单
Implement	代码 + 测试	按任务逐个实现，严格 TDD

关键概念 — constitution.md（宪法）：

不可违背的架构原则（如"每个功能必须先作为独立库"）
在 Plan 阶段自动进行合规审查（AI 扮演"合规官"角色）
确保一致性而无需人工逐条审查

测试集成：

强制 TDD（Red-Green-Refactor）
文件创建顺序：contract → integration → e2e → unit
验收标准按 31 条 IEEE/ISO 标准指标验证

安装：

bash

uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>

优势：

流程清晰，4 阶段线性推进
constitution.md 自动治理，减少人工审查
轻量级，学习曲线低
GitHub 背书，spec-kit 开源

劣势（Martin Fowler 2025 实测发现）：

AI 经常生成规格中没要求的功能
AI 会中途改变假设
AI 声称成功但构建实际失败
小 Bug 也被转化为"4 个用户故事 16 个验收标准"（过度规格化）
规格与代码的同步维护负担会持续增长
Fowler 结论：TDD 比纯 SDD 更实用——测试作为"强制理解函数"，让你真正理解 AI 生成的内容

3. AWS AI-Driven Development Lifecycle (AI-DLC)

出品方： AWS Labs (Amazon) GitHub： awslabs/aidlc-workflows博客： AWS DevOps Blog

三阶段流程：

Inception（需求） → Construction（构建） → Operations（运维）

阶段	关键活动	说明
Inception	Mob-Elaboration	AI 生成用户故事/验收标准/NFR，4-6 人 Taxi Team 验证
Construction	Mob-Programming + Mob-Testing	AI 提出架构/代码，团队实时验证；QA 主导测试策略
Operations	部署 + 监控	IaC 作为"规格"，AI 驱动洞察

核心概念 — Bolt（螺栓）：

时间盒执行周期：小时到天（而非传统 Sprint 的周/月）
每个 Bolt 实现 1 个或多个用户故事
内含 Plan → Execute → Validate 流程
每个 Bolt 有 10-26 个人工验证检查点

Taxi Team（出租车团队）：

4-6 人跨职能团队
BA/PM 主导需求、架构师主导设计、QA 主导测试
推荐同地办公 3-5 天（Mob 仪式需要）

优势：

覆盖最全（需求→构建→运维）
Bolt 节奏快（天级迭代 vs 周级 Sprint）
人在回路验证点最多（10-26 个/Bolt）
自适应工作流（自动识别新/老项目）
开源 workflow 模板（MIT 协议）

劣势：

需要 4-6 人同时在场（Mob 仪式开销大）
检查点过多可能导致决策疲劳
偏向 AWS/Amazon Q Developer 生态
上下文在阶段间如何传递的细节不够清晰
成熟案例和生产验证尚少

4. Intent-Driven Development (IDD)

出品方： intent-driven.dev / Kiro (AWS) 网站： intent-driven.dev工具： Kiro

核心模型 — 三层意图：

WHY（动机）→ WHAT（需求）→ HOW（方案）

层级	内容	示例
WHY	为什么要做这个	"用户注册流程太长导致 30% 放弃率"
WHAT	要实现什么	"简化为 3 步注册，支持第三方登录"
HOW	怎么实现	"React 表单 + OAuth2 + 后端验证"

与 SDD 的区别：

SDD 侧重规格文档的格式和治理
IDD 侧重意图的清晰表达，强调 WHY
IDD 认为 Context Engineering（上下文工程）是基础能力
SDD 用 constitution.md 做被动合规；IDD 用意图做主动引导

优势：

概念简洁（WHY/WHAT/HOW 三层即可上手）
强调动机，减少"做了但不知道为什么"的问题
Kiro 工具化落地（AWS 支持）

劣势：

2025-2026 年新兴，工具生态尚在建设
缺少企业级案例验证
与 SDD 的差异有时不明显

5. Anthropic "Try & Rollback" 方法论

出品方： Anthropic 内部实践 来源： How Anthropic Teams Use Claude Code

核心流程：

强规划 → Checkpoint Commit → 自主实现 → 测试 → 评估 → 失败则回滚

关键实践：

实践	说明
Checkpoint Commit	每个有意义的步骤都提交，形成回滚点
CLAUDE.md 记录错误	把 AI 犯过的错写入 CLAUDE.md，让它持续改进
移动边界	人机委派边界不固定，随模型能力提升定期重新协商
安全团队 TDD 转型	从"设计文档→粗糙代码→重构"转向"TDD + 伪代码审查 + 迭代测试"

Anthropic 内部应用场景：

增长营销：CSV → AI 识别低效广告 → 生成变体（数百个/分钟）
法务：构建原型"电话树"系统，无需传统开发
安全工程：TDD 驱动安全审计
数据基础设施：自动化数据工程任务

核心洞察：

AI 的价值不在于"生成代码更快"，而在于：消除陌生代码库的摩擦、扩展团队能力边界、让非技术人员也能创建工具。

优势：

最贴合 Claude Code 的原生工作方式
风险可控（频繁 checkpoint = 随时可回滚）
CLAUDE.md 持续改进机制
轻量，不需要额外框架

劣势：

不是完整方法论（缺少产品/设计阶段的明确流程）
依赖 git 纪律
缺少角色/阶段的结构化定义

二、值得了解的方法论

6. BDD for AI Agents（行为驱动开发）

出品方： 传统 BDD 演化 核心： 用 Given/When/Then 格式描述系统行为

gherkin

Given 用户已登录
When 用户点击"添加到购物车"
Then 购物车数量增加 1
And 显示成功提示

AI Agent 可直接读取 BDD 规格作为实现指导
AI 可从需求自动生成 BDD 场景
业务方可读、开发可执行、测试可自动化
适合场景： 需要业务方参与验收

来源： BDD for AI Agents - Medium

7. TDAD（Test-Driven Agentic Development）

出品方： 学术论文（arXiv）+ 实践社区 核心： TDD + Agent 特有需求

变更前做依赖图影响分析（防止回归）
支持灵活评分（不只 pass/fail，还有分数/评级）
Agent 自我纠错循环（测试失败 → 分析 → 重试）
适合场景： 复杂逻辑、需防回归

来源： arXiv TDAD

8. Prompt-Driven Development (PDD)

出品方： Capgemini、Hexaware 等企业 核心： Prompt 作为一等技术工件

Prompt 需要版本化、文档化、重构（像代码一样管理）
好 Prompt → 好输出，差 Prompt → 差输出（GIGO）
让领域专家/分析师也能直接参与开发
适合场景： Prompt 密集型系统

来源： Capgemini PDD

9. Copilot Workspace 方法论

出品方： GitHub/微软（2026 GA） 核心： 任务驱动 + 两个关键人工干预点

Task → Spec（当前状态 vs 期望状态） → Plan → 实现
                ↑ 人工干预点 1              ↑ 人工干预点 2

Spec 自动生成当前状态和期望状态的 diff
两个 Steering 时机：修改 Spec、修改 Plan
Repair Agent 自动修复构建失败
适合场景： GitHub 生态内的任务驱动开发

来源： GitHub Copilot Workspace

10. Vibe Coding（结构化变体）

出品方： Andrej Karpathy（概念）、go-vibe.dev（框架化） 核心： 对话式引导 AI，但加上结构

调研 → PRD → 技术设计 → Agent 配置 → 导出

5 阶段 Pipeline，每阶段有明确产出
规则文件（.cursorrules / CLAUDE.md）引导 AI 行为
20-50x 开发速度（快速原型阶段）
适合场景： 快速原型、内部工具
局限： 关键系统不可靠，可能产出不可维护的代码

来源： DEV Community、go-vibe.dev

三、业界趋同模式

所有方法论正在收敛到 5 个共同模式：

模式 1：规格/意图先行

先写清楚要什么，再让 AI 做

SDD：specification.md
BMAD：PRD.md + architecture.md
IDD：WHY/WHAT/HOW
AI-DLC：Mob-Elaboration 产出需求
共识：模糊需求 = 模糊代码

模式 2：文档即真相

文档是权威来源，不是代码

BMAD：文档驱动一切决策
SDD：constitution.md 宪法治理
Anthropic：CLAUDE.md 作为项目大脑
共识：AI 需要明确规格才能减少幻觉

模式 3：Checkpoint + Rollback

频繁提交，失败即回滚

Anthropic：每步 checkpoint commit
AI-DLC：每个 Bolt 有验证点
Copilot Workspace：Repair Agent 自动修复
共识：AI 输出不可靠，必须有回滚能力

模式 4：测试驱动

TDD/BDD 作为 AI 的护栏

SDD：强制 TDD（红-绿-重构）
BMAD：QA Agent + TEA 测试套件
TDAD：依赖图影响分析 + 自我纠错
Fowler 推荐：TDD > SDD（测试是"强制理解函数"）
共识：没有测试，就无法信任 AI 输出

模式 5：人在关键节点

人审批 Spec、审批 Plan、审批实现

AI-DLC：10-26 个检查点/Bolt
SDD：修改 Spec 和修改 Plan 两个干预点
BMAD：阶段门禁 + 角色互审
共识：AI 自主执行，人在关键节点把关

四、可集成到 Claude Code 的工具速查

项目知识库构建

工具	用途	集成方式
`/init`	自动生成 CLAUDE.md	CC 内置
Plan Mode	只读扫描理解项目	`Shift+Tab×2`
Memory MCP	持久化知识图谱	MCP Registry

产品阶段

工具	用途	集成方式
BMAD PRD Skill	引导式 PRD 生成	`npx bmad-method install`
PRD Generation Skill	工程向 PRD	`~/.claude/skills/`
Plan Mode	需求分析	CC 内置

设计阶段

工具	用途	集成方式
Figma MCP	设计↔代码双向同步	`claude mcp add figma`
Playwright MCP	交互原型验证	`claude mcp add playwright`
Mermaid	流程图/架构图	Markdown 原生支持

研发阶段

工具	用途	集成方式
Plan Mode	方案设计→审批→执行	CC 内置
Git Worktree	特性分支隔离	`--worktree`
Agent Teams	多 Agent 并行	`.claude/agents/`
MySQL MCP	数据库直连	MCP Registry
Hooks	自动格式化/lint	`.claude/settings.json`

测试阶段

工具	用途	集成方式
TDD Skill	强制红-绿-重构	`~/.claude/skills/`
Playwright MCP	E2E 浏览器测试	`claude mcp add playwright`
Pre-commit Hooks	lint/format/type-check	`.claude/settings.json`

五、任务拆分方法论

Claude Code 擅长小而聚焦的任务，但实际工作是复杂的。如何将大功能拆成 AI 友好的小任务，同时不丢失上下文，是工作流落地的核心问题。

核心痛点

痛点	表现
拆分时看不清隐含依赖	两个任务之间有隐含耦合，集成时才爆
执行时 AI 丢失全局视角	AI 只看局部代码，做出与全局架构不一致的决策
散弹式修改遗漏	改了一处接口/类型/函数名，漏改其他调用点

垂直切片 — 首选拆分模式

按完整用户旅程端到端切分，而非按技术层（前端/后端/数据库）水平切：

❌ 水平切分（AI 不友好）：
  任务1: 设计所有注册相关的数据库表
  任务2: 写所有注册 API
  任务3: 写所有注册页面
  → 每个任务都是"半成品"，无法独立验证

✓ 垂直切片（AI 友好）：
  任务1: 邮箱注册（表+API+页面+测试，端到端完整）
  任务2: 手机号注册（同上）
  任务3: 第三方登录（同上）
  → 每个任务可独立运行和验证

老项目适配 — 改造型切片：

✓ 老项目垂直切片：
  切片1: 在现有注册流程上增加手机号验证（在已有框架内改动）
  切片2: 重构现有密码校验逻辑（只动后端，但做完能独立验证）
  切片3: 新增第三方登录（新功能，但对接已有用户表）

SPIDR 进一步拆分

如果一个垂直切片还是太大，用 5 种方式继续细分（Mike Cohn 提出）：

方式	说明	示例（用户认证功能）
Spikes	先探索再实现	调研密码哈希策略
Paths	按不同用户路径	正常登录 / 忘记密码 / 账号锁定
Interfaces	按不同端/界面	PC 端 / 移动端 / API
Data	按不同数据状态	新用户 / 已有用户无密码 / 已禁用用户
Rules	按不同业务规则	密码强度校验 / 登录频率限制 / 验证码策略

粒度控制

最佳粒度：1-6 小时/任务（太小协调开销大，太大 AI 容易跑偏）
上下文检查：每 30 分钟检查 context 消耗（/context 命令）
一个任务一个目标，不混合无关关注点

上下文不遗漏的 5 层保护

第 1 层：CLAUDE.md 全局约束（每次 session 自动加载）
    ↓ 防全局遗漏
第 2 层：拆分前冲击分析（Plan Mode 分析文件/函数/数据流/调用关系）
    ↓ 防拆分遗漏
第 3 层：骨架先行（第一个任务搭结构，后续在结构内填充）
    ↓ 防结构偏差
第 4 层：任务 prompt 嵌入约束（架构模式、规范引用、边界外影响说明）
    ↓ 防执行偏差
第 5 层：集成验证（每 2-3 个任务全量构建+测试）
    ↓ 兜底

三个痛点的具体解法

痛点 1：拆分时看不清隐含依赖

拆之前在 Plan Mode 下做冲击分析：涉及文件、函数调用关系、跨模块数据流
每个 Story/任务描述中标注边界外影响："本任务改动会影响 X，但 X 的修改在任务 N 中处理"
显式声明任务间依赖（DAG 有向无环图）

痛点 2：执行时 AI 丢失全局视角

CLAUDE.md 写入关键架构约定（自动加载）
每个任务 prompt 嵌入具体约束：

任务：实现用户注册 API
约束：
- 必须使用现有的 BaseController 模式
- 数据校验走 validator 中间件，不要在 controller 里写
- 错误码遵循 error-codes.ts 中的枚举
- 用户表操作必须经过 UserService，不直接操作 DAO

痛点 3：散弹式修改遗漏

单独成任务：把"改接口签名"等散弹式改动从功能任务中剥离，单独作为重构任务
Grep 验证：改动后搜索旧引用，确认结果为 0
编译器护栏：TS 项目改了类型定义后跑 tsc，编译器报出所有未改的调用点
Plan Mode 预判：执行改动前先问 CC "这个改动会影响哪些文件"

可操作流程总结

拆分前：
  1. CC Plan Mode 做冲击分析（文件、函数、数据流、调用关系）
  2. 识别"散弹式改动"，单独成任务
  3. 输出任务列表 + 依赖关系 + 边界外影响说明
  4. 人审批/调整拆分方案

每个任务执行时：
  5. CLAUDE.md 提供全局约束（自动加载）
  6. 任务 prompt 嵌入具体约束（架构模式、规范引用）
  7. 完成后验证：grep 旧引用 + 跑编译 + 跑测试

集成验证：
  8. 每 2-3 个任务做一次全量构建 + 测试
  9. 发现问题立即修复，不积累到最后

工具支持

工具	用途	集成方式
Plan Mode	冲击分析、影响面预判、拆分方案输出	CC 内置 (`Shift+Tab×2`)
Task 系统	任务依赖管理、多 session 协作、持久化	CC 内置
TaskMaster	PRD→任务自动拆分、依赖管理	`npx task-master`
BMAD Epic Sharding	大规格→分片 Epic→超详细 Story	`npx bmad-method install`
TODO 骨架法	先写 `// TODO` 搭骨架，再逐个让 AI 填充	手动

常见错误

错误	后果	正确做法
过度拆分	协调开销 > 收益	1-6 小时/任务为佳
混合关注点	AI 被无关逻辑干扰，出错率升高	每个任务只有一个明确目标
漏声明依赖	任务在前置条件未完成时启动，浪费	显式声明 DAG
缺集成验证	各任务单独通过但集成失败	每 2-3 任务全量检查
不做冲击分析就拆	遗漏隐含依赖	Plan Mode 先分析再拆

六、自反馈进化机制

工作流不能是静态的。执行中发现的问题必须能反哺到流程本身的改进，形成闭环。核心原则：靠自动触发，不靠人记住。

反馈闭环总览

日常工作
  ├── session 中发现 AI 错误 → 更新 CLAUDE.md / lessons
  ├── 拆分中发现新模式 → 更新拆分经验库
  └── 项目中发现隐含知识 → 判断后沉淀

每完成一个功能（TaskCompleted 触发）
  └── 3 问回顾 → 记录到 retro-log

每次 /clear（SessionStart:clear 触发）
  └── 提醒记录教训

每月
  └── review CLAUDE.md：删过时、合并重复、补遗漏

层面 1：AI 行为进化

目标： 让 AI 不重复犯同样的错误。

分层存储（避免 CLAUDE.md 膨胀）：

CLAUDE.md（精简，< 200 行）
  └── 只放高频、全局性的约束
      例：编码规范、架构原则、不可触碰区域

docs/aicoding/lessons/（详细，按主题组织）
  ├── common-mistakes.md     # AI 常犯错误及纠正方式
  ├── pattern-library.md     # 项目中的代码模式（AI 应遵循的）
  └── anti-patterns.md       # 已知的反模式（AI 不应做的）

触发时机：

AI 犯了一个之前纠正过的错 → 应该记录了
一个 session 中纠正 3 次以上 → 值得总结
不需要每次 session 都更新

操作方式：

Session 结束前让 CC 总结错误："本次 session 中有什么值得记录的教训？"
CC 输出格式：错误 → 原因 → 教训 → 应写入 CLAUDE.md 还是 lessons 文件
人审核后写入

层面 2：拆分策略进化

目标： 同类功能越拆越准。

拆分经验库：

docs/aicoding/workflow/splitting-patterns.md

## CRUD 功能
推荐拆分：按实体粒度，每个实体一个垂直切片
注意：Migration 单独成第一个任务
经验来源：XX 项目用户管理模块

## API 签名变更
推荐拆分：1) 新增兼容接口 2) 迁移调用方 + 删除旧接口
注意：散弹式修改必须用 Grep 验证
经验来源：XX 项目 v2 API 迁移

更新时机：

拆分出了问题（依赖遗漏、粒度不对）→ 补充一条
拆分特别顺利 → 也记录（正反馈同样重要）
只记录有代表性的，不是每次都记

使用方式：

下次拆分前翻看 splitting-patterns.md，找同类模板
在 Plan Mode prompt 中引用："参考 splitting-patterns.md 中的 XX 拆分方式"

层面 3：流程度量与回顾

目标： 知道流程哪里有问题，持续改进。

3 问回顾（轻量到能坚持）：

每完成一个功能：
  1. 哪里最顺？ → 保持
  2. 哪里最痛？ → 改进
  3. 重来会怎么做不同？ → 记录

记录位置：

docs/aicoding/workflow/retro-log.md

## 2026-03-28 用户注册功能
- 顺：垂直切片拆分合理，每个切片独立可验证
- 痛：忘了做冲击分析，第三方登录缺失对 session 表的依赖
- 改进：涉及第三方集成时，必须先分析现有 session/token 机制

每条 3-5 行就够。关键是坚持记。

信号监测：

连续 3 次回顾都提到同一环节 → 该环节需要系统调整
偶发问题不过度反应，模式出现才行动

层面 4：项目知识沉淀

目标： 对项目的理解越来越深，不会因为换 session 就丢失。

什么值得沉淀：

✓ 沉淀	✗ 不沉淀
代码中的隐含约定（文档没写但大家知道的规则）	代码结构本身（看代码就知道）
跨模块的隐含依赖	git 历史能查到的
踩过的坑（库的 bug、环境配置等）	临时调试信息
性能/安全的关键约束	一次性信息

存储策略：

高频引用 → CLAUDE.md（AI 每次自动加载）
低频但重要 → 项目文档（需要时手动引用）
一次性 → 不存

保鲜机制：

CLAUDE.md 每月 review，删过时内容
某条知识 3 个月没被引用 → 考虑归档或删除
代码重构后检查相关知识是否还成立

Hook 自动触发配置

触发器 1：/clear 时提醒回顾

利用 SessionStart 事件 + "clear" matcher（因为 SessionEnd 在 /clear 时有 bug 不触发）：

json

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "clear",
        "hooks": [
          {
            "type": "command",
            "command": "echo '## 反馈提醒\\n上一轮工作有值得记录的教训吗？（AI行为错误/拆分经验/项目新发现）\\n如有请告诉我，我帮你整理写入对应文件。回复\"跳过\"则继续。'"
          }
        ]
      }
    ]
  }
}

触发器 2：任务完成时提醒 3 问回顾

利用 TaskCompleted 事件：

json

{
  "hooks": {
    "TaskCompleted": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo '## 任务完成回顾\\n1. 哪里最顺？\\n2. 哪里最痛？\\n3. 重来会怎么做不同？'"
          }
        ]
      }
    ]
  }
}

触发器 3：context 压缩后重新注入提醒

利用 PostCompact 事件，防止长 session 中反馈机制被压缩掉：

json

{
  "hooks": {
    "PostCompact": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo '提醒：完成当前功能后记得做 3 问回顾。'"
          }
        ]
      }
    ]
  }
}

配置位置： .claude/settings.json（项目级）或 ~/.claude/settings.json（全局）

注意事项：

SessionEnd 在 /clear 时有已知 bug 不触发（GitHub #6428），用 SessionStart + clear matcher 替代
Hook 输出的文本会作为 context 注入到 AI 对话中
可以用 /hooks 命令查看所有已配置的 Hook

AI Coding 方法论调研 ​

一、成熟方法论详细分析 ​

1. BMAD-METHOD（Breakthrough Method for Agile AI-Driven Development） ​

2. Spec-Driven Development (SDD) ​

3. AWS AI-Driven Development Lifecycle (AI-DLC) ​

4. Intent-Driven Development (IDD) ​

5. Anthropic "Try & Rollback" 方法论 ​

二、值得了解的方法论 ​

6. BDD for AI Agents（行为驱动开发） ​

7. TDAD（Test-Driven Agentic Development） ​

8. Prompt-Driven Development (PDD) ​

9. Copilot Workspace 方法论 ​

10. Vibe Coding（结构化变体） ​

三、业界趋同模式 ​

模式 1：规格/意图先行 ​

模式 2：文档即真相 ​

模式 3：Checkpoint + Rollback ​

模式 4：测试驱动 ​

模式 5：人在关键节点 ​

四、可集成到 Claude Code 的工具速查 ​

项目知识库构建 ​

产品阶段 ​

设计阶段 ​

研发阶段 ​

测试阶段 ​

五、任务拆分方法论 ​

核心痛点 ​

垂直切片 — 首选拆分模式 ​

SPIDR 进一步拆分 ​

粒度控制 ​

上下文不遗漏的 5 层保护 ​

三个痛点的具体解法 ​

可操作流程总结 ​

工具支持 ​

常见错误 ​

六、自反馈进化机制 ​

反馈闭环总览 ​

层面 1：AI 行为进化 ​

层面 2：拆分策略进化 ​

层面 3：流程度量与回顾 ​

层面 4：项目知识沉淀 ​

Hook 自动触发配置 ​

七、参考来源 ​

方法论官方 ​

评测与分析 ​

测试方法论 ​

工具与集成 ​

任务拆分 ​

Hooks 与反馈机制 ​

其他方法论 ​

AI Coding 方法论调研

一、成熟方法论详细分析

1. BMAD-METHOD（Breakthrough Method for Agile AI-Driven Development）

2. Spec-Driven Development (SDD)

3. AWS AI-Driven Development Lifecycle (AI-DLC)

4. Intent-Driven Development (IDD)

5. Anthropic "Try & Rollback" 方法论

二、值得了解的方法论

6. BDD for AI Agents（行为驱动开发）

7. TDAD（Test-Driven Agentic Development）

8. Prompt-Driven Development (PDD)

9. Copilot Workspace 方法论

10. Vibe Coding（结构化变体）

三、业界趋同模式

模式 1：规格/意图先行

模式 2：文档即真相

模式 3：Checkpoint + Rollback

模式 4：测试驱动

模式 5：人在关键节点

四、可集成到 Claude Code 的工具速查

项目知识库构建

产品阶段

设计阶段

研发阶段

测试阶段

五、任务拆分方法论

核心痛点

垂直切片 — 首选拆分模式

SPIDR 进一步拆分

粒度控制

上下文不遗漏的 5 层保护

三个痛点的具体解法

可操作流程总结

工具支持

常见错误

六、自反馈进化机制

反馈闭环总览

层面 1：AI 行为进化

层面 2：拆分策略进化

层面 3：流程度量与回顾

层面 4：项目知识沉淀

Hook 自动触发配置

七、参考来源

方法论官方

评测与分析

测试方法论

工具与集成

任务拆分

Hooks 与反馈机制

其他方法论