不是能力，而是分发形态：Claude Code Plugins 分层梳理

本文的目标不是整理 awesome list，而是给出一套判断框架：什么样的 Claude Code 扩展，真的值得被做成 plugin？

为什么要重新梳理 Claude Code Plugins

比如说下面这些

开发工程类：feature dev、backend/frontend、API、AI engineering、legacy modernization。
代码质量/测试类：code review、test writer/fixer、performance benchmark、bug detective、API testing。
Git / PR 工作流：commit、push、PR creation、PR review、branch naming、issue resolve。
DevOps / automation：CI/CD、deploy、infra、Husky hooks、serverless、cloud workflows。
数据/数据库类：SQL、BigQuery、ClickHouse、CockroachDB、analytics reporter、data scientist。
设计/UX 类：UI designer、UX researcher、mobile UX、brand guardian。
安全/合规类：security audit、API security、secrets/SAST/IaC、SOC2/GDPR/HIPAA automation。
项目/产品管理类：PRD、planning、sprint prioritizer、roadmap、workflow optimizer。
营销/增长/内容类：content creator、growth hacker、social channel agents。
这些分类在 awesome-claude-code-plugins 和 Chat2AnyLLM 的索引里都能看到类似结构。

这些在我看来大部分的最佳形态都应该作为 skills，部分应该作为MCP （事实上也是如此），而非作为 plugins

对 Claude Code Plugins 的 2 点核心认知

1、Plugin 不是能力，而是分发与组合形态

Plugin 不是一种能力本身。一个 plugin 可以包含 skills、slash commands、agents、hooks、MCP servers、LSP servers、monitors、CLI、Web UI 等多种组件。所以我们不该只问 "这个 plugin 能做什么？"，更该问 "它里面真正的能力单元是什么？为什么需要被打包成 plugin？"

如果一个扩展只是封装了一段 prompt，它更像 skill。如果只是连接外部系统，它更像 MCP server。如果只是一个专家角色，它更像 subagent。如果只是一个本地导出工具，它可能只是 CLI。只有当它组合多个能力，且需要跨项目复用、自动触发、版本化和治理时，plugin 才是最自然的形态。

Claude Code Plugin 的价值，不在于"让 Claude 多一个技能"，而在于"把一组能力产品化成一个可复用、可安装、可维护的工作流"。

2、场景分类 ≠ 形态分类

关键判断： 后一组更天然适合 plugin，因为它们往往需要跨项目安装、带多个组件、接管生命周期，而不是单次可调用的能力包。

但要加一个限定：

后一组（Task Graph / Session History / Export / Replay / Memory / Observability / Guardrails / Model Routing）天然更适合作为 "plugins / plugin bundle"；前一组（code review / test writer / PR / DevOps / DB / 设计/安全等）大部分天然更适合作为 "skills / MCP / subagents"，只有在需要组合、分发、自动化时才应该升级成 plugin。

所以更准确的分法是：

Skills = 可调用的认知/流程能力
比如 code review、写测试、生成 PRD、做 API design、写 migration plan。

MCP = 给 Claude 接外部世界的工具接口
比如 GitHub、Linear、Jira、DB、Figma、Slack、Sentry、Notion、浏览器、内部系统。官方也把 MCP 描述成连接外部服务和工具的方式。(Claude)

Hooks = 生命周期自动化
比如 SessionStart 注入上下文、PreToolUse 拦截危险命令、PostToolUse 记录文件变更、SessionEnd 导出总结、PreCompact/PostCompact 做记忆压缩。官方 hook 事件覆盖 session start/end、tool use 前后、compact 前后、file change、config change、subagent start/stop 等，这正好对应"管理 Claude Code 作为长期 agent"的场景。(Claude)

Plugin = 把上面这些打包成一个可安装、可更新、可共享的产品
官方说 plugins / marketplaces 负责 package and distribute 这些 features。(Claude)

---

因为现在很多 repo 会把三种东西都叫 plugin：

1. 真正的 plugin bundle
   有 .claude-plugin/plugin.json，里面打包 skills/hooks/MCP/agents/LSP 等。

2. 可被 Claude Code 使用的工具
   比如 CLI、dashboard、exporter、memory daemon，本身不是 plugin，但很容易被 plugin 包一层。

3. Claude Code 工作流资产
   比如 commands、agents、skills、CLAUDE.md 模板、hooks 片段，也被 marketplace 收录为 plugin。

这会导致“plugin”这个词在生态里同时表示：

• 安装包；
• 能力；
• 工具；
• 工作流；
• marketplace item；
• agent harness 的一部分。

