FDD 驱动 AI Coding 工作流
从理论框架到工程实践

Feature-Driven Development 如何重塑 AI 辅助编程工作流

分享人：杨正武 · 2026-05

00
议程

今天聊什么

  • 1
    FDD 方法论回顾 — 特性驱动开发的经典五阶段
  • 2
    三大 AI 编程框架工作流对比 — OpenSpec / BMad / Superpowers
  • 3
    Feature-Workflow 的 FDD 设计驱动 — 理论映证与工程实践
  • 4
    Feature-Workflow 实践 — 55 个特性归档的工程经验
01
方法论

Feature-Driven Development

以特性为最小交付单元，按依赖关系迭代开发。不按时间盒，不按任务列表，而是按业务价值切割交付。
FDD 1
Build Overall Model — 全局建模，建立团队共识
FDD 2
Build Features List — 列出所有待交付特性
FDD 3
Plan by Feature — 按依赖关系排序开发顺序
FDD 4
Design by Feature — 逐个特性进行技术设计
FDD 5
Build by Feature — 逐个特性实现、测试、交付

核心思想：先全局、再分解、按依赖迭代。每一步都围绕"特性"这个核心组织。

01
关键转变

从水平切片到垂直切片

水平切片（传统做法）

数据库层
↓
业务逻辑层
↓
API 接口层
↓
UI 展示层

按技术层分工，完成后才看到完整功能

垂直切片（FDD 驱动）

特性 A：用户登录（DB→逻辑→API→UI）
特性 B：订单查询（DB→逻辑→API→UI）
特性 C：支付流程（DB→逻辑→API→UI）

每个特性横跨所有层，独立可交付

为什么重要：垂直切片让每一次交付都有业务价值。FDD 的"特性"天然就是垂直切片 — 一个对用户有价值的小功能，必须横跨所有技术层。

01
团队演进

垂直切片驱动团队组织变化

FDD 如何保证垂直切片

  • 颗粒度控制：按用户价值点拆分，3+ 价值点时建议拆为子特性
  • Context 窗口设计：每个特性控制在单个 Agent 的 context 承载范围内
  • 先建模后切分：Build Overall Model 提供共同骨架，避免碎片化
  • 按特性交付：Design & Build by Feature 确保每块都端到端跑通

团队组织方式的变化

  • 传统：前端组 / 后端组 / DBA 组（按技术层分工）
  • FDD：特性小组（按业务功能跨职能组合）
  • AI Coding：AI Agent 同时覆盖所有技术层

AI Agent 天然适合垂直切片 — 一个 Agent 可以同时改 DB、逻辑和 UI，不存在技术筒仓问题。

核心洞察：垂直切片 + FDD + AI Agent = 开发组织方式的根本转变。AI Agent 天然是"全栈"的，垂直切片在 AI Coding 中比传统团队更容易实现。

02
框架对比

三大 AI 编程框架概览

维度OpenSpecBMad MethodSuperpowers
核心焦点规范管理敏捷流程代码质量
工作流风格轻量、灵活企业级、结构化强制性、系统化
学习曲线低中高中
团队规模个人到企业中大型团队个人到小型团队
设计哲学流动至上规模至上质量至上

共同趋势

  • 从临时对话 → 系统化工作流
  • 从单一 Agent → 多代理协作

互相借鉴的方向

  • OpenSpec 的规范先行思想
  • BMad 的多角色分工机制
  • Superpowers 的 TDD 强制流程
03
OpenSpec

规范驱动开发（SDD）

流动而非僵化，迭代而非瀑布，简单而非复杂，适配遗留系统而非仅限新项目。
/opsx:propose
→
/opsx:apply
→
/opsx:archive
# 1. 提议：创建变更文件夹
/opsx:propose "add-dark-mode"
→ proposal.md / specs/ / design.md / tasks.md

# 2. 实施：逐任务执行
/opsx:apply  →  逐个任务实施并验证

# 3. 归档：更新规范
/opsx:archive  →  移至归档目录

核心理念

  • 轻量，工具无关
  • 支持 20+ AI 编码助手
  • 构建前共识，减少不可预测性

适用场景

  • 规范先行的团队项目
  • 遗留系统渐进改进
  • 多人协作的企业环境
04
BMad Method

敏捷 AI 驱动开发

"Build More Architect Dreams" — 规模自适应的 AI 敏捷开发框架，从错误修复到企业系统。

核心特性

  • 12+ 专业代理：PM、架构师、开发者、UX、Scrum Master
  • 规模自适应：根据复杂度自动调整规划深度
  • Party Mode：多代理协作讨论
  • 完整生命周期：头脑风暴 → 部署

