规范驱动开发（Spec-Driven Development）

把人的价值观、做事准则、质量标准编码进 AI 系统，让规范从"靠人自觉"变成"靠系统保证"，实现流程的零偏差执行。

本文核心命题：软件团队的质量滑坡，根因不是规范不够好，而是执行规范的人天然不可靠------人会累、会妥协、会遗忘、会看人下菜。AI 的真正不可替代性不在于智商比人高，而在于它对规范的忠诚度可以达到 100%。规范驱动开发（SSD）就是把团队的价值观和做事标准编码进 AI 的 system prompt 与工具约束，让规范从"靠人自律"变成"靠系统强制执行"------第 1 次和第 1000 次执行完全一致，凌晨 3 点和上午 10 点完全一致，新人和老员工完全一致。这不是一套新方法论，而是对现有流程的"硬化"：把写在 Wiki 里落灰的规范，变成跑在代码里的守门人。
结果
方案
问题
👤 人执行规范
😴 累了跳过
😤 情绪波动
🤝 看人下菜
🧠 遗忘规则
📋 团队规范

编码标准·质量红线·流程纪律
🤖 AI 规范执行器

永不疲倦·零情绪·不可贿赂·完美记忆
🔧 生成式

按规范生成产出物
✅ 检查式

按清单逐条审查
🛡️ 护栏式

约束操作边界
🔁 流程式

确保步骤顺序
📌 第1次=第1000次
📌 凌晨=上午一致
📌 新人=老员工一致
📌 规范永不腐烂

一、什么是规范驱动开发

1.1 定义

规范驱动开发（Spec-Driven Development，SSD） 是一种以 AI 为执行器的开发范式。核心操作是：将团队的编码规范、质量标准、工作流程、价值观等"软性知识"，编码为 AI 系统的 system prompt、工具约束、检查规则等"硬性约束"，让 AI 在开发流程的每个环节中，无条件、零偏差地执行这些规范。

它不是一套新的敏捷或瀑布流程，而是对现有流程的一种"硬化"手段------把写在 Wiki 里落灰的规范，变成跑在代码里的强制执行器。

1.2 一句话概括

以前是你和同事说"提交信息要按规范写"------这是人在要求人，执行靠自律。

现在你把规范写进 AI 的 system prompt，AI 每次都按同样的模板、同样的标准输出------规范从"靠人自觉"变成了"靠系统保证"。

1.3 SSD 的三个关键词

关键词	含义
规范	不是"需求文档"，而是团队约定、编码标准、质量红线、流程纪律------那些"大家都知道但没人坚持做"的东西
驱动	规范不是参考，不是建议，是必须遵循的约束。AI 在执行时不会因为"嫌麻烦"而跳过
开发	贯穿开发全流程：编码 → 审查 → 提交 → 测试 → 文档 → 部署，每个环节都有 AI 按规范把关

二、为什么传统"规范先行"会失败

2.1 规范的生命周期------从制定到腐烂

每个团队都经历过这个循环：

复制代码

制定规范（全员讨论，热情高涨）
    ↓
文档落地（写了 20 页 Wiki，心满意足）
    ↓
开始执行（第一周大家都遵守）
    ↓
逐渐松懈（有人赶进度，跳过了一步）
    ↓
破窗效应（既然他跳过，那我也可以）
    ↓
规范腐烂（文档还在，但没人看了）

2.2 根因：人在执行链中的天然缺陷

规范写得再好，最终执行规范的是人------而人是最不稳定的执行器。

人的缺陷	对规范执行的破坏
精力衰减	加班到晚上 10 点，commit message 随便写一句 "fix"
情绪波动	今天和老婆吵架了，代码审查心不在焉，漏掉了明显 bug
社交压力	审查 Tech Lead 的 PR 时，不好意思太严格
认知偏差	自己写的代码怎么看都对，审查自己的代码时看不见问题
遗忘曲线	三周前定的新规范，写到一半就忘了，想起来时已经合入主干
工作量焦虑	手头还有 5 个任务，检查清单走一遍太慢了，这次跳过
习惯惯性	团队说要写单元测试，但老习惯不写，三个月过去覆盖率还是 0

这是结构性矛盾，不是态度问题。 不要责备人不遵守规范------规范执行本身就和人性的某些特质相悖。一个系统如果把一致性寄托在人的自律上，这个系统从一开始就注定不一致。

三、AI 如何补上这块短板

3.1 AI 真正的不可替代性：不是智商，是可靠性

AI 经常被拿来和人的"智力"比较------它能考多少分，能解多少道数学题。但这些不是它在规范执行上的核心优势。

