Vibe Coding 时代，为了解决 AI 因缺乏对项目整体背景、架构约束和长期目标的理解，输出往往会出现不一致，导致上下文频繁丢失和潜在的架构漂移的问题，规范驱动开发（Spec-Driven Development）与上下文驱动开发（Context-Driven Development）等方法论应运而生，旨在"先写规格说明，再让 AI 按规格生成代码"。本文将会介绍 SDD 与 CDD 方法论，以及方法论在 Spec-Kit、OpenSpec、Conductor 工具中的应用，最后介绍作者的 Conductor Workflow 配置工具 create-conductor-flow。
背景：从 Vibe Coding 到结构化 AI 编程
2025 年 2 月，Andrej Karpathy 创造了 "Vibe Coding" 一词，主张"忘记代码的存在"。该概念迅速风靡，但也带来了大量技术债务——行业称之为 "Vibe Coding 宿醉"（Vibe Coding Hangover）。
作为回应，2025 年下半年两个方法论相继浮出水面：
- Spec Driven Development (SDD)：以 GitHub Spec-Kit、AWS Kiro、Tessl 为代表
- Context Driven Development (CDD)：以 Google Conductor 为代表
两者都试图为 AI 编码引入结构和纪律，但切入角度不同。
SDD（Spec Driven Development）
一种 AI 辅助编程范式，在编码前先编写结构化的需求规格说明，使规格成为人类和 AI 的共同真相来源。根据规格的生命周期和权威程度，分三个递进层次。
"规格不服务于代码；代码服务于规格"
核心原则：
- 意图先行：先定义"做什么"和"为什么做"
- 规格即真相：规格是开发的锚点
- 行为导向：spec 描述系统行为、约束、接口契约和成功标准
- AI 执行：AI 根据 spec 生成、验证和重新生成代码
- 可追溯性：从意图到需求到设计到任务到代码，全链路可追溯
CDD（Context Driven Development）
一种 AI 辅助编程框架，通过系统化管理三层上下文（项目级、任务级、历史级）使 AI 理解完整项目语境，核心主张是人类保持对代码的理解和控制。
"AI 分析整个项目，而非单行代码"
核心原则：
- 上下文持久化：将上下文从瞬态聊天转为持久化 Markdown 文件
- 意图先于实现：编码前先形式化需求规格和执行计划
- 持续反馈循环：借鉴 DevOps 的持续集成理念
- 人类掌控权：开发者做架构决策，AI 是顾问而非替代者
- 上下文即代码（CaC）：代码和文档同时服务于人类和 AI
- 全栈上下文感知：理解代码库整体而非单个文件
简单类比
| 方法 | 比喻 |
|---|---|
| Vibe Coding | 告诉装修工"随便弄好看点" |
| SDD | 先画完整施工图纸，工人严格按图施工 |
| CDD | 带装修工参观你家，了解你的风格偏好，再开始干活 |
CDD 更像是给 Vibe Coding 加上下文约束，而 SDD 是用规范文档来约束。两者都是为了解决 Vibe Coding 的混乱问题，但采用了不同的路径。
1 | Vibe Coding 的反面 |
两个维度
1 | 强上下文（上下文深度） CDD |
| 维度 | CDD | SDD |
|---|---|---|
| 关注点 | 输入：AI 了解多少现有项目 | 输出：如何约束 AI 生成 |
| 核心问题 | "AI 理解我的代码库吗？" | "AI 按照规范生成吗？" |
| 侧重 | 理解你已有的 | 定义你要建的 |
组合使用
四种组合可能：
| 组合 | 描述 | 效果 |
|---|---|---|
| 低 CDD + 低 SDD | Vibe Coding | 混乱 |
| 高 CDD + 低 SDD | 纯上下文辅助 | AI 理解项目但自由发挥 |
| 低 CDD + 高 SDD | 纯规范驱动 | 有规范但不理解现有代码 |
| 高 CDD + 高 SDD | 两者结合 | AI 既理解项目，又按规范行事 |
Google Conductor 声称 CDD ，实际是就是加入上下文工程的 SDD，用 Google Conductor 团队的话说："不是直接跳入实现，而是先将你的意图形式化。CDD 通过将项目上下文从聊天窗口转移到代码库本身来解锁上下文驱动的开发。"
SDD 的三个层次（Bockeler/Fowler 框架）
Birgitta Bockeler（Thoughtworks 杰出工程师）在 Martin Fowler 网站上提出了 SDD 的三层次框架：
层次一：Spec-First（规格优先）
在 AI 编码前先编写规格说明，作为本次任务的指导。任务完成后，规格通常被丢弃。
- 规格是临时性工具
- 后续变更需创建新规格
- 人类仍然直接维护代码
- 代表工具：Kiro、Spec-Kit、Antigravity
层次二：Spec-Anchored（规格锚定）
规格在功能创建后持续保留，在维护和演进阶段持续编辑。人类和 AI 共同修改规格与代码。
- 规格成为功能的长期文档
- 规格与代码并行维护
- 两者都是可编辑工件
- 代表工具：Conductor（归档保留模式）、Tessl（声称目标）
层次三：Spec-as-Source（规格即源码）
规格成为主要可编辑工件，人类只维护规格，永远不直接触碰代码。
- 代码标注
// GENERATED FROM SPEC - DO NOT EDIT - 人类与代码的交互只通过规格间接进行
- 最激进的 SDD 形态
- 代表工具：Tessl（探索中）
| 层次 | 规格寿命 | 代码地位 | 人类编辑对象 |
|---|---|---|---|
| Spec-First | 临时 | 主要工件 | 规格 + 代码 |
| Spec-Anchored | 持久 | 并行工件 | 规格 + 代码 |
| Spec-as-Source | 永久 | 派生产物 | 仅规格 |
SDD 工具对比
四个工具都实现了 Spec-Driven Development (SDD)，但设计理念和严格程度各有不同：
| 工具 | 发布方 | SDD 层级 | 核心理念 |
|---|---|---|---|
| Kiro | Amazon | Spec-First | EARS 语法 + Steering 守护栏 |
| Conductor | Spec-First | 项目级上下文增强，TDD 内建 | |
| Spec Kit | GitHub | Spec-First | Constitution 驱动的严格规范，TDD 内建 |
| OpenSpec | Fission AI | Spec-Anchored | Delta Specs 增量迭代 |
完整信息参考 [SDD 工具对比]
工具定位图谱
| 工具 | 项目级规则 | Feature Spec |
|---|---|---|
| Spec Kit | Anchored (Constitution) | First (branch 生命周期) |
| Kiro | Anchored (Steering) | First (task 生命周期) |
| Conductor | Anchored (product.md，tech-stack.md) |
First (track 生命周期) |
| OpenSpec | 无 | Anchored (系统真相源) |
1 | 纯 CDD 纯 SDD |
递进关系：
1 | 无 Spec → Spec-First → Spec-Anchored → Spec-as-Source |
如何选择
| SDD 层级 | 每次任务需要加载的上下文 | Token 消耗 |
|---|---|---|
| Spec-First | 当前任务的 spec + 项目规则 | 较低 |
| Spec-Anchored | 当前任务的 spec + 所有相关的现有 specs / specs 索引 + 项目规则 | 较高 |
| Spec-as-Source | 完整 specs（代码从 spec 派生，需要全量理解） | 最高 |
系统越大，specs/ 目录越庞大，每次变更的 context 成本越高，即使存在分层加载也不能解决，这是一个 trade-off。
所以 Spec-First 是当前性价比最高的层级，Spec-Anchored 适合对一致性要求极高且愿意承担 token 成本的场景，具体额外成本需要实测评估。
如何使用 Conductor
Gemini CLI
1 | gemini extensions install https://github.com/gemini-cli-extensions/conductor --auto-update |
Coding Agent
1 | npm create conductor-flow |
Or if you prefer the shorthand alias:
1 | npx conductor-init |