让 AI 报价但不让 AI 定价：印刷订单计价系统的一条分工线

背景

印刷订单的报价是一件看起来简单、实际上极难自动化的事。

一张订单上写着书名、数量、开本、成品尺寸、印张、装订方式，还有一段自由填写的备注——「封面覆哑膜加烫金」「勒口 80mm」「配光盘一张」。这些要素组合起来，对应到印刷厂的报价表里，可能是十几条规则的叠加。

报价员靠经验完成这个映射。经验的问题是：新人上手慢、不同人报出的价不一致、报价表更新后老规则还在被沿用。

客户希望把这件事系统化。首批样本是两家教材出版社，目标是把同一套架构扩展到约 100 家印刷企业与出版社。

问题

订单格式不统一。 一家的规则文件是 Excel、订单是可提取文本的 PDF；另一家的规则文件是 Word、订单既有 PDF 也有图片。

规则本身是自然语言。 报价表里写的是「内文 80g 双胶，5000 册以内每印张 X 元，超出部分 Y 元」，不是可执行的表达式。

备注是不能忽略的。 订单里的备注、附加说明、非标要求经常直接决定价格，但它们是自由文本，格式各异。

术语对不上。 订单上写「蒙肯纸」，报价表里写「轻型纸」，ERP 里又是另一个编码。同一种纸在三个系统里三个名字。

原有方式为什么不行

两条常见路线都走不通。

纯规则路线——把报价表翻译成代码。问题是每接一家企业就要重写一遍规则，100 家就是 100 套代码，且规则一变就要改代码上线。

纯模型路线——把订单和报价表一起丢给大模型，让它直接算价格。问题更严重：算出来的数字无法回溯。客户对账时问「这个 3860 元是怎么来的」，系统答不出「用了哪条规则、哪个数量档位、哪几项工艺加价」。而印刷这个行业，报价错了是要真金白银赔的。

关键约束

• 价格必须可解释、可验证、可审计——每个数字都要能回溯到具体规则
• 不允许按单一企业建模——统一结构必须同时覆盖两家样本企业才算成立
• 订单必须先拆分再计价——不允许针对原始订单格式直接做企业级价格计算
• 备注必须进入正式处理链路——不能只作为文本附件保留
• 多租户数据隔离

做法

一、职责切开：模型负责理解，规则引擎负责定价

这是整个系统的核心设计。

模型可以做的：

• 阅读并理解订单、备注、报价表规则
• 对缺失字段做合理推测
• 对规则无法直接匹配的情况提出候选路径
• 对最终结果做专业复核

系统必须保证的：

• 模型的结论要结构化落地，不能只是一段话
• 模型输出必须附带理由、证据、置信度
• 最终价格不能只来自模型一句话
• 人工可以查看、确认、修改、覆盖

一句话概括这条设计线：模型应该像一个有经验的报价员那样工作，但系统不能是黑盒。

二、统一拆分大表：企业差异只体现在计价策略

所有订单先落到同一套标准结构——整书主表 + 部件表 + 工艺表。一本书可以拆成正文、封面、插页、环衬、扉页、护封、腰封、小册子、附件、包装等多个部件，每个部件挂各自的工艺。

企业之间可以有不同的阶梯规则、乘数因子、部件计价方式、工艺加价方式、最低收费规则、另议规则——但不应有不同的订单基础结构定义。

这条约束让第 3 家、第 30 家企业的接入成本，从「重写一套」变成「配一份计价档案」。

三、术语表是唯一桥梁，且精确匹配不做模糊

订单侧、规则侧、ERP 侧三方通过同一张平台术语表对齐：

                   平台术语表（标准名 + 别名 + ERP 编码）
                  /            |             \
          订单侧            ERP 侧            规则侧
        PDF → 解析        标准编码同步      报价表 → AI 提取
             ↓                 ↓                  ↓
          归一化  ══════ 精确匹配 ══════  归一化

关键规则是：精确匹配，匹配不上就不计价并产出警告，不猜。

模糊匹配在这个场景里是危险的——「蒙肯纸」和「轻型纸」也许是一回事，但「128g 铜版」和「128g 哑粉」不是，猜错就是报错价。

四、未知术语的人机闭环

匹配不上的术语不是错误，是待办：

原始值「蒙肯纸」
  → 归一化：未匹配
  → 模型建议：轻型纸（附理由与置信度）
  → 写入待确认队列
  → 界面显示「蒙肯纸 → 轻型纸？ [确认] [修改] [跳过]」
  → 人工确认后写入术语表，下次自动归一

模型提效率，人管正确性，词典随使用增长。 用得越久，需要人工确认的越少。

五、样本价格作为回归基线，而不是规则来源

客户提供的历史订单最终价格，明确定位为验证集而非规则来源。规则改动后跑一遍样本回归，看价格是否仍然对得上。

这个区分很重要：如果把历史价格当规则来源，系统会学会复现历史上的错误报价。

验证方式

• 样本回归：用历史订单验证每次规则改动，价格偏差可量化
• 计价档案版本链：规则改动有版本，可对比、可回滚
• 计算路径留痕：每个价格附带用了哪条规则、哪个档位、哪些加价项

结果

已跑通：

尚未完成：

• 报价精度仍在收敛——引擎乘数、工艺过滤、默认工艺三处仍在调整
• 订单识别目前只支持 PDF，图片、Word、Excel、邮件入口未做
• ERP 只有单向推送，无双向同步
• 任务队列用数据库表轮询，量大时需要替换

经验与边界

这个项目最有价值的一条经验，是那条分工线本身。

在企业 AI 项目里，「让模型端到端做完」几乎总是最省事的方案，也几乎总是过不了生产验收的方案——因为业务系统要的不是一个答案，是一个可以被追问的答案。

真正可落地的分工是：

• 模型负责有歧义的、需要理解的、规则写不全的部分——读懂自由文本备注、把自然语言规则提取成结构、对缺项做推测、提出候选;
• 确定性代码负责有唯一正确答案的部分——最终计算、精确匹配、权限、审计;
• 人负责模型不确定时的裁决，且这个裁决要沉淀下来，让下一次不用再问。

边界：

• 报价精度还没收敛到可交付水平，这是当前的主要风险
• 术语闭环在冷启动阶段人工确认量较大，规模效应要用一段时间才显现
• 「约 100 家企业」是设计目标，目前只在两家样本上验证过统一结构的成立性