理解是新的瓶颈：为何仍需读懂代码
Understanding is the new bottleneck
我是 Geoffrey Litt，Notion 的设计工程师。随着 AI Agent 编写越来越多的代码，许多人认为人类可以退居幕后。但我认为，理解代码依然是关键瓶颈。理解的目的不仅仅是为了验证 Agent 的工作是否正确，更是为了让我们能作为积极的参与者加入创造过程。如果缺乏对系统的深入理解，我们的创造力将受到限制，并积累难以偿还的认知债务。我分享了三种提升理解力的方法：利用 /explain-diff 生成结构化的解释文档、通过测验来调节理解速度，以及构建微世界（Micro-worlds）来直观体验系统逻辑。最终，我们要利用 AI 来增强人类的理解力，而非取代它。
理解的目的不仅仅是为了验证，更是为了参与。
HN 评论区
237- madrox
我觉得挺有意思的是，普通工程师们正开始发现工程领导和项目管理所面临的挑战。这一直以来都是瓶颈所在。
这就是为什么经理和产品经理想参加每日站会。这就是 Slack 存在的原因，也是工程师们总在上面被不断@的原因。这就是高管们总说不能离实际工作太远的原因。这就是“海鸥式管理”（指管理者像海鸥一样飞来飞去，制造噪音然后飞走）发生的根源。这也是为什么项目管理成了一门专门的职业。
所有那些工程师们曾经讨厌的、让他们无法专注于代码的老板们的行为……他们现在开始体会到另一面的滋味了，并且是在重新发明解决方案，而不是仅仅读一本关于工程管理的书。也许我们会把“项目管理”改名为“理解运维”之类的。
我好奇，如果给 AI 足够的 token 让它来抱怨我们，它会怎么说。
- alecbz
我们让 LLM 为我们生成 PR 的描述，结果大家普遍都不喜欢。它们总是对机械性变更给出过于复杂的描述，而且完全缺乏对背后动机的理解。
另外，自己理解代码的一个巨大原因是为了确保 LLM 没有出错，但如果 LLM 本身就在生成这种“理解”，那这一招就不管用了。
- w10-1
我同意问题所在，但不同意解决方案。
这个问题在 LLM 出现之前就存在了：写出“能跑”的代码，却破坏了底层的模型。因为它能跑，所以听起来总是合情合理，不会引起任何警觉。
只有那些（无论是人还是 LLM）将模型奉为标准的人，才能看出这个“能跑”的解决方案破坏了模型。
（理论上，模型是为了保持可扩展性、灵活性或其他不会被这段能跑的代码立即否定的系统特性，但和往常一样，模型本身也可能是错的。）
LLM 在阐述模型方面并不差；事实上，与 LLM 争论模型到底是什么，反而能澄清很多问题。但 LLM 会欣然接受一连串不一致的陈述作为它们的模型，所以它们不能作为权威。
- euthymiclabs
“我读过代码。”——Mitchell Hashimoto
伟大的代码需要深刻的理解，而智能体（agents）需要卓越的指导。即使在我目前的个人开发工作中，我也无法想象在完全理解之前就提交任何生产代码。我要为我代码的后果负责；这是 AI 智能体无法承担的责任。
- iainctduncan
我迫切地想多读一些关于这个新的/当前的/真正的瓶颈的内容！
瓶颈到底在哪里？在哪？？告诉我！不需要证据，就直接摆出来吧，男人对男人，思想领袖对思想领袖！
- est
我发现链接文章中提到的“读书没用”（来自测验部分）非常有趣
https://andymatuschak.org/books/
它解释了很多东西，而且效果真的很好。
我试着在 ChatGPT 里用了一个简单的提示：
> ...粘贴链接... 给我出一系列测验，看看我是否真的读懂了这篇文章。一问一答，轮流进行。
体验非常有趣。
- MinimalAction
我对标题和这个故事感到惊讶。理解力一直以来都是瓶颈，没什么新鲜的。这个论点大概是说，我们人类应该去理解，以便验证和参与。多么大胆啊！也许我们本该一直这么做……？
- Waterluvian
我喜欢“理解力是新的瓶颈”这个观点。因为如果我们暂时忽略赛博格增强可能带来的恐怖后果，这就意味着下一个挑战是如何更好地教授知识。而改进这一点是如此有价值。
当我发现一位老师、一本教科书或一个互动网站能让某个概念突然“顿悟”时，我对此情有独钟。我活在那些“顿悟”的时刻里。我渴望它。我渴望看到别人也经历这种顿悟。如果理解力成为首要目标，我能有多乐观啊。