Lobsters 上有个帖子，114 个赞、71 条评论，标记为 vibecoding。帖子的标题就两个字——「On AI」。挂的链接指向 jcs.org，但网站目前连不上。不过这不妨碍讨论本身成为焦点。
评论区顶楼，用户 tmcb 写了一段话：
「就像西西弗斯在推石头，但现在隔壁有人用起重机吊石头——准头堪忧，偶尔砸到观众，但确实快得多。你可以想象西西弗斯有多愤怒。」
这个比喻之所以能拿到 93 个赞，是因为它戳中了越来越多程序员隐隐的不安：AI 编程工具太「好用」了。好用到让你开始怀疑，自己到底还在不在「学」东西。
这篇文章讨论的是当你让 AI 替你写代码之后，那个「顺便学习」的过程去哪了。
配图：现代编程环境中，AI 代码生成已成为标准配置。但效率提升的背后，学习的代价正在被忽略。
被魔术抹掉的学习环节
Lobsters 用户 duck_tape 写了整个帖子里最关键的一段话，获得了 38 个赞：
「有一件事我们还没有真正面对：我们的大量学习是『顺便发生的』，是日常工作中的副产品。你在实现某个随机功能时、在折腾 CI 配置时、在为新的编译目标做准备工作时——你想不学习都难。但现在，我们可以把这些环节像变魔术一样变走。我们可以直接把脑子里的想法『创建』出来。但我们再也无法『顺便学习』了。」
「顺便学习」（incidental learning）不是教育学术语里的冷僻概念。它是人类最自然的学习方式——你在做一件事的过程中，无意间学会了另一件事。编程尤其依赖这种模式。
一个新手程序员接手一个真实的 bug 修复任务。他的目标是修 bug，但在这个过程中他被迫理解代码库的结构、学会使用调试器、领悟到为什么这个 bug 在特定条件下才会触发、顺便记住了相关的 API 用法。他没有「刻意学习」这些——他的目标是修 bug，学习是顺便发生的。
GitHub Copilot 在 2022 年正式发布，到 2025 年已拥有超过 2000 万用户，据微软的数据，用户编写的代码中有 46% 来自 AI 生成（部分项目中的 Java 代码比例高达 61%）。这个数字还在增长。
AI 把学习回路切断了。它的工作机制恰好绕过了「做中学」的环路。你输入 prompt，它输出代码。
这些「没有机会」加起来，就是那个被魔术抹掉的学习环节。
配图：AI 代码补全将开发者的角色从「创造者」转变为「审核者」——审查比自己写还快，但学习的深度也同时变浅了。
为什么这不是「Stack Overflow 2.0」
一个常见的反驳是：当年 Stack Overflow 出现时，同样有人说程序员会丧失自己查文档的能力；IDE 自动补全出现时，也有人说程序员会不再记忆 API。结果呢？行业没有垮。
这个类比不完全成立。bendmorris 在回帖中给出了一个关键区分：
「当然存在一些程序员靠复制粘贴 Stack Overflow 过日子，也不太理解自己在干什么。在零利率时代的工作泡沫里这或许能混过去。但现在这些程序员可以用 LLM，他们的平均产出质量可能会提高。我不认为结果会很好——这些人几乎没在贡献什么真正的价值。」
Stack Overflow 和 IDE 自动补全是在已有知识结构上提高效率。你仍然需要理解搜索到的答案，需要判断哪个片段适用；自动补全只在你已经知道要调用什么函数名时才有效。它们加速的是执行环节，没有跳过理解环节。
AI 生成代码跳过的是理解本身。你不会因为看到一段输出就自动学会它的逻辑——特别是当这段输出是 30 行你从来没见过的模式时。
心理学上有一对经典概念：「流畅度错觉」（fluency illusion）和「理想难度」（desirable difficulties）。加州大学洛杉矶分校的认知心理学家 Elizabeth 和 Robert Bjork 在 1990 年代就证明了：那些让人感觉学得很「轻松」的方式，恰恰是长期记忆效果最差的。 相反，那些让人感到费力的学习方式——比如需要费力回忆、需要自己解决问题——虽然过程痛苦，但长期 retention 更好。
AI 编程工具提供的恰恰是最大化的「流畅」和最小化的「费力」。这是产品设计的选择——但学习效果因此打了折扣。
2025 年的一项随机对照实验直接检验了这个假设。研究者将学习者分为两组，一组使用 ChatGPT 辅助完成任务，另一组使用传统方法。结果发现，AI 辅助组在即时任务上的表现更好，但在之后的独立测试中，成绩显著低于对照组。 这符合「认知卸载」（cognitive offloading）理论——太容易得到答案的大脑，会选择不存储答案。
「我还能学，但我不想只当审查员」
Lobsters 评论区另一个高赞（29 票）来自 zetashift，他描述了一种弥漫在社区中的倦怠感：
「我发现自己已经不点开 GitHub 链接了。当我看到仓库里有 CLAUDE.md 或 AGENTS.md 文件时，会条件反射般地关掉页面。到后来已经变成了下意识的反应。……用 LLM 编码后，我对自己做的东西毫无感情。 我完全不觉得那些输出属于我，也没有理解它们的意愿。」
这不是孤例。用户 gered 回复说，他试过 vibe coding 之后的感觉是「脏」——“I almost feel dirty afterwards”。另一个用户 lake 讲述了自己的故事：
「我花了一年半做一个开源项目。然后看到别人用 AI 在几个月内跑到了我想到达的位置。我很高兴这些工具存在，但如果它们在我开始之前就存在，我可能永远不会开始那个项目。我告诉自己：会有欣赏手工代码的人。我告诉自己：开源不是竞赛。但看着别人用加速器超过你，确实是令人沮丧的。」
这些情绪背后是一个被忽略的结构性问题。当资深程序员——那些已经有十年二十年经验的人——使用 AI，他们能判断输出质量、能发现 AI 的荒谬错误、能把 AI 生成的 50 行代码重构为 10 行清晰的逻辑。但新手没有这个判断力。
bendmorris 的总结很尖锐：
「Andreas Kling 这样的人可以轻松转向使用 LLM，因为他积累了足够的技能来确保输出质量和解决正确的问题，这些能力不会立即衰退。但下一代程序员如果从一开始就使用 LLM，他们怎么到达那个水平？那些建立技能的基础性工作，恰好也是最容易自动化的工作。 整个行业正在集体打自己的脚。」
反派不是 AI，是「无需理解」的工作流
这里需要小心地做一个区分。笔者并不主张「AI 是坏工具」——这个立场既无意义也不符合事实。AI 编程助手确实能显著提高生产力，让小型团队做到以前需要十倍人力才能完成的事。它让非专业人士可以用自然语言构建简单应用。这些价值是真实的。
问题在于：当工具的工作方式绕过了学习环路，谁来负责确保学习仍然发生？
当前几乎所有 AI 编程工具的交互模型都是「需求→代码→验收」。工具的设计目标是完成，而不是帮助用户理解。
论文《Agents That Teach: Towards Designing Incidental Learning Back into AI-Assisted Software Development》（arXiv:2607.06101）系统性地分析了这个问题，首次提出了**「知识债务」（Knowledge Debt）**的概念：
当 AI 代理执行了那些开发者不能完全理解的代码变更时，这些理解缺口会随着时间的推移而累积。今天 AI 帮你解决了一个你不理解的 bug，明天又生成了一段你不理解的优化。一年后，你的系统跑得很好，但你已经无法真正维护它——你不知道它怎么工作。
这是一个比技术债务更难察觉的问题。技术债务至少会在代码质量指标上显示出来。知识债务没有指标——它藏在开发者的大脑里，只有当需要独立解决问题时才会暴露。
计算的代价
另一位用户 pyj 的提问非常实际：
「我个人的问题是：用 AI 之后，我发现自己记住的东西少了很多。任务可以完成，但我学到的、记住的都不如从前。有没有好的策略，能在使用 AI 工具的同时保持学习效果？」
这是一个还没有被好好回答的问题。少数有经验的程序员分享了自己的做法——比如 zem 的「先让 Claude 生成，然后自己重构成更干净的架构」。但这需要你已经知道「干净的架构」长什么样。
Lobsters 上的讨论最终走向了两个方向。一方认为「手工编码正在成为一门手艺，就像做木工或弹钢琴」——你可以选择用电动工具，也可以选择手工刨花，两者没有对错。另一方则认为，当整个行业的奖励结构向 AI 倾斜时，选择手工编码的成本越来越高，直到只有最富有或最偏执的人才能负担得起。
这两个方向都有道理，但都回避了一个核心问题：如果「顺便学习」的路径被切断了，新手程序员要绕多远的路才能达到上一代人「顺便」达到的水平？
没有人在讨论中给出答案。但这个问题的提出本身，已经比大多数 AI 产品的 PR 文案有价值得多。
参考链接：
- Lobsters: On AI (114△, 71 comments) (item?id=zljfgp/on_ai)
- Joshua Stein: On AI (jcs.org)
- Hacker News: On AI discussion
- Bjork & Bjork (2011): Desirable Difficulties in Theory and Practice
- Anthropic: ChatGPT as a Cognitive Crutch
- arXiv 2607.06101: Agents That Teach
- Bjork (1994): Memory and Metamemory Considerations in the Training of Human Beings
- GitHub Research: Quantifying GitHub Copilot’s Impact on Developer Productivity and Happiness