它的核心优势在于：AI 不具备人性弱点。

人的弱点	AI 的对应优势	对规范执行的意义
会累，会偷懒	永不疲倦	第 1 次和第 1000 次执行完全一致
会被情绪左右	零情绪	不会因为心情不好而降低标准
会被关系影响	不可贿赂	对 CEO 和实习生一视同仁
会遗忘规则	完美记忆	所有规范一次性注入，永久生效
会嫌麻烦跳过步骤	任劳任怨	多复杂的检查清单都完整执行
会被权威压制	不畏权威	TL 的代码有安全问题，照报不误

3.2 AI 不创新，但它不妥协

AI 写出的代码可能不是最优雅的，可能没有天才架构师的灵感。但 AI 写出的代码一定不会违反你教给它的规范。

这就是规范驱动开发的核心价值主张：牺牲一点上限，换取底线的绝对可靠。

人类架构师 + AI 规范执行者 = 既能创新，又能保证质量基线。

3.3 SSD 解决的是"熵增"问题

任何团队随着时间的推移，代码质量、文档质量、流程纪律都会自然退化------这是软件工程的熵增定律。

SSD 的价值不在于让团队一开始就做到完美，而在于阻止退化：

第一个月 commit message 规范，第十二个月还是规范
第一个人提交 PR 要走检查清单，第 100 个人也要走
今天的安全红线不越过，一年后也不会越过

人维持标准需要消耗意志力。AI 维持标准不消耗任何东西。

四、SSD 的核心架构

4.1 四层模型

复制代码

┌──────────────────────────────────────┐
│  第四层：人在环审批                   │  ← 人做最终决策
│  (Human-in-the-Loop)                 │
├──────────────────────────────────────┤
│  第三层：工具约束                     │  ← AI 能做什么、不能做什么
│  (Tool Constraints)                  │
├──────────────────────────────────────┤
│  第二层：检查规则                     │  ← 什么是对、什么是错
│  (Validation Rules)                  │
├──────────────────────────────────────┤
│  第一层：规范定义                     │  ← 团队的价值观和标准
│  (Spec Definition)                   │
└──────────────────────────────────────┘

4.2 各层详解

第一层：规范定义

规范的来源，回答"我们相信什么"：

复制代码

来源：
├── 团队 CLAUDE.md / CONTRIBUTING.md
├── 编码规范（命名、结构、注释）
├── Git 规范（分支策略、提交格式）
├── 质量红线（覆盖率、lint 规则）
├── 安全策略（不能硬编码密钥、输入校验）
└── API 设计规范（RESTful 约定、错误码）

格式：人类可读，但需要结构化和无歧义。最好的规范文件是"人读得懂，机器也解析得了"。

第二层：检查规则

把规范转化为可执行的判断逻辑：

python 复制代码

# 规范："commit message 必须包含类型和作用域"
# 检查规则：
def validate_commit(message: str) -> bool:
    pattern = r"^(feat|fix|refactor|docs|chore)(\(.+\))?: .+"
    return bool(re.match(pattern, message))

AI 在这一层的作用是：将自然语言规范转化为结构化检查，同时对模糊地带做语义判断（如"这个变量名是否表达了意图"，正则做不了但 LLM 可以）。

第三层：工具约束

限制 AI 和人的操作边界：

复制代码

程序员不能做的事：
├── 不能直接推送到 main 分支
├── 不能绕过 PR 直接合入
└── 不能在代码中硬编码密钥

AI 不能做的事：
├── 不能修改核心安全模块
├── 不能在没有审批的情况下提交代码
├── 不能访问生产环境
└── 不能跳过检查清单

工具约束是最后一道防线------它不是建议，是物理上做不到。

第四层：人在环审批

人的角色从"执行者"转变为"决策者"：

以前（人在环内）	以后（人在环上）
人写 commit message	AI 生成，人确认
人写单元测试	AI 生成用例，人审查
人逐条走 CR checklist	AI 逐条检查，人审查 AI 的发现
人写 API 文档	AI 从代码生成文档，人校对
人排查 bug	AI 分析日志定位问题，人决定修复方案

人不做执行，人做决策。 这是 SSD 中人的新定位。

4.3 配置的三级优先级

规范有层级，不同层级的规范有不同的优先级。参考 Wingman 的设计：

复制代码

Level 1: 用户显式配置（settings.json）         ← 个人偏好，最高优先级
    ↓ 未配置时
Level 2: 项目规范文件（CLAUDE.md / .claude/）   ← 团队约定，次优先级
    ↓ 未配置时
