代码写得越来越快，我们却可能越来越不懂代码

发表于
AI 降低了代码生成成本，却提高了理解、判断和接管代码的价值。结合领域专家使用 LLM 与“认知债务”的讨论，分析怎样在获得速度的同时保留对系统的掌控。

2026 年 8 月 4 日，Hacker News 首页同时出现了两篇关于 AI 编程的文章。

一篇叫 《LLMs reward expertise》，讨论为什么领域专家能从同一个模型里拿到更多价值；另一篇叫 《Prevent cognitive debt by manually retyping LLM-generated code》，作者为了理解每一行代码，选择让 AI 在对话里给出修改建议，再由自己手动输入。

一个在讲如何把 AI 用得更快、更深，另一个却主动踩下刹车。它们其实在回答同一个问题：代码交付得更快以后，人是否仍然拥有这份代码？

我的判断是，AI 降低了代码的生成成本，却提高了理解、判断和接管代码的价值。它没有抹平经验，反而把“能否判断结果”的差距放大了。

同一个模型，专家拿到的不是同一种结果

Sean Goedecke 在文章里用了数学家陶哲轩与 ChatGPT 讨论数学问题的例子。陶哲轩的提问并不长，也没有复杂的“提示词工程”：他会抓住回答里的关键部分，指出不自然的地方，提出新的方向，并忽略模型给出的无效路线。

这些动作无法靠模仿句式复制。真正起作用的是数学知识：知道什么值得追问，什么看似合理却偏离了问题，什么地方本来可以更简单。

写代码也是一样。

当一个人熟悉业务和代码库时，他不会只问“怎样实现这个功能”，还会继续问：

  • 为什么要在这一层修改，而不是复用已有路径？
  • 这个方案会不会破坏现有的数据约束？
  • 仓库里是不是已经有相同的错误处理或状态机？
  • 如果上线后失败，应该观察哪个指标，怎样回滚？

缺少领域知识时，模型仍然有用。它可以补齐语法、生成样板代码、解释陌生 API，让人快速跨过原本无法进入的门槛。但此时判断标准往往是“这段回答看起来像不像正确答案”。

拥有领域知识以后，判断标准会变成“它是否适合这个具体系统”。前者把模型当答案来源，后者把模型当可被调度和纠正的合作者。

经验的价值已经不再主要表现为比 AI 多记住几个 API，而是能否为答案提供方向、约束和验收标准。

写进仓库，不等于进入了人的理解

技术债务通常留在代码里：临时方案、重复逻辑、缺失测试，以及迟早需要偿还的架构妥协。

认知债务留在人脑与系统之间。代码也许已经通过 CI、成功部署，甚至运行良好，但团队不知道：

  • 为什么要这样设计；
  • 哪些条件不能被破坏；
  • 一次修改会沿着什么路径传播；
  • 出现异常时，应该先检查哪里。

AI 很容易制造这种落差。过去，工程师要花几个小时理解文档、寻找调用链和修改代码；现在，Agent 可以在几分钟内完成几十个文件的修改。运行结果提前到达了，理解过程却没有同步提速。

这很像一直依赖导航开车。导航可以让人更快到达目的地，但如果从不观察道路、方向和地标，一旦道路封闭，原本节省的时间会在寻找绕行路线时一次性还回去。

Ankur Sethi 给出的做法很极端：禁止 Agent 直接修改个人项目，让它只在对话中展示建议，再由自己逐行输入。他估计这种方式只能获得大约两倍速度，而不是想象中的十倍；换来的收益是能够发现幻觉、调整设计，并在脑中建立代码库的“空间地图”。

这是一种个人工作流，不必被复制成团队规范。手动输入也不天然等于理解，复制速度慢一点，同样可能不加思考。但它指出了一个真实问题：如果人只在最后接收一个已经完成的 Pull Request，审查很容易退化成“测试绿了、代码看起来没问题”。

此时，人审核了差异，却未必接管了系统。

真正的标准不是有没有读过每一行

完全拒绝 Agent 直接写文件，并不适合所有任务。

生成测试夹具、调整机械化配置、更新类型声明，和修改支付、鉴权、数据库迁移，显然不应该使用同一种人工介入强度。强迫工程师手敲所有样板代码，只会把时间重新花在低价值劳动上。

更可行的标准不是“代码是不是人写的”，而是人能否在模型退出之后继续负责。

可以用五个问题检查这种责任是否仍然存在：

  1. 能否说明方案为什么这样设计，而不只是描述代码做了什么？
  2. 能否指出关键约束、异常路径和最可能失败的位置？
  3. 能否在不重新询问模型的情况下，完成一次小修改？
  4. 能否为结果设计有效的测试与线上观测？
  5. 能否在修改失败时停止影响并恢复系统？

如果五个问题都只能交回给 Agent，团队得到的不是自动化，而是一项没有写进账本的依赖。

让 AI 加速，但不要让理解退出循环

控制认知债务，不需要把所有任务退回手工时代。更合理的办法是根据风险和陌生程度，决定人应该在哪个阶段进入。

任务类型 可以交给 AI 人需要保留的工作
低风险、机械化修改 直接生成、批量修改、运行格式化与测试 抽查结果，确认改动范围没有外溢
熟悉业务中的一般功能 生成实现、补测试、修复反馈 定义方案、约束、不变量和验收标准
陌生代码或陌生领域 解释调用链、比较方案、给出小步修改 阅读原始资料，逐段验证，建立自己的系统模型
鉴权、计费、迁移等高风险路径 辅助检索、生成测试案例、检查遗漏 人工设计、分阶段实施、真实验证和准备回滚

无论选择哪一种方式，有三件事不应该完全外包。

第一是问题定义。模型可以实现一个需求，但它不知道哪些业务约束没有写进需求，哪些历史行为不能改变。

第二是验收标准。让写代码的模型同时决定“怎样算完成”，很容易得到一个自洽但错误的闭环。测试、日志和实际结果必须能够从系统外部证明修改有效。

第三是失败处置。真正的所有权不是合并代码，而是在凌晨报警出现时，知道先止损、再定位，还是直接回滚。

这些工作看起来没有“生成 500 行代码”直观，却决定了代码能否从演示走进长期运行的系统。

AI 没有让经验贬值，只是改变了经验的形状

“AI 奖励专家”不应该被理解成新手不配使用 AI。恰恰相反，大语言模型第一次让很多人可以越过技能缺口，完成原本无法开始的任务。它把每个人都向通才推近了一步。

但能够生成一个局部答案，与能够把答案放进真实系统，是两种能力。

未来更值钱的经验，可能不是记住更多语法，而是对业务、数据和系统形成稳定的内部模型；能够发现一个方案“哪里不对劲”；能够把模糊目标拆成可验证步骤；也能够在工具给出错误答案时接过方向盘。

代码会继续变得更便宜，理解代码不会。

所以，AI 编程真正值得追求的不是让人尽快退出开发过程，而是把人的时间从机械输入移到判断、验证和承担结果上。代码可以由模型生成，但方向和后果必须有人理解。

资料与口径