认真使用 AI 编程代理之后，最先让人惊讶的往往不是模型有多聪明，而是：
“它到底什么时候下班？”
白天调查，傍晚实现，晚上测试，半夜丢进去一个 bug，第二天早上它还在继续修。
如果这是人类团队，马上会涉及夜班、加班、交接、疲劳、排班和管理。AI 的约束却变成了套餐、用量上限、工具错误和系统可靠性。
重度使用之后还会出现更奇怪的现象：
一周的额度，几天就能烧完。
一开始觉得新额度大得离谱，几天后却进入“这周已经让它干太多了”的状态。
劳动法好像消失了，只是换成了 使用限额。
额度一多，想让它干的事也多了
额度变大之后，人就不会再节省。
以前自己做的事情，也会交给 AI。
原本只是“调查一下”，很快变成：
调查→实现→测试→修复→重测→看日志→继续修。
所以即使额度看起来大了很多，也可能几天就烧光。
写了120篇，网站上却只确认了116篇
假设写好了120篇文章，也保存了120篇。但进入发布等待名单的只有118篇，最后在网站上确认找到的只有116篇。
把数字排开，就知道去哪找：保存后有2篇停住了，后面又停了2篇。未必是AI没写出来。可能是保存失败，标题等信息不符合要求，或翻译做到一半停了。也可能已经发布，只是列表页没有显示。
写好120 → 保存120 → 等待发布118 → 网站确认116。
这些是说明用的例子，不是实际成绩。中间每步也记下数量，才找得到少掉的4篇。失败可以发生，最怕的是悄无声息地消失。
老是卡住时，再让它仔细想想
普通修改能顺利往前走，就继续用平常的模式。总在同一步失败时，再请花更多时间思考的模式列出可能原因，排好修复顺序。有了计划，就回到平常的操作。
更高档的模式可能消耗更多额度。比起每个小修改都用它，我更想留给“为什么发不出去”这种难题。换个创可贴不用每次都找专科外科医生；不知道该从哪下刀时，专家就有用了。
重做卡住的文章，不用全部重来
找到缺少的文章后，记下编号和停住的原因。可以安全重试就再试；又在同一步失败，就请人或另一个AI查看。没必要让全部文章从头重写。
等额度恢复时，也能整理错误记录和重现问题的方法。如果服务会定期恢复额度，恢复后就能先交给它重要的问题。恢复时间和数量取决于服务规则。
先问文章到了没有
哪些文章先做，发布前检查什么，哪些事不许自动重试，仍然要由人决定。
之后，比起整天盯着屏幕，我更希望一眼能看出哪篇停住了。AI写得越快，卡在保存或发布的一篇就越显眼。
“AI还能干，可那篇文章去哪了？”
让夜班搭档反复写同一篇，浪费的不是它的睡眠，而是额度。
