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 的场景：

• 你要构建一个有完整功能的模块或系统（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 多强大，它始终需要一个精确的输入。给它精确输入的能力，就是程序员在新范式下最核心的竞争力。