项目卡住的地方，往往不在模型
我们复盘过的项目里，真正卡住的很少是模型能力不足。更常见的情况是：需求方说要“用 AI 提升运营效率”，供方回一份通用方案，双方都点头，三个月后没人再打开。问题出在最开始——没有人把“提升效率”翻译成“哪个岗位、在什么时间、面对哪份材料、做哪几步判断、输出给谁”。场景没写清楚，后面所有的技术选择都只能靠猜。
旅游企业的业务看起来零散，其实很具体：计调排线、门店接咨询、票务处理退改、客服回口碑、市场写推文。这些动作每天重复，也都有相对固定的做法。
把场景写成“岗位 + 动作 + 输入输出”
具体做法并不复杂：挑一个岗位，跟着他过完整的一天，从上班到下班逐步记录。凡是重复出现、有固定套路、需要查资料或写文字的动作，都单独记一行。记完之后再合并同类项，通常一天下来会得到十几行，合并后剩下三到六件真正常做的事。
对每一行动作，先问三个问题：输入是什么、输出是什么、做完交给谁。比如“处理客人退改申请”可以写成：输入是订单号与客人诉求，输出是处理意见与回复话术，交给门店店长确认。写不出输入输出的动作，说明内部还没想清楚，先不要进入选型环节。
失败案例几乎都始于“想做 AI”，成功案例都始于“这个岗位每天重复做的三件事”。
三个筛子：频次、耗时、判断难度
写完动作清单，用三个维度筛一遍，三个都过才进第一批。我们的经验是，一个部门第一次真正能落地的场景通常不超过三个；列出来十几个的，往往是自己也没想明白。
- 频次：每天或每周都会发生的排前面，一年两三次的往后放。低频场景收集案例慢、调优更慢，做出来也难形成习惯。
- 耗时：单次十分钟以上、且量大的动作才值得做。省三分钟但一天只发生两次的事，投入产出不成比例。
- 判断难度：有明确规则、有参照资料、错了能改的容易做；依赖大量个人经验、出错代价直接落到客人身上的（比如重大投诉定责、大额赔付核算），不该由 AI 单独下结论。
这五类场景，第一年最好别碰
有些场景不是技术做不到，而是前置条件不齐。硬上之后，团队会把“流程没理顺”误判成“AI 不好用”，反而消耗掉后续推进的信任。
- 需要跨部门反复拍板、流程本身还在变的；
- 数据散在个人电脑和微信群里、没有人为准确性负责的；
- 输出要承担法律责任或直接影响赔付金额的；
- 一年只出现一两次、没有历史案例可参照的；
- 需求方自己都说不清“做成什么样才算好”的。
这几类的共同点是需要先补课：要么补流程，要么补数据，要么补责任归属。补完之后再回来做，成本和风险都会低得多。我们也见过华东某 5A 山岳型景区先把票务退改规则统一成一份文档，之后再做问答助手，一次就通过了验收。
一张场景卡，比一份方案有用
场景卡只写五件事：岗位、触发时机、输入材料、期望输出、验收人。控制在一页纸，由岗位本人和主管一起签字确认。这张卡的用处比想象中大——它同时是需求文档、验收标准，也是上线后做效果评测时最直接的题库。
把场景卡填具体了，对外沟通也会变简单：供应商报得出实在的工期，企业也能判断哪家是真的听懂了自己的业务。无论最终用谁的方案，这一步都是先做的。