Odoo + AI 落地三种形态：订单识别、智能客服、数据分析助手

很多团队谈 AI 落地，喜欢从“模型能不能做”这个问题开始。但真正决定成败的，往往不是模型能力，而是另一句话：这一步错了，会怎样？

按“错了会怎样”分类，企业里的 AI 应用大致可以分成三类：

• 一类错了立刻赔钱，比如订单录入、库存变更、价格计算；
• 一类错了顶多白答一句，比如客服话术、内部问答；
• 一类错了只是数字难看，比如报表口径、趋势分析。

这三类场景对准确率、人工介入、可追溯性的要求完全不同，落到 Odoo 这类 ERP 系统上，做法也根本不是一回事。本文以订单识别、智能客服、数据分析助手三种形态为例，拆解从“能用”到“敢用”的工程化落地路径。

一、订单识别：把“读懂”和“建单”拆成两段

订单识别是最典型、也最容易踩坑的场景。客户发来 PDF 或扫描件，里面有客户名、料号、数量、单价、交期、备注。传统做法是人对着 PDF 一条条抄进 Odoo，抄完再核对一遍，怕抄错。几十封单子堆到下午，中间还得接催单电话。

1.1 最常见的错误做法：端到端直接建单

最直觉的方案是：让模型读完 PDF，直接调用接口创建销售订单。听起来很顺，但它把“理解”和“写账”绑在了一起——模型理解错了，错误就直接落进了账里，而且往往是不可逆的。

一个真实案例：某工厂第一版就是这么做的。上线第三天，一份客户发来的改单（在原单基础上改了两个数量，邮件正文写着“以此版为准”）被模型当成新订单，系统多建了一张单，仓库照着拣了两箱货。追回来花了半天，客户还问了一句“你们怎么发两次”。

问题不在于模型笨，而在于设计把错误的代价放大了。

1.2 正确的拆法：抽取与建单分离

稳妥的做法是拆成两段：

第一段只做抽取，输出结构化 JSON。

抽取字段建议包括：

{
  "customer_name": "客户名称",
  "po_number": "对方单号",
  "lines": [
    {
      "sku": "料号",
      "qty": 20,
      "unit": "箱",
      "delivery_date": "2025-01-15"
    }
  ],
  "remark": "备注",
  "confidence": {
    "customer_name": 0.97,
    "lines[0].qty": 0.62
  }
}

这里有一条硬规矩：价格不许模型给。

单价应当按“客户 + 料号”去价格表查询，查不到就留空并标红。让模型去认价格，等于让它猜你的商业条款，猜错的代价比省下的时间大得多。

第二段是人工确认，不是全自动。

抽取结果先落到一张中间表，界面左边是原始 PDF，右边是解析出来的表单，字段级标出置信度，低于阈值的标黄。人的工作从“抄”变成“核”，一封单从三分钟压到二十秒，但最后还是由人来按确认。

这一步看着“不够智能”，恰恰是最值钱的地方——它把错误挡在账外，而不是挡在事后。

1.3 几个真踩过的坑

单位口径。 同一份单上“20 箱”和“20 件”混着写，口径不对，库存直接错一个量级。抽取时把单位单独一个字段，和料号的默认单位对不上就强制人工确认。

重复投递。 客户经常“没收到回复，再发一遍”。用附件哈希 + 对方单号做幂等键，重发的邮件识别为同一张单，不再新建。

手写改单。 扫描件上拿笔划掉一行、旁边写个新数量，模型经常把划掉的也算进去。这类件识别成“低置信度整单转人工”，别硬猜。

成本。 一页 PDF 大概一两千 token，一天两百单的量，月度成本是小几百块级别，比一个内勤一小时的工资便宜。这个量级不必纠结用不用得起，该纠结的是准确率够不够。

二、智能客服：按“错了会怎样”分级

智能客服的容错空间比订单识别大得多，但也不能一刀切。建议按错误的代价分层：

• 错了立刻赔钱：涉及报价、承诺交期、退款政策。这类问题必须走规则引擎或人工，不能让模型自由发挥。
• 错了顶多白答一句：常见问题、操作指引、物流查询。这类可以放心交给模型，配合检索增强，答案附上来源链接。
• 错了只是数字难看：内部知识问答、话术推荐。这类可以作为辅助工具，人工可改可弃。

落到 Odoo 上，智能客服的典型形态是：

1. 用户在聊天窗口提问；
2. 系统先在知识库和 Odoo 业务数据中检索；
3. 模型基于检索结果生成回答，并附带引用来源；
4. 涉及价格、库存、交期等敏感字段时，直接调用 Odoo 接口返回实时数据，而不是让模型“回忆”；
5. 回答置信度低或涉及承诺类问题时，自动转人工。

关键原则是：模型负责组织语言，系统负责提供事实。

三、数据分析助手：可追溯、可验证

数据分析助手的容错空间最大，因为它不直接改账，但它的风险在于“看起来对，其实错”。一个错误的趋势判断，可能导致备货决策失误。

3.1 让模型写查询，而不是写答案

比较稳妥的做法是：用户用自然语言提问，模型生成查询语句或指标口径，由系统执行后返回结果。模型不直接给数字，数字来自数据库。

例如用户问“上个月哪个料号出货最多”，模型生成一段聚合查询，系统执行，返回结果表格。模型再基于结果生成一句解释。

3.2 口径必须显式定义

“出货量”是按数量还是按金额？“上个月”是按自然月还是按发货日期？这些口径必须提前定义好，作为指标字典的一部分，模型只能引用，不能自己发明。

3.3 保留审计轨迹

每次问答都记录：原始问题、生成的查询、执行时间、返回结果、模型解释。这样出错时能回溯，也能持续优化指标字典。

四、三种形态的对比

形态	错误代价	是否自动写账	人工介入	核心设计
订单识别	立刻赔钱	否，先落中间表	必须确认	抽取与建单分离
智能客服	多为白答一句	否	低置信度转人工	检索 + 实时接口
数据分析	数字难看	否	可选	模型写查询，系统给数

五、落地建议

1. 先分类，再选型。 不要用一个方案套所有场景。按“错了会怎样”把需求分成三类，分别设计。
2. 能查就别猜。 价格、库存、交期这类事实性数据，一律走接口查询，不要让模型生成。
3. 中间表是朋友。 任何要写入业务系统的 AI 结果，先落中间表，人工确认后再入账。
4. 置信度要可见。 字段级置信度、低置信度高亮、整单转人工，这些机制比模型本身更重要。
5. 成本不用太纠结。 在订单识别这类场景，月度成本通常远低于人力成本，真正该关注的是准确率和错误拦截率。

AI 在 Odoo 里的落地，不是把模型塞进流程，而是重新设计流程，让模型做它擅长的事，让系统做它该做的事，让人守在错误代价最高的地方。三种形态，三种做法，核心都是同一个问题：这一步错了，会怎样？