这篇文章探讨了新兴的"规范驱动开发"(SDD)概念，指出其核心在于先编写规范文档再生成代码，将规范作为开发过程中的主要依据。作者分析了GitHub的spec-kit和Tessl等工具对SDD的不同定义，发现实际应用中存在多个实现层次，但都强调规范优先于代码的理念。

理解规范驱动开发：Kiro、spec-kit与Tessl的探索

规范驱动开发（SDD）的定义与层次

当前，"规范驱动开发"（SDD）尚无统一标准，但其核心理念可归纳为：先编写规范（Spec），再通过AI生成代码，并将规范作为开发过程中的唯一真相源。根据实践观察，SDD可分为三个层次：
1. 规范优先（Spec-first）：先编写详细规范，再通过AI辅助开发。
2. 规范锚定（Spec-anchored）：开发完成后保留规范，用于后续功能迭代。
3. 规范即源码（Spec-as-source）：仅维护规范文件，代码完全由AI生成且不可手动修改。

目前多数工具仅实现"规范优先"，而"规范锚定"和"规范即源码"仍处于探索阶段。

规范的本质与分类

规范通常被类比为"产品需求文档"，其核心特征包括：
- 结构化：以自然语言描述软件功能，指导AI生成代码。
- 行为导向：聚焦功能意图而非技术细节。
- 与上下文分离：区别于通用的"记忆库"（如项目架构文档），规范仅针对特定功能或任务。

三大SDD工具对比

1. Kiro（轻量级）

   • 流程：需求（用户故事）→ 设计 → 任务清单
   • 特点：通过Markdown文件分阶段引导，但规范仅用于一次性开发，未强调长期维护。

2. GitHub的spec-kit（高定制化）

   • 流程：宪法（基础规则）→ 规范 → 计划 → 任务（循环迭代）
   • 特点：依赖大量模板文件和检查清单，但规范分支策略暗示其仍偏向"规范优先"。

3. Tessl Framework（实验性）

   • 目标：实现"规范即源码"，生成代码标注// GENERATED FROM SPEC - DO NOT EDIT。
   • 挑战：需反复迭代规范以提高生成确定性，类似传统模型驱动开发（MDD）的困境。

实践中的关键问题

• 适用性矛盾：现有工具流程冗长，小问题（如修复Bug）可能被过度复杂化。
• 规范与代码的权衡：大量Markdown文件的审阅负担可能超过直接修改代码。
• 非确定性风险：即使规范详尽，AI仍可能忽略指令或过度生成。
• 历史教训：类似MDD的尝试曾因抽象层级尴尬而失败，需警惕"规范即源码"重蹈覆辙。

结论

SDD的核心理念（先规范后开发）具有价值，但当前工具尚未成熟。未来需解决以下问题：
- 提供灵活的工作流以适应不同规模任务。
- 优化规范审阅体验，平衡人工与AI的协作。
- 从历史经验（如MDD）中学习，避免过度依赖规范导致效率下降。

术语"SDD"仍处于语义扩散阶段，甚至被泛化为"详细提示词"的同义词。在工具完善前，开发者需谨慎评估其实际效用，避免陷入"越改越糟"的陷阱。

（注：原文中的图片描述和部分技术细节已精简，保留核心逻辑与案例。）

以下是评论内容的总结，平衡呈现不同观点并保留关键引用：

1. 对SpecKit的期待与失望

   • 正面：认为SpecKit有潜力但缺乏高级用例指导（"excited by it, but have had a hard time finding guidance on advanced real world use cases" - yodon）。
   • 负面：工具过度复杂化简单任务（"equivalent of Tony Stark building a robot from scratch in a cave" - ctxc），且生成的任务列表冗长（"12+ tasks with 4+ sub-tasks each" - hatmanstack）。

2. AI辅助开发的局限性

   • 人类仍需主导：AI在复杂场景中易混淆且需人工纠正（"AIs have been trying to bullshit me so much" - tharkun__）。
   • 测试问题：AI不擅长TDD，常需返工修复测试（"Claude is bad at TDD... has to go back and fix the tests" - yoaviram）。

3. 轻量级规范的价值

   • 支持简单规范：Markdown文档已足够（"just a simple Markdown file... don’t see value in the formalism beyond that" - esafak）。
   • 规范驱动效率：规范帮助拆分任务并加速开发（"helped me code faster... clarified a lot of things" - raphinou）。

4. 对SDD趋势的质疑

   • 回归瀑布式开发：担忧SDD可能导致过度设计（"feels like the process pendulum is swinging back toward... Big Design Up Front" - tconfrey）。
   • 讽刺性评论：直指当前模式是"AI加持的瀑布开发"（"waterfall, but with AI" - constantcrying）。

5. 改进建议

   • 灵活命令：提议通过自定义命令（如/experiment）平衡规范与灵活性（"bring context management benefits without the bloat" - josefrichter）。
   • 分层规范：将规范分为用户输入和输出验证两级（"split it into two levels... input prompt and output spec" - robertclaus）。

关键矛盾点：工具在提升效率（如raphinou）与增加复杂性（如ctxc）之间的平衡问题，以及AI能否真正替代人类决策（tharkun__ vs. yoaviram的实践对比）。