一个定价引擎能不能出真价，不取决于算法多先进，取决于数据齐不齐。所以第一件事永远是先量数据覆盖率。
业务流是「订单 → 自动拆单 → 自动报价 → 自动派单」，用 33,176 笔真实订单 / 387 个经销商 / 2,799 个型号 校验：型号 96.6%、厚度 95.2% 可用，但尺寸覆盖 29%、客户匹配 0%。生产侧更严峻：门店订购单系统 400 单里 97% 的 spec 为空（无尺寸），仅 3 单有尺寸且属 K/Y 系列，而主流是 H/H4/K/M/S 五系列。
三个前置数据依赖：出厂价红线（PV / KW / K1 三档）、尺寸数据源、订单↔经销商 ID 对照表——这三样不补齐，任何报价都是猜的。红线：缺数据时报「算不了」，比给一个看起来精确的数字安全得多。延伸：基础 16 讲数据为什么缺，模块 11 讲怎么把它补起来。
市面上谈定价引擎，都在谈算法：规则引擎、组合定价、动态调价、机器学习定价。这些全是第二层问题。
定价这件事的物理顺序是这样的：
需要型号和厚度能对上。这一步靠主数据，不需要算法。
需要尺寸。没有尺寸就算不出面积，算不出面积就算不出价。缺这一步，后面全白搭。
需要出厂价红线（按PV / KW / K1 三档）。没有红线，算法再好也只是把 0 算得更精确。
需要订单↔经销商的 ID 对照。不知道给谁报，价算出来也发不出去。
德莉玛的业务流是这条链：订单 → 自动拆单 → 自动报价 → 自动派单给供应商。整条链想自动化，第一步是拿真实数据验一遍每个环节的输入齐不齐。
校验用的样本：33,176 笔真实订单 / 387 个经销商 / 2,799 个型号。
| 校验项 | 覆盖率 | 结论 |
|---|---|---|
| 型号匹配 | 96.6% | ✅ 可用。主数据基本立得住 |
| 厚度匹配 | 95.2% | ✅ 可用。同样站得住 |
| 尺寸数据 | 29% | 🔴 瓶颈——算不出面积就算不出价 |
| 客户 / 经销商对应 | 0% | 🔴 阻塞——不知道给谁报 |
只看历史订单不够，还得看现在实际在跑的生产系统。查门店订购单系统的数据画像：
样本：门店订购单400 单 spec 字段为空（无尺寸）： 97% → 388 单 spec 有尺寸： 3 单 → 且这3 单属 K / Y 系列 实际主流系列： H / H4 / K / M / S 五系列
把上面的校验结果翻译成动作，就是三件事。它们不是「后续优化项」，是硬卡点。
| # | 缺什么 | 为什么是硬卡点 | 谁来补 |
|---|---|---|---|
| ① | 出厂价红线（按 PV / KW / K1 三档） | 没有红线就没有「底价」概念。低于红线接单=亏本，高于红线接单=丢单。引擎算得再准，也得有个准 | 客户方定价/财务口径，乙方不能替客户定 |
| ② | 尺寸数据源 | 尺寸覆盖率 29%、生产侧 97% 无尺寸。这是最大的一块缺口，也是工作量最大的一块 | 要么客户补录历史数据，要么从图纸/BOM 侧反解，要么改流程强制录入 |
| ③ | 订单↔经销商 ID 对照表 | 覆盖率 0%，意味着订单数据里根本没有可靠的客户标识。报给谁都不确定 | 客户主数据/ERP 侧，乙方无权威来源 |
不要承诺「一套系统全自动」，要承诺「一个可交付的分级能力」。这张表是写给客户看的，也是我给自己定验收线的。
| 等级 | 能力 | 依赖 | 现在能不能做 |
|---|---|---|---|
| L1 | 型号 / 厚度自动匹配 | 主数据（已具备：96.6% / 95.2%） | ✅ 可做。覆盖 95%+，这是现在唯一能全自动点亮的格子 |
| L2 | 规格补全与人工确认 | 部分尺寸 + 确认流程 | ⚠️ 半自动。引擎推荐，人工点确认。29% 的覆盖率决定了它只能做人机协同 |
| L3 | 自动报价 | ① 价格红线 + ② 完整尺寸 | ❌ 目前不具备条件。红线未定义、尺寸仅 29%，两个硬依赖都不在位 |
| L4 | 自动派单供应商 | L3 | ❌ 点不亮。依赖 L3，而 L3本身还点不亮 |
L2 不是一个技术选择，是一次岗位演进。真实业务里的演进路径是：
判断一个系统「到底能不能干某件事」，最可靠的方法不是读文档，也不是看日志——是拿真实参数去反向打它的接口。文档可能过期，日志可能漏打，接口返回不会骗人。
做法是：拿真实订单里的 model（型号）+ spec（规格）当输入，反向打三个接口，看引擎到底能算出什么。以下为示意输出：
# ① 查 BOM：用型号 + 厚度反查结构与用料
POST /api/bom
{ "model": "H-系列 型号", "thickness": "8", "spec": "..." }
# 响应：能不能给出完整结构？结构齐不齐？
{ "ok": true, "items": [ ... ], "matched": true } ← 型号对得上
# ② 查玻璃图纸：拿 spec 里的尺寸去试
POST /api/glass_dwg
{ "model": "H-系列 型号", "spec": "1600*2400" }
# 响应：尺寸能不能解析成面积？
{ "ok": false, "reason": "spec 缺失或不可解析" } ← 尺寸缺失即止步
# ③ 试算报价
POST /api/quote
{ "model": "H-系列 型号", "spec": "1600*2400", "dealer_id": "..." }
# 响应：dealer_id 传不进去，报价请求根本构造不出来
{ "ok": false, "reason": "dealer_id 无法解析" } ← 0% 对应的卡点在这里
/api/bom 走得通（型号厚度覆盖率 95%+ 的直接体现），/api/glass_dwg 卡在尺寸（29% 覆盖率的直接体现），/api/quote 卡在 dealer_id（0% 覆盖率的直接体现）。三个接口的卡点位置，和覆盖率表完全对得上——这才叫验证。从真实订单里随机抽 N 条，model 和 spec 全部用原值。造数据会绕过掉真正的数据问题
成功 / 参数非法 / 无数据。要记录失败原因分类，不只记成功失败
接口卡点位置必须能解释覆盖率表。如果接口跑得通但覆盖率是 29%，说明两边用的不是同一套数据
反向验证只用只读/ 查询接口。不触发写库、不触发任务下发——生产系统的变更必须先在预览环境验证
能力边界讲得好，是专业；讲得含糊，是埋雷。这张表可以直接拿去做沟通。
| 四问 | 可以这么答 |
|---|---|
| 能承诺什么 | 型号/厚度自动匹配（覆盖 95%+）；规格推荐 + 人工确认的技术确认岗流程；数据覆盖率报表与持续补录机制 |
| 不能承诺什么 | 现阶段不能承诺全自动报价、不能承诺自动派单。原因：价格红线未定、尺寸数据仅 29% 可用 |
| 需要客户提供什么 | ① 出厂价红线（PV / KW / K1 三档）② 尺寸数据源（历史补录 + 新单强制录入）③ 订单↔经销商 ID 对照表 |
| 上线后的期望值 | L1 全自动跑通；L2 人工确认环节的例外率逐月下降（用覆盖率提升来衡量，不用「准确率 99%」这种没定义的口径） |
关于报价自动化的说明：
我们用3万多笔真实订单（387 个经销商、2,799 个型号）做了完整校验。结果是：型号和厚度的自动匹配可以做到 96.6% 和 95.2%，这部分能直接上线。
但报价本身有两个硬前提目前不满足：一是尺寸数据覆盖率只有 29%，算不出面积就算不出价；二是订单与经销商的对应关系目前是 0%，系统不知道这个单该报给谁。此外价格红线（PV / KW / K1 三档）需要贵司财务口径确认。
所以我们建议先跑数据治理阶段：把尺寸和经销商 ID 补齐、补录历史数据、把新单录入流程改掉。数据覆盖率达标后再上自动报价，那时报价准确率是由数据保证的，而不是由模型保证的。
以现有数据直接上全自动报价，看起来会很准，但那个精度是算出来的假象——这对我们双方都不是好结果。
| 坑 | 为什么危险 | 正确做法 |
|---|---|---|
| 拿少量样本说覆盖率高 | 400 单里仅 3 单有尺寸，拿这3 单当证据是自欺；且这 3 单属 K / Y，还不是主流的 H / H4 / K / M / S 系列 | 覆盖率必须全量算，并说明样本的口径（哪年、哪个系统、哪些系列） |
| 为了签单模糊能力边界 | 前期模糊 = 后期验收扯皮 + 回款难收 | 能力分级写进合同附件，L3/L4 明确标注「依赖数据条件」 |
| 用「AI 智能定价」这种模糊词 | 用技术名词掩盖数据缺失，客户以为问题在算法，其实问题在数据 | 不用模糊词。每说一个能力，同时给出它的数据前提和覆盖率 |
| 客户期待 100% 自动化 | 29% 的尺寸缺口决定了 100% 不可能，承诺了就是埋雷 | 提前对齐「例外率」这个指标，用覆盖率提升曲线代替「全自动化」承诺 |
| 把「算不出」当成失败 | 为了显得有用，引擎对缺失尺寸强行给一个默认值 | 缺数据就返回「缺尺寸、待确认」，这是正确行为，不是失败 |
| 信文档和日志不做反向验证 | 文档可能过期、日志可能漏打，会高估引擎能力 | 拿真实 model + spec 打接口，卡点要和覆盖率对得上 |
| 在生产环境试探接口 | 可能触发生成任务、下发单据，代价远超验证本身 | 验证只用只读接口，变更先在预览环境做 |
/api/bom、/api/glass_dwg、/api/quote 三个接口我的判断标准是：不先看功能，先量数据覆盖率。因为绝大多数「系统不能上线」的真实原因，不是功能没做完，是输入数据不完整——这时候功能越完善，产出越像真的，越危险。
举个我真实做过的例子。业务流是「订单 → 自动拆单 → 自动报价 → 自动派单给供应商」，要自动化得先验数据。我用 33,176 笔真实订单 / 387 个经销商 / 2,799 个型号 跑覆盖率校验，结果是：型号匹配 96.6%、厚度匹配 95.2%，这两个说明主数据是立得住的；但尺寸数据只有 29%，算不出面积就算不出价；客户/经销商对应是 0%，系统根本不知道该报给谁。
我又去看生产侧的真实数据画像，结果更扎眼：门店订购单 400 单里97% 的 spec 是空的，也就是 388 单没有尺寸。仅有的 3 单有尺寸，还属 K / Y 系列，而主流业务是 H / H4 / K / M / S 五系列——连有尺寸的样本都不在主要业务线上。
所以我的结论是：缺三样前置数据——① 出厂价红线（按 PV / KW / K1 三档）② 尺寸数据源 ③ 订单↔经销商 ID 对照表。这三样不补齐，任何报价都是猜的。而且前两样里有两样根本不在我手里，得客户给财务口径和主数据。所以我把方案改成先跑数据治理阶段，自动报价等数据齐了再上——这避免了客户花大价钱买到一个算不出价的引擎。
然后我把引擎能力分了四级，并且明确说清哪一格现在点不亮：L1 型号厚度自动匹配能上线（覆盖 95%+）；L2 规格补全 + 人工确认只能半自动，需要设「技术确认岗」承接 29% 的缺口；L3 自动报价目前不具备条件；L4 自动派单依赖 L3，所以也点不亮。这里有个岗位演进的关键设计：真实业务里是从拆单员演进到技术确认岗——自动化不是消灭人，是把人从重复计算挪到例外处理。29% 的缺口意味着 71% 仍要人确认，那就明确设这个岗承接，而不是让引擎硬算一个数字。
验证能力边界的方法，我信的是反向验证而不是文档。拿真实订单里的 model + spec 去打 /api/bom、/api/glass_dwg、/api/quote 三个接口：bom 走得通、glass_dwg 卡在尺寸缺失、quote 卡在 dealer_id 传不进去——三个接口的卡点位置和覆盖率表完全对得上，这才叫验证。这里我也坚持一条纪律：验证只用只读接口，不在生产环境试探，变更先在预览环境做。
最后是这件事里我认为最值钱的部分：这个项目的数据匮乏（400 单 97% 没有尺寸）反而是最好的诚实性证据。我完全可以拿那 3 单有尺寸的订单说「尺寸数据我们有一部分」，然后接下全自动报价的单子——但那3 单属 K / Y，不在主流系列上，样本根本不成立。反过来说，我把这个坏消息如实写进方案，客户看到的是一份真的做过校验的方案，而不是一份销售话术。
所以我给自己定了一条红线：在数据不足时仍然输出一个看起来精确的数字，比报「算不了」更危险。因为那个假精确值会进入客户的报价单、进入真实交易，等被发现时损失的不是这一单的钱，是「这套系统不可信」这个结论。信任丢了，引擎做得再准也没人敢用。