当 AI 一天处理 285 个 case，人该怎么办？
当 AI 一天处理 285 个 case，人该怎么办？
——「人 × Agent 协作」系列开篇
一句话结论
当 AI 像队员一样每天产出代码、分析、报告后，真正棘手的不是"AI 能不能写代码"，而是三个连锁问题：为什么必须让它写、人怎么 Review 得过来、谁来管控整个流程。本系列用六篇逐一回答。
一个 AI 队员的早晨
每天早上 9 点，我们的工单系统会准时"活过来"。
不是有人在值班，是一个 AI 队员——我给他起个化名叫小布——开始跑他那一天的自动化。他不是某个聊天框里的助手，他是我们团队的一个编制外成员：有自己的内部 IM 账号，能创建工单指派给人，能主动在群里 @ 同事，手里同时挂着十几个并行的工作分支。
某个寻常的周二早上 9 点，小布跑完一轮巡检，交出这样一份答卷：
- 拉取并扫描了工单系统里 6486 条历史 issue；
- 自动关闭了 17 条被标记为"模型幻觉"的工单——这些是分诊 agent 排查后确认"规则/代码/上下文都没问题、纯模型自身犯错"的 case，当前没有工程修复项；
- 发现 112 条指派给人的工单，已经停滞超过 5 天——他把清单整理好，发消息提醒了工单负责人；
- 处理了 2 条卡在"智能体"身上的工单：其中 1 条他能判断属于哪个业务域，自动转给了对应产品经理；另 1 条他处理不了，明确标注"仍需人工关注"并写清原因；
- 9 点 30 分，他切到另一个任务：自动比对线上 staging 环境的最新部署，针对 65 个文件、4500 行新增代码，产出一份产品架构与 UX 审查报告，精准定位到某组件第 220 行的一处空态分支回归，给出归因、用户后果和修复建议。
而这，只是他一天的产出。在他本地的工作目录里，已经累计了 285 份线上 AI 审核 bad case 的分析报告——每一份都是一次真实生产事故的根因拆解。
数字背后：三个被忽视的崩溃点
把这些数字摊开看，你会发现一件不太舒服的事：如果这些工作全部由人来做，团队早就崩溃了。
这不是夸张。我们把小布一天处理的事，拆成三个真实的"崩溃点"：
崩溃点一：bad case 的洪流。 我们的产品是一个 AI 审核系统，线上每天都在产生审核结果，也每天都在产生"判错了"的 case。285 份分析报告，意味着 285 次需要人去拉 trace、看日志、定位是规则问题还是模型问题、判断要不要改代码。一个熟练工程师，认真分析一个 case 至少要半小时——285 个 case 就是 140 多个小时，将近 35 个工作日。也就是说，光是把已经发生的 case 分析完，就需要一个人全职干一个多月，而且这期间新 case 还在源源不断地产生。
崩溃点二：工单的慢性停滞。 112 条超时 5 天的工单，是更隐蔽的崩溃。它不是某一天突然爆发的，而是每天漏一点、忘一点，慢慢积出来的。人不是不会做，是会忘。被新需求打断、被会议切碎、被更紧急的线上故障抢走注意力——一条工单就这么静静躺了 5 天。而小布判断"智能体卡单"的阈值是 24 小时，是这个数字的二十分之一。
崩溃点三：AI 自己制造的噪音。 最微妙的是 17 条"模型幻觉"工单。这些是真实的 bad case，但分诊 agent 排查后排除了规则、代码、上下文的问题，确认是模型自身犯错——这类 case 当前没有工程修复项。如果不归类关闭，它们会一直挂在研发队列里，既没人能处理，又占据看板、污染统计。让研发逐条复核"这条还有没有工程抓手"，是对人类注意力最纯粹的浪费。
三个问题
讲到这里，我想把这一系列文章真正要讨论的问题，正式抛出来。
过去两年，所有人都在谈"AI 能不能写代码""AI 能不能取代程序员"。但当 AI 真的像一个队员一样开始每天产出代码、分析、报告之后，我们发现，真正棘手的根本不是这些。真正棘手的是下面三个问题——它们是 AI 自动写代码之后必然会到来的连锁反应，却几乎没有被认真讨论过：
问题一：为什么必须让 AI 自动写代码？ 当 bad case 洪流、工单停滞、噪音清理这些事已经超出人力上限，"要不要让 AI 写代码"就不再是个选择题。但它的真正价值到底是什么——是更快，还是别的什么？
问题二：AI 写完之后，人 Review 不过来怎么办？ 4500 行 diff、65 个文件，每天一次。让人逐行看，是另一种崩溃。我们的做法是：再让一层 AI 自动 review，把全量 diff 压缩成"几个需要人判断的头部问题"。用 AI 治理 AI 的产出——这背后是一整套分级门禁的方法论。
问题三：谁来管控 AI 之后的整个流程？ 当 AI 既能写代码、又能 review、还能创建工单、@ 人的时候，"管控"就不再是个权限开关的问题，而是一个组织形态问题。AI 队员、定时自动化、人，三者怎么分工？决策权始终在谁手里？AI 处理不了的时候，怎么保证它不会静默吞掉问题？
这三个问题，就是本系列接下来六篇文章要回答的。
本系列不打算讲什么
在正式开始之前，我想先划几条边界，避免读者期待错位。
这不是一篇"AI 编程真香"的软文。 我们不会花篇幅论证"AI 让效率提升 X 倍"。效率提升是前提，不是结论——我们要讨论的是效率提升之后，组织和人怎么不崩。
这也不是一篇技术教程。 你不会在这里看到具体的 prompt 怎么写、worktree 怎么自动清理、某个 CI 脚本怎么配。这些实现细节可以作为附录，但它们不是主角。
这更不是"AI 取代人"的预言。 恰恰相反。当你看完小布一天的工作，会发现一个反直觉的事实：AI 干掉的，全是那些不该占用人类注意力的事——重复分析、定时巡检、噪音清理、全量 diff 审阅。而真正需要人的部分——工程质量判断、业务正确性取舍、组织决策——一个都没有被拿走，反而被放到了更突出的位置。
真正要讲的，是一种新的协作模式
我们想讲的，是一种正在我们团队、也正在 Cloudflare、GitLab、OpenAI 等前沿公司里成型的协作模式。
不妨先剧透一句它的核心：
自动化的目标不是减少人的参与，而是把人的参与推迟到真正需要判断的节点。
围绕这句话，本系列会展开六篇：
- 第 2 篇正面回答"为什么让 AI 自动写代码"——用三个崩溃点说明，这不是效率问题，是团队存续问题。
- 第 3 篇正面回答"人 Review 不过来怎么办"——拆解用 AI 自动 review 治理 AI 产出的分级门禁体系，并对比 Cloudflare 的多 Agent 评审架构。
- 第 4 篇正面回答"谁来管控后续流程"——讲清楚 AI 队员、自动化、人三者组成的管控三角，以及"AI 处理不了必须显式转人工"这条铁律。
- 第 5 篇回到协作的物理基础——如何把工作现场从"个人电脑"搬到"共享环境"，让人能真正接住 AI 的产出。
- 第 6 篇讲质量保证——机器门禁只管机器能管的，人只判人该判的。
- 第 7 篇收束全系列，谈人在 Agent 时代的不可替代性。
回到那个早晨
文章最后，让我们再回到小布那个早晨。
那天他做完所有巡检，把 112 条超时工单的清单发给了工单负责人。清单的第一行，是一句加粗的总结，它把"本轮共 112 条超时、已处理多少、还有多少需要人工关注"四个数字，浓缩成一句话。
这句总结背后的设计哲学，其实就是这一整个系列想说的全部：
AI 把能算的都算清楚了，把能处理的都处理完了，然后把那些它实在判断不了的、需要人拍板的，干干净净地交回到人手里——不淹没你，也不替你做决定。
这是我们理解的、AI 与人协作最该有的样子。
接下来的六篇，我们慢慢拆开讲。
（本系列第 2 篇《为什么必须让 AI 自动写代码：三个被忽视的崩溃点》将于下篇发布。）