通过手动重打 LLM 生成的代码来防止认知负债——来自 Hacker News 讨论的见解

通过手动重打 LLM 生成的代码来防止认知负债

Ankur Sethi 在他的个人项目中通过要求 LLM 在聊天中生成代码，然后由自己手动输入每一行，而不是让模型直接编辑文件，从而避免了认知负债。

LLM 带来的认知负债问题

使用 LLM 一次性生成整个功能会让作者感到不满意且迷失方向，而审查 AI 生成的 pull requests 并不愉快。他担心行业正在积累认知负债，这些负债很快就会需要偿还。

我担心软件行业正在承担大量的认知负债，我们很快就必须偿还。总有一天，我们将不再理解我们的数字基础设施的很大一部分是如何构建起来的。我个人可能无法改变整个行业的走向，但我至少可以确保我完全理解我发布到世界上的软件。除此之外，任何行为都是职业失职。

手动重打的工作流

作者向 LLM 发出明确指令，要求其仅在聊天中显示建议的编辑和命令，绝不修改代码库。

我想理解进入这个项目的每一行代码。除非我明确要求你这样做，否则绝不要创建、编辑、移动、重命名或删除项目文件。相反，请在聊天中向我展示每一个建议的编辑，以便我可以手动输入它们。

除非我明确要求该操作，否则不要运行会修改项目文件、安装依赖或更改代码库状态的命令。相反，请在在聊天中向我展示这些命令，以便我可以手动运行它们。

我是一名经验丰富的开发者。除非明确要求，否则不要解释语法、API、编程概念或实现细节。

通过逐行输入代码，他建立了一个关于代码如何融入现有代码库的心理模型，可以查阅不熟悉的 API，并检测到幻觉或糟糕的设计选择。

当我手动将 LLM 生成的每一行代码输入到我的编辑器中时，我建立了一个关于它如何工作以及如何融入我现有代码库的心理模型。如果我不理解某个 API 或算法，我可以停下来查阅它，或者直接要求 LLM 解释它。

我自己动手打代码，迫使我慢下来，这也就意味着我更有可能检测到 LLM 可能犯的幻觉或糟糕的设计选择。我可以在过程中进行清理，重新组织它、重构它、添加注释，并将其调整为符合我自己的风格。

这种工作流还创建了代码库的“空间映射”，使得未来的更改和向 LLM 发出提示词（prompting）变得更加容易。

手动输入的益处

作者发现这种方法比完全委托给 LLM 要慢（大约是 2 倍速而不是 10 倍速），但他认为深入的理解比单纯的生产力更重要。

使用 LLM 的这种方式允许我比完全不使用 LLM 工作得更快，但仍然比那些愿意让机器替他们思考的人要慢。与其说速度提升了 10 倍，不如说我可能只提升了 2 倍。但我失去的是速度，我赢得的是对代码更深入的理解。

他将这种做法比作学习编程时的传统建议：从书本或论坛中手动打出示例代码。

手动将 LLM 生成的代码输入到我的代码库中，感觉就像完全相同的学习过程。这可能不是与 LLM 协作的最有效率的工作方式，但比起生产力，我更看重理解力。

社区反应

Hacker News 的评论者们表达了不同的观点，从支持到批评，并提出了替代策略。

支持或类似的实践

• @wahern: "Good advice yesterday, good advice today, and good advice tomorrow. … Typing out code manually gives you time and space to consider the broader picture。"
• @bandrami: "As an aside, back in the days of Stack Exchange 时期，我总是会手动输入我找到的任何答案，以确保我理解了 WTF I was adding to the system。"
• @andai: "The Zed Shaw method!"
• @FailMore: 提到使用 SmallDocs 来保持与 LLM 生成的代码的联系。
• @sltr: 引用“生成效应”作为手动输入可以提高知识保留率的原因。
• @twoquestions: "This is what I'm doing right now to learn Electron，我本质上是让 Opus 写了一个教程，教我如何编写我想要的应用程序，然后我在过程中不断地修改细节。"

对该方法的批评

• @npras1: "Big no for retyping llm generated code by hand. But a big yes for still typing code by hand, and not leaving it to the llm. Except it has to be the code generated by your brain。"
• @estebarb: 引用了一篇 arxiv paper: "When students rely on these outputs as a substitute for their own reasoning or critical engagement, the learning process is fundamentally compromised. Genuine learning requires the active construction of meaning, integration of knowledge, and integration of reflective engagement with content。"
• @f311a: "This does not sound fun. It's better to work on your side projects with manual coding. 在进行侧边项目时，手动编写代码是更好的选择。你会学到更多。重打代码是学习中的低效做法。这就像尝试重打 calculus 解决方案——你学不到任何东西。"
• @petcat: "This is just a miserable career of 'paint‑by‑number'，因为人们不再愿意为自己的专业工作或编程练习进行创造性思考了。"
• @a2128: "As someone who, at a point, would copy homework 也会有一个阶段我曾经会从别人那里抄作业，也从网上抄写书评，并使用答案页来完成作业，我可以告诉你，这种策略长期来看是积累而非防止认知负债。"

替代建议

• @smegma2: "Seems like an ok solution, but what about doing something like the opposite? 写出代码的脚手架和整体形状（classes, interfaces, function signatures），然后让 LLM
  填补它。"
• @reacweb: "在小型项目中使用 LLM 生成代码，然后在向大项目迁移时手动复制。"
• @overthenexttwod: 认为将思考外包给 LLM 会产生比自己写代码更弱的心理模型，并建议将 LLM 作为独立的 agent 引导，而不是作为生产力工具。
• @jruz: 描述了将方案降级为 $20 计划并只向 LLM 提问而不让其写代码。

结论

作者的手动重打方法旨在通过在处理枯燥任务时利用 LLM 辅助的同时，保留理解力。Hacker News 的讨论显示，该技术在一些人看来是现代版的传统“通过打字来学习”，通过这种方式可以获得更深的理解，而其他人则认为它效率低下或没必要，建议亲自编写代码，仅将 LLM 诉求于审查、脚手架或问答。