你有没有觉得，和 AI 一起写代码，时常像在带一个天赋异禀但不守规矩的实习生？
它能瞬间写出你半小时都憋不出的函数，也能在你最需要稳定输出时，给你一段天马行空的“艺术创作”。我们试图用复杂的 Prompt、用各种框架去约束它，但多数时候，我们仍像个疲惫的指挥官，在混乱的战场上勉力维持秩序。
因为我们搞错了一件事：开发的核心，从来不是写代码。
几十年来，代码为王。我们写的文档、画的图，都是为了服务于那最终的代码。代码是唯一的事实，文档是终将腐朽的脚手架。
但今天，AI 正在颠覆这一切。
GitHub 官方发布的一个开源项目 spec-kit（已获 2.4万+ Star），背后揭示了一种全新的开发范式——规约驱动开发（Spec-Driven Development, SDD）。
它的核心思想简单而彻底：
Spec-Driven Development (SDD) inverts this power structure.
规约驱动开发（SDD）颠覆了这种权力结构。
在这场“权力反转”中，代码不再是国王，而“规约”（Specification）——一份定义了“做什么”和“为什么做”的文档——加冕为王。代码，只是规约忠实的仆人。
这不仅是效率的提升，这是一场软件开发的工业革命。
这篇文章，就是我亲身实践这场革命的完整记录。我将带你见证，一个模糊的商业想法，是如何在一个下午之内，被 AI 变成一份包含完整架构设计和50个开发任务的专业工程蓝图。
Spec-Driven Development，AI时代的「开发宪章」
在深入案例前，我们必须先理解 SDD 的世界观。它到底是什么？
如果说我之前摸索的 cc-devflow 是一套精巧的“流程管理办法”，那么 SDD 就是一部指导AI行为的“开发宪章”。
SDD 的强大，在于它为混乱的AI开发世界，建立了三条不容置疑的核心原则：
- 规约为通用语 (Specifications as the Lingua Franca) 规约，是人类与AI之间沟通的唯一语言。它取代了代码，成为项目的“唯一事实来源”。我们的一切讨论、修改、迭代，都围绕规约进行。代码，仅仅是规约在某个特定技术栈下的自动翻译。
- 规约即可执行 (Executable Specifications) 规约不能是模糊的、供人揣测的散文。它必须精确、完整、无歧义，足以被AI直接理解并生成对应的代码和测试用例。这从根本上消除了“需求”与“实现”之间的鸿沟。
- 反馈即进化 (Bidirectional Feedback) 生产环境的运行数据、用户的行为、甚至是系统报错，都会反向流动，成为修订“规约”的输入。这形成了一个从想法到规约，再到代码，最终回归到规约的完美闭环。
理解了这三点，你就能明白，SDD 不仅仅是“让AI写代码”，而是建立了一套全新的、以规约为中心的、可持续进化的开发契约。
我如何用15分钟，为“小红书商机挖掘器”绘制完整工程蓝图
理论听起来总是优雅的。
现在，让我们进入实战，看看这部“宪章”的威力。
我的目标很简单：开发一个“小红书商机挖掘器”。
能分析评论，挖掘真实需求，并验证其商业可行性。
这是一个典型的、充满不确定性的模糊想法。
在传统模式下，这至少需要一个产品经理、一个架构师、一个项目经理花费数天时间来回拉扯。
但在SDD模式下，我只用了三条命令。
/init & /constitution — 为项目“立宪法”
首先，我通过 uv tool install 安装了 spec-kit，并用 specify init <项目名> 初始化了我的项目。
1️⃣：uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
2️⃣：
specify init <项目名>
init 项目后，会自动生成.claude 和 .specify 两个文件夹。
因为我们在 init 的时候选择的是 Claude Code，spec-kit 会自动生成Claude Code 能够识别的 commands。
.specify 文件夹里包含了memory（宪章模板） 、scripts（脚本）、templates（plan/sepc/task 等模板）
init 项目后，启动Claude Code 会自动相关命令。（偶尔会抽抽识别不出来）
我用官方的宪章文案再加上我平时的一些让 AI 遵守的原则，使用 /constitution 命令创建您项目的治理原则和发展指南，这些原则将指导所有后续的开发。
执行后，一个关键的文件诞生了：.specify/memory/constitution.md。
这，就是我们项目的“宪法”。它不是普通的配置文件，它是一系列不可动摇的原则，是给AI戴上的“思想钢印”，确保它未来所有的行为都严格遵守我们的工程纪律。
比如，其中最震撼的条款之一：
Article III: Test-First Imperative
This is NON-NEGOTIABLE: All implementation MUST follow strict Test-Driven Development.
No implementation code shall be written before:
Unit tests are written
Tests are validated and approved by the user
Tests are confirmed to FAIL (Red phase)
第三条：测试优先原则
这是不可协商的：所有实现必须严格遵循测试驱动开发。
在编写以下内容之前，不得编写任何实现代码：
单元测试已编写
测试已通过用户验证和批准
测试已确认失败（红色阶段）
“不可协商”、“严格遵循测试驱动开发”、“确认测试失败”。
在项目开始的第一分钟，我就以“宪法”的形式，将软件工程的最佳实践，注入了AI的灵魂。
/specify — AI化身“顶级产品经理”
我向AI下达了第一个指令，用一长串自然、甚至有些口语化的中文描述了我的想法：
/specify 开发一个工具，专门用于分析小红书里用户的评论，挖掘某类ToC 用户的真实需求，并且通过爬虫技术和 AI 能力挖掘需求且验证需求，验证是否为商机，我希望的是找到具体为某个需求付费的客户，这个客户量是否足够大，需求是否真实和用户是否愿意掏出真金白银付费，且实际可落地的需求。
AI没有立刻开始写代码，而是扮演起了产品经理的角色：
- 自动创建了一个语义化的分支：
001-toc-ai。 - 生成了一份结构化的规约文档：
spec.md。
这份 spec.md 里，包含了用户故事、功能清单、非功能性需求、甚至还有AI自己提出的“待澄清项 [NEEDS CLARIFICATION]”。
它将我的发散想法，瞬间收敛成了一份专业的PRD文档。
这一步的价值，是驯服模糊性。
正如官方文档所说：“这改变了传统的软件开发生命周期——需求和设计变成了持续的活动，而不是离散的阶段。”
/plan — AI化身“首席架构师”
有了“做什么”的规约，接下来是“怎么做”。
我继续用自然语言下达指令，描述我的技术偏好：
/plan 我希望能够运行在浏览器里,网页作为前端页面,后端只需要在本地即
可,Python作为爬虫技术,openrouter作为AI模型的提供商,模型使用openai/gpt-5,最后输出的内容可以是.md为格式的报告内容,可以下载到本地,元数据存储在本地SQLite 数据库中。
AI再次启动，这次它的角色是“首席架构师”。它没有直接输出代码，而是生成了一整套的架构设计蓝图，包括：
plan.md：记录了技术选型、性能目标、约束条件。data-model.md：定义了数据实体和表结构。contracts/api-contract.yaml：一份标准的OpenAPI合约文件。
最关键的是，AI的这次设计，并非天马行空，而是严格遵守了我们之前立下的“宪法”。
在 plan.md 文件中，我看到了一个“合宪性检查”（Constitution Check）部分，AI会逐条自审其设计是否符合“KISS原则”、“TDD原则”等宪法条款。
这一步的价值在于，设计必须遵从宪法，确保了架构的规范性和一致性。
/tasks — AI化身“资深项目总监”
规约已定，蓝图已出。最后一步，生成可执行的路线图。
我只输入了一个简单的命令：
/tasks
AI迅速分析了所有前面生成的文档，然后输出了一份tasks.md文件。这份文件，是一个包含50个具体开发任务的甘特图！
它清晰地列出了：
任务分布：Setup, Contract Tests, Data Models, Core Services…
依赖关系：哪些任务必须按顺序执行。
并行机会：哪些任务可以并行处理以提高效率（用[P]标记）。
最让我惊叹的是任务的顺序：
排在最前面的，永远是“Contract Tests”（合约测试）。
这完美印证了宪法的内容：
“TDD 贯彻始终，永远是测试先行”。
AI不是在空喊口号，而是将测试驱动开发的理念，落实到了每一个具体的执行步骤中。
至此，从一个模糊的想法，到一个包含完整架构设计和50个开发任务的专业工程计划，总共耗时不到15分钟。
我的认知被刷新：它凭什么比一个开发团队更“靠谱”？
看到这里，你可能会问：这太神奇了，但它凭什么这么靠谱？它的核心魔法到底是什么？
在我看来，spec-kit的魔法不在于生成代码，而在于它通过两大支柱，为善于创造却疏于纪律的AI，注入了“软件工程的灵魂”。
魔法揭秘1：模板(Templates) — AI的“写作脚手架”
【引：我的感悟：“流程、清单、模板的价值，在上下文管理中，好用到超乎你地想象”。】
spec-kit的.specify/templates/目录下，存放着各种输出物的模板。这些模板就像一个精密的“写作脚手架”，通过内置的规则和清单，强力约束着AI的行为。
例如，模板会强制AI：
- 避免猜测：当信息不足时，必须使用[NEEDS CLARIFICATION]标记，而不是自己编造一个“合理”的假设。
- 保持抽象：在写spec.md时，只关注“What”和“Why”，严禁涉及“How”（技术实现）。
- 自我检查：模板内置的清单，就像“单元测试”，强迫AI在输出前检查自己是否遗漏了关键点。
魔法揭秘2：宪法(Constitution) — AI的“思想钢印”
如果说模板解决了“单次输出”的质量，那么constitution.md则解决了“长期演进”的纪律。
这部“宪法”是不可变的根本大法，它定义了项目的架构DNA。例如，除了TDD，它还规定了：
- Article I: Library-First Principle: 所有功能都必须先作为独立的库来实现，强制模块化。
- Article VII: Simplicity Gate: 严禁过度设计和未来证明（future-proofing）。
这些原则通过“思想钢印”的方式，确保了无论项目如何演进，无论未来由哪个版本的AI模型来维护，其架构风格和工程质量都能保持高度一致。
模板是AI的“行为准则”，宪法是AI的“价值信仰”。 两者结合，构成了一个强大的约束系统，让AI从一个自由散漫的“艺术家”，变成了一个纪律严明的“工程大师”。
快速上手：今天就为你的AI“立宪”
spec-kit 和它背后的SDD范式，远不止一个提效工具那么简单。它预示着一个新时代的到来：
开发者的核心价值，正在从“代码的生产者”，转变为高质量“规约”的设计者、AI架构的监督者、以及整个系统意图的定义者。
我们正在从一个给AI下达零碎指令的“老板”，变成一个与AI签订严谨契约的“合伙人”。
本期互动
你觉得SDD模式最先会在哪个领域/场景爆发？
是个人项目、创业公司，还是大厂的创新团队？
在评论区聊聊你的看法。
下期预告 · 敬请期待
（上篇）我们用15分钟规划了一个项目，（下篇）我们将亲手执行这50个任务，把“小红书商机挖掘器”真正跑起来，并把全部代码开源！
关注我们，见证实战全过程。
用AI重塑工作流，而不只是生成内容。