1. 从“给AI塞提示词”到“给AI装技能包”：superpowers到底在解决什么问题

大多数人用编码代理（coding agent）的姿势，还停留在“写一段超长提示词，把要求全塞进去，然后祈祷它别跑偏”。我早期也这么干，结果就是每次开新会话都要重新粘贴那一大坨上下文，代理该忘的还是忘，该跳步的还是跳步。superpowers 这个项目让我眼前一亮的点，不在于它又是什么“更强的模型”，而在于它换了个思路：不再靠提示词堆砌，而是把一套软件开发方法论拆成一个个可组合的技能（composable skills），让代理在需要的时候自己去调用。

说白了，superpowers 是一个面向编码代理的agentic skills framework。它把“怎么做一个合格的软件工程师”这件事，从模糊的提示词里抽出来，固化成一堆有名字、有触发条件、有执行步骤的技能模块。代理不再是“你让它干啥它干啥”的工具人，而是能在合适的时机主动加载对应技能，按方法论走完整个流程。

这套东西适合谁？如果你只是偶尔让代理补个函数、改个 bug，那可能感受不深。但如果你在用它做完整的功能开发、重构、调试、写测试，甚至管理一个多步骤的工程任务，那 superpowers 的价值就出来了——它解决的是代理行为的稳定性和可复现性问题。同一个任务，今天跑和明天跑，结果不会因为提示词措辞的微小差异而天差地别，因为方法论是固定的，技能是可复用的。

我先把核心概念理清楚，不然后面聊使用会晕。superpowers 里的“skill”不是模型权重那种东西，而是一段结构化的指令集，通常包含：这个技能叫什么、什么时候该用它、用的时候分几步、每步的产出是什么。代理在运行时，会根据当前任务上下文去匹配并加载相关技能。这跟传统“一次性把所有要求写进 system prompt”最大的区别在于：按需加载，上下文干净，方法论内聚。

关键词里提到的 composable skills，重点在“composable”。技能之间可以嵌套、可以串联。比如一个“实现新功能”的技能，内部会调用“写测试”的技能，而“写测试”又可能调用“分析现有代码结构”的技能。这种组合能力，才是它区别于普通提示词模板的地方。

2. superpowers 的技能体系长什么样：拆开看那些真正在干活的模块

2.1 技能不是功能列表，而是“行为契约”

很多人第一次接触 superpowers，会以为它是一堆“功能开关”，打开就能用。实际不是。每个 skill 更像是一份行为契约：它规定了代理在特定场景下必须遵守的步骤和产出标准。比如“调试”这个技能，它不会直接告诉你 bug 在哪，而是强制代理按“复现问题 → 缩小范围 → 提出假设 → 验证假设 → 修复 → 回归验证”这个链路走。你可能会说，这不就是常识吗？对，但问题在于，代理在没有约束的时候，经常跳过“复现”和“回归验证”，直接猜一个修复方案就交差了。技能的作用就是把这种“偷懒路径”堵死。

我实测下来，技能体系大致可以分成几类，虽然官方没有严格分类，但从使用场景看很清晰：

• 流程类技能：管的是“做事的顺序”，比如需求澄清、方案设计、任务拆解、实现、验证。这类技能解决的是代理“想到哪做到哪”的问题。
• 质量类技能：管的是“产出标准”，比如测试覆盖、代码审查、边界条件检查。这类技能解决的是代理“能跑就行”的敷衍心态。
• 分析类技能：管的是“理解现状”，比如读代码库结构、追踪调用链、识别依赖关系。这类技能解决的是代理“没看懂就动手”的毛病。
• 协作类技能：管的是“多步骤任务的状态管理”，比如记录当前进度、标记阻塞点、决定下一步该加载哪个技能。

2.2 几个高频技能的实际作用

我不可能把所有技能都列一遍，但有几个是日常使用中触发频率最高的，值得单独说。

需求澄清技能：这个技能会在你给出一个模糊需求时触发。比如你说“帮我加个登录功能”，它不会直接开始写代码，而是先反问：登录方式是什么？要不要记住登录状态？失败几次锁定？这些问题的答案会被记录下来，作为后续实现的约束。我一开始觉得这很烦，后来发现这一步省掉了大量返工。代理在没有澄清的情况下写出来的登录逻辑，十有八九跟你的预期对不上。

任务拆解技能：把一个中等复杂度的需求拆成可独立验证的小步骤。关键在于“可独立验证”——每一步做完都能跑一下、看一眼，而不是憋一个大招最后一起放。这个技能会输出一个任务列表，每个任务有明确的完成标准。我通常会把这份列表留着，作为后续检查代理有没有漏做的依据。

