夜雨聆风“ 前几篇我们讲解了AICoding的全景图、AiCoding新范式下我们和AI协作写代码要做的转型、VibeCoding、Context Engineering。接下来几篇我会系统的讲解SpecCoding，。全篇2千余字，大概需要8分钟（若来不及看可先收藏，已把全文总结置顶！）”
全文速览
先想清楚，再让 AI 执行是 Spec Coding 的核心原则，区别于 Vibe Coding 的"边做边改"。它通过三层文档体系（需求层 spec.md、设计层 plan.md、任务层 tasks.md）确保 AI 在明确规格下开发，适合复杂功能、多人协作、长期维护类项目。
流程上采用六步法：收集需求→生成 spec→评审 spec→生成 plan→拆解任务→逐任务实现并即时 Review。任务颗粒度控制在 1 - 4 小时，确保可执行性和低偏差。Spec Coding 本质是"人类先完成系统设计，再让 AI 落地"，与 TDD 精神一致，文档是思考的产物，也是约束 AI 的边界。业界如 GitHub Kiro 和 BMAD 方法也验证了该范式的可靠性。
让 AI 在规格驱动下稳定交付：先想清楚，再让 AI 执行。这句话说起来简单，做到需要一套方法论。接下来我们详细介绍！
一、Spec Coding vs Vibe Coding：不是对立，是选择？
很多人在了解 Vibe Coding 之后，会问：那 Spec Coding 是不是更"正确"的方式？
答案是：不是更正确，是适合不同场景。
维度 | Vibe Coding | Spec Coding |
|---|---|---|
适用场景 | 原型、探索、个人工具 | 复杂功能、多人协作、长期维护 |
前期投入 | 低 | 中等 |
输出一致性 | 低 | 高 |
可并行化 | 难 | 容易 |
需要的技能 | 快速迭代能力 | 系统设计 + 文档写作 |
典型时间单位 | 小时 | 天/周 |
判断标准：
如果这个任务"做错了代价很高"，或者"需要多人协作"，或者"要长期维护"——用 Spec Coding；如果只是"快速验证一个想法"——用 Vibe Coding。
二、Spec 的三层架构
Spec Coding 的核心是在让 AI 写代码之前，先建立三层文档体系：
第一层：需求层（What)-spec.md
回答"我们要做什么"。
内容：
功能描述（用户故事或功能列表）
验收标准（什么情况下算做好了）
范围边界（明确不做什么）
关键约束（性能、安全、兼容性要求）
格式示例：
# spec.md - 用户认证模块## 功能目标为平台添加用户认证功能，支持邮箱注册/登录和第三方 OAuth。## 用户故事- 作为新用户，我可以用邮箱+密码注册账号- 作为已注册用户，我可以用邮箱+密码登录- 作为用户，我可以重置忘记的密码## 验收标准- 密码必须至少 8 位，包含大小写字母和数字- 登录失败 5 次后，账号锁定 15 分钟## 明确不做- 短信验证码登录（后续迭代）- 企业 SSO（后续迭代）
第二层：设计层（How)-plan.md
回答"我们怎么实现"。
内容：
技术方案选择（以及为什么这样选）
系统架构设计（模块划分、数据流）
数据模型定义
API接口设计
关键算法和逻辑
技术风险和应对策略
格式示例：
# plan.md - 用户认证模块技术方案## 技术选型- 认证库：NextAuth.js v5（原生支持 Next.js App Router，社区活跃）- 密码哈希：bcrypt- Session：JWT + Redis 存储（支持主动失效）## 数据模型```sqlCREATE TABLE users (id UUID PRIMARY KEY DEFAULT gen_random_uuid(),email VARCHAR(255) UNIQUE NOT NULL,password_hash VARCHAR(255),created_time TIMESTAMP DEFAULT NOW(),login_attempts INT DEFAULT 0,locked_until TIMESTAMP);
## API设计- POST /api/auth/register - 邮箱注册- POST /api/auth/login - 邮箱登录- GET /api/auth/google - 发起 Google OAuth- POST /api/auth/reset-password - 重置密码## 风险点- Google OAuth 需要在生产环境配置回调 URL，本地开发需要单独配置
第三层：任务层 (Steps)-tasks.md
回答"按什么顺序实现，每一步的范围是什么"。
内容：
细化后的任务列表
每个任务的输入、输出、验收标准
任务间的依赖关系
任务完成状态标记
格式示例：
# tasks.md- 用户认证模块## 任务列表### Task 1：数据库 Schema 设计与 Prisma 配置- **输入**：plan.md 中的数据模型设计- 表结构符合设计- **状态**：[ ] 待开始### Task 2：邮箱注册 API- **依赖**：Task 1 完成- **输入**：spec.md 中的注册需求，plan.md 中的 API 设计- **输出**：POST /api/auth/register 接口- **验收**：能成功注册新用户，密码正确哈希，重复邮箱返回 409- **状态**：[ ] 待开始...（依此类推）
三、Spec的生命周期管理
并非所有 spec 都有相同的生命周期：
类型 | 位置 | 生命周期 |
|---|---|---|
任务级 spec | 临时文件或 issue | 任务完成后可存档 |
功能级 spec | 代码仓库 docs/ | 功能上线后作为文档保留 |
仓库级 spec（AGENTS.md） | 代码仓库根目录 | 持续维护，永不删除 |
与 TDD 的类比
Spec Coding 在精神上和 TDD（测试驱动开发）非常相似：
TDD | Spec Coding |
|---|---|
先写测试，再写实现 | 先写 spec，再让 AI 实现 |
测试定义了"什么是正确" | spec 定义了"什么是完成" |
Red-Green-Refactor 循环 | Write-Review-Implement-Verify 循环 |
测试是活文档 | spec 是活设计文档 |
就像 TDD 的价值不仅在于测试覆盖率，而在于"先想清楚再写代码"的思维方式，Spec Coding 的价值也不仅在于文档本身，而在于在 AI 开始执行之前，人类已经完成了系统级的思考。
四、参考
GitHub Kiro
Kiro 是 GitHub 推出的 AI 辅助开发工具，内置了 spec-first 的工作流——在开始 AI 编码之前，必须先生成和评审 spec 文档。这证明了"规格驱动"的方法论被业界主流工具所认可。
BMAD Method
BMAD（Business Model AI Development）是一套开源的 AI 辅助软件开发方法论，核心也是"先规格，后实现"。它提供了一套完整的文档模板和工作流，在 GitHub 上有大量实践案例。
OpenClaw
在 openclaw 建设的 Skill 体系中，也有专门针对 Spec Coding 工作流的支持——可以根据需求描述自动生成初版的 spec.md 和 tasks.md ，大幅降低了规格文档的编写成本。
五、写在最后
Spec Coding 的核心价值不是文档本身，而是它所代表的工作原则：在 AI 开始执行之前，人类已经完成了系统级的设计决策。
文档是这个过程的副产品，也是这个过程的约束机制——它强迫你在开始编码之前真正想清楚"要做什么"和"怎么做"。
对于任何需要稳定交付的项目，Spec Coding 是目前最可靠的 AI 辅助开发方法论。
本文是「AI Coding 研发新范式」系列的第5篇。本系列计划10余篇文章，系统的介绍VibeCoding、SpecCoding、OpenClaw多Agent协作的AICoding研发新范式！
AiCoding研发新范式02 | Vibe Coding感觉驱动编程
AICoding研发新范式03 | 从「写代码」到「指挥AI写代码」你需要做的转变
AICoding研发新范式04 | Context Engineering
下一篇预告：Spec Coding中间各角色提示词实战！
关于我:
我是老乔伊，互联网大厂十年技术管理，专注技术人职场跃迁，也在持续探索AI时代IT人职场转型之路！
关注我：
每周持续分享AI时代的技术转型（AICoding）、职场跃迁、绩效管理、后端|数据开发|数据科学专业技能进阶、面试指南等等适合IT人的实操干货！欢迎关注交流~