AI 帮你写代码，但你要亲手敲进去：防认知债的个人项目工作流

原文来源：Ankur Sethi 的博客 — 让 AI 生成代码但自己手动敲进去，用 2 倍速换 100% 的理解，防止个人项目积累认知债。

2026 年，AI 编程助手已经成了标配。但一个越来越普遍的现象是：让 AI 一口气生成整个功能，代码合进去了，脑子却一片空白——项目越来越复杂，你对它的理解却越来越浅。Ankur Sethi 把这叫作认知债，并且给出了一个看似离谱的解决方案：让 AI 写代码，但你自己手动敲进去。

为什么 AI 全自动写代码会积累认知债

Sethi 自己也是重度 AI 编程用户。他承认用 AI「一键生成整个功能」会让他感到不安和迷失方向，但他喜欢用 AI 快进项目里无聊的部分——比如查 Django 文档给网站加标签功能这种事。

问题出在哪？他说得很直白：一个问题无聊，不代表你想把对解决方案的理解整个外包给机器。就算他讨厌翻文档，他仍然想从根本上理解这个功能是怎么工作的。

当然，有人会说：那你就逐行 review AI 生成的代码啊。这正是 2026 年大多数开发者的处境——机器人提 PR，人类审查。但 Sethi 不愿意：翻几百行过度防御、注释稀烂、隐藏着细微错误的 AI 代码，一点都不好玩。给老板打工他可以勉强干（同时默默准备离职），但个人项目必须好玩。个人项目的乐趣来自过程，不是结果。

他的方案：AI 生成，人类手敲

Sethi 的解决方案简单到有点滑稽：让编程助手在聊天里生成代码，然后所有编辑都由自己手动完成。他在个人项目的 agent 配置文件里写了这样的指令：

我希望理解进入这个项目的每一行代码。除非我明确要求，永远不要创建、编辑、移动、重命名或删除项目文件。相反，在聊天里展示每个提议的修改，让我手动敲进去。

不要运行修改项目文件、安装依赖或改变仓库状态的命令，除非我明确要求。相反，在聊天里展示这些命令，让我手动运行。

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

这样用 LLM，比完全不用快，但比那些让机器替自己思考的人慢。不是 10 倍速，大概是 2 倍速。但他失去的速度，换来了对代码更深的理解。

手动敲代码到底换来了什么

这个工作流看起来低效，实际收益却很具体：

强制减速，更容易抓幻觉。 亲手敲每一行 AI 生成的代码，逼着你慢下来，更容易发现模型产生的幻觉和错误设计。边敲边清理：重新组织、重构、加注释、改成自己的口味。

建立代码库的空间地图。 最关键的收益：你知道代码库里每个功能在哪。改需求时，你确切知道该改哪里。这不仅让你在项目里工作得更快，还让你以后能更好地给 LLM 下指令——因为你知道上下文在哪、该怎么描述。

和学编程的经典建议一脉相承。 十几岁学编程时，老程序员总是说：不要复制粘贴代码。看书要把例子敲一遍确保能跑；看博客帖子要把代码打出来并适配到自己的代码库。手动敲 AI 生成的代码，本质上是同一件事。这不是最有效率的方式，但理解优先于产出。

为什么这对独立开发者特别重要

这套工作流对个人开发者、独立开发者尤其有价值，原因有三：

个人项目没有团队兜底。 在公司里，代码有同事 review、有文档、有老人带。个人项目只有你自己。如果连你都不理解自己的代码，三个月后回来维护就是灾难——这恰恰是大量 side project 烂尾的原因。

side project 的本质是学习资产。 对独立开发者来说，个人项目不只是赚钱工具，更是技能积累。让 AI 全自动写代码，项目做完了，技能没长进；手动敲进去，同样的项目做完，你对架构、API、调试的理解都实实在在提升了。

降低对 AI 的路径依赖。 现在 AI 能力迭代飞快，但模型会换、工具会换、API 会换。真正属于你的，是大脑里对代码和系统的理解。认知债本质上是在透支你未来维护项目的能力。

什么时候不适合这个工作流

公平地说，这套方案有明显边界，别盲目照搬：

• 公司生产代码：团队协作场景下，手动敲几百行 AI 代码不现实，正常的 AI 辅助 + 严格 review 才是主流。
• 探索性原型：验证想法、快速试错的阶段，追求的是速度，理解可以后补。
• 你不打算长期维护的项目：一次性的脚本、演示项目，认知债无所谓。
• 你的目标就是出货速度：如果项目的目的就是快速上线赚钱，10 倍速可能比 2 倍速重要得多——这是个人选择，没有对错。

Sethi 自己也承认这个工作流「极其低效，甚至有点滑稽」。它不是普适方案，而是给「把理解和掌控放在速度之上」的人准备的。

行业层面的隐忧

文章结尾，Sethi 提出了一个更大的担忧：整个软件行业正在背上巨额的认知债，而且很快就要偿还。总有一天，我们会不再理解数字基础设施的很大一部分是怎么拼起来的。

他可能改变不了整个行业的走向，但至少能确保自己完全理解自己发布出去的软件。「其他任何做法，都是职业上的渎职。」

这个观点值得所有开发者想一想：当 AI 生成的代码占到你代码库的 50%、80% 甚至更多时，你对这个系统的掌控力还剩多少？如果有一天模型换掉、API 断掉、或者需要深度修改，你手里还有什么？

我的看法

说实话，「手动重打 AI 代码」听起来很极端，但它指向的底层问题非常真实：AI 编程的最大风险不是代码质量，而是你的理解脱节。代码质量有测试和 review 兜底，理解脱节没有。

更平衡的做法可能介于两者之间：让 AI 做重活，但对关键路径代码逐行理解——核心逻辑、数据流、架构决策必须自己吃透；样板代码、配置、重复劳动可以放手。理解你该理解的，外包你可以外包的。

无论选哪种方式，原则是一致的：用 AI 加速，但别把大脑也外包出去。对独立开发者来说，你的代码库就是你的资产，而理解是资产里最保值的那部分。