AI 时代，瓶颈在于人的理解

howie.serious

howie.serious 送你一篇内参文章

限时赠阅，剩余约 1 小时

了解 AI 内参

★★★★★ · 🍅 ·Geoffrey Litt

howie

导读

agent 时代，瓶颈在于理解，人的理解。问题在于，很多人不理解为什么理解本身，为什么基础的阅读、思考在 AI 时代反而是最重要的。更不要说踏踏实实每天行动多年积累了。

核心观点

Geoffrey Litt 的核心判断是：即使 coding agent 正在写越来越多代码，开发者仍然需要理解这些代码。理解的首要目的不只是“验收 agent 做得对不对”，而是让人保持在创造循环里，能够继续提出想法、调整方向、和系统一起演化。

这篇长线程的关键转折在于，它把“理解代码”从审查动作提升为参与条件。agent 的自我验证会越来越强，但项目从来不是一个单次 loop，而是很多很多 loop。人在每一轮里能不能参与，取决于心里有没有足够丰富的概念、直觉和共享语言。

agent 写代码越多，人越不能只做验收员

• 作者开头承认现实变化：agents are writing more and more code，开发者越来越难跟上。
• 但“读 diff 每一行”不是唯一理解方式。问题不是人必须回到旧式人工编码，而是要发明更高效的理解方式。
• 许多人给“为什么要理解”的答案是 verify：检查 agent 的工作是否正确、是否符合 spec、架构是否合理。
• 这个答案只覆盖了 thumbs-up / thumbs-down 的判断。它把人放在验收口，而不是创造过程里。
• 更关键的是，agent 会越来越擅长自我验证。agent 不犯错是好事，但如果人只剩下验收角色，人类位置会越来越边缘。

真正重要的是 understand to participate

• 作者提出第二个答案：we can understand to participate。
• 软件项目不是“一次 agent 循环”。真实项目是很多轮 agent 协作，人需要在每一轮里知道下一步可以怎样演化。
• 人对系统的理解，会直接影响他能否提出下一轮想法、识别新的可能性、和 agent 进行创造性互动。
• 如果缺少系统概念、局部机制和设计意图，人仍然可以让 agent 继续生成，但很难流畅地参与项目。
• 这与 Cognitive Debt 相关：短期可以不理解系统细节，长期会像技术债一样反噬。不是因为系统马上坏掉，而是人的参与能力逐渐被掏空。

理解不是自然发生的，需要借用教育方法设计出来

• 作者接着问：在 AI 协作速度很快的情况下，如何建立人类理解？
• 他的思路是回到教育。软件工程里的理解传递，并不是全新的问题；教育领域已经长期研究如何解释、练习和建立直觉。
• 线程介绍三类方法：解释文档、测验、微世界，最后扩展到团队共享空间。
• 这些方法共同点是：agent 不只是写目标代码，也可以写帮助人理解目标代码的工具和材料。

第一类方法：把 agent 产物变成高质量解释 artifact

• agent 完成工作后，本身就是一次解释机会。最朴素的材料是 code diff，但 diff 通常只是按文件名堆叠，不等于解释。
• 作者提出 code explainer docs。他自己的 /explain-diff skill 会输出 HTML、Markdown 或 Notion docs，帮助团队讨论。
• 好解释的第一原则是 background info：还没讲变更之前，先解释原有系统。例如游戏视角改动前，要先介绍 game engine。
• 第二原则是 intuition before details：先讲目标和相关概念，再进入代码。例如“用 2D 绘图技巧让花园显得三维”，以及什么是 isometric projection。
• 第三是 literate diff：把代码差异组织成一篇有顺序的说明文，穿插上下文和代码片段，而不是让读者在 alphabetic file order 里自己拼逻辑。
• 作者说自己仍会读原始 diff，但会先读 explainer packet；有时甚至打印出来专注阅读。这说明 AI 时代的“快”反而需要更好的静态理解材料来承接。

第二类方法：用测验抵抗“以为自己读懂了”

• 解释文档仍然有一个问题：reading is hard work。
• 作者引用 Andy Matuschak 的 “books don’t work” 思路：读完不代表保留，也不代表真正理解。
• 他借鉴 Andy Matuschak 与 Michael Nielsen 关于 spaced repetition quizzes in essays 的工作，在 code explainer 底部放交互式 quiz。
• 测验不是考试形式主义，而是理解校准：读者要回答关于本次变更的五个问题。
• 作者自己的规则是：不能通过 quiz，就不把代码发给别人；审查别人代码时也一样。
• 这是一种 speed regulator。AI 协作很容易让循环速度超过人的理解速度，quiz 机械地迫使人停下来问：do I actually understand?

第三类方法：用 micro-worlds 建立可操作直觉

• micro-worlds 来自 Seymour Papert 的教育思想。Papert 的 Mathland 比喻是：想学数学，最好能生活在一个自然接触数学的环境里。
• 作者把这个想法迁移到代码理解：能不能建立一个人可以“住进去”的环境，通过操作自然理解系统如何运转？
• 第一个例子是 Prolog interpreter。作者不只是让 agent 帮他 debug，而是让 agent 做一个 debugger，让他可以 scrub through time，看 stack、规则求值和执行过程。
• 关键区别在于：让 agent 自己 debug 解决的是结果；人亲自通过工具观察执行，解决的是理解。
• 第二个例子是个人网站框架迁移。Claude 写了迁移脚本，但作者不熟悉新框架，只能说“大概对吧”。
• 他让 Claude 做一个 command center game：自己点击按钮一步步迁移，看旧站、新站和文件树如何变化。
• 这个界面让他以接近手工迁移的方式形成理解，但速度更快，因为体验已经被铺好。

第四类方法：团队需要 shared spaces 和 shared mental models

• 作者最后把问题从个人理解扩展到团队理解。
• 团队协作不只是每个人独立理解代码，而是大家持有相近的 mental model。
• 当两个人有共享模型，就能用同一套词汇、图像和结构快速沟通；没有共享结构，讨论会变得困难。
• Notion 被作者作为 shared spaces 的例子：agent 生成的技术计划天然落在协作页面里，团队可以直接评论和讨论。
• 这里的目标是 thinking together, not alone。AI 工具不应该只把每个人推向自己的 silo，而应该帮助团队同步理解。

结尾：理解代码只是更大问题的一个切口

• 作者收束时说，今天谈的是理解代码，但实际问题更大：humans understand how things work in general。
• AI 越能执行，人越需要理解系统、判断、概念和关系。
• 理解不是为了保留对机器的控制感，也不只是为了抓 bug；理解是人继续参与创造、协作和演化的条件。
• 所以 coding agent 时代真正稀缺的能力，不只是写 prompt 或看结果，而是把 agent 产物转化为人类可参与的知识环境。