见过一个不算罕见的场景：团队花了两周把接口调通，模型回答得像模像样，演示时掌声不错。真正要上线前，却卡在一张表上——答案错了由谁发现，发现了记在谁头上。表格在几个人之间转了一圈，项目就停在演示阶段。没人吵架，只是谁也不愿意先签。
难的那一环常常不在模型
讨论人工智能落地，注意力容易集中在参数量、推理速度、要不要微调这些地方。它们当然重要，但系统一旦进入真实业务，最先暴露的往往是流程本身没写清楚：同一条规则有三种例外，例外由谁判断，只存在老员工的脑子里。把模糊的输入喂进去，输出的不稳定几乎是必然的。这不是模型退步，而是原本靠默契维持的那部分被显性化了。
换个角度看，这算好消息。它逼着团队把“我们到底在做什么判断”写成文字：依据哪几条信息，什么时候必须停下来问人，问谁。写不出来的地方，通常就是还不该交给机器的地方。
几个可以先自问的条件
我不太相信“先易后难”这种笼统的说法，但有几个具体条件值得在动手前过一遍：
- 结果能不能被使用者快速核验，一眼看出对错；
- 出错之后，影响范围是否可控，能不能回滚；
- 责任归属是否需要跨部门反复解释，如果需要，说明规则本身还没定型。
第三条最容易被忽略。技术团队觉得这是管理问题，业务团队觉得这是技术问题，于是它悬在中间，直到上线前夜才变成那张没人签的表。
“我不确定”是一条需要设计的出口
模型有个倾向：倾向于给出完整、流畅、语气笃定的答案，哪怕依据并不充分。使用者很难从字面上分辨哪句是推断、哪句是硬凑。所以在产品里留一条“这一点我不确定，建议人工确认”的出口，往往比再提升一点准确率更能减少麻烦。它不漂亮，但诚实。
我倾向于认为，承认不确定反而会提高使用者的核对意愿。一个从不犹豫的助手，人会慢慢停止思考；一个会说“这里我拿不准”的助手，人会多看一眼。这种信任的建立方式，和人际之间其实差不多。
人的位置挪了，但没有消失
流程改造之后，人的工作常常从“做”变成“定标准、看例外、处理卡住的那些”。这类工作更琐碎，也更难考核，短期内不容易被看见。如果组织只按处理量来衡量，很快就没人愿意干这部分，系统也会在例外上一点点失去校准。
所以下一次讨论要不要上人工智能，我会先问一句：这个流程，我们能用一段话讲清楚吗？讲不清楚，先在纸上把它讲清楚，可能比换一版模型更省时间。