信任链断裂：一个售前 AI 助手从 Demo 到废弃的完整复盘

做一个售前配置助手，听起来是一个天然适合大模型的任务。

客户说："我需要 20 台 6U 机架式服务器，支持 GPU 加速，万兆网络，能跑虚拟化。"

你有一整套产品手册、规格参数、选配清单。模型读进去，吐出一个配置单——CPU 型号、内存容量、网卡规格、电源功率，全部匹配客户需求。售前工程师拿过来跟产品手册比对，没错。下单。

然后配置单进了生产系统。

然后生产线的电话打回来了。

"这个内存条三个月前就停产了，AVL 里没有替代。"

"这个型号的 GPU 转接卡跟你们选的机箱不兼容，线缆长度不够。"

"物料拆到一半发现不齐套，缺高速线缆，这批要延期。"

这是同一个项目，同一个 Demo 跑出"看着都对"的结果。

现在，这个系统已经没人用了。连最基础的查询功能也起不来。

这是一个典型的、但不是偶然的失败。

它不是死在大模型不够强。它是死在信任链的构建方式上。

一、Demo 为什么能过？

因为这个系统的"验证"方式，在逻辑上是一次同义反复。

客户需求匹配的是什么？是产品手册里的描述。

售前工程师验证的依据是什么？也是产品手册。

模型输出"CPU：XXXX 型号，32 核，2.5GHz"。产品手册上查得到这个型号。售前工程师看了一眼，确认无误。通过。

这就是问题。

产品手册是什么？它在本质上是一份"应该能"的陈述，不是一份"我能"的陈述。它告诉你这个型号的 CPU 标称参数是多少，但它不告诉你这个 CPU 在当前采购周期里 AVL 状态是什么——有没有过认证、生命周期处于哪个阶段、替代料有没有准备好。

手册是静态的。AVL 是动态的。

手册是孤立的。而一套可生产的配置是耦合的——CPU 选了这个型号，对应的主板就得是那个型号，对应的散热方案就得是另一个，对应的线缆长度就不是通用的。

Demo 阶段验证的是"手册与手册一致"。这不是验证。这是两本同一来源的说明书在互相确认对方"写对了"。而当这个"来源"本身就不可靠——手册里有夸大宣传、有过时信息、有"理想工况"下才成立的参数——整个验证链条建立在沙滩上。

这个系统从第一天起就没有接触过真相。它接触的是真相的一个宣传版本。

二、产线为什么炸了？

因为产线接触的是物理世界。而物理世界不会替你"补全"缺失的约束。

一个配置单从"推荐"到"可生产"，中间要过多少道关卡？

AVL 校验。你选的那个内存条，供应商还在供货吗？样品测试过了吗？适配验证跑完了吗？这些不是静态属性，是一个持续演进的状态链条。任何一个节点的状态变了，整个器件的"可用性"就变了。

物料齐套。你列出来的物料清单，能不能在同一个采购周期内全部到位？有没有哪个部件还是"工程样品"阶段，交期是十六周？物料不齐套，生产线开不了工——这不是"规格问题"，这是"时间与供应链问题"。

兼容性耦合。选了一个大功率 GPU，机箱散热方案要不要改？功率预算还够不够？高速线缆的长度够得到背板吗？这些约束是跨部件的——改一个，等于改一串。

这个系统对这些关卡的处理方式是什么？

它没有处理。它把它们留给了"售前确认"。

售前工程师的确认，本质上是一个签字。他手里没有 AVL 查询工具，没有物料齐套计算引擎，没有线缆兼容性检查器。他唯一能做的，是用自己的经验和产品手册再做一次比对——而手册和 AVL 之间，隔着样品申请、测试验证、供应商认证、小批量试产整整一个流程的距离。

签字的人没有验证能力。有验证能力的人不在流程里。

这不是人的问题。这是架构把验证责任放在了验证能力够不到的环节。

三、为什么不只是"模型的问题"？

有人会听完这个故事后得出一个结论：模型不够强，需要更好的领域数据。

这个结论解释了问题的一小部分，但错过了问题的本质。

假设你把产品手册换成了 AVL 数据库，把参数表换成了实时物料状态，模型就能解决问题吗？

不能。因为 AVL 的验证不是一次知识查询，是一套需要执行的动作——查供应商状态、跑样品测试、做适配验证。这些东西不是"文本理解"能替代的。它们需要一个独立的、确定性的执行引擎。

再假设你用了最先进的多模态大模型，它能解释电路图、能读 BOM 表、能用 CoT 推理器件兼容性——它能解决问题吗？

还是不能。

因为一个配置的"可生产性"不是由单一推理路径决定的。它取决于多个外部系统的状态：ERP 里的库存、PLM 里的生命周期、供应商的交付承诺。这些状态的组合具有爆炸性的复杂度。一个概率系统试图在不完整的、动态的信息空间里做确定性的工程决策——它不是在解决问题，它是在赌博。

这个案例犯的错，不是"模型选错了"。而是在一个应该用 Harness 架构的场景里，选择了让 LLM 直接跑全程。

四、用 OPLA 做一次尸检

如果在这个项目第一天，有人用 OPLA 四要素来审视它，会看到什么？

O — Object。什么是"一个可交付的服务器配置"？

