AI Spark 知识库

外观

开发方法论 ​

最后更新：2026 年 2 月

本文是 2025-2026 年间涌现的 15 种结构化 AI 辅助开发方法论的快速参考。实践性工作流，参见 workflows/。

目录 ​

  1. 决策树
  2. 15 种方法论
  3. SDD（规范驱动开发）工具参考
  4. 编写有效规范
  5. 组合模式
  6. 来源

决策树：你需要什么？ ​

Plain
┌─ "我想要高质量代码" ──────────────→ workflows/tdd-with-claude.md
│
├─ "我想先写规范再写代码" ─────────→ workflows/spec-first.md
│
├─ "我需要规划架构" ───────────────→ workflows/plan-driven.md
│
├─ "我在迭代某个功能" ─────────────→ workflows/iterative-refinement.md
│
└─ "我需要了解方法论理论" ──────────→ 继续阅读

方法论地图 ​

各方法论在两个维度上的定位：规范优先 vs 代码优先（纵轴）和精益/个人 vs 企业/治理（横轴）。

Plain
                      规范/规划优先
                                ▲
  ── 精益·规范 ──              │             ── 治理·规范 ──
                                │
  [文档驱动]  [SDD（规范驱动开发）]  │  [BDD（行为驱动开发）]  [ATDD]   [需求驱动]
  [GSD]  [计划优先]            │ [CDD] [ADR驱动]  [DDD]  [BMAD]
                                │
  精益 ──────────────────────────┼──────────────────────────────► 企业
                                │
  ── 精益·代码 ──              │             ── 治理·代码 ──
                                │
  [上下文工程]   [TDD（测试驱动开发）]   │       [多智能体]
  [提示词工程]  [迭代]          │       [评估驱动]       [FDD]
  [Ralph Loop]                  │           [JiTTesting]
                                │
                         代码/涌现优先

如何理解：

  • 左上 — 规范优先精益型：SDD（规范驱动开发）、文档驱动、计划优先。适合独立开发者和小团队摆脱"代码优先"的自然起点。
  • 右上 — 规范优先治理型：BMAD、需求驱动、ATDD、DDD。有真正的治理，但设置成本高。投资回报率由项目复杂度和需求稳定性驱动，而非单纯看人数。
  • 左下 — 代码优先精益型：Claude Code 的自然地盘。TDD（测试驱动开发） + Ralph Loop + 迭代 = 核心独立开发工作流。
  • 右下 — 规模化代码优先型：多智能体、评估驱动、JiTTesting（Meta，超 1 亿行代码）。高产量团队的新兴模式。
  • 轴线上 — 计划优先、CDD、ADR 驱动、GSD：可适应任何场景的混合方法。

15 种方法论 ​

按 6 层金字塔组织，从战略编排到优化技术。

第 1 层：战略编排 ​

名称简介最适合Claude 适配度
BMAD以宪法为护栏的多智能体治理需求稳定、合规或治理要求高的复杂项目⭐⭐ 小众但强大
GSD元提示词六阶段工作流，每个任务独立上下文独立开发者、Claude Code CLI⭐⭐ 与指南中的模式类似

BMAD（突破性敏捷 AI 驱动开发方法） 颠覆了传统范式：文档而非代码成为事实来源。使用专业智能体（分析师、PM、架构师、开发者、QA）在严格治理下编排。注：BMAD 基于角色的智能体命名反映其方法论；以范围为中心的替代方案参见 §9.17 智能体反模式。

  • 核心概念：Constitution.md 作为战略护栏
  • 使用场景：需要治理的复杂企业项目
  • 避免场景：MVP、快速原型、需求变动频繁——BMAD 在规范中途变更时比较脆弱

GSD（把事情做完） 通过系统性的六阶段工作流（初始化→讨论→规划→执行→验证→完成）解决上下文退化问题，每个任务使用独立的 200k Token（词元）上下文。核心概念（多智能体编排、新鲜上下文管理）与 Ralph Loop、Gas Town 和 BMAD 等现有模式有大量重叠。详细比较参见「资源评估」。

新兴模式：Ralph Inferno 实现了带虚拟机执行和自我纠正端到端循环的自主多角色工作流（分析师→PM→UX→架构师→业务）。实验性但对"大规模氛围编码"很有趣。

基础纪律：计划优先工作流 ​

"计划一旦到位，代码自然到位。"— Boris Cherny，Claude Code 创始人

这不仅仅是一个功能（/plan 命令）——而是一种系统性纪律。