Level 3: 内置默认规范（硬编码在工具中）           ← 行业基线，最低优先级

这个设计确保：团队规范是底线，个人可以在底线上加更严格的标准。

五、SSD 的实践模式

5.1 模式一：生成式规范执行

场景：AI 按照规范生成产出物，人确认。

示例 --- Git 提交信息生成：

markdown 复制代码

## Git 提交信息格式（规范）

- 标题：约定式提交（feat/fix/refactor/docs/chore），包含作用域
- 正文：简短要点列出关键变更
- 文件：列出本次修改的核心文件
- 全篇中文，300 字以内

AI 每次生成提交信息时，system prompt 注入这段规范 → AI 严格按模板输出 → 人确认或修改。规范从文档变成了强制执行。

5.2 模式二：检查式规范执行

场景：AI 按照规范检查已有产出物，报告不合规项。

示例 --- 代码审查：

markdown 复制代码

## 代码审查检查清单（规范）

1. 是否有硬编码的密钥或 token
2. 外部输入是否做了校验和转义
3. 错误处理是否完整（非 200 状态码都要处理）
4. 是否有潜在的 NPE / 空指针
5. 函数是否超过 50 行
6. 命名是否清晰表达了意图

AI 按清单逐条检查 PR diff → 输出每条的结果（PASS/FAIL + 说明）→ 人审查 AI 的发现并决定哪些需要修改。

与人工 CR 的区别：人可能因为累了跳过第 5 条和第 6 条，AI 永远不会。

5.3 模式三：护栏式规范执行

场景：AI 在实时操作中被约束在安全边界内。

示例 --- Agent 操作边界：

markdown 复制代码

## Agent 操作规范（护栏）

允许：
- 读取任何文件
- 修改 src/ 下的文件
- 运行 npm test、npm run build

禁止：
- 修改 .env、.git/config
- 执行 git push --force
- 访问 /etc/、~/ 下的文件
- 执行 rm -rf、DROP TABLE

护栏不是建议------Agent 被物理约束在这些边界内，越界的操作不会发生。

5.4 模式四：流程式规范执行

场景：AI 确保开发流程的每个步骤都按顺序走完。

示例 --- 发布流程：

markdown 复制代码

## 发布流程（规范）

1. 跑全量测试，全部通过 → 进入下一步
2. 更新 CHANGELOG，检查格式 → 进入下一步
3. 打 tag，格式 vX.Y.Z → 进入下一步
4. 构建生产包，无报错 → 进入下一步
5. 部署到预发布环境，冒烟测试通过 → 进入下一步
6. 部署到生产环境 → 完成

AI 在每个步骤检查产出物，不满足条件不进下一步。人做决策（"这个 bug 可以 hotfix 吗？"），AI 做守门（"第 3 步的 tag 格式不对，不能继续"）。

六、与传统方法论的对比

维度	传统规范	TDD	代码审查清单	SSD
规范载体	Wiki / Word 文档	测试用例	Excel / Markdown	System Prompt + 工具约束
执行者	人（自觉）	机器 + 人	人（逐条打勾）	AI（自动）
一致性	低（随时间衰退）	高（但只覆盖测试）	中（看审查者状态）	极高（永不衰减）
覆盖范围	全面但不执行	仅测试行为	窄（检查列表）	全面且自动执行
更新成本	低（改文档）	高（写测试）	低（改列表）	低（改 prompt）
执行成本	高（靠意志力）	中（写测试费时）	高（审查费精力）	极低（AI 自动跑）
防止退化	❌ 全靠自律	⚠️ 新需求可能没测试	❌ 紧急情况跳过	✅ 系统性保证

SSD 不是替代 TDD 或 CR，而是把它们纳入一个更完整的规范执行体系。 TDD 确保行为正确，SSD 确保过程和标准一致。

七、实战案例：Wingman gitCommit

7.1 问题

团队要求所有 commit message 遵循约定式提交格式：type(scope): description + 中文要点 + 关键文件列表。但实际执行情况：

同事故障排查到半夜，提交写 "fix"
新同事不熟悉规范，经常写错格式
TL 不愿意每次花精力纠正，久而久之规范名存实亡

7.2 SSD 方案

把规范编码进 AI 系统，让每次提交都经过同一个"规范的守门人"。

规范定义（第一层）：

json 复制代码

// settings.json
{
  "wingman.commitFormat": "## Git 提交信息格式\n\n- 标题：遵循约定式提交..."
}

检查规则（第二层）：AI 的 system prompt 中写死模板要求，不接受不符合格式的输出。

