理解债：为什么我们应该比模型更累

在智能体驱动的代码生成时代，问题与解决方案之间的距离已缩短至几次提示词（prompts）之间。对于许多开发者而言，这种效率伴随着一个隐藏的代价：与他们交付的代码之间产生了一种日益增长的疏离感。当 AI agent 处理实现过程时，开发者往往绕过了关键的内部过程——即在手动编写代码的过程中传统上会发生的短期记忆、工作记忆和长期记忆的综合过程。

这种现象创造了一种“理解债”（comprehension debt）。虽然生产力的外在表现已经显现——代码写好了，测试通过了，功能上线了——但系统的内部心理模型却变得空洞。正如 Vicki Boykis 所言，当前 AI 编程工具的用户体验（UX）让人联想到老虎机：你拉动杠杆，然后就会以一个可运行的解决方案为形式获得奖励。这种循环与技能保留背道而驰，并可能导致普遍的“脑雾”，使开发者感觉自己失去了对自身代码库的控制。

无摩擦编程的认知成本

编程不仅仅是生成可执行文本的行为；它是一个深度理解的过程。手动实现功能时所涉及的摩擦——查阅文档、与 bug 作斗争、重构笨拙的方法——恰恰是巩固程序员基础的过程。当这种摩擦被移除时，大脑就会停止参与长效学习所需的这种高强度综合过程。

这种转变导致了开发者社区的分歧。一些人认为低级编程技能的丧失是一种自然的演进，类似于从汇编语言转向高级语言。他们认为开发者的角色正在向产品管理、设计和高层编排转移。正如一位评论者所指出的，价值不在于编写代码的能力，而在于让问题“优雅地消失”的能力。

然而，其他人警告说，这是一个危险的权衡。如果不对实现过程进行深度理解，开发者就会成为自己项目的乘客，无法调试复杂的边缘情况，也无法在模型提供的模式之外进行创新。风险不仅在于技能萎缩，还在于“品味”的退化以及批判生成输出质量的能力。

重新引入有意为之的摩擦的策略

为了对抗理解债，开发者开始实施“刻意摩擦”——旨在迫使大脑回到学习和综合的活跃状态的策略。

主动实现与审查

而非让 agent 写出整个功能，一些开发者正在采用“人类优先”的方法：

• 手动编写初稿： 手动编写初始实现，仅将 agent 用于审查和批判。
• 手动集成： 对 AI 建议的更改逐条注释地进行审查，并手动输入它们，而不是直接接受大块的 diff。
• 20 分钟规则： 承诺在求助于 AI agent 之前，至少花 20 分钟努力解决一个问题。

将 AI 作为苏格拉底式导师

与其将 LLM 作为实现引擎，不如将其重新定位为教学工具。这包括：

• 苏格拉底式提问： 要求 agent 对开发者进行提问，询问为什么选择某种特定方法，或者为什么另一种替代方案会失败。
• 文档发现： 使用 AI 指向原始文档和学术论文，而不是提供一个总结性的答案。
• 概念深度钻研： 使用 agent 来解释陌生的代码片段，或者头脑风暴两种竞争性的架构方法，然后对两者进行批判性分析。

结构化参与

一些开发者发现，重构的过程是重新获得心理模型的一种强大方式。通过指导 agent 执行特定的、细粒度的重构——例如“将此 SQL 逻辑移动到新文件”或“参数化这些测试”——开发者仍然是系统结构的架构师，确保代码即使在他们没有输入每一个字符时，也能在脑海中“留存”。

努力的悖论

AI 辅助开发的中心张力在于短期速度与长期能力之间的冲突。这些工具旨在最大化前者，往往以牺牲后者为代价。

"所有这些通过增加摩擦，在短期内抵消了 LLM 生成代码所带来的所谓加速效果，然而，从长长的远期来看，这使我更擅长使用该工具，因为它们巩固了我自己的基础，而不是基础模型的的基础。"

这为现代开发者提出了一个新的准则：我们应该比模型更累。如果 AI 在承担所有繁重的工作，那么人类就没有在成长。为了保持竞争力并具备能力，开发者必须有意识地选择更难的路径——即投入脑力、深度阅读和刻意挣扎的路径——以确保 AI 始终是用于增强能力的工具，而非思维的替代品。