测试先行技能：这个技能强制代理在写实现之前先写测试。注意，不是“建议”，是“强制”。它会先根据需求生成测试用例，跑一遍确认失败（红），然后再写实现让测试通过（绿）。这个流程对代理来说其实挺反直觉的，因为模型天然倾向于直接给答案。但实测下来，走完这个流程的代码，边界条件处理明显更扎实。

代码审查技能：在实现完成后触发，代理会切换到一个“审查者”视角，重新读自己刚写的代码，检查命名、重复逻辑、错误处理、潜在的性能问题。这个技能最有意思的地方是，它会让代理“假装自己是另一个人”来挑毛病，实际效果比让它直接“再检查一遍”好得多。

2.3 技能是怎么被触发的

这是很多人困惑的点：技能是自动加载还是手动指定？答案是两者都有。superpowers 的设计里，代理会根据当前对话的上下文自动匹配技能，但你也可以显式要求“用测试先行的方式来做这个”。自动匹配的准确率取决于技能描述的清晰度，以及代理对当前任务的理解程度。我个人的经验是，在任务开始时给一个明确的意图说明，比如“这是一个新功能开发，需要完整流程”，比什么都不说直接扔需求，技能触发会准得多。

3. 把 superpowers 引入到你的工作流：从安装到跑通第一个技能

3.1 引入前的环境判断

在动手之前，先确认你的使用场景。superpowers 是给编码代理用的，所以你得有一个能跑代理的环境。不同的代理平台接入方式不一样，但核心逻辑是：把技能定义文件放到代理能读取的位置，并确保代理在运行时能加载它们。我见过有人直接把技能内容粘贴到对话里，这也能用，但失去了“按需加载”和“可组合”的优势，等于把框架降级成了提示词模板。

提示：如果你用的代理支持“项目级配置”或“自定义指令目录”，优先把技能放在那里，而不是每次对话手动粘贴。这样技能才能被自动索引和触发。

3.2 安装与配置的实操路径

具体步骤因平台而异，但通用流程是这样的：

1. 获取技能定义文件：superpowers 的技能通常以结构化文本形式存在，可能是 Markdown、YAML 或 JSON。你需要把这些文件放到一个代理能访问的目录里。
2. 配置代理的加载路径：在代理的配置文件里，指定技能目录的位置。有些平台叫“skills path”，有些叫“custom instructions directory”，本质一样。
3. 验证加载：开一个新会话，问代理“你现在有哪些可用的技能”。如果配置正确，它应该能列出技能名称和简要描述。如果列不出来，说明路径不对或者格式不被识别。
4. 触发第一个技能：给一个明确的任务，比如“我要给这个项目加一个配置读取模块，请按完整流程来做”。观察代理是否主动加载了需求澄清或任务拆解技能。

我踩过的一个坑是：技能文件的命名和格式必须严格符合平台要求。有一次我把技能描述写得太随意，代理虽然加载了，但触发条件匹配不上，等于白装。后来我把每个技能的描述改成“当用户要求 X 时使用本技能”这种明确句式，触发率立刻上来了。

3.3 第一次跑通完整流程的体验

我第一次完整跑 superpowers 流程，是给一个已有项目加缓存层。需求本身不复杂，但涉及多个模块的改动。代理先触发了需求澄清，问了我几个问题：缓存粒度是什么？失效策略用哪种？要不要处理缓存穿透？我回答之后，它生成了一个任务列表，然后按顺序执行：先写测试，再改接口，再加实现，最后跑回归。整个过程我没有干预，只在它问问题时回答。最终产出比我预期要完整，尤其是边界条件的测试用例，有几个是我自己都没想到的。

但也不是没有槽点。技能加载会消耗额外的上下文，如果任务本身很简单，走完整流程反而显得笨重。我的做法是：小改动直接指定“跳过流程技能，只做实现”，大任务才启用完整技能链。

4. 让技能真正好用的几个关键设置：触发条件、组合方式与上下文管理

4.1 触发条件写得好，技能才不会被“雪藏”

技能能不能被用起来，八成取决于触发条件写得清不清楚。我见过太多人装了一堆技能，结果代理从来不用，原因就是触发描述太模糊。比如“用于代码相关任务”这种描述，等于没写。好的触发条件应该包含场景信号和动作意图。举个例子：

• 差的写法：“当需要测试时使用。”
• 好的写法：“当用户要求新增功能、修改现有行为，且尚未编写对应测试时，在开始实现之前使用本技能。”

后者明确了“什么时候”和“在哪个步骤之前”，代理匹配起来就准得多。我自己的习惯是，每装一个新技能，先手动测试三次不同措辞的请求，看它能不能稳定触发。如果三次里只触发一次，我就回去改描述。

4.2 技能组合的两种模式：串联与嵌套

composable skills 的“组合”有两种常见模式，用对了效率翻倍，用错了互相打架。