工具约束（第三层）：gitCommit 命令无法跳过 AI 生成步骤，必须经过弹窗确认。

人在环审批（第四层）：

复制代码

确认提交 → git add + git commit
修改后提交 → 输入框改完再提交
取消 → 不提交

7.3 效果

第 1 次提交和第 1000 次提交，格式完全一致
凌晨 3 点提交和上午 10 点提交，质量完全一致
新人第一天提交和老员工提交，格式完全一致
TL 不再需要当"提交格式警察"

规范的执行成本从"每次消耗意志力"降到了"一次性配置"。

八、落地路线图

第一阶段：个人级 SSD（1 周）

在个人工作流中引入规范驱动，验证可行性。

复制代码

□ 写一个 AI 驱动的 commit message 生成（或用 Wingman）
□ 把个人编码偏好写进 CLAUDE.md，让 AI Coding 助手每次遵循
□ 感受"规范被自动执行"的体验

第二阶段：团队级 SSD（1 个月）

把团队规范编码进共享的 AI 配置。

复制代码

□ 盘点团队现有的规范文档（编码规范、Git 规范、CR 清单、测试标准）
□ 将每条规范转化为可被 AI 理解和执行的格式
□ 写入项目 CLAUDE.md，全员共享
□ 在 CI/CD 中集成 AI 检查节点
□ 第一个月：AI 检查 + 人工复查（收集误报/漏报数据）
□ 第二个月：根据数据调优 prompt，逐步提升 AI 检查的置信度

第三阶段：组织级 SSD（1 季度）

规范驱动延伸到跨团队、跨项目。

复制代码

□ 建立组织级的规范库（安全、合规、API 设计、文档标准）
□ 每个新项目自动继承组织级 AI 规范
□ 跨项目的数据汇总：哪个规范被违反最多？哪个检查误报最高？
□ 逐步进入"规范即代码"（Spec as Code）的治理模式

九、前瞻：SSD 将把软件开发带向哪里

9.1 短期（1-2 年）：AI 成为"流程守门人"

每个 PR 自动经过 AI 审查，输出结构化的检查报告
commit message、CHANGELOG、API 文档由 AI 生成，人确认
CI/CD 中增加 AI 规范检查节点，不通过自动拦截

9.2 中期（2-5 年）：规范即代码，Agent 自主执行

组织的规范库成为真正的代码资产，和业务代码同等重要
AI Agent 在执行任务时自动加载相关规范，不必每次在 prompt 里重写
规范的迭代和优化成为团队日常工作（像维护测试用例一样维护规范）
出现"规范工程师"（Spec Engineer）这一新角色

9.3 长期（5-10 年）：AI 原生组织的诞生

公司的治理结构从"人管人"变成"规范管人 + AI 执行规范"
AI 不只是工具，而是组织流程的神经网络------规范是它的"突触权重"
新员工入职第一天，AI 助手就已经"学会了"公司所有规范，一路纠正和教导
组织的知识、经验、教训不再依赖资深员工的传帮带，而是直接编码进 AI 系统，永久保留

9.4 核心命题

人类文明的进步史，就是一部把规则从依赖个人意志转化为依赖系统约束的历史。

------从习惯法到成文法，从手工记账到复式记账，从口口相传到标准化流程。

SSD 是这条脉络在 AI 时代的自然延续：以前我们的规范靠人去解读和执行，现在可以靠 AI 去无条件遵守和施行。软件开发终于有了一种办法，让"对的事情"不再依赖"对的人"。

十、立即可以做的事

把你最烦的一条团队规范"硬化"掉。比如 commit message 格式，用 Wingman 或自己写一个 prompt，让 AI 生成、你确认。感受一下"规范自动执行"的体验。
把你的 CLAUDE.md 当宪法来写。不只是写"项目用了什么技术栈"，而是写"这个项目相信什么"------命名怎么定、error 怎么处理、依赖怎么引入。每次 AI 辅助编码时，这些信念都会被自动遵循。
选一个检查清单让 AI 来做。挑 CR checklist 里最机械、最容易漏的一条（比如"有没有硬编码密钥"），写入 system prompt，让 AI 每次审查时自动报告。对比一下人工审查的遗漏率。
三个月后回头看。统计一下：规范的遵守率从多少变成了多少？你当"规范警察"的时间减少了多少？团队的新人上手速度有没有变化？

规范驱动开发不是一套理论，它是一套现在就能开始做的事。从一条规范开始，从一个命令开始，把它硬化成 AI 的约束。你会发现：当规范不再靠人自觉，团队才真正有了底线。