上下文工程：Thoughtworks 在其技术雷达（2025 年 11 月）[^thoughtworks2025] 中将这种更广泛的方法称为"上下文工程"——对推理期间提供给 LLM 的信息进行系统性设计。三种核心技术：上下文设置（最小系统提示、少样本示例）、长期任务的上下文管理（摘要、外部记忆、子智能体架构）和动态信息检索（即时检索上下文加载）。Claude Code 中的相关模式：AGENTS.md、MCP Context7、计划模式。

[^thoughtworks2025]: Thoughtworks Technology Radar 第 33 卷，2025 年 11 月。PDF。另见：宏观趋势博客文章。

思维模型：

规划对于复杂任务来说不是可选的，而是区分以下两种情况的关键：

  • ❌ 8 次迭代的"尝试→修复→重试→再修复"
  • ✅ 1 次迭代的"规划→验证→干净执行"

何时优先规划：

任务复杂度先规划？原因
修改超过 3 个文件✅ 是跨文件依赖需要架构
修改超过 50 行✅ 是足够复杂，容易出错
架构变更✅ 是需要影响分析
不熟悉的代码库✅ 是行动前需要探索
拼写错误/明显修复❌ 否规划开销 > 任务时间
单行更改❌ 否直接做

计划优先的工作流程：

  1. 探索阶段（通过 Shift+Tab 进入计划模式）：

    • Claude 读取文件，探索架构
    • 不允许编辑 → 强制先思考再行动
    • 提出带权衡分析的方案

  2. 验证阶段（你来审查）：

    • 计划暴露假设和盲点
    • 现在纠正方向比写了 100 行后更容易
    • 计划成为执行的契约

  3. 执行阶段（用 Shift+Tab 切回普通模式）：

    • 计划→代码变成机械性转化
    • 减少意外，实现更干净
    • 尽管开始"更慢"，但整体更快

Boris Cherny 的工作流：

"我运行很多会话，从计划模式开始，计划看起来合适后再切换到执行。标志性的升级是验证——给 Claude 一种测试和确认自己输出的方式。"

相比"直接开始写"的优势：

  • 更少的纠错迭代：计划在问题成为代码前就发现它们
  • 更好的架构：被迫首先考虑结构
  • 更清晰的沟通：计划是与团队/Claude 的共同理解
  • 降低成本：一次干净的迭代 < 多次混乱的迭代（即使计划阶段消耗 Token（词元））

与 CLAUDE.md 集成：

记录你的团队的计划优先触发条件：

Markdown
## 规划策略
- 必须先规划：API 变更、数据库迁移、新功能
- 可选规划：10 行以内的 bug 修复、添加测试
- 绝不跳过：影响超过 2 个模块的变更

另请参阅：/plan 命令用法，参见计划模式文档。

高级模式：迭代式注解方法的计划驱动开发，参见「自定义 Markdown 计划（Boris Tane 模式）」。

第 2 层：规范与架构 ​

名称简介最适合Claude 适配度
SDD（规范驱动开发）先写规范再写代码API、契约⭐⭐⭐ 核心模式
文档驱动文档即事实来源跨团队对齐⭐⭐⭐ CLAUDE.md 原生
需求驱动丰富的工件上下文（20+ 工件）复杂需求⭐⭐ 设置成本高
DDD领域语言优先业务逻辑⭐⭐ 设计时使用

SDD（规范驱动开发） — 先写规范，再写代码。一次结构良好的迭代等于 8 次非结构化迭代。CLAUDE.md 就是你的规范文件。

文档驱动开发 — 版本化在 git 中的活文档成为唯一事实来源。规范的变更触发实现。

需求驱动开发 — 将 CLAUDE.md 作为包含 20+ 结构化工件的综合实现指南。

DDD（领域驱动设计） — 通过以下方式将软件与业务语言对齐：

  • 通用语言：代码中的共享词汇
  • 限界上下文：隔离的领域边界
  • 领域提炼：核心 vs 支撑 vs 通用领域

第 3 层：行为与验收 ​

名称简介最适合Claude 适配度
BDD（行为驱动开发）Given-When-Then 场景利益相关者协作⭐⭐⭐ 测试与规范
ATDD验收标准优先合规、受监管场景⭐⭐ 流程较重
CDDAPI 契约作为接口微服务⭐⭐⭐ OpenAPI 原生

BDD（行为驱动开发） — 超越测试：一种协作过程。

  1. 发现：让开发者和业务专家共同参与
  2. 制定：编写 Given-When-Then 示例
  3. 自动化：转换为可执行测试（Gherkin/Cucumber）
