有人问我：这套 AI 工具能不能改成我们自己公司用的？
我说能，但你别先动它源码。
他以为我在开玩笑。MIT 协议、几万 star，fork 一下想怎么改怎么改，凭什么不能动。
一、官方文档写得很硬
我把开发者文档翻给他看。里面有一句：替换或包装核心函数、方法、模块属性、私有字典，不属于受支持的扩展点。
不是「不建议」，是「不支持」。插件想进官方目录，有一项专门检查叫 no core override，命中直接拒。
理由不难理解：核心是别人在维护的，你改了它，下次上游一升级，你的改动要么冲突、要么被静默覆盖。改得越多，越没法升级。
二、它把「改」拆成了十几个有名字的口子
把文档从头翻到尾，能挂东西的地方是有一张对照表的，左边写「你想加什么」，右边写「去看哪一页」。常见的几类：
- 工具、钩子、斜杠命令、技能 → 通用插件
- 新的消息平台 → 平台适配器
- 记忆后端、上下文压缩 → 各自有独立 Provider 接口
- 桌面端面板、状态栏、命令 → 桌面 SDK
- 新的模型后端 → Model Provider
图像生成、视频生成、联网搜索、云浏览器、子代理、终端环境、密钥管理，也各有独立文档页，不是一句「自行扩展」打发你。
这里有个反直觉的点：口子多，不等于都该用。 每接一个扩展点，就多一份要跟着上游维护的东西。能不接就不接。
三、什么时候才真的需要 fork
三种情况，我们认：
- 身份类改动——名字、图标、安装标识（appId）。这类东西散落在各处，没有扩展点，只能改。做法见陆吾这个案例。
- 合规类改动——必须切断某个外部上报或自动更新，且官方没有开关。
- 上游已经停更，你接手维护。
除此之外的需求，九成可以在扩展点里做完。
四、怎么判断一个开源项目值不值得改
- 看文档有没有「扩展点清单」，而不是只有「如何编译」。
- 看它有没有检查核心覆盖的机制（
no core override这种）。有，说明作者认真想过别人怎么改。 - 看许可协议：MIT 允许改名商用，但要保留署名。
- 看上游还活不活：半年没提交的项目，改它就等于接手维护。
这些判断我们给客户做技术选型时都会过一遍，具体口径写在企业 AI 应用那页。
一句话：能配置的别改代码，能扩展的别 fork，真要 fork 就把身份类改动和业务改动分开，前者改代码，后者走扩展点。