Superpowers 与 Spec-Kit 如何结合落地从AI 随便写到AI 按规范执行一套让 AI 真正成为开发助力的工作闭环一、AI 写代码越来越强但问题也随之而来AI 辅助编程工具越来越多写代码的速度确实快了。但用过的团队大多会遇到同一个困境AI 写得很快但不是你想要的。举几个常见的场景需求是做一个用户登录AI 交出来的代码能跑但没有处理 token 过期错误提示文案是英文注册流程和登录混在一个组件里单元测试一个没有改 AI 的输出比自己写还累最后把 AI 的输出当成草稿重新自己写一遍问题不在 AI 能力不够在于 AI 不知道你要做什么。你给 AI 的是一句模糊的描述它按自己的理解把细节全填了而这些细节往往和你真正想要的并不一致。解法是在让 AI 动手之前先把做什么、做成什么样对齐并固化下来。这就是 Superpowers 和 Spec-Kit 组合要解决的事。二、如果没有 SDD会怎样在介绍工具之前先正视一个问题如果整个团队——包括 AI——都凭感觉做事会发生什么需求在脑子里不在任何地方“这个功能很简单就是用户能上传头像。”但产品理解的上传是覆盖式上传开发理解的是可以上传多张AI 直接生成了一个带裁剪、压缩、旋转功能的完整图片管理模块测试按单图场景写了用例。四个人说了同一句话脑子里是四个完全不同的产品。没有一份被所有人认同的文档每个人都在按自己的想象填空。接口是后置的靠同步来弥补前端问后端这个接口返回什么结构后端说你先做着回头再定。前端做了一版后端说改成那个格式吧前端默默重构。后端做完发现产品加了新字段要改接口前端说我这边也要动。一来一回接口改了四五版谁也说不清最初是谁的原因。改需求没有成本改完才发现“这个需求变更很小五分钟的事。”然后数据库要加字段后端接口要改参数前端要重新对接测试用例要从头补充凌晨两点在群里通知相关方。没人提前算过这笔账。完成没有标准差不多成为共识功能做完了吗开发说做完了。测试说还差边界情况没覆盖。产品说对但颜色不对。客户说能用但是不是我想象的那样。每个人都觉得自己完成了工作但没有人敢说这活真正干完了。因为没有一份文档事先定义了完成的含义。积累下去项目变成什么样阶段现象早期代码还能看懂小改怡情中期改一个小功能要顺藤摸瓜三个模块后期没人敢动核心逻辑加功能靠 if-else 堆砌晚期招聘 JD 上写着需要有勇气这不是技术不行是在错误的图纸上盖楼盖得越快拆得越惨。根因只有一个缺少一个在动手之前就达成共识的设计基准线。三、Superpowers 和 Spec-Kit 各自是什么Superpowers执行者Superpowers 是一个 AI 辅助开发框架拥有多种 Skills每种 Skill 对应一类特定任务头脑风暴需求探索、方案发散TDD 测试开发测试先行驱动实现前端设计界面方案设计代码评审requesting-code-review基于 SPEC.md 对照检查Superpowers 的特点任务目标明确时执行质量很高。但它不负责定义目标——在没有清晰边界的情况下它不擅长自己做决策。Spec-Kit规范制定者Spec-Kit 是一套结构化规范落地系统提供一组命令覆盖从需求到代码的完整生命周期命令作用speckit-constitution定义项目设计原则speckit-specify将模糊需求转化为技术规范SPEC.mdspeckit-plan制定实现计划plan.mdspeckit-tasks拆解为任务清单tasks.mdspeckit-analyze校验规范文档一致性Spec-Kit 的核心输出是三份文档SPEC.md技术规范、plan.md实现计划、tasks.md任务清单。两者的本质差异维度SuperpowersSpec-Kit定位执行者规范制定者输入明确的目标和规范模糊的需求输出代码、测试、评审意见SPEC.md、plan.md、tasks.md擅长动手做、按规范执行动手前、把事情想清楚Superpowers 知道怎么做但需要有人告诉它做什么。Spec-Kit 做的事就是在动手之前把做什么固化下来。四、两者如何结合一个完整的开发闭环第一步开工前——怎么让 AI 打开对应的技能用 AI 写代码直接丢一句帮我写一个用户管理系统然后期待 AI 自己搞定一切往往写出来的不是你要的。正确的做法是先告诉 AI你现在进入什么角色、用什么工具。角色对了讨论才有效。下面每一步该用什么工具会在步骤里直接写出来。为什么要先头脑风暴、再 spec-kitspec-kit 擅长问技术细节——接口什么格式、数据模型怎么设计、边界条件有哪些。但它不会质疑需求本身对不对。很多情况是需求本身有问题。• “我要一个文件上传功能” → 用户真正需要的是批量导入• “加一个筛选功能” → 没想清楚筛选出来之后干什么• “做一个数据面板” → 没有定义什么叫数据对这些是产品问题不是技术问题。spec-kit 不会挑战方案只会翻译方案。所以分工是头脑风暴用来挑战需求本身spec-kit 用来把确定的需求翻译成技术语言。需求还没收敛的时候直接进 spec-kit相当于在技术细节上吵了半天最后发现大方向还没对齐。第二步需求探索Superpowers — 头脑风暴触发指令我要实现一个用户管理系统现在使用 superpowers 的头脑风暴 skill 我们来讨论一下这个需求。用头脑风暴探索需求完成三件事深入理解业务场景识别真实用户痛点多角度发散解决方案不急于收敛完成产品需求的初步梳理形成清晰的待解决问题清单输入模糊的业务需求 →输出结构化的产品需求文档这个阶段 Spec-Kit 不参与——需求还没成型不需要那么重的结构。第三步规范落地Spec-Kit触发指令需求已经讨论完了现在用 spec-kit 来落地规范。 先用 /speckit-constitution 定义项目设计原则 然后 /speckit-specify 聊需求细节生成 SPEC.md 接着 /speckit-plan 确认实现计划最后 /speckit-tasks 拆解任务。用 Spec-Kit 的四个命令将产品需求转化为技术规范speckit-constitution— 定义项目设计原则先定规则再聊细节。项目级的基本约束包括代码风格要求、架构原则、API 设计风格、技术栈约束。这些是后续所有讨论的背景规则不是可有可无的前言。speckit-specify— 生成 SPEC.md最核心的一步。通过对话把产品需求中的每一个模糊点都明确下来接口定义URL、请求参数、响应结构、错误码数据模型字段含义、类型约束、关联关系边界条件空值、最大长度、并发场景验收标准什么叫做完了输入产品需求文档 →输出SPEC.mdspeckit-plan— 制定实现计划基于 SPEC.md 制定实现计划技术路径选择为什么用这个方案、文件结构设计、依赖关系和执行顺序、潜在的难点和备选方案。输出plan.mdspeckit-tasks— 拆解任务清单将 plan.md 转化为可独立执行的任务列表。每条任务有明确的输入输出可独立测试有验收标准。输出tasks.md第四步交接——Superpowers 读取规范规范制定了但 AI 执行者怎么接手规范如果只是存在于文件里AI 执行时很可能凭自己的理解填充细节——和最初的问题一模一样。触发指令用 Superpowers from-spec 模式读取当前 Spec-Kit 所有规范进入严格执行模式 要求禁止自由设计、禁止修改规范、100% 按 Spec 开发 注意这是读取规范不进行执行读取结束之后告诉我。Superpowers 读取规范后进入严格执行模式• 不允许自由设计规范里有的严格执行• 不允许修改规范发现问题记录下来走变更流程不自行决定• 100% 按 Spec 开发第五步TDD 测试开发Superpowers触发指令规范已经确定了现在用 superpowers 的 TDD skill 开始开发。 先写测试用例再写实现代码以通过测试为目标。有了规范Superpowers 用 TDD 模式执行先写测试基于 SPEC.md 中的验收标准明确预期行为再开发功能以通过测试为目标驱动实现小步提交每通过一个测试就提交步步有反馈这样保证代码实现和验收标准完全对齐——如果没按规范做测试直接失败。第六步代码评审Superpowers — requesting-code-review触发指令功能开发完了现在用 requesting-code-review skill 做代码评审。用 requesting-code-review skill 做代码评审逐条检查代码是否符合 SPEC.md 中的定义覆盖可维护性、安全性、边界处理等维度发现不符项立即打回修正。五、Superpowers Spec-Kit 的核心优势各司其职不混用。Superpowers 负责执行Spec-Kit 负责规划。两个工具在不同的阶段做不同的事不打架。规范不丢失交接有标准。传统流程里规范制定完了开发按自己理解做规范慢慢变成一纸空文。有了 from-spec 模式和严格执行约束规范才真正起到基准线的作用。AI 真正成为助力而不是制造问题。AI 写代码快但前提是目标清晰。当规范足够详细时AI 的速度优势才能真正发挥——它不是在猜测而是在执行。测试驱动质量有保障。TDD 模式让每行代码的修改都有测试覆盖。代码有没有按规范做测试会告诉你而不是等到上线之后才发现问题。六、总结问题没有 SDD 的做法Superpowers Spec-Kit需求对齐口头同步靠记忆规范文档所有人同一版本接口设计开发时后置边做边改编码前冻结SPEC.md 明确定义验收标准靠个人判断“差不多就行”SPEC.md 中每条可验证AI 执行AI 自由发挥结果靠运气规范约束100% 按 Spec 执行质量保障Code Review 靠审美讨论requesting-code-review TDD有据可查核心理念只有一句话在动手之前先把事情想清楚把想清楚的结果写下来然后让 AI 按写下来的文档执行。这样AI 的速度优势才能真正发挥项目也不再是盖得快、拆得快的反复循环