作者实测 Spec Kit 后认为，Spec Driven Development 虽理念新颖，但效率低下、流程冗余，远不如“氛围式编程”高效实用，甚至可能倒退回瀑布式开发。
Spec Driven Development（规格驱动开发，简称 SDD）。
这个概念最近被 GitHub 上一个叫 Spec Kit 的开源项目炒得火热，号称能靠“精准规格文档”直接生成可运行的代码，彻底取代“代码即真理”的传统开发模式。听起来是不是很酷？很未来？但真相到底如何？
今天给大家深度拆解一篇来自 Scott Logic 博客的实测长文，作者 Colin Eberhardt 亲自上手用 Spec Kit 重构自己儿子的卡丁车数据管理应用，结果却大失所望。他不仅花了几小时看 AI 生成几千行 Markdown，最后还得手动修 bug，效率还不到他平时“随心所欲”编程的十分之一！
什么是规格驱动开发（SDD）？AI 编程的新圣杯？
先给不熟悉的朋友科普一下：规格驱动开发（SDD） 是一种试图把“规格文档”变成软件开发唯一源头的全新范式。传统开发中，代码是最终裁决者——你写什么，系统就跑什么，文档很容易和代码脱节。
而 SDD 的核心思想是：规格即法律。你先写一份极其详细、结构清晰、逻辑严密的规格文档，AI 代理就能根据这份文档自动生成完整的实现代码。你后续想改功能？别碰代码！只需修改规格，然后一键“再生”代码。
听上去是不是像编程界的“乐高说明书”？只要图纸够准，拼出来的房子就稳如泰山。
这个理念最早在 2024 年下半年开始流行，当时 AI 编程代理能力突飞猛进，像 Claude Opus 4.5、GPT-5 Codex Max、Gemini 3 这些顶级模型已经能完成中等复杂度任务。
开发者们开始思考：既然 AI 能写代码，那我们是不是该把精力更多放在“描述问题”而非“实现细节”上？于是 SDD 应运而生。
其中，GitHub Spec Kit（2025 年 9 月发布）被认为是 SDD 最纯粹的代表，它强制实行“规格即源”（spec-as-source）模式，短短两个月就收获了 5 万 GitHub Star，风头一时无两。
还有 Tessl 框架、亚马逊 Kiro 等类似工具，也都试图把 AI 编程流程“工业化”“标准化”。
但 Colin 的实测，却狠狠泼了一盆冷水。
作者是谁？为什么他的体验值得相信？
在深入细节前，先聊聊作者 Colin Eberhardt。他是英国知名金融科技公司 Scott Logic 的 CTO，同时也是开源社区的活跃贡献者，技术博客写了十几年，以严谨、实证、不盲从著称。他不是随便玩玩 AI 的新手，而是长期关注 LLM 编程演进的资深工程师。早在 2024 年初，他就尝试过 Harper Reed 提出的“对话式规划 + 代理实现”工作流，并认为那是当时最高效的 AI 编程方法。但不到一年，他就感慨那套方法已经“过时”。这说明他始终站在 AI 编程实践的最前沿，而且愿意亲手验证新工具——不是道听途说，而是真刀真枪地干。
所以，他对 Spec Kit 的批评，不是情绪化的吐槽，而是基于真实项目、真实时间投入、真实代码产出的深度反思。
实战测试：用 Spec Kit 重写一个卡丁车管理功能
Colin 决定用自己业余开发的*KartLog（卡丁车日志） 应用来测试 Spec Kit。这个 PWA 应用用的是常见技术栈：JavaScript + Firestore + SvelteKit + SMUI（Svelte Material UI），功能是帮他儿子记录卡丁车比赛的各种数据：引擎、轮胎、圈速、赛道设置、天气等。原本他用 Google 表格加一堆脚本管理，后来觉得不够用，就自己撸了个 App。
测试目标很明确：把已有的“赛道管理”功能完整删掉，再用 Spec Kit 从零重建。这个功能不算复杂，主要是 CRUD（增删改查）操作，外加和现有数据模型集成、GPS 定位支持。但正因为是他亲手写过的，所以他能写出“无歧义”的规格——他知道所有边界条件和业务逻辑。这为实验提供了绝佳的对照基础。
第一步：宪法（Constitution）——定规矩，但花了 4 分钟只产出 189 行 Markdown
Spec Kit 的第一步不是写代码，也不是写功能规格，而是先定义 Constitution（宪法）。你可以理解为项目的“最高指导原则”，比如是否采用 TDD（测试驱动开发）、代码风格偏好、错误处理策略等。Colin 运行了 /speckit.constitution 命令，AI 代理花了 4 分钟分析他的代码库，生成了一份 189 行的 Markdown 文件。内容其实挺“正确但平庸”——比如强调“用户故事必须可测试”“数据必须验证”等常识。因为是个人项目，他并不想搞 TDD，就让 Copilot（集成 Claude Sonnet 4.5）调整宪法，又花了 5 分钟。
这一步还算顺利，但已经让人隐隐觉得：为了生成代码，先得写一堆元文档？
第二步：规格（Specify）——189 行规格描述一个 CRUD 功能？
接下来是核心：写功能规格。Colin 给 AI 的提示是：“我想把赛道从一个字符串字段升级为独立实体（含名称、经纬度、备注），并提供类似引擎管理的 CRUD 界面。” 听起来很直接对吧？结果 Spec Kit 的 /speckit.specify 命令跑了 6 分钟，吐出一份 189 行的规格文档，包含：5 个用户故事、18 项功能规格、6 个预期结果、8 条假设，甚至还有一份 41 行的“自评估报告”，用来检查规格是否符合宪法！有些假设还挺到位，比如“需要迁移旧会话数据”。
但 Colin 也手动删掉了一些“放错位置的非功能性需求”。光写规格就花了 20 多分钟，产出 230 行 Markdown。对比一下：如果直接写代码，这功能可能半小时就搞定了。
第三步：规划（Plan）——2000 行 Markdown 描述 700 行代码？
最离谱的来了：Plan（规划）阶段。这一步本意是把规格翻译成可执行的技术方案。但 /speckit.plan 命令跑了 8 分半钟后，生成了惊人的*2067 行 Markdown！具体包括：444 行的模块契约（含大量代码片段）、395 行的数据模型（含迁移细节）、285 行的项目计划、500 行的快速上手指引、406 行的研究文档（比如解释“为什么用 SMUI？因为其他页面都用它！”）。
Colin 说，这部分内容“明显冗余”，很多只是把规格机械地翻译成技术术语，毫无新价值。他花了整整 2 小时审查——但他自己也怀疑：这一步真的需要人工审吗？AI 生成的规划，人看得懂但改不动，不看又怕出错，陷入两难。
第四步：任务（Tasks）——66 个步骤，但还是不能写代码！
你以为下一步就能生成代码了？不！Spec Kit 还有个 Tasks（任务） 阶段。它会分析 Plan 文档，生成一份 66 步的详细任务清单，标明哪些可以并行、哪些有依赖。这一步又花了 8 分半钟，但输出很简洁（相对而言）。然而，这又是一个“中间产物”。
Colin 感到无比烦躁：我只想实现一个功能，为什么要先走完宪法→规格→规划→任务这四重门？ 每一关都要等 AI 慢悠悠生成几千字文档，然后人还得战战兢兢地审，生怕漏掉关键假设。整个过程像在玩“文字版乐高”，但积木块全是纸做的。
第五步：实现（Implement）——13 分钟生成 700 行代码，但跑不起来！
终于到了 /speckit.implement 阶段！AI 花了 13 分 15 秒，生成了 14 个文件、约 700 行代码。Colin 兴冲冲启动开发服务器——结果直接报错！ 一个低级得不能再低级的 bug：在新建会话表单中，变量 circuitsData 没从数据存储里加载。这种问题，任何一个有经验的开发者肉眼都能发现。Colin 把错误粘贴给 Copilot，30 秒就修好了——典型的“氛围式编程（vibe coding）”风格：边跑边调，快速迭代。
但问题来了：按照 SDD 哲学，bug 说明规格不完善，你应该回过头去修规格，而不是改代码！ 可这个 bug 根本和规格无关——规格说“能管理赛道”，没说“必须加载数据”，这是纯实现疏忽。Colin 问 Copilot 该怎么从规格层面修正，AI 也承认：这不属于规格问题。这暴露了 SDD 的致命软肋：它无法处理“实现细节的随机性错误”，而这类错误在真实开发中占比极高。
最终，他只能“违规”手动修代码，违背了 SDD 的初衷。
第二轮测试：加个 GPS 功能，又是 2000 行 Markdown！
不甘心的 Colin 又试了第二轮：给赛道管理加 GPS 功能——编辑会话时自动选最近赛道，新增赛道时可一键获取当前位置。这功能很小，按理说几分钟搞定。结果 Spec Kit 又花了 23 分半生成约 300 行代码，但伴随的是 2262 行 Markdown！
他惊讶地发现，仅 Implementation 阶段就耗时 11 分钟。对比他的常规流程：8 分钟生成 1000 行代码，零 Markdown，15 分钟审查，9 分钟测试修 bug，全程无错误。
SDD 的效率差距，已经不是“慢一点”，而是“差一个数量级”。
为什么 SDD 像瀑布模型？AI 时代还需要重型流程吗？
Colin 在文中犀利指出：SDD 本质上是瀑布模型的 AI 包装版。瀑布模型强调“先设计，再实现”，阶段分明、文档先行，结果往往脱离实际、难以变更。而敏捷开发的核心就是“拥抱变化、快速迭代”。现在 AI 让代码变得“极其廉价”——生成快、修改快、抛弃也快。我们应该利用这一特性，用“测试+反馈”驱动开发，而不是用“规格+规划”束缚手脚。
Spec Kit 强迫你把 80% 的时间花在审查 AI 生成的冗余文档上，却忽略了 AI 真正的强项：快速生成可运行代码。这就像给法拉利装了个手摇启动器——技术先进，流程倒退。
代码才是法律！规格文档无法替代形式化验证
SDD 宣称“规格即法律”，但 Colin 反驳：代码才是真正的法律。为什么？因为代码是形式化语言，可以被编译器、测试框架、类型系统精确验证。你写错一个分号，程序直接报错。但 Markdown 规格呢？它本质是自然语言，充满模糊性。
AI 生成的规格看似详细，实则可能暗藏逻辑矛盾或遗漏。比如 Spec Kit 的规划里会写：“卡丁车用户常戴手套操作手机，所以 UI 要大按钮”——这听起来合理，但属于“伪上下文”，实际是否必要？
只有用户测试说了算。AI 擅长的是生成 plausible（看似合理）的内容，而非 provably correct（可证明正确）的内容。把软件命运押在 Markdown 上，风险极高。
AI 到底更擅长写代码，还是写文档？
Colin 提出一个灵魂拷问：大模型到底更擅长写代码，还是写 Markdown？ 从训练数据看，GitHub 上的代码量远超技术文档。模型在代码语法、API 调用、模式匹配上经过海量训练，但写高质量规格文档的能力，其实很弱。它只能机械拆解需求，堆砌术语，无法真正理解业务。
所以，让 AI 花 10 倍时间写文档，再基于文档写代码，等于让一个顶尖程序员先写 10 页设计说明书，再照着说明书写代码——纯属内耗。直接让它写代码，人负责测试和引导，效率高得多。
SDD 是为谁设计的？也许不是给“氛围工程师”
Colin 反思：也许 Spec Kit 的目标用户不是他这种“氛围工程师”（vibe engineer）——即自己懂代码、能架构、会审查、敢重构的全能开发者。SDD 可能更适合产品经理、业务分析师，或者那些“不敢直接写代码”的初学者。对他们来说，有一个结构化流程，能降低心理门槛。
但问题是：如果使用者不懂代码，如何判断 AI 生成的规格是否合理？如何验证最终实现是否符合业务？ 这就像让一个不会开车的人写赛车设计图纸——再详细，也造不出能跑的车。
SDD 的“民主化编程”愿景很美好，但忽略了软件开发的核心：对系统行为的精确控制和快速验证能力。
作者的态度：虽不看好，但承认其思想价值
尽管全程批判，Colin 最后还是给了 SDD 一些肯定。他说：SDD 就像 TDD（测试驱动开发）、XP（极限编程）一样，是一种激进的软件工程思想实验。它迫使我们思考：在 AI 时代，开发流程该如何重构？规格、代码、测试三者的关系是否需要重新定义？这些讨论本身极有价值。他不反对“规格先行”的理念，但反对 Spec Kit 这种“工业化流水线”式的极端实现。
他主张“实用主义”：取 SDD 之精华（比如明确需求），弃其糟粕（比如冗余文档），融入现有敏捷流程。毕竟，工具是为人服务的，而不是反过来。
结语：AI 编程的未来在于“人机共舞”，而非“文档牢笼”
Colin 的实测给所有沉迷“AI 自动化”的开发者提了个醒：不要为了流程而流程。AI 的真正价值，不是取代人类思考，而是放大人类创造力。在他自己的“氛围式编程”中，他和 Copilot 形成了一种高效协作：他出想法，AI 出代码；他跑测试，AI 修 bug；他看架构，AI 写细节。整个过程流畅、快速、富有掌控感。
而 Spec Kit 却用一堆中间文档，在人和 AI 之间筑起高墙，反而拖慢了节奏、增加了认知负担。
在 AGI（人工通用智能）尚未到来的今天，最强大的开发模式，依然是“人机共生”——人负责方向与验证，AI 负责执行与生成。 至于 Spec Kit？它可能是一个有趣的探索，但绝不是未来。至少现在，最快的路，还是边写边调，而不是先写一万字说明书。