这条在讲一个没有编程背景的人靠提示词一个下午做出登录、数据库、能用的界面。出处是 dev.to 上 Gamya 的评论，初稿去年七月发的。
“一下午”和“完整应用”这两个词，我本来准备关掉。这种故事现在哪都有。但作者自己写了句让我停下来的话：AI 擅长生成能跑的代码，却没法让用代码的人理解它为什么能跑。她原话是「这两种是不同的能力」。
对，问题就出在这。
编程这行里“理解”的水分一直很大。怀念底层概念的人翻出来看，一大块是记语法、记 API 签名、记 build 报错长什么样。这些被 AI 绕开，不是坏事。作者自己也认了，说过去理解代码的门槛里很大一块只是记忆语法，不等于逻辑推理。读到这我才确认这条不是那种抱着情怀当真理的。
但剩下那一块没被绕开。只是藏起来了。
真正让我觉得这条值得留的，是她说的那个场景：系统以没人预料到的方式出故障的时候，只靠 AI 构建的人手里没有任何排查的思维框架。评论区 Alex Shev 提了句更狠的——「真正建造」和「只是组装」的区别。作者表示认同，说组装出来的应用在正常的时候和真正建造没差别，一旦出事差距才显出来。
一个应用如果一辈子都跑在预想得到的路径里，组装和建造确实没差别。但现在越来越多的人第一次认真碰一个应用，就是在处理异常。不是正常路径。他们手里没有从行为反推模型的习惯。
评论区后面有个叫 mote 的人说了个比“理解”准确得多的说法：可调试的心智模型，比懂得语法更重要。这个词选得对。“理解”没法验证，你说你理解，我怎么知道？“可调试”能验证——出了事，你能不能从现象出发一步一步往回找。mote 还给了几个具体手段：追踪、差异、状态。这其实在说，别要求人一上来就懂内部结构，先教人怎么从外面看行为。
这差不多是我这些年学代码最有效的那部分。不是背会多少语法，是学会在跑不通的时候问“上一刻它在做什么”。
作者回 mote 那段也值得看。她说 AI 生成的故障经常先以一个明显的崩溃冒出来，修掉表层症状之后留下更多静默错误，让没有心智模型的人更难察觉风险。这是全篇最实在的一个判断。静默错误现在天天都能碰到。不是 AI 出现之后才有，但 AI 让一群从没建立过排查习惯的人也能把东西跑起来，结果第一课就是静默错误——这太难了。不是“我不会”，是“我根本不知道有东西坏了”。
还有人讨论新员工因为不知道内部约定，做出看起来合理的操作却导致故障，这往往说明架构长期依赖没写进文档的假设。这个和 AI 生成代码挺像。你接手的不是一个程序，是一堆没写成文档的内部约定。AI 不告诉你哪行是它顺手凑的，哪行是真正在抗风险的。它把“这个写法只在这个数据库版本下能用”这种假设埋进代码里，一句都不交代。
这篇我没法跑什么。观点类，没有代码可贴。只能老实说这条我通读过全文，35 条评论也过了一遍。读完倒想拿“可调试”当筛子：判断一个人用 AI 写代码靠谱不靠谱，不看 ta 能拼出多少功能，看 ta 能不能在功能跑不起来的时候讲清楚它上一次看起来正常时发生了哪些事。这差不多就是不点链接也能带走的一句。
末尾还有个细节。一个自称初学者的评论说自己愿意放慢速度理解 AI 生成的代码。作者回了一句，说这种问题解决能力是唯一不会被外包的。我不觉得像鸡汤。语法记忆被外包了，查文档找签名被外包了，连把 bug 描述清楚都能外包，但你愿不愿意在它崩了之后留在那看它怎么崩的，这件事还没人替你做。
这条值得点开，尤其后半段评论区。不少文章点子挺好，评论区却跟正文对不上，这篇没有。作者在评论里补了正文没展开的东西，没把评论当装饰。