波仔
🐎 第9章 集腋成裘：Plugins 生态
📄 一句话概括

打包有成本：写清单、定版本、写文档、维护发布。所以不是所有东西都值得打成包。 六个能力真跑一遍：三个该打包，两个不该，一个暂缓。 「暂缓」这个答案最有用，它挡住了过早打包。

📝 本章和前面几章的关系

上一节讲包该怎么设计，这一节讲「要不要打包」——两个问题不一样。 这一节的四个问题可以直接当决策表用。

一、四个问题

会被两个人以上用吗？不会就不打包：一个用户的包，维护成本全落在自己身上。 需要版本号吗？需要就打包：别人依赖它，就得能说清「哪一版」。 需要治理吗（权限、审计）？需要就打包：没包的治理只能靠制度。

内容稳定了吗？没稳定就暂缓：天天改的东西，打包只是多一步。 前三个问「该不该」，第四个问「现在该不该」。四个都过，才打包。

二、真跑：六个能力逐个判

演示里六个：个人提示词、团队发布检查、跨团队安全扫描、临时小技能、公司统一 MCP 配置、快捷键绑定。 结果三个该打包，两个不该，一个暂缓。 「快捷键绑定」最典型地不该打包：一个人用、不要版本、不要治理。

「临时小技能」是暂缓：可能以后有人用，但现在还没稳定。

三、暂缓和打包的区别

暂缓不是「永远不打包」，是「先按散装用，等形状稳定了再收进包」。 这个判断很实用：它避免了「过早打包」——包一旦发出去，改法就受约束了。 而形状没稳定就打包，往往是改了三版之后把包废掉，回到散装状态。

那三版的时间不是白花的，但发版、通知、改文档的时间是白花的。

四、一个常被忽略的成本

打包之后，你的改动要经过「改、测、发版、通知」四步，而不是「改完就生效」。 这个成本是固定的，跟包大小无关。所以小东西打包之后，维护负担反而更重。 判据还是那句：这个能力会有人依赖吗？没人依赖，四步全是白走的。

这也是为什么小团队常常打包失败：包做出来了，但没人有耐心维护那条流程。

五、反过来：什么情况必须打包

要给别人装、要能回滚、要能审计——三条里有任何一条，就必须打包。 因为这三件事都需要「版本」和「清单」，而散装的配置提供不了。 注意这三条都不是「方便」：它们是「出事的时候能不能收拾」。

所以打包这个决定的性质是「上保险」，不是「上档次」。

六、动手 Demo：六个能力，四个问题决定该不该打包

打包有成本：写清单、定版本、写文档、维护发布。所以不是所有东西都值得打成包。 这里六个能力，四个问题逐个过一遍。

if users <= 1 and not vers and not gov:
    pick = u"暂缓" if not stable else u"不打包"
elif not stable:
    pick = u"暂缓"
else:
    pick = u"打包"

实跑输出：

--------------------------------------------------------------------
六个能力，四个问题决定该不该打包
--------------------------------------------------------------------

  打包有成本：写清单、定版本、写文档、维护发布。所以不是所有东西都值得打成包。
  四个问题一问，答案基本就出来了。

  ① 四个问题
  --------------------------------------------------------------------
| 问题 | 结论 | 理由 |
|---|---|---|
| 会被两个人以上用吗 | 不会 → 不打包 | 一个用户的包，维护成本全落在自己身上 |
| 需要版本号吗 | 需要 → 打包 | 别人依赖它，就得能说清「哪一版」 |
| 需要治理吗（权限、审计） | 需要 → 打包 | 没包的治理只能靠制度 |
| 内容稳定了吗 | 没稳定 → 暂缓 | 天天改的东西，打包只是多一步 |


  ② 真跑：六个能力逐个判
  --------------------------------------------------------------------
| 能力 | 几个人用 | 要几个版本 | 结论 |
|---|:---:|:---:|:---:|
| 个人常用的一段提示词 | 1 人 | 0 版 | 不打包 |
| 团队发布前检查的五个步骤 | 6 人 | 2 版 | 打包 |
| 跨团队共用的安全扫描 | 30 人 | 5 版 | 打包 |
| 临时试的一个小技能 | 1 人 | 0 版 | 暂缓 |
| 公司统一的 MCP 配置 | 200 人 | 8 版 | 打包 |
| 自己改的快捷键绑定 | 1 人 | 0 版 | 不打包 |

  六个里 3 个该打包。剩下的三个分别落在「不打包」和「暂缓」。
  「自己改的快捷键绑定」是最典型的「不打包」：一个人用、不要版本、不要治理。
  「临时试的小技能」是「暂缓」：可能以后会有人用，但现在还没稳定。

  ③ 暂缓和打包的区别
  --------------------------------------------------------------------
  暂缓不是「永远不打包」，是「先按散装用，等形状稳定了再收进包」。
  这个判断很实用：它避免了「过早打包」——包一旦发出去，改法就受约束了。
  而形状没稳定就打包，往往是改了三版之后把包废掉，回到散装状态。

  ④ 一个常被忽略的成本
  --------------------------------------------------------------------
  打包之后，你的改动要经过「改、测、发版、通知」四步，而不是「改完就生效」。
  这个成本是固定的，跟包大小无关。所以小东西打包之后，维护负担反而更重。
  判据还是那句：这个能力会有人依赖吗？没人依赖，四步全是白走的。

  ⑤ 反过来：什么情况必须打包
  --------------------------------------------------------------------
  要给别人装、要能回滚、要能审计——三条里有任何一条，就必须打包。
  因为这三件事都需要「版本」和「清单」，而散装的配置提供不了。
  ! 四个问题是这一课的归纳，实际取舍还要看团队习惯；把它当自查，不当规则。

①四个问题：会被两个人以上用吗、需要版本号吗、需要治理吗、内容稳定了吗。 前三个问「该不该」，第四个问「现在该不该」。 ②六个能力里三个该打包：团队发布检查、跨团队安全扫描、公司统一 MCP 配置。 两个不该打包（个人提示词、快捷键绑定），一个暂缓（临时小技能）。 ③暂缓不是永远不打包，是「先散装用，等形状稳定再收进包」。 形状没稳定就打包，往往改三版之后把包废掉。 ④打包的固定成本是「改、测、发版、通知」四步，跟包大小无关。所以小东西打包之后，维护负担反而更重。

30 秒实验

  1. 把「临时小技能」的稳定项改成 1，重跑一遍。结论从暂缓变成什么？
  2. 给「快捷键绑定」加一条「要发给同事」，重跑一遍。它该打包吗？这说明哪个问题是决定性的？
  3. 把阈值从「两个人以上」改成「五个人以上」，重跑一遍。哪几个结论会变？

常见误区

  1. 什么都打包。每个包都有固定的维护成本，小东西打包之后负担反而更重。
  2. 形状没稳定就打包。改三版之后往往把包废掉，回到散装。
  3. 以为打包是「更正式的版本」。它本质是上保险：给出问题时留退路。
  4. 只看人数不看治理需求。要审计的东西，一个人用也得打包。
  5. 把「暂缓」当成「不做」。它只是延后，不是放弃。
自测三问（点开对答案） 1. 决定该不该打包的四个问题是什么？ —— 会被两个人以上用吗、需要版本号吗、需要治理吗、内容稳定了吗。 2. 「暂缓」是什么意思？ —— 先按散装用，等形状稳定了再收进包。它挡的是「过早打包」。 3. 什么情况必须打包？ —— 要给别人装、要能回滚、要能审计——任何一条都要求有版本和清单，散装提供不了。

最后一节换个角度看未来：语言服务器能给 agent 省掉什么。

相关笔记