Spec Coding：下一代 AI 编程方式，正在替代传统 Prompt 编程

AI Coding 正在进入 2.0 时代。

未来真正重要的，不再只是 Prompt，而是 Spec（Specification）。

这半年，很多人都在疯狂使用：

• Cursor
• Claude Code
• Gemini CLI
• Copilot
• OpenAI Codex Agent

很多开发者第一次感受到：

AI 已经不只是"代码补全"了。

它开始：

• 自动阅读项目
• 自动修改多个文件
• 自动修复 Bug
• 自动重构
• 自动生成模块

但与此同时，另一个问题也越来越明显：

AI 写代码，越来越容易"失控"。

比如：

• 改一个文件炸一片
• 命名风格混乱
• 不遵守项目规范
• 重复造轮子
• 架构越写越乱
• 一次改动影响整个项目

于是，一个新的概念开始火起来：

Spec Coding

也叫：

• Specification Driven Coding
• Spec Driven Development（SDD）
• 规格驱动编程

它正在成为 AI Coding 的下一阶段。

---

一、什么是 Spec Coding？

先说最核心的一句话：

Spec Coding = 先定义规则，再让 AI 写代码

传统 AI Coding：

帮我写一个登录接口

AI 可能直接开始输出代码。

但问题是：

它根本不知道：

• 你的项目结构
• 你的命名规范
• 你的异常规范
• 你的技术栈
• 你的架构原则

所以结果通常是：

能跑，但不一定能进项目。

---

而 Spec Coding 的思路完全不同。

它会先告诉 AI：

- 使用 Spring Boot 3
- Controller / Service / Repository 分层
- 所有接口统一返回 Result<T>
- 使用 JWT 鉴权
- 所有异常统一处理
- Repository 不允许写业务逻辑
- 所有金额必须使用 BigDecimal

然后再让 AI 开始编码。

这时候：

AI 不再是"自由发挥"。

而是在：

规则约束下进行编码。

这就是 Spec Coding。

---

二、为什么普通 AI Coding 经常翻车？

这是很多人正在遇到的问题。

尤其是 Cursor、Claude Code 用多了以后，会越来越明显。

---

1. AI 没有长期记忆

AI 很难真正理解：

整个项目的长期规则

比如：

你这一轮说：

统一返回 Result<T>

下一轮它可能就忘了。

于是：

有些接口：

return Result.success(data);

有些接口：

return data;

项目开始越来越乱。

---

2. AI 不知道你的架构原则

例如：

你项目要求：

禁止跨层调用

但是 AI 很可能：

Controller -> Repository

直接跳过 Service。

因为：

它只会"完成任务"
不会天然遵守架构

---

3. AI 会不断"局部最优"

AI 最大的问题之一：

只关注当前上下文

它为了快速完成当前任务：

可能：

• 复制已有代码
• 临时 patch
• 重复实现
• 增加隐藏耦合

短期看：

写得很快

长期看：

项目逐渐腐烂

这就是很多 AI Coding 项目后期：

越来越难维护的原因。

---

三、Spec Coding 的核心思想

Spec Coding 的本质：

把"项目规则"显式化

而不是藏在：

• 人脑里
• Wiki 里
• 老员工经验里

因为 AI 无法"猜规则"。

你必须：

把规则写出来

---

四、Spec Coding 的三层结构

这是整个体系最重要的部分。

---

第一层：Project Spec（项目级规范）

这是：

整个项目的全局规则

例如：

技术栈
目录结构
编码规范
日志规范
异常规范
数据库规范

典型内容：

# Backend Rules

- 使用 Spring Boot 3
- 使用 PostgreSQL
- 所有接口返回 Result<T>
- 所有异常统一处理
- Controller 不允许出现业务逻辑
- Service 不允许操作 HttpServletRequest
- Repository 仅负责数据访问

这一层：

决定 AI 的整体行为。

---

第二层：Feature Spec（模块级规范）

这一层：

针对某个模块。

例如：

• 支付模块
• 订单模块
• 权限模块
• 用户模块

比如支付模块：

# Payment Module Spec

- 所有金额使用 BigDecimal
- 所有回调必须验签
- 所有支付接口必须幂等
- 所有支付操作记录审计日志

这时候：

AI 就会知道：

支付 ≠ 普通 CRUD

---

第三层：Task Spec（任务级规范）

最后才是：

当前要做什么

例如：

实现退款接口

或者：

新增批量导出功能

这个时候：

AI 才真正开始写代码。

---

五、为什么 Cursor 和 Claude Code 开始流行 Spec？

因为：

AI Coding 已经进入：

Agent 模式

以前：

问一句 → 回一句

现在：

AI 会：

• 自动读项目
• 自动分析依赖
• 自动修改多个文件
• 自动执行任务

这意味着：

AI 的权限越来越大

所以：

规则必须越来越严格

否则：

AI 改一次：

可能：

整个项目都被污染

这也是为什么：

现在越来越多人开始写：

• .cursorrules
• CLAUDE.md
• spec.md
• project-rules.md

本质上：

都是在做：

Spec Coding

---

六、一个真实工作流

下面是一个典型的 Spec Coding 工作流。

---

第一步：定义全局规则

例如：

.cursorrules

# Project Rules

- 所有接口返回 Result<T>
- 禁止 Service 直接操作数据库连接
- 所有异常统一处理
- DTO 请求对象使用 Req 后缀
- DTO 返回对象使用 Resp 后缀
- 禁止 Mapper 写业务逻辑

---

第二步：定义模块规范

例如：

payment.spec.md

# Payment Module Spec

- 所有支付接口必须幂等
- 所有金额使用 BigDecimal
- 所有回调必须验签
- 所有支付操作记录审计日志

---

第三步：给 AI 下任务

请按照 payment.spec.md
实现退款接口

这时候：

AI 的输出质量会明显提升。

因为：

它不是：

"自由发挥"

而是：

"受规则约束"

---

七、Spec Coding 最大的价值

很多人以为：

Spec Coding 的作用是：

让 AI 更聪明

其实不是。

真正的作用是：

降低 AI 犯错概率

注意这句话非常重要。

---

Prompt 决定 AI 能写什么

但：

Spec 决定 AI 不会写错什么

这才是核心。

---

八、一个典型案例

例如：

你让 AI：

新增退款接口

传统 AI Coding：

可能：

• 改了 Controller
• 忘了改 DTO
• 忘了改异常处理
• 忘了加日志
• 忘了事务

结果：

项目直接编译失败

---

但如果你提前写好 Spec：

- 所有接口必须记录 traceId
- 所有支付操作必须开启事务
- 所有异常统一转换
- 所有金额使用 BigDecimal

AI 会明显稳定很多。

因为：

它已经知道：

哪些东西绝对不能漏

---

九、Spec Coding 最适合什么项目？

非常适合：

• 中大型项目
• 企业系统
• 微服务
• 长期维护项目
• 团队协作项目

因为：

项目越大：

规则越重要

---

不太适合：

• demo
• 一次性脚本
• 小实验
• 临时工具

因为：

Spec 本身也有维护成本。

---

十、如何写一个好的 Spec？

很多人最大的问题：

不是不会用 AI。

而是：

不会定义规则

一个好的 Spec：

必须：

• 明确
• 可执行
• 可验证
• 不模糊

---

推荐结构

# Goal

# Architecture

# Constraints

# Coding Rules

# Forbidden

# Examples