尽管我在四月说过，但我仍然在个人项目中使用编码助手。使用它们一次性完成整个功能让我感到不满足和迷失，但我确实喜欢利用它们快速通过项目中无聊的部分。然而，让我的编码助手在我的项目中自由发挥则让我背负了巨大的认知债务。我可能讨厌为了弄清楚如何在我的网站上添加标签而翻阅Django文档的想法，但我仍然从根本上想理解它是如何工作的。仅仅因为一个问题很无聊并不意味着我想完全将对解决方案的理解转移给机器。当然，我可以逐行审查LLM生成的每一行代码。这是大多数开发人员在这个诅咒的2026年所期望做的。机器人提出PR，人类审核它们。这是一个勇敢的新世界。但我并不喜欢审查AI生成的PR。仔细查看数百行过于防御性、注释差、微妙错误的代码并不好玩。我可能勉强会为雇主做这件事——同时确保该雇主尽快变成前雇主——但我绝对不会为我的个人项目这样做。个人项目必须是首先有趣的。从事个人项目的乐趣来自于过程，而不是结果。那么，我该怎么办呢？我如何将无聊的工作外包给LLM，而不将自己工作和认知的控制权交给这个糟糕的机器呢？我想出了一个极其低效也许略显可笑的解决方案：我让我的编码助手在聊天中生成代码，然后自己手动进行所有编辑。我在个人项目的所有代理文件中都有这些指令：我想理解这个项目中每一行代码的含义。除非我明确要求这样做，否则不要创建、编辑、移动、重命名或删除项目文件。相反，请在聊天中向我显示每个提议的编辑，以便我可以手动输入。除非我明确请求该操作，否则不要运行会修改项目文件、安装依赖项或更改存储库状态的命令。相反，请在聊天中向我显示这些命令，以便我可以手动运行。我是一名经验丰富的开发者。除非明确询问，否则不要解释语法、API、编程概念或实现细节。以这种方式使用LLM可以让我比完全不使用LLM工作得更快，但我仍然比那些愿意让机器为他们思考的人慢。与其说我是10倍快，我可能只是2倍快。但我在速度上损失的部分，我在对代码的更深入理解上获得了回报。当我手动将每一行LLM生成的代码输入到编辑器中时，我建立起了它是如何工作的以及如何融入我现有代码库的心理模型。如果我不理解一个API或算法，我可以停下来查看，或只是问LLM让它解释。自己输入代码迫使我放慢速度，这使我更容易发现LLM可能犯下的幻觉或糟糕的设计选择。我可以在继续过程中清理代码，重新组织它，重构它，添加注释，并根据自己的口味调整它。最重要的是，这个工作流程让我能够构建我的代码库的空间地图。我知道代码库中每一功能的位置。当我需要进行更改时，我确切知道在哪里进行。它不仅帮助我在项目中更快地工作，还使我在未来能够更好地提示和指示LLM。当我还是青少年学习编程时，有经验的程序员常常告诉我绝不要将代码复制粘贴到我的项目中。如果我是在从书中学习，我会被建议将所有示例复制到我的计算机上并确保能够运行它们。如果我是在从博客文章或论坛回答中学习，我会被建议手动输入并将其调整到我的代码库，以便我完全理解它。手动将LLM生成的代码输入到我的代码库中感觉就像是完全相同的学习过程。这可能不是与LLM合作的最有效方式，但我更加重视理解而非生产力。我已经这样做了几个月，这对我来说效果很好。我计划尽可能继续使用这种工作流程。我担心软件行业正在承担大量认知债务，我们很快就必须偿还。总有一天，我们将不再理解我们数字基础设施中的大部分是如何组合在一起的。我可能个人上无法改变整个行业的方向，但至少我可以确保我完全理解我推出到外面的软件。否则，将是职业失职。