如果是软件公司，大家很自然会从知识库、RAG、Copilot、Agent、工作流这些词开始。但放到我们自己的业务里，这套顺序很容易跑偏。

我们不是一家纯 IT 软件公司。

我们交付的不是一个网页，也不是一套后台系统，更不是“上线即可交付”的 SaaS。我们的业务更接近仓储物流自动化设备交付：方案设计、设备配置、图纸、BOM、采购、生产、发货、现场安装、调试、KPI、验收、回款，任何一个环节出问题，都会变成真实成本。

所以，AI 化的第一步不应该是“先做一个能聊天的机器人”。

聊天框可以做，知识库也可以做，但它们不是第一矛盾。第一矛盾是：一个项目从合同签订到最终验收回款，中间每一步到底有没有被系统化地看见。

对我们来说，一个项目至少有四条线：

设计线：方案、配置、图纸、变更。
供应链线：BOM、采购、到货、齐套、生产、发货。
现场线：安装、调试、KPI、验收、问题闭环。
商务线：收款节点、开票、回款、成本和损益。

这四条线不是并行写在 PPT 上就结束了。它们每天都在互相影响。

配置一改，BOM 可能要重算。
BOM 一变，采购周期可能变。
采购晚到，生产排期会变。
生产延期，发货计划会变。
发货晚了，现场安装窗口会变。
现场延误，KPI 测试和验收节点会变。
验收推迟，开票、回款和项目利润都会被影响。

这就是设备工程交付和纯软件交付的根本不同。

软件项目也怕需求变，但设备工程项目更怕“实物状态没有被看见”。一个零件晚到，一个定制件返修，一张图纸版本错用，一个现场安装条件不满足，都可能让纸面利润变成真实损耗。

所以我们谈 AI，不能先问“AI 能回答什么”，而要先问“AI 能不能帮我们提前看见项目链条哪里要断”。

我会把第一阶段定义成：项目可见性。

不是炫酷大屏，而是系统真正能回答这些问题：

这个合同现在处于什么阶段？
设计配置是否冻结？
当前图纸版本是不是最新？
BOM 是否已经完整拆出？
哪些物料已采购，哪些还没下单？
哪些长周期件会影响生产？
哪些到货异常会影响发货？
生产装配是否按项目计划推进？
现场安装需要的设备、人员、工具、备件是否齐套？
KPI 验收条件是否已经确认？
收款节点和交付节点有没有对齐？
这个项目的真实损益有没有被看见？

这些问题表面上不像 AI 问题，但它们决定 AI 能不能落地。

如果这些问题没有被系统回答，AI 接进去很容易变成另一个“聪明但不落地”的工具。它可能能写周报、总结会议纪要、生成方案描述，但项目该延期还是延期，BOM 该错还是错，到货该没人盯还是没人盯，现场该救火还是救火。

我们要警惕一种软件公司式 AI 幻觉：以为只要把知识库、聊天框、Agent 做出来，公司就 AI 化了。

不是。

对我们这样的设备工程交付公司来说，AI 化的第一张门票不是知识问答，而是项目主数据。

项目对象要清楚。
配置对象要清楚。
BOM 对象要清楚。
采购对象要清楚。
到货对象要清楚。
生产对象要清楚。
发货对象要清楚。
现场任务对象要清楚。
验收对象要清楚。
收款对象要清楚。

没有这些对象，AI 没有地方落脚，只能漂在聊天框里。

更准确地说，AI 的价值不在于替人“拍脑袋”，而在于基于项目链路做辅助判断：

提醒哪些物料会拖累发货。
发现哪些配置和 BOM 不一致。
总结哪些项目反复因为同类物料延期。
提示现场安装前置条件是否缺失。
把会议纪要里的变更同步到配置、BOM、采购和商务影响。
帮助项目经理生成真实的项目风险报告，而不是格式正确但没有用的周报。

这才是我们需要的 AI。

它不是先长成一个聊天框，而是先长成一条能看懂“合同 -> 设计 -> BOM -> 采购 -> 生产 -> 发货 -> 现场 -> 验收 -> 回款”的项目系统。