串联模式：技能按顺序依次执行，前一个的输出是后一个的输入。比如“需求澄清 → 任务拆解 → 测试先行 → 实现 → 代码审查”。这种模式适合流程明确的任务，每个技能只管自己那一段。

嵌套模式：一个技能在执行过程中调用另一个技能。比如“实现功能”这个技能内部，在需要写测试时调用“测试先行”技能，写完后再回到主流程。这种模式适合技能之间有依赖关系的场景。

我遇到过一个坑：两个技能都试图控制“任务拆解”这一步，结果代理在两者之间反复横跳，浪费了大量上下文。后来我把其中一个技能的触发条件改窄，明确它只在“重构场景”下使用，冲突就消失了。所以组合技能时，一定要检查触发条件有没有重叠。

4.3 上下文预算：别让技能把窗口吃光

技能定义本身是要占上下文的。如果你装了二三十个技能，每个都几百字，光技能描述就可能吃掉大量窗口。我的做法是分层管理：

• 常驻技能：最核心的三到五个，比如需求澄清、任务拆解、测试先行，始终加载。
• 按需技能：特定场景才用的，比如性能分析、安全审查，只在相关任务开始时手动加载。
• 归档技能：很久不用的，直接移出加载路径，需要时再放回来。

另外，技能执行过程中的中间产出也要控制。比如任务列表，如果每一步都保留完整历史，上下文会迅速膨胀。我通常让代理只保留当前步骤和下一步，已完成的步骤压缩成一行摘要。

5. 实测中容易踩的坑：从技能不触发到流程僵化

5.1 技能装了但代理“视而不见”

这是最高频的问题。原因通常有三个：路径不对、格式不识别、触发条件太模糊。排查顺序建议从路径开始，确认代理能读到文件；然后检查格式，有些平台对技能文件的字段名有严格要求；最后才是改触发描述。我自己的排查清单是这样的：

5.2 流程走得太死，简单任务被拖慢

superpowers 的方法论是好的，但不是所有任务都值得走完整流程。我一开始有点“强迫症”，什么任务都启用全套技能，结果改一行配置也要走需求澄清和任务拆解，效率反而低了。后来我给自己定了个规则：改动涉及三个以上文件，或者需要新增测试的，走完整流程；否则只加载实现和验证技能。这个阈值可以根据你的项目复杂度调整。

5.3 技能版本更新后的兼容问题

技能定义不是一成不变的，你可能会根据项目需要修改它们。修改之后，之前跑通的任务可能会出问题。我的经验是，每次改完技能，拿一个之前跑过的简单任务回归一遍，确认流程没断。另外，如果你在团队里共享技能配置，一定要版本化，不然别人拉到的技能和你的不一致，结果对不上。

6. 把 superpowers 用出复利：从单次任务到可积累的工程习惯

6.1 技能库的沉淀比单次使用更重要

superpowers 真正有价值的地方，不是某一次任务跑得多漂亮，而是你可以在使用过程中不断沉淀自己的技能库。每次遇到一个代理容易犯错的场景，就把它固化成一个技能。比如我发现代理经常在改接口时忘记更新调用方，就写了一个“接口变更检查”技能，强制它在改完接口后搜索所有调用点。这种技能一旦沉淀下来，后面所有任务都受益。

我现在的技能库里，大概有三分之一是官方或社区提供的通用技能，三分之二是我根据自己项目特点定制的。定制技能不需要写得多复杂，关键是触发条件要精准，步骤要可执行。

6.2 用技能来对齐团队协作标准

如果你在团队里用编码代理，superpowers 还有一个隐藏价值：它可以把团队的工程标准变成可执行的技能。比如“所有新增函数必须有对应的单元测试”“数据库变更必须附带回滚脚本”，这些规范写在文档里没人看，但写成技能后，代理会在执行时强制检查。我试过把团队的代码审查清单做成一个技能，代理在提交前会自动过一遍，漏项明显少了。

6.3 我个人的使用节奏

最后分享一点我自己的使用节奏。我不会在所有任务上都开 superpowers，而是分三档：

• 轻量档：只加载实现和验证技能，适合改 bug、调参数、写小函数。
• 标准档：加载需求澄清、任务拆解、测试先行、实现、审查，适合新功能开发。
• 重载档：在标准档基础上加性能分析、安全审查、文档生成，适合核心模块或对外接口的改动。

这个分档不是固定的，你可以根据自己的项目阶段调整。关键是别让框架变成负担，它应该是帮你省事的，不是给你添流程的。我见过有人把 superpowers 用成了“必须走完所有步骤”的教条，结果代理累、人也累，那就本末倒置了。

技能这东西，装得多不如装得准，触发得频繁不如触发得恰当。先把三五个核心技能跑顺，再慢慢扩展，比一上来就搞一大套要靠谱得多。