44,614名顾客的实验：AI客服让销售涨了16.3%

你的下一个AI项目，可能始于一条没人回复的销售咨询。或者一份花了两天才做出来的报价单。又或者一位专家整个上午都在找资料，而不是在用资料。

这些场景都不会告诉你该买哪个模型。它们告诉你的是：该去查哪里。这就是“启动一个AI项目”和“找到一个值得动手的业务理由”之间的差别。

如果一家组织正在考虑上AI，在讨论工具、智能体或招人之前，更该先问一句：哪些有用的工作正在被拖延、被重复、或者干脆没人做——如果把它改好了，会有什么变化？

2025年10月发布的一篇工作论文，考察了一家大型国际电商平台的七个随机实验。研究者在真实的业务工作流里测试了AI干预。这些是分别针对不同基线做的独立比较，收益不能相加，也不代表公司整体收入的增长。

但差异本身才是有用的部分。把AI塞进一个工作流，并不会自动让这个工作流更值钱。基线很重要。

最大那个数字背后的细节

客服实验涉及44,614名顾客。一组在购买前可以使用生成式AI客服，对照组收到的是一条脚本化消息，告知客服不可用。相对于这个对照，AI辅助组的销售额提升了16.3%。

这不意味着AI比一支优秀的人工客服团队强了16.3%。它意味着“提供帮助”胜过了“有效帮助不可得”的体验。业务机会不是简单地“用AI替换客服”，而是：别再让顾客得不到回答。

你的组织可能有另一处缺口。重点是在围绕它动手之前，先把它找出来。

三个值得先查的地方

以下是调查的起点，不是“每家企业都需要一套定制AI系统”的主张。

• 顾客在等的地方：需要人工查资料才能回答的产品问题、等信息才能给出的报价、服务时间之外进来的咨询、找不到合适商品的顾客、对已有信息的重复询问。第一个干预可以是基于来源的助手，或一个报价准备工具。目标不是“回复更多消息”，而是帮顾客准确地走好下一步。
• 专家在拼信息的地方：找几份文档、抽取重复字段、比对版本、还原案例历史、起草标准回复、核对适用哪条政策。有用的系统可以先把材料准备好供人审阅，这和替人做最终专业判断是两回事。检验标准是：专家验证输出的速度，能不能快过自己从头做一遍？如果检查系统等于把活重干一遍，这个系统还没挣到它的位置。
• 增长堆出队列的地方：卖得多了，请求、例外、交接、内部提问都会变多。队列在变长值得查，但不自动等于AI机会。原因可能是信息缺失、责任不清、软件系统割裂、一条本来用常规自动化就能解决的规则，或者一个确实很难的解释任务。不同原因需要不同干预，正确的建议可能是AI，也可能只是一张更好的表单或一次直截了当的系统集成。

一个像样的首个AI项目长什么样

设想一家经销商，销售团队手工准备报价单。产品规格在一个文件里，价格在另一个文件里，库存需要确认。客户发来询价，团队花时间拼答案。这是一个假设的例子，不是已报告的客户项目。

一个有边界的第一版可以是这样：客户询价，抽取所需品项、数量和单位，识别缺失或含糊的细节，检索已批准的产品信息，按明确的业务规则计算，生成报价草稿，由销售员审核批准。

注意这个系统不需要做什么：不独立定价、不编造交期、不批准折扣、不发出有约束力的报价、不接入所有数据库、不充当一个自主的销售部门。最初的问题要小得多：这个做法能不能帮销售员用更少的力气，准备出一份正确、可复核的报价单？这是可以测试的问题。

衡量工作，而不是衡量演示

一个报价生成器可以在几秒内产出草稿，同时照样浪费时间：也许选错了产品，也许单位不一致，也许销售员必须逐句对照原始文件核验。评估时要算“总时间”——准备、等待、检查、纠错都算进去，而不只是生成那一下。验收标准要在看最终结果之前就定好。

至于数据，不必先修完整个公司的数据。对报价这个例子，先找出这项任务具体需要哪些信息：产品标识、已批准的规格、价格及其生效日期、单位、相关销售条件、库存信息的来源与状态。这和发动一场全公司数据变革不是一回事，也不是说数据差就可以不管。实际要问的是：这项有边界任务所需的信息，是否足够可靠、可获取、且被授权用于拟议用途？如果不是，这就成了前期工作的一部分。模型不该被要求靠猜来弥补缺失的商业事实。

什么时候该建议先等等

不是每个需求都该变成开发项目。出现这些情况时，定制开发该暂停：预期结果仍不清楚；所需信息不可得或未获授权；没人能评估输出；复核成本吃掉了预期收益；工作量太小，撑不起维护；更简单的方案能达到同样效果；拟议的自主程度超出组织能安全监管的范围。

“先别建这个”可以是一条有价值的建议。它能防止一次成功的演示，变成一项昂贵的运营负担。

在承诺实施之前，五个问题该有清楚答案：什么结果重要？先查哪个工作流或能力？它需要哪些信息和权限？最小的有用干预是什么？什么证据能证明值得继续？结果应该是一个决定，而不只是一张技术采购清单。这个决定可能是：先改流程、先准备特定数据集、用现成工具、做一个聚焦的概念验证、跑一次有限试点，或者停下来以后再议。

你不需要带着架构图来。你不需要先知道该用智能体、检索系统还是预测模型。你需要的是一个业务目标，以及足够的上下文去调查它。技术应该跟着问题走，而不是反过来。