等这条链路跑起来，聊天框才有意义。

因为那时候用户问“这个项目为什么可能延期”，AI 才不是在猜。它能看到设计是否冻结，BOM 是否齐套，采购是否到货，生产是否排期，现场是否具备安装条件，验收节点是否被影响。

没有项目链路的 AI，只是会说话。

有项目链路的 AI，才可能真正进入我们的业务。

设备要运到客户仓库，要安装，要调试，要跑 KPI，要验收。海外项目还会叠加运输、人工、安装窗口、沟通成本和现场不可控因素。这些当然都难。

但如果从经营视角往前追一层，很多现场问题并不是现场才产生的。

它们更早发生在 BOM、采购、到货、齐套、生产、发货这条供应链线上。

某个关键物料采购晚了，现场就要等。
某个定制件版本错了，到现场才发现装不上。
某个供应商交期不准，生产只能临时调整。
某个图纸变更没有同步到 BOM，采购买回来的不是最新配置。
某个项目为了赶发货临时替代物料，但替代影响了调试和验收。
部分设备先到了，配套件没到，现场无法完整安装。
运输计划和现场窗口没对上，客户仓库腾不出安装条件。

这些表面上是现场问题，本质上往往是供应链问题在现场爆发。

所以我们不能只把现场当成救火点。更应该把现场之前的链路做成预警点。

一个软件模块没写完，可以临时加人加班。一个物料没到，很多时候加班也没有用。图纸错了，也不是改一行代码就能“热修”：要重新确认、采购、加工、运输、安装，时间和成本都会真实发生。

所以 SCS 的核心不应该只是采购台账，而应该围绕“项目齐套”重构。

采购不是目的，齐套才是目的。

项目经理真正关心的不是“采购单有多少张”，而是：

这个项目能不能按计划发货？
如果不能，是哪些物料卡住？
这些物料属于长周期件、标准件、定制件，还是变更件？
它们影响哪个设备、哪个模块、哪个现场安装节点？
有没有可替代方案？
替代会影响成本、性能、KPI、验收还是售后？
谁有权批准替代？
替代后是否回写图纸、BOM、采购、生产和项目损益？

这才是设备工程公司的供应链智能。

传统采购系统容易站在采购部门视角看问题：供应商、询价、下单、到货、付款。我们更需要从项目交付视角看采购：这个物料不只是一个采购项，它是某个项目、某个配置、某张图纸、某个设备模块、某次现场交付的一部分。

如果系统只知道“物料 A 未到货”，价值有限。真正有价值的是系统能继续告诉我们：

物料 A 未到货，会影响项目 X 的第 2 批发货。
它对应某台设备的某个模块。
如果晚 3 天，会压缩生产装配窗口。
如果晚 7 天，会影响客户现场安装计划。
如果替代，需要工程、采购、商务共同确认。
如果不替代，项目可能延期，并影响某个收款节点。

这就是 SCS 应该做的事。

AI 在这里也不是万能采购员。它不应该直接替人改供应商、改物料、改交付承诺。但它可以成为供应链线上的风险放大器和决策助手。

它可以基于历史项目识别哪些物料经常成为瓶颈。
它可以在方案配置变更时提示 BOM 是否需要重算。
它可以比对图纸版本、配置清单和采购清单是否一致。
它可以把供应商交期、历史准交率、当前库存、生产排期放在一起，生成项目齐套风险。
它可以提醒项目经理：这个项目表面上采购进度正常，但某几个关键件会拖住整机发货。
它可以总结供应链会议纪要，并把行动项落到具体物料、负责人和时间。
它可以帮助商务看到：某个采购变更是否正在侵蚀项目利润。

这里最重要的是“影响链”。

设备工程公司怕的不是单点异常，而是不知道异常会影响哪里。

一个采购延期，如果不影响项目发货，它只是采购问题。
一个采购延期，如果影响生产装配，它就是生产问题。
一个采购延期，如果影响现场安装，它就是客户交付问题。
一个采购延期，如果影响验收节点，它就是回款问题。
一个采购延期，如果导致加急采购、替代料、现场等待、二次进场，它就是利润问题。

