当 AI 累计做完 285 批分析，老张说不上哪里不对劲

编辑说明：本系列基于团队真实工程实践改编。"老张"是多个技术管理者的合成化名，"阿行"是对外人格化的 Agent 系统。文中的运行数字来自真实记录，对话和内心活动为叙事化重构。

老张第一次感到说不上来的不对劲，是在一个周二早上。

他 9 点到工位，泡了杯茶，打开电脑。内部 IM 里躺着一条消息，是团队新来的"AI 队员"阿行发的，发送时间凌晨 2 点 17 分。

老张本来没当回事——自从公司要求"用 AI 提效"，他给团队配了这个叫阿行的 AI，让它跑一些自动化。头几天老张还每天看看报告，后来发现也就是些例行巡检，就慢慢不怎么看了。

但那天早上他点开消息，多看了两眼。

阿行发的是一份清单。过去一段时间，它累计做了这些事：

• 拉取并扫描了工单系统里 6486 条历史记录，逐条核对状态；
• 发现 112 条指派给人的工单，停滞超过 5 天没人动——它把清单整理好，发消息提醒了负责人；
• 处理了 17 条"当前无工程抓手"的异常记录——分诊时确认过、当前没有修复抓手的，它自动归了档；
• 累计产出了 285 批异常分析，每一批都带根因和证据。

数据口径：285 指 2026-05-16 至 07-28 期间 case-analysis 中累计生成的分析批次，一批可能包含多个异常，不等于 285 个 case；6486 是一次巡检扫描的历史工单总数；112 是其中“已指派给人且超过 5 天未推进”的记录，5 天是巡检告警阈值；17 是分诊后暂时没有可执行工程修复项、转入可复查观察清单的记录，并非永久忽略。

老张盯着这份清单，喝了口茶。

让他不安的不是数字本身。让他不安的是——这些事，过去从来没有人持续、系统地做完过。

不是团队偷懒。是这些事一直淹没在"重要但不紧急"的角落里，永远排不到优先级前面。新功能要上、线上故障要救、客户要响应——谁有空去清理积压的工单、去分析每一个历史异常？它们就那么躺在系统里，像冰箱深处那盒没人记得什么时候放进去的酸奶。

而现在，一个 AI，在不打扰任何人的情况下，把它们全做了。相较于依赖临时轮值和个人记忆，它更适合稳定执行已经定义清楚的巡检流程；但它仍然受模型能力、上下文质量、工具状态和权限配置影响。

老张放下茶杯，心里冒出一个让他自己都有点意外的念头：

"如果它能长期稳定地做这些事，而且越干越好——那我们这帮人，到底还干什么？"

这不是"AI 要不要用"的问题

老张把这个念头压了下去。他是技术 TL，不是科幻小说读者，他知道"AI 取代人"这种话术太廉价。

但那个周二早上之后，他开始留意一些以前没注意的事。

他发现，团队里最让他头疼的，从来不是"代码写得不够快"。代码写得慢，可以加人、可以加班、可以等。让他头疼的，是另外一些事——一些人扛不住、但又必须有人扛的事。

比如，线上系统每天都会产生异常 case。每个 case 都需要有人去排查：是规则错了？是数据脏了？还是某个边界场景没覆盖？这些 case 不会自己消失，它们积压着，隔一段时间有人看一眼，看不过来就关掉，假装没看见。质量改进只能靠"哪天出了大事故，集中冲刺一波"。

比如，工单系统里总有几十条工单，静静地躺在那里，没人推进。不是忘了，是被更紧急的事挤出了注意力。人不是不会做，是会忘。

比如，团队用 AI 做工单分诊后，系统里多出了一些"当前无工程抓手"的记录——分诊 AI 排查完发现，规则、代码、数据都查过了，没有可修复的工程缺陷。这些记录如果不清理，会污染整个工单池，让真正需要处理的问题被淹没。

这些事有个共同特征：重要，但不紧急；高频，但低单次价值。 它们恰恰是人类注意力最不擅长的领域。

老张慢慢意识到，那个周二早上的"不对劲"，其实指向一个他之前没认真想过的问题：

当 AI 已经能像一个队员一样，每天稳定地处理掉那些"人扛不住的事"——团队该怎么重新分工？

这个问题，比"AI 能不能写代码"难多了。

三个真问题

