1. 定制订单的“最后一公里卡点”Spec提取到底卡在哪定制类产品的订单履约流程看起来并不复杂客户报需求销售报价工程师出图车间加工最后交付。但只要你真正走过一遍就会发现在这条链路的起点有一个特别容易被低估的卡点——客户说出来的需求和系统能识别的参数几乎不是同一种语言。比如客户写一句“外罩按常规做厚度要加厚”到了生产端到底加厚多少是壁厚加厚还是整体尺寸放大没有答案“无人化”连第一步都迈不出去。产品定制无人化的核心不是让机器直接去加工而是让需求从进入系统的那一刻起就变成可以被程序处理、被下游CAD/CAM/ERP消费的结构化数据。这条转化链路里最关键的环节就是Spec提取把客户原话里的定制信息变成一份可校验、可追溯、可直接驱动生产系统的结构化规格说明书。我参与过的一个定制订单数字化改造项目最初定下的目标是“订单录入人员减半”后来发现真正的瓶颈根本不在录入速度而在录入质量。客户发来的需求十单里有七单需要二次确认。今天换个供应商明天改个材质后天又出现一个“跟上次一样”的引用。这些问题不解决后面的自动报价和自动排产都是空中楼阁。1.1 客户语言和系统语言是两套体系Spec提取的第一个难点是语言体系不一致。客户用日常白话描述需求系统需要的却是带单位、带公差、带材料牌号的确定性参数。客户原始说法系统需要的字段为什么这里容易断外壳按图纸做图纸编号、图纸版本、BOM校验状态“按图纸”可能指旧版图纸还需要确认是不是最新版颜色跟上次一样色号、色差值、表面质感“上次”要关联历史订单不能只存一个颜色名称厚一点材料厚度、公差、是否影响折弯“一点”没有量化不同工程师理解不一样防水防护等级、密封条规格、测试标准客户说的防水可能是“泼溅”也可能是“浸泡”这些例子不是抠字眼每一个都会直接影响报价和制造。如果系统只提取了一个模糊的颜色词到了车间依然要靠老师傅猜。所谓无人化本质上就是把老师傅脑子里那些“默认逻辑”“常见做法”“历史经验”显性化成规则和数据结构。1.2 人工录入不仅是慢更是不透明有人会说人工录单也没什么不好老业务员一小时能录七八张订单。但当产品线从十种扩展到一百种字段组合会指数级增加老业务员的经验也会失效。更麻烦的是人工录单的中间过程是一个黑盒他为什么把“厚度要加厚”理解成2.0mm为什么不确认“冰灰”的色号这些判断逻辑是沉淀在个人经验里的系统学不到。我们在项目初期做过一次抽样两百张历史订单里同一句话被两位录单员解释成不同参数的情况占了三成左右。这还不是离谱的错误而是岗位差异造成的“合理偏差”。比如“常规做”这个短语在销售眼里是标准产品在工艺员眼里却意味着要重新校核折弯系数。Spec提取要做的第一件事就是把这些隐性的解释规则统一掉。1.3 一个贯穿全文的例子为了后面方便讨论我先放一个典型的客户需求原文外罩尺寸800600400板厚2.0材质304表面拉丝不要把手颜色冰灰数量200年前能交吗如果交给系统理想的Spec提取结果大概是这样字段提取值状态产品族机柜外罩已识别外形尺寸长800mm × 宽600mm × 高400mm已提取板厚2.0mm已提取材质SUS304已归一化表面处理拉丝已提取把手数量0由“不要把手”识别已提取颜色冰灰具体色号待确认有歧义数量200已提取交期年前需结合产能待评估注意这份Spec往下游传递的时候还会暴露出几个缺口没有标注公差材质只写了“304”但没区分304和304L颜色“冰灰”没有对应标准色号交期问题也不是提取模块能单独回答的。所以Spec提取不是简单抓关键词而是边提取边发现缺口边把缺口反馈给人工处理。2. Spec提取的技术选型规则、词典、模型怎么分工很多人一听到“提取”就直接想到大模型这其实是个误区。Spec提取和生产制造是强绑定场景一个字段错了可能直接造成批量返工。系统给出的每个值都应该能被解释出了问题要能溯源。大模型表达能力强但输出不稳定不适合作为唯一决策源。2.1 先别急着上大模型我见过不少团队刚立项就买了一堆算力让大模型直接从客户留言里抽字段。Demo阶段确实惊艳一上线就傻眼同样的需求换个说法输出结构就变了字段明明抽对了但缺少来源引用出了问题不知道是谁的锅更麻烦的是大模型会把客户没写的值“脑补”出来这在制造场景里非常危险。所以更合理的思路是分层处理80%的固定表达用规则和模板解决15%的可变句式用模型解决最后5%的罕见表达交给人工兜底。听起来不够性感但稳定、可控、可维护。2.2 三层解析架构我建议把提取逻辑拆成三层各管一段第一层是范式解析层。像“尺寸800600400”“板厚2.0”“数量200”这类表达格式相对固定用正则模板和词典就能拿到。这一层速度最快也最容易被验证。第二层是语义解析层。处理“不要把手”“厚一点”“跟上次一样”这类需要理解语义的表达。比如“不要把手”要识别出否定意图把把手数量置成0而不是简单匹配到“把手”这个词就填“有”。第三层是知识兜底层。维护产品族词典、同义词表、历史订单索引。比如“304”要归一成“SUS304”“拉丝”要映射到标准工艺代码“冰灰”要尝试查色卡。没有这一层前两层抽出来的东西还是散的。这三层之间不是严格串联而是并行提取后做合并投票。每个字段都会带一个置信度值越高越直接自动通过值越低越要转人工。2.3 几种技术方案的适用边界技术方案优点主要坑适用场景正则模板速度快、完全可控对自然语言变化太脆弱结构化PDF、Excel、固定句式词典加规则可解释、容易维护词表膨胀后维护成本高同义词归一、产品族识别传统机器学习模型有一定的泛化能力需要标注数据处理“厚一点”“不要把手”等短文本大模型理解力强、零样本可用输出不稳定、难溯源提取结果的辅助建议、人工复核界面我们这个项目最后采用的方案是“固定格式走规则可变句式走小模型罕见表达走大模型辅助加人工确认”。这样既保留了吞吐速度也把解释不了的风险控制在人工闭环里。技术选型不是越高级越好而是越匹配数据现状越好。3. Spec Schema设计比算法更重要的目标结构如果提取算法是汽车Spec Schema就是方向盘和仪表盘。很多项目失败不是因为模型不够好而是从一开始就不知道要提取哪些字段、字段之间有什么约束关系。拿到客户文本后先把字段设计清楚比急着训练模型重要得多。3.1 从制造BOM倒推数据模型不要从文本反推正确做法是先问下游系统需要什么再让提取方案去适配。举个例子如果自动出图程序需要长、宽、高、板厚、折弯半径、色号那Schema里就必须有这些字段如果ERP只需要产品编码和数量那提取得再细也没有用。我习惯把Spec字段分成几组基础识别组产品族、订单号、数量、交期。几何尺寸组长、宽、高、直径、厚度、公差、尺寸类型。材料工艺组材质牌号、表面处理、涂层、热处理。配置项组把手、门板、脚轮、开孔位置、印刷内容。商务属性组颜色、包装、标识、认证要求。每个字段都要带单位、置信度、来源和状态。不要只存“800”这个数字要存“800mm来自‘尺寸800600400’置信度1.0”。这样后续审计、纠错、复盘才有依据。3.2 字段约束关系必填、条件、互斥、缺省Spec Schema不能只是字段清单还得把约束关系写清楚。最常见的四类关系约束类型含义例子必填项缺了不能往下走外形尺寸、材质条件必填满足某个条件时必须出现材质选铝型材时必须确认氧化工艺互斥项两个值不能同时成立“不要把手”和“把手数量2”不能并存引用项需要关联历史数据“颜色跟上次一样”必须引用历史订单色号还有一个容易被忽略的问题缺省值和“客户没提”要区分。“不要把手”是明确为0“没提把手”是未知如果把未知当成默认没有很可能做错。Schema里要单独留一个“status”字段明确区分已提取、缺省、有歧义、未提及。3.3 一份可落地的Spec JSON模板下面是我在实际项目中常用的Spec JSON结构字段不多但足够支撑下游系统使用{ schema_version: 1.0, order_no: SO-2025-00421, product_family: 机柜外罩, extract_time: 2025-05-12 10:30:00, fields: { external_length: { value: 800, unit: mm, confidence: 1.0, source: 尺寸800*600*400, status: confirmed }, external_width: { value: 600, unit: mm, confidence: 1.0, source: 尺寸800*600*400, status: confirmed }, external_height: { value: 400, unit: mm, confidence: 1.0, source: 尺寸800*600*400, status: confirmed }, sheet_thickness: { value: 2.0, unit: mm, confidence: 0.99, source: 板厚2.0, status: confirmed }, material: { value: SUS304, confidence: 0.98, source: 材质304, status: confirmed }, surface_finish: { value: brushed, confidence: 0.9, source: 表面拉丝, status: confirmed }, handle_quantity: { value: 0, confidence: 0.95, source: 不要把手, status: confirmed }, color: { value: null, confidence: 0.4, source: 颜色冰灰, status: ambiguous } }, missing_fields: [tolerance], ambiguous_fields: [color] }每个字段都带source的好处是哪怕系统判断错了审核人员也能顺着来源回到客户原话而不是面对一个不明不白的结果。无人化之后可追溯性比提取准确率更让人安心。4. 从客户原话到可执行Spec五步流水线的落地细节有了Schema还只是搭了骨架真正要跑起来需要一条完整的处理流水线。我们最终落地的流程大体分为五步输入标准化、字段提取、冲突检测、人工复核、下发冻结。每一步都直接影响最终质量。4.1 输入标准化把图片、PDF、语音、Excel统一成文本加附件客户需求来源千奇百怪网页表单、邮件附件、微信截图、手写扫描件、Excel报价单。Spec提取的第一步不是直接抽字段而是把所有内容统一成标准输入一段可检索的文本加上若干原始附件。这个环节经常被当成琐事但它决定了提取上限。扫描版PDF如果OCR不准后面的规则再精细也没用。中文表格里“板厚2.0”经常被识别成“板厚2.O”字母O和数字0难以区分客户拍的照片有透视变形标注的尺寸在图像上已经扭曲。我们对OCR结果一定要做字段级抽样验证不要只看整页准确率。另一个小经验是网页表单里的结构化字段和附件里的备注文本应该分开处理。表单字段直接映射备注文本走Spec提取。两者冲突时不要一方直接覆盖另一方而是发起冲突校验。4.2 字段提取与归一化不是只抽出来还要翻译成内部语言字段提取完成后紧跟着做归一化。“304”“sus304”“SUS 304”要统一成“SUS304”“拉丝”“拉丝处理”“表面拉丝”要统一成工艺代码“brushed”“冰灰”按色卡尝试映射如果查不到对应色号就保留值并标记为有歧义。这一步经常被忽略却是下游能否自动化的关键。如果系统里存了十种“灰色”的写法自动比价、自动排产都会出问题。归一化规则要维护在词典和知识库里随着新订单不断补充。4.3 冲突检测与缺省策略不自动猜是无人化的底线提取结果里出现冲突不可怕可怕的是系统为了显得“聪明”而自动选择一个值。我们遇到过一个典型情况客户先写了“尺寸800600400”后面备注里又加了一句“高改成1200”。如果简单取后者就可能漏掉宽度和深度信息如果简单取前者又忽略客户的修改意图。我们的处理原则是同一字段出现两个不同来源的值时不自动覆盖而是进入冲突队列由人工根据上下文判断。缺少必填字段时只有产品族里有明确默认值才允许填充没有默认值的生成一条待确认问题反馈给客户。单位缺失时按产品族默认单位解析但置信度只能给0.7不能当成确信值。情况处理方式同一字段出现两个值标记为冲突转人工复核缺少必填字段有默认值才填充否则生成待确认问题值超出允许范围进入异常队列单位缺失按产品族默认单位解析但降置信度4.4 人工复核与字段级修订把人工集中到异常单里无人化不是零人工介入而是把人工从100%的订单里解放出来只处理真正需要判断的那部分。在流程设计上所有低于置信度阈值的字段、冲突字段、歧义字段都会集中到一个复核队列。复核界面按字段展示来源、位置、客户原句和推荐值审核人员可以修改、补充、退回重提。这个问题解决后修订结果要回流到样本库用于补充词典、调整规则、更新模型。没有这个回流闭环系统只会停留在固定水平上无法越用越准。4.5 下发下游系统与版本冻结让Spec变成不可变快照Spec确认完成后系统会生成一个唯一的spec_no并把整个Spec连同来源文本打成快照保存。所有下游系统都调用这个固定的版本不要允许任何人直接修改。我们踩过的教训是客户中途把“材质304”改成“材质316”如果直接在原Spec上改动工艺部门还在用旧版本排产结果做错了批次。后来改成严格冻结旧版本、生成新版本的方式每次变更都会生成差异对比表还要触发一次工艺可行性评估。这条规则对定制类订单尤其重要。5. 踩坑实录Spec提取最容易翻车的五个细节5.1 一词多义同一个词在不同产品线里含义不同“厚度”在钣金产品里指板材厚度在喷涂件里可能指涂层厚度在管材里又可能是壁厚。客户只写一个“厚度12”不同产品线的理解完全不一样。所以产品族识别必须放在字段提取之前先确定上下文再选择对应的字段词典。我们还遇到过“尺寸”这个词的歧义对箱体类产品通常指长宽高对型材类产品可能指截面尺寸。Schema里要专门增加“尺寸类型”字段区分外形尺寸、展开尺寸、内径尺寸、成型尺寸。分类错了后面的所有几何参数都会错。5.2 “没提”和“不要”要严格区分“不要把手”和“没提把手”是两件事。前者是明确要求把手数量等于0后者是信息缺失不能想当然填默认值。我们的语义解析层专门处理否定意图把所有“不要”“无需”“去掉”“不需要”开头的短语单独走一条路径。颜色的缺省问题也一样。客户没写颜色不应该自动填“常规灰”除非产品族明确规定默认色号。如果随便填了默认值后面客户看到成品才发现颜色不对整个订单都白做。Spec里的未提及字段宁可让它在“missing”列表里躺着也不能为了好看而填一个猜测值。5.3 单位、小数点和尺寸顺序定制订单里最常见的单位混用是英寸、毫米、米混在一起。客户写“2m”可能是2米也可能是2毫米的手误写“1/2寸”又需要转换成毫米。我们的做法是强制单位归一所有长度在Spec存储层统一用mm无法确定真实单位时给0.6的置信度并转人工。OCR也会引入很诡异的错误。小数点被识别成句号“2.0”变成“2。0”乘号“*”在客户手写单里可能像字母“x”也可能像“×”。这些都需要在规则层做容错但容错规则不能无限放宽否则会把原本正确的输入也改坏。5.4 订单变更不能直接改原Spec定制订单在报价、设计、生产阶段都可能被客户追加修改。“颜色改成深灰”“数量加100”“把手去掉”每个变更指令都意味着一次新的Spec提取和版本对比。我们的做法是把变更当作一次新的提取任务生成新版本保留旧版本计算字段差异。差异表要能直接推动报价重算、交期重排、生产影响评估。如果新版本发现“已投产”的字段被修改系统直接弹警告不允许静默通过。这一步看似浪费实际上避免了大批量返工。5.5 “跟上次一样”这类跨订单引用客户为了省事经常写“跟上次一样”“类似上次那个机柜”“颜色按上批来”。这类表达看似简单处理起来非常麻烦系统要解析出引用对象去历史订单里找到对应订单再判断哪些字段可以继承。如果历史订单有多个版本还要判断引用的是哪个版本。如果找不到唯一匹配就标记为歧义字段转人工绝不能用“看起来最像”的订单直接替代。我们在做历史订单索引时把客户编号、产品族、订单时间、工艺版本都作为匹配条件宁可多问客户一句也不要自作主张。坑点现象最终处理一词多义同一术语在不同产品线含义不同先确定产品族再选字段词典“不要”被忽略“不要把手”被当成缺省语义层单独识别否定意图单位混用“2m”被误判成2mm单位强制归一无法确定进人工订单变更直接覆盖原Spec冻结旧版本变更生成新版本跨订单引用“跟上次一样”找不到匹配历史订单索引未命中转人工这些坑如果前置到测试用例里会节省大量开发时间。我们后来在验收时专门造了一批“坑单”每一条都覆盖一个极端场景定期回归测试确保改了新规则后没有把以前做对的单子改坏。6. 从“半无人化”到“无人化”指标、闭环和下一步产品定制无人化不是一步到位的项目推进也得分阶段看指标。很多团队一上来就追求100%自动通过率结果发现客户需求千奇百怪上线后反而把人工流程搞得更复杂。我更建议分产品线逐步推进先把自动化率做起来再慢慢扩大覆盖范围。6.1 用历史订单样本评估自动化率在正式开发前先选出两个字段较少、表达相对稳定的产品线收集一千张历史订单做标注。人工标注出每个订单的真实Spec然后拿这部分样本估算字段识别率和自动通过率。关键指标有这么几个指标定义初期目标字段级准确率正确提取字段数 / 人工标注字段总数90%以上自动通过率无需人工复核的订单数 / 总订单数60%左右变更单回归通过率重新跑历史订单时已识别正确的字段是否保持正确100%字段级准确率和自动通过率要分开看。有些订单虽然大多数字段都对了但一个颜色有歧义整单就要转人工有些订单字段少、表达规范准确率不高也能自动通过。所以两个指标都要监控。6.2 建立规则回流闭环系统上线后人工复核的结果不能白白浪费。每一条人工修改都要记录原因并且定期聚类分析哪些字段经常被改哪类客户表达总是理解错哪些产品族的词典缺失严重这些问题会转化成新的规则、新的词典词条、新的训练样本。我在项目里最看重的不是模型本身的准确率而是这个闭环转起来之后的长期稳定性。今天把“冰灰”映射到色号库明天把“灰色”映射到另一套色号库靠的都是运营积累不是一次性的代码交付。6.3 下一步扩展从Spec提取走向Spec生成当历史Spec数据积累到一定规模可以做的就不再只是提取了。系统可以基于客户询价时的粗略描述先生成一份建议Spec再让客户确认可以对比历史类似订单给出报价区间可以在工艺环节自动推荐加工方案。这些能力的前提都是结构化Spec数据本身足够准确、足够完整。我们当时的目标是把常规订单的自动通过率从60%逐步推到85%剩下的15%集中在真正的非标需求上。这一目标完成后再去扩展新产品线会比一开始就铺开所有产品线稳妥得多。如果让我重做一遍我会先花两周时间把过去一年的订单整理成标注样本再碰代码。很多团队在这里省时间后面全都花在补坑上。这个时间投入比换任何先进模型都划算。