不仅是开发，软件的分发方式也将发生改变

即使你像我过去在编程过程中那样对 SemVer 望而却步，你仍然可以将开源软件的分发过程视为一个遵循固定步骤的过程。
开发工作会沿着一条分支进行，而这条分支往往并不完全适合投入可靠的工作。
随后，你会将开发工作冻结一段时间（即便在此期间，工作仍可在另一条新的不稳定分支上继续推进），
修复漏洞，并请用户进行测试。到了某个时刻，错误报告的数量开始下降，你的团队和用户也逐渐相信：
在接下来的几周里，已经不再存在那些容易被发现的、显而易见的重大缺陷了。
于是，你便将该分支命名为 2.4 或其他任何名称，就此告一段落。

然而如今，随着人工智能编码的兴起，不仅开发方式发生了变化，软件使用本身这一行为也受到了影响：
你不仅可以请求 AI 对软件进行特定的修改，软件的接收方同样能够参与其中。
这一点在那些软件的主要用户群体主要由程序员构成的领域中尤为明显，但随着越来越多具有技术倾向的用户能够接触到人工智能工具并使用编码代理，
这一现象也已普遍适用。

由于这一变革，仅仅保留一个经过打磨、一切就绪的稳定分支，以及一个所有内容都处于不断迭代中的不稳定分支，
这种做法或许已经不再是最合适的方式。
代码仓库也可以成为一款成品，但如果它能作为解决某一特定问题时的模板，其价值甚至会更高。
也许用户会根据自身需求、硬件条件或具体要解决的问题，对代码进行个性化定制与优化。
此外，对于那些对大众而言过于不稳定、尚未得到充分验证的方案，或许对另一群用户来说，
恰恰是最佳选择。

以 Redis 为例。在过去数周里，我一直持续推进一项 PR，旨在为有序集合带来显著的内存节省效果。如果这项工作获得通过，它将惠及 Redis 的每一位用户——从普通用户……