08/04 Tl.2 你的软件，真的需要插件系统吗？

读前须知
请不要强行带入自身，不要对号入座——本期 OMI 并无引起争端的意愿，请您以身作则，维护社区良好交流环境。

不知道什么时候开始，一家一家软件都开始做起来插件系统，不管是课表、批注、不管是最近才发展起来的或者是已经小有气候的，都开始做了。当然不是说这不是一种明智之举——只不过有的是早有考量或者深思熟虑的结果，有的则是继上次 OpenClaw 大学习风潮后的又一波风气而已。而基于 Vibe 大流行的现状，如果本来就不适用插件而非要加上去，最终结果要么是徒增 Token 使用量并狠狠地烧钱、要么是白白耗费脑力与日后的维护精力。

所以，你的软件真的需要一个插件系统吗？

欢迎收看本期 OhMyIWB Thinklog 2。

插件系统适用在哪？

首先，让我们看看几个优秀利用插件系统的例子。或许从他们之中，我们能学到点什么。

ClassIsland 社区中的优秀项目，插件社区发展的很完善 —— 从主界面组件、自动化增强到各项增强体验的小功能，不管是 ClassIsland 1 这种老资历还是 ClassIsland 2 这种新起之秀，即使经历了一次大换血社区开发者也在不停地适配开发。
VSCode 提到插件就不得不提 ~~微软大战代码~~ 了，这里简直是各种各样五花八门眼花缭乱。各位用过基于 VSCode 的 AI IDE 的同学应该深有体会。

它们有什么特点呢？在我看来，无非这几个：

有明确的扩展点。扩展点是啥意思呢？我不知道以前有没有这个词汇，不过基于我 Minecraft Wiki 最后一块用户框可以看出，我的语言能力十分的贫瘠以至于需要重新造词来描述一个……呃……名词。 ~~扯远了~~ ， 扩展点 指的是能被第三方扩展功能、发挥社区创意的软件本体功能。比如 CI 的主界面组件从 1.5 Griseo 开始就能自由定义了（是的之前 CI 主界面是定死的），也正是在这个版本，CI 插件系统被开发出来，直到如今 CI 发展出了令人赞叹的插件体系。
有明确的 SDK。显然我们社区开发者不能够仅仅依靠软件源码去做插件，像 CI 就有明确的文档供开发者参考——有能力还可以把 SDK / 模板发布在公开库上（如 C# 对应 nuget，node.js 对应 npm，Python 对应 PyPI 等）供开发者使用。
有明确的社区生态。像 CI 的插件市场就是例子，它在 GitHub 上维护着一个 Repo PluginIndex，插件开发者可以选择发布到插件市场进行分发——同时每个仓库的许可证 / 反馈渠道也很明确。小道消息还说 CI 将会对插件做近一步治理，包括（可能）加入评分系统 / 重 Vibe、质量低 Badge 提示等。VSCode 甚至还有社区维护的插件源（如开放的 Open VSX）供二次开发的基于 VSCode 的项目使用。

我的软件到底适不适合插件掺和？

说了这么多，你大概也看出来了：一个 适合拥有插件系统的软件，既要有明确的「扩展点」，作为开发者的你还要有精力维护一份格式良好的文档（最好还别是 AI 生成奥，参见 OMI Tl.1），还要与开发者 / 用户社区有良好的沟通合作。

但是有同学又要问了，诶 MM，这里你说的「扩展点」看起来实际上只是一种很宽泛的概念，能否再讲讲呢？

彳亍。鉴于作者这个啥子豆包是个啥子，我还是分为以下几点分点阐述「你的软件到底要不要加入插件系统」这个问题，即使这会让这篇文章看起来就像 AI 生成的一样，不过只要我够疯癫够啥子，你就读不出来，嘻嘻。（？）

