使用LLM重写过时的开源项目

大型语言模型（LLM）正在从根本上改变软件开发的成本结构，特别是对于重写现有开源项目这一任务。在过去，重写一个成熟的、经过长期打磨的开源项目可能需要数年时间，因为需要处理数十年积累的边缘情况、平台兼容性和隐含的设计决策。但如今，这些障碍正在被消除。

本文的作者来自一家名为Architect的公司，他们正在经历一场这样的重写。由于使用了LLM的帮助，他们预测对关键工具CRIU（Checkpoint/Restore In Userspace）的重写将在几个月内完成，而不是通常需要的几年。CRIU是Linux上唯一能够实现进程检查点/恢复的工具，它被集成在runc、podman和整个Kubernetes生态系统中。然而，这个拥有十多年历史的项目正在变得陈旧：其代码库是C语言，主页仍然运行着过时的MediaWiki实例，并且维护者面临AI生成的大量补丁和错误报告，这些报告看似正确却需要耗费大量精力审查。

文章深入分析了开源项目为什么会过时。首先，维护者是人，他们的热情会消退。一个项目在初期充满活力，但随着时间推移，维护工作变得乏味，导致核心开发者逐渐离开。其次，世界在变化：Go、Rust、Zig等新语言出现，eBPF和io_uring等新功能被引入内核，但成熟的代码库很难适应这些变化。第三，大型项目往往停止创新，因为稳定性和向后兼容性成为了首要目标，任何大的改动都难以被合并。作者将这种情况与大型公司类比：它们不创新，而是收购创新成果。但开源项目没有这种机制，因此创新必须来自外部。

AI如何改变这种局面？关键在于LLM不仅能够生成代码，更重要的是，现有项目本身成为了一个可用的参考规范。数十年来积累的决策、边缘情况和平台细节，曾经是重写的最大障碍，而现在它们成为了验证新实现的规范。开发者可以利用LLM快速生成符合这些规范的新代码，而无需从头摸索所有细节。AI不能替代架构设计和判断力，但能够显著减少乏味的工作：编写样板代码、处理平台特性、构建测试矩阵等。这使得重写从“不可能”变为“在有限时间内可行”。

回到具体案例。Architect的核心业务是实时迁移工作负载，他们需要一个快速、可预测、能随时修复的检查点/恢复工具。CRIU虽然功能强大，但它的C语言代码库使得集成和优化变得困难。因此，他们决定用Zig重写CRIU。选择Zig的原因包括其现代特性、更好的内存安全性以及与现有C代码的互操作性。利用LLM，他们能够以原始CRIU为参考，快速生成新代码，并针对自己的特定用例进行优化，摆脱了CRIU为了服务于所有可能场景而积累的复杂性。

当然，这并非没有挑战。Kernel接口、精确的进程状态捕获等核心难点仍然需要人工处理。但LLM极大地加快了开发速度。团队计划在几个月内完成重写，而不是通常的几年。这篇文章提供了一个清晰的视角：AI并没有使软件开发变得简单，但它使许多原本代价高昂的任务变得廉价，从而改变了重写旧项目的经济学。