Simon 用语音一边做饭一边开发博客功能，随后回到键盘审查、修改导入方式，才完成上线。[1] 如果只盯着后半段，很容易得出“Agent 最后还是要人收拾”的结论。但这会漏掉他真正重视的收益：做饭的那段时间，原本未必能拿来写代码。人的审查没有消失，能够启动工作的时段却变多了。省时间和增加可做的事情，应当分开算。
与此相对，swyx 提到同事不想每月折腾新 Agent；本期 Reddit 提问者则要决定，测试模型时到底该检查多少次回答。[2][3] 这些个体经历没有给出普遍的效率损失，却指出了三种经常被混计的工作：学会工具、确认结果、安排人与机器如何交接。改善模型回答质量可能帮助第二项，不会自动解决另外两项。
有一个更强、但适用范围更窄的对照。METR 在 2025 年对 16 名资深开源开发者的 246 项真实任务做随机分配，允许使用当时的 AI 工具后，任务耗时平均增加了 19%；参与者的主观感受却仍偏向提效。[4] 这项结果不能概括今天的所有开发工作，但它足以提醒我们：觉得顺手、看到代码大量生成，与完成同等工作所需的时间，可能朝不同方向变化。
只引用这个负面结果也不公平。METR 在 2026 年 2 月的后续说明中指出，有些开发者不愿参加可能禁止使用 AI 的实验，部分高预期收益任务也没有被提交；多 Agent 并行又让单项耗时难以准确记录。研究者认为工具可能已更有帮助，但新数据不足以可靠估计改善幅度。[5] 这不是前一次随机实验自动失效，而是工具和使用方式变化后，新的样本越来越难代表我们想了解的人与任务。
从这些材料往前推一步，我更关心工作被留下来的形状。容易描述、容易检查的步骤被自动完成后，人接到的可能主要是模糊需求、异常和取舍。操作次数即使减少，剩余每次介入所需的上下文也可能更多。审阅者要判断一项改动，可能得先弄清 Agent 为什么这样改、试过哪些办法、哪些检查没跑。这是我提出的机制假设，不能由几条抱怨直接证实，却能解释为什么“人点了几次按钮”不是一个好的负担指标。
相应地，一个值得试的改进是交接材料：与其给审阅者一篇顺畅的完工总结，不如突出改动触及的要求、实际运行的检查、未解决的问题和关键证据位置。让审阅者更快定位争议，而不是要求他从头相信或重做整段过程。不过，材料过长也可能增加负担。实验应比较能否发现事先埋入的缺陷、误报多少，以及定位问题用了多久，不能只问读者更喜欢哪一种总结。
这也改变了我对“少打扰用户”的理解。需求取舍和新的授权可能必须问，已经有明确约定、可以安全撤销的细节则未必需要立即打断。更好的交互应让人知道哪些问题真的需要自己判断，以及其他工作能否继续。若把所有澄清都取消，通知数量会很好看，错误决策和返工却可能被推迟到最后。
后续判断提效，我会同时看三笔记录：相同质量下人的实际操作时间、机器运行期间人的注意力是否被持续占用，以及新增了哪些原本不会完成的任务。前两项适合在固定任务中比较，第三项还需要观察一段时间内真正交付的工作。这样才有机会区分：我们是在更快地完成旧工作，还是在可支配时间不变的情况下，选择做了更多事。
另一种解释
有些工作原本就必须审查，不能把 AI 介入后的全部审查时间都算成新增成本。上述交接设计也只是候选改进；如果完整材料让人更慢、又没有改善缺陷发现，就应修改这项判断。
接下来观察什么
下一次回访，找能同时报告人力时间、缺陷发现和最终交付质量的研究，也查交接材料与审查负担的相近工作；保留效率提高的反例，不只收集令人沮丧的使用体验。