Spec-First AI编程工作流对比评测：2024最佳推荐
AI编程：从直接生成到结构化协作
过去半年，随着内部AI Coding项目的推进，Cursor、Codex、Claude Code这类AI编程工具在团队中的渗透率显著提升。大家都在不同程度地利用AI辅助编码。但一个现象值得关注：指令“直接写代码”与“先输出方案再生成代码”之间，最终交付的代码质量差异极大。
本文分享的是近期验证下来效率最高的协作流程。
1. 高频痛点：指令过简导致代码失控
多数开发者都踩过这个坑：接到一个需求，图省事，直接用一句话命令AI——“帮我实现 xxx”，然后AI“啪”地生成一大段代码。
乍看之下，代码结构完整。但深入检查，问题立马暴露：它可能顺手修改了与你目标无关的文件，自行脑补了未指定的边界逻辑，或者项目里已有的工具函数被它重新发明了一遍。最终你花在“审查代码、剥离冗余改动”上的时间，可能不比自己从零开始写少。
核心问题不在AI能力，而在于上下文缺失。当边界条件未讲透时，AI只能靠猜测补全——你未明确约束的部分，它就替你做主。
2. Spec-First工作流：先约定，再实现
2.1 核心定义
在动手编码前，先让AI输出一份可供人工审核的实现方案（spec），待人工确认后，再要求其严格依方案完成代码编写。
这个流程包含三个关键动作：
- 可审核：方案必须是用中文编写的逻辑说明，而非代码本身。团队成员都能看懂，支持协作。
- 人工确认：方案未经人工核准，AI不能进入编码阶段。这个节点能阻止在错误的假设上累积工程量。
- 依方案执行：第二轮的prompt需将确认过的spec回传，强制AI完全遵循既定的实现路径，约束其自由发挥空间。
2.2 五步操作流程
1. 喂上下文：提示词、产品需求说明、设计稿、AGENTS.md、相关代码/文档、...
2. 出方案：让 AI 输出 spec
3. Review 改方案：最重要的一步，人工主导，必须经人工确认后才能进入下一步
4. 按方案实现：让 AI 严格依据 spec 编码
5. 验收 review：AI review + 人工 review2.3 适用边界与限制
| 场景 | 是否适用 | 备注 |
|---|---|---|
| 新功能开发 | ✅ | 最佳场景 |
| 旧模块重构 | ✅ | spec 阶段需要先对齐边界 |
| 技术方案调研 | ✅ | spec 就是调研报告本身 |
| Bug 修复 | ⚠️ | 修复 bug 主要在于问题排查，改动往往是小范围的，效果有限 |
| 纯 Code Review | ❌ | 代码审查是为了提前发现问题，没有必要 |
3. 完整实战案例
Step 1 · 供给AI充足上下文
要求AI输出方案前，必须确保它“看”到足够的信息。典型需求的输入组合包括：
- 用户提示词（手动书写，需包含基本描述）
- 需求说明（截图或文本描述，注意脱敏）
- figma 设计稿（截图或 MCP 读取，推荐使用MCP）
- AGENTS.md（agent 自动读取）
Step 2 · 让AI输出方案而非代码
上下文就绪后，此轮目标只有一个：生成书面方案。 给AI的指令大致结构如下：
我要在菜单下，新增一个模块：
- 需求原型见上传的截图（需要手动上传）
- figma设计稿如下：
https://www.figma.com/xxx
请根据需求原型、figma设计稿和当前代码上下文输出详细实现的方案。
注意：
- 需求原型截图和figma设计稿中的顶部导航栏和侧边菜单栏是已有的，不需要实现
- 原型截图中的红色文案是业务逻辑相关描述，要重点关注
- 不清楚的地方需要和我进行确认，禁止随意推测可以将编程工具切换至 plan 模式（claude、codex、cursor 均支持此功能），以便AI结构化输出实现方案。
AI输出的方案示例：
Step 3 · 人工审查与修正方案
审查方案时，重点排查以下几个类别的问题：
- 需求理解偏差：AI复述的需求与你的真实意图不一致。这个阶段发现，纠错成本最低。
- 越界改动：AI计划修改与当前需求无关的文件。必须砍掉，确保最小改动范围。
- 复用顺序错：AI打算自建工具函数，而项目里已有现成的实现。
- 假设未说明：AI默默假设的边界条件，必须让它显式写出来或向你确认。
- 遗漏边缘场景：加载状态、空状态、权限校验、异常分支等容易被忽视的环节。
审查结束后，让AI重新生成修订版spec，反复确认。直到双方对spec达成共识，才能进入Step 4。
示例：
Step 4 · 要求AI严格按方案编码
第二轮指令示例：
请严格按照上面确认的方案实现。
- 不引入方案之外的改动
- 实现完成后，请按方案的"实现步骤"逐条说明你做了什么
- 如果实现过程中发现方案有问题，先停下来告诉我，不要自行调整部分AI工具提供了spec的build按钮，无需额外prompt。
AI生成的代码示例：
import React, { useCallback, useEffect, useState } from 'react';
import OverviewPanel from './components/overviewPanel';
import RecordTable from './components/recordTable';
// ...省略
const ApiMonitor: React.FC = () => {
const [overviewData, setOverviewData] = useState();
const [overviewLoading, setOverviewLoading] = useState(false);
// ...省略
return (
页面效果：
Step 5 · 对照Spec进行代码审查
可让AI先基于spec执行一轮审查，再进行人工审查。强烈建议落实本地AI审查+人工审查环节，这能大幅降低MR审查者的工作量。
对于MR审查，通常直接在gitlab页面上人工完成。可借助gitlab mcp获取MR信息，而后让AI出具详细的审查意见。本地AI审查与gitlab上的AI审查有明显区别：本地上下文更完整，能使用更强模型，审查效果通常优于gitlab端。经过AI审查后，仍需人工仔细过一遍。
补充说明：
- 使用gitlab mcp可能导致上下文过大，可改用内部自建的gitlab-MR-code-review skill替代。
- 也可使用Superpowers的code review功能。
5. 让Spec-First运转顺畅的“基础设施”
工作流能否顺畅落地，不取决于某次prompt的措辞精妙，而是底层基础设施是否持续发挥作用。
5.1 AGENTS.md：始终存在的“团队规范”
AGENTS.md 是仓库根目录下的Markdown文件，可被Cursor、Codex等工具识别，并在每次会话中自动加载。它解决一个核心问题：团队约定无需每次手动敲入prompt，AI默认就会遵循。
我们的AGENTS.md分为四层（按优先级从高到低）：
| 层级 | 关注点 | 例子 |
|---|---|---|
| 安全边界 | 哪些事不能做 | 不读 .env、不自动 git push、不主动 pnpm install |
| 仓库边界 | 改动作用域 | monorepo 多产品隔离、跨产品改动须确认 |
| 工程约束 | 技术栈 / 复用顺序 | React、复用顺序 公共包 → antd → 新增 |
| 行为约定 | 沟通 / 验证 | 默认中文沟通、交付前必须跑 lint + check-types |
以下是真实摘录，体现“硬规则”的写法：
### 3.3 安全边界
- 不自动提交代码、不自动推送分支、不改写 git 历史；
commit / push / reset / rebase / git add . 等写类操作
仅在用户显式要求时执行。
- 不读取 .env*、应用运行期配置以及密钥/凭证类文件；
不修改 node_modules/、构建产物、工具缓存目录。
- 不主动执行 curl / wget / ssh / scp 以及带 deploy /
release / publish 关键字的命令。
- 非必要不新增依赖、不执行 pnpm install / add / update。
- 不主动启动 pnpm dev / pnpm start 等长驻服务。5.2 MCP：Spec的输入触发器
MCP让AI像调用工具一样直接读取外部系统。它之所以关键，原因如下：
过去给AI喂上下文依赖“人肉中转”——自己查看Figma，整理成文字再粘贴给AI。这一步骤即耗费大量时间。MCP去掉了这层中转，让AI直接拿到你能获取到的东西。
MCP的本质是让AI直接访问你看到的信息。Spec-first工作流得以顺畅推进，很大程度上依赖MCP将“上下文喂入”的人力成本降了下来。
6. 尚未解决的挑战
坦诚地说，这套工作流仍存在一些待解决的问题，值得共同探讨：
6.1 如何量化效率提升？
目前判断“AI提升了多少效率”基本依赖感觉。为了让效率可衡量，近期开发了一个 ai-coding-stats skill，基于git-ai在commit上记录的元数据，可统计出AI代码有效采纳率、AI代码提交留存率、AI代码占比等指标。
个人维度已能跑通。团队维度（跨仓库聚合、可视化看板）仍在开发中。
6.2 Spec-Driven Development的正式形态
目前这套实践本质上是“轻量版Spec-Driven Development（SDD）”。SDD作为一套更系统的方法论，对spec的形态、版本管理、自动化测试生成做了更完整的设计。这块仍在学习和探索中，欢迎共同讨论。
6.3 跨岗位延伸
这套工作流不仅前端可用，不同岗位的切入角度可能不同：
- 后端：spec阶段是否天然适合产出接口设计？
- 测试：能否将spec直接作为测试用例的输入？
- 产品：spec能否用于为PRD查漏补缺？需求文档的颗粒度是否需要为“AI友好”进行调整？
- 运维：基础设施变更能否也跑spec-first流程？
7. 核心总结
整篇文章的三个重点：
- 让 AI 先写方案，再让它按方案写代码，review 环节要认真对待
- 用 AGENTS.md 把团队规范沉淀成 AI 默认能看到的上下文
- 用 MCP 让 AI 拿到你想拿到的东西
最后一句话：
AI Coding 不是“AI 替我们写代码”，而是“我们用一种新的方式表达意图，由 AI 把意图翻译成代码”。
意图表达得越清楚，AI 的产出就越接近你想要的。 Spec-first 就是让意图表达清晰化的一个具体实践。