「我可能造了一个超出我自己理解水平的系统。」写这句话的读者没有 CS 背景，过去一年靠 LLM 攒出一套 TypeScript/JavaScript 系统，里面有 API、PostgreSQL、LLM 流水线和多模型工作流，现在想把它做成正经产品，却修完一个错又冒出下一个。他给 Mark Seemann 写了封长信问该怎么办，Seemann 2026-09-16 在 ploeh blog 上公开作答，开头先声明自己的答案算不上严谨。

一年攒出来的系统，推生产时卡住了#

一年前他开始迷上 AI 辅助编程，用他自己的话说，那感觉近乎魔法，AI 好像把「有个想法」和「能做出来」之间的距离压没了。麻烦是往生产环境推的时候才出来的：修掉一个错，另一个冒出来，再有一块的行为自己也讲不明白。系统正常的时候，理解上的那道差距几乎看不见；一出问题，它就实打实地显出来。有时候不去问另一个模型，他真不知道下一步该做什么。

信里最后的疑问是：这一年做出来的到底是一个产品，还是一个看着像产品的东西，复杂到能跑起来，但他还没懂到能独自扛住它。

庆幸在 LLM 之前学过，今天重来会考虑木工#

答问题之前，Seemann 先亮了立场：对 AI 还没下定论，但偏向不喜欢，同时清楚它可能拦不住。他是经济学出身，对「技术进步会创造今天想象不到的新岗位」这个论证只信一半：新岗位确实会出现，但常常不落在丢掉工作的那批人身上，煤矿工人不会一夜之间变成程序员。

来信的第一问是：你庆幸自己在 LLM 之前就学过编程吗？今天从头开始，还会认真去学语言、数据结构、数据库、网络、操作系统、调试和架构吗？

前半句他答得干脆，当然庆幸，这套技能管了三十年。后半句的回答拐了个弯：要是今天重新开始，他会认真考虑木工、金工、枪械制作这类需要手眼配合的行当，理由是机器人虽然也在推进，可体力劳动被替代的时间点看起来还远一些。至于基础本身，他眼下正在一个大学课程里学数据结构和语言语义，但把动机说得很清楚，只是好奇，并不指望换来多少经济回报。

往下懂一层，往上懂一层#

同一问里还跟了一句更要命的：AI 是不是让人「做东西的能力」跑到了「理解的能力」前面？

Seemann 说这还要再看，因为这件事本身并不新鲜。软件开发者几十年来本来就站在自己不懂的抽象之上：做 web 开发的不怎么懂编译器是怎么实现的，写编译器的不怎么懂集成电路怎么设计，而做集成电路的人，也不了解上面那几层到底在干什么。

A good rule of thumb was: Understand the level of abstractions directly below the one you work in, as well as the one above.

往下懂一层、往上懂一层，大部分故障就排得动。

停下来补基础，今天的人还有那么多时间吗#

第二问最贴近来信人自己的处境：换成是你，会停下来系统补基础，还是边做边学，还是两头一起来？

Seemann 说这在他身上和在来信人身上根本是两个问题，因为他早就不缺基础了。他举了个极端的例子：就算让他去维护一个全部用 RISC-V 汇编写的程序，那大概是他能想到的最陌生的环境，他也能靠已有的知识一点点垫上去。

但他入行头几年恰恰就是基础薄弱的状态。1999 年起他用 C++ 写 COM 组件，用他自己的说法是不太明白自己在做什么，最后还是让它跑了起来，连明显的内存泄漏都清掉了。当时他选的正是「停下来系统补基础」这条路，对一个 1990 年代中期起步的职业生涯来说，这条路走得通。

今天还走得通吗？他没有给是或否，只把问题换成了时间。Dunning-Kruger 曲线最左边那一段说的是，刚入门的人因为不知道自己不知道，反而最自信；人得爬到足够高，才回得过头去认出当年那份自信有多无知。Seemann 说这段路他走了几十年，今天的人还有这么多时间吗？

有 LLM 确实能学得快些，因为问题可以问得更有针对性。三十年前他的办法是买书，指望里面有几页用得上，剩下的照样得啃过去。但他怀疑人类学习能大幅提速：瓶颈一直是人脑吸收新知识的快慢，老师和教材都算不上卡点。

文档和示例为主，书只在 F# 和 Haskell 上管用#

第三问是：你自己当年是怎么学编程的？今天要学一门全新的语言，又会怎么学？

短答案是：慢，靠大量试错，偶尔有本书垫着。他第一批真正的程序是给经济学硕士论文写的，用 QBasic，照着它自带的样例一点点学。1990、2000 年代也主要靠示例代码和文档，买过一本 C++ 的书但没读完，各种 Basic 方言和 C# 全是从文档和示例里捡起来的。只有 F# 和 Haskell 是例外，这两门是书教会的。

至于今天怎么学一门新语言，他直说自己的经验对 2026 年的新手没有参考价值：见过的语言足够多，翻翻现成代码、查几个不明显的点就能上手，前提是这门语言「正常」；真要回头碰 APL，他一样得先找份教程。

对 LLM 只问可证伪的问题#

信的最后，Seemann 交代了自己怎么用 LLM 学东西：基本不用。理由写得很直接：

LLMs don’t hallucinate; they bullshit, and I’m deeply distrustful of anything they tell me.

用还是用，但他挑着问，只问答案能当场验证的。他给了两个对照的例子。问「这段 Haskell 表达式能写得更简洁吗？」，有用的回答是一段代码，要么跑得通要么跑不通，要么更短要么不更短，对错当场就能判。问「我接下来该学什么？」，答案没有任何东西能验证，这类他就不拿去问 LLM。原文的最后一句是：倾向于向 LLM 提可证伪（falsifiable）的问题。

几点笔记（个人观点）#

  • 「往下懂一层、往上懂一层」这条老规矩拿来看来信人的处境正合适：LLM 把上面那层的产出速度提了上去，下面那层仍然得有人懂。具体到他那套系统，就是 PostgreSQL 什么时候会走全表扫描、Node 的事件循环被什么堵住、自己那条 LLM 流水线在哪一步会超时重试。出了事，这些才是落脚点。
  • 「只问可证伪的问题」是这篇里最能直接拿走的操作。落到日常就是：让 agent 去干有编译器、有测试、有 diff 能判对错的活；「这两个库选哪个」「要不要上这个框架」这类当场验证不了的，可以拿它列材料，但别指望它给结论。
  • 原文那条老规矩用的是过去时（“A good rule of thumb was"）。Seemann 没有展开这个时态，但放在整篇的语气里，读着像是说这条规矩今天未必还够用。
  • 来信人「系统超出自己理解」这个处境，和 Anthropic 论文：AI 会怎么影响技能形成 指的是同一件事。两边的证据强度不同：那篇有实验数据，这篇是一位从业三十年的开发者的判断。

参考资料#