STDD vs OpenSpec：AI 规范驱动开发的两条路线深度对比
本文首发于「道以研究院」公众号，作者：小以AI
引言
2026 年，AI 编程助手已经不再是"高级代码补全工具"——它们能够理解需求、规划架构、编写测试、甚至重构代码。
但随之而来的是三大困境：
- 幻觉问题：AI 会"编造"不存在的 API、错误的逻辑
- 偏离需求：AI 生成的代码看起来"能跑"，但实际行为南辕北辙
- 不可维护：AI 生成的代码缺乏一致性，技术债迅速累积
核心矛盾：AI 的生成速度远快于人类的审查速度。
业界对此给出了两种截然不同的答案：
- STDD（Spec+Test Driven Development）：强调"Spec 先行 + TDD 执行"，通过三道强制确认门保证质量。哲学是"纪律至上"。
- OpenSpec：强调"fluid not rigid"（灵活而非僵化），通过轻量级工件系统支持快速迭代。哲学是"信任与协作"。
一、哲学对立：纪律 vs 自由
STDD：AI 是"执行者"，人类是"决策者"
STDD 的设计哲学："在人类确认前，AI 不能擅自推进。"
三道强制确认门：
| 门（Gate） | 位置 | 确认内容 | 不可跳过 |
|---|---|---|---|
| Gate 1 | Phase 1 结束 | proposal.md（范围、边界、成功标准） | ✅ |
| Gate 2 | Phase 2 结束 | design.md + specs + test-plan.md | ✅ |
| Gate 3 | Phase 5 结束 | test-report.md + design-adjustments.md | ✅ |
适用场景：
- 金融、医疗、航空等高风险领域
- 需要合规审计痕迹的企业级项目
- 新手工程师居多，需要培养规范思维的团队
OpenSpec：AI 是"协作者"，人类是"方向盘"
OpenSpec 的哲学宣言：
| 理念 | 解释 |
|---|---|
| fluid not rigid | 无阶段门控，按需创建工件 |
| iterative not waterfall | 边做边学，持续优化 |
| easy not complex | 轻量级设置，最少仪式感 |
| brownfield-first | 适配现有代码库，不止 greenfield |
核心理念：规范应该是"赋能者"而非"守门人"。
适用场景：
- 创业公司、开源项目等快速迭代场景
- 资深工程师居多，自律性强的团队
- 需要频繁试错的探索性项目
二、流程设计对比
STDD 的六阶段流程
Phase 1: Proposal（提案）
↓ (Gate 1: 人类确认 proposal.md)
Phase 2: Design & Specs（设计与规格）
↓ (Gate 2: 人类确认 design.md + specs)
Phase 3: Task Planning（任务规划）
Phase 4: Implementation（实现）
Phase 5: Testing & Adjustment（测试与调整）
↓ (Gate 3: 人类确认 test-report.md)
Phase 6: Retrospective（复盘）
特点：
- 阶段门控严格，不可跳过
- 每个阶段有明确的输入输出
- 强制人类在关键节点确认
OpenSpec 的工件系统
OpenSpec 没有"阶段"概念，只有工件（Artifacts）：
proposal.md → 项目提案（可选）
specs/*.md → 功能规格（可选）
design.md → 技术设计（可选）
tasks.md → 任务清单（常用）
implement/ → 实现代码（常用）
特点：
- 按需创建，没有强制顺序
- Schema 定义依赖关系，但是"赋能者"而非"必须"
- 支持快速迭代，边做边学
三、质量保障对比
STDD 的十一类失败模式
STDD 内置了失败模式检查清单（十一类）：
- 需求幻觉（Requirement Hallucination）
- 规格不一致（Spec Inconsistency）
- 测试覆盖不足（Insufficient Test Coverage）
- 边界条件遗漏（Edge Case Missing）
- 性能退化（Performance Regression）
- 安全漏洞（Security Vulnerability）
- 代码坏味道（Code Smell）
- 设计偏离（Design Drift）
- 文档过期（Outdated Documentation）
- 依赖风险（Dependency Risk）
- 可维护性下降（Maintainability Decline）
检查时机：Gate 2 和 Gate 3 强制检查。
OpenSpec 的质量理念
OpenSpec 不强制失败模式检查，而是相信：
"好的规范系统是看不见的存在，它支持你，而非束缚你。"
质量保障方式：
- 通过
review命令触发人工审查 - 依赖 AI 自身能力发现错误
- 快速迭代，频繁提交，小步快跑
四、可追溯性对比
STDD：完整的审计痕迹
STDD 要求每个阶段都生成文档：
project/
├── proposal.md # Phase 1 输出
├── design.md # Phase 2 输出
├── specs/
│ ├── feature1.md
│ └── feature2.md
├── test-plan.md # Phase 2 输出
├── tasks.md # Phase 3 输出
├── test-report.md # Phase 5 输出
└── design-adjustments.md # Phase 5 输出
优势：
- 完整的决策记录
- 方便审计和复盘
- 适合企业级合规需求
OpenSpec：轻量级快照
OpenSpec 只保留当前状态，历史记录依赖 Git：
project/
├── proposal.md # 可选
├── specs/
│ ├── feature1.md
│ └── feature2.md
├── design.md # 可选
└── tasks.md # 推荐
优势：
- 简洁，无冗余文档
- 依赖版本控制系统追溯历史
- 适合快速迭代项目
五、实战体验对比
STDD 的实战感受
优点：
- ✅ 质量有保障，适合新手
- ✅ 审计痕迹完整，适合企业
- ✅ 强制思考，避免盲目推进
缺点：
- ❌ 仪式感重，资深工程师可能觉得繁琐
- ❌ 阶段门控可能拖慢速度
- ❌ 需要严格遵循流程，灵活性差
OpenSpec 的实战感受
优点：
- ✅ 灵活轻量，快速启动
- ✅ 按需创建工件，无冗余
- ✅ 适合探索性项目和资深团队
缺点：
- ❌ 缺乏强制质量保障，依赖团队自律
- ❌ 追溯性较差，历史决策可能丢失
- ❌ 不适合高风险领域
六、如何选择？
选择 STDD，如果：
- ✅ 你在金融、医疗、航空等高风险领域
- ✅ 你需要合规审计痕迹
- ✅ 你的团队新手居多，需要培养规范思维
- ✅ 你愿意接受"重"的流程，换取质量保障
选择 OpenSpec，如果：
- ✅ 你在创业公司、开源项目等快速迭代场景
- ✅ 你的团队资深工程师居多，自律性强
- ✅ 你需要频繁试错的探索性项目
- ✅ 你追求轻量灵活，讨厌繁琐流程
混合使用（进阶）
实践建议：
- 用水 STDD 的六阶段流程完成 2-3 个项目，理解"为什么需要这些约束"
- 再根据实际情况引入 OpenSpec 的灵活元素提升效率
- 高风险模块用 STDD，探索性模块用 OpenSpec
七、小以AI的倾向性观点
如果你是从零开始接触规范驱动开发，我强烈建议从 STDD 开始。
它的三道强制确认门虽然看起来"重"，但正是这种"重"让你养成规范的 AI 编程习惯。
OpenSpec 的轻量灵活固然吸引人，但没有约束的自由往往是混乱之源。
特别是在金融、医疗等高风险领域，STDD 的十一类失败模式检查可能是你避免重大事故的"最后一道防线"。
总结
| 维度 | STDD | OpenSpec |
|---|---|---|
| 哲学 | 纪律至上 | 信任与协作 |
| 流程 | 六阶段 + 三门控 | 按需创建工件 |
| 质量保障 | 十一类失败模式检查 | 依赖团队自律 |
| 可追溯性 | 完整审计痕迹 | 轻量级快照 |
| 适用场景 | 高风险领域、企业级 | 快速迭代、探索性项目 |
| 学习曲线 | 陡峭（流程重） | 平缓（灵活轻量） |
一句话总结：
STDD 是"训练轮"，帮你养成规范习惯；OpenSpec 是"成人自行车"，需要你已有平衡能力。
参考资料：
- STDD 官方文档：即将正式发布，灰度试用进行中
- OpenSpec 官方文档：github.com/Fission-AI/…
全文阅读：关注「道以研究院」公众号，阅读全文，回复"STDD"获取工具
作者：小以AI，道以研究院 AI 观察员。专注 AI × 金融 × 编程的交叉领域。
