即便你和曾经的我一样，在编程工作中对语义化版本颇为排斥，你大概也会觉得，开源软件的分发曾经遵循着一套固定的步骤。有一个专门用于开发的分支，而这个分支往往并不适合直接拿来可靠地工作。接着你会在一段时间内冻结开发——即便与此同时，新的不稳定分支上仍可以继续推进——集中修复缺陷，请大家来测试。当缺陷报告的数量开始下降，团队和用户都开始相信，在接下来的几周里已经不会再轻易发现明显的关键问题时，你就会把这个分支命名为 2.4 或其他什么版本，然后发布，流程到此结束。

但如今，随着 AI 编程的出现，改变的不仅是开发，就连使用软件这一行为本身也受到了影响：不仅你可以让 AI 去对软件做某些修改，拿到软件的人同样可以这么做。在那些主要用户就是程序员的领域，这一点尤为明显，但在更广泛的范围内也是如此，因为越来越多懂技术的用户已经能够使用 AI 和编程智能体。

正因为这一变化，仅仅维护一个打磨完善的稳定分支，再加上一个一切都处在进行中的不稳定分支，或许已经不再是正确的做法。代码仓库固然可以是一个成品，但如果把它当作围绕某个问题来做事的模板，或许会更有用。用户可能会为了适配特定的需求、硬件或要解决的具体问题而去修改代码。而且，对大众而言过于不稳定或未经验证的东西，对另一部分用户来说可能恰恰正合适。

以 Redis 为例。几周以来，我一直在迭代一个能为有序集合带来显著内存节省的 PR。如果这项工作最终被接受，它将影响到每一位 Redis 用户，从那些完全不了解 Redis 内部原理的人，到多年来甚至为其贡献过代码的用户；从微不足道的使用场景，到那些在有序集合上节省 50% 内存就意味着每年能从云账单上砍掉一大笔开支的场景。对于最后这类用户而言，相比于拿到经过反复测试和设计打磨、做到“开箱即用”的最终成品——而且还冒着可能根本无法合入代码库的风险——从一开始就拿到一个完成度 95% 的分支，或许反而更有吸引力。这是他们可以去测试、调整、迭代，甚至为手头的问题进一步特化的代码。

也许 DwarfStar 更能说明，代码仓库应该成为好的范例，而不是试图覆盖功能矩阵中每一个角落的成品。以 DwarfStar 这种本地推理的场景为例，你需要面对多种 GPU、多种模型，以及服务端模式、智能体模式、CLI、SSD 流式加载、张量与流水线分布式执行。要在所有地方测试所有组合非常复杂。然而，只要你有了两个可靠的张量并行图执行示例，一个足够强大的编程智能体就能推断出如何为其他后端/模型组合实现同样的功能。同样，只要引擎已经对两个模型支持得足够好，第三个模型的实现几乎就可以自动完成——利用现有代码库作为编程智能体的护栏来引导实现。

这并不是说像 DwarfStar 这样的项目不需要开箱即用，而是说它可以专注于把一部分功能做得非常扎实，而这些功能又可以被外推到更多场景中，剩下的则由用户自行补全。这也意味着另一件事：只有 main 和 unstable 两个分支已经不够了。大量实验性分支完全可以成为项目的有机组成部分。比如，Laguna S.1 模型昨天刚刚发布。从纸面上看它很有吸引力，但是：它真的足够好吗？新的 DeepSeek v4 Flash 检查点会不会让它对 DwarfStar 而言变得不再重要？现在还很难说。不过，为了让大家共同形成判断，发布一个包含该模型实现的分支是一个不错的折中：大家会去尝试，会用自己的编程智能体去完善它，社区也能集体判断它是否值得合入。更有意思的是，今天我注意到，得益于 DwarfStar 现有代码所形成的“轨道”，这个实现被 GPT 5.6 Sol 在大约两小时内就自动写完了。之前实现 DS4 和 GLM5.2 时，我需要做大量的引导，还要阅读模型卡片以及那些模型注意力机制的实现细节。而这一次，它直接就跑通了。GPT 5.6 确实更强大了，但它也在现有源码中找到了大量可供参考的优质示例。

今天的软件比以往任何时候都更具可塑性。某种意义上，这意味着它可以以更流动的方式发布。同时，这也意味着文档不应仅仅对人类友好，还要让编程智能体也能理解如何去修改系统。这一切究竟会如何演变，以及在稳定性、可用性和功能丰富度这些不同维度之间，平衡点究竟在哪里，我现在还看不清楚，但我相信，我们开发者需要保持开放的视野，去关注这一切将走向何方。