这就是为什么供应链线必须和设计线、现场线、商务线连起来。

BOM 不能只属于工程。
采购不能只属于采购。
到货不能只属于仓库。
生产不能只属于生产。
发货不能只属于物流。
它们都属于项目。

我会把 SCS 第一阶段的供应链指标压到四个：

第一，项目齐套率。不是仓库总体库存，而是某个项目、某批发货、某次安装所需物料是否齐。

第二，关键件风险。哪些物料影响路径最长，哪些供应商风险最大，哪些变更最可能导致延期。

第三，变更影响范围。配置一改，影响哪些 BOM、采购单、库存、生产计划、现场节点和商务成本。

第四，供应链对损益的影响。延期、替代、加急、返工、二次发货、现场等待，最终都要回到项目利润。

如果这四个指标跑起来，SCS 就不是一个后台软件，而是项目交付的雷达。

我们的设备方案本身就有大量组合：格口、上包台、扫描方式、拓展模块、定制料箱、现场布局。配置越多，越不能只靠人脑记忆和 Excel 追踪。

因为每一个配置背后，都是 BOM、供应商、生产、运输、现场和验收。

AI 真正有价值的地方，不是让它写一篇采购总结，而是让它帮我们看见：哪些项目会因为供应链链路不清而翻车。

少一次缺件。
少一次现场等待。
少一次加急采购。
少一次图纸版本错用。
少一次发货后才发现配套不齐。
少一次项目经理靠群消息到处追。
少一次利润被隐性损耗吃掉。

这比任何“智能问答”都更接近我们的核心经营。

对软件公司来说，FDE 可能是把模型、Agent、数据和客户流程接起来的人。对我们来说，更准确的说法应该是：把合同、设计、供应链、现场、商务全部翻译成项目交付系统的能力。

这不只是懂 AI。

它首先要懂设备工程交付。

我们的项目经理、方案工程师、交付负责人、供应链负责人，其实天然就有一部分 FDE 能力。因为他们每天面对的不是抽象需求，而是实物交付：

客户要什么业务能力。
方案配置怎么定。
图纸怎么出。
BOM 怎么拆。
供应商怎么交。
生产怎么排。
设备怎么发。
现场怎么装。
KPI 怎么跑。
客户怎么验。
款怎么收。
利润怎么保。

能把这些线串起来的人，比很多只会讲 AI 的人更接近真正的企业 AI 落地。

但这里也有一个风险：我们很容易把这种人用成救火队。

客户现场有问题，去现场。
设计和采购对不上，去协调。
生产缺料，去催。
发货计划变了，去解释。
安装调试出问题，去盯。
KPI 跑不出来，去想办法。
验收卡住，去沟通。
回款慢了，去补材料。

如果只是这样，再强的人也会被项目消耗掉。

所以我们需要的 FDE，不应该只是“谁都找他”。更准确地说，我们需要把 FDE 能力沉淀成系统能力。

第一，项目对象定义能力。

合同签了以后，不能只靠项目经理脑子里知道这个项目是什么。系统里必须有清楚的项目对象：客户、场景、配置、设备数量、格口数量、上包台、扫描方式、定制料箱、现场限制、KPI 指标、验收节点、收款节点。

这个对象定义不清，后面所有线都会乱。

设计觉得自己出了方案。
采购觉得自己按 BOM 买了。
生产觉得自己按计划做了。
现场觉得自己按设备安装了。
商务觉得自己按合同节点收款。
每个人都可能是“对的”，项目却仍然是错的。

第二，边界定义能力。

设备工程项目里，边界非常重要。

什么是标准配置，什么是客户定制。
什么变更属于合同范围内，什么要走商务变更。
什么替代料可以接受，什么必须重新评审。
什么现场条件由客户提供，什么由我们负责。
KPI 测试前置条件是什么。
验收失败是设备问题、现场条件问题、操作问题，还是业务流程问题。

这些边界如果不清楚，项目会变成无止境的“再帮客户处理一下”。

软件项目需求边界不清，会拖进度；设备工程项目边界不清，会同时拖进度、拖成本、拖库存、拖人员、拖回款。

