白追追1. 为什么SDD能治好AI编程的“脑补”顽疾
先讲个真实翻车现场。上个月我接手一个内部数据看板项目，需求文档写得明明白白：“按部门维度展示工单完成率，支持日期范围筛选”。我图省事，直接用一段长提示词把需求甩给Claude Code，让它自己“看着办”。
结果它确实办得挺快——三分钟交出一版带图表、带筛选、带导出Excel的页面。表面看很完美，可一打开代码我愣住了：它顺手帮我“补充”了权限系统、暗黑模式、国际化文案，甚至给数据接口设计了缓存策略。这些功能我一个字没提，需求方也没提，纯属AI脑补出来的“锦上添花”。
更要命的是，验收时需求方说：“我要的是工单完成率，不是处理时效；筛选范围是自然日不是工作日。”我在屏幕前沉默了——因为对话历史里那几十轮来回改稿，早就说不清当初到底定的什么口径。项目最后返工了三天，核心原因就一句话：口头和提示词层面的“说清楚”，根本经不起工程化审视。
事后复盘，我当时缺少的正是SDD那套“先规范、后编码”的做事框架。不用“大概意思”，而是把每个需求用结构化文件固定下来，让AI在任何一次对话、任何一次修改里都能回到同一份“契约”上，而不是靠它对聊天记录的模糊记忆自由发挥。这就是SDD——Specification-Driven Development，规范驱动开发——存在的理由。
围绕这套方法，现在社区里最热的两样东西是OpenSpec和SuperPowers。前者把规范变成项目里的实体文件，后者把AI的干活方式拆成一整套可复用技能，两个配合起来，基本就是让我前面那种翻车事故从源头消失。这篇文章我会把SDD的门道、OpenSpec怎么落地、SuperPowers怎么装怎么配，以及三者组合的完整实战流程，一次讲透。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. OpenSpec：让技术规范变成可评审、可追踪的文件资产
2.1 OpenSpec到底解决了什么问题
先给结论：OpenSpec是一个把“需求讨论”变成“文件变更”的开源工具链。它不是写文档的模板库，也不是项目管理软件，而是一套约束AI和人都按同一个格式工作的规范协议。
我理解OpenSpec的切入点在于：过去我们让AI改代码，输入的是“口语”，输出的是“代码”，中间的“理解”是不可见的。AI说它懂了，它真懂了吗？没人知道。OpenSpec强迫你在这两者之间插入一层机器可读、人也可审的规范文件——你说清楚要改什么、为什么改、怎么验收，AI读了这份规范之后才开始动代码。这层文件的存在的最大价值不是“写得好看”，而是把需求和实现之间的映射关系固化成可追踪的资产。
打个比方：以前和AI协作像和一个记性很差但手脚麻利的外包聊天，你交代完需求，他干完活就忘了，你追加一句“上次那个逻辑再调一下”，他一脸茫然。OpenSpec相当于给他配了个工单系统，每个需求都建了档、挂了号，不管过了多久，翻档案就能恢复全部上下文。
2.2 目录结构：一个提案就是一个独立文件夹
OpenSpec的目录结构非常简单直接，一套标准的OpenSpec项目长这样：
text复制openspec/
├── project.md
├── specs/
│ ├── epic-1/
│ │ ├── proposal.md
│ │ └── specs/
│ │ ├── feature-a.md
│ │ └── feature-b.md
│ └── epic-2/
│ ├── proposal.md
│ └── specs/
│ └── feature-c.md
└── archive/
project.md：项目级说明，记录全局约定，比如技术栈、架构约束、命名规范、测试要求。这部分是给所有AI辅助工具看的“基本法”。specs/：当前活跃的规范目录，每一个Epic对应一个子目录。- 每个Epic目录下有一个
proposal.md，解释这个Epic要解决什么问题、包含哪些需求条目。 - 每个Epic下可以拆多个
specs/*.md，分别描述单个Feature的详细规范。 archive/：已经完成的、不再活跃的Epic归档区，保证specs/里永远只有“正在进行中的事”。
我第一次建这种目录的时候觉得“就这？这么简单？”但实际用下来才意识到，简单是刻意的。OpenSpec要的不是厚重的需求文档，而是一个轻量、能持续更新、AI能快速读取的文件集合。
2.3 规范文件里到底写什么：一个Feature的完整模板
这是我从OpenSpec官方文档提炼后自己一直在用的精简模板，每个specs/*.md文件基本包含下面这些块：
markdown复制# Feature: 工单完成率统计
## 需求背景
运营团队需要按部门实时掌握工单处理效率，用于周会汇报和绩效考核。
## 需求描述
- 用户进入数据看板页面后，默认展示本月各部门工单完成率。
- 支持通过日期范围选择器筛选统计区间。
- 支持按部门进行多选过滤。
## 验收标准
- [ ] 接口返回字段包含 department_id、completion_rate、total_tickets、completed_tickets
- [ ] completion_rate 计算口径 = completed_tickets / total_tickets * 100
- [ ] 日期范围默认为本月1日至今日，可选范围为近12个月
- [ ] 部门多选为空时默认全选
## 影响范围
- 新增文件：src/api/dashboard.ts
- 修改文件：src/pag