手动重敲 LLM 代码，拒绝认知债务

Prevent cognitive debt by manually retyping LLM-generated code

▲ 524mpweiher434 HN 评论区

尽管 2026 年机器人提交 PR 已成常态，但我拒绝在个人项目中完全依赖 LLM 生成代码。为了避免陷入巨大的认知债务，我采用了一种看似低效却极有价值的策略：让 LLM 在聊天框生成代码，然后我手动逐行重敲进编辑器。这种方式虽然让我只比不用 AI 快两倍，而非十倍，却让我对每一行代码、每一个 API 都建立了深刻的理解。通过手动输入，我构建了代码库的空间地图，能及时发现幻觉和糟糕的设计。在效率与理解之间，我选择后者，因为完全掌控自己编写的软件才是对职业操守的坚守。

我担心软件行业正在积累大量认知债务，而我们很快就会为此付出代价。
阅读原文 →HN 评论区RSS

HN 评论区

434
  1. bigbuppo

    手动重敲 LLM 生成的代码？绝对不行。

    但手动自己写代码，而不是把活全丢给 LLM，这绝对值得支持。前提是，这代码必须是你脑子里想出来的。

    这才是能催生新神经元和新连接的关键，也是防止认知衰退的良方。

    而且，不使用 LLM 的限制反而会激发创造力。

    事实上，LLM 给代码带来的限制比过去更多。LLM 只会用它们训练数据中特定的方式写代码，所以你永远接触不到其他解法。

    我一时能想到的例子是 RubyQuiz.com [0]，这是十多年前我学 Ruby 时发现的。看看那些用户提交的解决方案（你得下载 zip 文件！），你会发现解决问题的方式千差万别。

    当然，其中很多方案在今天看来，可能无法通过 LLM 或 rubocop 的效率与标准检查，但看着那些代码，亲手重敲一遍并验证它们能运行，对于我学会用 Ruby 思维解决编程问题至关重要。

    学 Go 时我也做过同样的事，用的是 "learn go with tests" 指南 [1]。

    [0] - http://rubyquiz.com/

    [1] - https://quii.gitbook.io/learn-go-with-tests

  2. ablob

    这无论如何都会导致认知债务。正如 https://arxiv.org/pdf/2509.21972v1 中所指出的："当学生将这些输出作为自身推理或批判性参与的替代品时，学习过程从根本上就受到了损害。真正的学习需要主动构建意义、整合知识，并与内容进行反思性互动。这些过程无法通过对语法正确但语义空洞的回答的被动消费来实现。如果没有这种更深层的认知工作，学习者可能会将语言流利度误认为理解力，从而破坏教育的根本目标"。

    就我个人而言，我不认为我们永远能调和使用 LLM 与认知债务之间的矛盾。甚至在 LLM 出现之前，我们就已经意识到这一点：我们知道那些转向管理或 PM 岗位的人，最终编程技能都会生锈。好吧，现在我们要么都成了那些管理者……

  3. GuB-42

    这听起来并不有趣。最好是在你的个人项目中通过手动编码来练习，这样你学到的东西会更多。

    重敲代码对于学习来说效率很低。这就像试图重敲微积分的解题步骤——你学不到任何东西。即使有关于"为什么代码要这样写"的解释，但这并非你构思出来的，你也并不知道替代方案。这是一种记忆练习，而非构建直觉的练习。

    更好的选择是：先自己写一遍，然后再问 LLM 有没有更好的方案。它们在这方面很擅长，尤其是当你需要优化热点循环时。

  4. wahern

    这是昨天的好建议，是今天的好建议，也是明天的好建议。

    我不记得是自己读过这条建议，还是自己悟出来的（也许是在吃了一些苦头之后），但这确实是我能记起的编程习惯中最长久的一条（我从 90 年代开始写代码）。如果我觉得时间紧迫，比如有人在我身后盯着，而我复制粘贴了一段代码，那总会让我感到不安。这会留下一个记忆和理解上的漏洞，哪怕只是看似简单的代码片段，也会像大拇指一样显眼。你不仔细逐行检查，就无法确定它真的简单，而"简单"往往具有欺骗性，因为通常正是与周围代码的交互和假设导致了意外。手动敲代码能给你时间和空间去考虑更宏大的图景。

  5. 3dsnano

    对此有什么合适的折中方案吗？我同意，不可避免地，我在工作中更高级的软件方法已经因为依赖 LLM 而打了折扣，尤其是考虑到管理层还鼓励这样做。有没有哪些特定的提示词或指令，大家觉得既能促进学习和迭代开发，又不会太拖慢实际开发周期？我想保持学习，保持技能敏锐，但这感觉像是一场必输的战役。

  6. Syzygies

    这里有很多反应，但如果这对你有用，那真是太好了。

    对我来说，我觉得 LLM 极大地（以好的方式）扩展了我的认知能力。我现在更像是一支军队的将军，而不是扮演士兵的角色。当然，这意味着我失去了作为孤独士兵的体验，但对我来说，这显然是笔划算的买卖。

    不管怎样，我得走了，我得推着车去杂货店（免得我忘了怎么走路），我和我的大粗腿几小时后回来。

    以上纯属善意。继续做你正在做的事，谢谢分享，希望大家保持友善，只进行善意的调侃。

  7. WhyComboNadir

    所以我总是先尝试自己动手做想做的事。然后请 AI 审查，它通常会给出一个更高效的方法来完成工作。

    举个例子，我在一个 Godot 场景中添加了一个正在工作的线性衰减速度提升函数，它今天建议的重构实际上减少了代码行数。所以看到这种结果时我挺开心的，但是的，我也是手动应用了这些更改，以便真正理解它们，希望能记得更牢。

  8. system2

    我同意作者的观点。我也认为，完全理解我拥有的代码库非常重要。当你让 LLM 为你生成代码时，很多东西自然就会丢失，其中最大的损失就是对所添加代码功能的心理模型。当你亲手写代码时，你会在过程中构建这个模型，这在以后——无论是添加功能还是调试意想不到的行为时——都无比有用。

    我一直在尝试通过告诉 LLM 代码应该如何构建，而不仅仅是它应该做什么，来解决这个问题。不过，任何我交给 LLM 的设计在某种程度上都会定义不足（如果完全定义清楚了，那直接就是代码了），而 LLM 会以某种方式填补这些空白——这就会逐渐增加认知债务，虽然缓慢但确凿无疑。

    重敲 LLM 生成的代码是一个有趣的解决方案。你肯定会比仅仅审查代码更好地理解生成的代码，但我怀疑它产生的心理模型，不如你自己写代码时构建的模型可靠。你思考得越久，心理模型就越完善——而把思考外包给 LLM 意味着思考得更少。

    话虽如此，我开始怀疑自己是否解决了错误的问题。我真的有必要坚持要求对自己拥有的代码建立准确的心理模型吗？如果一位非工程背景的管理者试图完全理解下属编写的每一行代码，我们会觉得这很奇怪。如果这个类比是恰当的，那么随着 LLM 代理能力的提升，也许我们应该停止将……

  9. npras1

    这听起来并不有趣。最好是在你的个人项目中通过手动编码来练习，这样你学到的东西会更多。

    重敲代码对于学习来说效率很低。这就像试图重敲微积分的解题步骤——你学不到任何东西。即使有关于"为什么代码要这样写"的解释，但这并非你构思出来的，你也并不知道替代方案。这是一种记忆练习，而非构建直觉的练习。

    更好的选择是：先自己写一遍，然后再问 LLM 有没有更好的方案。它们在这方面很擅长，尤其是当你需要优化热点循环时。

同日更多故事

2026-08-03