通过手动重新输入LLM生成的代码来避免认知债务

# 通过手动重新输入 LLM 生成的代码来防止认知债务 —— Ankur Sethi 的实验笔记本 来源：https://ankursethi.com/blog/prevent-cognitive-debt-by-manually-retyping-llm-generated-code/ 尽管我在四月（https://ankursethi.com/blog/coding-assistants-personal-projects/）说过那些话，我仍然在我的个人项目中使用编程助手。 用它们一次性生成整个功能让我感到不满和迷失方向，但我确实喜欢用它们来加速项目中枯燥的部分。 然而，让我的编程助手在我的项目中自由游荡，会给我留下大量的认知债务。我可能讨厌翻阅 Django 文档来搞清楚如何为我的网站添加标签功能，但我仍然从根本上想要理解它是如何工作的。一个问题枯燥，并不意味着我想把对解决方案的理解完全外包给机器。 当然，我可以逐行审查 LLM 生成的每一行代码。在 2026 这个被诅咒的年份，大多数开发者都被期望这么做。机器人提出 PR，人类审查它们。这是一个美丽的新世界。 但我并不喜欢审查 AI 生成的 PR。翻阅数百行过度防御、注释糟糕、微妙错误的代码一点都不有趣。我可能会为了雇主勉强这么做——同时确保这位雇主尽快变成前雇主——但我绝对不会为了个人项目这么做。个人项目最重要的是有趣。做个人项目的乐趣来自于过程本身，而不是结果（https://ankursethi.com/blog/results-are-a-side-effect-of-doing-the-work-with-love/）。 那么一个男孩该怎么办呢？我如何把枯燥的工作外包给 LLM，同时又不把自己的工作和认知控制权让渡给那台垃圾制造机？ 我想出了一个极其低效、也许还有点滑稽的解决方案：我让我的编程助手在聊天中生成代码，然后我自己手动做出所有修改。 我在个人项目的所有 agent 配置文件中都写入了这些指令： > 我希望理解进入这个项目的每一行代码。除非我明确要求，否则永远不要创建、编辑、移动、重命名或删除项目文件。相反，在聊天中向我展示每一个提议的修改，以便我手动输入。除非我明确要求，否则不要运行修改项目文件、安装依赖项或改变仓库状态的命令。相反，在聊天中向我展示这些命令，以便我手动运行。我是一位经验丰富的开发者。除非被明确要求，否则不要解释语法、API、编程概念或实现细节。 以这种方式使用 LLM，让我比完全不用 LLM 工作得更快，但我仍然比那些愿意让机器替自己思考的人慢。我不是快 10 倍，可能只快了 2 倍。但我在速度上失去的，我在对自己代码更深入的理解上赚了回来。 当我手动把每一行 LLM 生成的代码输入编辑器时，我会建立起一个关于它如何工作以及如何融入现有代码库的心智模型。如果我不理解某个 API 或算法，我可以停下来查资料，或者直接让 LLM 解释给我听。 自己手动输入代码迫使我的节奏慢下来，这意味着我更有可能发现 LLM 可能产生的幻觉或糟糕的设计选择。我可以边输入边清理代码，重新组织、重构、添加注释，并总体上让它符合我自己的品味。 最重要的是，这种工作流程让我能够建立起代码库的*空间地图*。我知道代码库中每个功能模块住在哪里。当我需要做修改时，我确切地知道应该在哪里修改。这不仅帮助我在项目中工作得更快，也让我在未来更容易更好地向 LLM 提供提示和指令。 当我十几岁学习编程时，有经验的程序员经常告诉我，永远不要直接复制粘贴代码到你的项目中。如果我是从书里学，他们建议我把所有示例复制到计算机里并确保能运行它们。如果我是从博客文章或论坛回答中学，他们建议我亲手输出来并改编到我的代码库中，这样我才能完全理解。 手动将 LLM 生成的代码输入到我的代码库中，感觉就像是完全一样的学习过程。这也许不是使用 LLM 最有效率的方式，但我看重的是理解力而非生产力。我已经这样做了几个月，对我来说效果很好。我计划尽可能长时间地继续使用这种工作流程。 我担心软件行业正在背负大量的认知债务，而我们很快就要偿还。总有一天，我们将不再理解数字基础设施的很大一部分是如何拼凑起来的。我可能无法凭一己之力改变整个行业的走向，但我至少可以确保我完全理解我推向世界的软件。除此之外的任何做法都是职业失职。