写在前面

前阵子做得最多的事情，就是跟业务侧一个部门接一个部门地聊需求。
这是 AI 办公室成立后，绕不开的第一步——你得先搞清楚，大家真正痛在哪里。
这个过程中有一次沟通，内容不复杂，但它特别典型。典型到我觉得可以拿出来和大家分享一下，不是为了证明谁对谁错，而是想还原一下当时我思考的过程。
因为它背后折射的问题，我相信很多正在推 AI 落地的朋友都会遇到：业务提了一个需求，你要不要照着做？

01 一张被嫌弃的表格

那天跟客户服务团队聊，他们掏出了一个云文档的表格。
这张表是用来做什么的呢？简单说，他们跟一个超级大客户之间有时效承诺——报过来的故障，x小时内处理完；整条链路又拆成了好几个环节，各有一个时间约束，例如：客服环节2小时，依次往下。
这张表的核心功能，是监控那些已经超时的工单。
然后他们提了一个诉求——
"这张表每天要花大半天去维护，一天至少两次。我们想把这个人力省出来，去做更有价值的事。"
坦白说，这是一个很常见的表述。听上去很合理，逻辑也通顺：人在做重复劳动 → 让AI或自动化来替代 → 人力释放。
原文配图 1
如果是以前的我，可能真的就会顺着这个思路往下走了。但现在我会停一下。

02 我的第一个追问：这张表，只是用来"监控超时"的吗？

我没有马上讨论怎么优化这张表，而是问了一个看起来有点跑题的问题：
"这张表除了监控时效达成，还发生过什么事情？"
他们想了想，给我举了一个例子——
有一台车，同一个故障，一个月内被报修了三四次。每一次都在时效内正常处理了，所以数据层面看不出任何异常。但没有人把这几次串起来看，没有人意识到这台车可能有更深层的问题。
后来，这台车出了事故。很严重，整台车报废了。
事后追责时，每个人都说："我的环节时效没问题啊。"
你看，这就是我停下来的原因。
这张表，它的价值并不只是"超时监控"。它本应该具备的另一层能力——风险洞察——被忽略了。而团队自己也没有意识到，他们只看到了"维护这张表好累"。
我并不是说他们的痛点不真实。维护确实辛苦，这一点没有问题。但如果我们只盯着"让维护变轻松"这件事，可能会错过更本质的东西。
原文配图 2

03 我的第二个追问：2小时，是一个"正确"的基准吗？

接下来，我把目光转向了时效本身。
"客服环节的承诺是2小时，那客服服务一个单，真的需要2小时吗？"
大家沉默了一会儿。
我换了个说法："如果一个客服处理一个单需要2小时，那意味着他一天只能处理4个单？"
原文配图 3
其实真实情况可能是这样的？
客服处理一个单大概需要10分钟，但中间这个单可能挂在那里观察，耗了一个多小时。然后流转到调度，又停了一段时间。最终留给一线工程师的响应窗口，反而被压得很短。
而现在的预警逻辑是——超过2小时才触发告警。
那其实已经是"事后"了。
我当时的想法是：如果我们知道客服正常处理一个单只需要10分钟，那到了20分钟还没流转，是不是就应该有人介入了？为什么非要等到2小时？
原文配图 4
这不是批评谁，而是我觉得我们目前缺少一个"正常基准"的概念。 没有正常基准，就没办法定义什么是"异常"，也就没办法做到真正意义上的主动干预。

04 不是每个人都能马上接受这种思路

坦白讲，当我把这些问题抛出来的时候，现场反应是分化的。
有同事理解了——他们意识到，之前一直在"表"的层面打转，确实没有退后一步去看全局。
但也有同事直接说："我现在就想解决这个问题，你跟我讲那么多顶层设计的东西干嘛？"
我完全理解他。他是一线做客户服务的，每天被考核、被追问、被客户催，他就想快速把眼前这件事搞定。
我当时跟他说了一个不太恰当但很直觉的比喻：
你现在有点像牙痛，想赶紧吃颗布洛芬止一止。这完全可以理解。但如果这颗牙已经蛀了，布洛芬能解一时，过两天可能还是会痛的。
他没有马上被说服，这很正常。我从来不指望一次沟通就能对齐所有人的认知。 但至少，这颗种子留在那里了。后续的验证和数据会帮助大家慢慢形成共识。
原文配图 5

05 退后一步，我看到了什么

复盘这次沟通，我看到的核心其实是三件事：
第一，缺少全链路的服务过程观测。
故障从报入到关闭，每个节点停了多久、卡在哪里、是否有异常聚集——目前没有人看得到全貌。大家只能看到自己负责的那一段。
第二，缺少基于正常基准的预警机制。
现在的逻辑是"超时了我去追"，而不是"快异常了我提前介入"。前者是被动的，后者才是主动的。
第三，也是最根本的——需要从客户视角出发去思考。
对客户来说，他要的其实就两件事：你快速响应我的故障，以及你帮我发现我自己都没注意到的风险。他并不关心你内部有没有一张Excel表。
而且这套逻辑也不只是解决一家客户的问题。只是因为某客户体量大、时效要求严格，问题暴露得更明显。但其他客户大概率也面临类似的困境，只是还没有被显性化。
最终我们当然会解决表的问题，但如果只停留在“省人力”，就永远抓不住核心。需求必须站在客户的视角去审视，因为一切服务的终极目标都是为了NDR

06 我们打算怎么做

最终我们达成了一个共识：先不急着写需求、开系统。
原文配图 6
第一步，明确基准。每个环节正常到底需要多少时间？不拍脑袋，拿真实数据去跑。
第二步，设计一个全链路观测的原型。从报入到关闭，每个节点的停留和流转，都能被看到。
第三步，做Demo验证。把分析结果摆出来，大家一起看——这个数据长什么样，再决定往下怎么走。
就像我们之前做工程质检的验证一样，先有感觉、先心里有数，再决定要不要投入资源做正式开发。

写在最后

这件事给我一个很深的感受——
在 AI 落地的过程中，最容易踩的坑，不是技术选型的问题，而是需求理解的问题。
原文配图 7
业务同事提出的诉求，痛点通常是真实的，但他们给出的解法，往往是基于自己视角能想到的最直觉的方案。这并不是说他们不专业——每个人都会下意识地从自己的认知半径出发。
我们的价值，恰恰在于能退后一步，帮他们看看，痛的地方到底是"表面的淤青"，还是"里面的骨折"。
顺着表象做，可能做得又快又漂亮，但三个月后他可能带着新的问题再来找你——因为根因还在那里。
这不是谁的错，只是一个需要被看见的盲区。
而看见它，就是 AI 解决方案这个角色最重要的起点。

如果你也是在AI时代的浪潮里，不想听那些“颠覆未来”的空话，只想看怎么解决眼前的具体问题；
欢迎关注我的公众号【林万劲的AI思考】。我不发新闻，不追热点，只写那些我亲手验证过的真思考，和帮业务扒开表象找到的“真问题”
路很难走，但方向是对的，有些坑我踩过了，希望你们能绕着走。