夜雨聆风
我给 AI 助手做了一次＂减肥手术＂——Claude Code Superpowers 技能优化实录
我让 AI 帮我改一行代码，它回我说：”要不要先做个头脑风暴？”
不是 AI 抽风了——是它每次开对话都自动加载了一整套开发流程，然后努力把所有任务都塞进这条流水线里。
这就是我决定优化 Superpowers 技能包的起点。Superpowers 是 Jesse Vincent（GitHub @obra）为 Claude Code 编写的一套提示词模板（Claude Code 叫它”Skills”），包含 13 个技能，覆盖从需求分析到代码交付的完整流程。设计很用心，GitHub 上也颇受欢迎。但实际用下来，我发现了一些值得改进的地方。
于是我花了一点时间，和 Claude 一起做了一次彻底的优化。过程中最大的收获不是”删了多少行”，而是一个认知：
优化 AI 的提示词，和优化代码遵循同样的原则——先改架构，再改实现。
第一层：什么时候加载？这才是最大的杠杆
原版 Superpowers 有一个核心设计：一个叫 using-superpowers 的”总调度”技能被配置为每次新建会话自动注入。
这意味着什么？无论你是启动一个复杂的开发项目、写一封邮件、还是随口问一个问题，AI 都会先加载整套 Superpowers 的调度逻辑，然后判断”这次要不要走 brainstorming → writing-plans → executing-plans 这条流水线”。
这个设计带来两个问题：
- 每次对话都额外消耗 Token
——加载调度指令本身就占上下文窗口，而大多数对话根本不需要走开发流程 - AI 对非编码任务也试图套用开发流程
——你让它帮忙写个邮件，它可能先问你”要不要做个头脑风暴”
优化方案很简单：改为按需调用。
using-superpowers 不再自动注入，只在用户明确启动开发类任务时才加载。日常对话、写作、调研等场景完全不受影响。
这一刀没有改动任何技能的内容，但可能是整个优化中收益最大的单一改动——因为它减少的不是几十行提示词，而是大量本不需要的完整调度周期。如果你每天开十几个新会话，其中大半是非开发任务，这一改动每天就省掉了十几次完全不必要的调度加载。
第二层：加载了什么？精简每个技能的内容
解决了”什么时候加载”的问题后，下一步是审视”加载了什么”。打开每个技能文件一看，发现不少内容对 AI 的实际执行帮助有限，但每次调用都要消耗 Token。
具体发现了什么？
大量”说服性”而非”指令性”的内容。举个例子，test-driven-development 这个技能原版 372 行，其中：
-
GraphViz 流程图：~30 行——图表是给人看的视觉辅助，AI 用文字描述的步骤就能理解流程 -
“Why Order Matters” 原理解释：~50 行——解释 TDD 为什么要先写测试。但 AI 不需要被说服，它只需要被告知”先写测试”就会照做 -
Rationalizations 表格 11 条 + Red Flags 13 条：~60 行——设计意图是防止 AI 跳步，但同样的效果用几条精炼规则就能达到
也就是说，一个技能里大约 40% 的内容属于”道理没错，但 AI 不需要这么多论证才能执行指令”的部分。
语气过于绝对，导致 AI 行为僵化。原版技能里有不少这样的措辞：
我理解作者的用意——AI 确实有”偷工减料”的倾向，强硬语气是为了对抗这种倾向。但副作用是：AI 要么完全遵守导致僵化（简单任务也走完整流程），要么在多条”NEVER”和”ALWAYS”相互冲突时无所适从。给出明确的条件判断效果更好：
一些设计假设和我的使用场景不匹配。原版作者是经验丰富的专业开发者，他的工作流很完整，但其中一些设定并不适合所有人：
-
默认使用 Git Worktree（高级分支隔离）——纯编码项目里很有价值，但我用这套技能也处理很多非编码工作（写报告、做调研、整理文档），这些场景下 Worktree 没有用武之地 -
每个任务强制两轮代码审查——大型项目的好习惯，但不是所有改动都需要这么重的流程 -
一些文化梗（比如 “Circle K” 便利店引用）——会心一笑，但对非北美用户来说莫名其妙
五条优化策略
1. 精简辅助性内容 — GraphViz 流程图、效果展示文案、统计数据、详细反面案例（保留核心警告）
2. 绝对语气改为条件判断 — “NEVER” 改为默认行为 + 明确的跳过条件
3. 强制依赖改为可选 — Git Worktree、双轮审查、固定文件路径，全部降级为”建议”
4. 统一术语 — “human partner” 统一为 “user”
5. 合并同类项 — 分散在多个表格里的 20+ 条注意事项，压缩为 3-6 条 “Essentials”
部分技能的优化对比：
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
第三层：缺了什么？发现流水线的结构性盲区
优化过程中还有一个意外收获。当我把 13 个技能按使用顺序排列出来后，发现了一个空缺：
| brainstorming |
|
writing-plans |
|
executing |
|
code-review |
|
finishing |
头脑风暴和写计划之间，没有调研环节。
原版的 brainstorming 技能直接从”问用户需求”跳到”提出方案”。也就是说，AI 全凭自己的训练数据在”闭门造车”。如果遇到它不熟悉的领域（比如某个冷门框架的最佳实践），它会硬编一个”看起来合理但实际可能过时”的方案。
于是我新增了一个 research 技能，插入到流水线中：
| brainstorming |
|
research |
|
writing-plans |
|
executing |
|
… |
research 技能的定位：不是学术论文式的深度研究，而是”动手之前先查一查”的轻量级验证。搜索官方文档确认 API 可用性、查看 GitHub Issues 排除已知坑、对比社区对同类方案的评价、验证版本兼容性。
它和另一个独立工具 syswebfetch（网页抓取）的关系是：research 负责”调研什么、怎么组织结论”，syswebfetch 是它的数据获取手段之一。research 是侦探，syswebfetch 是侦探手里的放大镜。
三层优化后的整体效果
|
|
|
回头看：Prompt 优化和代码优化是一回事
这次优化最大的认知收获是：优化 Prompt 和优化代码遵循完全相同的原则。
第一层：架构（什么时候加载）— 取消强制注入，按需调用。改动最小，收益最大。
第二层：实现（加载什么内容）— 精简每个技能的冗余内容。工作量最大，但单点收益不如第一层。
第三层：补全（缺了什么）— 发现并填补结构性盲区。这是优化过程中的意外收获。
就像代码优化一样——你可以花一周微调算法常数，但如果一开始就选错了数据结构，那些微调毫无意义。Prompt 优化也是：先确保技能在正确的时机加载，再去打磨内容。
另外几个具体心得
Prompt 也需要”代码审查”。我们通常只审查代码，不审查 Prompt。但技能文件本质上就是程序——它指挥 AI 如何行动。定期审查你的技能文件，问自己：这段话删掉后，AI 的行为会变差吗？如果不会，那就删。
通用工具要和专用流程分离。原版倾向于把所有技能串成一条严格的流水线。但调试、测试、并行分发这些技能其实是”通用工具”，应该在任何阶段都能独立调用。优化后我们把技能分成两类：
brainstorming → research → writing-plans → executing → finishing → code-review
systematic-debugging、test-driven-development、dispatching-parallel-agents、verification-before-completion
减少 Token 就是减少成本。Claude 按 Token 计费，技能内容在每次调用时都会注入上下文。优化后光是技能文件本身的 Token 消耗就减少了近 70%。积少成多，这是实实在在的钱。
最后
这次优化让我意识到：我们和 AI 助手的关系，越来越像管理一个团队。
你不会给团队成员发一份 50 页的操作手册——你会给出清晰的原则、合理的默认行为、以及何时可以变通的条件。对 AI 也一样。
如果你也在用 Claude Code 或类似的 AI 编程工具，不妨花点时间审视一下你的配置文件和技能文件。不是说要删掉一切，而是先问”加载时机对不对”，再问”加载内容精不精”。从架构到实现，和优化代码一个道理。