不担心 AI 写错代码，担心的是人看不过来

老张在阿行到岗之前，对"用 AI 提效"这件事，有一个很朴素的想象。

他觉得，AI 就像一个打字特别快的实习生——以前一个工程师一天写 200 行代码，现在加上 AI，能写 500 行。效率提升了，团队就能干更多活。皆大欢喜。

这个想象在阿行到岗的第一周就太简单了。

碎掉的方式不是"AI 写错了代码"——老张本来就有心理准备，AI 会犯错，人 review 就行。真正让老张意识到事情不对的，是另外三件事。三件和"写代码"毫无关系、却让他意识到问题的事。

第一件事：那些永远没人看的 case

老张的产品是一个业务系统，每天处理大量订单。系统跑着跑着，难免会有异常——某笔订单走错了流程、某个审批卡在了不该卡的环节。

这些异常，行业内叫"case"。

老张知道这些 case 的存在。每隔一段时间，他会让人去翻一翻最近的异常，挑几个看看。但每次翻完，他的心情都很复杂——积压的 case 比想象中多得多，而且每一个都需要花时间去排查：是规则配错了？是数据有问题？还是某个边界场景？

他试过让团队里的人兼职分析。"每周挤出半天看看 case"，他是这么安排的。

结果是这半天永远挤不出来。一旦有线上故障、有客户紧急需求、有新功能要赶 deadline——最先被挤掉的，永远是这件"没有 deadline 的事"。

老张后来想明白了一件事：不是团队不努力，是这件事在人类的注意力排序里，永远排不上号。 它重要，但从不紧急。它高频，但每一次单独看都很小。它是那种"知道该做，但永远没空做"的事。

直到阿行来了。

阿行每天凌晨按计划跑一轮，分析新产生的异常 case，写出根因和建议。从 2026-05-16 到 07-28，它累计产出了 285 批分析；这里的一“批”是一次分析产物，可能包含多个异常，不等于 285 个 case。每一批都带着"这个 case 是因为 X 规则触发了 Y 条件，但实际属于 Z 场景"这样的结论。

老张有一天翻了翻这些分析，愣了一下。这些 case 里藏着好几个真实的产品改进方向——但它们在系统里躺了几个月，从来没有一个人系统地看过。

不是没人想看。是人扛不住这种"高频、低单次价值、需要持续性"的工作。人会累、会被打断、会把注意力让给更紧急的事。按计划运行的 Agent 更适合稳定执行这类已定义流程，但仍需要监控它的模型输出、工具状态和任务失败。

老张第一次意识到：让 AI 干这件事的价值，不是"更快"，是"不会积压"。

第二件事：那条躺了 5 天的工单

如果说 case 积压是"显性的忽视"，那工单停滞就是"更难被及时发现"。

有一天，阿行的巡检报告里列出了 112 条停滞超过 5 天的工单。老张扫了一眼清单，看到其中一条——他想起来了，这条工单三周前就指派给了团队里的小张。他当时还问过小张一句"那个事处理得怎么样了"，小张说"在弄"。

三周过去了，那条工单的状态，还是"进行中"。

老张没有怪小张。他知道小张这三周在干什么——第一周赶一个客户要的功能，第二周处理一次线上故障，第三周请了两天假。那条工单不是被故意忽视，是被挤出了注意力。

人会忘。这不是态度问题，是认知的物理限制。人的工作记忆容量有限，注意力会被紧急事项不断抢占。一条"已经在那躺了三天的工单"永远不会触发人的紧迫感——因为它没变，它就那么静静地躺着，像一滴水慢慢渗进墙里，等你发现的时候，墙已经潮了一大片。

最讽刺的对照是：阿行对"AI 自己卡住的工单"，判定阈值是 24 小时——一个 AI 处理的工单如果 24 小时没动静，它就进入处理或转派队列。而人的工单使用 5 天作为巡检告警阈值；这不代表此前没人看见，只代表达到 5 天后系统会主动把它提到负责人面前。

老张以前试过很多办法解决这个问题——每周开站会过工单、设个人专门催进度、在群里 @ 人提醒。这些办法都失败了，因为它们都在消耗另一种稀缺资源（人的注意力和开会时间）来弥补第一种稀缺资源的不足。

而阿行的做法很简单：每天扫一遍，把停滞超期的工单整理成清单，只发一条消息给负责人。负责人看完，决定推进哪几条就行。

老张第二次意识到：AI 的真正价值，是它把"需要人判断的信息，从噪音里过滤出来，把少数需要判断的工单直接提醒给负责人"。 它不替你决策，它替你记得。

第三件事：那 17 条"当前没法修"的记录

第三件事最微妙，也最能说明问题。

