设计一个真能验证出结论的 14 天 AI 试点
多数 AI 试点失败，并不是因为技术不达标，而是因为没有人事先就「什么算成功」达成一致。一个以「各执一词」收场的试点，成本和一个以「作出决策」收场的试点完全一样。本文讲的就是如何为后一种结果做设计。
发布于
选一条旅程，而不是一个部门
「把客服自动化」不是一个试点，那是一个预算科目。「在 WhatsApp 上用中文和英语端到端解决订单状态问题，包含查询动作」才是一个试点。它有起点、有终点、有记录系统，也有毫不含糊的完成定义。
旅程划得越窄，分歧暴露得越快——而让分歧在第一周就浮出水面，正是做试点的全部意义。
选一个真正有流量的渠道
在流量已经存在的地方做试点。在多数面向消费者的企业里，那是 WhatsApp；在 B2B 是官网；在房地产是电话。在低流量渠道上做试点，只会得到一个漂亮的结果和零证据。
十四天内必须积累足够多的对话，数字才有意义。如果选定的渠道供不上这个量，那就先换渠道，而不是先换供应商。
选定一项主指标，并把阈值写下来
一个数字，上线前达成一致，且门槛白纸黑字：「40% 的订单状态对话无需人工即可解决」，或者「同样的来访量带来多 30% 的有效会议预约」。
次要指标可以收集，但用来做决策很危险。一旦两个指标给出相反结论，试点复盘就会变成一场谈判——而事后挑出来的那个数字，永远是好看的那个。
这十四天
第 0–3 天是共同设计：人格设定、知识来源、系统连接，以及书面的成功标准。在标准达成一致之前不动手开发，因为复盘正是按这份文档来打分的。
第 4–14 天是在您选定的部署姿态下上线——共享云、VPC、自托管或沙特境内——在真实渠道上面向真实客户、使用真实数据运行。用合成流量做的试点，只能证明演示跑通了。
第 15 天起进入度量期。在度量窗口内务必忍住，不要改提示词、不要改范围、不要改指标；任何中途变更，都会让您失去当初做这个试点想要得到的那个对照结论。
在上线前埋好度量，而不是事后补
提前确定以下每一项如何采集，因为到第 12 天再补，得出的数字没人信：
- 自助闭环率：无人工介入即结束的对话，需与被客户中途放弃的对话区分开。
- 升级质量：人工收到了什么，以及他们是否还得重新问一遍。
- 写回成功率：尝试执行的动作数，对比真正提交到记录系统的动作数。
- 延迟：首次响应时间，以及端到端的解决时长。
- 语言分布：各语言的量与成效，需分开统计。
- 客户信号：对话结束后的一道问题，用客户自己的语言提问。
开始之前就定好决策规则
把三种结果写下来并让项目发起人签字：达到或超过阈值，就推进到第二条旅程；在约定的容差范围内，就优化后再跑两周；低于阈值，就停止。
「停止」必须是一个真实存在的选项，并且在第 0 周就公开讲明。一个不可能失败的试点不是试点——那是多加了几道工序的采购流程，在场每个人都心知肚明。
对照文档来开复盘会
到第 30 天，先翻开第 0 天写下的成功标准并逐条朗读，然后再看任何仪表盘。对照、决策，并把决策及其理由记录在案。
接着选定第二条旅程。第二个试点比第一个便宜得多——连接、人格与部署姿态都已经就位——而这种复利效应，才是这十四天真正的回报。