我们试过通用大模型，效果很差，是不是行业还太早？

不是行业太早，是用错了工具。通用大模型读工业文档缺两样东西：行业知识和工程化校验。它不知道哪些条款是红线，读漏了也不会告诉你。换具备深度文档处理能力的方案再测一次，结论往往反过来。

非标是不是意味着每个项目都要定制、很贵？

前期确实要有人深入业务梳理口径，这部分按周计、躲不掉。但定制的是规则和知识，不是从零开发系统。而且梳理过的经验会沉淀下来，第二个同类场景的成本会明显下降。

问三个问题：在你们真实文档上敢不敢实测；低置信度的内容有没有显式标记、人能不能接管；每次人工修正会不会变成系统的规则。三个都答得具体的大概率跨过了门槛，答得含糊的，演示再漂亮也进不了工厂。

多半不用。产品标准、文档模板固定、订单重复度高的厂，通用工具加简单配置可能就够。先确认核心文档是不是真的非标——一份 SOR 换个客户就大变样的，才是。

FDE 是前沿部署工程师模式：工程师进驻现场，在真实业务里把系统打磨到能用，并对结果负责。和咨询公司的区别在交付物——不是一份报告，是一个敢在真实业务里运行的系统。

老板对 AI 的第一印象大多来自写周报、做 PPT——又快又像样。于是自然期待：既然这么聪明，把客户发来的 SOR 读一遍、出个方案应该不难。

真试过的人都知道结果。销售把一份 300 页的客户 SOR 丢给通用大模型，它还回来一段通顺流畅的总结，挑不出语病。工程师逐条核对后才发现：强制性条款漏了十几条，其中一条是关键公差。总结越通顺，漏得越隐蔽。

这类文档有三个共同点：语义密度高，一张图纸每个符号都是工艺约束；隐性知识多，「按惯例」「同上次订单」写在字面之外；容错率为零，一个公差漏读就是一批报废。

代价：

跨过门槛的方案，差别不在模型更聪明，而在补上了两块结构性缺失：行业知识——知道某个配合代号意味着什么、哪个客户的哪些条款从来不让步；工程化校验——每条结论带来源、能回溯，低置信度的标出来交给人。

落到日常，是三个看得见的变化：在你们的真实文档上读得准，而不是在演示样本上；读错了能被人接管，而不是悄悄错过去；每次人工修正都沉淀成规则，下一份同类文档自动受益。这背后那层能力叫深度文档处理，它是各环节应用共用的地基。

先确认你的文档是不是真的非标。 产品标准、模板固定、订单重复度高的厂，通用工具加简单配置可能就够，别为不存在的难题买深度方案。判断方法：一份核心文档换个客户是不是就大变样。是，才谈得上非标。

隐性知识必须有人喂。 「按惯例」三个字背后的东西在老师傅脑子里，任何系统都读不到字面之外。老师傅不配合把惯例讲出来，系统永远停在演示水平。

它不改「谁负责」。 漏读一条强制性条款的损失谁承担，合同里写不清楚，系统就不该上线。AI 能标红风险，但拍板的还是人——读标场景里的这条边界，在所有环节都一样。

非标的含义是没有开箱即用：前期要有人深入业务，把行业知识、校验规则和文档口径一起梳理出来，这部分按周计，躲不掉。

判断值不值，拿漏一条强制条款的代价去比：一单的错配损失，通常就覆盖掉前期梳理的投入。我们的做法是场景诊断、PoC 验证、再谈扩展——先在真实文档上跑通，再决定要不要往下走，而不是先签一个「平台」。

一家汽车零部件企业收到客户的 SOR，300 多页。用通用大模型处理，得到的总结通顺流畅；工程师逐条核对，发现漏掉 12 条强制性条款，其中一条是关键公差要求。

如果按这份总结报价：满足那条公差需要新增一道精加工工序，单件成本增加 8 元；按年供货 50 万件算，就是 400 万元一年的成本没有计入报价。中标即亏损。

换个读法的结果：12 条强制条款逐条列出、各自带来源页码，公差那条因为涉及关键特性被标红，工程师复核只用确认这十几条，而不是重读 300 页。差别不在省了多少阅读时间，在于漏没漏——漏一条，前面省的时间全部赔进去还不够。