过去两年，所有人都在谈"AI 能不能写代码""AI 能不能取代程序员"。老张也看过不少这类文章。但当阿行真的像一个队员一样开始每天产出之后，老张发现，棘手的根本不是这些。

棘手的，是 AI 自动干活之后必然会到来的连锁反应——它们几乎没有被认真讨论过。老张把它们整理成三个问题，这也是这一系列文章要回答的：

问题一：为什么必须让 AI 干这些活？ 那些事人扛不住，这老张知道。但让 AI 干的真正价值到底是什么——是更快，还是别的什么？如果只是为了"提效"，为什么团队反而更焦虑了？

问题二：AI 干完之后，人 Review 不过来怎么办？ 老张见过阿行一晚上分析完一整个 staging 部署的代码变更——上千行 diff，几十个文件。让人逐行看？那是另一种崩溃。老张的团队试过，最后 review 变成了走过场。

问题三：谁来管控 AI 之后的整个流程？ 阿行能创建工单、能给人发消息、能自己判断把工单转给谁。老张一开始觉得挺省心，直到有一天他突然想："等等，它刚才是不是自己关了一条工单？谁允许它关的？"

这三个问题，老张花了几个月才想明白。他想明白的过程，就是这一系列八篇文章。

这一系列不讲什么

在正式开始之前，老张想先划几条边界，避免期待错位。

这不是"AI 编程真香"的软文。 不会花篇幅论证"AI 让效率提升 X 倍"。效率提升是前提，不是结论——要讨论的是效率提升之后，团队和人怎么不崩。

这也不是技术教程。 你不会在这里看到具体的 prompt 怎么写、某个自动化脚本怎么配。

这更不是"AI 取代人"的预言。 恰恰相反。当老张把那三个月的经历走完，他发现了一个反直觉的事实：AI 干掉的，全是那些不该占用人类注意力的事。而真正需要人的部分——工程质量判断、业务正确性取舍、组织决策——一个都没有被拿走。

被改变的，是人做判断的环境：它变得干净了、信息完备了、不再被噪音淹没了。

要讲的，是一种新的协作方式

老张想讲的，是一种他这三个月慢慢摸出来的协作方式。

它的核心可以用一句话概括——这句话他后来反复跟团队讲：

自动化的目标不是减少人的参与，而是把人的参与推迟到真正需要判断的节点。

围绕这句话，这一系列会展开八篇：

• 第 2 篇正面回答"为什么让 AI 干"——用三个"人扛不住"的崩溃点说明，这不是效率问题，是注意力问题。
• 第 3 篇正面回答"Review 不过来怎么办"——老张团队怎么用 AI 来 review AI 的产出。
• 第 4 篇正面回答"谁来管控"——以及那条老张后来奉为铁律的规则。
• 第 5 篇回到协作的物理基础——怎么让人不用搭环境就能验收 AI 的活。
• 第 6 篇讲质量保证——一次差点出事的经历，让老张重新定义了"完成"。
• 第 7 篇讲持续进化——为什么 AI 会越用越好，以及这件事为什么不是自动发生的。
• 第 8 篇收束全系列，谈人在 AI 时代的不可替代性。

回到那个周二早上

文章最后，让我们回到老张那个周二早上。

那天他看完阿行的清单，想了很久，最后做了一件事——他没有把阿行关掉，也没有放任不管。他开始想：怎么让阿行做该做的事，同时让团队做该做的判断，两者不互相踩脚。

这个"怎么想清楚"的过程，就是接下来七篇要讲的故事。

而在老张想清楚的所有事情里，有一条他后来最常跟人提起。那不是关于 AI 多强、也不是关于人多重要，而是关于那条消息最末尾、那四个数字之后的一句话。

阿行在那份清单的最后写了一句："本轮还有 2 条工单需要人工关注，原因如下……"

老张后来才意识到，这句话才是整个故事里最重要的部分——不是 AI 做了多少，而是它把做不了的部分，干干净净地交回给了人。当然，阿行并不是天生就知道边界的——这个"处理不了就显式上报"的规则，是老张后来吃了亏才补上的（那是第 4 篇的故事）。但当他回看这条消息时，他看到的正是一套成熟协作方式的样子。

这是我们理解的、AI 与人协作最该有的样子。

接下来的七篇，我们慢慢拆开讲。

一句话结论

自动化的目标不是减少人的参与，而是把人的参与推迟到真正需要判断的节点。