接手的第一个像样的软件项目（至少在当年看来像样），是把一份旧报纸上那款著名的文字版《星际迷航》游戏，移植到上世纪70年代中期的一台IBM 5100“便携”计算机上。我父亲是心脏病医生，是医学界较早提倡使用计算机的人之一，他在工作中就用一台IBM 5100。每逢周末，他会把这台巨兽带回家，我就在上面写代码。

我完全想不起那份印着代码的报纸是从哪儿来的，但第一眼看到就被迷住了。代码是用某种BASIC方言写的——带行号，诸如此类——和IBM 5100上能跑的程序并不完全一样，我只能靠反复试错去弄清两种语言之间的细微差别。我清楚地记得，当时必须搞明白GOSUB在两边的行为有何不同。

我花了好几个月才把它敲进去、调通、跑起来。但我做到了。这话说起来有点俗，可让那个游戏跑起来，是我人生中最激动的时刻之一。真是太酷了。

前不久，Claude Code把那个BASIC程序通过Go转成了WebAssembly，用时不到一分钟。这个游戏确实挺简单，可还是……唉。

这让我开始琢磨：距离我们能用同样的办法处理自己的“大泥球”，还有多久？我大胆猜一句——不会太久。

泥球，智能体却能读懂

我相信大多数人写的代码都很漂亮、好维护。但你们中的一些人——比如我——整天都在维护一个由十几个人在30年里陆续写出来的遗留应用。你大概明白这个系统怎么运转、本该怎么运转，但你几乎肯定不可能理解你所负责的那几百万行代码中的每一行。翻着看的时候，你每分钟蹦出“这什么鬼”的频率相当高。

如果你不是天天跟大泥球打交道，你至少也完全能理解这个概念。

但眼下正在发生的奇妙之处在于，编码智能体能够理解这些大泥球。它们能迅速而轻松地穿过那个3000行、没人愿意碰的过程里那团盘根错节的乱麻；它们能在让你头晕目眩的代码里修好缺陷。我这儿就是如此——正职工作里，我和另一个人一起维护500万行代码。编码智能体大幅加快了我们的速度，大概提升了五倍甚至更多。这真是颠覆认知。

这一切让我忍不住想：如果我们让Claude Code把我们的应用转换成，比如说，Go加Wails，会发生什么？

我们可以让Claude采用现代编码手法，写出干净、模块化的代码，用易于维护和扩展的整洁编码方法重构整个代码库；可以让整个应用的代码风格统一，看起来足够现代；可以让这个应用同时跑在Windows、Mac、Linux以及浏览器里。只要我们的规格说明写得足够周全、对过程的监督足够上心，我们就能造出理想中的代码库。

Spolsky的禁令，今天已不成立

我敢打赌，整件事可以在几周（甚至几天？）内完成，而不是手工干上好几年。为什么不呢？我们有什么可失去的？

从头重写代码，恰恰是Joel Spolsky告诉我们绝对不能做的事。但那是26年前的事了，我要说，Spolsky当时并没有预见到编码智能体。Spolsky的第一条理由是，旧的遗留代码里沉淀着多年的企业知识和各种边界情况的解决方案，这些东西不可能在新版本里重新获得。可这恰恰是编码智能体能够看见、也能够捕获的东西。Spolsky的第二条理由是，全量重写意味着好几年交付不出任何新东西——而重写的速度让这个理由根本不成立了。

再不动手，反而是一种失职

面对现实吧。那个时刻很快就会到来——或许已经到来了——届时不重写我们的大泥球，反而是不负责任的。如果能让编码智能体承担98%的工作来现代化一个遗留应用，并且在一两个人月内完成，那么这件事的商业理由在我看来显而易见。这当然意味着大量测试，但我们同样可以让智能体去做这些测试。

Spolsky在当时是对的——你绝不该用一支软件开发团队去重写你的应用。但现在呢？这件事迟早得做。