内容
即便你像我在编程生涯中曾经那样排斥语义化版本（semver），你仍然可以把开源软件发行看作过去遵循固定步骤的一件事。有一个分支负责开发，而这个分支往往并不真正适合可靠工作。然后你把开发冻结一段时间（即便与此同时，工作也可以在某个新的不稳定分支上继续），修复漏洞，请大家测试。到了某个时候，漏洞报告的数量开始下降，你的团队和用户开始相信，接下来几周里已经不再有明显、容易发现的严重缺陷：这时你把这个分支称作 2.4 或者别的什么版本，仅此而已。
然而现在，随着 AI 编程的出现，改变的不只是开发本身，软件“被使用”这件事也受到了影响：不仅你可以要求 AI 对软件做某些修改，软件的接收者本身也可以这么做。这在软件的主要用户群本来就是程序员的领域里显而易见，但一般而言也同样如此，因为越来越多技术倾向型用户都拥有 AI 访问权限和编码代理。
正因如此，单纯拥有一个一切都已打磨完善的稳定分支，以及一个一切都在进行中的不稳定分支，也许不再是正确的做法。代码仓库也可以是一个成品，但如果它还是一个围绕某个问题的做事模板，可能会更有用。也许用户会修改代码，把它专门化以适配一组特定需求、硬件或要解决的具体问题。并且，对公众来说过于不稳定或未经验证的东西，对另一类用户来说也许正合适。
以 Redis 为例。最近几周，我一直在迭代一个 PR，它能为有序集合（sorted sets）带来显著的内存节省。如果这项工作被采纳，它会影响 Redis 的每一位用户——从那些根本不了解 Redis 如何工作的人，到那些也许在多年里甚至贡献过代码的用户。它适用于从极其简单的用例，到那种有序集合节省 50% 内存、每年都可能为云账单砍掉很大一块开销的场景。对后一类用户来说，最终成品（在我为打磨一个“能用就行”的方案而进行的所有测试和设计修改之后，而且还有可能它甚至不会进入代码库）也许不如从第一天起就有一个 95% 完成度的分支更有吸引力。那是他们可以测试、适配、继续迭代、甚至针对手头问题进一步专门化的代码。
也许 DwarfStar 是一个更能说明问题的例子：代码仓库应该更像优秀示例，而不是覆盖功能矩阵每一项的最终成品。对于本地推理而言，在 DwarfStar 的具体场景中，你会面对多种 GPU、模型、服务器模式、代理模式、CLI、SSD 流式传输、tensor 和 pipeline 分布式执行。要把所有东西都在所有地方测一遍，是很复杂的。然而，一旦你有了两个扎实的 tensor parallel graph execution 示例，一个强大的编程代理就能推断出如何在其他后端/模型组合上实现同样的东西。类似地，一旦你的引擎已经很好地支持了两个模型，那么第三个模型就几乎可以自动实现，利用现有代码库作为编码代理的护栏，从而引导实现过程。
这并不意味着像 DwarfStar 这样的项目不应该开箱即用，而是说它可以专注于把一组特性支持得非常好，而这组特性又能外推到更多用户自行覆盖的情境。这也意味着另一件事：主分支和不稳定分支已经不够了。许多实验性分支可以成为项目不可分割的一部分。比如昨天发布了 Laguna S.1 模型。纸面上看它很有意思，不过：它真的会足够好吗？新的 DeepSeek v4 Flash checkpoints 会不会让它对 DwarfStar 来说变得不那么重要？现在下结论还太早。不过，为了集体形成一个判断，发布一个包含该模型实现的分支是个很好的折中：大家会去试，用自己的编码代理去打磨它，社区可以共同形成对它是否值得合并的看法。而且今天我还注意到，多亏了 DwarfStar 内部代码语料形成的“轨道”，这个实现竟然是由 GPT 5.6 Sol 自动在大约两小时内写出来的。实现 DS4 和 GLM5.2 花了我很多精力去引导、阅读模型卡，以及研究这些模型注意力机制实现的细节。现在它只是顺利跑通了。GPT 5.6 更强大，同时也在现有源代码里找到了许多很好的示例。
如今的软件比以往任何时候都更具可塑性。从某种意义上说，这意味着它可以以更流动的方式发布。与此同时，这也意味着文档本身不应只对人类有用，还应该让编码代理能够理解如何修改系统。这个演进最终会如何展开，以及稳定性、可用性和功能这些不同维度之间怎样才算平衡，我并不清楚；但我相信，我们开发者需要睁大眼睛，看看这一切将走向何方。