AI 编程：从能跑到真懂

用 AI 写代码的晚上，常常出现两种截然不同的结果。一种是我一口气做出好几个功能，代码跑通了，但回头一看，其中一半我说不清是怎么实现的。另一种是我花几个小时卡在一个小问题上，最后学到的东西反而比前面一整晚都多。两次都算有产出，两次都得到了能跑的代码，但真正留下的东西完全不同。

我几乎每天都在用 AI 编程工具，它们确实帮我做了很多原本不会尝试的东西。但我也一直在想一个问题：把功能做出来，和弄明白它为什么能工作，中间隔着一大段距离。

有时候我让 AI 解释一段代码，它讲得条理清楚，每一部分在做什么我都跟得上，当时觉得懂了。三天后需要改点东西，再打开那段代码，却像从没见过一样。问题不在于我记不住语法或者某个 API 的细节，那些随时可以查。问题在于我说不出当初为什么这样写。如果我对一个功能的全部记忆只是“AI 写的，能跑”，那基本等于没学到什么。

最近我在做一个叫 Slate 的文本编辑器，里面有个细节让我印象很深：在文件还在编辑的时候执行保存，会发生什么。保存听起来简单，把内容写到磁盘，标记为已保存，结束。但如果用户在保存过程中继续打字呢？写进文件的是旧内容，编辑器里却已经有了新改动。保存完成后如果直接清掉未保存标记，就等于告诉用户一切已保存，而实际上并不是。

Slate 用基于修订版本的保存跟踪来处理这件事：保存开始时记住当前文档的修订版本，这样保存期间产生的新改动就不会被误标为已保存。AI 完全可以替我把这套逻辑写完，我点一下保存按钮，看到它能用，然后继续做别的。但理解为什么需要这个修订跟踪，才让这段代码对我有意义。它真正教给我的不是某一行实现，而是一个更普遍的情况：一个操作从开始到结束之间，状态可能已经变了。这个问题不只出现在文本编辑器里，很多应用都会遇到。

本地运行 AI 模型时也有类似的体会。比如一个任务跑了 30 秒，第一反应是“慢”。但 30 秒到底花在哪了？是加载模型占了大头，还是推理本身慢？再跑一次会不会快很多？这些都可以动手测。比起直接问 AI“为什么慢”，自己跑一遍、把各阶段分开计时、改一个条件再看结果，学到的东西要多得多。有时候结果和预期一致，有时候完全相反，而后者往往更有意思。AI 可以帮我分析该试什么、为什么结果不符合预期，但“AI 告诉我应该发生什么”和“我亲眼看到发生了什么”是两回事。何况 AI 的解释本身也可能出错。

真正花时间弄懂一个问题之后，我通常记不住具体代码，但会记住问题本身和当时的解决思路。这种记忆会迁移到别的项目里：我会想到某个异步操作有没有可能在用户已经改动之后才完成，会怀疑一个性能问题其实出在启动阶段，会检查自己是不是存了一份本可以算出来的状态。具体实现可能还要查资料，也可能还是让 AI 帮忙写，但至少我知道自己在找什么、为什么它重要。如果只是接受生成的代码而不多想，解决方案就摆在那里，换个场景再遇到同样的问题，我可能根本认不出来。

当然，不是每件事都值得变成学习机会。有时候我只是想让 AI 把按钮的内边距调好，不需要花四十五分钟研究 CSS 间距的原理。样板代码、重复修改、已经做过一百遍的事，交给 AI 完全没问题，这本来就是我用这些工具的原因。但在接触不熟悉的东西、或者做以后还要维护的功能时，我会让自己多参与一点。有时只是多问几个问题，有时是直接改点东西看反应。哪怕只是在下手之前先预测一下改动会带来什么结果，也有帮助：结果和预期不符，就有了可以追查的线索。

我并不是每次都这么做。有时候盯着一个问题两个小时，AI 终于把它跑通了，我满脑子只有“谢天谢地，继续下一个”。但我在试着分清什么时候是在学东西，什么时候只是在推进度。这两件事并不总是一回事。

AI 编程工具最让我喜欢的一点，是它让我更愿意去碰那些几乎不了解的领域。语言、框架、本地模型、桌面应用，换作以前我可能会一拖再拖，不是因为学不会，而是从零开始的门槛太高。AI 把这道门槛削低了很多，这是实打实的好处。但随之而来的是一种惯性：一个功能跑通了，就去做下一个，再做下一个，不知不觉整个应用建起来了，其中一些挺重要的部分却只有模糊的理解。很容易把这种进度当成学习。

我印象最深的，往往是那些不得不去查一查的东西：某个行为不符合预期，或者我好奇它为什么这样工作，于是花时间弄明白。有时只花几分钟，有时耗掉一整晚。不管哪种，都比一次就成功的功能记得更牢。我不想因此停用这些工具，也不想故意把每件事都弄难，只是不想在建得太多太快的时候，忘了留意自己到底学到了什么。