刚开始接触 AI 辅助编码那阵子我和大多数人一样把大模型当成一个“嘴替”把需求往对话框里一贴生成代码复制跑。结果就是50 行的需求描述换来的是一堆看似合理、一跑就崩的代码崩了之后再把报错贴回去来回拉扯七八轮才勉强跑通。真正让我下定决心换套思路的是 OpenSpec Superpowers 这套组合。准确说是从“聊天式生成”改成 SDDSpec-Driven Development规范驱动开发和 TDDTest-Driven Development测试驱动开发的工作流之后我的返工率才真正降了下来。这篇文章不打算讲太多虚的我会把整套工作流从理念到落地的完整过程拆开包括工具怎么装、规范怎么写、测试怎么生成、踩过哪些坑以及最关键的有 OpenSpec 和没有 OpenSpec差别到底在哪。1. 为什么我把编码工作流从“聊天生成”换成了“规范驱动”1.1 一段让我崩溃的真实经历之前我接过一个小项目要做一个给内部团队用的待办事项 API。需求并不复杂支持增删改查、按状态筛选、给每个任务打标签。当时我图省事让 AI 一口气把整个 Flask 项目“写出来”模型也确实给了完整代码有路由、有模型、甚至还有 JWT 鉴权。但一跑测试数据库连接配置错了依赖缺了三个最离谱的是它把“删除任务”的接口设计成了物理删除而产品那边要求的是软删除。问题不在于 AI 笨而在于我给的 prompt 里压根没写“软删除”“数据库用 SQLite 还是 Postgres”“鉴权方案是什么”。AI 只能靠上下文去猜猜错了整个实现方向就错了。这件事给我两个教训第一需求本身必须形成可被验证的规范而不是一句笼统的话第二代码质量不能靠“事后检查”必须在写之前就定义好“怎样算完成”。这两个需求恰好就是 SDD 和 TDD 想要解决的。1.2 SDD 和 TDD 各自的定位很多人把 SDD 和 TDD 当成两种互相替代的方法论其实二者根本不是一回事。TDD 是“测试先行”先把验收条件变成测试再写实现目的是让每一行代码都有测试兜底。SDD 更靠前一步它把“用户需求”先翻译成结构化的规格说明书Spec在里面写清楚业务规则、输入输出、边界情况然后才进入设计和编码。放在 AI 辅助开发的场景下SDD 尤其重要。因为大模型最大的问题不是不会写代码而是不会“憋着不写”——你给的信息越模糊它越会自由发挥。OpenSpec 就是用来把需求“锁死”成文档的工具Superpowers 则是给 AI 编码助手装上一套可复用的技能包让它在合适的阶段做合适的事比如先写测试再写实现。1.3 OpenSpec 和 Superpowers 的分工我用一个表格说清楚它们在我工作流里的角色工具解决的核心问题工作流中的角色OpenSpec需求怎么从“一句话”变成“可验收的规格”需求入口、变更管理、验收依据Superpowers怎么让 AI 按流程执行 SDD/TDD而不是自由发挥技能编排、流程控制、测试生成简单说OpenSpec 负责“定义正确的事”Superpowers 负责“正确地做事”。两者单独用都有效但合在一起才是一个完整的闭环先用 OpenSpec 确定需求边界再用 Superpowers 里的 TDD 技能让 AI 先生成测试然后实现代码最后回到 OpenSpec 做验收。2. 环境准备在 Codex CLI、Cursor、Trae 里装好 Superpowers并初始化 OpenSpec2.1 Superpowers 到底是什么如果你第一次听说 Superpowers可以把它理解成 AI 编码助手的“外挂技能库”。它不是一个单独的 IDE也不是编译器而是一组可以被 AI 读取的、结构化的技能描述文件。每个技能文件里都写着这个技能适用于什么场景、执行步骤是什么、有哪些注意事项。这样 AI 就从一个“什么都会一点但不知道先干哪步”的全能选手变成了一个“知道在 TDD 阶段必须先写测试、在 Debug 阶段必须按日志链路排查”的老手。我第一次在 Codex CLI 里装上 Superpowers 后明显感觉到它的行为习惯变了。以前你让它“写一个带测试的功能”它可能先写实现再补测试装完技能后它会主动先问你要验收条件然后生成一个失败的测试再开始写实现。这种“流程上的自觉”靠普通 prompt 是压不出来的。2.2 安装步骤不是死记命令而是理解三步不同宿主工具的安装方式略有差异但核心逻辑只有三步获取技能库、把技能目录告诉 AI 工具、重启会话让技能被加载。以我当时在 Codex CLI 里的做法为例我克隆了 Superpowers 仓库到本地固定目录然后在 Codex 的配置里把 skills 路径指过去。不同版本可能命令不一样但思路是一样的让 AI 在启动时能扫描到技能文件。如果你用 Cursor直接在项目根目录放一个.cursor/skills文件夹把 Superpowers 里的技能文件复制进去重开对话就能生效。Trae 也类似只是目录名变成了.trae/skills。安装完以后你可以先问 AI“你有哪些技能”如果它列出了 SDD、TDD、Debugging、Code Review 等说明加载成功。2.3 初始化 OpenSpec 项目OpenSpec 的初始化比装 Superpowers 更简单。我在项目根目录执行了初始化命令它会自动生成一个openspec/目录里面通常包含specs/和proposals/两个子目录。proposals/放的是“变更提案”也就是你新提出的需求specs/放的是已经接受并固化的规格。初始化完成后我会第一时间把openspec/目录提交到 Git 仓库。这一点非常重要因为 OpenSpec 的核心价值是把需求文档变成可追踪、可 diff 的东西。如果只有你本地有那和普通的文档没什么区别团队协作时也发挥不出威力。2.4 环境问题排查心得在实际安装过程中我碰到过两次比较典型的坑。一次是技能文件路径配错了AI 直到重启也没加载出来后来发现是目录层级多套了一层技能文件应该在skills/子目录下而不是仓库根目录。另一次是 OpenSpec 初始化后我在specs/里手写了规格但执行验收命令时提示找不到原因是我漏了把提案先“接受”成正式规格的步骤。这两个问题本身不复杂但如果你不知道“先提案后接受”这个流程很容易卡住。3. 实操用 OpenSpec Superpowers 走完一个“待办事项 API”的 SDDTDD 闭环3.1 第一步把需求拆成可验收的 Spec我先用一个具体项目来演示。假设我们要开发一个待办事项 API需求是“用户可以创建任务、查看任务列表、标记任务完成、删除任务。”这句话如果直接丢给 AI它一定会自由发挥。用 OpenSpec 的时候我会先创建一个提案把这句话拆成具体的验收规则。拆规格的时候要遵循“行为优先”的原则。比如“创建任务”这条我关心的不是用哪个框架而是接口接收什么参数哪个字段是必填的重复的任务名允许吗默认状态是什么把这些规则都列清楚AI 才知道边界在哪里。我当时写的提案里就有类似这样的条目POST /tasks接收title和descriptiontitle必填长度在 1 到 100 之间新任务默认状态为pendingGET /tasks支持按status筛选DELETE /tasks/{id}执行软删除数据仍在数据库中但查询列表时不可见写到这里OpenSpec 的作用已经体现出来了它逼着我把需求细化到“可验收”的粒度。如果哪一条规则没法被测试验证就说明需求还不够清晰。3.2 第二步让 Superpowers 的 TDD 技能先生成失败的测试这份 Spec 写好后我把它放到提案目录下然后打开 AI 助手调用 Superpowers 里的 TDD 技能。这个技能会引导 AI 先写测试而不是先写实现。我第一次跑的时候AI 会先问我“你希望用哪个测试框架测试文件放在哪个目录”这些问题听起来基础但其实就是技能在起作用它在按流程走。确定之后AI 会根据 Spec 里的验收规则生成第一批测试。这些测试大概率是失败的因为实现代码还不存在。我特别强调一下这一步失败是正常的而且是刻意为之。TDD 的红灯阶段就是要让测试先失败证明测试真的覆盖到了需求。如果一开始测试就通过反而要怀疑测试是不是写了个寂寞。3.3 第三步实现代码并让测试通过测试写好后接下来才是写实现。这时候我不再让 AI“写一个 API”而是让它“实现openspec/proposals/xxx/里定义的规格并让测试全部通过”。注意这里的措辞差异前者是开放式任务后者是带验收标准的执行任务。AI 在实现过程中会不断跑测试。如果测试没过它会看失败信息回头改代码。这个循环本身不稀奇但因为有前一步的测试兜底AI 的自由发挥空间被限制住了它不是“写得像需求”就行而是要“让测试变绿”才行。我实际跑下来这段流程里 AI 犯错的概率明显降低因为测试一跑就知道哪里不对不用等到人工 review 才发现。3.4 第四步用 OpenSpec 做变更管理与回归实现通过测试后我会回到 OpenSpec把提案“接受”为正式规格。这一步会让提案从proposals/移动到specs/成为后续所有开发的基准。之后如果产品说要改需求我不会直接改代码而是先创建一个新的提案描述变更再走一遍 SDDTDD 的循环。这样每次变更都有记录代码和需求始终能对齐。我做过的项目里最受益的就是这个环节。以前用传统方式需求变更可能只是在聊天记录里说一句“改成软删除”代码改了但没人知道为什么改过两周又有人把它改回物理删除。有了 OpenSpec 的规格基线任何一次变更都有文档和测试双重记录不会再出现同一个坑踩两次的情况。4. 有没有 OpenSpec差别到底在哪4.1 “没有 OpenSpec 的时候”AI 靠上下文猜为了让你更直观地理解 OpenSpec 的价值我做一个对比实验。同样一个需求“给 API 增加按状态筛选任务的功能”在没有任何规范的情况下我直接让 AI 改代码。AI 第一反应是问“状态字段叫什么可选值有哪些”但因为我没写在规范里它只能猜猜出来是status、done/pending然后开了个接口参数叫filter_status。结果前端同事对接时发现字段命名和另一个模块不一致又得改一遍。这就是没有规范时的典型问题每个功能都“能用”但组合起来到处都是不一致。今天这个接口叫filter_status明天那个接口叫state后天又来个task_status。每次不一致都是一次隐性返工而且是需求越复杂、问题越严重的返工。4.2 “有 OpenSpec 的时候”AI 靠规范执行同样一个需求如果在 OpenSpec 的specs/里已经定义了任务状态的标准命名和筛选参数规则AI 拿到变更提案后会先去看现有的规格然后按照规格里的命名约定来写代码。哪怕它想发挥测试和规格也会拦住它。我自己感受最深的是“AI 的行为预期”变了。没有规范时AI 是一个充满创意的初级工程师你问它怎么做它有一百种做法有规范时AI 变成一个严谨的执行者它的每一步都有依据。对于个人开发者这种差别可能只是少改几行代码对于团队这种差别意味着代码风格、接口命名、业务规则可以长期保持一致。4.3 同一需求两种模式的对比表维度没有 OpenSpec有 OpenSpec需求理解依赖 prompt 里的只言片语AI 靠猜依赖规格文件AI 按规则执行变更追踪变更散落在聊天记录里难以回溯每次变更都是一个提案有完整历史测试依据测试靠人肉补充覆盖不全测试从规格推导验收规则全覆盖返工成本接口语义不一致后期频繁返工前期拆规格花时间后期返工大幅减少团队协作新成员靠问人老成员靠记忆新成员看规格任何需求都有文档这张表不是我拍脑袋写的是我在项目里真实对比后的感受。尤其是“前期拆规格花时间”这一条我可以告诉你最开始的几次确实会不习惯觉得多花了不少功夫。但一旦项目超过两个模块、涉及多人协作这部分时间会十倍百倍地赚回来。5. 这套工作流的边界、常见坑和我的调优经验5.1 Spec 写太粗和太细的两个极端SDD 最大的坑不是不写 Spec而是 Spec 写得不好。写太粗比如只写“用户可以删除任务”那 AI 还是得猜软删除还是硬删除写太细比如连变量名都规定好那 AI 就失去了灵活性代码会很机械。我的经验是Spec 应该聚焦在“业务规则和验收标准”上而不要管“怎么实现”。什么算业务规则“删除后列表不可见”算。“调用tasks.delete()而不是remove()”就不算。前者是需求后者是实现细节。OpenSpec 的提案模板里一般会引导你写“行为”和“验收标准”这就是在逼你把注意力放在业务规则上。5.2 测试不是越多越好如何把握 TDD 粒度引入 TDD 之后很容易走向另一个极端每条规则都写好几个测试测到后面测试比代码还长改一个功能要连带改十几个测试人就开始烦躁了。我自己也经历过这个阶段后来总结出一个标准一个验收标准对应一个端到端测试加上必要的边界测试不要为了覆盖率而写重复的单元测试。比如“创建任务时 title 必填”这条规则我会写一个“不带 title 创建返回 422”的测试再写一个“正常创建返回 201”的测试这就够了。不需要再写“title 长度刚好 100 返回 201”“title 长度 101 返回 422”这种排列组合式的测试。真正容易出 bug 的边界情况当然要覆盖但不要让测试变成代码的复读机。5.3 AI 幻觉环节如何让 Superpowers 的技能描述约束模型就算装了 SuperpowersAI 还是偶尔会在不该发挥的地方发挥。我遇到过一次规则明明写了“删除任务为软删除”AI 在模型层依然实现了物理删除因为它在网上学到的“删除”就是delete()。这其实是技能描述里的约束没被 AI 理解透。怎么解决关键不在于骂模型而在于把测试写得更狠。既然规格里写了软删除那就在测试里加上“删除后数据库中记录仍存在”的断言。有了这条测试AI 再想物理删除就会被红灯拦住。Superpowers 的技能只是提高 AI 按流程执行的确定性最终真正的防线还是测试。5.4 团队协作与 CI 集成建议这套工作流如果只是个人用价值已经不小如果团队用我有个强烈建议把 OpenSpec 和测试接入 CI。每次有新提案时CI 自动跑一遍规格变更的检查看一下是否有对应的测试每次代码提交时跑一遍全量测试。这样“规范和测试同步”就不是靠自觉而是靠流程强制。我见过一个团队他们甚至会在 Code Review 的时候先看提案再对照测试最后看实现。这个顺序很重要提案解决“为什么做”测试解决“怎么做算对”实现解决“怎么做出来”。按这个顺序 review基本不会出现代码风格之争因为真正的业务讨论都发生在更早的提案阶段。5.5 别把它和 n8n、Dify、ComfyUI 里的“工作流”搞混最后想多说一句。最近“工作流”这个词被各种自动化平台用得很多像 n8n、Dify、Coze甚至 ComfyUI 里的节点连线也叫工作流。但这些是“自动化业务逻辑编排”或“数据处理流程”和本文说的 SDDTDD 编码工作流不是一回事。OpenSpec Superpowers 解决的是“AI 写代码的时候按什么流程来”而不是“把 A 应用的数据传到 B 应用”。如果你同时用 n8n 做业务自动化也用 OpenSpec 做开发流程管理两者不冲突但它们不属于同一个层次。我在实际使用中的体会是OpenSpec Superpowers 这套组合真正改变的不是代码生成的速度而是“返工的节奏”。以前问题是靠人肉 review 发现的现在是靠规范和测试自动拦截的。这个转变带来的心理变化也很大——我不再担心 AI 哪次悄悄自作主张了反正有测试兜底有规格对齐。最后再分享一个小技巧每次完成一个功能并接受提案后把当时的经验和新增的规则沉淀回后面的技能描述里。你会发现这套工作流用久了AI 助手会越来越懂你。