AI 编程新范式：Spec Kit 的规格驱动开发到底在解决什么

Thu, 18 Jun 2026 22:10:00 +0800

AI 写代码的真相：看着对，其实不对

你用 Cursor、Copilot 或者 Claude Code 写过代码吧？体验大概是这样的：你描述一个需求，AI 刷刷刷给你吐出一大段代码，编译能过，单测也能跑，但你一集成就炸了。

问题出在哪？不是 AI 不会写代码，而是它不知道你到底要什么。你给它的是一句模糊的 Prompt，它给你的是一堆看起来合理的实现。这中间的偏差，就是所谓的"AI 幻觉"——它不是瞎编，它是自信地偏离了你的意图。

更隐蔽的问题是，AI 生成的代码往往"结构正确但语义偏离"。你让它写一个用户认证模块，它给你一个标准的 JWT 实现——但你的项目需要的是 OAuth2 + 多租户隔离。代码没毛病，但根本用不了。你还得花时间理解它的实现、拆解它的逻辑、替换掉不符合需求的部分。这个修改的成本，有时候比自己写还高。

这才是当前 AI 编程最大的痛点：Prompt 是模糊的，代码是具体的，中间缺了一层确定性的桥梁。 你不能用一段自然语言去精确约束一个工程系统的行为——这本身就是错位的。

Spec Kit 就是来填这个坑的。

Spec Kit 是什么

一句话概括：规格即源头，代码即实现。

Spec Kit 是一个开源的开发工具框架，它的核心理念是把软件开发从"你问我答"的 Prompt 模式，转变为"先定规格，再写代码"的规格驱动模式。具体来说：

你先定义不可协商的规范（Specification）
AI 根据规范拆解成可测试的微小任务
每个任务严格执行 TDD 流程：先写失败的测试 → 再写让它通过的代码
最终交付的代码 100% 被测试覆盖，且 100% 符合你的规格

这相当于给 AI 套了一个"紧箍咒"——它可以自由发挥实现细节，但必须通过你定义的测试用例。幻觉？不存在的，测试不过就是不过。

七条核心指令

Spec Kit 的工作流由 7 条指令串联，按顺序执行就能完成从需求到代码的全流程：

1. `spec init` — 初始化项目

在项目根目录运行，创建项目骨架并配置你使用的 AI 编辑器（Claude Code、Cursor、Copilot 等）。选对脚本类型（Mac 用 zsh/bash，Windows 用 PowerShell）。

2. `spec constitution` — 建立宪法

定义项目的"铁律"：技术栈约束、架构风格、不可违反的原则。比如：

1

spec constitution "保持 FastAPI 后端风格，强制执行 OpenAI 协议兼容性，所有接口必须包含请求频率限制，支持多租户 Key 管理，坚持 TDD 开发模式。"

这条宪法会贯穿后续所有阶段。写得越严厉，AI 越不容易跑偏。加一句"严禁脑补未定义的接口"会非常有用。

3. `spec specify` — 定义规格

描述"做什么"和"为什么"，不涉及具体实现。AI 可能会在这个阶段反问你 3-5 个澄清问题（比如异常怎么处理、并发上限是多少），直接回答就行。

1

spec specify "构建一个 AI 中台，能够转发 API 请求。核心功能包括：/v1/chat/completions 接口封装、API Key 校验、Web 管理界面显示实时调用量。"

4. `spec blueprint` — 制定蓝图

确定架构设计、数据模型和技术实现路径。这里输入具体的框架选型（FastAPI、SQLAlchemy、React 等），AI 会据此生成技术方案。

5. `spec task` — 拆解任务

将蓝图自动拆分为几十个微小的、可测试的任务清单，生成 tasks.md 文件。每个任务严格按照 TDD 顺序排列：先测试失败 → 实现代码 → 测试通过。

6. `spec analyze` — 一致性检查

系统自我审计，检查规格、蓝图和任务之间有没有冲突。如果有 Warning，直接让 AI 自动修复：

1

spec analyze -> 发现问题 -> "请根据分析建议自动更新相关规范文件"

7. `spec implement` — 自动化实现

启动全自动编写模式。AI 读取前面所有上下文，逐条完成任务清单。跑之前建议先 spec clear 清空冗余上下文，节省 Token 也提高准确率。

完整工作流：想清楚 → 定方案 → 拆细活 → 看表演

把七条指令串起来，开发节奏是这样的：

1
2
3
4
5
6
7


想清楚：constitution + specify
 ↓
定方案：blueprint
 ↓
拆细活：task + analyze
 ↓
看表演：implement

