今年我们为制造企业做了两次 AI 落地，起点完全不同，最后得到的教训却是一样的。

第一家是一家面料制造商，大约有 1,000 人，125,000+ 个 SKU，积累了几十年的 PDF、电子表格和扫描文档，产品目录放在 Algolia 上。

没人说得清哪一版文档才是当前版本。我们就拿这样的数据原样搭了个助手，跑了三周试点。结果准确率不到 60%。

这事可以有两种解读：要么是「AI 在我们这儿不管用」，要么是「试点恰恰帮我们找出了卡点在哪」。我们属于后者。错误集中出现在四个方面：

  • 多个来源互相冲突，却都给出看似笃定、实则错误的答案
  • 扫描版 PDF 一直没能正确解析，悄无声息地从检索结果里掉了出去
  • 未建索引的商品页面，这直接导致 SKU 搜索失效
  • 来源选择不稳定，同一个问题明天再问，得到的答案却不一样

这些都不需要更聪明的模型。我们改的是：

在源头就把重复和过时的文件清掉，而不是每次查询时再去纠正它们

  • 上下文窗口提升到 128k
  • 每次回答会检索更多来源，并做交叉核对，而不是直接采信第一个匹配结果
  • 调低了温度

准确率从不到 60% 提升到了大约 90%。在网上，大家总把这件事说成是选哪个 LLM 的大决策。但在企业里，问题往往出在一份老 PDF 上，以及从来没人就哪个系统才是权威数据源达成过一致。

第二个案例是一家汽车滤清器厂商，大约 700 人，系统跑在 NetSuite 上。他们的 CEO 没等供应商，自己通过 MCP 把 Claude 接到了 NetSuite 上，自己写了提示词，到周末结束时就已经做出了一个能用的订单状态助手。它确实能用。但每回答一个问题也要花 4–6 分钟。

别把这种成果当成一文不值，也别以为它已经能直接铺开用。它两头都不是。它是一个免费的需求信号：真问题、数据够得着、场景可行、零投入。要把它变成整个支持团队都能用的东西，就得按阶段重建：

  1. 订单状态，包括那些难缠的边缘情况（缺货补货、只给你一个零件编号的人）
  2. 知识库放在最上层，靠增量同步保持更新
  3. Shopify
  4. 邮件和 Zendesk

最后阶段的取消订单和改单，比前面任何一个环节都更耗时，这一点我要提醒在座所有人注意。“我的订单到哪了”和“取消我的订单”感觉像是同一个集成，但在信任层面，两者差得远。