Superpowers 实测：把开发方法论塞进 agent，值不值得装

这是单次对照，不是统计结论：执行者是同一个模型，每个任务只跑一遍，所以下面的数字只能说明方向，不能说明分布。每个数字怎么来的，我写在了表下面；原始命令与时间戳记在实验记录里。

它到底做了什么

obra/superpowers（301,784 stars，MIT，建库 2025-10-09，最近 push 2026-10-10，2026-10-19 取数）装的不是单个 skill，而是 15 个 skill 组成的一套流程。决定行为的是其中四个：

• using-superpowers：入口。原文要求「只要有 1% 的可能用得上 skill，就必须调用」，而且是在回答任何问题、看任何文件之前。它列了一张「红旗」表，专门堵「这个任务很简单，不用流程」这类想法。
• brainstorming：先问再做。第一条消息只能是一句「你可以让我跳过提问」加一个开放问题，之后一次只问一个问题；结论写成设计文档，放在 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md。文档写完之前不许写产品代码，原文把它写成 HARD-GATE，连「装依赖、建项目」也算构建。
• writing-plans：把设计拆成带勾选框的任务，落到 docs/superpowers/plans/YYYY-MM-DD-<feature>.md，每个任务自带「写失败测试 → 跑红 → 写最小实现 → 跑绿 → 提交」的步骤，并且要求写清「哪个文件、哪个函数、哪个测试」。
• test-driven-development：核心是一句「没有失败的测试就不写产品代码」。SKILL 里还有更狠的一条：先写了实现？删掉重来，不许留着当参考。

装法就是 npx skills add obra/superpowers。实际落盘是项目里的 .agents/skills/（真身）加 .claude/skills/（给 Claude Code 的副本），15 个目录。它不改变模型的任何开关，只是往 agent 的 skill 列表里放文件；能不能用上，取决于你的 harness 会不会在新会话里加载它们。

实测：同一个小任务，装与不装

任务原文（两次完全相同）：

在一个只有 add 命令的 Node CLI 小项目里，增加 --csv 导出功能，并补测试。node cli.js add 2 3 --csv 输出一行 2,3,5；不传 --csv 时行为完全不变；--csv 可以放在参数任意位置；npm test 全绿；不引入任何依赖。

起始代码相同：cli.js 44 行、test/cli.test.js 22 行、package.json 9 行，npm test 原有 2 个用例全绿。

口径先说清：耗时是墙钟时间，从第一条命令到最后一条命令，包含模型思考；工具调用按「读一次 / 写一次 / 执行一条命令」各计一次；行数来自 git diff --numstat，+ 是插入、- 是删除，文档与代码分开列，不拿文档行数冒充代码。

基线我跑了两遍（两个 bench 各一次），两次都是 +23/-3、3 个用例全绿，所以基线不是单次偶然。两次耗时分别是 18 秒和 26 秒，差的 8 秒是第二次多读了两个文件，不是实现有分歧。装后多出来的 9 次调用逐个数是这样：读 4 份 SKILL.md、写 2 份文档、读 2 个源文件、写 1 次失败测试、跑 1 次红、改 3 次实现（主逻辑、输出分支、--help）、跑 1 次绿并提交。需要说明的是基线那 5 次不含读文件——起始文件是我几分钟前刚写的；换一个陌生仓库，基线大概会多 2 到 4 次读文件。

多出来的 11 行代码不是流程自己长出来的，是流程逼出来的边界被写成了测试：--help 多一行，测试里多了「位置无关」和「负数小数」两个断言。设计文档里「不输出表头、不引入 flag 解析器、小数直接插值」这三条决定，如果不写下来，基线那次我也不会停顿去想「到底要不要表头」——这次我是在文档里把它定死的。

好的地方