关键洞察：前面的阶段你投入越多，后面的实现越省心。 constitution 写得好，AI 不会乱加功能；specify 澄清得彻底，AI 不会猜错意图；analyze 跑一遍，任务之间不会互相打架。

整个过程的核心机制是 TDD 的 Fail → Pass 循环。Spec Kit 不是让 AI 先写代码再补测试，而是强制先写测试、确认失败、再写实现、确认通过。这意味着每一行交付的代码都有对应的测试证明它是对的。

另一个容易被忽略的要点是上下文管理。spec clear 这条命令看似简单，实际上是保证 implement 阶段质量的关键。规范文档生成后，你和 AI 之间的讨论历史就变成了噪音。清空这些冗余上下文，AI 在实现阶段才能专注于规格和任务清单，而不是被之前的对话干扰。Token 消耗降低的同时，准确率反而提高了。

Prompt Engineering vs 规格驱动

维度	Prompt Engineering	Spec Kit 规格驱动
输入形式	自然语言描述	结构化规格文档
确定性	低，每次生成可能不同	高，规格锁定后行为一致
质量保障	靠人肉 Review	靠自动化测试
幻觉控制	靠 Prompt 技巧	靠 TDD 强制约束
可复现性	差，换个模型结果就变	好，规格不变结果就不变
适用场景	快速原型、脚本编写	正式项目、生产级代码
学习曲线	低	中等，需要理解工作流
Token 消耗	单次少，但反复修改总量大	前期多，后期几乎零返工

说白了，Prompt Engineering 像是口头交代，规格驱动像是写需求文档+验收标准。哪个更靠谱，做过项目的人都懂。

什么时候用，什么时候不用

适合用 Spec Kit 的场景：

你要构建一个有完整功能的模块或系统（API 服务、Web 应用、数据处理管道）
代码需要上生产环境，不能容忍"差不多就行"
你对技术栈有明确偏好，需要 AI 严格遵守架构约束
多人协作项目，需要统一开发规范
你想让 AI 完成 80% 以上的实现工作，自己只做 Review

不需要 Spec Kit 的场景：

写个一次性脚本或工具（直接 Prompt 更快）
快速验证一个想法的原型（规格化反而拖慢速度）
纯探索性编程，你自己也不确定要什么
简单的 Bug 修复或代码重构（杀鸡不用牛刀）

一个判断标准：如果你愿意花时间把需求想清楚并写下来，就用 Spec Kit；如果你只是想让 AI 帮你快速出个初稿，直接 Prompt 就好。

AI 辅助开发的下一步

当前的 AI 编程工具基本都停留在"更好的自动补全"层面。Cursor 很强，但它本质还是一个更聪明的编辑器；Copilot 很快，但它不理解你的项目上下文。

Spec Kit 代表的方向是：把 AI 从"代码生成器"变成"规格执行器"。 你负责定义 What 和 Why，AI 负责实现 How，而 TDD 是连接两者的契约。

这不是要取代程序员的判断力，而是把判断力前置到规格定义阶段。写规格的能力，本身就是架构能力的体现。未来真正值钱的开发者，不是写代码最快的那个人，而是能把需求拆解成精确规格的那个人。

从工程实践的角度看，这种模式还有一个好处：它让 AI 的输出变得可审计。传统的 Prompt 方式，你拿到一段代码，不知道为什么 AI 这么写，也无法追溯决策过程。而在规格驱动的模式下，每一步都有文档支撑——宪法解释了为什么选这个技术栈，规格解释了为什么做这个功能，蓝图解释了为什么这样设计架构，任务清单解释了为什么代码按这个顺序实现。出了问题，你能一路回溯到源头。

工具层面，我们可以期待的是：Spec Kit 这类框架会和 IDE 更深地集成，规格文档可能直接变成项目的一等公民，TDD 循环可能完全自动化到开发者只需要 Review 最终结果。甚至可能出现"规格即测试"的统一范式——你写的每一条规格，自动转化为可执行的验收测试。

但核心逻辑不会变：先想清楚，再让机器干活。这个顺序，永远不会错。 不管 AI 多强大，它始终需要一个精确的输入。给它精确输入的能力，就是程序员在新范式下最核心的竞争力。

TDD on 文艺技术笔记

AI 编程新范式：Spec Kit 的规格驱动开发到底在解决什么

AI 写代码的真相：看着对，其实不对

Spec Kit 是什么

七条核心指令

1. spec init — 初始化项目

2. spec constitution — 建立宪法

3. spec specify — 定义规格

4. spec blueprint — 制定蓝图

5. spec task — 拆解任务

6. spec analyze — 一致性检查

7. spec implement — 自动化实现