阿行的巡检报告里，有一个数字让老张困惑了一阵——自动归档了 17 条"当前无工程抓手"的异常记录。

老张一开始以为是系统误判，去查了一下。结果发现，这些记录本身是真实的异常，但分诊 AI 排查之后，给出的结论是：规则没问题、代码没问题、数据没问题，这次出错的根因暂未定位——规则、代码、数据都查过了，没找到可复现的工程缺陷，当前没有可修复的抓手。

换句话说：这些 case 是真的，但你没法通过改代码或改规则来防止它再次发生。

这让老张有点不舒服。他的工程师本能是"每个 bug 都要修"。但现在面对的是一类暂未定位根因的异常——规则查过了、代码查过了、数据查过了，没找到可复现的工程缺陷。你没法修，因为你不知道该修哪里。

那这些 case 该怎么处理？

如果让它们留在工单队列里，它们会一直挂着——既没人能处理（因为没抓手），又占据看板位置、污染工作量统计。让工程师逐条复核"这条到底还有没有修的可能"，是对人注意力的纯粹浪费——因为分诊 AI 已经做过一遍同样的复核了。

阿行的处理方式是：把这些"当前无抓手"的 case 归档到一个专门的清单里。归档不代表忽视——它们会被统计，用来观察这类偏差的频率和趋势，是后续系统优化的输入。但它们不占用研发当下的注意力。当然，归档这个动作本身不是完全自动的——分诊 AI 给出归因结论后，这类记录会进入一个可复查的队列，老张可以随时抽查"这条真的没有工程抓手了吗"。归档也不是不可逆的：如果后续发现了新的线索，任何一条都可以重新打开。

老张第三次意识到：AI 时代的问题，不能用"每个 bug 都要修"的老思维来管。 有些问题当前没有工程解，让 AI 把"可修的"和"不可修的"分开，把不可修的归档——这本身就是一种价值。

三个崩溃点的共性

老张把这三件事放在一起想，发现了一个共性。

这三件事——case 积压、工单停滞、无抓手 case 归档——它们的共同特征是：

重要，但不紧急。高频，但低单次价值。有套路，但需要持续性。

它们恰恰是人类注意力最不擅长的领域。人的注意力是为"低频、高价值、需要深度判断"的事设计的——架构决策、业务取舍、复杂调试。让人的注意力长期浸泡在"高频低价值的机械核查"里，不仅浪费，而且会反过来磨损人做高价值判断的能力。

所以，"为什么必须让 AI 干这些活"的真正答案，不是"AI 更快"：

AI 接管的是那些不该占用人类注意力的工作。把这些工作交出去，不是为了让人闲下来，而是为了保护人最稀缺的能力——做高价值判断的能力。

老张把这个结论告诉团队的时候，有个年轻工程师问了一句："那是不是说，我们的活儿变少了？"

老张摇摇头。"不是变少了。是变了。以前你们大部分时间花在执行上。以后得多花时间判断哪些问题值得改。机械步骤和待办数量会减少，但判断的责任不会少。"

年轻工程师似懂非懂。但老张已经隐隐感觉到，这句话背后藏着一个更大的麻烦——一个他还没准备好面对的麻烦。

那个麻烦和"代码"有关。

一个新的麻烦浮出水面

老张后来回忆，真正让他下定决心把这套协作方式系统化起来的，不是上面这三件事。而是一次 code review。

那次，团队的一个工程师用 AI 辅助写了一个功能，提交了代码。老张打开 diff，准备 review。

他往下翻。翻了一页。又翻了一页。

那个 diff 有上千行，几十个文件。

老张坐在那，看着那个滚不到底的代码变更，突然明白了一个新问题：AI 让代码产得更快了，但人的 review 能力没有相应提升。 瓶颈瞬间从"写不出来"转移到了"看不过来"。

他试着认真看，但看了没多久就意识到——这种规模的 diff，逐行看根本看不过来。他要么硬看然后漏掉问题，要么走马观花点个 Approve。

那天晚上老张想：这种 review，等于没 review。它给了虚假的安全感。

而更可怕的是——如果团队为了 review 得过来，开始限制 AI 产代码的速度……那引入 AI 提效的意义不就没了吗？

当 AI 一晚上产出上千行代码变更，人，怎么 review 得过来？

这个问题，老张花了很长时间才找到答案。答案出乎意料地简单，却又出乎意料地反直觉——让 AI 来 review AI 的产出。

这是第 3 篇的故事。

一句话结论

让 AI 接管 case 分析、工单核查、无抓手记录归档这些事，不是为了"提效"，而是把它们从人的注意力里清走——保护人最稀缺的能力：做高价值判断。