引用：Prevent cognitive debt by manually retyping LLM-generated code
这篇文章提出一个看似低效的做法：让 LLM 在聊天里生成代码，但不让它直接改文件，而是由开发者逐行手动输入。作者把它称为抵抗「认知债」的办法。我的判断是，这个方法对个人项目很有价值；它真正提醒我们的，是 AI 编程必须重新设计责任边界。
文章最有意思的地方，是它拒绝把效率当成唯一指标。现在很多 AI 编程讨论默认追问「快了几倍」：能不能一口气生成一个功能，能不能自动开 PR，能不能把人从细节里解放出来。作者的经验刚好反过来：LLM 一次性写完大量代码之后，项目表面推进了，开发者却失去了对代码的空间感。文件在哪里、边界怎么分、某个 API 为什么这样用、下一次要改哪里，这些本该沉进手里的知识，被外包给了一次性输出。
「认知债」这个词用得准确。技术债通常还能在代码里留下痕迹：重复、坏抽象、缺测试、难迁移。认知债更隐蔽。代码可能能跑，测试也可能过，但维护者并不知道它为什么能跑。等下一次需求变了，真正的账单才出现：每一行都像别人的房间，灯开着，却没有地图。
手动重打代码的价值，在于把生成结果重新变成学习过程。它强迫开发者慢下来，在输入时完成一次低速审查：这个函数名顺不顺，错误处理是不是过度，依赖是否必要，结构是否贴合现有项目。很多幻觉和坏设计，不是在「读 diff」时被发现的，而是在手指准备落下之前被发现的。输入不是观看，输入要求人预先理解下一小段代码将要落到哪里。
这和早年学习编程时「不要直接复制示例代码」的建议很接近。手打一遍不会神秘地提升水平，它只是制造摩擦。摩擦让人有机会停顿、改写、查文档、追问。AI 把样板劳动压低以后，开发者反而更需要主动保留一部分摩擦，否则理解会被速度吞掉。关键是把理解重新嵌回动作里。
不过，我不认为这个方法可以直接推广成团队规范。个人项目的最高目标可以是快乐、掌控感和长期可维护性；商业团队还要面对协作成本、交付节奏、审计责任和人员流动。要求所有人手动重打 AI 代码，很容易变成另一种形式主义：大家仍然不理解，只是把复制粘贴换成了更慢的复制。
更通用的结论应该是：AI 生成代码必须有清楚的吸收机制。小改动可以让模型直接落盘，但人要用测试、类型、review 和局部重写来验收；陌生模块、核心抽象、数据迁移、权限与安全边界，则应该要求人类先建立设计意图，再让模型填充局部。对个人项目来说，手动输入是一种吸收机制；对团队来说，可能是架构说明、测试先行、分步提交和关键路径解释。
文章里还有一个值得延伸的点：开发者对代码库的「空间地图」正在变成稀缺能力。过去这种地图来自长期写代码、查调用、改 bug。AI 代理能在几秒内跨文件修改，效率很高，也会绕开人脑形成地图的过程。短期看，这是自动化；长期看，这是维护权的转移。谁拥有地图，谁才真正拥有项目。
我推荐读这篇。它的方案有点笨，却笨得诚实。AI 编程的成熟，不会只表现为更快地产出代码，还要表现为开发者知道哪些理解不能外包、哪些摩擦必须保留、哪些责任必须留在人这边。速度当然重要，但一段代码进入项目以后，最贵的不是写出来的那十分钟，而是未来几年里每一次修改它时，你是否还认得它。