ARTICLE · 1314916
流程里的“看情况”,AI 学得会吗?
多数 AI 项目不是被模型卡住的，是被一句看情况卡住的。流程图交出去，会上讲得很清楚；走到某一格，经办人一句“这个得看情况”，项目就停在那一格不动了。
这篇给一套拆法：把一个看情况拆成能写进规则的三问，剩下拆不动的那部分，也有它该去的地方。
按四步走：先分清哪些判断画得出来，再把画不出来的拆开，然后给例外找主人，最后让规则改得动、有人管。
一、AI 学的不是流程，是判断
这一节先统一口径：AI 接手的到底是什么。
流程图上有框、有箭头、有条件分支，这部分交给 AI 不难。 难的是图上没画的那一句看情况。
波士顿咨询有个判断被反复引用：AI 的价值里，算法只占一成，人和流程占七成。那七成里，很大一块就是这些从来没被写下来的判断。
一个环节里的两类判断
◆ 画得出来的条件清楚，能直接写成规则➤● 看情况的靠经验，得先拆开才写得下
误 区
把现有流程图直接当需求交出去。图上没有的那一句，才是成本与风险真正待的地方。
二、把看情况拆成三问，经验才拿得出来
难点在于：经验在人嘴里，怎么落到纸上。
拆一个看情况的三问
▲看什么
这个判断依据的是哪几条信息
■分几种
常见情况能归成几类
○谁说了算
每一类由谁定，换个人结论一样吗
三问答完，一句看情况会变成一张几行的分类表。表填得出来，这个环节才谈得上交出去。
场 景
有客户做供应商资料初审，经办人一开始只有一句“资料齐不齐我看着办”。 三问拆完变成四类情况、每类对应不同处理，新人照表也能判。
误 区
三问问一次就归档。问出来的分类表要跟着业务改，不然三个月后又是新的看情况。
三、剩下的例外，别假装没有
换个角度看：三问拆完，总有一块拆不动。
拆不动的那部分不要藏。它要单独列成一张例外清单，写清谁接手、多久给结论、结论回写到哪里。
AI 落地最怕的不是有例外，是例外没写进交付物。
逐 条 问
例外清单逐条问
▢这一条现在谁接手，点得出名字吗
▢接手后多久给结论，当天还是三天
▢结论回写到哪里，下次遇到同样的能查到吗
▢例外越堆越多时，谁负责回头看
误 区
把例外当成没做好的证据。例外是流程的边界，标出来才算划清。
四、规则要写成文件，和技术分得开
这一步决定以后谁改得起规则。
规则如果埋在提示词里、写在脚本里，改一次就得等技术排期。改规则不该是一张技术工单。
盛迈斯交付时把场景规则库单独成册，和操作指引放在一起。业务自己改得了的那部分才叫规则；只能由技术改的，那叫配置。
场 景
有客户的判定阈值每月调一次。规则成册之后由业务负责人自己改，改动记一笔日期和原因，三个月后回头查得到当初为什么这样定。
五、规则会过期，要有主人和周期
剩下的问题更实际：这条规则能活多久。
上线那天准的规则，三个月后不一定准。
规则从采集到复盘的四步
★ 采集把经验拆成三问➤◇ 成册规则独立成文件➤✦ 定人每条规则点得出主人▷ 复盘按月看例外堆在哪运营管理这一段按月要做的，主要就是最后一步：看例外往哪一类堆，堆得多就说明那条规则该补了。
规则没有主人，就等于没有规则。
六、盛迈斯进场，先找那个能说清看情况的人
方法讲完了，说我们自己怎么进场。
盛迈斯做咨询规划这一段，我们第一件事不是看系统，是找那个能说清看情况的人。 找不对人，后面拆出来的只是流程图的复述。
我们交付的四件套里，场景规则库和验收标准一起交。原因很实在：验收时能对得上的东西是规则，不是演示效果。
客户数据怎么用，我们写进合同里：脱敏之后才用于复用，原始数据不出客户域。
规则写不下来的地方，就还是人在扛。
判断这件事最后都要落到某个人身上。把看情况拆开、写下来、交到一个点得出名字的人手上，AI 才从会跑变成能用——模型还是那个模型，变的是这个组织终于说清楚了自己是怎么做决定的。
让 AI 在企业真正跑起来！
盛迈斯 SunMize · AI 落地交付 · 按场景跑通结果 ｜ 官网 www.sunmize.com
