可以委托写代码，但绝不能委托理解

一句话点破AI编程的核心矛盾

"Delegate coding. Never delegate understanding."（可以委托写代码，但绝不能委托理解。）这句在Twitter上引发讨论的观点，精准戳中了当下AI辅助编程时代最容易被忽视的陷阱。

当Copilot、Cursor这类工具能替我们生成大段代码时，很多开发者不自觉地把"写代码"和"理解系统"这两件事一起交给了AI。前者可以外包，后者一旦外包，隐患就埋下了。

为什么理解不能被委托

在传统开发流程中，代码本身往往就是开发者理解系统的"真理之源"（source of truth）。你通过一行行敲代码、调试、重构的过程，逐步在脑中建立起对系统的完整心智模型。写代码不只是产出结果，更是一种认知活动。

原文点出了一个关键的连锁反应：

"If code was previously your source of truth for managing understanding, then you need a new source of truth artifact."

意思是——如果过去你依靠代码来管理和承载你对系统的理解，那么当AI接管了写代码这件事之后，你就必须找到一个新的"真理之源"载体。否则，代码还在源源不断地产出，但你对它的理解却在悄悄流失。

理解的流失是隐性的

这种流失危险之处在于它不会立刻暴露。AI生成的代码能跑、能通过测试，一切看起来很正常。直到出现一个棘手的线上问题、一次架构级的重构、或者需要向他人解释设计决策时，你才会发现自己其实并不真正"拥有"这套系统。

**心智模型（Mental Model）**是认知科学中的核心概念，指人脑对某个系统运作方式的内部表征。对开发者而言，心智模型决定了你能否预判一个改动的副作用、能否在没有文档的情况下快速定位问题、能否做出符合系统整体一致性的设计决策。传统编程中，心智模型的建立是一个隐式过程——每次调试一个难缠的bug、手动追踪一条数据流、或者为一个函数想合适的命名，都是在无意识地加固和校准脑中的系统地图。AI代码生成工具绕过了这些"低效"步骤，但代价是剥夺了这些步骤所附带的认知训练。开发者拿到的是正确的输出，却跳过了构建理解的过程。

工作流也需要重构

原文的第二层洞察更进一步：

"If code-centric workflows were how you developed that understanding, then you need new workflows."

过去以代码为中心的工作流，恰恰是你建立理解的方式。既然写代码这个环节被AI接管，那么原来依附于这个环节的"理解生成机制"也随之失效了。你不能指望在减少了亲手写代码的情况下，还能用旧的工作方式保持同等深度的理解。

这意味着开发者需要主动设计新的工作流来弥补理解的缺口，比如：

• 用架构文档、设计决策记录（ADR）作为新的真理之源
• 在委托AI写代码前，先亲手写清楚意图和约束
• 把code review从"检查语法"升级为"重建心智模型"的主动学习环节
• 定期用自己的话复述系统是如何工作的，检验理解是否还在

**架构决策记录（Architecture Decision Record，ADR）**是一种轻量级的文档实践，由Michael Nygard在2011年提出并逐渐被业界广泛采用。每条ADR通常记录：面临的上下文与约束、被考虑过的备选方案、最终做出的决策，以及这一决策的预期后果。ADR的价值不仅在于留存历史，更在于书写ADR的过程本身就是一次强迫性的深度思考——你必须能够清晰说明"为什么不选另一种方案"，才算真正理解了当前的设计。在AI大量生成代码的环境下，ADR可以成为开发者保持理解深度的重要抓手：在让AI动手之前先写ADR，既是给AI的上下文输入，也是开发者向自己证明"我真的想清楚了"的检验机制。

对AI时代开发者的启示

这条观点的价值，在于它没有停留在"AI会不会取代程序员"这种老生常谈上，而是指出了一个更实际的操作层面的问题：分工的边界应该画在哪里。

代码是可交付物，理解是能力。前者可以量产、可以外包；后者是判断力、debug能力和架构决策的根基，一旦丧失就很难通过AI补回来。真正高效的AI协作模式，不是把整个大脑外包出去，而是把重复性的产出交给机器，同时用新的方式牢牢守住对系统的掌控。

换句话说，AI让写代码变便宜了，但也让"保持理解"这件事变得更需要刻意为之。谁能设计出既高效利用AI、又不丢失理解的个人工作流，谁就能在这个时代真正拉开差距。

注：本文基于一条Twitter观点展开分析，原文信息量有限，文中延伸解读为编者结合行业实践的补充。