Claude Code 的插件系统让社区可以把"工作方法"打包成可安装的增强包。以 `superpowers` 插件为例,它在 Agent 的工作流程中注入了任务拆解、执行反思和结果复盘三个环节,让 Agent 不只是"写完代码",而是"有方法地写代码"。但插件不是万能的——它补强了思考流程,却不能替代代码阅读、测试验证和项目事实检查。

插件使用技巧:以 superpowers 为例增强任务拆解、反思和复盘

Claude Code 的插件系统让社区可以把"工作方法"打包成可安装的增强包。以 superpowers 插件为例,它在 Agent 的工作流程中注入了任务拆解、执行反思和结果复盘三个环节,让 Agent 不只是"写完代码",而是"有方法地写代码"。但插件不是万能的——它补强了思考流程,却不能替代代码阅读、测试验证和项目事实检查。

一、插件 vs Skill vs 项目规则

维度 项目规则 (CLAUDE.md) Skill 插件 (Plugin)
作用 全局约束 标准工作流 增强工作方法
粒度 一行一条规则 完整流程 多个 Skill + Hook + Agent
触发 始终生效 按需调用 安装后自动生效
可复用 项目内 跨项目 跨项目,可发布
示例 "使用 pnpm" "数据库迁移审查" superpowers(任务拆解+反思+复盘)

插件 = Skill 集合 + Hook 集合 + Agent 定义 + MCP Server(可选)

二、superpowers 插件架构

text
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 安装前的评估

yaml
# 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 权限审查表

yaml
# 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

yaml
# 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

yaml
# 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 会话复盘

yaml
# 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 如何分工