一个反差：写周报很强，读 SOR 全军覆没
很多老板对 AI 的第一印象来自写周报、做 PPT——又快又像样。于是他们自然期待：既然 AI 这么聪明，帮我把客户发来的 SOR（Statement of Requirements，需求规格书）读一遍、出个方案应该不难。
真试过的企业知道结果。我们见过一家汽车零部件企业用通用大模型处理客户的 SOR：300 多页的文档，AI 总结得通顺流畅，但逐条核对后发现，漏掉了十几条强制性条款，其中一条涉及关键公差要求。如果按这份「总结」报价和排产，损失以百万计。
什么是「非标」
工业业务的核心载体是一批高度「非标准化」的文档：SOR、图纸、技术协议、工艺卡、检验规范。它们有三个共同点：
- 语义密度极高：一张图纸上的每个符号都可能对应一条工艺约束，没有一句废话可以跳过。
- 隐性知识多：「按惯例」「同上次订单」「参考样件」——大量约定俗成的含义写在字面之外。
- 容错率为零：一个公差值漏读、一个材料牌号看错，就是几十万甚至更高的报废与索赔。
通用方案为什么不够
提示词工程加通用大模型，是很多企业尝试的第一步，也是多数人停下的地方。问题不在模型不够聪明，而在两个结构性缺失。
一是缺少工业知识图谱。通用模型不知道你的行业里某个配合代号意味着什么、不知道某个客户的技术协议里哪些条款从来不让步。没有这些知识，它读文档时无法分辨哪里是普通描述、哪里是红线。二是缺少工程化校验。工业场景要的不是「大概率对」，而是「每一条都可核对、可追责」——抽取结果必须逐条回溯到原文位置，低置信度的必须标出来交给人。
真正的门槛：深度文档处理
把非结构化需求转成可执行的结构化指令，这件事我们称之为深度文档处理。它远不止「让 AI 读 PDF」：要先理解文档的行业语境，再把需求拆解成结构化的条款、参数、约束，最后输出成下游系统能直接消费的形式——报价单的输入、工艺规划的输入、质检计划的输入。
谁跨过这道门槛，谁就能把 AI 从「办公室的文案助手」变成「业务流的入口」。这也是我们判断工业 AI 项目价值的第一标准：它处理的是不是真实业务文档，输出的是不是能直接驱动下一步业务动作的结构化结果。
出路：FDE，深入业务、为结果负责
Palantir 用 FDE（Forward Deployed Engineer，前沿部署工程师）模式回答过同样的问题：面对高度非标、教科书里没有的场景，标准化产品卖不动，唯一有效的方式是让工程师进驻客户现场，在真实业务里把系统打磨到能用、敢用、为结果负责。
OnlyFDE 的名字正来自这个理念。我们相信工业 AI 没有「开箱即用」：SOR 的读法、公差的处理方式、条款的风险分级，每一家企业都不一样。正确的姿势是深入客户业务，把行业知识、校验规则和文档处理管线一起工程化，并且对最终结果负责——不是交付一个模型，而是交付一个敢在真实业务里运行的系统。
判断框架：先问三个问题
不管你是自研还是选供应商，面对一个工业 AI 方案，先问三个问题：
- 读得准吗？在你的真实文档上实测，不是演示样本。漏一条强制性条款的后果谁来承担？
- 错了能接管吗？低置信度的内容有没有显式标记？人能不能在流程中随时介入、修正、回退？
- 经验能沉淀吗？每一次人工修正有没有变成系统的规则与知识，下次同类文档能不能自动处理？
- 三个问题都答得好的方案，大概率跨过了「非标」门槛；答不上来的，演示再漂亮，也进不了工厂。