陶哲轩最近做了一件很适合拿来校准 AI 编程预期的事。
他把自己 1999 年写的一批 Java 1.0 数学可视化 applet，交给现代 AI coding agent 移植到 JavaScript。那些 applet 原本用于复分析、线性代数教学，也包括 honeycomb、Besicovitch set 这类数学对象的可视化。后来浏览器不再支持旧 Java，它们就逐渐失效。
这次移植花了几个小时。约二十多个旧 applet 重新可用，Besicovitch set 还从单色变成彩色；那个他和 Allen Knutson 在 1999 年合写、当年手工实现很麻烦的 honeycomb applet，也重新跑了起来。
更有意思的是 bug 数量。陶哲轩说，LLM coding agent 当然可能写出明显或隐蔽的错误，但这批移植里，他只发现一个小问题：某个复分析 applet 在拖出主区域时行为异常。同时，agent 还指出了原始代码里两个他之前没注意到的 bug。
这批 applet 的特殊之处在于：有旧代码，有可见输出，也有明确风险边界。AI 可以多做一点，人也能很快判断它做得对不对。
高手不是把判断交出去
这批 applet 适合交给 AI，不是因为任务简单，而是因为验证条件好。
旧代码在那里，目标很明确：从 Java applet 移植到现代浏览器能运行的 JavaScript。输出对不对，不需要相信模型自述，直接打开页面、拖动图形、看数学对象是否呈现正确。尤其是陶哲轩本人知道这些对象应该长什么样，错了很容易被看见。
这和很多人用 AI 写代码的方式不同。普通使用者常常只给一句模糊需求，然后把模型生成的实现当作答案。出了问题，再让模型解释模型刚写的代码。整个过程里，人既没有清楚的规格，也没有独立验证能力。
陶哲轩的优势并不只是数学强，而是他在进入对话前，已经拥有三样东西：知道自己要复活什么；知道结果应该如何表现；知道错误的影响范围在哪里。
AI 在这里像一个执行力很强的助手。它把繁琐移植、事件处理、图形 API 改写这些工作快速做完，但每一步能不能成立，仍然要回到人的判断。
AI 最先放大的是定义问题的人
这也是 AI 编程让人产生错觉的地方。
它看起来降低了写代码门槛，实际上先奖励的是会拆任务、会验收、会设边界的人。一个人越能把需求拆成可运行、可观察、可回滚的小块，Agent 越容易发挥价值。反过来，如果需求本身是一团雾，Agent 只会更快地产出一团看似完整的雾。
这批数学可视化 applet 的风险等级并不高。它们是辅助工具，不是论文证明本身。一个拖拽事件的小 bug 会影响体验，但不会改写数学结论。这种风险边界，正适合让 Agent 多做一点。
很多团队的问题正好相反：把 AI 直接推到核心业务路径上，却没有测试、没有日志、没有回滚，也没有人能解释生成代码为什么这样写。工具越快，债务积累越快。
把一个旧项目交给 Agent 之前，可以先做四项核对：有没有可运行基线；输出能不能被人或测试直接观察；改错后能不能回滚；失败是否不会进入核心业务链路。四项里缺两项，就不适合让 Agent 大步快跑。
所以开发者更稳妥的顺序，是先让 Agent 做迁移、重构、脚手架、可视化、测试补全；人保留规格、验收和风险判断。
AI 编程不会自动让人变强。它更像一面放大镜：问题定义清楚的人，会被放大；问题定义混乱的人，也会被放大。