Gherkin
Feature: 订单管理
  Scenario: 无库存无法购买
    Given 库存为 0 的产品
    When 客户尝试购买
    Then 系统拒绝并显示错误消息

ATDD（验收测试驱动开发） — 验收标准在编码前定义，通过协作完成（"三剑客"：业务、开发、测试）。

在 agentic 开发中，ATDD 特别有效，因为智能体需要明确的成功条件。流程可以清晰地映射到智能体任务：

  1. 定义验收标准，采用 Gherkin 格式（人类可读、机器可执行）
  2. 智能体编写失败的测试，基于场景（而非实现）
  3. 智能体实现，直到测试通过
Gherkin
Feature: 密码重置
  Scenario: 用户通过邮件重置密码
    Given 注册用户，邮箱为 "user@example.com"
    When 他们请求密码重置
    Then 他们在 60 秒内收到重置邮件
    And 重置链接在 24 小时后过期

这个 Gherkin 场景是意图和实现之间的契约。智能体无法误解范围，因为"完成"在写下第一行代码之前就已定义。

应用于智能体：在实现之前将 Gherkin 文件传给 Claude Code。"为这个功能文件编写失败的测试，然后实现直到通过。" 场景编写角色（人类或智能体）在执行开始前强制明确范围。

CDD（契约驱动开发） — API 契约（OpenAPI 规范）作为团队间的可执行接口。模式：契约即测试、契约即存根。

JiTTesting（即时测试） — 在 PR 提交时动态生成测试，被设计为会失败的，合并后丢弃。没有维护成本，测试套件不会增长。

TDD（测试驱动开发）/BDD（行为驱动开发）/ATDD 都假设开发者控制代码编写节奏。Agentic 开发打破了这个假设：智能体每小时可以生成 200 行代码，比任何人工测试编写工作流都要快。JiTTests 是对这种不匹配的工业化响应。

机制：在 PR 时，LLM 推断 diff 的意图，生成代码变体（故意破坏的变体），编写能捕获这些变体的测试，运行规则和 LLM 评估器的集成来过滤误报，只将真实回归浮现给工程师。测试从不落入代码库。

Meta 在规模上部署了这一方案（超过 1 亿行代码）：在传统硬化测试上捕获回归提升 4 倍，人工审查负担减少 70%，从 41 个候选中防止了 4 次严重生产故障。

目前尚无开源实现。今天你可以这样近似：在合并任何智能体生成的 PR 之前，提示 Claude："生成专门捕获此 diff 引入回归的测试——我会在本地运行它们，PR 关闭后丢弃。" 临时性的框架让测试生成专注于实际变更，而不是一般覆盖率。

参考：Meta 的即时捕获测试生成 — Harman，2026。

第 4 层：功能交付 ​

名称简介最适合Claude 适配度
FDD逐功能交付并行交付的功能团队⭐⭐ 结构
上下文工程上下文作为一等设计要素长会话⭐⭐⭐ 基础性

FDD（功能驱动开发） — 五个流程：

  1. 开发总体模型
  2. 构建功能列表
  3. 按功能规划
  4. 按功能设计
  5. 按功能构建

严格迭代：每个功能最多 2 周。

上下文工程 — 将上下文视为设计元素：

  • 渐进式披露：让智能体增量发现
  • 记忆管理：对话记忆 vs 持久记忆
  • 动态刷新：响应前重写待办列表

第 5 层：实现 ​

名称简介最适合Claude 适配度
TDD（测试驱动开发）红-绿-重构高质量代码⭐⭐⭐ 核心工作流
评估驱动针对 LLM 输出的评估AI 产品⭐⭐⭐ 智能体
多智能体编排子智能体复杂任务⭐⭐⭐ 任务工具

TDD（测试驱动开发） — 经典循环：

  1. 红：编写失败的测试
  2. 绿：最小代码使测试通过
  3. 重构：清理代码，测试保持绿色

使用 Claude：要明确。"编写尚不存在的失败测试。"

验证循环 — 自主迭代的正式模式（比 TDD（测试驱动开发）更广泛）：

核心原则：给 Claude 一种验证自己输出的机制。

为何有效（Boris Cherny）："能够'看见'自己所做的事的智能体会产生更好的结果。"

按领域划分的验证机制：

