中文

English

中文

English

Appearance

0 分钟阅读 0 字

Spec-Driven Development：写文档，让 AI 写代码 ​

2025 年开始，「Vibe Coding」这个词火遍了整个开发者社区。对着 AI 说一句「帮我做个XX」，代码就生成了。确实爽，但爽完之后，问题来了：

  • AI 猜的架构和你想要的不一样
  • 改了一处，它又动了不该动的地方
  • 不敢上线，因为不知道 AI 写的代码到底干了什么

Vibe Coding 的问题不是 AI 不行，是你没告诉 AI 边界在哪。

于是 2026 年，主流的工作流开始从 Vibe Coding 转向 Spec-Driven Development（SDD） ——先写 spec，再让 AI 写代码。

从 Vibe Coding 到 Spec Coding ​

Vibe Coding 和 SDD 的核心区别，一句话说清楚：

维度Vibe CodingSpec-Driven Development
流程描述 → 生成 → 测试 → 迭代写 spec → 审查 → 生成 → 验证
设计决策AI 替你决定了你在 spec 里写清楚
验收标准「看起来差不多」「验收条件全部通过」
可复用性聊天记录里翻spec 在 git 里，随时可重来

Vibe Coding 适合原型和一次性脚本。但只要是会上线、会维护、会交接的代码，没有 spec 就是在赌 AI 猜对了你的想法。

而 AI 最不擅长的就是读心术。

Spec-Driven Development 是什么 ​

SDD 就是把 spec 当作代码的唯一真实来源。开发流程变成：

你写 spec（.md 文件，放 git 里）
    ↓
AI 读 spec → 出计划 → 拆任务 → 写代码 → 验证
    ↓
你 review 结果 → 改 spec → 循环

spec 不是写论文，不用长篇大论。核心就三个问题：

1. 做什么 + 为什么 ​

一句话说清楚：给谁用、解决什么、做成什么样算完。

2. 关键约束（给 AI 看的） ​

技术栈、数据结构、性能要求、不能碰哪些代码。写得越清楚，AI 越不会跑偏。

3. 边界 ​

这一步最重要——明确哪些事 AI 必须停下来问你。比如加依赖、改表结构、动公共组件——这些决策必须你来做。

一个真实例子 ​

这是我一个功能最短的 spec：

markdown
# Spec: 用户导出 CSV

## 目标
后台用户列表加一个「导出 CSV」按钮，下载 name / email / created_at。

## 技术约束
- Vue 3 + Composition API
- 直接用已有的 /api/users 接口
- 不引入新依赖

## 边界
- 只导当前列表，不做筛选导出
- 不分页，一次性返回
- 不写测试

15 行，5 分钟写清楚。AI 读了这个 spec，一次就产出了我要的代码，不需要来回改。

2026 年的 SDD 工具生态 ​

几个主流的 SDD 工具，定位各有不同：

工具定位适合谁
Claude Code + spec skillAgent 读 spec 自主执行习惯终端、复杂项目
GitHub Spec Kit开源 CLI，四阶段工作流团队协作、规范流程
Cursor + .cursor/rulesIDE 集成，轻量级约束个人开发者、快速上手
AWS KiroVS Code 插件，三段式文档从 Vibe 过渡到 Spec 的团队

目前社区共识度最高的是 GitHub Spec Kit——开源、四阶段工作流（/specify → /plan → /tasks → 执行），而且能同时对接 Copilot、Claude Code、Gemini CLI。

我的实际工作流 ​

目前我用的是「Claude Code + 手写 spec」的组合：

功能需求来了
    ↓
1. 写 spec.md（10-15 分钟）
   - 目标 + 技术约束 + 边界
   - 放到项目 docs/specs/ 目录
    ↓
2. 丢给 AI（Claude Code / Cursor）
   - 让 AI 读 spec 并出计划
   - 快速审一眼计划，没问题就执行
    ↓
3. Review 结果
   - 对照 spec 验收
   - 有问题就改 spec，再让 AI 重做

这个流程的核心习惯是：你的手只碰文档，不碰代码。 发现 AI 做偏了，回去改 spec，而不是自己修代码。

什么时候该用 SDD，什么时候不该 ​

先说不该用的场景：

  • 一次性脚本 — 用完就删的，直接 Vibe Coding
  • 快速原型 — 还不知道要不要的东西，不值得写 spec
  • 纯探索 — 你都不知道自己要什么，spec 写不出来

但如果是会上线的功能、会维护半年以上的代码、需要交接给别人的项目——SDD 能省的时间远多于写 spec 花的时间。

GitHub 内部的实践数据：用了 Spec Kit 的团队，「推倒重来」的轮次减少了约一个数量级。AWS Kiro 的客户案例里，40 小时的功能在 spec 先行之后只要 8 小时 human time。

怎么上手 ​

三步就够了：

第一，下次有功能的时候，不要直接打开 IDE。 先建一个 spec.md，花 10 分钟把目标、约束、边界写清楚。

第二，让 AI 按 spec 做。 把 spec 丢给 Cursor 或 Claude Code，说「按这个来」。

第三，只改 spec，不动代码。 AI 做偏了，回去改 spec 再让它重做。这是形成习惯的关键。

用上三次之后你会发现，写 spec 不是在拖慢你，而是让你少走弯路。

总结 ​

2026 年，AI 编程已经到了一个拐点。工具不再是瓶颈，方法论才是。

从 Vibe Coding 到 Spec-Driven Development，本质上是把开发者的角色从「写代码的人」变成了「写 spec 的人」——你负责定方向和边界，AI 负责执行。

