写代码免费了，读代码却更贵了

凌晨两点，你盯着同事写的三千行工具函数，突然意识到：AI 能一秒生成这些代码，但你得花三小时才能看懂它到底在干什么。

这不是错觉。过去半年，我和十几位技术负责人聊过同一个现象——当写代码的成本趋近于零，"好代码"的定义正在被重写。

从"写两遍"到"看一遍"

以前加个接口（interface）常被怼："同样的功能写两份代码，维护量翻倍。"

这话没毛病。接口文件 + 实现文件，两个地方改，两处风险。Ruby on Rails 社区甚至把"约定优于配置"捧成信仰：机器能猜到的，人何必啰嗦？

但一位 CEO 的话点醒了我：

「抽象接口几个月前还让人头疼，就因为得写双倍代码。但 AI 让代码行数变得免费。我们仍然需要这些结构，是因为最终还得有人读代码。接口降低的是认知负荷。」

写代码的成本崩了。读代码的成本纹丝不动。这个不对称，正在颠覆我们对"抽象"的全部理解。

你的大脑才是瓶颈

1988 年，教育心理学家 John Sweller 提出认知负荷理论（Cognitive Load Theory）。2022 年 ACM 的一篇综述追踪了它在计算机教育中的应用。

人脑处理信息时扛着三种负荷：

内在负荷——问题本身的难度。外在负荷——噪音，混乱的组织、多余的细节、糟糕的命名。相关负荷——好东西，建立有用心智模型的脑力投入。

关键限制：工作记忆一次只能容纳 2 到 6 个信息块。不是 2 到 6 个文件，不是 2 到 6 个类，是 2 到 6 个"东西"。

Felienne Hermans 在《程序员的大脑》（2021）里论证：设计模式本质是"组块化"（chunking）工具。认出 Strategy 模式，大脑把整个类层次结构压缩成一个认知单元。"Strategy"这个词替代了五个类及其关系。这不是"整洁代码"的空洞口号，是人脑记忆的实际运作方式。

2021 年，Norman Peitek 和 Janet Siegmund 团队的 fMRI 研究在 ICSE 拿下 ACM SIGSOFT 杰出论文奖。他们把开发者塞进脑扫描仪，观察读代码时的大脑活动。

发现：语义层理解——明白代码做什么——比自下而上的语法解析——追踪它怎么做——所需的神经激活显著更少。

接口让你停留在语义层。UserRepository.findById(id) 告诉你足够的信息，而不必钻进去看 SQL 怎么拼、连接池怎么取、异常怎么抛。

AI 加速了生产，也放大了混乱

以前写接口是奢侈，因为人力贵。现在 AI 能批量生成实现，人力从"写"转向"审"。

但审的成本被低估了。一个团队告诉我，他们用 Copilot 两周生成了过去半年的代码量，然后花了五周做代码审查和重构。净效率？几乎为零。

问题不在于 AI 写得差。在于它写得"足够好"——能跑，但结构随意，命名凑合，上下文散落在十几个文件里。

人类审阅者被迫承担全部的外在负荷。没有接口隔离，没有抽象层，你得一行行追踪数据流，重建作者（或 AI）的意图。

那位 CEO 的观察因此成立：抽象结构的价值从"减少编写工作量"转向"减少阅读理解工作量"。这是 180 度的重心迁移。

新权衡公式

旧公式：抽象成本 = 编写时间 × 2，收益 = 未来维护节省

新公式：抽象成本 ≈ 0（AI 写），收益 = 每次人类阅读节省的认知负荷 × 阅读次数

当阅读次数趋近于无穷（微服务、开源库、团队流动），抽象的收益被无限放大。

我看到的团队在调整实践：

接口前置。以前先写实现、后补接口，现在反过来——先定义契约，再让 AI 填充。人类守住边界，机器处理内部。

文档即代码。不是事后补注释，是把设计意图写成可执行的类型定义、测试用例、架构决策记录（ADR）。AI 读这些约束，生成符合上下文的实现。

审查聚焦结构。不再纠结变量命名（AI 能改），重点看抽象层是否清晰、职责是否单一、依赖是否倒置。

一个未被回答的问题

认知负荷理论诞生于前 AI 时代。它假设"人类是信息处理瓶颈"。

但如果 AI 也能"阅读"——不是语法解析，是真正的语义理解——这个瓶颈会不会转移？当机器能生成、能审查、能解释，人类在代码生命周期里的角色会收缩到什么范围？

我们还在用 1988 年的大脑模型做 2024 年的技术决策。这本身可能是最大的认知负荷。