领域验证工具Claude"看到"的内容前端浏览器预览（热更新）视觉渲染、布局、交互后端测试（单元/集成）通过/失败状态、错误消息类型TypeScript 编译器类型错误、不兼容风格Linter（ESLint、Prettier）风格违规、格式问题性能分析器、基准测试执行时间、内存使用无障碍axe-core、屏幕阅读器WCAG 违规、导航问题安全静态分析器（Semgrep）漏洞模式UX用户测试、录制可用性问题、困惑点

TDD（测试驱动开发）作为典型示例：

官方指导："告诉 Claude 持续直到所有测试通过。通常需要几次迭代。" — Anthropic 最佳实践

实现模式：

反模式：没有反馈的盲目迭代。没有验证机制，Claude 无法收敛到正确的解——它只是在猜测。

这一方法防止的实现侧故障模式，参见「验证缺口」。

评估驱动开发 — LLM 的 TDD（测试驱动开发）。通过评估测试智能体行为：

  • 基于代码：output == golden_answer
  • 基于 LLM：另一个 Claude 进行评估
  • 人工评分：参考标准，速度慢

评估框架 — 端到端运行评估的基础设施：提供指令和工具、并发运行任务、记录步骤、评分输出、汇总结果。

参见 Anthropic 的综合指南：揭秘 AI 智能体的评估

多智能体编排 — 从单一助手到编排团队：

Plain
元智能体（编排者）
├── 分析师（需求）
├── 架构师（设计）
├── 开发者（代码）
└── 审查者（验证）

ADR 驱动开发 ​

模式：用简单英文编写 ADR → 传入实现 ADR 技能 → 原生执行

架构决策记录（ADR）与 Claude Code Skills（技能模块）结合，创建了一种架构决策直接驱动实现的工作流。

工作流步骤：

  1. 记录决策，使用 ADR 格式（上下文、决策、后果）
  2. 创建实现技能（通用或 implement-adr 专用）
  3. 将 ADR 作为提示词，传给带明确验收标准的技能
  4. Claude 执行，基于 ADR 中的架构指导

ADR 模板示例：

Plain
# ADR-001：数据库迁移策略

## 上下文
遗留 MySQL Schema 需要迁移到 PostgreSQL 以获得更好的 JSON 支持。

## 决策
使用带功能标志的增量双写模式。

## 后果
- 积极：零停机迁移
- 消极：过渡期间临时增加代码复杂度

实现工作流：

Bash
# 1. 编写 ADR（简单语言）
vim docs/adr/001-database-migration.md

# 2. 传入实现技能
/implement-adr docs/adr/001-database-migration.md

# 3. Claude 基于 ADR 指导执行
# → 创建迁移脚本
# → 更新 ORM 配置
# → 添加功能标志
# → 实现双写逻辑

优势：

  • ✅ 文档驱动：架构和代码保持同步
  • ✅ 原生执行：无需外部框架
  • ✅ 可追溯的决策：从决策到实现有清晰的审计链
  • ✅ 团队对齐：ADR 向人类和 AI 传达意图

来源：Gur Sannikov 嵌入式工程工作流

第 6 层：优化 ​

名称简介最适合Claude 适配度
迭代循环自主精炼优化⭐⭐⭐ 核心
新鲜上下文每个任务重置，状态存文件长期自主会话⭐⭐⭐ 高级用户
提示词工程技术基础所有场景⭐⭐⭐ 前提条件

迭代精炼循环 — 自主收敛：

  1. 执行提示词
  2. 观察结果
  3. 如果结果 ≠ "完成" → 精炼并重复

提示词工程 — 所有 Claude 使用的基础：

  • 零样本思维链：「逐步思考」
  • 少样本学习：2-3 个期望模式示例
  • 结构化提示词：用 XML 标签组织
  • 位置很重要：对于长文档，将问题放在末尾

新鲜上下文模式（Ralph Loop） — 通过为每个任务派生新鲜智能体实例来解决上下文退化问题。状态在 git + 进度文件中持久化，而非聊天历史。适合长时自主会话（迁移、隔夜运行）。实现参见《Claude Code：从入门到大师》 - 新鲜上下文模式。

SDD（规范驱动开发）工具参考 ​

三种工具已经出现，用于正式化规范驱动开发：

工具使用场景官方文档Claude 集成
Spec Kit绿地项目、治理github.blog/spec-kit/speckit.constitution, /speckit.specify, /speckit.plan
OpenSpec棕地项目、变更github.com/Fission-AI/OpenSpec/openspec:proposal, /openspec:apply, /openspec:archive
SpecmaticAPI 契约测试specmatic.io提供 MCP 智能体
Spec-to-Code Factory绿地、工具化强制执行github.com/SylvainChabaud/spec-to-code-factory多智能体参考实现（BREAK→MODEL→ACT→DEBRIEF）

