一位署名 EvilGenius、从业约三十年的开发者，最近写了一篇文章，批评当前不少编程教育把“学会一门语言”误当成“学会编程”。

他举的例子很小，但很扎眼。

几年前，他审查一名初级开发者的 pull request。那门语言不是他日常职业中常写的语言，他甚至还要去查 lambda 的具体语法。可即便如此，他没有运行代码，也能看出函数结构有问题。

这就是这件事最反常的地方：一个人不熟某门语言的语法，却仍能判断代码组织不对。说明资深开发者真正依赖的，不只是语法记忆，而是对系统结构、数据流和维护后果的判断。

这不是说语言课没用。语法、标准库、工具链当然要学。问题在于，它们只是入门材料，不是职业能力的终点。

会语法的人像翻译者，程序员要决定写什么

这位开发者给出的对比很直接：只会语法的人，更像翻译者。需求来了，他能把一句话翻成机器看得懂的文本。

但程序员要多做一步：判断这段需求在系统里该变成什么代码，放在哪里，和哪些模块发生关系，将来谁来维护。

这一步，很多课程很难教足。

不是因为课程不重要，也不是因为 bootcamp 天然有问题。现实约束摆在那里：时间短、作业小、目标明确，课程更容易训练“功能跑通”。但真实项目里，更贵的是“为什么不该这么写”。

对比项语言学习能训练什么编程能力还要补什么
关注点语法、类型、标准库、框架用法系统拆分、模块边界、数据流
常见成果能完成教程和小功能能判断代码该放哪里、接口怎么定
容易忽略代码能跑但结构别扭半年后修改成本变高
真实考验写出当前功能调试、扩展、回滚、长期维护

作者还提到一个 Visual Basic 6 项目里的例子。初级开发者懂 VB 语法，却把事件驱动程序写成了自上而下的批处理流程。

后来真正改变的，不是他又记住了多少关键字，而是他开始理解运行时的事件模型。代码这才“像 VB”。

这件事对初学者有点不舒服：你以为自己差一门语言，其实可能差的是系统模型。

AI 让会判断的人更快，也让不会判断的人更危险

把这篇文章放到今天看，AI 编程工具是绕不开的变量。

GitHub Copilot、Cursor、Claude Code 这类工具，已经把“写出一段代码”的成本压低了。作者本人也提到，他每天使用 Claude Code，并认可它带来的效率。

但他的警告也在这里：AI 生成的代码常常“看起来合理”。资深开发者会继续追问：这段代码适合当前系统吗？边界条件在哪里？会不会破坏已有约定？出错后从哪里查？

初学者如果只会描述需求，再接受输出，就可能更快地产生更难维护的代码。

我更在意的是，AI 没有降低评审代码的门槛。它降低的是生产速度。

这会改变两类人的动作。

对初级开发者和编程学习者来说，工具可以用，但不能只用来“交作业”。更好的用法是让 AI 解释一段真实代码的调用链，再自己画出数据流；让 AI 给出重构方案，再自己判断哪个方案破坏最小。

对技术教育从业者和导师来说，考核也要变。不能只看功能是否跑通，还要看学生能不能解释：为什么这样拆模块，错误如何定位，AI 生成的代码哪里不能直接合并。

这里有个现实限制：短课很难模拟长期维护。那就至少把代码阅读、调试记录、PR 评审和二次修改放进作业里。一次写完，不算真正见过项目。

学习路径别追新语言，要补真实项目的疼痛感

这位开发者给出的学习建议并不花哨。

先深耕一门语言。不要只停在教程和小 demo，而是做一个非玩具项目，并持续维护。只有维护过，才会知道自己当初写下的“方便”，后来怎样变成负担。

然后再学一门结构差异大的第二语言。比如从 C# 到 Python，或从 C 到 JavaScript。差异越大，越容易看见哪些是语言特性，哪些是跨语言的编程问题。

更具体一点，初学者可以做四件事：

  • 读真实代码库，不只读文档和教程；
  • 看 issue 和 pull request 讨论，理解别人为什么拒绝某种写法；
  • 维护一个项目，记录哪些设计后来让修改变困难；
  • 找资深开发者看代码，学习他们如何假设 bug、缩小范围、放弃漂亮但危险的重构。

导师和课程设计者则要问另一个问题：学生交上来的作业，是不是只证明“会写”，没有证明“会判断”。

更有效的训练不是多加一门语言，而是把同一个项目拉长。第一周写功能，第二周改需求，第三周修线上式 bug，第四周要求解释哪些代码现在不敢动。

接下来真正该看的是教育内容怎么变：是否把代码阅读、调试过程、长期维护和 AI 代码评审放进核心训练。语言会轮换，框架会更替，但能不能判断代码该不该写、该写在哪里，这件事不会过时。