所以高质量分类不应只问"它是不是 plugin"，而应拆成两轴：

我建议的二维分类

A 轴：用户场景

1. Planning / Task Graph
2. Session History
3. Session Export
4. Session Replay / Migration
5. Persistent Memory
6. Usage / Cost Observability
7. Lifecycle Automation / Guardrails
8. Context Engineering / CLAUDE.md / Rules
9. External Integrations
10. Code Intelligence
11. Agent Orchestration
12. Coding Workflows

B 轴：最佳形态

1. Skill
2. Subagent
3. MCP
4. Hook
5. LSP
6. Monitor
7. Standalone CLI
8. Daemon / Web UI
9. Plugin bundle
10. Marketplace

这样就能避免错位。比如：

场景	最小形态	产品化形态
code review	skill	plugin with skill + subagents
GitHub PR	MCP	plugin with MCP + PR skills
export markdown	CLI / command	plugin with /export + SessionEnd hook
memory	daemon + storage	plugin with hooks + MCP + viewer
task master	local task DB + MCP	plugin with skills + MCP + hooks
history dashboard	standalone web app	plugin with hooks + commands + viewer launcher
LSP/code intelligence	LSP config	official-style LSP plugin
guardrails	hook	policy plugin

官方文档里的组合示例也支持这种 mental model：skill 负责 workflow，MCP 负责连接外部系统，hook 负责自动触发，subagent 负责隔离执行，plugin 负责打包分发。(Claude)

---

很多 plugin 索引按"开发工程 / 代码质量 / Git/PR / DevOps / 数据"等场景分类。这些分类本身没错，但容易掩盖一个事实：很多"能力型插件"的最佳形态不是 plugin，而是 skill、MCP、subagent 或 hook。 code review 更像 skill，test writer 更像 subagent，PR creation 更像 skill + GitHub MCP，数据分析更像 skill + database MCP。只有当这些能力需要被组合、分发、自动触发、跨项目复用、版本化和团队治理时，才应升级成 plugin。

本文真正关注的是另一类扩展——它们不是让 Claude 多做某一类工程任务，而是让 Claude Code 作为长期 agent 工作台变得更强。我把这类扩展叫做 Agent Operating Layer：任务管理、session 恢复与浏览、历史导出与归档、session 迁移、长期记忆、token 和成本追踪、生命周期 hooks、运行时 guardrails——让 AI coding workflow 可观测、可恢复、可治理。这类扩展天然更适合 plugin bundle。

形态分类一览：一个扩展到底该做成什么？

在讨论具体场景前，先建立一个判断矩阵。下表回答了"一个扩展的不同形态分别适合解决什么问题"，以及"反向查询"——当你有一个想法时，应该先用哪个问题判断它是否属于某类形态。

形态	适合解决	判断问题（反向查询）
Skill	封装流程、规范、判断标准、输出格式	只是封装一套提示词或流程规范？
Slash Command	显式触发的重复动作	只是提供一个手动触发的快捷命令？
Subagent	专家角色、隔离上下文、分工协作	需要专家角色或上下文隔离？
MCP Server	连接外部系统、工具、数据源	需要访问外部系统或数据源？
Hook	生命周期自动化、拦截、记录、注入	需要在 CC 生命周期中自动触发？
LSP Server	语言智能、诊断、跳转、代码理解	需要语言诊断或代码智能？
Monitor	运行时观测、策略检查、状态追踪	需要运行时观测或策略检查？
CLI / Web UI	本地工具、dashboard、导出器、viewer	只是本地文件处理或统计？
Plugin Bundle	组合多个组件后的产品化形态	需要组合多组件、跨项目安装、版本化分发？
Marketplace / Team	组织级统一分发、权限治理	需要组织内统一安装升级和权限治理？

一句话判断：如果它只有一个能力单元，先不要叫 plugin。如果它组合了多个能力单元且需要跨项目分发和生命周期集成，再考虑 plugin。

真正适合 Plugin 的场景

这一节只讨论我眼中天然更适合以 plugin / plugin bundle 形态存在的场景。

它们的共同点是：不是提供某个技能，而是改造 Claude Code 的工作台能力。

或者说，不提供“业务能力”，而是对 cc本身赋能。因为业务能力更应该面向项目，而通用能力的切面更大，使用频率更高，也就更应该作为plugins

这 7 类场景之间有一条清晰的逻辑链：