Spec Kit（绿地项目） ​

5 阶段工作流：

  1. 宪法：/speckit.constitution → 护栏
  2. 规范：/speckit.specify → 需求
  3. 计划：/speckit.plan → 架构
  4. 任务：/speckit.tasks → 分解
  5. 实现：/speckit.implement → 代码

OpenSpec（棕地项目） ​

双文件夹架构：

Plain
openspec/
├── specs/      ← 当前事实（稳定）
└── changes/    ← 提案（临时）

工作流：提案 → 审查 → 应用 → 归档

Specmatic（API 契约） ​

  • 契约即测试：从 OpenAPI 规范自动生成数千个测试
  • 契约即存根：用于并行开发的模拟服务器
  • 向后兼容性：检测破坏性变更

编写有效规范 ​

基于对 2500+ 智能体配置文件的分析。来源：Addy Osmani

六个核心组成部分 ​

组成部分包含内容示例
命令带标志的可执行命令npm test -- --coverage
测试框架、覆盖率、位置vitest, 80%, tests/
项目结构明确的目录src/, lib/, tests/
代码风格一个示例胜过多段描述展示一个真实函数
Git 工作流分支、提交、PR 格式feat/name、约定式提交
边界权限层级见下方

权限层级 ​

层级符号用途
始终执行✅安全操作，无需批准（lint、格式化）
先询问⚠️高影响变更（删除、发布）
绝不执行🚫硬性禁止（提交密钥、强制推送 main）

指令的诅咒 ​

⚠️ 研究表明指令越多 = 每条指令的遵从度越差。

解决方案：每个任务只传入相关的规范章节，不要传整个文档。

单体 vs 模块化规范 ​

项目规模方法
小型（<10 个文件）单一规范文件
中型（10-50 个文件）分章节规范，按任务传入
大型（50+ 个文件）按领域的子智能体路由

组合模式 ​

按场景推荐的组合方案：

场景推荐组合备注
独立 MVPSDD（规范驱动开发）+ TDD（测试驱动开发）最小开销，质量导向
5-10 人团队，绿地Spec Kit + TDD（测试驱动开发）+ BDD（行为驱动开发）治理 + 质量 + 协作
微服务CDD + Specmatic契约优先，并行开发
现有 SaaS（100+ 功能）OpenSpec + BDD（行为驱动开发）变更跟踪，无规范漂移
高复杂度/合规BMAD + Spec Kit + Specmatic完整治理 + 契约
LLM 原生产品评估驱动 + 多智能体自我改进系统

快速参考表 ​

方法论层级主要焦点最佳场景学习曲线
BMAD编排治理高复杂度、需求稳定高
SDD（规范驱动开发）规范契约任何场景中
文档驱动规范对齐任何场景低
需求驱动规范上下文复杂需求、多工件中
DDD规范领域复杂业务领域极高
BDD（行为驱动开发）行为协作多角色利益相关者参与中
ATDD行为合规受监管、明确验收标准中
CDD行为API服务边界、并行团队中
FDD交付功能功能团队、并行交付中
上下文工程交付AI 会话任何场景低
TDD（测试驱动开发）实现质量任何场景低
评估驱动实现AI 输出任何场景中
多智能体实现复杂度任何场景中
迭代优化精炼任何场景低
提示词工程优化基础任何场景极低

来源 ​

官方文档（Tier 1） ​

方法论参考（Tier 2） ​

SDD（规范驱动开发）与规范优先

BMAD

AI 辅助 TDD（测试驱动开发）

BDD（行为驱动开发）与 DDD

上下文工程

评估驱动与多智能体

工具文档（Tier 1） ​

其他参考 ​

另请参阅 ​

  • 「workflows/tdd-with-claude.md」 — 实践 TDD（测试驱动开发）指南
  • 「workflows/spec-first.md」 — 规范优先开发
  • 「workflows/plan-driven.md」 — 使用 /plan 模式
  • 「workflows/iterative-refinement.md」 — 精炼循环
  • 「ultimate-guide.md#912」 — 第 9.12 节摘要

来源：飞书 · AI Spark 知识库 ｜ 原文（最新版）：https://lcnniolukk80.feishu.cn/wiki/D5wGw4fM7iSYWDkCXECcrJ26nTh ｜ 归档：2026-06-04