用 AI 批量生成几百行代码早已不是难事。代码可以一次性输出，注释齐全、可以正常运行。但一旦需要调整需求，麻烦才真正浮现。 代码是 AI 写的，背后的设计假设不在你的脑子里。你根本不敢动，一处简单的字段变更，会牵扯遍布整个项目的多层逻辑，生怕一动就全线崩溃。
AI 编码最大陷阱就在这里：它加速了代码产出，却没有带来可维护性。能跑 ≠ 能交付，更不等于能迭代。
问题并不是模型不够强。单一模型包揽需求定义、架构设计、编码实现、代码审查全链路，本身就不符合工程逻辑。
这篇文章，就来拆解 Spec Kit 这套规范驱动开发方案，以及我实战沉淀下来的模型分工策略：在开发的不同阶段，分配合适的模型，各司其职。
读完你将看到：
01 它到底解决什么问题，为什么单纯优化 prompt 救不了许愿式编程
02 7 个阶段如何分配模型选型与分工逻辑 ------ 这是全文重点
一、如果你也这样，缺的不是模型
我用 AI 写代码一年，撞过的墙基本就这三堵。你对上两条以上，后面的内容就能直接用。
| 你大概经历过 | 最后的结局 |
|---|---|
| 每个新会话都要重新解释一遍项目 | 你解释得不全，它就自己补全------补出来的部分，就是未来的坑 |
| 需求只在脑子里，没写下来 | 于是不存在「验收」，只剩下「看着还行」 |
| 你说「这里不对」，它说「你说得对」 | 改完是另一个也不对的样子，因为你没有一条依据能卡住它 |
这三件事看着是三个毛病，其实是一个：AI 编码的瓶颈，早就从「写代码」转移到了「说清楚要写什么，以及判断有没有写对」。
而这恰好都可以工程化------只要你别再指望一个模型全包。
二、Spec Kit：不教 AI 写得好，只规定它按什么顺序交什么
Spec Kit 是 GitHub 官方开源的规范驱动开发（Spec-Driven Development，SDD）工具包 ，MIT 协议，仓库：spec-kit
官方定位是「给 AI 编码代理结构化流程、可复用模板、可追溯产物」。
翻成大白话：它不管 AI 写得漂不漂亮，它规定 AI 按什么顺序、交出哪几个文件、每个文件必须包含什么。
方法论只有一句：先定义「做什么、为什么」，再决定「怎么做」。落到仓库里，就是一条产物链：
这条链换来三个「可」：
| 可追溯 | 每行代码都能回答「你在满足 spec.md 的哪一条」。答不上来的，就是该删的代码。 |
|---|---|
| 可验收 | 每条需求带验收标准，「做完了」从主观判断变成逐条打勾。 |
| 可换人 | 换模型、换同事、三个月后的你自己，都不用重新听一遍解释------读文件就行。 |
三、十分钟跑通
需要 Python 3.11+ 和 uv，两行命令：
bash
uv tool install specify-cli
specify init my-project --integration cursor-agent主链路六条命令，按顺序敲，一次只敲一条，看完产物再继续：
| 命令 | 干的事 |
|---|---|
| constitution | 建立项目原则，全项目只做一次 |
| specify | 产出 spec.md，只谈做什么、为什么 |
| plan | 产出 plan.md，技术栈、架构、权衡 |
| tasks | 拆成有依赖顺序、可独立验收的任务 |
| implement | 按任务执行，改代码 |
| converge | 对账：代码 vs spec/plan/tasks，追加漏项 |
另外三个是可选的质量门，只在需要时开：
clarify 规划之前逼 AI 提问，把模糊处问成明确结论。一次最多五个问题，可多轮。
checklist 生成「需求的单元测试」------不测代码，测你的需求写得够不够清楚。
analyze 只读审查三份文档的一致性，输出带严重等级的冲突清单，不改任何文件。
官方把后两个叫「quality gate」，很准确：它们不产出功能，只负责拦住错误往下流。而后面要讲的模型分工，绝大部分价值就发生在这些闸门上。
四、为什么必须「一个阶段一个模型」
这是本文的重点，也是最多人做错的地方。
大部分人的用法是：开一个 Cursor，选一个「最强模型」，从宪法一路干到实现。看着省事，但这相当于让同一个人当设计师、当施工队、还当监理。
下面五条，是我认为换模型真正的理由。它们跟「谁跑分高」基本无关。
4.1 每个阶段「错的类型」不一样
宪法错在「漏」，规范错在「假」，计划错在「偏」，任务错在「碎」，实现错在「断」，审查错在「同」。不同的病，得用不同的药。
| 阶段 | 最典型的错 | 真正需要的能力 |
|---|---|---|
| 宪法 | 漏项 | 覆盖广度 + 条款化表达 |
| 规范 | 把猜测写成事实 | 资料综合 + 敢标「待确认」 |
| 计划 | 方案单一、无权衡 | 发散生成 + 多方案比较 |
| 任务 | 粒度失控、依赖错乱 | 长时结构化输出 + 状态追踪 |
| 实现 | 上下文断裂、顺手重构 | 长时耐力 + 工具调用稳定 + 克制 |
| 审查 | 自我一致性偏差 | 独立的先验（换个模型） |
所以「哪个模型最强」是个伪问题。真问题是：在这个阶段，哪个模型最不容易犯这一类错。
4.2 起草和审查必须「换脑」
让一个模型审它自己刚写的东西，它多半不是在验证，而是在复述 ------它复用的是同一套假设，所以同一套错误它看不见。换个模型，等于换一套训练分布、换一个先验，这才叫交叉验证。这不是「多问一遍」，是「换个人问」。
还能再往前推一步：让两个不同语料来源的模型并行读同一份材料，各自独立出结论。**重合的部分可以直接信，分歧的部分就是你必须人工确认的地方。**这就是工程上的双人独立复核，比任何单一模型的自信都可靠。
4.3 上下文窗口 ≠ 有效注意力
「能塞进去」和「能用上」是两回事。一百页规范塞进去，模型往往只记住开头和结尾。大资料综合是一项专门能力，得交给擅长检索归纳的模型，而不是靠堆窗口硬扛。
4.4 语言和资料分布，是两个世界
中文会议纪要、行业规范、老系统的中文注释，和英文架构文档、开源协议、厂商手册，属于不同的语料世界。让中文语料强的模型读中文现场资料，不是它更聪明，是它真的读过那些东西。
4.5 成本必须分层，否则你一定用不下去
整条链上 token 消耗并不均匀：写规范时读得多、写得少；实现时读得多、写得也多。全程上最贵的模型，成本会劝退你，然后你就再也不用它了------一个用不起的流程，等于没有流程。
五、七个阶段，各派谁上场
为了让「约束」看得见，下面用一个高约束场景举例：工业控制系统（SCADA）。选它是因为错误代价最直观------漏一条联锁，可能就是一次事故。
普通业务项目当然不用这么重。但分工逻辑完全一样，按比例削减即可：把「安全」换成「支付」「权限」「数据合规」，把「现场工程师」换成「产品经理」。
**如果你只想抄作业：**每个阶段给模型的话其实只有三句------你是谁、必须包含什么、绝对不许做什么。下面每张卡的「为什么」，就是在解释这三句该怎么定。
01 立宪 · constitution
| 起草 | Grok 4.7 |
|---|---|
| 审查 | Claude Opus 5.5 |
| 交叉检查 | Gemini 3.1 Pro ／ Kimi K3 |
| 签字 | 现场工程师 · 工艺负责人 · 安全负责人 |
为什么这么配：Grok 4.7 擅长长时知识工作，能把散落在会议、规范、口头约定里的约束组织成条款；Opus 5.5 的强项是长约束保持------给它四十条宪法，它能逐条对照不跑偏，这正是守门人需要的；Gemini 和 Kimi 语料来源不同，交叉检查能补「行业惯例漏项」，这是单一模型最容易缺的。
一条硬规则：宪法条款必须可判定。「代码要优雅」不可判定，AI 没法执行；「所有对外接口必须有超时与重试」可判定。写不出判定方法的条款，删掉。
02 规范 · specify ＋ clarify
| 并行读料 | Gemini 3.1 Pro ＋ Kimi K3 |
|---|---|
| 出初稿 | Grok 4.7 |
| 挑错 | Claude Opus 5.5 |
| 提问 | 最不了解你现场的那个模型（见下） |
为什么：规范阶段最大的病不是写得少，是写得太具体。AI 天生想帮你定方案，一不留神 spec 里就出现「用 Modbus TCP」------技术方案提前锁死，plan 阶段的自由度就没了，后面全是在给一个草率的决定做辩护。
**反直觉的一条：**clarify 阶段，故意用「最不了解你现场」的模型来提问。越懂的越问不出盲点------你早就默认那不重要了。
03 计划 · plan
| 候选架构 | Gemini 3.1 Pro |
|---|---|
| 现场支撑 | Kimi K3 |
| 整合 | Grok 4.7 |
| 独立审查 | GPT-5.6 Sol ／ Claude Opus 5.5 |
为什么：架构错是「方向性错误」，代价最高、暴露最晚。所以这里要的不是一个答案，是两三套互斥的候选加一张取舍表------发散交给跨厂商知识面最广的 Gemini，落地约束交给最懂中文现场资料的 Kimi，收口交给能长时间保持结构的 Grok。
**这一条最关键：**强制「每项技术决策都必须说明满足 spec.md 的哪一条」。这是防止 AI 自由发挥最有效的一句约束------答不上来的决策，就是它在替你做产品决定。
04 任务 · tasks ＋ checklist
| 拆分追踪 | Grok 4.7 |
|---|---|
| 依赖风险 | GPT-5.6 Sol |
| 大库梳理 | GLM-5.3 |
| 检查表 | 交给「审查者角色」的模型来生成 |
为什么：任务粒度直接决定 implement 的成败。Grok 4.7 的优势是长时任务里的状态维持------写到第四十个任务还记得前面改过哪些文件；GPT-5.6 Sol 擅长长链约束推理，适合算依赖、标风险、把验收条件写成可执行的判断；GLM-5.3 对中文注释密集的老库更熟，梳理遗留系统很省心。
**经验值：**单个任务控制在改 1--3 个文件、能独立跑通、能独立回滚。一次生成超过 20 个无法单独验收的任务，基本等于没拆。
05 审查 · analyze
| 主审 | Claude Opus 5.5 |
|---|---|
| 资料一致性 | Gemini 3.1 Pro |
| 代码与依赖 | GLM-5.3 |
| 汇总与验证 | Grok 4.7 |
为什么：只读审查必须由没参与生成的模型来做，而且必须分领域------一个模型全审，注意力会被稀释，最后只交给你一句「整体看起来没问题」。分开之后，Opus 判严重等级、Gemini 追资料出处、GLM 查代码与依赖，Grok 负责汇总冲突并验证修复方案是否真的可行。
06 实现 · implement
| 默认 | Grok 4.7 · High |
|---|---|
| 复杂场景 | Grok 4.7 · xHigh（跨文件改造、故障恢复、架构调整） |
| 抢时间 | Grok 4.7 · Fast |
| 快速执行层 | Flash ／ Terra ／ Luna ／ Composer |
为什么：实现阶段最稀缺的不是智力，是耐力加克制。长时编码能力决定它能不能一口气做完三十个任务而不精神分裂；克制决定它会不会「顺手帮你重构」------而顺手重构，是 review 失效的头号原因。
一个很实用的做法：把任务分成两类。
机械任务------样板代码、格式化、批量重命名、补单测、加日志埋点。交给 Flash／Terra／Luna／Composer 这类快速层，一次省掉大半等待。
判断任务------状态机、并发、错误路径、跨模块契约。留给 Grok 4.7 的 High／xHigh，别省这个钱。
反直觉建议：implement 的档位不要一上来就拉满。拉满的副作用是模型更爱「表现」------多改几个文件、多引入一层抽象。diff 一大，人和 AI 都 review 不动了。
07 收敛 · converge 最容易被跳过
| 差异修复 | Grok 4.7 |
|---|---|
| 回查原始资料 | Gemini 3.1 Pro |
| 是否真满足需求 | Claude Opus 5.5 |
| 漏洞与安全逻辑 | GLM-5.3 |
以为「任务勾完了＝做完了」，converge 干的事恰恰是戳破这个幻觉------它对照三份文档检查代码，把**「打了勾但其实没实现」**的需求重新变成任务追加回来。这一步几乎每次都能抓出东西，性价比最高。
六、一张表收走
建议截图存手机，下个项目直接照着派活。
七、七个坑，我都踩过
1. 把 spec 写成 PRD 八股。用户故事写得工整漂亮，验收标准写成「体验流畅」。spec 的价值不在格式，在于每一条都能被判真假。
**2. 一次生成四十个任务。**看着很爽，implement 时全乱。超过 20 个就该要求它分批。
**3. 跳过 clarify。**省下的十分钟，会在 plan 阶段变成一整篇基于猜测的架构，再在 implement 阶段变成返工。
**4. 让 implement 顺手优化。**它一定会的。所以要提前在宪法里写死：未经任务授权的重构，视为缺陷。
**5. 不跑 converge 就宣布完成。**你的「完成」和代码的「完成」，可能差着三成。
**6. 全程一个模型自审。**它说「已仔细检查，未发现问题」时，你要知道那句话的信息量约等于零。
7. 宪法写成口号。「代码要优雅、要健壮」------不可判定，AI 只能装作用上了。改成「所有对外调用必须有超时」才叫宪法。
想验证这套分工有没有用？记三个数就行
① analyze 抓出的冲突条数（越多，说明前面越省事）
② converge 追加的任务数（应该逐轮下降）
③ 需求返工次数（跟没走流程的项目对比）
八、什么时候别用它
工具都有适用范围，它也不例外。下面四种情况，用它反而更慢：
| 一次性脚本 | 两百行以内、跑完就扔。写宪法的时间够你写完代码。 |
|---|---|
| 探索性原型 | 连你自己都不知道要什么时，先写代码去发现需求更快。 |
| 纯视觉调参 | 「这个间距再小两像素」------没有可写的需求，只有来回看。 |
| 线上救火 | 用它的 bug 修复流程（assess → fix → test），别开整套 SDD。 |