半年前 marketplace 刚开放的时候，我大概装了三十多个 plugin。心态很简单：能装的都装上，反正用不到也不亏，万一哪天就救了我一把。

半年后回头看装机列表，留下来还在每周都用的，只剩五六个，全是 skill 类的。那些当时我觉得"这下开发体验要起飞"的功能性 plugin，git 工具的封装、lint wrapper、format 工具集、commit message 生成器、PR diff 总结器，一个不剩。不是我手动卸的，是它们慢慢就不再被触发。

我原以为情况会反过来。功能性 plugin 边界清晰、调用便宜、错不了；skill 类那种几百行 markdown 写工作流的东西，我本来觉得太重，模型读完前缀就把上下文吃掉一半。结果活下来的恰恰是后者。 这件事让我后来选 plugin 的方式整个变了。

我当初怎么挑 plugin

把场景说清楚：单人项目为主，偶尔接团队仓库，Claude Code 是主要 IDE。装 plugin 时我用的判断标准很朴素，就是这个工具能不能省我打字。

按这个标准筛，功能性 plugin 看起来是稳赢的。git tools 类把 git add . && git commit -m "..." && git push 折叠成一句"提交并推送"；lint wrapper 把 make lint 加上自动修复包成一个 slash command；format 集合按文件类型自动选 prettier / gofmt / black。每一个都是省 30 秒的小胜利，三十多个加起来一年能省下不少时间。

skill 类我当时是抱着"试试看"的态度装的。比如 writing-tech-blog 这种，给我看的时候是一份四千多字的 markdown 加七八个 reference 文件，我心想这玩意儿真的会被调起来吗，模型自己难道写不出博客。结果第一次让它跑就被打脸：不挂 skill 我让它直接写一篇技术博客，开头就是"在当今 AI 飞速发展的浪潮中"，全文 14 个破折号，三段并列每章一组；挂上 skill 再让它写同一题，破折号降到 4 个，多了"我以为 X 结果 Y"的反转段，trade-off 段单独成节。差距一眼能看出来。

实际跑半年下来发生了什么

功能性 plugin 死得很安静。我没有"决定弃用"的某个时刻，只是渐渐发现自己在做某件事的时候，根本没想起来调那个 plugin。

举个例子。“提交并推送"这个 plugin，我第三个月开始就直接打字"帮我把这些改动提交了，commit message 你写”。模型自己会跑 git status、看 diff、起一个比 plugin 模板更贴合内容的 message，然后 push。plugin 存在或不存在，对结果没差别。lint wrapper 同理，make lint 在 CLAUDE.md 里写过一次，模型遇到要 lint 的场景自己就调了。我专门去看了下我那个 git tools plugin 的 marketplace 页面，它内置的 commit message 模板是"feat: add X / fix: resolve Y"这种，模型自己生成的反而更具体，会写出"refactor stripe webhook idempotency to use charge.id instead of event.id"这种带上下文的描述。模板在和零样本能力比拼，输了。

skill 类反过来。writing-tech-blog 是我用得最多的之一。我自己每次写博客都得在 prompt 里塞"别用破折号、加个我以为 X 结果 Y、写 trade-off"，这些规则单条说出来都简单，连起来在脑子里管着十条规则边写边自检，模型干不到。skill 把这些规则编码成审稿协议，模型按 checklist 跑，质量稳定。

两类 plugin 的本质差距在"封装厚度"

我后来想明白，这件事跟 plugin 写得好不好没关系，跟它包了多厚的工作流有关。

功能性 plugin 的问题是它在和模型的零样本能力直接竞争。模型一年比一年聪明，零样本能搞定的事在变多，去年还需要 plugin 兜底的"提交并推送"，今年模型自己已经能跑得比 plugin 模板更好。它是一个赔率随时间持续走低的赌局。

skill 类不参加这个赌局。它封装的不是"把几个命令串起来"，而是"一套质量约束"或"一套领域 checklist"，这种东西即使模型再聪明十倍，没有外部锚点它还是会回归"统计上最常见的写法"，因为它的训练目标就是这个。skill 等于强制把"小众但正确"的做法摆在它面前。

举几个我留下来的：写博客的反 AI 审稿、代码评审的多视角分析、debug 的系统性排查流程、一个把支付订单转移流程写成 SQL 工单的运营 skill。它们的共同点是：如果不写下来，每次都得重新教模型一遍，而教的过程本身就比直接做还累。

我现在装 plugin 前会问三件事

不是说功能性 plugin 全都该卸。hook 类、MCP 类、跨工具链编排类是例外。我说的是那种"包了几条命令"的薄封装。

装之前我现在固定问：

第一，这件事让模型从零跑一遍要几步？少于三步的不装。一步两步的事自然语言比 slash command 还快。

第二，这个 plugin 解决的是"模型不知道怎么做"还是"模型每次都换着花样做"？前者随模型能力提升会消失，后者是 skill 类的本命场，稳定性需求不会因为模型变强就消失。

第三，半年后我还会用它吗？这个问题不好答，但有个代理指标：如果这个 plugin 的功能能在 CLAUDE.md 里写一句话替代，那它就活不过半年。

上周一个真实场景。有人推荐我装一个 “auto-changelog” plugin，扫 git log 自动生成 release notes。我用这三问筛了一遍：第一问，模型从零跑要几步？我让 Claude Code 跑了一遍 git log --oneline v1.7.0..HEAD + 让它分类，三句话搞定，不到三步。第二问，是"不知道怎么做"还是"换着花样做"？前者——changelog 风格 CLAUDE.md 里写一行"按 feat/fix/refactor 分组"就稳定了。第三问，CLAUDE.md 一句话能替代吗？能。三问全否，没装。下次我想用的时候直接说"按上次那个格式生成 changelog"就行。

反过来 brainstorming skill（YC office hours 那套）我装了，它封装的是"用六个反诱导问题逼出真实需求"，模型自己绝对跑不出这个流程，跑出来也不会问"现状是什么 / 最窄入口在哪"这种刁钻问题。第二问是"换着花样做"，这才是 skill 类该装的场景。

什么时候我会反过来选功能性 plugin

这套判断有三个明显失效场景。

团队仓库，多人协作。这种时候自然语言指令的"语义漂移"成本很高，每个人对"提交并推送"的理解可能不一样，封装成 plugin 反而是把约定固化下来的好方式。这时候我不在乎模型零样本能不能做，我在乎的是团队所有人调起来行为一致。

其次是 hook 类 plugin。PreToolUse / PostToolUse 这种本来就不是"工具封装"，而是"流程约束"，它和 skill 类是同一类生物，只是表现形式不同。我前面说的"功能性 plugin 都死了"不包括 hook。

最后是 MCP 类。MCP 接的是模型本身没有的外部能力（数据库查询、文档搜索、内部 API），这种"模型从零跑不出来"的事，封装一次就值。

留白

我不太确定的是，这套判断在多人团队和大型代码库里还成不成立。我自己的样本是单人 + 少量协作仓库，模型零样本能力好不好用，跟仓库大小、领域知识深度强相关。也许在十万行的金融系统里，连"提交并推送"都需要 plugin 兜底，因为模型连 commit message 风格都猜不准。

但有一件事我比半年前更确信：装 plugin 不是越多越好，每装一个都在和"模型半年后是不是还需要它"赌。skill 类是少数赌赢的，它赌的是"再聪明的模型也得有 checklist 才能稳定输出小众正确做法"，这个赌注大概率不会随时间贬值。

下一篇我想写的是为什么我把 CLAUDE.md 从两百多行砍到了六十行，某种意义上是同一件事的另一面。