一句话:经销商行业最值钱的是「订单字段是否完整」,不是算法。AI 最容易犯的错,是把「字段缺失」当成「默认值」往下跑,最后算出一个看着像真的错价。
一条流水线跑的是 订单 → BOM → 玻璃图纸 → 报价。项目里真实存在的三件事:
| 项目事实 | 内容 |
|---|---|
| 系统 | 德莉玛淋浴房门店订购单系统 v2.5.0,Express + better-sqlite3,本地端口 8787,pm2 挂进程 |
| 产品线 | 5 大系列:H / H4 / K / M / S。其中只有 H / S / M 配了价格,K 系列要靠 BOM 模板兜底 |
| 数据体检 | 拿 33,176 笔历史订单 / 387 个经销商 / 2,799 个型号 跑校验:型号匹配 96.6%、厚度 95.2%、尺寸覆盖 29%、客户匹配 0% |
| 抽样式体检 | 抽 400 单 看 spec:97% 为 null 或「否」(等于没尺寸),只有 3 单有真实尺寸且属于 K / Y 系列,不是 H / S / M 主流系列 |
| 三个卡点 | ① 出厂价红线(PV / KW / K1)② 尺寸数据源 ③ 订单 ↔ 经销商 ID 对照表 |
结论:数据量根本不够跑智能算法。这一步不是"劝退客户",是把钱花在真正缺的地方——先补字段、建数据源,再谈引擎。延伸:模块 11 · 数据迁移实战(这批历史订单怎么落成一个能查的真库)、模块 13 · 报价引擎(为什么先量覆盖率再谈算法)。
客户进店到售后,不是一件事,是七段手工作坊式的接力。每一段的产出物,到了下一段就变成一个字段——字段断了,后面全断。
| # | 业务段 | 谁做 | 用什么 / 落到哪个字段 | 最容易错什么 | 信息化优先级 |
|---|---|---|---|---|---|
| 1 | 客户进店 | 门店导购 | 口头交流 + 微信;几乎不落库 | 客户是谁、从哪来,事后全靠回忆 | P1 |
| 2 | 出方案 | 导购 / 门店设计 | 画册 + 经验;型号 + 规格 + 颜色 | 型号写错字(H4 写成 H),选配漏项 | P0 |
| 3 | 下单 | 导购 | order + order_line(dealer_id / model / spec / thick / process / qty / area) | ① dealer_id 挂错 ② spec 空着交 ③ 型号无码 | P0 |
| 4 | 拆单 | 门店技术员 / 厂内 | bom_line(bom_cat 玻璃/五金/密封/型材 + sku + qty + route + supplier + line_cost) | 玻璃和五金的用量算错一档,整单成本偏 | P0 |
| 5 | 生产 | 厂 / 玻璃车间 | 玻璃图纸;thick 厚度 + process 工艺 | 厚度/工艺没传下去,整块玻璃重做 | P1 |
| 6 | 交付安装 | installer / 物流 | 出库单 + 安装单 + 照片回传 | 尺寸和现场对不上,装不上 | P2 |
| 7 | 售后 / 复购 | 店长 / 客服 | 客服记录(往往还在纸上/微信里) | 没有客户资产沉淀,二次购买不认识你 | P2 |
这句话是我在这个项目里最想让客户听懂的一句。它听起来像废话,但门店经营方普遍以为"我有三万多笔订单,我有数据了"。
| 有订单(表面看) | 有数据(能算东西看) | |
|---|---|---|
| 订单号 | 有,33,176 笔 | 有(唯一键) |
| 客户 / 经销商 | 有(订单表上写着) | 客户匹配 0% —— 订单和经销商对不上号 |
| 型号 | 有,2,799 个型号 | 型号匹配 96.6% —— 大部分能认 |
| 厚度 | 有 | 厚度 95.2% —— 勉强可用 |
| 尺寸 | 「应该有吧,都是按尺寸做的」 | 尺寸覆盖 29%,抽 400 单有 97% 是 null / 「否」 |
series / product_model / sku)是干净的;但尺寸和归属对不上,说明采集环节(第 3 段)从来没被当成数据环节管理过。spec 字段为空的杀伤力:一个字段能让整条流水线停摆在门店订购单系统里,order_line 的规格字段叫 spec。它看起来只是"一个可选参数",实际是报价、拆单、玻璃图纸三处的共同上游。
| 下游环节 | 需要 spec 干什么 | spec 为空时会怎样 |
|---|---|---|
| 报价 | 算玻璃面积 → 面积 × 单价 × 工艺系数 | 面积算不出来,只能报"区间价"或拍一个估算值 |
| 拆单 BOM | 决定标准件规格(铰链周长、胶条长度、型材长度) | 用量只能按默认值,BOM 是"看起来对"的错单 |
| 玻璃图纸 | 开孔位置、分割方式、磨边工艺都要尺寸 | 出不了图,或者出了图车间开不了料 |
| 生产排程 | 按尺寸分批次 | 全塞同一批,加工效率崩 |
实测分布(抽 400 单):
| 状态 | 占比 | 含义 |
|---|---|---|
spec 为 null 或「否」 | 97% | 等于这条订单没有尺寸 |
| 有真实尺寸 | 3 单 | 且都属于 K / Y 系列,不是 H / S / M 主流系列 |
"DP"在这个品类里指的是 DP 选型( doing 门型 / door pattern 的门扇配置选型)——选哪个系列、哪个门型、几个扇、什么开口方向。它是型号名(H4-T52 这种)的前半段。选型和型号对不上,后面全白搭。
| 校验项 | 实测覆盖率 | 判定 | 卡在哪 |
|---|---|---|---|
| 型号匹配 | 96.6% | 🟢 可用 | product_model.code 唯一索引在起作用,绝大多数历史单能对上型号 |
| 厚度匹配 | 95.2% | 🟡 勉强 | 厚度落在少数几个档位上,sku 主数据够用,但没有了档位就会掉到"无厚度"分支 |
| 尺寸覆盖 | 29% | 🔴 致命 | 见第 03 节:抽 400 单 97% 为空,且样本不在主流系列 |
| 客户 / 经销商匹配 | 0% | 🔴 致命 | 订单和经销商门店对不上号——不知道这张单该给谁报、算谁的业绩 |
| 匹配率 | 引擎能到哪一档 | 输出长什么样 |
|---|---|---|
| 型号 + 厚度(≈96%) | L2 | 能给到标准件成本,能出 BOM |
| + 尺寸(≈29%) | L3 卡死 | 面积算不出,只能报区间价(total_min / total_max 两列并存) |
| + 客户匹配(0%) | L4 卡死 | 连"给谁报"都答不了,红线价体系无从挂靠 |
PV / KW / K1建材行业的价格不是"一个数",是一张带红线的表。红线是厂家给的最低出厂价,低于这条线就是串货/违规——所以系统里必须能"拦",而不是"算完才知道"。
| 代码 | 性质 | 在系统里干什么 | 对 AI 的约束 |
|---|---|---|---|
PV | 出厂价 / 底价口径 | 报价计算的乘数基准 | 不许由模型"推"出来,只能从价表里读 |
KW | 口径 / 宽度类系数 | 和宽度相关的换算口径 | 变化频率高,必须按生效日期查 |
K1 | 口径 / 折扣类系数 | 和系列、经销商等级挂钩 | 不同经销商不同值,跨单混用就是错价 |
PV 这种缩写,非常容易顺手编一个"合理值"——这就是最危险的一类错:错得很像真的。below_floor: true,让人一眼看到"这条单不能这么报",而不是让人自己拿计算器去比对。"尺寸覆盖率 29%" 这句话本身还有歧义。真正难的不是"有 29% 的尺寸",而是这 29% 的尺寸可信吗、从哪来、谁改过。
| 缺的不是 | 缺的其实是 | 不解决会怎样 |
|---|---|---|
| 一个尺寸输入框 | 尺寸的数据源定义:门店量房单?厂里复尺?还是导购口头记的? | 同一个客户两版尺寸,谁也不知道哪个是最终版 |
| 一个字段 | 字段的必填纪律:下单时哪几个字段是"不填不让提交" | 99% 的单都能提交成功,系统就在默许空字段 |
| 一个表 | 复尺变更的痕迹:改过几次、谁改的 | 装不上时无法追责,只能吵 |
不是全字段必填——是按系列分档必填。H / S / M 这类主力系列尺寸必填;K 系列走 BOM 模板兜底时,允许参数缺失但必须打上"模板价"标记,绝不能静默当真实尺寸用。
同一个 spec 值,source = 门店量房 / 厂内复尺 / 客户口头 三种可信度不同。报价时用最高可信度的那一版。
不是上线就不管了。SELECT count(*) FROM order_line WHERE spec IS NULL OR spec='否' 这条 SQL 每周跑一次,数字从 97% 往下降就是真的在治理,不动就是假的。
客户匹配 0%,指的是:订单上虽然有"经销商"这个字段,但它和实际的经销商门店主数据对不上。
| 现象 | 根因 | 后果 |
|---|---|---|
| 同一个门店在不同订单里 ID 不同 | 历史数据里门店是按名字存的文字,没有统一编码 | 按经销商统计业绩时,一家店被拆成五家店 |
订单 dealer_id 指向不存在的行 | 删过门店,没做软删除 | 外键悬空,关联查询直接丢行 |
| 387 个"经销商"里大部分只有一两张单 | 这是渠道/项目制的残留,不是零售门店 | 以为有 387 个客户,实际能跑通业务闭环的是少数 |
SELECT DISTINCT 经销商名称 FROM order,拿到实际出现过的所有写法dealer.code(如 DL01…)dealer_id;改前先 SELECT 同一个 WHERE 看影响行数延伸:模块 11 · 数据迁移实战 里那套「脏数据六种典型形态」里的单位不统一和孤儿引用两种,就是这两类问题的学名。
这是这一页最该被复制走的东西。不管用什么模型,把下面这张规则贴进你的系统提示词或校验层,能挡掉 90% 的"看起来很专业的错"。
| # | 规则 | 违规示例 | 正确行为 |
|---|---|---|---|
| R1 | 字段缺失 ≠ 默认值 | spec 为空 → 取"标准 800mm"继续算 | 立即返回 COMPLETE_REQUIRED,附上缺哪个字段 |
| R2 | 价格/系数只能读,不能推 | 缺 PV → 模型编一个"合理出厂价" | 缺失即中断,绝不许生成数值 |
| R3 | 未知 ≠ 零 | 厚度没匹配上 → 按 0 参与计算 | 厚度档位未命中就走"未定档"分支,不参与数值运算 |
| R4 | 兜底必须显式标记 | K 系列无价 → 静默用模板价 | 返回结果 + 标记 priced_by = template,让下游知道这是估的 |
| R5 | 错误必须可归因 | 只回一句"无法报价" | 回 { error, missing_fields[], blocking_reason } |
| R6 | 宁可少说,不可编造 | 不确定时给个"大约"值凑上 | 不确定就输出"该维度覆盖率 X%,不足以计算" |
同一类错误有三种长相。它们的共同点是:结果都长得像一个正常的报价单——有金额、有明细、能导出、能发给客户。这才是危险所在。
| 错误长相 | AI 实际做的 | 看起来像什么 | 真实后果 |
|---|---|---|---|
| 静默补默认值 | spec 空 → 用"标准尺寸"算,不加任何提示 | 「一份完整的报价单」 | 客户按这个价签单,实际开工发现尺寸不对 |
| 编造系数 | 缺 PV → 说"按常规 0.85 系数" | 「算得很细的报价单」 | 价格低于红线,厂家不认,或者你自己亏 |
| 混淆兜底与实测 | K 系列用 BOM 模板价,输出时没说是估的 | 「和别家一样的精确价」 | 客户拿模板价当实价砍价,门店没有还价空间 |
客户常问"能不能先上个智能推荐"。先给这张表,比讲一堆技术概念有用得多。
| 优先级 | 做什么 | 交付物 | 为什么是这个顺序 |
|---|---|---|---|
| P0 | 下单表单强制字段校验 + 经销商下拉锁定 | 一个能"不许提交不完整单"的表单 + 空值周报 SQL | 不动数据质量 ,后面全是空中楼阁 |
| P0 | 出厂价红线表落库(PV/KW/K1 只读路径) | 价表 + 报价结果带 below_floor 标记 | 红线是合规线,必须先有 |
| P1 | 订单 ↔ 经销商 ID 对照表回填 | 对照表 + 历史数据 UPDATE 记录 | 解锁一切按客户的分析 |
| P1 | 主流系列(H/S/M)尺寸采集纪律 | 分档必填规则 + 来源标记字段 | 把 97% 的空值率往下降 |
| P2 | 玻璃图纸自动化、安装回传拍照 | 图纸生成 + 回传链路 | 生产端提效,不影响正确价 |
| P3 | 智能推荐、智能客服、销量预测 | 算法模块 | 数据达标后才谈得了 |
德莉玛门店订购单系统 v2.5.0 的主链路就这四段。每一段的输出都是下一段的输入字段,中间任何一段"静默降级",都会传染到最后。
order + order_line)order_no / dealer_id / status / total_min / total_max),明细放每行独有(model / spec / thick / process / qty / area)。这一步决定了"这条单有没有身份"。bom_line)bom_cat 四类(玻璃 / 五金 / 密封 / 型材)+ sku + qty + route(玻璃厂/型材厂/五金厂/胶条厂)+ supplier + line_cost。这是 BOM 揭示成本的地方。thick(厚度)+ process(工艺)+ spec(尺寸)。这一段是"物理世界"——出错了不是数据错,是真要开料、真要装不上。total_min / total_max)priced_by=template。坑 1 · 拿「订单数量」当「数据质量」汇报
「我们有 33,176 笔订单」是数量,不是质量。真正该汇报的是四个数字:型号 96.6% / 厚度 95.2% / 尺寸 29% / 客户 0%。汇报数量会被问"那能算出价吗",汇报覆盖率会直接决定下一步做什么。
坑 2 · 抽样的单不在主流系列上
400 单里只有 3 单有真实尺寸,而且这 3 单是 K / Y 系列。如果只说"尺寸覆盖率 3%",结论方向没错,但你会误以为补 397 单就能达标。正确说法是:主力系列 H/S/M 的有效样本量 ≈ 0。
坑 3 · 用 BOM 模板价冒充实价对外报价
K 系列没价格,BOM 模板能兜底算出个数。兜底是内部算成本用的,不是对外报价用的。只要模板价 outflow 到报价结果里,就必须在输出上打标记;不打标记 = 主动制造纠纷。
坑 4 · 让 AI 去"推断"经销商归属
客户匹配 0% 的时候,模型很容易根据片区/电话区号"猜"这是哪家店。猜对是运气,猜错是事故(业绩算错、红线价给错对象)。归属关系只能来自对照表,不能来自推理。
坑 5 · 上线即不管,空值率永远 97%
表单校验加了,第一周从 97% 掉到 20%,第三周又爬回 90%——因为门店赶单时会绕开必填。所以才需要那个每周的空值 SQL 和月度盘点,否则你会以为"改了表单就完了"。
spec 为 null /「否」,且有效样本不在主流系列说立场:我做过德莉玛淋浴房的门店订购单系统,本地 8787 端口跑订单→BOM→玻璃图纸→报价这条流水线。这个项目 data 层面最难的不是算法,是"字段根本没被采集过"。
先给客户看数字。客户原本要的是自动报价,我拿他 33,176 笔历史订单 / 387 个经销商 / 2,799 个型号 跑了一遍校验,结果很直接:型号匹配 96.6%、厚度 95.2%,这两个还行;但尺寸覆盖只有 29%,客户匹配是 0%。 我又单独抽了 400 单看 spec 字段,97% 是 null 或者写着「否」——等于没尺寸。而且剩下那 3 单有真实尺寸的,是 K / Y 系列,不是主力 H / S / M。
所以我给客户的结论是:主数据是干净的,业务数据是空的。型号厚度能匹配,说明型号库、SKU 库建得没问题;但尺寸和经销商归属对不上,说明采集环节从来没被当成数据环节管理过。真正的卡点也不是缺一个报价算法,是三个前置数据缺失——出厂价红线 PV/KW/K1、尺寸数据源、订单↔经销商 ID 对照表。
所以方案改成:先把这三个前置建起来,报价引擎等数据达标再上。这避免了客户花大钱买到一个算不出价、或者算出个错价的系统。
至于 AI 这一层,我最坚持的一条规则是:字段缺失不等于默认值。 我把校验规则写死在系统里——缺尺寸就报「算不了,缺 spec」,缺 PV 就不许模型编一个"合理系数",K 系列走模板兜底必须在结果上打 priced_by=template 标记,报错必须返回缺哪几个字段。判断一个 AI 系统靠不靠谱,只问一句:它算不出来的时候会不会说"我算不出来"。会说的才能被信任;总能给你一个数的,你只是不知道哪次是编的。
价值上,这套东西改变的是对话方式:以前客户说"你这系统算的价不对",我自证不了;现在系统每次算不了都会明确说缺哪个字段,争议从"你算错了"变成"这个字段还没录"——这是两个完全不同的对话,也是数据治理的钱该花的地方。
七段:客户进店 → 出方案 → 下单 → 拆单 → 生产 → 交付安装 → 售后复购。
我会按"谁做 / 用什么 / 最容易错什么 / 信息化优先级"四列拆成一张表。但真正要盯的是优先级:P0 只有两个——下单和拆单。理由是:这两段是唯一决定"这条订单有没有变成数据"的段落。第 1 段(进店)和第 7 段(售后)错了只是慢一点;第 3 段(下单)错了,整条数据链从源头就是空的——型号对、厚度够,但 spec 是 null,后面报价、拆单、玻璃图纸三处一起塌。
拆单段也别低估:它输出 bom_line 的玻璃 / 五金 / 密封 / 型材四类,还带 route 和 supplier。用量错一档,整单成本就偏,而且这个错平时看不见,只有对账时才发现。
先给一张优先级表,再谈智能。
我会把 P0 到 P3 摊开给他看:P0 是下单表单强制字段校验 + 经销商下拉锁定、出厂价红线 PV/KW/K1 落库;P1 是订单↔经销商 ID 对照表回填、主流系列尺寸采集纪律;P2 是玻璃图纸自动化和安装回传;P3 才是智能推荐、智能客服、销量预测。
P3 那一行我会跟他一起读三遍。因为经销商行业最贵的错,是在 P0 没做完的时候先花钱买了个 P3 的东西,然后说"算法不准"——不是算法不准,是它拿到的是空字段。
因为价格表上没有 K,只能靠 BOM 模板兜底。
德莉玛 5 大系列里,H / S / M 配了价格,K 系列要靠 BOM 模板兜底。这不是"还没配上"的临时状态,是必须写进系统的约束。所以我定的规则是:兜底可以,但必须在结果上打 priced_by = template 标记。
为什么这么严:模板价是内部算成本用的,一旦冒充实价对外报价,客户会拿这个估计值来砍价,门店就没有还价空间了。而且它造成的错特别隐蔽——数字看起来完全正常,只是不准,等到对不上账才发现,已经吵完了。
所以对应的校验规则是 R4:兜底必须显式标记,和 R1(字段缺失 ≠ 默认值)配套用。
一条 SQL,每周跑,数字只准往下走。
SELECT count(*) FROM order_line WHERE spec IS NULL OR spec='否'——这条 SQL 就是唯一的客观证据。改完表单第一周能从 97% 掉到 20%,第三周又爬回 90%,因为门店赶单时会绕开必填;这时候你只有两种选择:要么真管,要么假装没这事。
我会把这个数字做成一个固定看板,跟型号 96.6%、厚度 95.2%、尺寸 29%、客户 0% 这四组数放一起看。四组数一起动才是治理,只有一组动说明是局部补丁。汇报的时候也只报这四组数——"我们有 33,176 笔订单"是数量,不是质量,报数量会被问"那能算出价吗",报覆盖率才能直接决定下一步做什么。
本篇讲的是业务流和数据质量。栅格类产品的结构正确性怎么度量、AI 出图怎么不把门扇数画错,在 21 组 · 门窗与淋浴房;旧改 / 局改 / 适老化的 B2B 定位与出片降本,在 21 组 · 旧改局改。
基础面:模块 11 · 数据迁移(脏数据六种形态)· 模块 13 · 报价引擎(先量覆盖率再谈算法)· 基础 16 · 数据库(27 张表怎么组织)。