理解规范驱动开发 (SDD)

核心定义："文档优先"。在 AI 写代码前先写规范 (Spec)，规范是人类与 AI 的共同真理源。

🥈 Level 1: Spec-first

规范优先

先写好规范辅助 AI 开发。
任务完成后，规范可能被丢弃。
目前大多数工具属于此类。

🥇 Level 2: Spec-anchored

规范锚定

规范是“活”的。
任务完成后保留规范，用于后续维护。
规范随功能演进而更新。

💎 Level 3: Spec-as-source

规范即源码

规范是唯一的真理源。
人类只编辑规范，绝不触碰代码。
代码完全由 AI 生成。

📝 什么是 "Spec" vs "Memory Bank"?

Memory Bank (记忆库/上下文): 全局性文档。如 project.md, rules，适用于所有会话。
Spec (规范): 针对特定任务的文档。如 story-123.md, data-model.md。

🛠️ 三款工具深度评测

注：评估 SDD 工具非常耗时，且在旧代码库(Brownfield)中难以应用。

🟢 Kiro (轻量级)

定位： Spec-first，基于 VS Code。

工作流： 需求 (Requirements) → 设计 (Design) → 任务 (Tasks)

Input: 用户故事 + GIVEN/WHEN/THEN 验收标准。
Output: 包含待办事项的 Task 列表，可逐个运行。
记忆库: 称为 "Steering" (产品/技术/结构文档)。

🔵 spec-kit (GitHub 出品)

定位： Spec-first (虽然看似锚定，但为每个 Spec 建分支)。

工作流： 宪法 (Constitution) → 定义 (Specify) → 计划 (Plan) → 任务 (Tasks)

核心: "Constitution" (宪法) 是不可变的原则文件。
特点: 高度依赖 Checklist (检查清单) 和 CLI 命令。
体验: 生成大量 Markdown 文件，过程繁琐。

🟣 Tessl (Beta 阶段)

定位： Spec-anchored / Spec-as-source。

工作流： Spec ↔ Code (双向同步/生成)

机制: 代码文件标记 // GENERATED - DO NOT EDIT。
逆向: 可通过 CLI 将现有代码反推为 Spec。
现状: 目前是 1:1 映射 (1 Spec = 1 Code File)。

🧐 深度反思与质疑

1. 流程适配性 (One size fits all?)
工具流程过于僵化。修复一个小 Bug，Kiro 却要求写 4 个用户故事；spec-kit 的文档量对于中小型功能来说是“杀鸡用牛刀”。

2. 审查疲劳 (Markdown vs. Code)
比起审查几十个冗长的 Markdown 文件，开发者可能更愿意直接审查代码。SDD 必须提供极佳的审查体验才能落地。

3. 虚假的控制感 (False sense of control)
即使有详细的“宪法”和检查清单，AI 仍会忽略指令或过度执行 (Hallucinations)。“小步迭代”可能比“大而全的 Spec”更可控。

4. 历史的教训 (SDD vs MDD)
Spec-as-source 让人联想到失败的 MDD (模型驱动开发)。SDD 可能会同时继承 MDD 的不灵活和 LLM 的不可靠 (非确定性)。

5. 目标用户错位
要求开发者写详细的产品需求和用户故事，是否意味着开发者要兼职产品经理？

🏁 结论：Verschlimmbesserung?

虽然 "Spec-first" 的原则很有价值，但目前的工具似乎在生硬地套用工作流。

作者用德语词 "Verschlimmbesserung" (越改越糟/弄巧成拙) 来表达担忧：我们是否为了改进开发体验，反而创造了更繁琐、更难维护的东西？

* 术语 "Spec-driven development" 目前定义模糊，有时甚至仅指 "详细的 Prompt"。

📑 理解规范驱动开发 (SDD)

🧩 SDD 的定义与层级