只需正确瞄准大炮

James Shore最近发表了一篇关于AI编码代理的文章，其核心论点是：你的AI编码代理必须显著降低维护成本，而不是仅仅加速代码生产。他认为，长期生产力受限于维护成本的复合增长，任何只加速生产而不控制维护的代理本质上是债务洗钱操作——让你今天跳过账单，却要永远偿还。

Justin Duke在本文中回应了Shore的观点。他同意Shore的诊断，即代码是债务、维护成本会复合增长、快速添加功能而团队无法消化的代理长期来看是反生产力的。但Duke在Shore即将得出的结论——当前LLM工具总体上是坏的——处停下了脚步。

Duke提出一个实用的框架：“难度评分”。这个想法很简单：组织中的每个重复性操作都有一定的摩擦，你可以用粗略的成本函数来近似度量。例如，对于发起一个拉取请求，他的版本是：等待测试或CI每十秒加1分；每次工具上下文切换（文档、仪表板、终端）加5分；每次点击加1分；每次手动检查加10分。对于支持工作，版本可能不同：每次分类工单的点击加5分；每次答案不是简单的文档链接加10分；每次需要登录用户账户加25分；每次用户后续回复乘以1.25。

具体的权重不重要，关键是有了函数后，你可以求导，识别出“坏”的操作，然后逐步减少它们，目标是使分数尽可能低。Duke的经验表明，LLMs在降低这些分数方面非常出色。在Buttondown 2026年，他将大部分LLM辅助时间花在挤压内部循环、精简依赖、将诊断和范围界定工作交给后台代理上，获得了超额的回报。

相反，他看到LLMs最有害的部署方式——也是Shore论点最适用的地方——是当工具与代码库的关系纯粹是叠加时。LLMs非常擅长添加功能，而且更隐蔽的是，它们非常擅长告诉你添加功能是个好主意。Duke多次试图说服编码代理不要构建某些东西，但发现这比相反方向更难。他警告，如果搭建一个功能从一周缩短到一下午，答案会倾向于“是”，直到你某天早上醒来发现十六个新端点，却不知道它们为何存在。

但你可以选择不这样使用工具。Duke提供了一个简单的工作手册：首先定义关键操作的难度分数，并让团队讨论完善；然后优先处理明显的低垂果实（通常比预想的多），因为这是内部循环；最后交付改进并重复。

这一切并非LLM特有。Duke指出，维护债务累积的失败模式早于LLM，也将持续下去。LLM的作用是提供了一个快进按钮：让已经在维护债务中失败的组织失败得更快，让有良好评分体系的组织拉大差距。

总之，Duke同意Shore的诊断，但认为治愈方法不是放弃工具，而是将它们指向正确的操作，并牢记：添加代码是编码工具能为你做的最昂贵的事情。