一、第一性原则AI 编程真正的问题不是“不聪明”而是“不稳定”很多人用 AI 写代码时都会遇到一种熟悉的崩溃一开始它看起来很强。能读代码、能改文件、能跑命令、能解释架构。但只要任务稍微变长它就开始出现几类问题第一它会跳步骤。本来应该先理解需求、再设计、再写测试、再实现它可能直接开改。第二它会自我合理化。比如“这个改动很简单不需要测试”“我先快速看一下代码”“我先修一下再说”。这些话听起来很像一个赶工期的初级工程师。第三它会上下文漂移。前面说好的约束后面忘了前面设计过的边界后面改着改着又偏了。第四它会把完成感误认为完成。代码写了测试没跑问题看似修了根因没验证功能能跑一次但边界条件没覆盖。所以第一性原则不是“如何让模型更聪明”而是如何让一个概率型 Agent在长流程任务里持续遵守确定性工程纪律。Superpowers 的价值就在这里。它不是简单地增强模型能力而是把工程流程拆成一组可复用的 Skill头脑风暴、写计划、使用 git worktree、测试驱动开发、系统性调试、代码审查、接收 review、完成分支等。Superpowers 官方 README 里也把它的基本流程写得很清楚从 brainstorming到 writing-plans再到 subagent-driven-development / executing-plans、test-driven-development、requesting-code-review、finishing-a-development-branch。它的底层哲学是 TDD、系统化优先、降低复杂度、证据胜过声明。这就是我对 Superpowers 的理解**Superpowers 不是“让 AI 更会写代码”的工具而是“让 AI 更像一个遵守工程流程的团队”的约束系统。 *二、Superpowers 真正强的地方不是自动化而是降低工程熵我觉得 Superpowers 最强的地方有三个。1. 它逼 Agent 先想清楚再动手brainstorming的作用不是“多聊几句”而是让 Agent 在写代码前先澄清目标、边界、替代方案和风险。这一步对复杂需求非常重要。因为 AI 写代码的问题往往不是语法不会而是需求还没被压缩成可执行设计。人类工程师也一样。需求不清楚时写代码越快返工越快。2. 它把“计划”变成可执行工单writing-plans的关键不只是生成一个漂亮计划而是把任务拆成足够细的执行单元文件路径、具体改动、验证步骤、预期结果。这让 Agent 不再凭感觉游走而是围绕一个计划推进。这也是 Superpowers 和普通“帮我写个实现计划”的差别普通计划是文档Superpowers 里的计划更像 Agent 的任务队列。3. 它用 TDD 和 Review 对抗模型幻觉Superpowers 强调 RED-GREEN-REFACTOR先写失败测试确认失败再写最小实现再确认通过。README 中甚至明确描述test-driven-development会执行“写失败测试、看它失败、写最小代码、看它通过、提交”的循环。这背后有一个朴素但重要的判断**不要相信 Agent 说它完成了要相信可重复验证的证据。 *三、但 Superpowers 不是银弹它最大的副作用是“流程过重”如果只讲优点也没必要写这篇文章了。Superpowers 的问题也很明显它可能把小任务复杂化。官方仓库 Issues 里已经有不少用户反馈类似问题。有人反馈安装后 Claude Code 响应明显变慢怀疑 Superpowers 的上下文占用了太多空间。也有人反馈一个简单任务让 Claude 在 5 分钟内把 quota 用完表现为“开始 overthink做了很多以前不会做的事比如写文档”。还有一个很典型的 Issue 提到Superpowers 当前像是 “all-or-nothing” 体验会对每个 prompt 触发完整工程流程哪怕只是修一个 typo 或改一个 UI 颜色用户希望有/fast、/direct、!sp、/simple-mode之类的机制来按需开启或绕过。这说明什么说明 Superpowers 的核心矛盾是流程纪律能降低错误率但流程本身也有成本。这在软件工程里很正常。你不会为了改一个按钮文案开一次完整架构评审也不会为了改一个 README 拼写错误走完整 TDD。所以**Superpowers 应该按风险启用而不是按习惯启用。 *四、哪些场景适合 Superpowers哪些场景不适合第一类强烈适合 Superpowers这类任务通常具备几个特征需求有歧义、改动跨多个文件、需要保持架构一致性、失败成本高、需要测试和 review。例如从 0 到 1 做一个功能模块重构核心业务逻辑修一个复现不稳定的 bug接入支付、鉴权、权限、数据迁移多 Agent 并行开发一个较大需求需要先出设计方案再分阶段执行这类任务里Superpowers 的流程成本是值得的。第二类可以使用轻量 Superpowers这类任务有一定复杂度但不一定需要完整链路。例如修一个中等复杂 bug给已有功能补测试小范围重构生成一个 PR review checklist这时可以只显式调用某个具体 Skill而不是让 Superpowers 全套流程启动。比如/superpowers:systematic-debugging 这个接口偶发 500帮我按根因排查或者/superpowers:test-driven-development 给这个函数补边界测试第三类不建议使用 Superpowers这些任务更适合 direct mode改 typo改一个颜色值改一句文案问一个概念让 AI 解释某个命令快速生成一个小脚本草稿临时做一次不进入主分支的实验对这类任务Superpowers 的完整流程很可能是负收益。五、常见的几个坑以及我的解决办法坑 1Skill 自动触发不稳定Anthropic 文档说codex、Claude 会在相关时使用 Skill也可以用/skill-name直接调用。 但社区测试表明自动触发并不总是可靠。Scott Spence 做过一个关于 Claude Code Skills 激活率的测试。他的结论是无钩子或简单提示时Skill 激活像“掷硬币”他后来通过 forced eval hook 和 LLM eval hook 把激活率提升到 80% 到 84%但也承认并不完美。另一个 Medium 文章也做了 650 次测试指出普通描述下自动激活表现不稳定而更强指令式描述能显著提高触发率不过这类文章属于社区实验不能等同官方结论。关键任务不要赌自动触发。要么显式 Slash 调用/superpowers:brainstorming 我想做一个本地 AI 视频口播工具先别写代码先帮我拆需求和方案要么在 prompt 里明确说请显式使用 superpowers:brainstorming不要直接进入实现。但最稳的方式仍然是 Slash Command因为它比自然语言提醒更接近“命令”。坑 2过度思考烧 token拖慢速度Superpowers 的流程会引入 brainstorming、planning、review、subagent 等额外步骤。对复杂任务这是护栏对简单任务就是阻力。官方 v6.1.0 其实已经开始处理这个问题最新版重点是降低每个 session 的 token 成本压缩using-superpowersbootstrap删掉冗余的工具映射参考同时不移除关键行为约束。但即便 v6.1.0 降低了成本也不代表所有场景都该启用。我的解决办法是做“三档模式”Fast Path小改动直接做不启用 Superpowers。 Skill Path中等任务只调用一个明确 Skill。 Full Superpowers复杂任务走 brainstorming → plan → TDD → review。你可以在项目的 Agent 规范里写默认使用 Fast Path。 只有当我显式输入 /sp、/superpowers 或具体 /superpowers:xxx 时才启用 Superpowers。 对于 typo、样式微调、单文件机械改动不要自动进入 brainstorming / writing-plans / subagent-driven-development。这不是削弱 Superpowers而是让它从“默认反射”变成“高风险任务的工程模式”。坑 3子 Agent 可能没有继承完整 discipline contextSuperpowers 很依赖“先检查技能、不要跳过流程”的纪律。但一些测试发现主会话能看到using-superpowers的 Red Flags 表子 Agent 却看不到子 Agent 虽然能看到 Skill 列表但在没有纪律提示时会跳过 TDD而在明确提示后才遵守。该 Issue 的判断是问题不是 Skill 工具不可用而是子 Agent 缺少 discipline context。这类问题说明多 Agent 流程不只是“多开几个 Agent”这么简单。每个子 Agent 都是一个新的上下文岛。如果纪律没有传进去它就会回到默认模型行为。分发子任务时把流程要求写进任务本身。不要只写实现 Task 3。而要写实现 Task 3。必须先检查适用 Skill如果涉及代码实现使用 TDD完成后说明测试证据不要跳过验证。坑 4计划文件可能变成 token 黑洞有用户在 Issue 里指出writing-plans会生成单一的大计划文件反复读取会贵讨论中也承认计划文件本身是已知低效点真正的缓解来自 subagent 只读取自己的任务切片以及任务列表作为压缩后仍能保留的索引。不要迷信“一个巨型计划文档”。更好的做法是docs/plans/xxx/ overview.md task-1.md task-2.md task-3.md让主 Agent 只读 overview让子 Agent 只读自己的 task 文件。这符合工程里的模块化原则也符合 Agent 上下文管理的第一性原则**少读、精读、按需读。 *坑 5简单任务也走两阶段 review可能成本过高subagent-driven-development对完全机械的任务也会触发“实现 → spec review → 修复 → code quality review → 再修复”的链条导致 token 和时间螺旋上升但输出质量未必提升。作者建议按任务复杂度分类机械任务轻量检查集成任务完整 review设计任务完整 review 并升级处理。因为工程流程不是宗教。流程的目的不是“显得专业”而是降低风险。对机械任务最好的 review 可能不是两个冷启动 Agent 反复审而是一个 deterministic diff check、lint、test 或 snapshot 校验。六、如何让用户显式调用 Superpowers而不是让它主动触发添加限制一个手动调用型 Skill 可以这样写--- name: superpowers-manual description: Manual entrypoint for Superpowers workflow. Use only when the user explicitly invokes this skill. disable-model-invocation: true --- 当用户显式调用本 Skill 时 1. 先询问任务目标、边界、成功标准 2. 判断任务属于 Fast / Skill / Full Superpowers 哪一档 3. 只有复杂任务才进入完整 brainstorming → plan → TDD → review 4. 简单任务直接建议使用 Fast Path然后用户通过 Slash 调用/superpowers-manual 帮我设计一个本地 AI 口播工具的 V1 版本所以对 Superpowers 这种插件型工作流我更推荐三种方式第一保留官方插件但在使用习惯上显式调用具体 Skill。比如/superpowers:brainstorming 先帮我拆方案 /superpowers:systematic-debugging 按根因排查这个问题 /superpowers:test-driven-development 用 TDD 实现这个函数第二**为自己的项目做一层“手动入口 Skill”**把它作为/sp或/superpowers-manual让它决定是否进入完整流程。第三**如果你强烈需要 opt-in 模式可以 fork 一份 Superpowers 或只复制需要的 Skills 到项目目录然后给它们加disable-model-invocation: true**。这样比在 prompt 里反复说“不要自动触发”更可靠。**想要显式调用就不要只靠提示词要在 Skill frontmatter、权限、插件管理、项目规范四层同时收口。 *七、写在最后如果你已经在用 Claude Code / Codex / Cursor并且想把 Superpowers 用得更稳以下是一些小的建议。1. 建立任务分级规则放在你的项目规范里Task Mode Policy: Fast Path: - typo - 文案 - 单文件小改 - 无业务风险的样式调整 直接完成不启用 Superpowers。 Skill Path: - debugging - test - code review - 小范围重构 显式调用对应 Superpowers Skill。 Full Superpowers: - 新功能 - 架构调整 - 多文件改动 - 高风险逻辑 - 需要设计确认的需求 必须先 brainstorming再 writing-plans再执行。2. 使用显式命令而不是期待自动触发/superpowers:brainstorming 先不要写代码帮我梳理这个需求 /superpowers:writing-plans 基于刚才确认的方案写执行计划 /superpowers:executing-plans 执行这个计划每一步完成后给验证证据 /superpowers:systematic-debugging 按根因分析这个 bug3. 给子 Agent 的任务里重复纪律你是子 Agent。执行本任务前必须检查适用 Skill。 如果涉及代码必须 TDD。 完成后必须提供验证证据。 不要因为任务看起来简单而跳过测试和 review。4. 对简单任务明确禁止过度流程这是 Fast Path 任务。不要 brainstorming不要 writing-plans不要启动 subagent。只做最小修改并说明改了哪里。当任务足够复杂时让 Agent 拥有 Superpowers。当任务只是改一个 typo 时让它闭嘴直接改。这才是效率和质量之间真正的平衡。