ARTICLE · 1307765
你的 AI 写码助手,缺的不是智能,是纪律
你的 AI 写码助手，缺的不是智能，是纪律
一份「Superpowers 工程方法论」的完整使用教程。这篇会讲清楚四件事：它是什么、怎么安装、怎么触发，以及七步工作流每一步到底在做什么、做到什么程度算过关。
“帮我写个接口。”你对 AI 说。
30 秒后，代码出来了。你贴进项目，跑测试，报错；改了一处，又报错；再改，终于能跑了。三个小时过去，你看着这段“能用但不敢重构”的代码，突然意识到：它写代码的时间，还没有你修代码的时间长。
这个场景太常见了。问题不在 AI 不够聪明，而在你从来没有告诉过它：什么叫“好好写代码”。
今天介绍的Superpowers 工程方法论，就是给 AI 补上这一课——它不是让 AI 写得更快，而是让 AI 写得更稳。
01 为什么 AI 写代码总是“快而不稳”
把 AI 想象成一个聪明但没受过训练的新人：你让它直接出结果，它就直奔结果——不确认需求、不设计方案、不写测试、不检查回归。
它把“写出来”当成终点。而在工程里，真正的终点是“能上线、能维护、能改”。
于是，所有被省略的环节，都变成你事后要还的债：需求理解错了，返工；没有测试，不敢改；没有评审，没人把关。
一句话：AI 缺的不是能力，是流程。
02 什么是 Superpowers：不是按钮，是一套工程纪律
Superpowers 是一套开源的 AI 编程工程方法论技能集，由开发者 Jesse Vincent（网络名 obra）创建，目前已上架 Anthropic 官方插件市场，在 GitHub 上积累了超过 20 万 Star（据第三方技术社区报道，截至 2026 年年中）。
它要解决的问题只有一句话：让 AI 产出“工程级”的代码，而不是“玩具级”的代码。
它不是某个功能按钮——装上之后，界面上并不会多出一个按钮。它改变的，是 AI 接到需求之后的行为方式：
先提问，再设计，再计划，再动手；
先写会失败的测试，再写实现；
先评审，再合并。
你可以把它理解成：给 AI 请了一位严格的项目经理。它不再直奔结果，而是按流程走完每一步。
03 三分钟装好，全项目生效
技能安装在你的用户级目录下，一次安装，所有项目都能用，不用每个项目单独配置。装好之后长这样：
<用户级 skills 目录>/superpowers/├── SKILL.md # 主入口：核心理念 + 7 步工作流├── README.md # 能力简介与触发词└── references/ ├── 01-workflow.md # 基础工作流详解 ├── 02-writing-plans.md # 实施计划的格式规范 ├── 03-tdd.md # 红绿重构循环铁律 ├── 04-systematic-debugging.md # 4 阶段系统化调试 └── 05-code-review.md # 两段式代码评审常见安装位置：
Windows：%USERPROFILE%\.workbuddy\skills\superpowers\
macOS / Linux：~/.workbuddy/skills/superpowers/
安装方式有两种：直接对助手说「安装 superpowers」；或在技能市场搜索「Superpowers 工程方法论」。装好的技能，随时可以在设置里查看或停用。
04 怎么触发：显式和隐式
Superpowers 没有界面开关，它的触发分两种：
怎么确认它生效了？看 AI 的第一个动作：如果它上来就贴代码，说明流程没启动；如果它先反问澄清问题、先出设计文档或计划、先写一个会失败的测试——说明纪律已经在工作了。
05 核心：七步工作流
这是整套方法论的主体。先给一张总表，再逐条拆解。
第 1 步：头脑风暴——把想法逼成规格。粗糙的想法不能直接开工。AI 会用提问帮你把想法逼成规格：这个功能给谁用？边界在哪？做成什么样算成功？同时至少对比 2 个方案，让你逐块确认。产出是一份设计文档，门禁只有一条：你明确点头签字，才进下一步。这一步最常见的坑是“想都不想就开写”——需求越模糊，后面返工越贵。
第 2 步：开隔离工作区——先给自己一块安全区。新建一个 git worktree 或分支，跑通项目初始化，确认测试基线是干净的。这样后面任何一步写坏了，都不会污染主分支。门禁：基线测试全绿才开写。
第 3 步：写实施计划——把大象装进冰箱。把整个功能拆成一个个 2-5 分钟能完成的小任务，每个任务精确到：改哪个文件、改哪一行、跑什么命令验证。门禁：任务粒度超过 5 分钟，就继续拆。计划的意义不是好看，而是让每个任务小到不可能出错。
第 4 步：子代理驱动开发——专人专项。每个任务派一个全新的子代理去执行，执行完做两段式评审：先看是否符合规格，再看代码质量。门禁：每个任务独立评审通过。这么做的好处是，评审者和写代码的人分离，不容易“自己看不出自己的问题”。
第 5 步：TDD——先失败，再成功。强制走 RED → GREEN → REFACTOR 循环：先写一个会失败的测试（RED），再写最少量的实现让它通过（GREEN），然后重构、确认测试仍然全绿（REFACTOR）。门禁：没有先失败的测试，就不算实现。这一步把“测试”从可选项变成了硬性前提。
第 6 步：代码评审——合并前的最后一道闸。对照实施计划逐条检查，问题按严重程度分三级：Critical（阻断合并）、Major（必须修）、Minor（建议优化）。门禁：Critical 未清，阻断推进。
第 7 步：收尾——干净地结束。跑完整测试套件，给出四个选项让你决定：合并、开 PR、保留分支、丢弃，最后清理 worktree。门禁：全量测试通过。
06 四条铁律：写在最前面的红线
七步流程之外，有四条红线贯穿始终。违反任何一条，流程立即停止：
规格未确认，不动手。需求没有说清楚之前，任何代码都是浪费。
计划没写清，不派活。任务含糊，执行就会跑偏。
没有先失败的测试，就不算实现。先有红，才有资格谈绿。
能用 100 行解决，不写 1000 行。克制是工程美德。
07 配套能力：系统化调试
七步流程管的是“写新代码”。遇到偶现 Bug 时，还有一套专门的调试方法论，核心是四个字：不猜不改。
第 1 阶段：复现。先写出一个能稳定复现问题的最小用例。复现不了，就谈不上修。
第 2 阶段：根因追踪。沿调用链用日志定位“真相在哪一层”——是数据源的问题，还是消费端的问题？先找到根因，而不是修表面症状。
第 3 阶段：纵深防御。修根因的同时，在边界加防御：输入校验、超时、重试。让同类问题以后更难发生。
第 4 阶段：条件等待。遇到竞态问题，用事件或条件变量代替 sleep 硬等，最后跑回归测试，证明真的修好了。
除调试外，这套方法论还自带几项配套能力：完成前验证（每个任务交付前都要真实验证，而不是“看起来没问题”）、并行派单（互不依赖的任务可以并行推进）、接收评审（子代理之间互相评审，把把关当成流程的一部分）。
08 四个真实场景
方法讲完，看四个最常见的用法，全部用对话体还原。
场景一：新功能开发。“用 superpowers，给车辆状态查询加一个按区域聚合的接口。”AI 不会直接写代码，而是先提问确认：聚合粒度按什么算？返回结构什么样？复用已有 schema 还是新建？然后落设计文档 → 开分支 → 拆任务（写 schema、写 service 方法、挂路由加测试，每个精确到文件路径和验证命令）→ 子代理逐任务 TDD 推进 → 评审 → 收尾合并。
场景二：修一个偶现 Bug。“superpowers 模式，遥测数据偶尔丢失最后几条。”AI 不猜不改：先写一个能稳定复现的最小用例，沿调用链用日志定位“真相在哪一层”，修根因的同时在边界加防御（输入校验、重试），对竞态用条件等待代替 sleep，最后跑回归测试证明修好。
场景三：重构迁移。“先想清楚再写，把异步任务从 Redis List 迁到 Redis Streams。”头脑风暴阶段先对比“逐个 key 渐进迁移”和“整体切换”两个方案的取舍，让你选；然后设计文档 → 计划拆到函数级 → 每个小任务红绿 TDD → 评审把关 → 收尾。
场景四：只要计划，不要代码。“用 superpowers 给‘设备驱动热插拔’写一份实施计划。”AI 只走到第 3 步，产出计划文档交给你确认或派发，一行代码不动。
09 常见疑问
Q1：需求已经很明确了，还要头脑风暴吗？不用。直接说“跳过 brainstorm，直接写计划”，AI 会从第 3 步开始。
Q2：计划写到一半想改需求，怎么办？可以改，但必须回头更新计划文档，不能悄悄改代码。计划是唯一的事实来源。
Q3：它不是代码任务，能用吗？能。它管的是工程纪律，可以和领域技能并行——写脚本、做视频项目、处理数据分析，只要涉及产出物，这套“先想清楚再写”的流程都适用。一次性脚本、探索性 demo、纯文案润色就不必硬套。
Q4：子代理是什么？是 AI 为每个任务临时派出的“专职执行者”。它只负责当前任务，执行完就结束，评审由另一个代理完成，保证写和查分离。
写在最后
回到开头那个场景。你让 AI 写接口，它 30 秒出码，你 3 小时修 bug。
真正的问题从来不是 AI 写得不够快，而是它缺一套流程。Superpowers 做的事，就是把“工程纪律”装进 AI 的行为里：先想清楚，再动手；先写失败，再写成功；先评审，再合并。
下次再让 AI 写代码，不妨先说这四个字：“先想清楚再写。”
你会发现，慢下来的那几分钟，省掉的是后面几小时。
