Spec-Driven Development：从提示词工程到规格工程

1背景与定义：为什么 2025 年"写规格"突然值钱了

规格驱动不是新概念——航天、军工、瀑布式企业软件写了几十年需求规格说明书。它在新一轮 AI 编程浪潮中翻红，是因为经济学反转了：

• 过去：写规格贵（资深工程师的时间），写代码也贵，所以大家用敏捷把规格削薄，用"沟通 + 迭代"补齐。
• 现在：代码生成近乎免费，但 AI 没有"意图"。需求理解错误时，AI 会以极快的速度产出大量自信但错误的代码——纠错成本随生成速度同步放大。

于是 2025 年出现了明确的范式口号：人负责 what 与 why，AI 负责 how。规格文档从"大公司流程"变成"给 Agent 的高精度输入"，这正是"从提示词工程到规格工程"的含义——提示词是对话级、一次性的；规格是工件级、可版本化、可评审、可复用的。它也常被视为上下文工程（见本系列 003 篇）在需求侧的具体应用。

SDD 的标准工作流通常是四步：specify（写需求）→ clarify（AI 反问补全模糊点）→ plan（技术方案）→ tasks（拆任务），之后才进入实现。实现阶段 AI 严格对照 tasks 逐项打勾，验收阶段再对照 spec 里的标准逐条核对。

2现状与工具格局：五家框架，两种路线

格局上形成了两条路线：IDE 内置路线（Kiro：开箱即用，但 spec、hooks、steering 都长在它的 IDE 里）与工具无关路线（Spec Kit、OpenSpec：spec 是仓库里的 Markdown，Cursor、Claude Code、Codex 都能消费）。2025 年 Spec Kit 发布时，社区曾出现"Kiro is cooked"的争论——如果 GitHub 用开源工具包把规格流程做成通用约定，绑定 IDE 的产品价值就会被抽空。一年后看，两条路线都活着，但规格文件本身普遍 Markdown 化、仓库化已是行业共识。

3两条路线与案例

3.1 GitHub Spec Kit：把流程做成"仓库里的约定"

Spec Kit 的聪明之处在于它几乎"没有产品"：初始化后只生成一套 Markdown 模板与斜杠命令约定。需求阶段 AI 会主动追问边界条件（未登录用户怎么办？并发写怎么处理？），产出的 requirements.md 里带 EARS 风格的结构化语句（当…时，系统应当…），这类句式可直接映射为验收测试。它还支持为项目写一份 constitution——"本项目的不可妥协原则"（如"API 一律向后兼容""绝不引入新 ORM"），每次生成都受宪法约束。

3.2 什么时候值得上 SDD：一个判断矩阵

4机会分析

个人开发者：把 spec 当复利资产。同一份 requirements + tasks，今天喂给 Claude Code，下个月喂给 Codex，规格不变、执行者可换——这是对抗工具涨价与能力波动的唯一低成本手段。此外，写 spec 的过程本身就是免费的产品思考：AI 的反问（clarify 阶段）会把你自己都没想清的边界逼出来。

小团队：spec 即对齐、即验收。两三人的远程团队用 spec 文档代替大半会议：分歧在 Markdown 里用 diff 解决，AI 按 tasks 逐项实现，验收按 requirements 逐条核对。交付外包时，一份结构化 spec 直接可用作合同附件。

差异化切入点：

• 规格模板生意：面向垂直场景（跨境电商站、SaaS 计费模块、合规审计）卖"填空即用"的 spec 模板包，与 080 篇的模板/Boilerplate 生意同构但更轻。
• spec → 测试的转换器：把结构化 requirements 自动转成验收测试用例的工具仍是空白地带，是开源刷脸 + 商业化托管的好题材。
• "规格工程师"服务：帮非技术创业者把想法整理成可交给任何 Agent 执行的规格包，按项目收费——本质是 AI 时代的产品咨询。

5风险与挑战

• 过度规格化：小项目套大流程，规格写得比代码还长。纪律是：spec 只写意图与验收，不写实现细节。
• 规格腐化（spec rot）：代码改了 spec 没改，文档变成谎言。对策是把"更新 spec"写进每个功能的 Definition of Done，或让 AI 在 PR 里检测 spec 与代码的漂移。
• 自嗨循环：让同一个模型写 spec、写代码、再做验收，等于既当运动员又当裁判——错误需求会被"自信地"全程贯彻。关键决策处必须有人类评审，或至少换一个模型做红队式质疑。
• 格式碎片化：Spec Kit、Kiro、OpenSpec 的文件结构互不相同，跨工具迁移要靠人工整理；短期内没有事实统一标准，选 Markdown 最朴素的方案最抗风险。
• 厂商路线风险：Kiro 式"IDE 内置 spec"体验顺滑但迁移成本高，参考其定价风波——流程资产的产权要留在自己仓库里。

6行动建议

• 用 specify 起步：安装 GitHub Spec Kit（开源、工具无关），给当前项目初始化一套 spec 模板，体验一次 /specify → /clarify → /plan → /tasks 全流程。
• 为最有价值的一个项目写 constitution：列 5-8 条不可妥协原则（技术栈边界、安全底线、兼容性承诺），放进仓库根部让所有 Agent 读取。
• 建立"spec 先行"触发器：凡是预计超过 1 天或涉及数据模型的功能，先写 requirements 再动代码；更小的改动保持对话式。
• 交叉评审防自嗨：重要 spec 让另一个模型（或另一个人的新鲜视角）只做质疑与找漏洞，不做实现。
• 把验收标准写成可执行断言：requirements 里的每条"系统应当…"尽量能映射成一条测试，让 AI 实现后自跑测试并汇报。
• 季度清理：检查 spec 与代码的漂移，删掉过时文档——撒谎的文档比没有文档更危险。