第三，沉淀能力。

一个项目救火成功，不等于公司能力提升。

真正有价值的是把这次项目里的经验沉淀下来：

某类客户场景适合什么配置。
某类项目 BOM 容易漏哪些物料。
某类供应商交期风险大。
某类现场条件必须提前确认。
某类 KPI 验收容易卡在哪里。
某类配置变更会影响哪些成本。
某类海外项目运输和安装需要提前准备哪些材料。

这些内容如果只停留在个人经验里，公司下一次还是从零开始。

所以我会把我们的 FDE 能力分成四层。

第一层，方案翻译。把客户业务场景翻译成设备配置和交付边界。电商、零售、快递、3C、冷链，每个场景的分拣对象、吞吐要求、准确率、占地、上包方式、格口设计、扫描方式都不同。

第二层，工程拆解。把方案配置翻译成图纸、BOM、采购、生产、测试和发货计划。这里不能只会讲方案，必须理解配置变化如何影响实物链。

第三层，现场闭环。把安装调试、KPI、验收问题翻译成可追踪的任务和责任，不让现场问题只停留在微信群和个人经验里。

第四层，模式沉淀。把项目经验反哺到产品、配置模板、BOM 模板、供应商策略、安装 checklist、验收标准和商务报价模型。

如果我们要做 AI，最有价值的不是做一个“AI 项目经理”取代人，而是做一个能增强这些 FDE 型人才的系统。

AI 可以帮项目经理看风险，但不能替项目经理承担承诺。
AI 可以帮工程师比对配置和 BOM，但不能替工程师确认最终方案。
AI 可以帮供应链识别缺件影响，但不能随便替换物料。
AI 可以帮现场总结调试问题，但不能替代安全和验收责任。
AI 可以帮商务识别损益异常，但不能替公司决定让利。

这种边界很重要。

我们不是要把人拿掉，而是要把人的判断放到系统里，让它可见、可复用、可复盘。

设备工程公司的核心竞争力，不只是设备本身，也包括项目交付能力。很多客户最后记住的不一定是某个功能参数，而是你能不能按期交付，能不能跑通 KPI，出了问题能不能解决，验收和回款能不能顺利。

所以我们需要的 FDE，不是驻场救火的人。

它应该是一种组织能力：把客户场景、设备配置、供应链齐套、现场安装和商务回款串成一个交付系统。

如果 SCS 能成为这类人的工具，而不是又一个让他们填表的系统，我们的 AI 化才会有真正的根。

这些词在软件产品里有用，但如果直接拿到我们内部，可能会显得太 IT。对设备工程交付公司来说，可信链路不能只停在“答案有没有引用”。它必须落到更硬的东西上。

我们的 source，不只是文档来源，而是合同、方案、配置清单、图纸、BOM、采购单、供应商承诺、到货记录、生产记录、发货单、现场安装日志、调试记录、KPI 测试数据、验收单、发票、回款记录。

我们的 state，不只是“处理中/已完成”，而是设计是否冻结、BOM 是否齐套、采购是否下单、物料是否到货、生产是否开工、设备是否发货、现场是否具备安装条件、调试是否完成、KPI 是否达标、验收是否通过、款项是否回收。

我们的 citation，不只是“这句话来自哪份资料”，而是“这个判断依据哪张图纸、哪个 BOM 版本、哪条合同条款、哪个供应商交期、哪次现场测试、哪份验收记录”。

我们的 action log，也不只是 AI 调了哪个工具，而是“谁改了配置，谁确认了 BOM，谁批准了替代料，谁变更了交期，谁确认了发货，谁记录了现场问题，谁确认了 KPI，谁触发了开票”。

这才是设备工程公司的真实链路。

如果这条链路做不起来，AI 再聪明也不敢用。因为设备工程里的很多判断会产生真实成本。

一个配置判断错了，可能买错物料。
一个 BOM 版本错了，可能生产错设备。
一个到货状态不清，可能现场缺件。
一个安装前置条件没确认，可能人员白跑。
一个 KPI 口径不清，可能验收扯皮。
一个收款节点漏跟，可能现金流被拖。

