AI编程新痛点：速度越快，认知债越深

代码生成越快，你所背负的“认知债务”便越沉重

近期在使用 Coding Agent 时，我产生了一种愈发强烈的感触：

虽然它确实能显著提升代码编写效率，然而随着代码体量的增加，系统未必会因此变得更加健壮可用。

在许多场景下，AI 就像是在一块地基日益不稳的地面上不断加盖楼层。

底层或许还能居住，上层看似也未曾坍塌。然而，若地基未经重新梳理，承重结构亦未经过严谨核查，每一次加墙或改管，都是在拿之前的结构做赌注。

这正是 Coding Agent 最易引发的隐秘风险：

代码产出速度虽然攀升，但系统理解能力却未能同步提升。

代码日益庞大，架构愈发盘根错节，模块间的关联日趋模糊。从短期来看，功能尚在交付；但从长远考量，系统的可维护性、可扩展性及稳定性都在不断恶化。

这便是：认知债。

技术债是代码结构上的亏欠，而认知债则是人类对系统理解上的缺失。

AI 编写得越快，这笔债务便越容易积聚。

从“亲力亲为”到“被动签收”：理解权是如何流失的

昔日编写代码，人至少亲身经历了一遍思考的全过程。

你需要拆解需求、定位文件、研读接口、编写实现、执行测试。这一过程虽显缓慢，却能将系统架构深深烙印在脑海中。

你或许无法记住每一行代码，但你知道关键路径所在，知晓何处不可随意变动，以及遇到问题时应从哪一层开始排查。

然而，Coding Agent 将这一整套流程大幅压缩。

你只需设定一个目标，它便能读取文件、修改代码、补充测试并提交差异。顺利时，这令人倍感畅快。昔日数日的劳作，如今仅需十几分钟便可见成果。

但代价在于，你极容易跳过“建立理解”这一环节。

Simon Willison 近期转述了 Geoffrey Litt 的一个观点，名为“Understand to participate”。其意并非要求你逐行研读 AI 编写的每一行代码，而是要理解到这样一个程度：你仍具备继续参与该项目的能力。

这一界限至关重要。

若你仅关注结果，觉得测试通过、页面可访问、差异看起来尚可，那你实际上已从工程参与者退化为了交付签收员。

短期看是效率提升，长期看则是理解权的流失。

一旦理解权流失，随后便会发生三件事。

其一，你不知晓 AI 为何如此修改。当需求变更时，你只能继续让 AI 进行猜测。

其二，你不知晓风险潜藏何处。系统出现故障时，你无法判断是局部问题，还是架构已被悄然扭曲。

其三，你愈发依赖更强大的模型。这并非因任务真需更强模型，而是因为你已丧失了独立接手的能力。

它不像 Bug 那般即刻爆发，更似一层迷雾，起初只是视野受阻，继而便是寸步难行。

认知债如何转化为真金白银的账单

第一层成本，是 Token 债。

SonarSource 近期发布了一项实验：研究人员利用 Claude Code（Sonnet 4.6）进行了 660 次试验，涵盖 6 组最小对照代码库及 33 个任务，旨在对比干净代码库与混乱代码库对 AI Coding Agent 的影响。

干净代码使 AI 节省了 7-8% 的 Token，且文件回访次数减少了 34%。

第二层成本，是维护债。

当 AI 一轮轮向系统中追加代码，而人未同步理解结构时，系统便会逐渐演变成另一种“屎山”。

这并非传统意义上“无文档、无重构”的屎山，而是每一段代码看似都有依据，每一个差异都能给出解释，但整体拼凑起来却无人敢轻易触碰。

若你想修改一个小功能，却发现它牵扯着三个模块，但这仅仅是三个模块吗？

若你想添加一个字段，虽测试了主路径，但边缘场景是否覆盖？

在此状态下，维护成本将持续攀升。这并非因 AI 不善编写，而是因系统已失去清晰的边界。

第三层成本，是业务延展性变得脆弱。

若系统结构清晰，面对新需求，你能判断应加在哪里，哪些能力可复用，哪些地方需抽象。

但若系统被认知债拖累，新需求便会转化为风险源。

每次新增功能，都如同在一栋地基不稳的房屋上继续加盖房间。此时，AI 的效率反而会掩盖问题。

它能迅速给出一个实现，甚至能补全测试。但你无法确定该实现是否进一步加重了系统负担。

功能上线后，却会源源不断地涌现边缘 Bug：此处状态未同步，彼处权限未覆盖，另一边缘流程亦被新逻辑误伤。

如何善用 Agent 而又不丢失判断权

这并非意味着拒绝使用 Coding Agent。

而是要重新定义你的工作重心。

Anthropic 于 7 月 6 日发布了一个 Alberta 政府案例：Alberta 省政府利用 Claude Code（配合 Opus 和 Sonnet 模型）扫描了 4.66 亿行代码，约 50 个 Agent 并行工作，耗时 20 小时完成大规模安全审查。官方称，人工完成同等工作可能需要数年。

Claude Code 不仅负责扫描，还能定位文件与行号、生成修复方案、补充测试，甚至重写部分旧系统。但在正式上线前，仍须由人类工程师审核与批准。

这才是 Agent 落地的真实形态。AI 承担大量探索、扫描、初稿及修复建议工作，人则把控目标、边界、证据与验收标准。

未来工程师的工作重心，将转变为以下几件事。

其一，能否清晰定义任务边界。

研读结构，制定计划，进行架构抽象。

其二，能否要求 AI 解释关键路径。

需让其回答：核心逻辑位于哪些文件？为何改动必须发生在此处？是否存在替代方案？风险点何在？

其三，能否将差异（Diff）切小。

过大的差异最易制造认知债。AI 若一次改动 20 个文件，你极易仅浏览摘要。唯有切小的差异才能保留人的判断力。每一步均可审核，才有资格进入下一步。

其四，能否建立验收证据。

测试仅为其中一部分。还包括复现步骤、截图、日志、基准测试、用户路径、回滚方案。AI 可生成证据，但你要判断证据是否足以支撑上线。

这意味着你需要让 AI 多劳作，但不可交出理解权。

写在最后：坚守的是判断权，而非代码量

代码可让 AI 编写，测试可让 AI 补充，文档可让 AI 起草，甚至架构图亦可由 AI 生成。但你需要理解整体框架与抽象方案。

因此，我如今使用 Coding Agent 时，会刻意保留几个动作：

令其先读后写。令其先解释后改。令其小步提交。令其提供证据。

令我自身始终能说清：此次改动解决了什么，触碰了何处，风险为何，以及凭什么可以合并。

AI 编写代码越快，理解代码便越不能被外包。

我需坚守的是对系统的判断权。

想了解 AI 最新观点，请点击下方名片关注我。