截图下面，顾客只写了三个问号。

她原本问的是：“深弧M还有藏蓝吗？”

系统识别到“深弧”，触发了供应商模板库里的“大码女装关怀话术”。大肚姐妹、藏肉显瘦、梨形救星，被放在同一个标签组里。我们测试时只输入了“怎么选版型”“什么时候发货”，没有覆盖顾客直接说深弧的路径。

“先停自动模块。”蒋晓慧说。

运营担心两千条消息刚清完，全部停会重新堵。我们没有只停“大肚姐妹”四个字。若触发逻辑仍把深弧等同某种身体，换成“亲爱的姐妹”只是把错误藏软一点。

十点零七分，自动欢迎、版型推荐与营销追问全部下线；订单状态等已核的纯事务提醒另行逐项检查，在确认前也改为人工。平均首次回复速度立刻变慢。

第一步不是发公开声明，是找到谁收到过。

系统日志显示，错误模板上线十八小时，触发四十三次。四十三条不等于四十三位顾客，有人重复咨询；也不等于所有人都已读。客服按账号、发送、撤回、阅读和后续人工处理状态核对，不为了数字小把未读删掉。

核完后，四十三次对应三十六个账号。二十九条已读，九条未读，五条状态无法只凭现有界面确认；有人同时触发两种模板。这个数字只用于找受影响范围，不能公开成三十六个人都受到相同程度伤害。内部台账按最小必要信息保存，营销团队只看汇总。

其中一位顾客没有选择深弧。她在消息里说“我不想要深弧”，系统仍抓到关键词发了大肚称呼。所谓识别甚至没有理解否定词。工具供应商解释这是规则匹配的限制，不是智能判断；我们此前却在采购说明里把它叫“智能客服”，默认它会懂上下文。

最初截图的顾客已读。蒋晓慧用人工账号回复：“刚才的自动称呼与推荐错误，把版型选择等同身体标签。是我们的审核问题。已停用相关模块。您问的藏蓝深弧M当前库存为——”

库存事实放在道歉后面，不用优惠券替代。

对方回：“你们不是最反对这些词吗？”

“是。我们仍然用了。”

“机器人用的，又不是你打的。”

“系统由公司选择、配置和上线，不能让工具替公司承担。”

她没有回复原谅，也没有继续下单。

我们逐条联系已确认收到错误模板的人，只说明发生什么、已采取什么、其咨询如何继续处理；不要求提供身体信息，不拿群发“亲爱的用户”再次覆盖。未读且平台允许撤回的记录按系统状态处理，撤回也保留内部日志，不能当没发过。

供应商客服解释，模板库是行业默认内容，商家可自行修改，开通页面已经提示审核。事实证明责任不在单一一方：对方提供了带羞辱性标签的默认方案，我们选择启用，审核人只看了六条示例，我作为最终上线批准人没有要求完整触发测试。

供应商提出免费升级到另一套“女性友好”模板作为补偿。我让他们先给完整文本与规则，不接受只换名称。新库里没有“大肚”，却有“微胖女孩”“腿粗星人”和“身材救星”；表面更温和，仍在替顾客定义身体。

合同里有服务、故障和内容配置条款，具体责任由双方按事实处理。我们保留要求整改、费用与是否续用的权利，却不等合同谈完才停错误功能。顾客当下收到什么，优先于我们和供应商最后谁承担多少费用。