1. Task Graph — 入口：把需求变成可执行的任务结构；
2. Session History & Export — 回溯 + 沉淀：让历史 session 可查、可搜、可导出；
3. Session Replay / Migration — 迁移：让 session 跨环境打包、复现、恢复；
4. Persistent Memory / Knowledge Base — 记忆：把历史压缩成未来可用的上下文；
5. Usage / Cost Observability — 观测：量化 token、成本和使用模式；
6. Lifecycle Hooks / Guardrails — 治理：在关键生命周期节点自动执行校验和拦截；
7. Model Routing — 调度：根据任务类型自动选择最合适的模型。

前三类构成 "执行 → 回溯 → 沉淀" 的工作流闭环；中间三类构成 "记忆 → 观测 → 治理" 的基础设施层；Model Routing 是 "调度层"。三层合在一起，就是本文所说的 Agent Operating Layer。

---

1、Task Graph / PRD Planning：从需求到任务图

把 PRD 拆成可执行、可追踪、可跨 session 继续的任务图——不只是 TODO 列表，而是 AI coding 的入口基础设施。

这个分类解决什么 + 今天是否还有意义？

这类插件解决的是 AI coding 的入口问题。我们缺的不是"会写代码的模型"，而是能把需求拆成任务、依赖、执行顺序和状态的系统。典型问题包括：PRD 太长不知道怎么拆、任务间有依赖但 AI 跳步、做到一半不知道当前状态、多 session 间缺少连续性。今天仍然非常有意义——任务越大，越需要拆解、依赖管理和状态恢复。

更匹配什么形态？

最小形态可以是 skill（/parse-prd、/next-task），但一旦需要维护任务状态、依赖关系、子任务和数据执行历史，就不再只是 skill。完整的形态是 plugin bundle：skills 负责 PRD 解析和任务拆分，commands 负责用户交互，local storage 保存状态，MCP server 暴露给 Claude Code，hooks 在 session start/end 同步任务状态，可选的 Web UI 浏览任务图。

工具对比

为什么选这些维度？因为 Task Graph 类工具的核心差异不在于"能不能拆 PRD"（这是基础能力），而在于是否维护任务状态、是否支持跨 session 延续、是否与 Claude Code 执行过程联动。

#  一个专为 AI 编码环境打造的AI 驱动任务管理系统，可以直接“丢进” Cursor、Windsurf、Lovable、Roo、VS Code 等编辑器里使用。它能把 PRD（产品需求文档）自动拆成结构化任务，支持任务跟踪、依赖管理、子任务、研究集成等，完全在 AI 聊天窗口里操作。
- name: claude-task-master
  url: https://github.com/eyaltoledano/claude-task-master
  任务状态持久化: ✅ 本地文件存储 + 任务 ID
  跨 session 继续: ✅ /continue 恢复任务图
  依赖管理: ✅ 父子任务 + 前置依赖
  MCP 暴露: ✅ MCP server 集成
  Web UI: ❌ 纯 CLI
  推荐度: 高

- name: "/generate-tasks (手写 skill)"
  任务状态持久化: ❌ 仅 Markdown 输出
  跨 session 继续: ❌ 需手动保存
  依赖管理: ❌ 无结构化依赖
  MCP 暴露: ❌
  Web UI: ❌
  推荐度: 低（适合轻量场景）

我的判断

如果只是"帮我把 PRD 拆成 Markdown TODO"，skill 就够了。但如果它能形成稳定任务图且贯穿多个 session，就非常适合 plugin 化。关键判断标准：是否有任务状态？是否有依赖关系？是否支持跨 session 继续？是否能和执行过程联动？

---

2、Session History & Export：从回溯到沉淀

---

合并为一个逻辑链——先让历史可查可搜，再把有价值的对话沉淀成文档资产。

这个分类解决什么 + 今天是否还有意义？

Claude Code session 本质上是长期工作流的一部分，但默认情况下历史 session 不易浏览、不易搜索、不容易按项目筛选、不容易恢复。Session History 解决的是"如何让过去的 session 变成可浏览、可检索、可继续的工作资产"。Session Export 进一步解决"如何把 session 中的需求讨论、设计决策、调试过程、代码解释等有价值信息，从临时对话变成可保存、可分享、可复盘的文档资产"。

今天仍然有意义，但价值正在从"看历史"转向 session retrieval / audit / resume。如果只是偶尔看一下历史，简单 viewer 就够了；如果长期高频使用，需要的是按项目搜索、关联文件变更、关联 token 成本、自动归档、支持 resume。

更匹配什么形态？

历史浏览的最小形态是 standalone Web UI（读取 ~/.claude/ 的 JSONL 提供本地 dashboard），导出则是最小形态 CLI。但当需要深度集成时，plugin bundle 更合理：