所以 SCS 不应该只做“信息登记”，而应该做“项目证据链”。

每一个项目状态，都应该能回答三个问题：

现在为什么是这个状态？
依据是什么？
下一步谁负责？

比如“BOM 已齐套”。

这句话不能只是一个勾选框。系统应该能看到：齐套依据是哪版配置清单、哪版图纸、哪些 BOM 行、哪些库存、哪些采购到货、哪些替代料批准记录。如果后来项目出问题，能追溯当时为什么认为齐套。

比如“可发货”。

这也不能只是物流说一句可以发。它应该同时检查：设备是否生产完成，配套件是否齐，包装是否完成，海外项目是否准备好运输和清关材料，现场安装窗口是否确认，客户收货条件是否满足，商务节点是否允许发货。

比如“现场可安装”。

这不是项目经理一句话。它应该包含：设备到货、现场空间、电源网络、地面条件、客户人员、施工许可、安装工具、备件、工程师排班、风险事项。

比如“KPI 可测试”。

它应该包含：测试口径、样本类型、吞吐量要求、准确率要求、异常处理方式、客户见证人、测试时间、测试记录。

这些状态一旦有证据链，AI 才能真正发挥作用。

AI 可以在项目周会上自动总结风险，但它必须引用具体物料、具体采购单、具体图纸版本、具体现场日志。AI 可以回答“这个项目为什么延期”，但它必须能指向：设计变更、供应商延期、生产排期、现场条件、客户验收口径里的哪一个。AI 可以建议“这个项目要重点盯”，但它必须说清楚，是因为关键件未到、发货窗口临近、回款节点绑定验收，还是项目毛利被加急成本侵蚀。

没有证据的 AI，只是会写。

有证据链的 AI，才是项目管理能力。

我觉得 SCS 可以从四个看板开始，但每个看板都不能只是展示，而要能追溯。

第一，设计配置看板。

显示每个项目的方案、配置、图纸状态。重点不是“图纸上传了没”，而是配置是否冻结，变更是否影响 BOM，图纸版本是否和采购、生产一致。

第二，供应链齐套看板。

显示项目级 BOM、采购、到货、生产、发货状态。重点不是采购台账，而是某个项目、某批发货、某次现场安装所需物料是否齐套，哪些物料会影响关键路径。

第三，现场交付看板。

显示安装、调试、KPI、验收状态。重点不是记录现场日志，而是把现场问题和设计、供应链、客户条件、验收口径关联起来。

第四，商务损益看板。

显示收款节点、开票、回款、成本变化、项目毛利。重点不是财务报表，而是让项目过程里的变更、延期、加急、返工、二次进场都能回到损益。

这四个看板连起来，我们才真正拥有项目链路。

这时候 AI 才适合进来。

AI 可以做项目风险解释。
AI 可以做配置-BOM 变更影响分析。
AI 可以做采购齐套预警。
AI 可以做现场问题归因。
AI 可以做验收资料自动整理。
AI 可以做项目复盘，总结哪些损耗来自设计、供应链、现场还是商务。

但所有这些都建立在真实链路之上。

我们的 AI 产品不是为了让内部多一个聊天窗口，而是为了让项目经理、工程、采购、生产、现场、商务看到同一条项目事实链。

这条链路一旦跑通，公司很多管理问题会变得更清楚：

到底是设计变更太多，还是采购响应慢？
到底是供应商交期不准，还是 BOM 拆解不完整？
到底是生产排期问题，还是项目齐套问题？
到底是现场条件没确认，还是设备交付质量问题？
到底是验收口径不清，还是 KPI 没跑出来？
到底是项目本身报价低，还是过程损耗吃掉了利润？

这才是我们应该追求的 AI 化。

不是让 AI 替公司说话，而是让公司第一次真正看清：一个设备工程项目，从合同到回款，中间每一步到底发生了什么。

对我们来说，可信 AI 的底座不是模型，而是项目事实链。

配置、BOM、采购、到货、生产、发货、安装、KPI、验收、回款。

这十个词，比任何 Agent 口号都重要。