摘要：在 AI 代码生成工具大行其道的今天，很多人以为“写代码”已经不再是编程的核心门槛。但真正的开发者都清楚，写只是表面功夫，读懂代码才是决定项目进度和质量的关键。无论是维护老项目、调试复杂系统，还是接手别人留下的遗产代码，最消耗精力的环节都是“构建心智模型”。

【CSDN 编者按】在 AI 代码生成工具大行其道的今天，很多人以为“写代码”已经不再是编程的核心门槛。但真正的开发者都清楚，写只是表面功夫，读懂代码才是决定项目进度和质量的关键。无论是维护老项目、调试复杂系统，还是接手别人留下的遗产代码，最消耗精力的环节都是“构建心智模型”。

作 者 | Ibrahim Diallo 翻译 | 郑丽媛

出品 | CSDN（ID：CSDNnews）

在不少刚入行的开发者眼里，编程似乎就是一件“写代码”的事情。掌握一门语言的语法、熟悉常用框架和库，就能一路敲键盘实现业务需求。而且现在有了大模型（LLM）的加持，想写一段函数、一个模块，甚至一个完整的微服务，简直比点外卖还容易：一句 Prompt，几秒钟就能吐出几百行代码。

可真正在一线写过项目的人都知道，写代码只是冰山一角。真正耗时、耗力、考验功底的环节，往往是读代码。这是很多程序员都心照不宣的“隐性共识”：代码写十分钟，读可能要花一整天。

心智模型：读代码时的“脑内地图”

当我们读代码时，其实是在构建一种“心智模型”（mental model），也是你针对系统运作方式所构造的一张地图：哪些部分最复杂，哪些模块依赖哪些组件，哪里可能有坑。没有这张地图，你看到的就只是毫无关联的几行文本。

我做外包顾问的时候，这种情况尤其明显。通常第一天接手一个完全陌生的项目，需求是修 bug 或加个新功能。一开始，我对这张“地图”必然是一片空白。于是我会先打开首页，看看界面长什么样；再看源码，这到底是 React 写的，还是 jQuery 搞的，抑或用了什么第三方插件；接着搜索代码库，前台要加的那个轮播图是不是别处已经复用过；再顺着 CI/CD 流程看看它的构建、测试和工具链。每发现一点，就像在脑子里往地图上补充一条街道。

这种感觉就像搬去一座新城市。刚开始你只认识小区楼下，走几条街，慢慢搞清楚哪条路通高速，哪家超市最近。等路线越来越多，你才不会每天都迷路。读代码的过程，本质就是在脑海里建立这种“不会迷路”的地图。

一个函数，牵一发而动全身

举个例子，假设我们要理解一个简单函数 getUserPreferences(userId)，它的作用听起来很直白：获取用户偏好。但要形成完整的心智模型，必须弄清楚以下一串问题：

● 这个函数具体在哪里定义？

● 它的返回值是什么？Promise 还是普通对象？数据结构是怎样的？

● 它是直连数据库还是通过 API？

● 有没有缓存机制？

● 如果用户不存在会怎样？抛错？返回空对象？

● 系统里还有哪些地方调用了它？在什么场景下？

● 有没有副作用，比如写日志、触发埋点或修改全局状态？

仅仅理解这一个函数，可能就需要在数据库 schema、API 文档、错误处理中间件以及多个调用点之间来回切换。只有当你把这一张“关系网”建立完整后，才敢安心地去修改它。

为什么“写”比“读”简单？

写代码是“往前走”，铺设一条新路。读代码则是“往回追”，你必须跟随别人留下的脚印，在文件之间跳转、顺着调用链查下去，推测那些没写在注释里的意图。理解一个函数，可能意味着你得打开五个文件。等你把地图补全，才算真正上手。

这也是为什么调试比写新功能更费劲。在 Stack Overflow 上，我们经常能看到这样的评论：“能不能贴一下你写的代码？”——因为如果没有完整过程，别人没法在脑子里加载一个正确的心智模型去帮你定位问题。而所谓的 XY Problem，本质也是用户只描述了症状，没有提供足够的上下文，导致别人没法重建全貌。

甚至在法律界也有类似情况。还记得那位把 ChatGPT 当法律助手的律师吗？他递交的文件里引用了六个根本不存在的案例。大家都问他：为什么不去读一读？答案也是一样的：建立心智模型需要大量时间和精力。他必须查到每个案例，读完并放进更大的法律框架里。但他没做这一步——生成内容很容易，理解内容才难。

读代码不仅是逐行扫视，还包括翻文档、看 Code Review、做 Pair Programming。这些都是帮助我们加快构建心智模型的方法。可无论如何，你还是得亲自“读懂”。这也是为什么开发者总爱说“老代码太烂了，重写一个算了”。

其实老代码未必真烂，只是我们不想花时间去读懂它。

大模型的“双刃剑”效应

这也解释了为什么大模型在编程里既强大又危险。不管 AI 生成的代码是完美无缺，还是满是幻觉，你依然得去读，去追踪它的逻辑，搞清楚它跟系统其他部分的交互，以及可能的副作用。生成的代码越长，你构建地图的时间就越久。只有在彻底读懂之后，你才能发现问题，找出它和系统契合不上的地方，或者那些潜在的“暗坑”。

而 LLM 的无限产出能力，最大诱惑就是让人跳过“阅读”这一步——但这是跳不过去的。你不会希望直接加载别人的游戏存档，然后一进来就是最终 Boss 战吧？继承或生成一堆你没读懂的代码，就是这种感觉。

因此，软件开发真正的瓶颈，不在于“写”，而在于“理解”。

我们缺少的，是“理解的加速器”

到目前为止，我们还没有能让系统心智模型瞬间加载到大脑的“理解版 LLM”。打字速度的问题，我们已经用自动化和生成式 AI 解决了，现在我们能生成自己一生都读不完的代码；但“理解速度”的问题没解决，开发的成本依旧停留在原地：就是有人必须花时间去搞懂。

这对 AI 工具的使用方式有着直接影响。与其让它生成一大坨新代码，不如让它帮我们更快读懂现有代码。与其用“代码行数”来衡量产出，不如看团队能多快地建立起准确的心智模型。

所以，编程的未来也许不是“更快地产生代码”，而是“更快地产生理解”——而这，才是真正难啃的硬骨头。

来源：CSDN一点号