• SessionStart hook：记录当前 session
• SessionEnd hook：生成摘要或自动归档
• PostToolUse hook：记录文件变更
• command：快速打开当前项目历史
• local index：做全文搜索
• Web UI：浏览多项目历史

简单导出适合 CLI，自动归档和知识沉淀适合 plugin bundle。

工具对比

为什么选这些维度？因为历史工具的核心竞争力已从"能不能读取 JSONL"转向"搜索能力、实时性、token 追踪、resume 支持"。这四个维度决定了它是 viewer 还是 session retrieval layer。

- name: cchistory
  搜索/筛选: ✅ 多项目筛选 + 搜索
  实时更新: ✅ WebSocket
  Token tracking: ✅ 内置
  Resume 支持: ✅ 生成恢复命令
  安装方式: Go 二进制 / 源码
  推荐度: 高

# 轻量 Claude Code 历史 Web 浏览器，读取 ~/.claude/，有 session list/project filter/resume command/SSE 实时更新，默认 localhost:12001。
- name: claude-run
  url: https://github.com/nilbuild/claude-run
  搜索/筛选: ✅ 项目筛选
  实时更新: ✅ SSE
  Token tracking: ❌
  Resume 支持: ✅ 生成恢复命令
  安装方式: Rust 二进制
  推荐度: 中高

- name: claude-code-history
  搜索/筛选: ✅ 项目浏览
  实时更新: ❌
  Token tracking: ❌
  Resume 支持: ❌
  安装方式: PyPI (pip install)
  推荐度: 中

# Python CLI 工具，将 Claude Code session JSONL 导出为 Markdown，支持 --list/--latest/按 title 选 session/--all 批量导出。
# - url: https://github.com/odysseus0/ccexport
# des: 极简 Python CLI，导出 Claude Code 最近 session 为 Markdown，只保留 user/assistant 对话，过滤 tool calls 和 thinking。
- name: cc2md / ccexport (导出类)
  url: https://github.com/magarcia/cc2md
  搜索/筛选: ❌ 仅清单
  实时更新: ❌
  Token tracking: ❌
  Resume 支持: ❌
  安装方式: CLI (Python/Go)
  推荐度: 中（轻量导出场景）


#  - claude-run：只支持 Claude Code，定位是本地历史 Web UI；README 没看到 Markdown export。
#  - agent-thread：支持 Claude Code 和 Codex session discovery/export，但默认是上传到 hosted/public share service；README 明确说会上传 raw transcript，隐私风险很大。它适合“分享session 链接”，不适合默认塞进 Linear。
#  - codiedev：靠 Claude SessionEnd / Codex Stop hook 捕获到云端，和我们刚刚移除 hook 的方向冲突。
#  - tokenjuice：是 terminal output compactor/hook integration，不是 session history ->Markdown exporter。

我的判断

History 类工具容易同质化——单纯"读取 JSONL 展示聊天记录"的价值有限。更值得关注的是能搜索、能筛选项目、能关联文件、能看到 tool calls、能继续 session、能导出、能和 memory 结合的深度工具。如果只是 viewer，它是 nice-to-have；如果能成为 session retrieval layer，它就非常值得 plugin 化。

Export 同理。三档价值：简单导出（轻量 CLI 即可）、结构化归档（开始值得 plugin 化）、可恢复可搜索的 session archive（最有价值，把导出从一次性动作变成知识资产系统）。

---

3、Session Replay / Migration：让 session 可迁移、可复现

不只导出对话，而是打包 session + 文件 + 状态 + 恢复逻辑。

这个分类解决什么 + 今天是否还有意义？

Export 解决的是"把会话保存下来"，Replay / Migration 解决的是更进一步的问题：如何把 session 打包、迁移、复现、甚至在另一个环境里继续。一个复杂 session 里可能包含多轮问题定位、多个文件修改、设计取舍、工具调用、测试结果——如果这些信息无法迁移和复现，就只能停留在一次性工作流里。今天仍然很有意义，尤其适合重度用户和团队场景，因为 AI coding session 越来越像一个真实的工作单元。

更匹配什么形态？

最小形态可以是 CLI，但真正的 replay / migration 工具天然适合 plugin bundle：/export-session 和 /import-session commands、SessionEnd hook、file snapshot collector、manifest generator、restore script、archive format。它是 command + hook + file collector + archive format + restore workflow 的组合。

工具对比

为什么选这些维度？因为 replay 的核心价值不在"导出格式丰富"，而在于能否跨环境复现——需要文件快照、导入恢复、任务状态关联。

