认真使用 AI 编程代理之后，最先让人惊讶的往往不是模型有多聪明，而是：
“它到底什么时候下班？”
白天调查，傍晚实现，晚上测试，半夜丢进去一个 bug，第二天早上它还在继续修。
如果这是人类团队，马上会涉及夜班、加班、交接、疲劳、排班和管理。AI 的约束却变成了套餐、用量上限、工具错误和系统可靠性。
重度使用之后还会出现更奇怪的现象：
一周的额度，几天就能烧完。
一开始觉得新额度大得离谱，几天后却进入“这周已经让它干太多了”的状态。
劳动法好像消失了，只是换成了 rate limit。
0. 真正该看的是吞吐量，不是工作时长
“AI 一天运行了 12 小时”很容易让人拿它和人类 12 小时工作制比较。
但真正重要的是：
- 完成多少调查
- 修改多少文件
- 跑了多少测试
- 修掉多少异常
- 多少结果真正到达生产环境
- 多少结果卡在中途
AI 可以高速反复执行搜索、比较、修改、测试。因此关键不是“跑了多久”，而是多少有效工作真正穿过整个流水线。
1. 24 小时运转的可怕之处，不是夜班便宜
人类要做 24 小时运营，需要夜班、补贴、排班、交接和缺勤应对。
AI 则通常只受产品额度和系统条件限制。
奇怪的不是“晚上也能工作”。
而是同一个执行单元可以从白天一路跑到深夜，不需要换班。
AI 也会失败，但通常不是因为困，而是上下文不足、错误假设、工具失败或规格理解错误。
2. 额度变大，任务也会膨胀
额度变大之后，人就不会再节省。
以前自己做的事情，也会交给 AI。
原本只是“调查一下”，很快变成：
调查→实现→测试→修复→重测→看日志→继续修。
所以即使额度看起来大了很多，也可能几天就烧光。
这不一定说明额度太小。
供给增加后，对 AI 的需求也被诱发出来。
3. 周期恢复并不是停工，而是建立缓冲区
如果用量会定期恢复，那么等待期间可以做：
- 记录新异常
- 整理复现条件
- 积累日志
- 归类可能原因
- 给下批任务排优先级
额度恢复后，再一次性批处理。
工作方式从实时聊天变成了批处理工厂。
AI 在休息，队列却在长大。
4. 高质量模式更适合“卡住时的设计会议”
高质量、高消耗的推理模式可能一次就吃掉大量额度。
但这并不等于浪费。
真正卡住时，可以让它负责：
- 枚举根因
- 整理依赖关系
- 制定修复顺序
- 设计防复发措施
- 决定监控指标
也就是把它用在高不确定性的规划问题上。
普通任务用普通模式。 卡住时升级。 高质量模式负责诊断和计划。 然后再回到普通模式执行。
这就是合理的升级机制。
5. AI 越快，瓶颈越容易转移
一个典型流水线可能是：
生成 → 保存 → 转换 → 发布 → 上线 → 验证
任何一个环节不稳定，前面再快都没用。
生成 100 个，只上线 99 个，剩下 1 个就成了库存。
如果反复发生，就不是偶发错误。
而是良率问题。
6. “文章没出来”不一定是生成失败
可能的故障点包括：
- 生成成功但保存失败
- 元数据校验失败
- 本地化流程停止
- 没进入发布队列
- 已部署但验证失败
- 线上存在但列表页没展示
因此每个阶段都要有计数器。
生成 120 → 保存 120 → 入队 118 → 线上确认 116
这样丢失的 4 个就能被看到。
允许失败，不允许静默消失。
7. 24 小时 AI 工厂必须具备自动恢复
理想流程是：
- 检测缺失
- 隔离对应 ID
- 记录失败类型
- 可安全重试则自动重试
- 只有重复失败才升级给人或更强模型
不要全部重跑。
只重处理坏掉的部分。
8. 人类角色会减少，但不会消失
人类仍然决定：
- 什么最重要
- 可接受多少失败
- 哪些事情不应自动化
- 速度和质量谁优先
- 哪些异常值得升级到高质量模式
人类从执行者变成了流水线设计者。
9. 真正可怕的不是 AI 工作太多
真正的问题是烧掉大量额度后，结果却：
- 卡在半路
- 没上线
- 缺失不可见
- 同一个 bug 反复出现
- 高质量模式被拿去做杂活
更好的原则是：
普通任务便宜快速处理；真正卡住的地方才用高质量模式；失败必须可见；可重试的失败尽量自动恢复。
这时你不是在“使用 AI”。
你是在设计一座让 AI 能持续工作的工厂。
