插件使用技巧:以 superpowers 为例增强任务拆解、反思和复盘
Claude Code 的插件系统让社区可以把"工作方法"打包成可安装的增强包。以
superpowers插件为例,它在 Agent 的工作流程中注入了任务拆解、执行反思和结果复盘三个环节,让 Agent 不只是"写完代码",而是"有方法地写代码"。但插件不是万能的——它补强了思考流程,却不能替代代码阅读、测试验证和项目事实检查。
一、插件 vs Skill vs 项目规则
| 维度 | 项目规则 (CLAUDE.md) | Skill | 插件 (Plugin) |
|---|---|---|---|
| 作用 | 全局约束 | 标准工作流 | 增强工作方法 |
| 粒度 | 一行一条规则 | 完整流程 | 多个 Skill + Hook + Agent |
| 触发 | 始终生效 | 按需调用 | 安装后自动生效 |
| 可复用 | 项目内 | 跨项目 | 跨项目,可发布 |
| 示例 | "使用 pnpm" | "数据库迁移审查" | superpowers(任务拆解+反思+复盘) |
插件 = Skill 集合 + Hook 集合 + Agent 定义 + MCP Server(可选)
二、superpowers 插件架构
superpowers 插件结构:
┌────────────────────────────────────────────────────┐
│ superpowers │
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ Hook 层(自动注入工作节奏) │ │
│ │ │ │
│ │ PreTaskExecution → 任务拆解检查 │ │
│ │ PostTaskExecution → 执行反思 │ │
│ │ SessionEnd → 会话复盘 │ │
│ └──────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ Skill 层(可复用的工作方法) │ │
│ │ │ │
│ │ task-breakdown → 任务拆解方法论 │ │
│ │ reflection → 执行后反思 │ │
│ │ retrospective → 会话级复盘 │ │
│ │ decision-log → 决策记录 │ │
│ └──────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ Agent 层(专门的子 Agent) │ │
│ │ │ │
│ │ reflect-agent → 反思分析 Agent │ │
│ │ planner-agent → 任务规划 Agent │ │
│ └──────────────────────────────────────────────┘ │
│ │
│ plugin.json → 元数据、权限、依赖 │
└────────────────────────────────────────────────────┘三、插件评估清单
3.1 安装前的评估
# plugin-evaluation-checklist.yaml
# 在安装任何插件前,先过一遍这个清单
evaluation:
pre_install:
- question: "插件解决了什么具体问题?"
required: true
note: "如果说不清问题,就不需要插件"
- question: "这个问题能靠 Skill 或项目规则解决吗?"
required: true
note: "如果能,就不需要插件的复杂性"
- question: "插件的权限范围是什么?"
required: true
note: "检查是否有不必要的权限(如不需要网络但申请了 network access)"
- question: "插件是否开源?代码可审查吗?"
required: true
note: "不开源的插件不应该在生产环境使用"
- question: "插件的维护活跃度如何?"
required: false
note: "最后更新超过 3 个月的插件可能有兼容性风险"
- question: "插件和其他已安装的插件有冲突吗?"
required: true
note: "两个插件都注入 PreTaskExecution Hook 可能会冲突"
post_install:
- question: "插件的功能可以验证吗?"
note: "执行一个简单任务,观察插件的注入效果"
- question: "插件增加了多少 Token 开销?"
note: "对比安装前后的 Token 使用量"
- question: "插件的 Hook 是否影响了已有工作流?"
note: "检查是否有意外行为"3.2 权限审查表
# plugin-permission-audit.yaml
superpowers_audit:
# 插件声明的权限
declared_permissions:
- "hook:PreTaskExecution" # 任务执行前注入
- "hook:PostTaskExecution" # 任务执行后注入
- "hook:SessionEnd" # 会话结束注入
- "agent:reflect-agent" # 子 Agent 定义
- "agent:planner-agent" # 子 Agent 定义
# 权限评估
assessment:
hooks:
risk: "LOW"
reason: "Hook 只注入文本提示,不执行文件操作或命令"
agents:
risk: "MEDIUM"
reason: "子 Agent 可以调用工具,需要确认其工具范围"
file_access:
risk: "NONE"
reason: "插件不直接读写文件"
network_access:
risk: "NONE"
reason: "插件不需要网络访问"
# 最终结论
verdict: "APPROVE"
notes: "权限范围合理,Hook 只做提示注入,无副作用风险"四、核心功能解析
4.1 任务拆解 Hook
# superpowers-task-breakdown.yaml
hook:
type: "PreTaskExecution"
trigger: "task.estimated_complexity >= 'MEDIUM'"
prompt_injection: |
## 任务拆解检查
在开始执行之前,请先完成以下拆解步骤:
1. **目标澄清**:用一句话描述"做完这件事后,什么是不同的?"
2. **步骤分解**:把任务拆成 3-7 个独立步骤,每个步骤可以独立验证
3. **风险预判**:每个步骤可能的失败点是什么?
4. **验证标准**:每个步骤完成的标志是什么?
请以以下格式输出拆解结果:
```
目标:[一句话]
步骤:
1. [步骤名] → 验证标准:[什么算完成] → 风险:[可能出错的地方]
2. ...
依赖关系:[步骤之间的先后依赖]
```
拆解完成后再开始执行。4.2 执行反思 Hook
# superpowers-reflection.yaml
hook:
type: "PostTaskExecution"
trigger: "task.completed OR task.failed"
prompt_injection: |
## 执行反思
任务执行完毕后,请反思以下问题:
1. **结果评估**:任务完成了吗?完成度是多少?
2. **方法评估**:执行过程中有没有走弯路?有没有更好的方式?
3. **意外发现**:过程中有没有发现之前不知道的信息?
4. **可复用性**:这次的解法能复用到其他类似任务吗?
如果任务失败了,额外反思:
- 失败的根本原因是什么?(不是表面原因)
- 如果重新来一次,你会怎么做?
- 需要什么额外信息才能成功?
把反思结果记录到 `.agent-logs/reflection-{date}.md`。4.3 会话复盘
# superpowers-retrospective.yaml
hook:
type: "SessionEnd"
prompt_injection: |
## 会话复盘
本次会话即将结束。请总结以下内容:
### 完成的任务
- [列出完成的任务和关键成果]
### 未完成的任务
- [列出未完成的任务和原因]
### 学到的经验
- [列出本次会话新发现的项目知识、技术细节或工作模式]
### 建议的后续行动
- [列出下次会话应该优先处理的事项]
把复盘结果保存到 `.agent-logs/retro-{date}.md`。五、插件的适用边界
5.1 插件擅长的事
| 场景 | 插件如何帮助 |
|---|---|
| 复杂任务容易遗漏步骤 | 任务拆解 Hook 强制分步 |
| 犯过的错误重复犯 | 反思日志记录经验,后续会话可参考 |
| 团队工作方法不统一 | 插件统一工作节奏(拆解→执行→反思) |
| 会话结束知识丢失 | 复盘日志保留上下文 |
5.2 插件不能替代的事
| 场景 | 为什么插件不够 |
|---|---|
| 代码阅读理解 | 插件只能提示"要读代码",不能替 Agent 读 |
| 测试验证 | 插件不能替 Agent 运行测试 |
| 项目事实检查 | 插件不知道项目的具体实现细节 |
| 安全审计 | 插件不做安全扫描,需要专门的 Skill 或工具 |
六、真实经验与踩坑
6.1 Hook 注入太多会降低效率
场景:安装了 superpowers 后,每次任务执行前都会注入 500 字的"任务拆解检查"提示。
问题:对于简单任务(如修改一个 CSS 颜色),这个提示是多余的。Agent 花了额外的 Token 去"拆解"一个不需要拆解的任务,反而更慢了。
解决方案:Hook 的触发条件设置为 task.estimated_complexity >= 'MEDIUM'——简单任务不注入拆解提示。或者让 Agent 自行判断是否需要拆解:"如果任务可以在 1 个步骤内完成,跳过拆解。"
6.2 反思日志不能被遗忘
场景:superpowers 把反思结果写到 .agent-logs/,但后续的 Agent 会话没有读取这些日志。
问题:反思的价值在于"下次不再犯同样的错"。如果日志写了但没人看,反思就白费了。
解决方案:在 CLAUDE.md 中增加规则:"每次会话开始时,读取最近 3 天的 .agent-logs/reflection-*.md,作为经验参考。" 同时控制日志大小——只记录"有价值的反思",不是每次都强制反思。
6.3 插件和 Skill 可能冲突
场景:同时安装了 superpowers 和一个"代码审查"Skill。两者的 PostTaskExecution Hook 都在任务完成后注入提示。 问题:Agent 收到两个互相冲突的指令——superpowers 说"反思执行结果",代码审查 Skill 说"检查代码质量"。Agent 不知道该优先做哪个。 解决方案:明确 Hook 的优先级。superpowers 的反思是通用的("做得怎么样"),代码审查是具体的("代码质量如何"),两者可以合并成一个提示。在插件文档中注明与其他常见插件的兼容性。
七、参数说明表
| 参数 | 类型 | 默认值 | 说明 |
|---|---|---|---|
plugin_name |
string | 必填 | 插件名称 |
install_source |
string | 必填 | 安装来源(GitHub / registry) |
enabled_hooks |
list | 全部 | 启用的 Hook 列表 |
enabled_skills |
list | 全部 | 启用的 Skill 列表 |
complexity_threshold |
string | "MEDIUM" |
Hook 触发的最低复杂度 |
reflection_log_path |
string | ".agent-logs/" |
反思日志路径 |
max_log_retention_days |
int | 30 |
日志保留天数 |
token_budget_per_hook |
int | 500 |
每个 Hook 注入的最大 Token |
auto_update |
bool | false |
是否自动更新插件 |
disallowed_tools |
list | [] |
禁止插件使用的工具 |
八、落地检查清单
- 插件解决的问题已明确,不是"看着酷"才安装
- 插件的权限范围已审查,无不必要权限
- 插件源码可审查(开源)
- 和已有插件/Skill 的兼容性已确认
- Hook 的触发条件合理(不会在简单任务上浪费 Token)
- 反思日志的读取机制已配置(不只是写)
- 插件的 Token 开销可接受(< 日常使用的 10%)
- 失败回退策略已明确(插件禁用后的替代方案)
- 插件维护者活跃,最后更新 < 3 个月
- 敏感上下文不会被插件泄露(检查网络访问权限)
九、系列导航
上一篇:Skill 使用实战:把团队经验沉淀成 Agent 可执行的工作方法 下一篇:Agent 团队使用规范:开发者、Reviewer、Tech Lead 如何分工