# Claude Code session 打包/归档/迁移工具，支持 /export-session 和 /import-session，输出 RENDERED.md/raw JSONL/manifest/file history 等。
- name: cctrace
  url: https://github.com/jimmc414/cctrace
  文件快照: ✅ 包含 file history + snapshots
  导入/恢复: ✅ /import-session 支持
  任务状态关联: ✅ 含 todos/plans
  输出格式: RENDERED.md + raw JSONL + manifest
  跨项目迁移: ✅
  推荐度: 中高

- name: cc2md / 普通导出
  文件快照: ❌ 仅对话文本
  导入/恢复: ❌
  任务状态关联: ❌
  输出格式: Markdown 纯文本
  跨项目迁移: ❌
  推荐度: 低（作为导出工具可用，作为迁移工具不足）

我的判断

Session replay / migration 是比 export 更 plugin-native 的方向，因为它需要的不只是文本转换，而是一个完整的 session packaging protocol。关键在于：是否保留 raw data、是否有 manifest、是否记录文件快照、是否支持 import、是否支持 restore。能做到这些的，是典型的 Claude Code plugin-native 工具。

---

4、Persistent Memory / Knowledge Base：把历史压缩成未来上下文

关键不是记忆多少，而是治理记忆。

这个分类解决什么 + 今天是否还有意义？

Claude Code 每次 session 都很强，但长期记忆很弱。架构选择原因、模块潜在风险、用户偏好代码风格、团队约定、已踩过的坑——这些信息如果只存在于历史 session 里，下次未必能用上。Persistent Memory 解决的是如何把过去 session 中的有价值信息压缩成未来可用的上下文。今天非常有意义——但关键不是"有没有记忆"，而是"有没有治理记忆"：自动去重、项目隔离、可审计可删除、避免上下文污染。

更匹配什么形态？

Persistent Memory 几乎天然适合 plugin bundle：hooks 捕获 session 和 tool calls、local storage 保存 facts 和 decisions、semantic index 做检索、SessionStart hook 注入相关记忆、commands 查询和删除、Web UI 查看管理。这已明显超过 skill 或 CLI 的范围。

工具对比

为什么选这些维度？Memory 工具的核心差异不在于"能不能记录"，而在于治理能力——项目隔离、语义搜索、注入预算控制、可删除。

# 持久化记忆系统，自动捕获 tool 调用观察并生成语义摘要，提供 Web viewer（默认 localhost:37777）和 worker API。
# 不是传统 Skill，而是 Claude Code 的持久记忆系统。它通过 hooks、worker service、SQLite、Chroma vector DB、MCP tools 等方式，在 session 之间保留上下文。适合解决“每次都要重新解释项目背景”的问题。
- name: claude-mem
  url: https://github.com/thedotmack/claude-mem
  项目隔离: ✅ per-project memory
  语义搜索: ✅ 语义摘要 + 向量索引
  SessionStart 注入: ✅ worker API
  Web viewer: ✅ 默认 localhost:37777
  记忆治理（去重/过期）: ✅ schema 结构化存储
  推荐度: 高

- name: 手写 memory hook
  项目隔离: ❌ 需自己实现
  语义搜索: ❌ 仅文本匹配
  SessionStart 注入: ❌ 需自己写 hook
  Web viewer: ❌
  记忆治理: ❌
  推荐度: 低（学习验证可用，长期不推荐）

我的判断

Memory 是最有潜力也最危险的 plugin-native 场景之一。好的 memory plugin 应有明确的 schema、项目隔离、可解释的来源、可删除机制、注入预算控制、stale memory 处理。不看好那种"无限追加所有历史摘要"的工具。长期看，memory plugin 的核心竞争力不是捕获，而是治理。

---

5、Usage / Cost Observability：看清 token 和使用模式

量化 token、成本和使用模式，轻量用 CLI 统计，重度用 plugin 做实时观测。

这个分类解决什么 + 今天是否还有意义？

Claude Code 使用久了之后，token 和成本会变成真实问题：今天用了多少 token？哪个项目最耗 token？哪个 session 最贵？哪些任务导致成本异常？compress 前后节省了多少？对于轻度用户只是 curiosity，但对于重度用户或团队会变成基础设施——控制成本、发现异常 session、优化 prompt 和 workflow、比较模型、评估插件效果、量化 AI coding ROI。

更匹配什么形态？

最小形态是 CLI（读取本地 JSONL 按维度统计），但和 Claude Code 工作流深度结合时值得升级为 plugin：SessionEnd hook 记录 session cost、dashboard 按项目展示、alerts 成本异常提醒、command 查看当前项目 usage。离线统计用 CLI，实时观测用 plugin bundle。

工具对比

为什么选这些维度？因为观测工具的价值不在于"能不能算总数"，而在于能否关联 session 和 task 做归因分析，以及能否实时告警。

