即便你和曾经的我一样，在编程过程中对 semver(语义化版本)十分抵触，你依然可以把开源软件的分发理解为曾经遵循固定步骤的一件事。有一个进行开发的分支，而这个分支往往并不真正适合可靠的工作。接着你会在一段时间内冻结开发（即便在此期间，工作可以在某个新的不稳定分支上继续），修复缺陷，请大家来测试。到了某个时刻，缺陷报告的数量开始下降，你的团队和用户开始相信在接下来的几周里已经不会再轻易发现明显的严重缺陷：于是你把这个分支称为 2.4 或其他什么版本，就此完成。

然而现在，随着 AI 编程的出现，改变的不仅是开发，使用软件这一行为本身也受到了影响：不仅是你能让 AI 对软件做某些修改，软件的接收者本身也能这么做。这一点在那些主要用户群体是程序员的软件领域表现得尤为明显，但总体而言也是如此，因为越来越多倾向于技术的用户都已拥有 AI 访问能力和 coding agents(编程智能体)。

由于这一变化，仅仅拥有一个精雕细琢的稳定分支和一个一切皆在进行中的不稳定分支的想法，可能不再是正确的做法。代码仓库也可以是一个成品，但如果它是一个围绕特定问题展示如何做事的模板，或许会更有用。用户可能会为了适配特定的需求集合、硬件、要解决的特定问题而修改代码。而且，对大众而言过于不稳定或未经验证的东西，对另一群用户来说可能恰恰合适。

以 Redis 为例。数周以来，我一直在迭代一个为有序集合带来显著内存节省的 PR。这项工作如果被接受，将影响每一位 Redis 用户，从那些完全不了解 Redis 如何工作的人，到多年来甚至可能贡献过代码的用户。从微不足道的用例，到那些有序集合上 50% 的内存节省可能意味着每年削减一大笔云账单的用例。对于最后这类用户而言，拥有最终成品（在经历了我为打磨一个“刚好能用”的东西而做的所有测试和设计变更之后，还要冒着它可能根本不会进入代码库的风险）或许还不如从第零天起就拥有一个完成度 95% 的分支来得有吸引力。那是他们可以测试、调整、迭代，甚至针对手头问题进一步特化的代码。

也许 DwarfStar 更能说明代码仓库应该成为好的范例，而非覆盖功能矩阵每一块的成品。在本地推理的场景下，就 DwarfStar 的具体情况而言，你会面对多种 GPU、模型、server mode、agent mode、CLI、SSD streaming(SSD 流式传输)、tensor and pipeline distributed execution(张量与流水线分布式执行)。要在所有地方测试所有东西非常复杂。然而，一旦你有了两个可靠的 tensor parallel graph execution(张量并行图执行)范例，一个强大的 coding agent 就能推断出如何为其他后端/模型组合实现同样的功能。类似地，一旦你有了一个足够好地支持两种模型的引擎，第三种模型就可以用几乎自动化的方式来实现，利用现有代码库作为 coding agents 的护栏来引导实现。

这并不意味着像 DwarfStar 这样的项目不应该开箱即用，而是说它可以专注于非常好地支持一组功能，这组功能可以外推到用户自行覆盖的更多可能场景。这还意味着另一件事：main 和 unstable 已经不够了。许多实验性分支可以成为项目不可或缺的一部分。例如，昨天 Laguna S.1 模型发布了。从纸面上看它很有意思，然而：它真的足够好吗？新的 DeepSeek v4 Flash 检查点会不会让它对 DwarfStar 而言不再那么相关？现在下结论还为时过早。然而，为了共同形成一个判断，发布一个包含该模型实现的分支是一个很好的折中：人们会去尝试，会用他们的 coding agents 去完善它，社区可以共同形成对其是否值得合入的看法。此外，今天我注意到，得益于 DwarfStar 内部代码语料库所形成的轨道，该实现被 GPT 5.6 Sol 在大约两小时内自动编写完成。实现 DS4 和 GLM5.2 曾花费我大量的引导工作，需要阅读模型卡以及那些模型注意力实现的细节。现在它直接就成功了。GPT 5.6 更强大，但它也在现有源代码中找到了大量优秀的范例。

今天的软件比以往任何时候都更具可塑性。在某种意义上，这意味着它可以以更灵活的方式发布。同时，这也意味着文档本身不应仅仅对人类友好，还应让 coding agents 能够理解如何修改系统。这一切究竟会如何演变，以及在稳定性、可用性和功能这些不同维度之间恰当的平衡点会在哪里，对我而言尚不清晰，但我相信我们开发者需要保持关注，看清这一切将走向何方。