与主程序解耦。如果插件接口与主程序耦合过于严重，那么每次更新都可能导致插件 API 的巨大变化，这肯定是插件开发者不愿意看见的。最好的情况就是你提前预见了插件的开发，把部分功能甚至设计成了内置插件的形式——这其实也是一种良好的开发风味，如果你仅仅靠 Vibe 写代码，这种经过深思熟虑的代码是不怎么会出现的。这也是为什么我推荐你先写点代码，或者说设计好应用的骨架，不要一股脑让 AI 从 0 开始开发的原因。 ~~像这个老啥子兼老鸽子作者开发的老久没碰过的 NoMessyDesktop 就是我用老一辈手艺搓出来的，虽然是用了这种范式，但也很难不说有过分设计的嫌疑（x~~
要么明确职责、要么提供足够多的接口。两极分化一般来说不是好文明，但是我个人认为，这在插件开发中是适用的。为啥子呢？首先，「明确职责」指的是你提供了你个明确的插件开发方向。比如说啥子 NMD，它目前的设计是提供了 3 个步骤：Watcher、Classifier 和 Placer，分别对应「发出分类信号」、「分类文件为指定类别（这里指哪个科目）」和「移动文件到制定的位置」。这里 Watcher、Classifier 其实都可以被「插件化」：它提供了一个明确的方向，即「发出分类信号」与「分类文件为指定类别」。比如说，我就实现了根据 CSES 课表与 ClassIsland 联动，每到下课就发出信号的 2 个 Watcher（感谢 @lrs2187 在 CI IPC 联动方面提供的指导）和几个不同的 Classifier（感兴趣的同学可以去翻源码）。虽然现在 NMD 鸽鸽鸽以至于很久没有 Commit 了，设计也不一定是真的好，但仍具有一定的参考价值—— ~~至于是正面的或是反面的那就说不定了~~ 。「足够多的接口」又是哪一方面呢？返回去看 CI。CI 本体提供了许多主界面组件、可自定义的自动化（有不同的触发器、规则、行动）、提醒等诸多功能。试想一个插件便能扩展这以上所有的内置功能会激发多少创造力、或者试想这些功能都被定死了想要扩充只能去问问你好 WRC 会有多困窘就知道了——有了插件，自己写一个就行。（不会写基于现在的情况可以直接问 AI、但把一不适合生产环境的半成品直接挂在插件市场在我看来就不怎么明智了——不过，这点跟我们要讨论的话题有点远了，或许可以当作下个话题也说不定）甚至，不仅仅是扩展这些接口，官方提供的 SDK 就实现了每次打开 ClassIsland 自动弹出一个 Hello World Dialog 的功能——这意味着不仅仅是上述接口，任何可以在 Avalonia 中实现的效果只要配合得好都能做出来。
要有精力长久维护。不仅仅是文档——还包括所有附属设施，如提供插件分发的服务器 / GitHub Repo，等等等等。别看这看起来很少，实际上如果你一个人维护，同时应付开发、文档、服务、社区其实是很难的事情——更别提作为学生的其他职责了。

如何有个良好的插件开发氛围（？）？

如果你已经下定决心要做插件了，不管合不合适（ ~~不合适其实也没人会给你开发的说~~ ），维护肯定是要维护的。那么如何有个良好的插件生态呢？首先，你得吸引足够多的用户。这看起来似乎与「尽早开始规划」这点建议相悖，但其实不是——这两者是相互促进的，有了更好的功能 / 插件开发基础、更多用户 / 开发者就会围过来。反之，如果你的软件本体功能无法吸引足够多的用户、或是插件设计一团糟，那么要么就没有人开发社区插件、或更坏的，甚至没有人关注你这个软件。

随后，你要把上文提到的配套设施准备完善——无论是有插件和社区开发者基础、或是没有。这样，才能更好的实现上文所提到的良性循环。不过这也不是说一个垃圾文档或者插件市场基础设施的不完善就会毁了这一切——不过几乎可以肯定的一点是，如果你的代码令人血压升高，文档 AI 味溢满屏幕、功能让人 HYW、又几乎没有什么基础设施的建设，那么你这个软件大概率是长久不了的（笑）（x）（狗头保命）

结语

~~所以你到底有没有决定好要不要加插件？~~ 通过上述文字，你或许对以后开发有了更多思考、或是决定加上 / 放弃插件系统的打算。即使你是一个用户而不是开发者、你可能也会对谁的软件有明确的功能设计而谁的软件只是盲目设计一个不完善的插件系统有了更多考量。当然，我并非要拉踩什么软件——也不要对号入座了——不不不这样无疑是老牧师的（生气）（一阵神秘的 BGM 响起了）。不过那与我又有什么关系呢，这里是 OMI，欢↗迎↘下↝次↘光↗临-~