AI 写了我大部分代码，我却发现自己解释不了它

AI 让我构建软件的速度大幅提升。这一点在我的 GitHub 上看得出来：9 月初活动突然激增，启动了多个项目，其中一些真的上线了。 这部分没什么可争议的。我可以在一天内从一个想法做到能用的原型。我可以问不熟悉的 API 的问题、生成测试脚手架、在代码库里追踪一个 bug、在不打开二十个浏览器标签的情况下获得架构上的第二意见。自 9 月初以来，我用 AI 构建了一个 Linux 桌面宠物、一个给客户的库存应用、一个用于我写作流程的终端工具、一个可漫游的 3D 图书馆，还有比我可能需要的更多的实验。 AI 也写了其中大部分代码。 在所有这些发布之中，我注意到一件让人不太舒服的事： 我生产软件的能力，比我解释自己所生产的软件的能力，提升得更快。 这让我有点害怕。我不认为使用 AI 会让工作变得虚假。项目能跑，人们在使用它们。让我害怕的是，我把整个工作流都围绕一个问题建立起来——"它能跑吗？"——而几乎从不问另一个问题："我明白它为什么能跑吗？" 这周我清楚地看到了这个差距有多大。 我意识到自己仍然缺失很多计算机科学基础。最大的空洞在于数据如何被存储和检索：哈希表、集合、索引。我现在有一个客户应用跑在 PostgreSQL 上，而我说不清一个索引的代价是什么。这可不妙！ 于是我坐下来开始学哈希表。我搞懂了它们如何存储东西，以及两个键落到同一个槽位时会发生什么。然后我打开 Two Sum——著名的 LeetCode 第一道"简单"题——我的脑子就满了。当晚就停了。 我仓库里的软件处理着我还解释不了的东西。当写代码的工具比你懂得多，而你又从不让它展示它的工作时，就会发生这种事。 在编程助手出现之前，不懂一件事会产生摩擦。如果我不理解异步 JavaScript、数据库事务、Linux 权限或 Python 打包，我最终会撞上一堵墙。 墙很容易看见。不翻过去，你就没法继续推进项目。 墙很烦，但它有用。我必须读文档、检查报错、尝试点什么、错上几次。最终，一个心智模型形成了。 AI 改变了这个反馈回路。现在我可以把报错粘进去，然后得到回复： 问题在这里。改这四行。 很多时候这四行真的管用，感觉好极了。然后你会意识到，五分钟前你解释不了这个 bug，五分钟后你依然解释不了。 报错消失了。墙消失了。知识缺口没有。 我以为自己在避开那个陷阱。我并没有像自己以为的那样避开它。 这两种工作流之间有巨大的差别。第一种： 继续构建。 第二种： 稳定复现它。 写下我认为正在发生什么。 找出这个猜测里哪部分我可以验证。 检查相关代码或日志。 在我真正需要时才向 AI 求助。 弄懂修复为什么有效。 尽可能补一个回归测试。 第一种工作流快得多。我想我们现在都明白这一点，但它也完全绕过了我们的批判性思考。你懂的，就是让我们成为好工程师的那个东西。 第二种让我成为更好的开发者。我一直把大部分时间花在第一种上，所以我正在刻意把一些摩擦加回来。 在我问 AI 为什么某个东西坏了之前，我逼自己写下一个预测。它可以完全错。有时错得离谱。但我必须写下类似这样的东西： 我猜是这个状态更新触发了另一次渲染，重建了对象，导致副作用又跑了一遍。 我猜两个客户端在用过期状态更新同一条记录，后写的覆盖了先写的。 然后我去调查，只有在这之后我才问模型。现在 AI 的回答变成了对我推理的反馈。这更接近旁边坐着一位资深工程师说"你看的地方是对的，但你的心智模型这里偏了一点"，这比一个补丁值钱得多。 我不需要理解每个依赖的每个实现细节。没人需要。但如果 AI 往我的应用里加了一块重要逻辑，我应该能回答： 把我当成六个月后要维护这段代码的工程师，解释给我听。 然后我对着解释读真实代码。AI 生成的代码看起来极其自信，而这份自信会让可疑的决定被轻易略过。 当东西坏了、我终于搞懂原因之后，我尽量不停在"太好了，修好了"。我会问：什么测试能在用户之前暴露它？可能是单元测试。可能是集成测试。也可能诚实的答案是这一层根本没法现实地测，那也行。重点是去想失败模式。 一个 bug 只有在改变了系统之后才更值钱。否则我就是在交两次学费学同一课。 这听起来 painfully obvious，而我并不总是在这么做。当你跑得很快时，很容易选中一个文件说"清理一下"。模型返回更漂亮的版本，测试通过，你就发布了。 但重构恰恰是大量架构理解所在的地方。为什么这个函数和那个对象耦合？为什么这个状态放在这里？为什么这些职责混在一起？所以现在我会先想清楚自己不喜欢一段代码的哪里，再让 AI 改进它。不是"重构这个"，而是我想能说出： 这个模块同时在做持久化、校验和 UI 状态管理。我认为这些职责应该分开。给我几种重组方式，并解释取舍。