别再只顾着跑代码了，你在背负「认知债」吗？
最近，软件架构界的「教父」Martin Fowler 的官网上发了一篇重磅文章，作者是 Thoughtworks 的资深工程师 Unmesh Joshi。文章标题很朴素，就叫《什么是代码？》（What is Code?）。
在这个大模型（LLM）几秒钟就能生成几百行代码的时代，问这个问题似乎有点「复古」。大家都在讨论怎么写更精准的 Prompt，怎么让 AI 直接帮我们把功能跑起来。
但读完这篇文章，我挺有感触的。我意识到，我们可能正在以前所未有的速度，透支着软件系统的生命力。
代码的双面性：指令 vs 模型
Section titled “代码的双面性：指令 vs 模型”Unmesh 在文中提出了一个非常深刻的观点：代码其实有两个互不相同的维度。
- 它是给机器看的「指令集」：告诉 CPU 怎么算、告诉内存怎么存。
- 它是给人类看的「概念模型」：定义了系统的边界、实体的名字、以及它们之间的逻辑关系。
长期以来，我们衡量一个程序员的生产力，往往看的是第一部分——你能写出多少可执行的代码？
但现在，第一部分正变成一种「大宗商品」。
如果你只把代码看作指令，那么 LLM 确实可以替代你。甚至，它比你写得更快、更少 Bug（在某些固定场景下）。
然而，真正的价值，往往藏在第二部分：词汇（Vocabulary）。
词汇：代码中的「权力」
Section titled “词汇：代码中的「权力」”为什么 Martin Fowler 被称为「软件植物学家」？因为他最擅长的事情，就是观察那些「野蛮生长」的优秀工程实践，并给它们起名字。
比如「重构」（Refactoring）、「微服务」（Microservices）。
这篇文章也延续了这种「命名」的力量。Unmesh 认为，一个设计良好的代码库，其实就是一套明确的词汇表。
你在银行系统里定义 Account（账户）、Transaction（交易）；在零售系统里定义 Sku、Order。这些名字不仅仅是变量名，它们承载了业务的约束和设计的后果。
写代码的过程，本质上是一个翻译过程：把复杂的业务领域词汇，映射到技术的词汇（比如 Repository、Workflow）上。
这种映射，往往不是一蹴而就的。它需要你不断地打磨、重构，最终才能让代码像文章一样易读。
最可怕的陷阱：认知债（Cognitive Debt）
Section titled “最可怕的陷阱：认知债（Cognitive Debt）”这是文中让我印象最深的一个新词。
在 LLM 时代，我们可以轻而易举地让 AI 生成代码。但问题在于：代码生成的词汇速度，往往远超开发者建立理解的速度。
这就是认知债（Cognitive Debt）。
当你把一段 AI 生成的代码粘贴进系统，虽然它跑通了，但你并没有真正构建起对这些新引入的「名字」和「边界」的心智模型。
久而久之，你的系统里充满了各种「黑盒」。每个人都敢加代码，但没人敢动旧逻辑。因为没有人能说清楚，系统里的那些概念到底是怎么交织在一起的。
技术债（Technical Debt）可能只是让系统变慢，但认知债会让系统彻底失去演进的能力。
程序员的新角色：词汇的架构师
Section titled “程序员的新角色：词汇的架构师”如果 AI 承包了「指令」的生产，那程序员该干什么？
答案是：去做词汇的架构师，去构建那套防御性的「安全带」（Harness）。
Unmesh 在文中提到，我们需要通过测试驱动开发（TDD）等方式，在写代码的过程中不断地去「发现」那些局部概念。
在 AI 时代，代码库不应该是一个指令的垃圾场，而应该是一个共享的、显式的概念模型。
那些高水平的代码抽象，就是防止 AI 在生成代码时滑向混乱的「安全带」。
写代码不只是在表达逻辑，更是在探索真理。
正如文中所说：“写代码的行为不仅是表达，更是发现的过程。”
如果你发现自己现在的日常就是机械地在 Prompt 和 Ctrl+C/V 之间循环，那可能需要停下来问问自己：
在这个由代码构建的世界里，我是在建立秩序，还是在堆积债务？
思考题： 你在使用 AI 辅助编程时，感受到过这种「认知债」吗？欢迎在评论区聊聊。