# 重型 Claude Code 历史 Web dashboard，支持多项目/搜索过滤/WebSocket 实时更新/hooks 集成/token usage tracking，默认 localhost:18080。
- name: "cchistory（内置 token tracking）"
  url: https://github.com/badlogic/cchistory
  Per-session 成本: ✅ 对话级别统计
  项目维度汇聚: ✅ 按项目分类
  实时更新: ✅ WebSocket
  异常告警: ❌
  关联分析: ✅ token + session + 文件变更
  推荐度: 中高

- name: ccusage
  url: https://github.com/ryoppippi/ccusage
  des: Claude Code / Codex CLI usage 分析，token 消耗 + 成本 + pattern

- name: claude-hud
  url: https://github.com/jarrodwatts/claude-hud

- name: 手写 CLI 统计
  Per-session 成本: ✅
  项目维度汇聚: ✅ 按目录归并
  实时更新: ❌ 事后统计
  异常告警: ❌
  关联分析: ❌ 纯数值统计
  推荐度: 中

我的判断

Usage 工具的价值不在于表格，而在于能否指导行为改变：哪类任务最耗 token？哪些 session 应该拆小？哪些项目上下文太重？哪些 hooks 或 memory 注入过量？只是显示 daily token usage 是不错的小工具；能关联 session、task、memory、history，才成为真正的 observability layer。

---

6、Lifecycle Hooks / Guardrails：让 agent 更可控

在生命周期关键节点自动执行校验、拦截、记录——让 agent 更可控而不是失控。

这个分类解决什么 + 今天是否还有意义？

Claude Code 有一套完整的运行生命周期：session start、tool use before/after、file change、compact before/after、session end、subagent start/stop。Lifecycle Hooks / Guardrails 解决的是如何在这些节点自动执行记录、校验、拦截和治理。今天非常有意义——Claude Code 越强，越需要 guardrails。当 agent 能读写文件、执行命令、调用工具时，需要安全边界、审计日志、自动验证和权限控制。

更匹配什么形态？

天然匹配 hook-based plugin。最小形态是 hook 脚本，但真正可用的 guardrails 需要 hooks + policy config + command + logging + local state + allowlist/denylist + project rules。

工具对比

为什么选这些维度？Guardrails 的核心矛盾是"控制力 vs 透明性"，需要对比 hook 的透明程度、配置灵活性、是否可关闭、是否影响正常 workflow。

- name: 自定义 guardrails plugin
  配置灵活度: ✅ 按项目 yaml 配置
  Hook 透明性: ✅ 每次触发有日志
  可关闭: ✅ per-hook 开关
  策略引擎: ✅ allow/deny/notify 三级
  Workflow 侵入性: ✅ 非阻塞设计
  推荐度: 高

- name: 内联 hook 脚本
  配置灵活度: ❌ 无配置，硬编码
  Hook 透明性: ❌ 需自行加日志
  可关闭: ❌ 需手动注释
  策略引擎: ❌ 纯 if/else
  Workflow 侵入性: ⚠️ 容易阻塞
  推荐度: 中（适合个人快速验证）

我的判断

Hooks / guardrails 是最 plugin-native 的方向之一，因为它直接依赖 Claude Code 生命周期且通常需要跨项目复用。但这类工具也最需谨慎：hook 是否透明？是否有日志？是否能关闭？是否阻塞正常 workflow？是否泄漏代码？好的 guardrails 让 Claude Code 更安全，而不是让用户失去控制感。

---

7、Model Routing：根据任务自动选择模型

在 2023-2025年，之所以 ccr (claude-code-router) 会成为当时最重要的 cc插件，确实有其时代背景。当时各种model各擅胜场，但没有一个能覆盖所有场景。很多model没有 reasoning，没有 websearch，没有 long context，model价格也有点贵，所以需要这么一个东西。典型路由表是 background → 便宜小模型、think/plan → reasoning 模型、longContext → 长上下文模型等。

Claude Code 任务类型 适合路由到
background / 轻量任务 便宜小模型
default / 普通任务 性价比模型
think / plan reasoning model
longContext 长上下文模型
webSearch 支持联网或搜索的模型
subagent 按角色指定模型

但是在2026年的今天，感觉这玩意似乎也没有那么需要，比如说 D4F 这么便宜的model，上面这些就完全能够满足，那么无非是对于复杂任务跟简单任务的二分即可，不再需要上面这套了。

或者说，这个问题转变成了 multi-agent场景，也就是说从“有没有”变成了“好不好”。所有的模型都有 reasoning, longContext, websearch，但是不同model的能力边界仍然不同，仍然各擅胜场。但是这就不是所谓“model-routing”去做的了。

