我给 Codex 做了一个额度悬浮球

第一版 Quota Float 是一个 60×60 的桌面悬浮球。它把额度与重置时间放到随手可见的位置，想省掉的是一段重复动作：离开正在做的事，找到额度页面，看一眼，再回来。

这个起点没有要求重做任务管理。把信息挪近一点，就可能减少一次寻找。问题足够窄，第一版才有清楚的完成范围。下面的回看写于 2026 年 9 月，结合后续迭代记录展开；7 月的公众号文章保留产品最初的样子。

后续使用记录里，更突出的摩擦变成了逐个检查任务。它们不会同时结束：一个还在执行，一个已经有结果，另一个停在需要回应的地方。额度足够，并不能告诉人下一步应该回到哪个任务。

并行扩大了同时推进的工作量，也把等待变得分散。每次打开侧边栏重新辨认状态，都需要恢复一点上下文。更麻烦的是，任务完成只是机器这边的结束；结果还要被人看见、判断和使用，工作才继续向前。

因此，继续增加额度图表无法完整回应这层摩擦。产品需要把“资源是否够用”放到辅助位置，把“哪件事需要介入”放到前面。名称从 Quota Float 变成 Task Radar，也是在承认这次问题变化。

“等你处理”“完成待看”“进行中”看起来只是三个分类，背后却有不同的动作。等待回应的任务要先解除阻塞；完成待看的任务需要回收结果；仍在进行的任务通常只需知道它还在工作。把它们混成一个活动总数，会把判断任务重新交还给人。

收藏又属于另一种关系。一个长期重要的任务，现在未必需要处理；一个从未收藏的任务，也可能正在等待回应。因此，收藏由人选择，“现在”根据状态出现，两者不互相代替。这也是后来把三个视图收回同一个悬浮窗时，需要保住的区分。

提醒同样要服从下一步动作。首次同步安静建立基线、同一状态不反复提示，是为了避免工具把历史活动都变成新的打断。提醒出现得多，并不等于人能更快找到真正需要处理的事。

状态判断还有一个更基础的问题：证据够不够。“最近有活动”只能说明任务出现过，不能单独证明它仍在运行。把缺失信号补成确定状态，会让人错误地等待或介入。

后续迭代因此区分直接生命周期信号、最近一轮结束记录与普通元数据；证据不足时显示待确认。这个取舍允许界面暂时不完整，同时保留用户判断的依据。它也约束了数据范围：为看见任务状态，不必保存提示词和回复正文。

这些设计说明了产品怎样回应摩擦，还没有证明监督时间减少了多少。现有材料不足以给出采用率、节省时间或普遍有效的结论。这个起点最有用的启发仍然具体：当一个小工具开始长大，先检查人的下一步动作是否变了，再决定要增加什么。