模块生态

  • BMM：核心框架，34+ 工作流
  • BMB：自定义代理和工作流构建器
  • TEA：基于风险的测试策略
  • BMGD：游戏开发工作流
  • CIS：创新、头脑风暴、设计思维

定位：企业级敏捷框架，适合需要多角色协作的大型项目和专业领域。

05
Superpowers

代理技能框架

测试驱动、系统化、降低复杂度、证据优于声明。
brainstorming
→
worktrees
→
plans
→
subagent
→
TDD
→
review
→
finish

7 步流程

  • 苏格拉底式设计完善
  • Git worktree 隔离工作区
  • 2-5 分钟小任务拆分
  • 子代理 + 两阶段审查
  • RED-GREEN-REFACTOR 循环
  • 按计划代码审查
  • 验证 + 合并/PR

核心理念

  • 强制性流程：不是建议，是要求
  • 自动触发：代理自动检查技能
  • TDD 核心：测试先行，删除无测试代码
  • 子代理架构：并行深度审查

适合极端重视代码质量、TDD 实践、使用 Claude Code 的团队。

06
设计哲学

规范 vs 规模 vs 质量

OpenSpec — 流动至上

  • 规范先于代码
  • 迭代优于瀑布
  • 适合遗留系统改造
  • Workflow: propose → apply → archive

BMad Method — 规模至上

  • 自适应智能
  • 多角色协作（12+ 代理）
  • 覆盖完整生命周期
  • Workflow: brainstorm → plan → architect → dev

Superpowers — 质量至上

  • TDD 强制执行
  • 系统化调试
  • 子代理审查机制
  • Workflow: brainstorm → worktree → plan → dev → TDD

Feature-Workflow — FDD 驱动

  • 特性为核心组织单元
  • 依赖建模 + 上下文传播
  • 物理隔离 + 归档积累
  • Workflow: init → new → spec → impl → verify → archive
07
实践

Feature-Workflow 登场

Feature-Workflow 是一套以 FDD 为理论驱动 的 AI Coding 工作流插件。借鉴了三大框架的优秀实践，同时以特性为核心组织单元，构建端到端开发工作流。

借鉴三大框架

  • OpenSpec：规范先行，构建前共识
  • BMad：多角色分工，规模自适应
  • Superpowers：TDD 流程，worktree 隔离

FW 的 FDD 特性

  • 以 Feature 为核心组织单元
  • 显式依赖 DAG + 上下文传播
  • 物理隔离（worktree）+ 并行
  • 归档即知识积累（55 归档）

核心问题：EvoDev 论文提出的 FDD + Feature Map 理论框架，在工程实践中是否可行？55 个特性归档能否构成实证？

08
论文介绍

EvoDev：FDD 的学术形式化

EvoDev 是一篇将 FDD 方法论引入 AI Coding 的学术论文，核心思想是引入 Feature Map（特性地图）作为 DAG 结构，显式建模特性依赖关系。

arxiv.org/abs/2511.02399 — EvoDev: An Iterative Feature-Driven Framework for End-to-End Software Development

论文三阶段

Overall Design
→
Feature Map
→
Iterative Dev

灵感来源：经典 FDD 方法论

四项创新

  • Feature Map 作为 DAG 建模依赖
  • 三层上下文：Business / Design / Implementation
  • 依赖关系驱动的上下文传播
  • 在 Android 任务上超越 Claude Code 56.8%
09
FDD 映射

FDD 五阶段 → Feature-Workflow

FDD 1
Build Overall Model → EvoDev: Overall Design → FW: /init-project + project-context.md
FDD 2
Build Features List → EvoDev: Feature Map Gen → FW: /new-feature + /split-feature
FDD 3
Plan by Feature → EvoDev: Feature Map Gen → FW: queue.yaml 依赖排序
FDD 4
Design by Feature → EvoDev: Iterative Dev → FW: spec.md 技术方案 + task.md
FDD 5
Build by Feature → EvoDev: Iterative Dev → FW: /implement-feature + /verify-feature

映射关系：两者都遵循"先全局设计 → 再特性分解 → 按依赖迭代开发"的流程。FDD 每个阶段对应 Feature-Workflow 中的具体 skill 或文件。

10
Feature Map

Feature Map 结构对比

EvoDev: 单一 DAG

每节点含三层上下文，信息沿依赖边传播。

Feature Set A ← Business + Design + Impl
Feature Set B ← depends on A
Feature Set C ← depends on A, B

