云 / 系统
代理式编程改变的不只是代码的写法，也改变了我的时间安排。交出任务、代理开始工作之后，我需要作出自己的决定：继续守着，还是利用这段时间处理另一个主题？
如果知道它还要二十分钟，我可以开始其他事情。如果它三十秒后就需要我的答复，我可能会等着。困难在于，我往往不知道自己面对的是哪一种情况。
等待不等于空闲
虽然不用亲手编写每一处修改，我也未必已经有空。可能还要批准操作、澄清需求或检查结果。看着对话记录像是在参与工作，有时却只是阅读状态更新，没有推进任何事情。
离开后，代理又可能很快遇到问题，停下来等我。于是，要么我等代理，要么代理等我。
值得开始另一个主题吗？
短暂空档或许适合处理一件小事。另一个技术问题则需要恢复上下文、理解上次的进度并进入思考状态。这种切换本身就有成本。
如果我刚进入第二个主题，第一个代理就完成了，我又要选择：打断新工作，还是让完成的结果先等着？再开一个代理并不自动解决问题，也可能让多个工作流同时等待审查。
所以有用的问题不只是“代码什么时候完成”，而是“在这项任务再次需要我的注意力之前，我能有多少时间有效处理其他事情”。
旋转图标不能帮助安排时间
“工作中”不能区分代理是在探索问题、实施修改、运行检查，还是等待外部服务。
这些阶段对安排时间的意义不同。分析阶段可能发现缺失的需求；运行测试时可能有更容易预估的空档；批准请求需要立即回应。补丁完成后仍需审查，这部分工作不会因为自动化而消失。
如果缺乏区分，我只能围绕一个黑箱安排时间：不是查看得太频繁，就是回来得太晚。
ETA 应该告诉我什么？
我不需要假装了解未来的倒计时，而需要足够的信息来决定下一步：
- 代理处于什么阶段？
- 它能独立继续，还是现在就需要我？
- 下一个可利用的时间窗口预计是短还是长？
- 估算有多不确定，情况是否已经变化？
例如，“验证中 · 粗略窗口：几分钟 · 无需输入”会比旋转图标更有帮助。这是界面设计示例，不是实测预测，也不表示已有这项功能。
显示还应区分预计完成时间与下一次需要回应的时间。任务整体可能很长，但几乎马上就需要一个决定。
更好地规划，而不是制造承诺
早期估算一定有不确定性。范围会改变、检查可能失败、外部服务可能延迟。有用的预测应说明变化，而不是让已经到零的倒计时继续存在。
第一步可以很小：明确区分“独立工作中”和“正在等你”。之后再加入有依据的粗略时间范围，并与真实结果对照，逐步判断它能在多大程度上支持规划。
有时应该继续陪着代理，有时适合处理小事，有时确实值得切换到另一个主题。代理式编程可以在我做其他事情时推进实现；要在日常工作中获益，我还需要判断何时离开、何时回来，以及交接仍需多少注意力。
继续阅读实用指南：构建诚实的 ETA 显示。