表演 AI，还是 AI-Native
一个 AI 项目上线以后，有没有哪个决定真正交给了系统，是区分表演和 AI-Native 最简单的办法。
这两年我看过不少企业的 AI 项目清单，长的五六十项，短的也有十来项。看得多了，我慢慢习惯用一个问题去过这些清单：上线以后，有没有哪个原来由人做的决定，改成由系统来做了？
决定可以很小，比如今天先见哪个客户，这封邮件转给谁处理，这张单子要不要再核一遍。只要有一个决定改由系统先拿出答案，这个项目就算是真的用上了 AI。一个都没有的话，模型再大、界面再漂亮，也还是在表演。这样过一遍，能留下来的项目通常不多。
同一个功能，两种做法
药企里有个很常见的功能叫 NBA（Next Best Action，下一步最佳行动），由系统告诉医药代表，接下来最该去见哪位医生、见了谈什么。
不止一家公司是这样做的：建议放在 CRM 客户页面的侧边栏里，代表想看就看。上线头一个月还有人好奇点开，后来点的人越来越少。没人照着做，也就没有结果可以回头核对，这些建议到底准不准，谁也说不清。项目最后不了了之。
我自己做产品时试了另一种做法。每周的拜访计划由系统先排好，代表可以改，但改的时候要选一个原因。经理不用再一份份审核计划，只看被改动的部分。这样一来，照着执行的建议有结果可查，被改掉的建议带着原因，系统错在哪里看得比较清楚。经理的时间也从看报表挪到了处理例外上。
两种做法完全可以用同一个模型、同一份数据，差别只在拜访计划的第一稿由谁来出。
常见的几种表演
一个决定都没交给系统的项目，比较常见的有四种。
一种是 POC 一个接一个地做。一年做二十个，每个都在汇报会上演示过，反响也都不错，但很少有哪个在业务里用满三个月。一个 POC 结束，接着再立下一个。
也有的是给老系统换个名字。在原有系统上加一个对话框，改叫“智能某某”，流程和数据都没怎么变。
还有的是在流程末尾加一步。前面的环节一个没动，最后多出一步“AI 生成总结”。有没有这一步，前面的人都照原样干活。
再就是只让 AI 检索，不让它总结。法务担心 AI 说错话，规定它只能返回原文片段。这样一来，大模型能起的作用和搜索引擎差不多。
为什么会这样
这很难怪到具体哪个人头上，是几件事凑在一起，把大家推到了这一步。
首先是考核。立项的好处当年就能兑现，预算批下来，创新案例报上去，年终总结也有东西可写。业务结果却要一两年才看得出来，到那时项目负责人多半已经换了岗位。在这样的考核下，多立项、快出演示是很自然的反应。
然后是签字。决定交给系统，出了错总得有人担责任，业务、IT、法务各有各的顾虑，谁都不太愿意担。没人签字，AI 给的东西就只能当参考。
数据也是个坎。真正有价值的用例要用公司自己的数据，而且要干净、打通、细到每个客户。多数公司的数据还没到这个程度，只好先做用不上自家数据的东西，比如通用的问答、写作和翻译工具。这些工具值得用，只是竞争对手也能买到一样的，很难拉开差距。
AI-Native 是什么意思
AI-Native 这个词现在用得很多，每个人说的意思不太一样。我用这个词的时候，指的是流程在设计时就假定判断是便宜的。
老流程假定判断很贵，所以会把决定集中起来，一个季度做一次，交给少数几个人。按 AI-Native 的思路设计，一个决定先由系统给出答案，人负责改掉不对的、处理特殊情况。节奏也跟着变，原来一个季度做一次的事，可以每周都做。衡量效果的方式也要换，省了多少小时、多少人在用都是次要的，要看照着系统的答案做了以后，业务指标有没有变好。系统做过的每个决定都有记录，错了能撤回，也能查到当初是谁批准它这么做的。
这些变化里，最关键的是第一个，默认答案由系统来给。其余几个，多半是有了它之后自然要跟上的。
从一个决定开始
所以起步的时候，可以先挑一个具体的决定，模型和平台放到后面再选。
比较合适的决定，一般一周要做几十上百次，次数多了才能积累足够的反馈；做决定需要的信息已经在系统里，而且大体可信；做错了也能改回来。
怎么挑，我在《很多 AI 项目死在选题上》里整理过一套方法。挑好以后，更难的是让组织敢放手，这部分写在《AI 的决策权是挣来的》里。