Vibe Coding:      你说 → AI 猜 → 你改 → 循环
Spec-Driven:      你写 → AI 读 → 做对 → 收工

SDD 不是让开发变慢，是让「做对」变得可预测。

学习路线图 ​

从入门到上手，按顺序来就行：

1. 理解概念（30 分钟） ​

把本文从头读一遍。Vibe Coding vs SDD 的对比、三块 spec 模板、什么时候不该用——这些是地基。

2. 上一门课程（2-3 小时） ​

首选 DeepLearning.AI + JetBrains 的免费短课，Paul Everitt 主讲，15 节视频，从 project constitution 到 feature spec 到自动化 skill，全部动手练：

备选：

3. 动手练（最重要） ​

下次有功能需求，直接上手：

  1. 在项目里建一个 spec.md
  2. 三块写清楚：目标 + 技术约束 + 边界
  3. 丢给 AI，说「按 spec 来」

可以配合开源工具降低门槛：

两个都是开源的，readme 看了就能上手。

4. 进阶阅读 ​

参考资源 ​

Last updated:

📚 相关文章
#AI#工作流

我的 AI 编码工作流——从 spec 到 commit 的完整闭环

把 SDD、OpenSpec、AI 工具、编码判断力串成一条线。从需求到代码，每一步做什么、为什么、怎么落地。

#AI#工程化

Spec Coding：AI 编程的正确打开方式

从 Vibe Coding 到 Spec Coding，为什么先写规范再让 AI 写代码才是正道

#工作流#AI

AI 辅助前端开发的正确姿势

<h1 id="ai-辅助前端开发的正确姿势" tabindex="-1">AI 辅助前端开发的正确姿势 <a class="header-anchor" href="#ai-辅助前端开发的正确姿势" aria-label="Permalink to &quot;AI 辅助前端开发的正确姿势&quot;">&ZeroWidthSpace;</a></h1> <p>这篇文章不讲 prompt 技巧，不列工具对比表格。分享的是我 2025–2026 年在真实项目中用 AI 辅助前端开发的<strong>工作流和判断标准</strong>。</p> <p>2026 年的 AI 编码工具有一个共同特征：<strong>它们已经够好了，但前提是你知道怎么用</strong>。这个&quot;怎么用&quot;不是指写 prompt 的技巧，而是指：什么时候该用、什么时候不该用、怎么验证输出、怎么在团队层面落地。</p> <hr> <h2 id="一个判断框架-什么任务交给-ai" tabindex="-1">一个判断框架：什么任务交给 AI <a class="header-anchor" href="#一个判断框架-什么任务交给-ai" aria-label="Permalink to &quot;一个判断框架：什么任务交给 AI&quot;">&ZeroWidthSpace;</a></h2> <p>我总结了一个简单的四象限判断，用来决定一个任务是否适合 AI：</p> <div class="language- vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang"></span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0" v-pre=""><code><span class="line"><span> 高复杂度</span></span> <span class="line"><span> │</span></span> <span class="line"><span> AI 辅助策划 │ AI 辅助实现</span></span> <span class="line"><span> (给方向) │ (写代码)</span></span> <span class="line"><span> │</span></span> <span class="line"><span> ──────────────┼──────────────→ 高确定性</span></span> <span class="line"><span> │</span></span> <span class="line"><span> 自己写 │ AI 自动化</span></span> <span class="line"><span> (不适合AI) │ (重复劳动)</span></span> <span class="line"><span> │</span></span> <span class="line"><span> 低复杂度</span></span></code></pre> </div><ul> <li><strong>高确定性 × 高复杂度</strong>（右上）：AI 最适合。比如&quot;写一个符合 OpenAPI 规范的接口 handler&quot;。规范清楚、预期明确，AI 能一次搞定。</li> <li><strong>低确定性 × 高复杂度</strong>（左上）：AI 适合做调研和方案生成，但需要你审校和决策。比如&quot;设计这个页面的组件结构&quot;。</li> <li><strong>高确定性 × 低复杂度</strong>（右下）：用自动化脚本，不必每次都调 AI。</li> <li><strong>低确定性 × 低复杂度</strong>（左下）：自己写更快。比如改个文案、调个颜色。</li> </ul> <p><strong>判断依据就一句话：AI 写的代码我能不能一眼判断对不对？</strong></p> <p>能 → 交给 AI。不能 → 先自己理清楚。</p> <hr> <h2 id="我的-ai-辅助工作流" tabindex="-1">我的 AI 辅助工作流 <a class="header-anchor" href="#我的-ai-辅助工作流" aria-label="Permalink to &quot;我的 AI 辅助工作流&quot;">&ZeroWidthSpace;</a></h2> <p>这套流程的核心逻辑是：<strong>用 AI 处理执行，用人脑处理决策</strong>。</p> <h3 id="step-1-建立上下文" tabindex="-1">Step 1：建立上下文 <a class="header-anchor" href="#step-1-建立上下文" aria-label="Permalink to &quot;Step 1：建立上下文&quot;">&ZeroWidthSpace;</a></h3> <p>这是最容易被跳过、但最重要的一步。</p> <p>AI 在没有上下文的情况下写的代码，看起来没错，但放进项目里就是不对劲——用的变量名不合约定、样式没走设计 token、import 路径风格不一致。</p> <p>做法：**项目根目录放一个 <code>CLAUDE.md</code>（Cursor 用户是 `.</p>

💬 评论区

Built with VitePress · 小周

© 2026 Xiaozhou