报价数字不应直接由大模型自由生成。问题不只是偶尔算错，而是生产报价需要同样输入得到同样结果、能解释采用哪版规则、能被财务或销售复算、能在争议时还原现场。大模型天然适合语言理解，确定性引擎更适合金额计算。
把报价链拆成两层
| 环节 | 大模型适合 | 确定性引擎适合 |
|---|---|---|
| 读取邮件/聊天 | 提取客户、产品、数量、交期 | 校验字段格式 |
| 缺项处理 | 生成自然追问 | 判断必填条件是否齐全 |
| 规则选择 | 从候选规则中解释适用原因 | 按条件优先级选定版本 |
| 金额计算 | 解释费用构成 | 查表、公式、舍入、税费、上下限 |
| 输出报价 | 生成客户可读说明 | 固定明细、总价和版本哈希 |
| 异常 | 解释冲突并请求确认 | 拒绝不完整或不合法输入 |
这不是排斥大模型，而是让每种技术做擅长且可负责的部分。
可复算比“看起来合理”重要
每次计算应保存输入快照、规则版本、逐项公式、中间值、舍入方式、币种与汇率来源、税率、折扣批准和最终结果。销售在界面上看到的总价，财务用同一规则重算应得到完全一致的数字。
如果规则依赖“老客户可以酌情优惠”，就要把酌情范围、批准角色和上下限写出来；无法写清的部分进入人工确认，不能藏在模型提示语里。
三种常见错误必须阻断
- 条件缺失：没有数量、地区或交付方式，Agent 不能采用默认值静默算价。
- 规则冲突：客户协议价与促销价同时命中，应按明确优先级裁定或转人工。
- 版本过期：历史报价可以参考关系和格式，但不能自然继承旧汇率、旧成本或旧折扣。
这三类错误即使算术本身完全正确，也会得到错误报价。
人审要看证据，不是只看总价
确认卡应同时展示结构化需求、费用明细、规则依据、异常与存疑项。批准人可以修改业务条件，但金额应由引擎重新计算，不能直接手改总价而不留原因。
完整询价流程见客户询价怎么自动报价；动作批准的风险分层见Agent 人工确认怎么设计。
企业 AI 的可靠性往往来自这种组合：模型负责理解和协调，规则与业务系统负责确定性，关键动作由人确认，写入后再独立回读。需要把现有报价规则重建为可执行服务，可继续了解企业知识中枢和定制开发。
规则引擎不等于写死一堆 if
可维护的计算服务应把条件、公式、数据表、优先级、生效期和批准记录分开管理。业务人员能查看当前规则和模拟结果，技术人员负责执行引擎与系统连接。规则变更形成新版本，旧报价继续指向旧版本，不因今天改价而被重新解释。
对于阶梯价、组合价、一对多费用和最低收费，先把计算拆成可测试的小步骤。每个步骤都有输入输出和边界用例，远比把整张价格表塞进提示语稳定。
模型选择规则也要受约束
大模型可以根据询价描述推荐候选产品或费用规则，但最终命中必须满足确定性条件。若候选之间无法唯一选择，就展示差异并追问。模型置信度高不代表业务条件齐全，也不能替代规则优先级。
异常时保留现场，不自动重算覆盖
当汇率服务超时、价格表版本冲突或审批过期时，任务进入挂起，保存当时输入和已取得证据。恢复后先确认外部数据时点，再决定继续原计算还是创建新版本。直接用最新数据覆盖旧现场，会让客户看到的金额与内部记录无法对应。
用金标准样本验收
从历史已确认报价中选择正常、边界、折扣、税费、币种和异常样本，由业务与财务先算出金标准。引擎不仅要总价一致，还要逐项费用、舍入和版本一致。再加入故意缺字段、重复和冲突的负向用例，验证系统会拒绝而不是补猜。
