技术供应商说，算法当然听数据的。

蒋晓慧问：“顾客说‘算了’，你们准备把它标成什么？”

项目经理停了一下：“可以结合上下文做意图识别。”

“她可能嫌步骤麻烦，可能不想再量，也可能已经发现没有合适的。还有人是不想把大腿围发给客服。”蒋晓慧说，“都叫流失，下一步完全不一样。”

供应商带来的方案很完整：接历史订单和退货，导入客服对话，用已有围度、照片和浏览行为训练，再由系统直接给出商品与尺码。演示页上的顾客轮廓发着蓝光，旁边跳出“深弧L，推荐置信度92%”。

“九十二怎么来的？”我问。

项目经理解释了模型会综合多个特征。解释到第三层，页面上的顾客已经听不懂了。

“她如果大腿紧，能知道哪道答案导致推荐吗？”

“模型可以后续优化。”

“她能改吗？”

“可以联系客服。”

蒋晓慧笑了一声：“最后还是来找客服。”

我们没有当场否掉技术，也没有把“真实的人胜过算法”写在墙上。人工一样会记错，会受当天订单量和培训影响，还会把熟悉的顾客强行归到常见路径。工具如果能把重复询问整理好，客服可以把时间留给真正模糊的情况。

问题是它要看多少东西，错了以后谁能发现。

数据会重新从目的开始。我们需要的是帮助顾客判断某一款商品是否可能合适，不是预测她全部消费偏好。与这个目的无关的姓名、手机号、地址、婚育、收入和完整浏览轨迹不接入；身体照片不作为使用工具的门票，体重也不因为系统喜欢数字重新加回来。

历史客服聊天不能整库交给供应商“清洗”。里面有订单、家庭地址片段、工作单位和顾客随口说出的健康情况，许多内容只为当时售后而提供。我们只选用途和授权范围清楚的案例，先由内部去掉不必要的身份信息，再把判断问题做成编号测试集。供应商开发环境拿到的是虚构与经过筛选的数据，不是一个可以搜索顾客名字的后台。

秦舒把委托处理条款逐项念给双方：处理目的、期限、方式、信息种类、保护措施、人员权限、日志、返还或删除、是否允许转委托。项目经理原本说他们使用统一云服务，分包商名单要等技术确认。

“确认完再接。”我说。

工具上线前，见己单独做了影响评估。谁会受影响、错荐可能带来什么、系统是否会推高本不需要的收集、退出后资料怎么处理，都要有人签字。评估不是塞进合同附件就结束；模型用途、数据种类或供应商发生变化，必须重新走一遍，不能拿第一次勾选的同意包住以后所有升级。