1. 真的看红了一次。基线的做法是「改实现 → 补测试 → 全绿」，测试是事后补的，我没见过它失败。装后按 TDD 先写测试，npm test 报的是 用法: calc add <a> <b>、退出码 1，因为 --csv 被当成了第一个数字。这五秒钟让我确认测试确实在测新行为，而不是跟着实现一起写对。
2. 把「谁决定的」和「谁没决定」分开了。brainstorming 要求把执行者的决定单列，不能写成「提问者同意的」。我在设计文档里因此留下「无表头是执行者的决定」这一条；团队里如果有人要表头，吵的时间点在写代码之前，而不是在 review 时。
3. 计划里的 Review Focus 清单生成了一个我基线没写的用例：add -1.5 2 --csv 应输出 -1.5,2,0.5。这是整个对照里唯一一处「装后质量确实更高」的可指认证据，其它都是成本。

问题

1. 流程重，而且重在下游。 18 秒变 52 秒，5 次调用变 14 次，为了 11 行代码产出 118 行文档。文档不是废纸，但对「加个 --csv」这种需求，读计划、勾步骤、写 spec 的时间已经超过写代码本身。任务越小，这笔账越难看。

2. 安装先卡在网络上，而且报错不指向真因。 第一次执行时，skills 1.7.2 直接失败：

   fatal: unable to access 'https://github.com/obra/superpowers.git/':
   Failed to connect to github.com port 443 via 127.0.0.1 after 2057 ms

   真因不是 GitHub 挂了，是这台机器的全局 git 配置把 http.proxy 和 https.proxy 指到了 127.0.0.1:7890，而那个端口没有服务在听（本机实际在听的是 7897）。用 GIT_CONFIG_COUNT/KEY/VALUE 临时覆盖成 7897 之后，用 git ls-remote 验证连通 3.3 秒返回，随后安装 9.8 秒完成。这件事和 skill 本身无关，但它是中文用户装它时要过的第一道关，报错长得像「网络被墙」。

3. 装完，当前会话不生效。 安装完成后，我这个会话的可用 skill 列表没有多出任何一条；我是手动打开 .claude/skills/using-superpowers/SKILL.md 才照着做的。也就是说「装」和「用上」之间还差一次新会话，或者一次显式的读文件。对本机这种早就装过副本的情况（~/.dsh/skills/superpowers-skill，创建于 2026-08-22）尤其如此：装了几个月，也不会自动生效。补一个更准确的区分：那份旧副本在会话的 skill 列表里是列出来的（listed），只是正文没有被读入（not loaded）。这削弱了对照的干净程度——基线里的模型早就知道它存在、也知道它的一句主张，「不装」只是没加载，不是不知道；我不能把它当成一个干净的对照。

4. brainstorming 要求一问一答，和批处理场景直接冲突。 它规定一条消息只问一个问题、然后等回答。这个任务里没有能回答的人。我选择自答并把它记成「偏差」，而不是假装流程跑通了——这已经偏离 SKILL 的定义，所以我不能说「它在无交互场景下表现如何」。如果你的使用场景是 CI、单轮问答、定时任务，这道 HARD-GATE 会让你要么卡死，要么像我一样绕过；绕过之后它还剩多少价值，得你自己判断。

什么任务不值得用它

1. 一行到十行的 bug fix。 这类改动的正确性靠读代码就能确认，brainstorming 的问与答、计划的勾选框、TDD 的红灯，三层成本都指向同一个结果。
2. 一次性的探查脚本。 SKILL 里其实留了豁免：spike 可以不打测试、跳过计划和 review。问题是你得先知道有这条豁免，并且主动说「这是 spike」；否则默认流程照样把你按在文档上。
3. 无人值守的自动化：CI 里跑的修修补补、定时任务、批量迁移。没有人类批准，HARD-GATE 就是死锁；强行跳过，你拿到的只是「读了一堆文档之后照常写代码」，成本付了，纪律没落下。

结论

看场景，别默认常开。 改动会交给别人 review、跨多个文件、或者中途可能换人接手，装；只是想让 agent 把一个小功能写完，它带来的 118 行文档比那 11 行代码贵。单次对照的局限我再说一遍：一个模型、每个任务一遍，这些数字只能当方向，不能当承诺。