---

还有哪些值得关注的方向（Unknown Unknowns）

除了上述 7 类，还有一些方向目前没有成熟工具，但值得关注：

• Claude Code 专用的测试沙箱 / evaluation framework：能自动 replay session 做回归测试的工具，用来验证新版本 Claude Code 或新 plugin 是否 break 已有工作流。目前 session replay 工具（如 cctrace）提供了打包能力，但还没有人做成完整的 eval harness。
• 跨实例 session 同步 / 协作层：如果团队多人使用 Claude Code，如何共享 session、task、memory？目前的工具都是单机单用户设计，缺少多用户协作场景的 plugin。
• Project-level 配置分发与版本化：CLAUDE.md 和 .claude/settings.json 可以项目内共享，但缺少"组织级默认配置 + 项目级覆盖 + 版本化"的完整链路。这本质上是 plugin marketplace 的企业级延伸。
• 权限感知的 tool call sandbox：某次 tool call 是否越权？是否可以按项目或文件路径做细粒度权限控制？目前 hooks 能做到拦截，但缺少声明式的权限配置层。
• Claude Code 自身的自动化测试工具：当 plugin 修改 hooks 或 settings 时，能否自动验证"Claude Code 仍然正常工作"？一个 plugin 导致 Claude Code 启动变慢或功能异常的情况已有社区反馈，但缺少自动化检测手段。

---

筛选方法论

5 个筛选问题

以下 5 个问题融合了分层分类思维与"less-is-more"的实操原则。评估任何扩展时，按顺序过一遍：

1. 它是解决长期工作流，还是一次性任务？ 一次性任务 → skill 或 command。长期工作流才值得 plugin 化。
2. 它是否需要进入 Claude Code 生命周期？ 如果在 SessionStart/End、PreToolUse/PostToolUse 等节点需要自动触发，就更适合 plugin。完全不需要生命周期的话，未必需要 plugin。
3. 它是否维护本地状态？ task state、session index、memory database、usage history、audit log、semantic index——有状态的扩展更适合 plugin bundle。无状态输入输出转换 → CLI 或 skill。
4. 它是否组合了多个能力单元？ skill + MCP、command + hook、hook + local database、MCP + Web UI——组合越多，越需要 plugin 分发形态。
5. 它是否值得跨项目安装和长期维护？ Plugin 成本比单个 skill 高，需要跨项目价值。只适合某个 repo → 项目配置里就好；适合所有项目甚至团队统一使用 → 值得 plugin 化。

融合 less-is-more 的五个终审标准：

高频、低权限、可验证、可 debug、低维护成本。

一个插件如果不同时满足这五点，长期来看不值得保留。

评分标准（压缩版）

从原来 10 个维度压缩到 6 个核心维度：

维度	关键问题
Cross-project value	是否多个项目都能用？
Workflow depth	解决长期 workflow 还是一次性动作？
Lifecycle fit	是否真的需要 hooks 或 session 生命周期？
Statefulness	是否维护任务、历史、记忆、索引、日志等状态？
Composability	是否组合了 skill、MCP、hook、agent、CLI 或 UI？
Governance & Risk	是否提供权限/策略/日志等治理？是否引入安全风险？

粗略标准：0-2 项 → 大概不值得作为 plugin；3-4 项 → 值得观察；5-6 项 → 值得认真评估。

选型 Prompt

以下 prompt 可直接复用于快速评估一个 Claude Code plugin / skill / MCP / hook / CLI 的价值。

我正在评估一个 Claude Code 扩展，请你帮我判断它更适合做成 skill、MCP server、subagent、hook、CLI，还是 plugin bundle。

请按以下框架分析：

1. 它解决的核心场景是什么？
2. 它解决的是一次性任务，还是长期工作流？
3. 它的最小合理形态是什么？
4. 它是否真的需要作为 plugin 安装？为什么？
5. 它是否需要跨项目复用、生命周期触发、本地状态、外部服务或团队分发？
6. 它是否组合了多个组件（skill + MCP、hook + local storage、CLI + dashboard）？
7. 它和 Claude Code 原生能力有什么重叠？
8. 它的主要风险是什么？（权限、隐私、维护、性能、上下文污染、vendor lock-in、卸载成本）
9. 如果不用它，最小替代方案是什么？
10. 最终结论：推荐安装 / 值得观察 / 不建议安装，以及适合个人、团队还是企业。

请优先使用五个标准：高频、低权限、可验证、可 debug、低维护成本。

示例输出（以 claude-task-master 为例）：

