关于编码智能体（coding agents）提高生产力的说法是，它们消除了打字瓶颈。但在实践中，工程师真正遇到的瓶颈却截然不同。工程师再也无法在脑中掌握整个系统，因为智能体修改文件的速度快于工程师阅读的速度，编写测试的速度快于工程师推断覆盖率的速度，重构抽象的速度快于工程师在设计层面（而不仅仅是编译器层面）验证类型检查的速度。
那个紧凑的内环——假设、更改、观察、优化——定义了胜任的工程工作，但它正悄然瓦解为另一种循环。工程师现在是在审查智能体的输出，而不是建立对系统的直觉。2025 年中期的一项 METR 随机对照试验发现，经验丰富的开源开发人员在使用 AI 助手处理熟悉的代码库时，速度慢了 19%，但他们却报告感觉快了 20%。认知感知的生产力与实际生产力之间这 39 个百分点的差距并非测量误差。这是为了吞吐量而默默牺牲理解力的代价。
内环与打字无关
有着十年系统交付经验的工程师都知道，内环不是击键周期，而是认知周期。你形成一个关于某种状态如何流经三个模块的假设。你做一个微小的改动。你观察系统的行为是否符合你心智模型的预测。如果符合，你的模型就得到了强化。如果不符合，你就学到了关于系统的一些新知识，并更新了你的模型。
内环的产出不是 diff。而是那个现在能以一小时前还无法达到的水平来推导系统的工程师。diff 只是副产品。
编码智能体加速了 diff，却减慢了认知。改变仍在发生，但“假设-测试-更新”的循环消失了，因为工程师被隔开了一个层级：他们不再是形成假设的人，而是在审查智能体的假设；他们不再是观察行为的人，而是在阅读智能体对行为的总结。原本可以更新他们心智模型的信号，被一个拥有自己模型且没有义务保持工程师模型完整的解释器过滤掉了。
几个月后，工程师会发现他们仍然可以交付功能，但再也无法回答关于他们所负责模块的架构问题。他们并没有停止学习，而是再也没有什么可以学习的了，因为那个教导他们的循环已经消失了。
没有理解的吞吐量是一种替代，而非收益
关于编码智能体的标准论调是它们是力量倍增器。而诚实的说法是它们是一种替代。它们用一个单位的理解力换取一个单位的吞吐量。这种交换是否划算，取决于你下周需要这位工程师做什么。
这个数学计算让人感到不安。如果一个团队只衡量速度——合并的 PR 数量、代码行数、故事点——那么这种替代看起来就像是纯粹的双赢。2025 年卡内基梅隆大学的一项研究报告称，开发者在样板代码上花费的时间减少了 28%，而审查 AI 针对复杂逻辑建议的时间增加了 19%。这种转变是从“创作”转向“评估”，而评估在短期内认知成本更低，在长期内认知价值更贫乏。你可以评估一千次某个东西，却永远无法建立起能让你从零创造出类似东西的结构化模型。
如果不计算这种替代成本，团队就会在庆祝仪表盘数据的同时，导致工程能力的衰退。六个月后，代码库增长了，但团队对它的掌握程度却缩水了。最具体的症状是当工程师再也无法引导新员工入职时，因为他们自己也解释不清自己交付的模块。智能体无法转移它的模型，因为它从未拥有过一个可供转移的模型——而工程师从一开始就不是模型的来源。
仪表盘无法衡量的工程师损失
理解力衰退带来的损失在关键时刻（通常是发生事故时）才会显现。首先会出现三种模式：
对自己模块的“架构文盲” ：工程师可以在行级层面描述一个函数的功能，但无法从设计层面解释它存在的原因。“为什么”从未被争论推敲过；它是被生成并接受的。当新的约束条件出现、函数需要演进时，没有设计原理可供参考，因此变更也是被生成并接受的，这加剧了问题。品味的丧失 ：如果不运行代码，工程师就无法判断一个提议的结构是好是坏。判断力是某种压缩形式——它源于以前在类似结构上犯过错，并在随后的 Bug 中感受到了那种“错误感”。智能体阻止了这种错误感的产生，因此这种压缩从未发生。无法在设计层调试 ：当 Bug 不在单个函数中，而在于三个函数的交互方式时，没有构建过这三个函数中任何一个的工程师，就无法对它们应该如何交互建立因果模型。调试变成了考古，然后是祈祷。 速度报告中不会显示这些。但在你试图让代码库完成一些非预生成任务的第一个季度，所有这些问题都会暴露无遗。
保持内部循环活跃的实践 解决方法不是停止使用编程智能体。而是要设计工作流，使循环即使在智能体进行打字时仍能运行。有三种模式在实践中被证明有效。
修改前解释环节 。在智能体进行任何非微小的更改之前，要求它生成一段逻辑说明：它认为该更改的作用是什么，为什么这是进行更改的正确位置，以及可能会破坏什么。工程师阅读逻辑说明并决定是否批准。逻辑说明是强迫工程师心智模型参与进来的产出物。代码差异（diff）是一个既成事实；而逻辑说明是一个工程师可以反驳的假设。Claude Code 的 Plan Mode 和多个智能体 IDE 正是朝着这个方向发展的，因为“仅有 diff”的循环会产生“AI 震荡（AI thrash）”——即没人能理解的已接受更改。
小幅修改纪律 。要求智能体一次只做一个概念性更改。不是一次一个文件，不是一次一个 PR——而是一个概念性更改。如果智能体批量处理四个更改，工程师的心智模型就必须在两次观察之间吸收四次更新，而每次批量四个时，这种吸收就会停止。Augment Code 的审查工作和其他研究得出了相同的结论：针对单一意图的最小化差异，是人脑仍能处理的单元。重点不是为了智能体而控制节奏，而是为了人类的理解带宽。
脱离智能体的时间 。一个周期性的时间窗口——每天一小时，每周半天，任何合适的安排——在这段时间里，工程师不使用智能体进行编码。目的不是为了怀旧。而是为了肌肉记忆。在没有检索的情况下导航代码库、在脑海中处理多文件更改以及在没有提示（prompting）的情况下形成假设的能力，是一种会退化的技能。如果一个季度不练习，它就会退化。工程师将其描述为“我再也无法用代码思考了”，这正是正在发生的事情：让你在媒介中推理的认知支架已经萎缩，因为该媒介变成了智能体的 UI。
第四种模式较少见，但值得一提：定期解释演练 。在团队层面，每两周要求一名工程师向同事解释他们负责的一个模块——没有笔记，没有智能体，只有屏幕上的代码。团队会跟踪随着智能体吞吐量的提高，这些解释的质量是否在下降。这是衡量理解健康度的唯一直接指标，不需要等到事故发生才暴露问题。
架构层面的认知 编程智能体并不是纯粹的生产力提升。它们是以理解力换取吞吐量的代换，且代换率并非固定。这取决于你如何使用它们。将模糊的意图交给智能体并直接合并返回内容的团队，正在以最高速率进行这种代换。而运行“修改前解释环节”、控制差异流节奏并保护无智能体编码时间的团队，其代换率要低得多，在最重要的维度上可能接近于零。
指标看板不会告诉你你是哪支团队。在这两种情况下，合并的 PR 数量看起来是一样的。你真正需要的信号是目前没有人衡量的：你的工程师今天能否像一年前解释代码那样，清晰地解释本季度交付的代码？如果答案是否定的且你并不感到惊讶，那么你已经付出了代价。如果你感到惊讶，那么你即将付出代价。
可操作的总结不是一项政策。而是一种机制。将理解力健康检查融入你的工程习惯中——解释演练、无智能体回顾、下次重构前的架构测验——并观察曲线。在智能体转型中保持工程能力完好无损的团队，不会是那些速度最快的团队。相反，他们是那些尽早察觉到原本用来学习的循环已悄然断开，并在其中人员忘掉如何使用它之前将其重新连接的团队。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
