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

Plugin 是把一堆配置打成一个包：技能、子智能体、钩子、命令，一起装、一起升、一起卸。 它解决的是一致性：改一次要通知几个人，超过了「口头同步能覆盖」的范围，才需要包。

📝 本章和前面几章的关系

前八章讲的都是「单个能力怎么做好」，这一章讲「怎么把它发给别人」。 这一节先定位：包解决的是什么问题，不解决什么。

一、打包解决了什么

装：一条命令装齐。没包的时候，是一个个文件拷，漏一个就不工作。 升：整包升级。没包的时候，谁改了哪个文件没人说得清。 卸：整包卸载。没包的时候，删了一半剩下一半还在生效——这种「半生效」最难查。

审：一份清单可以评审。散在各处的配置，评审时根本看不全。 四件事里，「卸」最容易被忽略：它只在出问题的时候才重要，而那时候已经晚了。

二、四种规模，成本怎么涨

自己用：一份源，没有拷贝。 一个小组用：几份拷贝，口头同步，出问题再问。 跨团队用：几十份拷贝，要写文档、发版本、答疑。

对外发布：几百份，要管版本兼容、变更说明、issue。 同步方式那一列越往下越重。而这个重量不是线性的：答疑和 issue 会吃掉维护者大部分时间。

三、分界线在哪

判据不是人数，是「改一次要通知几个人」。 一个人改了自己知道；两个人就要说一声；五个人以上，口头同步必然漏。 所以真正的分界线在「口头同步失效」的那一刻，通常就是三到五个人。

一句话：Plugin 真正解决的是「一致性」，不是「方便」。方便是顺带的。

四、包和散装的关系

包里的东西还是那些东西：技能还是 SKILL.md，子智能体还是那份定义，钩子还是那段脚本。 包只是在外面加了一层：一份清单、一个版本号、一个安装位置。 所以「该不该打包」和「内容写得好不好」是两个问题，别混在一起想。

先有能跑的单件，再考虑打包——顺序反了，你会为一个还没成形的东西维护版本。

五、什么时候打包没意义

只有你自己用、改了就生效、没有第二个人依赖——打包只会多一步「装」。 还有一类：东西还在天天变。这时候先别打包，等形状稳定了再说。 这两条会在 9.8 节展开成四个具体问题。

现在先记住一句：包是有维护成本的东西，不是「更正式的版本」。

六、动手 Demo：四种分发规模，同步成本怎么涨

Plugin 是把「一堆配置」打成一个包：一起装、一起升、一起卸。 这里把四种分发规模摆出来，看「同步」这件事的成本怎么涨。

SHAPES = [(u"自己用", 1, 0, u"拷一份目录"),
          (u"一个小组用", 5, 1, u"口头同步，出问题再问"),
          (u"跨团队用", 30, 4, u"写文档、发版本、答疑")]

实跑输出：

--------------------------------------------------------------------
四种分发规模，同步成本怎么涨
--------------------------------------------------------------------

  Plugin 是把「一堆配置」打成一个包：技能、子智能体、钩子、命令，一起装、一起升、一起卸。
  它的价值跟用的人多少成正比：一个人用，打包没意义；三十个人用，不打包就是灾难。

  ① 打包解决了什么
  --------------------------------------------------------------------
| 这一步 | 有包 | 没包 |
|---|---|---|
| 装 | 一条命令装齐 | 一个个文件拷，漏一个就不工作 |
| 升 | 整包升级 | 谁改了哪个文件，没人说得清 |
| 卸 | 整包卸载 | 删了一半，剩下一半还在生效 |
| 审 | 一份清单可以评审 | 散在各处，评审时看不全 |


  ② 四种规模，成本怎么涨
  --------------------------------------------------------------------
| 场景 | 多少人 | 几份拷贝 | 同步方式 |
|---|---|:---:|---|
| 自己用 | 1 | 0 | 拷一份目录 |
| 一个小组用 | 5 | 1 | 口头同步，出问题再问 |
| 跨团队用 | 30 | 4 | 写文档、发版本、答疑 |
| 对外发布 | 500 | 20 | 版本兼容、变更说明、issue 处理 |

  注意「几份拷贝」这一列：自己用是零份（就一份源），对外发布是二十份。
  而同步方式那一列越往下越重——从「拷一份」到「发版本、答疑、处理 issue」。

  ③ 分界线在哪
  --------------------------------------------------------------------
  判据不是人数，是「改一次要通知几个人」。一个人改了自己知道；两个人就要说一声；
  五个人以上，口头同步必然漏 —— 这时候才需要「包加版本号」。
  所以 Plugin 真正解决的是「一致性」，不是「方便」。方便是顺带的。

  ④ 包和散装的关系
  --------------------------------------------------------------------
  包里的东西还是那些东西：技能还是 SKILL.md，子智能体还是那份定义，钩子还是那段脚本。
  包只是在外面加了一层：一份清单、一个版本号、一个安装位置。
  所以「该不该打包」和「内容写得好不好」是两个问题，别混在一起想。

  ⑤ 什么时候打包没意义
  --------------------------------------------------------------------
  只有你自己用、改了就生效、没有第二个人依赖 —— 打包只会多一步「装」。
  还有一类：东西还在天天变。这时候先别打包，等形状稳定了再说。
  这一条和 9.8 节那个判断是同一件事，那边会给具体判据。
  ! 这一节的成本是示意，不是实测；它演示的是「拷贝份数随人数线性涨」这件结构上的事。

①打包解决四件事：装（一条命令装齐）、升（整包升级）、卸（整包卸载）、审（一份清单可评审）。 「卸」最容易被忽略，它只在出问题时才重要，而那时候已经晚了——半生效的状态最难查。 ②分界线的判据不是人数，是「改一次要通知几个人」。 五个人以上口头同步必然漏，这时候才需要「包加版本号」。 ③所以 Plugin 真正解决的是「一致性」，不是「方便」。方便是顺带的。 ④包不改变内容的格式，只改变它们放在哪儿、怎么被找到。所以先有能跑的单件，再考虑打包。

30 秒实验

  1. 把「跨团队用」的人数从三十改成三，重跑一遍。这时候还需要包吗？「几份拷贝」到多少才叫管不住？
  2. 给「自己用」加一个条件「半个月后才回来改」，结论会变吗？为什么「隔了多久」也会影响这个判断？
  3. 列出你现在散装维护的三样配置。它们各自处于哪种规模？有哪一样其实已经该打包了？

常见误区

  1. 一个人用也打包。多一步「装」，换不来任何东西。
  2. 以为打包能解决「内容写得不好」。包只管分发，不管质量。
  3. 东西还在天天变就打包。改三版之后往往把包废掉，回到散装。
  4. 把「卸载」当成小事。删了一半、剩一半还在生效，是最难查的一类问题。
  5. 以为包越多越专业。每个包都有维护成本，包的数量要克制。
自测三问（点开对答案） 1. Plugin 解决的核心问题是什么？ —— 一致性。装、升、卸、审四件事在散装状态下都没有保证，包把它们变成一个动作。 2. 该不该打包的判据是什么？ —— 「改一次要通知几个人」。五个人以上口头同步必然漏，那时候才需要包加版本号。 3. 为什么「卸载」最容易被忽略？ —— 因为它只在出问题的时候才重要。而「删了一半还在生效」是最难查的一类状态。

定位说清了，下一节看一个包具体长什么样：一份清单加几个目录。

相关笔记