前言¶
2026 年 8 月 4 日，开发者 Ankur Sethi 在个人博客发表文章《Prevent cognitive debt by manually retyping LLM-generated code》，主张通过手动逐行重打 AI 生成的代码来避免「认知债务」。该文在 Hacker News 获得 409 分、348 条评论，评论区几乎对半分裂——一方认为这是对「Vibe Coding」的必要纠偏，另一方则质疑：这不就是「复制粘贴加了额外步骤」吗？
Sethi 本人是资深开发者，仍在个人项目中使用 Claude Code、Cursor 等编码助手。他的问题很具体：Agent 一次性生成功能固然快，但会让自己对代码库「迷失方向」；而逐行审查 AI 提交的数百行 PR 又枯燥到难以忍受。于是他想出了一条「效率极低、略显滑稽」的中间路线——让 Agent 只展示改动，不直接写文件，由自己手动敲进编辑器。
这篇文章梳理 Sethi 的核心主张、HN 上的主要争议，以及评论区更被广泛接受的替代做法，供你在 2026 年的 AI 编程工作流里做取舍参考。
什么是「认知债务」¶
Sethi 用 Cognitive Debt（认知债务） 来类比技术债务：当你把理解某段代码的责任完全交给 LLM，代码虽然跑起来了，但你对它的心智模型是空的——出了问题无法独立调试，改需求时不知道从哪里下手，最终只能回到聊天窗口问 AI「这段是干什么的」。
他在文中举了一个典型场景：给个人网站加 Django 标签功能，查文档很无聊，但他仍然想理解解决方案是怎么工作的。「问题无聊」不等于「可以把理解外包给机器」。
这与 2026 年行业主流形成张力：机器人提 PR，人类做 Review——Sethi 承认这种模式存在，但他不愿意在个人项目里扮演「AI 代码审计员」。个人项目的乐趣在于过程，而不只是交付结果；对着几百行过度防御、注释混乱、 暗藏错误的 AI 代码做 Review，对他来说既不 fun，也积累认知债务。
Sethi 的工作流：Agent 只说不写¶
Sethi 的解法可以概括为：LLM 当参谋，手当执行器。他在各项目的 Agent 配置文件（类似 AGENTS.md）里写了三条硬规则：
- 禁止 Agent 直接改文件——不得创建、编辑、移动、重命名或删除项目文件，除非他明确要求。
- 改动与命令只在聊天里展示——Agent 把每一处 proposed edit 和 shell 命令输出到对话，由他手动执行。
- 跳过基础教学——他是 experienced developer，不需要 Agent 解释语法或 API，除非主动提问。
实际流程如下：
需求描述 → Agent 在聊天中生成代码片段 / diff 建议
→ 开发者逐行手动敲入编辑器
→ 遇到不懂的 API 或算法，停下来查文档或追问 LLM
→ 顺手重构、加注释、调整风格
Sethi 坦言，这套流程比不用 AI 快大约 2 倍，但远达不到 Agent 全权代劳宣称的「10 倍」。他主动用速度换理解——「I value comprehension over productivity（我重视理解胜过生产力）」。他说已实践数月，效果良好。
他还把这套做法类比为学编程时的老经验：看书记例题要手敲一遍，看博客抄代码要改写成自己的项目结构。手动输入迫使大脑慢下来，更容易发现幻觉、错误 API 调用或糟糕设计；同时建立代码库的「空间地图」——知道每个功能在哪，下次改哪里不用问 AI。
HN 上的激烈争论¶
HN 讨论的核心分歧不在「要不要理解代码」——几乎所有人都同意理解很重要——而在手动重打是否是达成理解的正确机制。
支持方：摩擦带来觉察¶
支持者认为，重打创造了一个强制暂停点：你必须处理每一个字符，更容易注意到变量名不合理、假设有误、或调用了不认识的 API。相比「读 diff → 一键 Accept」，机械输入至少不会完全跳过细节。有人回忆从杂志学编程的年代：「这基本就是我当年从 BYTE 杂志抄代码的方式。」
Sethi 还强调，慢下来有助于捕获幻觉——LLM 生成的代码表面能跑，但可能用了不存在的方法或错误的库版本；快速粘贴时这些细节容易被忽略。
反对方：重打 ≠ 生成，可能是「clerical theatre」¶
HN 高赞批评直指机制本身。一条代表性评论写道：
如果你的流程是：认真想 → 让 LLM 写 → 读 LLM 写的 → 再想一遍 → 重打 → 再修——效率增益在哪？干脆去掉 LLM，还省 token。
批评者指出：重打已审查过的代码，认知活动与自己设计并实现完全不同。学生抄课堂笔记时也会进入「自动打字」模式，记忆留存几乎为零。重打可能只是把 copy-paste 换成了 copy-retype，并没有增加真正的理解深度。
还有人认为 Sethi 真正想要的是「comprehension（理解）」，但选了「retyping（重打）」这个非必要的手段——理解可以通过其他方式达成，不必逐字符 transcription。
更深层的问题：Review 够吗？¶
评论区另一个 recurring 担忧是：读 diff 和能独立调试是两回事。就像学外语——你能读懂句子，不代表能自己说出来。六周后收到 bug 报告，被动 Review 时「看懂了」的代码，未必能帮你定位问题，尤其在没有 AI 辅助的凌晨三点。
这一点对团队更有现实意义：不少 Tech Lead 反映，新人用 AI 快速交付 ticket，但数月后仍缺乏本该通过手动追 bug 积累的基础直觉——这与 Sethi 个人项目的认知债务是不同层面的问题。
评论区更被广泛接受的替代方案¶
即便批评 Sethi 的具体方法，HN 线程里仍浮现出若干共识度更高的做法：
1. 先规划，再委托
让 Agent 先输出实现计划（plan），人类审阅、修改计划，确认「what should happen」后再让 Agent 写代码。决策权留在人这边，字符输入可以委托。
2. Chat-only Review，理解后再粘贴
Agent 在聊天里展示 diff，你仔细阅读、提问、确认理解后再粘贴——跳过机械重打，但保留「我搞懂了才入库」的门槛。
3. Design-first 委托
架构、函数签名、数据流由自己写；Agent 只填 implementation 细节。维护性最关键的部分留在人脑里。
4. 把 AI 当 Rubber Duck
实现前先问「有没有遗漏的设计问题」，比写完几百行再 Review 便宜得多。
5. 严格限制 scope
一次只要单文件、小范围改动，Review 负担接近审查同事的小 PR，而非审计 1000 行 drop。
6. 测试作为 ground truth
先写 failing test，再让 Agent 修 bug——正确性由测试验证，不完全依赖人工读代码。
7. 按 stakes 匹配摩擦
没人主张重打 boilerplate 或测试脚手架；争议集中在需要长期维护、出了问题你得扛的核心业务代码。Disposable 代码或测试覆盖充分的代码，速度优先更合理。
一套可落地的 AGENTS.md 参考¶
若你认同 Sethi「Agent 不直接改文件」的框架，但不想逐行重打，可以折中配置 Agent 规则。以下基于 Sethi 原文整理，可按项目裁剪：
## Agent 协作规则
- 理解优先：我需要理解项目中每一行代码。除非我明确要求，否则不要创建、编辑、移动、重命名或删除任何文件。
- 改动展示：所有 proposed edit 和会修改仓库状态的命令，只在对话中展示，由我手动执行。
- 简洁输出：我是有经验的开发者，默认不要解释基础语法或 API，除非我追问。
- 小步提交：每次建议的改动范围尽量小，便于我 Review 和理解。
配合实践：每合并一段 AI 生成的代码前，用两句话向自己解释「这段做什么、为什么这样写」——若做不到，说明认知债务已经产生，需要停下来搞懂再入库。
小结：机制可争议，警觉不可少¶
Sethi 的「逐行重打」是一种极端的个人实践，HN 对其机制的质疑是成立的——mindless transcription 不等于 deep comprehension。但他指出的问题——AI 全权代劳会在代码库中积累认知债务，在凌晨 incident 或安全审计时集中爆发——很难被反驳。
对你而言，不必二选一：
- 个人 side project、需要长期维护的模块：可以借鉴 Sethi 的「Agent 只说不写 + 强制慢下来」，重打只是选项之一，「理解后再入库」才是核心。
- 团队生产环境：更现实的路径是 plan-first、小 scope PR、测试驱动、以及 Review 时追问「why this approach」，而非要求每人重打每一行。
- 判断是否欠债的简单标准：Review 时若无法脱离聊天日志解释自己的 PR，债务已经在那里了。
2026 年的 AI 编程工具设计目标，是消除摩擦。Sethi 与 HN 这场争论真正提出的问题是：在哪些地方，你故意把摩擦加回来——以及用什么方式加，才既保理解又不沦为低效表演。
参考来源
- Ankur Sethi, Prevent cognitive debt by manually retyping LLM-generated code
- Should You Manually Retype LLM-Generated Code? The HN Debate（HN 409 分 / 348 评论讨论梳理）
