30 年大学同学会，最容易撞在一起的两样东西，是怀旧和焦虑。

Bryan Cantrill 在 Brown 1996 届同学会上碰到的，正是这组反差：同辈技术人反复聊 LLM 对知识工作、对子女未来的冲击；同一场重逢里，他和 Adam 又借助 Claude，把一款 1993/1994 年写出来的双人对战俄罗斯方块 BattleTris 重新跑了起来。

让人焦虑的 AI，促成了一次很人味的重逢。旧代码、旧同学、旧玩法，二十年没人收拾，最后被一个大模型推了一把。

同学会上的两件事：AI 焦虑，和一款旧游戏复活

这件事的事实并不复杂。

BattleTris 是 Brown CS 学生时代的项目，后来也在 Sun 内部小圈层流行过。它不是商业爆款，也没有改变游戏史。它更像一块程序员青春的化石：X Window、校园机房、局域网对战、工程师之间的玩笑和胜负心，都压在里面。

问题信息
发生了什么Cantrill 和 Adam 借助 Claude，把 BattleTris 移植到 Linux，并让老同学重新玩上
游戏是什么1993/1994 年诞生的双人对战俄罗斯方块，可用“武器”干扰对手棋盘
曾在哪里流行Brown CS，以及后来 Sun 内部的小圈层
为什么沉寂老代码、老系统、老 X Window、迁移成本高，二十年基本没人真正处理
争议焦点LLM 到底是在增强程序员，还是让人把判断交给机器

这类旧项目最麻烦的地方，不是技术多高深。

麻烦在琐碎。依赖旧，环境旧，报错旧。每一步都像清灰：你不知道下一层下面是可运行的代码，还是另一堆陈年债。

过去二十年，他们当然“可以”修好 BattleTris。问题是没人愿意为这点不确定性付出整段时间。

LLM 真正改变的，就是这笔账。

它把“值得不值得动手”的边界往前推了一截。很多遗留代码、内部工具、旧脚本、旧 demo，以前不是不能修，而是不值得修。现在至少有机会被重新拿起来。

Claude 做了什么，也没做什么

Claude 没有独立复活 BattleTris。

Adam、Cantrill 和 Claude 是协作关系。人决定方向，人观察现象，人验证修复。Claude 主要承担的是迁移、排查、解释和缩短试错。

关键技术点出现在真正开打之后：BattleTris 崩溃，报出 stack smashing。

Claude 协助定位到 sendBoard 里的一个老 bug：缓冲区按 sizeof(int) 分配，但写入时用的是 sizeof(unsigned long)。在 64 位 Linux 上，前者通常是 4 字节，后者是 8 字节。老的 32 位 Solaris 环境里没炸，是因为两者大小一致。换到新平台，埋了二十年的雷响了。

这个细节很重要。

它说明 LLM 在遗留代码里有真实价值：读旧代码、猜平台差异、缩小排查范围、解释为什么旧环境没问题而新环境会炸。

但它也说明边界同样清楚：没有人的目标设定、上下文判断和最终验证，Claude 给出的东西只是一串可能有用的路径。它不是项目负责人，也不是责任人。

“工欲善其事，必先利其器。”这句话放在这里很准。器利了，人省力；但器不会替你决定为什么要修 BattleTris，也不会替你承担修错之后的后果。

我不太买账两种省事说法。

一种把 LLM 说成救世主，好像程序员很快只剩下写需求。另一种把 LLM 说成暴君，好像知识工作马上被碾平。BattleTris 这个例子没支撑这么大的结论。

它能支撑的是更窄、也更真实的一点：LLM 正在降低遗留工作、不确定工作、低回报排查工作的启动成本。

这已经足够大。

对技术读者的影响：该用，但别退位

这件事最该影响两类人。

一类是还在写代码、维护系统、处理迁移的开发者。你可以更积极地把 LLM 放进旧代码场景：让它读报错、梳理调用链、列迁移风险、解释平台差异、给出可疑位置。

动作要具体：先让它缩小范围，再自己跑测试；先让它解释假设，再自己看日志；先让它给补丁，再自己做 review。别把“它说得像真的”当成“它已经对了”。

另一类是经历过校园计算机文化、早期互联网项目、内部工具堆积的中年工程师。你们手里可能有一堆“想过要修，但从没排上优先级”的旧东西。现在可以重新评估，不是因为情怀突然变贵，而是修复成本可能变低了。

但别把这当成一键复活机。

目前能看到的，是 LLM 在迁移和排查上很有用；看不清的，是它在缺少测试、缺少领域上下文、缺少维护者记忆时，能稳定做到什么程度。越是生产系统，越不能把验证外包给模型。

接下来最该观察的，不是大模型又会不会写一个小游戏。

该看团队怎么把它嵌进真实流程：

场景合理用法危险用法
遗留代码迁移让 LLM 找兼容性差异，人类验证补丁直接合并模型生成的修改
崩溃排查让 LLM 缩小嫌疑范围，结合日志和测试确认把模型解释当根因报告
内部旧工具维护用 LLM 降低启动成本，决定哪些值得救因为“能修”就什么都修
新人理解老系统让 LLM 辅助读代码，再由维护者校准用模型总结替代真实文档和代码审查

这才是 BattleTris 故事的现实含义。

LLM 没有夺走 Cantrill 和 Adam 的创造力。它帮他们跨过了那些原本让人懒得开始的坎：环境、迁移、崩溃、类型差异。

真正危险的地方也在这里。

工具越顺手，人越容易偷懒。以前你必须痛苦地读代码，现在模型会给你一个看似完整的解释。以前你必须自己判断，现在模型会把判断包装成流畅文本递过来。

机器未必会抢走判断力。更常见的情况是，人嫌判断太累，自己交出去。

所以这篇同学会故事比许多 AI 宣言更有意思。它没有证明程序员会被替代，也没有证明 AI 只会带来好事。它只说明一件小而硬的事：LLM 正在改变人类处理琐碎、遗留和不确定工作的边界。

边界变了，方向、验证和意义还得由人掌舵。

回到开头那场同学会。焦虑是真的，怀旧也是真的。最反讽的地方在于：让他们担心未来的工具，刚好帮他们把过去接了回来。

这不是答案。倒像一个提醒：别神化它，也别妖魔化它。用它，但别从自己的位置上撤下来。