结论：推荐安装，适合个人和团队。

1. 核心场景：把 PRD 拆成可执行、可追踪的任务图，贯穿多个 session。
2. 长期工作流——任务状态需要跨 session 维护。
3. 最小合理形态是 skill，完整价值需要 Plugin Bundle。
4. 需要 plugin 安装：因为它维护结构化任务状态和依赖关系。
5. 跨项目复用（是），生命周期触发（SessionStart/End 同步状态），本地状态（是），团队分发（是）。
6. 组合了 skills + commands + local storage + MCP server + hooks。
7. CC 没有内置任务图系统，重叠小。
8. 主要风险：任务存储格式可能随 CC 版本变化；任务内容含项目细节需注意隐私。
9. 最小替代：手工 Markdown TODO + /resume。
10. 综合：推荐安装，典型 Agent Operating Layer plugin。

反模式（精选 5 条）

1. 把单条 prompt 包装成 plugin

如果一个 plugin 只是封装了一条 prompt，它更像 skill。除非需要跨项目安装、版本化、与其他组件组合，否则不需要 plugin 化。

2. 把一个 MCP 配置直接叫 plugin

MCP 是工具接口，不是完整 plugin。MCP server 只有在和 skills、commands、hooks、workflow 结合时才像完整 plugin。

3. Hook 太重，偷偷执行不可见逻辑

反模式包括：默认执行重操作、没有日志、无法关闭、修改文件不透明、调用外部服务不说明、阻塞正常 workflow。Hooks 很强也很危险，透明性是底线。

4. Memory 工具只会无限追加

什么都记、不去重、不过期、不区分项目、不支持删除、不显示来源、注入过多上下文。Memory 最怕污染，核心竞争力不是捕获而是治理。

5. Dashboard 很漂亮但没有可靠的数据模型

很多 history / usage / memory dashboard 看起来不错，但核心是数据模型。不能稳定解析 session、维护索引、处理项目边界、支持迁移——UI 再漂亮价值也有限。

总结

Claude Code Plugin 的价值不在于"让 Claude 多一个技能"，而在于让 Claude Code 作为长期 agent 工作台变得更可控、可观测、可恢复、可迁移、可组合。

所以我不把所有 Claude Code 扩展都当成 plugin 看。我更关心的是：它是否真的值得被做成 plugin？

• 它是否解决长期工作流，而不是一次性任务？
• 它是否需要进入 Claude Code 生命周期？
• 它是否需要维护本地状态？
• 它是否组合了多个能力单元？
• 它是否值得跨项目安装和长期维护？

如果大多是否，它可能只是一个 skill、MCP、subagent、hook 或 CLI。大多是是，它才真正适合成为 plugin bundle。

最终，真正值得关注的不是"让 Claude 多一个技能"的插件，而是"让 Claude Code 作为长期 agent 工作台更可靠"的插件——task、history、export、migration、memory、observability、guardrails、model routing。它们不是能力清单，是 Claude Code 的 operating layer。

大多数人不需要更多插件，而需要更少、更稳定、更容易解释的插件。

---

附录

A. 判断矩阵：一个扩展到底该做成什么形态？

形态	适合场景	是否天然是 plugin
Skill	封装流程、规范、判断标准	否，通常是 plugin 内部组件
Slash Command	显式触发的重复动作	否，可 plugin 化
Subagent	专家角色、隔离上下文	否，通常是能力单元
MCP Server	连接外部系统、工具、数据源	否，常作为 plugin 组件
Hook	生命周期自动化、拦截、记录	很适合 plugin 化
LSP Server	语言智能、诊断、跳转	适合以 plugin 分发
Monitor	运行时观测、策略检查	很适合 plugin 化
CLI / Web UI	本地工具、dashboard、导出器	单独存在合理；接入 CC 后适合 plugin 化
Plugin Bundle	组合多组件后的产品化形态	本文核心
Marketplace / Team	组织级统一分发、权限治理	企业级演进方向

B. 成熟度模型

层级	描述	特征
L0：Prompt / Snippet	提示词片段	个人复制使用，不需要 plugin 化
L1：Skill / Command	可复用的 skill 或 slash command	重复流程，单点能力
L2：Skill + MCP / Agent	连接外部系统或引入专家角色	复杂任务场景，未必需要 plugin
L3：Hook + Local State	进入生命周期并维护状态	从此层开始 plugin 化价值明显提高
L4：Plugin Bundle	组合 skills + commands + hooks + MCP + storage + UI	本文核心形态
L5：Marketplace + Team	面向团队或组织分发	统一安装、版本锁定、权限声明、audit log