FW: 三文件组合等价

queue.yaml（动态 DAG 边）+ archive-log.yaml + spec.md

queue.yaml:      pending/blocked/active
archive-log.yaml: 55 completed nodes
spec.md:         3-layer context

实际归档中的依赖 DAG：

feat-redesign-system (设计令牌基础)
  └→ feat-redesign-layout (全局布局)
       ├→ feat-redesign-timeline    (Timeline)
       ├→ feat-redesign-knowledge-map (知识图谱)
       └→ feat-redesign-explorer    (浏览器)

feat-p3-governance-engine (治理引擎)
  └→ feat-p3-board-ecosystem (生态集成)
       depends: [governance-engine, board-redesign]
11
上下文传播

三层上下文对比

EvoDev 论文

  • Business-layer：功能范围 + 接口定义
  • Design-layer：UI 组件 + 数据实体
  • Implementation-layer：代码变更记录
  • 信息沿依赖边自动传播

Feature-Workflow spec.md

  • Description + User Value + Gherkin
  • Technical Solution + Context Analysis
  • Reference Code + Related Features + Archive Patterns
  • /start-feature 加载前置特性摘要
实际案例（feat-redesign-layout 的 spec.md）：
Related Features:
• feat-redesign-system（前置）— 提供 Bento Grid 设计令牌和 shadcn/ui 组件
• feat-p2-board-scaffold（已完成）— 建立了当前 layout.tsx，需完全重写
Archive Implementation Patterns:
• 当前布局: Sidebar 使用 position: fixed w-60
12
多智能体

多智能体协作对比

EvoDev: 6 个固定 Agent

  • Business Analyst → Architect
  • Feature Extractor → Planner
  • Chief Programmer → Programmer
  • 顺序执行特性集

FW: 1 SubAgent + 15 Skills

  • /dev-agent 调度层
  • DevSubAgent 独立 200k context
  • 15 个原子 skill 可组合
  • 物理隔离（worktree）+ 并行

物理隔离

每个特性独立 git worktree + 独立文件系统，比逻辑隔离更安全

并行开发

多 SubAgent 并行执行，max_concurrent 控制并发数

容错恢复

SubAgent 超时保护 + 自动重试 + /dev-agent --resume

Skill 可组合

15 个原子 skill 按需链式调用，比固定 agent 更灵活

13
总结

FDD 驱动 AI Coding 的实践思考

FDD 方法论为 AI Coding 工作流提供了成熟的理论框架，Feature-Workflow 是其在工程中的一次完整实践。

理论启发

FDD 五阶段 + Feature Map DAG + 三层上下文

工程实践

55 个特性归档、worktree 隔离、插件化分发

互相借鉴

OpenSpec 规范先行 / BMad 角色分工 / Superpowers TDD

持续演进

工作流框架在理论和实践中不断迭代优化

AI Coding 工作流还处于早期，各家框架互相借鉴、共同演进。

A1
附录

FDD 五阶段详解

1
Develop Overall Object Model — 开发人员和领域专家协作，建立系统整体架构模型，确保对业务逻辑有统一认知
2
Build Feature List — 将需求拆解为特性列表。特性 = <动作> <结果> <对象>，如"验证 用户的 密码"
3
Plan By Feature — 按优先级、复杂度和依赖关系制定开发计划，分配特性小组
4
Design By Feature — 针对单个特性进行详细设计：设计评审、时序图、类定义
5
Build By Feature — 编码、单元测试、代码评审，通过后集成到主干

八大最佳实践：领域对象建模 · 按特性开发 · 类负责人制 · 特性小组 · 代码评审 · 定期集成 · 配置管理 · 报告进度

A2
附录

FDD vs Scrum

维度FDD（特性驱动）Scrum（迭代驱动）
关注点工程实践、架构和代码质量过程管理、团队协作和交付节奏
迭代单位特性（Features）冲刺（Sprints）
代码归属明确的类负责人制团队共同拥有代码
适用场景中大型项目，对架构要求较高各种规模，强调快速反馈
设计方式先建模再按特性切分按冲刺批量处理
进度可视特性完成进度（看板）Burndown 图
FDD 更关注怎么写好代码，Scrum 更关注怎么管理过程。两者可以互补 — 用 Scrum 管节奏，用 FDD 管工程质量。
谢谢

FDD 驱动 AI Coding 工作流

从理论框架到工程实践

分享人：杨正武 · 2026-05
基于 EvoDev (arXiv:2511.02399) · Feature-Workflow Plugin · 55 个特性归档