破坏性调整

最近对项目的整体架构做了一次比较彻底的重新审视。说是破坏性调整，倒不是因为有什么紧急的问题要修，而是项目推进到当前阶段，一些早期埋下的设计选择开始显露出不太合理的地方，趁现在体量还小、几乎没有用户负担，赶紧把它们掰正。

Octopus 与 Squid 的合并

一直以来，我维护着两个后端：开源的 Octopus 和闭源的 Squid。起初这么分是因为两者面向的场景不同，Squid 承载了一些不便公开的业务逻辑，单独拉一个仓库似乎顺理成章。但维护的时间越长，问题就越明显——两套代码虽然共享大量基础能力，却各自独立演化，修一个 bug 往往要在两边各改一遍，新功能的同步更是让人头疼。

这次调整的思路是：与其维护两套平行的代码，不如让它们变成一层核心加一层补丁。具体来说，我对齐了 Octopus 和 Squid 的接口与核心逻辑，然后把 Squid 重新定位为 Octopus 之上的一个叠加层——你可以把它理解成一个认证网关，或者一组功能补丁，它在 Octopus 的基础上追加闭源场景所需的额外能力，而不再是一套独立的系统。

这样一来，日常维护的重心就完全落在 Octopus 这个核心库上，Squid 只负责它那薄薄的一层差异。代码不再分叉，精力不再分散。

知几将不再提供 SaaS

另一件事是关于知几，也就是我一直在做的体细胞分析平台。

之前我的设想是把它做成一个 SaaS 服务，用户按量付费，后端统一托管。但随着项目逐渐成形，我发现这条路对体细胞场景来说并不好走。核心问题是：体细胞的 Panel 和遗传全外相比，多样化程度太高了，数据量也完全不可控。全外显子组测序好歹有一个相对固定的靶向范围，体细胞 Panel 则各有各的设计，不同 panel 覆盖的基因区域差异巨大，上游数据产出的波动也大得多。在这种条件下设计一套合理且透明的计费模式，难度远超预期，甚至可能根本不可行。

与其在一个不适合的模式上硬撑，不如把决定权交还给用户。我决定后续不再为知几提供 SaaS 服务，而是将它完全开源，让有需要的人自行部署。自部署意味着用户对自己的数据和计算资源有完整的掌控，也就不存在计费粒度、数据量核算这些 SaaS 模式下绕不开的问题。

目前知几仍在构建中，没有线上用户，所以这个决定不会对任何人造成影响——只是我自己在岔路口做了一个方向选择。

---

这两个调整本质上是同一件事：把精力集中在真正值得长久维护的东西上。Octopus 是那个内核，开源的工具平台是那个方向。专注做少一点事情，然后把它们做好。