前两天跟一个朋友聊了蛮长时间，我之前在他们公司做了一次关于 AI 原生组织的培训，在我印象中，他一直过得很不错啊！
但他这次给我说：公司要黄了、干不下去了！他想出来跟我卖课、做培训，自己再也不想上班了，FDE 这碗饭看着就很好吃……
我很清楚他在卖惨，说实话，我甚至有点害怕他突然开口问我借钱，我以后也一定要多卖惨…
当然这只是他的玩笑话（我相信他应该也不会借钱吧），导火索是前些日子一个大单子，他在一家企业负责推进物流 AI 项目，过去差不多一个月，人已经快被物流业务里面各种例外规则搞懵了。
他希望我们能基于 FDE 的思路来帮他盘一盘，下一步要怎么做。
他现在主要负责在推一个境外物流智能体项目。
简单理解，以前有一批物流运营人员，主要负责处理境外订单履约过程中的各种异常。
一个订单从发货到客户收到，中间可能经过多个国家、多个仓库、多个承运商。一旦出现异常，比如物流长时间没有更新、清关失败、派送异常、客户拒收、包裹丢失，物流运营人员就需要根据国家、线路、承运商、订单金额、客户情况等信息，判断下一步应该怎么处理。
现在他们已经做了一套物流异常处理智能体，可以自动读取订单状态、物流轨迹和业务规则，对部分异常进行识别，并自动执行标准化处理流程。
系统已经开始跑了，也确实已经自动化了一部分工作。
问题是：现在自动化率大概 40%，老板希望年底做到 80% 以上。
但是越往后推越痛苦，业务人员拿到 AI 的结果，会说：这个单子正常规则不适用；我这里特殊情况比较多；这个流程就算从我这过了，下一个节点也会退回来；你不懂我们业务。
聊完我整理了一下，发现这一个项目其实把很多 AI 项目真正进生产以后会遇到的问题都碰了一遍。
总结几个我觉得比较核心的点。
造能力→分责任
我们推项目的时候，第一阶段通常关注的是产品能力建设。
包括我拿到这个问题的时候第一反应也是：是不是技术架构还没有做好？
自动化率上不去，会不会是现在的系统太死，把太多东西写到固定流程里去了，所以只要业务环境稍微变化一点就处理不了了，或者是反过来，把很复杂的逻辑直接让 AI 自己处理，最后遇到模型幻觉、对话生硬、答非所问等问题，又不知道怎么控制。
于是我们开始拆解 SOP。
对于确定性的事情，比如数据获取、异常计算、明确的判断条件，能用公式、规则、算法来解决的，原则上都应该尽可能的沉淀到程序或者 Workflow 里面。
对于不确定性的事情，比如需要结合多项信息做语义判断、上下文理解，可以考虑交给 LLM 节点去分析和生成。
对于无法提前定义路径的，比如出现复杂异常以后，需要多轮查信息、调用工具、重新规划的，再考虑交给 Agent Loop。
也就是我们之前文章讲的：确定性下沉、不确定性上浮。稳定的东西尽量固定下来，把真正需要动态判断的部分留在上面。
这部分大家的实践都挺一致的，而且这个朋友他们项目的核心链路已经跑起来了，说白了很多事情 AI 系统已经可以做了，只是部分特殊场景下业务觉得它做的不对。
如果项目目标只是做一个工具给业务用，已经基本达标了，愿意用的人先用，后面慢慢迭代就行。
但问题是大老板要的目标不只是这个，如果只是提供一个这样的 AI 工具，是很难达成 80% 这种高自动化目标的。
走到这里会发现，瓶颈不在写代码了，我们得回答：
原来人做的这些工作，有多少真要交给系统，人干什么，系统出了问题业务谁来兜底。
老板的 AI 指标
聊到这里我突然问了朋友一个问题：80% 是怎么算的。
我们需要知道最终的目标要怎么算的，以及理论上要满足什么条件才能达成。
在这种高目标要求的项目里面，我觉得至少得先把几个基本条件想清楚：
第一，工具能力得真的能打。
至少对于那些真正愿意提升效率、愿意尝试新方法的业务人员来说，把系统接入业务流必须是帮助大于麻烦的。
如果连最愿意尝试的一批人都觉得系统很难用，那后面也不用聊组织推动了，先回去把产品做好。
第二，业务在过渡阶段一定要投入额外精力。
因为系统不可能一下子变成完美的产品，业务一边要在真实流程里面使用，一边在系统不靠谱的时候还要对业务结果兜底，同时还得愿意把发展的问题讲清楚，和产品、算法一起共创，让产品越来越好用。
这段时间里面，业务的工作量大概率是上升的。
第三，一定会存在无法完全自动化的例外。
但是例外要如何识别出来，是调整管理流程和规则规避这部分人工，还是变成固定的人机交互模式由系统识别出来转人工。
这里涉及到管理机制、人员职责的调整和系统功能的设计。
第四，业务本身还会持续变化。
业务在不断发展，新国家、新线路、新承运商、新业务流程在不断出现，系统和机制要怎么承接。
新的业务算不算在自动化率的分母里面？是否计入指标。
以上这些都共同影响了最终指标能否达成，如果这些东西没有定义，80% 就是拍拍脑袋的口号。
我理解高目标 AI 项目里面，得先把目标-达成条件-推进动作-需要的资源连起来，形成脑子里的一张对应关系图。
因为不同的目标难度，深入组织的深度也是不一样的，需要的资源支撑也是不一样的。
推不下去的时候
朋友自己一开始想了两种推法。
第一种是自下而上，业务说我这里缺一个功能、那个线路有特殊情况，我就给他作为例外写进去，理论上是蛮合理的，
你要什么我都给你做，总有一天应该满足的差不多了吧？
但实际上：“业务提一个需求，我做一个功能”，大概率永远做不完。
尤其这种跨境物流业务，每个国家、线路和承运商都有自己的历史处理方式，例外后面还有例外，而且新规则和老规则还可能互相打架。
他自己也说了：自下而上就是不断给业务做功能，但按这个速度，今年年底很难达到目标。
既然自下而上做不完，那就自上而下。他也提了，可以找管理负责人，从管理上统一规则，以后大家就按这一套来，理论上也没啥问题。
但是现实是：真正干这件事情的业务人员要自己背指标。
时效下降、客户投诉增加、赔付成本上涨，最后都是业务团队的问题。管理部门可以统一流程、统一制度，但是没法一刀切的说：
大家全部按照系统规则来，但是自己承担业务结果
这也是自上而下很难真正推下去的原因。
说白了，真实复杂世界的真实运转情况不是产品和算法做几次调研、拍拍脑袋就能穷举的出来的，最后真出问题还是得由人来对业务结果负责。
对方完全可以问一句：可以按照你的来，那这个指标你来负责吗？
这里的核心是：谁背业务指标，谁天然拥有更强的评价权，那出现例外情况对业务结果的影响判断，就得听谁的。
AI 落地到深水区
进入 AI 项目深水区，不可能避免要改变原来的工作方式，以前业务人员自己判断、自己操作，并对判断和操作的结果负责。
现在系统开始替他执行，后面还想进一步替他把判断的事情做了，这本身就是一次工作方式的变化。
这里面涉及到几个问题，第一个有哪些人愿意推动业务变革、哪些人愿意参与变革、哪些人抗拒变革，第二个是变革对他们的影响是什么，他们的出路在哪里。
常规做法也很清晰，先复习毛选第一章：找出哪些是我们的朋友。
有一批人大概率愿意尝试的，对他们来说参与变革本身就是红利，大概占 20%；有一批大概率天然就是抗拒的，对他们来说凡事变化都是风险。
中间最多的那批人其实没有那么坚定，他们主要看结果，不要给他造成麻烦就行。
这里就是要挑选一部分最愿意配合、业务能力又比较强的人，跟他们一起做业务共建，先用这 20% 形成有效的业务样板，甚至可以由这批业务人员去承接更多场景的判断。
具体的做法可以是这样：
比如 AI 提供的异常处理方案被改了，不能改完就算了，可以由愿意配合的业务骨干和管理部门一起，组建一个小型的评估虚拟团队。对应的业务人员需要说明为什么这么处理，然后再由平台运营、愿意配合的业务骨干和管理代表一起共同判断。
最后判断下来：
- 如果是新的情况，那就补规则。
- 如果是系统问题，就优化系统。
- 如果是个人习惯，那就由管理和其他业务骨干一起给出更权威的业务评价确认。
- 真的没有办法处理的，那就保留人工判断，并逐步让业务骨干承接这部分判断。
不管最后判断该删还是不该删，只要经历了这个评估，这个经验就沉淀下来了，同样的问题就会慢慢收敛，同时，愿意配合的那一部分人也越来越能兜底。
等业务样板跑出来，中间大部分人会开始松动：别人没出大问题、效率确实很高了、新的工作方式公司也认可、愿意转的人有新的位置。
这个时候推动成本就完全不一样了。
但是这是理想状态，实际上一定会面临组织问题，比如项目组不一定能兜住所有例外业务、过渡阶段业务指标可能会有波动、没有办法承诺足够的出路。
所以仅仅改变下面的人也是不够的，组织的关系也会发生变化，我们要考虑业务变革的终局。
改变岗位，想清楚终局
说白了，项目组可以解决产品能打的问题，也可以从下面找人、共建业务结果、推动变化，但如果一个项目真的要把自动化率做到 80%，光靠下面的人推动是不够的。
上面的人得先同步好一件事情：这件事做成以后，业务最终准备怎么运行？
因为终局没有定义清楚，下面所有人都会按照自己的利益做最合理的选择，最后一定会产生内耗。
比如这个物流项目，至少有两种完全不同的终局。
第一种，业务指标和职责继续留在原来的业务部门。
AI 项目组本质上还是一个能力提供方，由系统去负责大部分自动化工作，但最终的业务结果还是由业务部门负责。
如果是这种模式，那业务人员保留比较高的判断权是合理的，因为履约时效、赔付成本这些指标还是由他来背的，你不能要求他相信一个自己不能控制的系统。
相应的，AI 团队要做的事情就是尽量把系统做得足够好，把大量重复执行吃掉，把复杂例外留给人。
业务团队则继续承担业务结果，并处理过渡阶段可能产生的例外和业务指标波动。
第二种，这部分的业务职责准备逐渐转移到项目团队。
未来由系统承担了绝大部分执行，以后可能只需要少数几个业务专家加平台运营就能管理很多场景。这个时候转移的就不只是工作量了。人员判断权、业务指标，甚至部门职责都应该跟着一起调整。
同时，项目团队就要考虑，怎么样去平衡例外业务、中间的指标波动和配合人员的发展方向。
而最麻烦的情况是没有一开始想清楚终局，哐哐开始推动自动化率，然后开始互相指责，一方说另一方阻碍项目进度或者干扰业务运转。
说实话，如果最后连业务团队和指标都准备拿走，那么原来的业务负责人肯定会想：既然以后这件事情都不是我的了，那为什么这个转型过程中的额外成本还要让我来承担？反过来说，如果业务还留在我这儿，那这套系统就必须满足我所有的业务要求。
对，大老板是强制下了指标，大家都知道最终目标是 80% 的数字，但如果项目团队不断的拿走执行和判断权，最终业务指标还是压在原来的业务团队身上，同时还要求业务人员在过渡阶段投入更多时间，还不能影响原来的业务指标。
那我是业务我也会想：凭什么？
其实业务人员很清楚：你们现在做的这个系统，最终就是想把我的工作给干掉。
那我为什么要主动把自己的脑子里面的经验抽出来，费半天劲跟你一起研究怎么干掉我？
从个人利益角度来说，拖得越久反而越安全。最好的结论就是：可以有一部分提效，但是因为行业特殊，人员还是需要的，并且这个结论不能是我下的。
这里不是说一定要完全接管或者完全不管，到了一定阶段，就要由几个老大定义清楚项目的终局，通过终局来反推过渡阶段的策略。
FDE
聊到这里啊，其实我们可以发现，朋友现在做的事情本质上很像一个内部 FDE。
我们平时做 FDE 项目，更多的是从企业外部的角度帮客户去推进。大家基本都要经历几个阶段：
- 先把能力做出来，能力不行就先打磨产品；
- 再去找业务共建，选出最愿意合作的业务人员，跑出样板；
- 再用这个业务样板继续扩大，持续推广；
- 最后进入到终局，实现项目指标。
中间过程中不断的处理过渡阶段的问题和做好产品的打磨，能固定的规则放进系统，不能固定的例外交给人。
内部 AI 团队和外部 FDE 都是这么干的，区别在于当问题继续从技术往组织里面走的时候，侧重和责任不同。
内部 AI 团队需要为业务责任负责。
朋友的这个项目就是，他们直接对数字负责，所以他们的负责人可以跟老板沟通。
甚至极端一点，当部分业务人员提出质疑：这个指标你来负责吗？
如果拿到了相应的权限，他可以基于对业务的基本理解、对一起参与变革业务人员的信心、对老板过渡阶段容忍度的判断，回答一句：可以，按我的来，这部分结果我来负责。
所以当朋友问我：那你建议我跟老板汇报什么？是相关的数据、证据，还是一个方案。
我的回答是：你需要老板的什么资源，就跟老板汇报什么内容。
因为我们肯定要考虑事情做不下去的免责方式，而内部团队本身就在组织里面，就有机会推动这些条件产生。
内部团队不能单纯说：这是业务的问题，业务不配合导致推不下去。
得证明：我们已经进入到某个里程碑了，下一步需要这些资源，我们就能达到下一个里程碑。
而 FDE 团队不太一样。
外部 FDE 也需要看懂组织，但没法承担组织内部的责任转移。
FDE 团队需要承担更多的产品打磨、业务梳理工作，产品和算法团队大概率是要有一段时间驻场和业务人员一起解决产品体验和例外问题。
同时脑子里也要有那张目标指标-达成条件-推进动作-需要的资源的对应关系图，甚至甲方内部应该找哪些人、采用什么共建方式、怎么做样板，都应该要能出建议，推动甲方的负责人去解决对应的资源和组织问题。
但是这里有一个明确的边界：FDE 毕竟是外人，没法对组织内部的责任转移负责。
所以外部 FDE 可以设计方案、推动、沟通、给证据，但最终还是需要甲方内部有人真正去执行这些管理动作，我们讨论的时候有一个很形象的说法：
FDE 可以提供这把刀，但是甲方内部需要有人握住这把刀。
如果甲方内部没人愿意或者有能力握，那外部团队再专业，也解决不了他的内部管理问题，也就达不成高目标的指标要求。
所以 FDE 项目一方面我们一直说的是一把手工程，另一方面也得在项目开始的时候比内部团队更早的把责任边界定义清楚：
项目成功里哪些是 FDE 的责任：比如业务理解、方案设计、核心能力验证、工程化实现，以及授权范围内的业务共建和持续迭代。
哪些是依赖客户提供的条件：比如业务专家投入、业务规则决策、跨部门冲突、过渡阶段指标承担、新的工作方式落地。
这是外部 FDE 要注意的事情：提供目标指标-达成条件-推进动作-需要的资源透明的摆在桌面上，对自己能够控制的结果负责，同时把不可控的依赖条件说清楚。
说白了，这也是一种专业的免责方式。
不过也只是理想情况，该不付尾款还是不付尾款，大部分的 ToB 项目落单和回款还是得靠销售刷脸。
同时，不管是内部 AI 团队还是外部 FDE 团队，项目都要有一个退出机制：当业务骨干能够覆盖剩余例外，新的运行方式能够自己运转，最开始推动项目的人就可以退出去做下一件事了。
结语
回头看这个项目，其实可以用两条线来理解。
第一条线是项目推进的路径：产品能打-业务共建-组织复制。
先让产品能打；再找一批愿意共建的人跑出业务样板；最后复制到更多同类业务上。
第二条线是问题深入的方向：执行-规则-判断-责任。
AI 一开始只是替人去做执行；往后推就必须理解执行背后的规则；规则覆盖不了所有场景，就要有人去判断和兜底；判断权一旦发生了变化，最后又会涉及到谁来承担业务结果，就可能涉及到组织责任的转移。
第一条线解决项目怎么做大，第二条线解释项目怎么做深。而 AI 项目真正进入生产，这两条线是在同时发生的。
不过，也不是所有的 AI 项目都需要走到这么深，如果只是做辅助工具，那做到能力这一层就够了，这也是大部分技术团队落地 AI 项目的舒适区。
本文由作者@叶小钗，授权发布于平台，未经许可禁止转载。