"构建速度超过理解速度"是什么意思？
简单说，就是你做出了一个能跑的东西，但你没跟上它的原理。
这周拎出来讲，是因为 Mark Seemann 三天前在 blog.ploeh.dk 发了一篇公开信，回一位读者的提问。这是我近段时间看到最实在的一篇，讲 LLM 和学编程的关系。
先把那位读者交代清楚。
他没有计算机科学背景。一年时间，用 LLM 搭了一个不算小的 TypeScript/JavaScript 系统。里面有 API、PostgreSQL、LLM 流水线、研究自动化、多模型工作流。
他的说法是，一开始像变魔术。一个想法到它真的跑起来，中间那段距离被抹掉了。
然后他把它往生产上推。
问题不是一个个来，是一串来。修好一处，另一处冒出来。有几个模块的行为，他自己也说不清。
几个月重构之后，他意识到一件事：这个系统可能超出了他自己的理解水平。
平时它跑得好好的，落差看不出来。一出故障，落差全露出来。
他后面那句才是重点。他说有时候不知道下一步该干嘛，除非再去问另一个模型。于是他开始怀疑，自己造的到底是一个产品，还是产品的外观。
我讲这段，不是当反面教材。他在信里写得很清楚，不反对 AI，对这套东西着迷，想以此为职业。他真正在问的是另一件事：人和 AI 之间该是什么关系。
Seemann 没给漂亮答案。
他先说实话。他说自己对 AI 还没有最终立场，情感上偏向不喜欢它，同时承认这股趋势大概挡不住。
我欣赏这个开头。一个作者肯先把自己的位置说清楚，后面的判断才有人信。
然后是整封信里我唯一想抄下来的一句。
Seemann 提了一条经验法则：理解你自己所在抽象层的上面一层和下面一层，通常够排查大多数问题。
这话不新鲜，放在这个语境里很准。那位读者的系统里，LLM 流水线是一层，PostgreSQL 是一层，多模型编排又是一层。他站在最上面，下面每一层只能靠猜。
他的问题不是不会写代码。是他站的地方，离他真正看得懂的地方太远。
这两层不是什么高深概念。上面一层是你调用的东西，下面一层是它背后真正发生的事。
接着 Seemann 说了一句更不留情的。一个人要长到能认出自己当年有多过度自信，可能需要几十年。然后他反问：今天开始学的人，有那么多时间吗。
这一问没法回答。但我觉得这是整封信里最诚实的地方。
他也交代了自己的选择。他庆幸在 LLM 出现之前把编程基础打完了，这些技能给他用了差不多三十年。如果今天从零开始，他会认真考虑木工、金属加工这类靠手眼协调的手艺。理由是机器人取代体力活可能更晚发生。
这段被人拿去当标题。我倒不觉得是在劝退。一个干了三十年的手艺人，在老实算自己那套技能的保质期。他算完，也没叫别人别学。
再补两句他关于怎么用 LLM 的说法。
他说自己不怎么用 LLM 学习。因为 LLM 的问题不只是幻觉，是它会一本正经地胡说，所以他对回答保持很深的怀疑。他只问那些答案能验证的问题，比如某个 Haskell 表达式还能不能写得更简洁。他不会问"我下一步该学什么"。
这条建议可以直接抄。判断标准很土：你问出去的问题，有没有一个能当场证伪的答案。反过来，"我下一步该学什么""这个方向还有没有前途"，问了也白问，因为没有一个当场能证伪的答案。
写到这儿我得改一下自己前面的说法。
Seemann 另外指出，软件开发者几十年来一直在自己并不完全理解的抽象层之上工作。所以"理解"这件事本来就不是全有全无。那位读者不是从"懂"掉进了"不懂"，只是他站的位置太高。
这个区别很重要。按前一种说法，这封信是个悲剧。按后一种说法，那只是一段需要补的楼梯。
还有一段我没打算展开。Seemann 还从经济学角度聊了几句，说知识工作者万一出现三到四成的失业会怎样。他拿了煤矿工人和中国入世打比方。
那段我只看懂了一半。先放在这里，想清楚了再单独讲。
回到标题里那个词。"构建速度超过理解速度"这句话本身是不是真的，Seemann 说还有待观察。他的怀疑是，人吸收知识的速度存在生理瓶颈，老师和教材都不是主要限制。
我倾向相信有上限。但我更倾向相信另一件事：上限能一点点往上抬，前提是你肯回头把那两层补上。这两件事不矛盾。上限是客观的，抬不抬是自己的事。那位读者其实已经在做了。他花了几个月重构，那几个月就是学费。
本周就这些。
上面有任何一条你试过、或者觉得我讲错了，欢迎告诉我。讲错的我补，没讲清的我改。
下周见。