在项目的认知里，"配置"是一份参数列表。在物理世界里，"配置"是一套有 AVL 状态的、物料齐套的、兼容性自洽的、可被产线执行的 BOM。

这两个定义之间，差了一整套约束系统。

一个正确的 Object 定义应该是："一组通过 AVL 校验、物料齐套性检查、兼容性验证的器件组合。"如果这个定义在第一天就写下来了，立刻就会发现：系统推荐出来的东西，没有任何机制证明它满足这个定义。

P — Property。AVL 状态是一个属性吗？

如果是，它是什么类型？它是"可用/不可用"的布尔值？还是"已认证/样品阶段/EOL"的枚举？还是"需要 XX 部门签核"的工作流状态？

不管它是什么类型——在当前的系统里，它没有被建模。没有建模，就不参与计算。不参与计算，系统就不知道什么能选、什么不能选。

L — Link。配置里的器件之间，依赖关系是什么？

选了这个 CPU，主板就被约束了。选了主板，机箱就被约束了。选了 GPU，电源和散热就被约束了。这些关系不是"可选建议"，是物理与工程的确定性。

在 Demo 阶段，这些关系被隐藏在"产品手册描述"的语义近似里。到产线阶段，它们以"物料不齐套""线缆不够长"的方式报复回来。

A — Action。"验证这个配置是否可生产"是一个 Action 吗？

在项目设计里，它是售前工程师的一个点击确认。

在工程系统里，它应该是一组可自动执行的校验程序——AVL 校验、物料齐套校验、兼容性校验、交期可行性校验。每一项都是一个独立的、可由代码调用的 Action。全部通过，配置才叫"可用"。

四个要素，这个项目在每一个上都有缺口。而这四个缺口是互锁的——缺了 Object 的准确定义，Property 就建不对；缺了 Property，Link 就推不下去；缺了 Link，Action 就不知道要校验什么。

最后所有缺口在产线汇聚，以"改配置"的形式一次清算。

五、连查询也死了——这才是最该警惕的信号

一个很多人会忽略的细节：这个项目不仅推荐功能废了，连最基础的查询功能也起不来了。

为什么？

因为查询和推荐共享的是同一套数据。当推荐结果在产线被反复推翻之后，售前工程师对系统的信任就已经归零了。他不会说"推荐不行，但查询我还用"。他会说"这个系统不准"。

信任是不可切分的。

当你让 LLM 在一个不可靠的数据基础上做任何输出——不管是推荐、查询还是问答——用户不会去甄别"这次的结果是可验证的，那次的不行"。他们只会记住一件事：这个工具给出的东西，到产线可能会错。

一次错，就够了。

这就是为什么 Harness 框架反复强调一件事：LLM 只负责提出方案，不负责验证方案。 验证必须交给一个独立的、确定性的系统。不是因为 LLM 不可靠——是因为信任一旦被破坏，修复成本远高于建设成本。

六、这个案例的深层教训

大多数人听完这个故事，第一反应是"把数据做好就行了"——把 AVL 接进来，把 BOM 结构化，把兼容性规则写清楚。

这些都对，但不够。

这个案例的深层教训不在数据层，在架构层。它暴露了工业 AI 系统设计中最根本也最被低估的一个原则：

你的 AI 系统的可信度上限，不超过你的验证系统的可信度。

而验证不能由 LLM 自己完成。不能外包给"人看一眼"。不能被缩写成 Prompt 里的一句"请确保配置合理"。

验证必须是一个独立于模型的、可自动执行的、每一次都运行的硬节点。它不听解释，不接"差不多"，不因为上一个配置跑通了就豁免下一个。"约束没满足，就是没满足，输出必须打回去"——这句话我在 Harness 那篇文章里写过，而这个案例就是它的反证。

更残酷的一个判断是：如果你的验证系统不可靠，那么 AI 不仅不是资产，它是负资产。 因为它在以远高于人类的速度、在更广的覆盖面上，批量生产不可信的结果。

一个人做错一单配置，影响一个订单。一个 AI 做错一批配置——在没有独立验证的情况下——影响的是整条信任链。

七、如果重来一次

如果是我来重新设计这个系统，我会做三件事。

第一，把数据源从产品手册换成结构化工程数据。 不是把 PDF 喂给模型，而是把 AVL 状态、物料交期、兼容性约束、生命周期信息建模进本体。手册是表象，本体才是基础。

第二，把"推荐"和"验证"拆成两个独立系统。 LLM 只负责理解客户需求、生成候选配置方案。但方案能不能下到产线，由独立的约束求解和校验引擎说了算。AVL 状态、物料齐套、线缆兼容性——每一项都是一个硬校验。全部通过，配置单才允许流出。

第三，用 OPLA 建模整个配置域。 一个"配置"不是一个参数列表——它是一个 Object，带着可计算的 Property、可推导的 Link、可自动执行的 Action。定义清楚这些，系统才知道自己不知道什么。知道不知道，比假装知道，是更高一级的工程能力。

把一句话留在这个案例的结尾：

如果你的 AI 输出的东西，到产线还需要"再确认一遍"，那它的输出就不是工程结果。它是一个高级一点的搜索建议。

产线不需要建议。产线需要可执行的、一次对的、倒了能追责的决策。

作者提示：本文案例已脱敏处理，关键事实来自真实的工业 AI 项目复盘。讨论的是架构模式，不指向任何企业或产品。