工业企业一个简单数字化需求，往往要经历业务部门提需求、IT部门梳理、外部团队开发和多轮现场修改。当几个月后系统终于交付时，业务需求可能已经发生变化。更小、更碎的场景，则常常因为开发成本过高，根本没有机会被数字化。
AI正在改变这种工业软件交付方式。按照寄云科技当前的实践，基于一份相对完整的PRD和设计文档，AI可以在约30分钟内生成应用原型，并在一周左右在现场部署完成。但这只是表层变化，真正的难题，是怎样让AI理解异构数据、非标系统、企业SOP、工艺知识和业务规则。
寄云科技创始人兼CEO时培昕将工业智能体平台的核心归纳为“本体+技能”：本体负责组织来自不同系统的数据，技能承载解决问题的方法和业务逻辑。平台不用先治理企业全部数据，而是从具体问题出发，先生成技能，再由技能规划本体和所需数据。
时培昕此前参与过数百个工业数据分析和应用开发项目，长期的定制化交付经历，让时培昕重新思考工业软件的开发与实施模式：AI降低代码门槛以后，需求理解、私域知识和业务型FDE反而成为更稀缺的能力。
围绕工业智能体架构、应用开发、长尾数字化和FDE交付，爱分析与时培昕展开了交流，以下为访谈实录。
核心观点
本体负责组织数据，技能决定AI如何解决问题。企业SOP、工艺模型和业务规则，必须转化为AI可执行的技能。
工业本体应从具体问题出发生成。先定义问题和技能，再由AI规划本体并寻找所需数据。
工业私域知识，给专业厂商留下至少五年窗口。场景高度碎片化，基础模型厂商难以仅靠模型和通用FDE模式覆盖工业市场。
长尾数字化是工业智能体最先释放的价值。工艺数据分析、质量追溯和实时监控等碎片化需求，正在获得低成本落地机会。
FDE决定工业智能体能否规模化落地。代码能力退居次位，业务理解、技能沉淀和生态交付成为核心。
01本体组织数据，技能承载业务逻辑
爱分析：寄云最近推出了工业智能体平台，进展和反馈怎么样？
时培昕：最近两个月，我密集跑了三四十家客户，绝大多数客户第一次看到产品时，都觉得耳目一新。
我们的设计理念归结起来主要有两点：一个是本体，一个是技能。这套逻辑与Palantir的本体体系不完全一样。Palantir本体很强，但是高度依赖熟悉Foundry的FDE工程师，而对AI的使用相对保守。
爱分析：工业企业使用智能体，首先需要解决什么问题？
时培昕：首要问题是对接私有数据和非标业务系统，还要处理主数据、元数据等问题。更重要的是，AI怎样理解企业内部的规章流程、SOP、专业知识和私域知识。
工业客户还非常关心敏感数据，即使规模不大的企业，也会担心自己的工艺数据、量测结果和内部文件上传以后，变成公开知识。
国内很多企业使用Dify、Coze等工具，手工搭建工作流，开发ChatBI、智能客服和知识问答。这种模式本质上仍然是IT部门完成开发，再交给业务部门使用，不但周期长、效率低，更大的问题是，当IT人员不知道业务问题怎样解决时，需要花很长时间把业务逻辑转换成工作流，这种模式很难让业务人员随时提出问题、立即验证想法。
爱分析：为什么这个问题在工业领域更加突出？
时培昕：工业底层有大量结构化、非结构化和实时数据，而且大部分系统都是非标的。不同部门按照各自专业建设系统，最初没有考虑互联互通，所以才需要本体组织这些数据。
工业企业的大量工作由流程、知识和规则驱动。以设备故障诊断为例，大模型通常只能给出FMEA等通用方法，但每家企业都会针对特定设备建立自己的故障诊断流程。这些流程属于企业私域知识，大模型天然无法获取。
工艺优化也是一样。少量化学、物理等通用知识，大模型可能具备，但大量业务逻辑来自企业长期积累的工艺模型、工艺路线、作业指导书和计算书。
还有一些知识更加碎片化，例如故障特征的提取和识别，以及基于规则的数据处理。人需要经过长期训练才能成为专家，但相关知识往往分散在专业文献、企业知识库和专家经验中。
如果不能把这些知识与企业数据结合起来，智能体能够解决的仍然只是知识问答或者有限范围的报表问题。
爱分析：在寄云的平台中，本体主要承担什么作用？
时培昕：我把本体看作底层能力，主要使用Ontology中的Data视图，组织和管理来自不同系统的异构数据。
本体需要说明数据从哪里来、实体之间有什么关系、分析结果写到哪里。比如进行根因分析，需要哪些数据，这些数据来自SCADA的哪些字段、ERP的哪些表格，最终形成什么结果，写到哪里去，这些由本体描述。
Palantir会在本体中同时强调Data、Logic和Action，必须有非常熟悉Ontology的FDE工程师才能实施。寄云的处理方式不同，我们主要把Logic和Action放在技能层，用自然语言来描述。
爱分析：技能与本体是什么关系？
时培昕：技能是一套解决问题的方法，告诉AI一件事情应该怎样一步一步完成。
企业原来使用过的算法、标准SOP、知识文档、作业指导书和计算书，都可以被转化为技能。技能承载业务逻辑、决策关系和执行方法，再结合大模型的通用推理能力，指导AI完成具体任务。
并不是所有数据都必须进入本体。一些碎片化文件和表格，可以直接被技能调用。对于需要跨系统关联的数据，再通过本体完成组织。
所以，本体解决的是AI怎样理解和找到数据，技能解决的是AI拿到数据以后应该怎样做。工业智能体能否真正解决问题，关键就在这两层能不能建立起来。
02先定义问题，再让AI生成本体
爱分析：寄云构建本体的路径，与传统数据治理有什么不同？
时培昕：我们不是先把企业全部数据整理好，再从数据里寻找应用，而是从问题出发。
首先让AI规划解决这个问题需要什么技能。技能确定以后，再按照实体、属性和OWL等约束生成本体。本体会说明需要哪些数据、数据从哪里来、结果是什么，最后再连接数据库表、文件、SCADA和ERP等数据源。
所以，它是一条“问题—技能—本体—数据”的路径，是从应用向下寻找数据，而不是从数据向上寻找应用。
爱分析：这跟之前的数据分析路径完全不一样，为什么会选择这条路线？
时培昕：我们做了十多年工业数据项目，大约做过三四百个数据分析项目、两三百个应用开发项目。
过去的项目基本都很被动，客户提出需求以后，我们先读大量的专业文献，研究问题应该怎样解决，再与客户反复沟通。两三个月后做出一个原型，客户可能会说完全不是他想要的，只能推翻以后重新做。
我们一直在思考，这种高度定制、一次性的工业项目，能不能用AI提高效率。
真正从用户角度出发，业务人员应该能够随时提出问题，用一个可信赖的AI工具快速验证，而不是先找IT团队，再等待漫长的需求分析和开发周期。
爱分析：能否用一个具体场景说明这套过程？
时培昕：比如太阳能电池片切片工序中的断线预测。
客户提出这个问题后，平台会先判断现有技能库中是否有匹配技能。如果没有，AI就创建一个新技能，规划需要哪些输入、输出、评价标准、样例数据和分析脚本。
技能会进一步明确需要哪些测点，例如线速度、张力、电流和振动等工艺参数。这些测点再对应到SCADA字段、ERP表格和相关文件中。本体则把设备、数据、事件和结果之间的关系组织起来。
我们还可以让AI先生成模拟数据，对技能进行初步验证。这样不需要一开始就接入客户全部真实数据，也能很快生成分析结果。
爱分析：AI生成的技能和本体，准确率怎样保证？
时培昕：首先取决于技能是否准确。
客户提出了问题，通常也知道这个问题应该怎样解决，只是他不懂算法、不懂开发。平台先用模拟数据生成报告，客户或者业务专家可以判断结论是否合理。如果缺少某个因素，或者指标设计不对，可以通过对话直接修改技能，补充指标和评价标准。
平台分为开发和使用两个阶段。开发阶段主要由业务专家确认技能是否可靠；使用阶段再按照技能要求生成本体，与实际数据源完成匹配。
最终，一线用户只需要创建智能体，挂接对应的本体，再调用技能分析数据。专家负责把解决问题的方法开发出来，一线人员负责使用。
爱分析：每个问题生成一套本体，会不会影响跨场景复用？
时培昕：工业首先就是一个高度碎片化的市场。不同设备、工艺和企业面对的问题都不一样，所以我们现阶段优先解决具体场景。
这种方式确实会产生很多不同本体，也会带来跨场景复用的问题。我们还在考虑怎样处理，但已经看到一些共性，例如设备编码、物料编码、生产计划和状态参数。这些可以从不同场景中提取出来，再沉淀为主数据层。
问题驱动的好处是效率高。传统方式需要人先理解大量数据，再一点点扩大范围，很容易受到个人知识边界限制。AI可以按照场景目标，系统规划需要哪些数据。
即使企业当前没有某项数据，也能提前发现：是需要增加一个采集系统，还是增加一个录入环节。AI不只是连接已有数据，也可以帮助企业发现解决问题还缺什么数据。
这条路线不追求一次建立覆盖全公司的完美本体，而是先快速解决具体问题，再从多个场景中逐步沉淀共性。
03 AI写代码能力越强，需求描述越重要
爱分析：除了数据分析类，寄云的平台也能构建工业应用？
时培昕：对。平台底层可以连接寄云原来的数据治理平台和IoT平台，上层包括本体、技能、工作流、大模型推理、应用生成和发布等能力。
我们的核心能力基本都是自己开发的，没有直接采用Dify、Coze等开源工具。最近上线的一项重要能力，就是AI应用开发系统。
爱分析：这套系统怎样开发应用？
时培昕：我们最初希望完全基于本体开发应用。例如开发一套电力交易系统，先根据PRD生成技能和本体，再由本体驱动应用开发。
实践以后发现，这条路径生成的应用数据结构比较完整，但功能性不够。页面更多是表格、数据录入和统计，AI对新增功能、交互流程等方面的规划受到本体结构限制。
后来我们调整了路径：先把客户需求整理成PRD，再生成概要设计和详细设计，由这些文档指导AI开发应用。这样生成的系统既有数据，也有更完整的业务功能。应用生成以后，再把数据结构与现有本体库结合。这条路线目前效果更好。
爱分析：这对传统定制软件开发会产生多大影响？
时培昕：我认为传统定制开发模式会受到巨大冲击。
过去开发一套MES、APS或者类似的工业应用，可能需要投入两三百万元，开发周期也比较长。按照寄云目前的阶段性实践，有了PRD和详细设计文档以后，平台大约30分钟可以生成原型，并在一周左右完成客户现场部署。
从模型调用成本看，生成应用可能只需要几百万Token，直接成本很低。甲方如果能够把需求描述清楚，很快就可以看到系统原型，就很难再接受花几十万元甚至数百万元、等待几个月的传统开发方式。
当然，这些效率数据来自平台推出初期的项目实践，还需要在更多复杂场景中持续验证。
爱分析：PRD文件由谁来写？
时培昕：很多PRD文件也是由AI生成的。
客户可能先提供一份需求材料，列出需要哪些功能、每项功能的描述和优先级。平台可以把这些内容整理成完整PRD，再交给客户确认。
客户需要判断哪些功能应该增加，哪些应该删除，业务流程和字段是否符合实际。确认以后，再把PRD转成详细设计文档，交给AI生成应用。
所以，AI可以完成需求整理和文档编写，但客户和产品经理仍然要负责确认和纠偏。
爱分析：AI能够直接开发以后，还需要PRD吗？
时培昕：我认为需求描述反而变得更加重要。需求越清晰，AI理解得越准确。复杂应用仍然需要一个结构化、可确认的需求基线。
软件开发本身有一套逻辑：先明确需求，再做概要设计和详细设计。过去这些环节主要由人完成，现在可以由AI辅助生成，但不能让AI只根据零散信息猜测整个系统。
爱分析：产品经理这个角色还有必要？
时培昕：产品经理的工作重点会从写文档、传递文档，转向判断需求是否完整、业务逻辑是否正确，以及生成的系统是否真正解决客户问题。AI降低的是编码和文档生产成本，并没有降低对业务判断的要求。
04工业智能体激活长尾数字化需求
爱分析：寄云最擅长生成哪一类工业应用？
时培昕：从寄云原来的能力看，我们最擅长的肯定是数据分析。我们做了十多年工业数据项目，这一直是老本行。我们开发智能体平台的初衷就是提高数据分析的效率，让用户自己就能不借助算法工程师的帮助就能自己分析各种工艺、质量、能耗、设备故障等问题。
但平台推向客户以后，我们发现，给客户冲击最大的是30分钟就能生成一套MES原型。
很多工业企业仍然存在大量传统数字化需求，例如信息录入、质量追溯、设备监控和生产管理。这些需求通常比较碎片化，场景小、变化快，过去用传统软件开发方式很难解决。
所以，不是企业没有需求，而是单独为一个小场景建设系统，成本和周期都不划算。AI把开发门槛降下来以后，这些长期被搁置的需求开始具备落地条件。
爱分析：传统数字化需求在客户需求中占多大比例？
时培昕：按照我们目前观察，中等规模客户大约80%的需求是应用开发，20%是数据分析。
他们最直接的诉求仍然是：原来没有这套系统，现在希望快速建设一套。过去需要采购软件或者委托外部团队开发，现在有机会在平台上自己完成。
对于数字化基础更好的中大型客户，应用开发和数据分析需求可能各占一半。除了碎片化应用，他们还希望围绕具体场景开展预测、诊断和优化。
爱分析：客户能够自己使用平台开发应用？
时培昕：应用开发相对容易，经过一两天培训，就可以开始尝试。
我们服务一家阀门企业时，最初计划帮助客户建设质量追溯系统。经过两三天培训后，客户已经开始自己使用平台开发质量监控的应用。
还有一家无锡客户，只听过我们的公开课，没有接受专门培训，就自行完成了比较复杂的数据分析。这类客户本身数字化能力很强，对数据、业务和系统都有较好的理解。
但也有一些中大型客户，需要我们手把手辅导。工具是一样的，能否自主使用，很大程度上取决于甲方原有的数字化水平和团队能力。
爱分析：为什么应用开发比数据分析更容易上手？
时培昕：应用开发的核心是把需求描述清楚。客户知道要哪些功能、有哪些字段、业务流程怎样运行，AI就可以帮助生成应用。
复杂的数据分析是另一回事。使用者不仅要理解问题，还要理解技能、本体、数据源以及分析结果之间的关系。现有数据能不能支持分析、缺少哪些指标、结果是否符合工艺逻辑，都需要更专业的判断。
所以，应用开发经过短期培训可能就能使用，但复杂数据分析仍然需要专业人员辅导。
爱分析：未来所有工业客户都能自己建设应用吗？
时培昕：我认为所有客户都可以使用这类工具，但使用深度会不同。
这就像所有人都会使用Excel，但不是所有人都会使用函数和宏。基础功能容易掌握，高级能力取决于使用者的知识和经验。
客户用得好，解决问题的效率和最终成果就会更好；用得不够好，就需要继续学习，或者由平台厂商和合作伙伴提供培训与支持。
工业智能体近期最直接的价值，不一定是替代专家做高阶决策，而是把过去不值得开发、来不及开发的长尾数字化需求，变成可以快速生成和持续修改的应用。
05 FDE，决定工业智能体能否规模化落地
爱分析：寄云采用怎样的交付模式？
时培昕：我们现在的FDE模式，与传统项目中的FDE已经不太一样。
交付人员到客户现场后，先帮助客户梳理需求、形成PRD，再由平台生成应用原型。客户判断哪些功能不符合要求，哪些字段与现有数据不匹配，FDE就现场修改需求描述并重新生成。
整个过程中，现场人员基本不需要写代码。只有遇到平台或工程问题时，后端工程师才会参与处理。
爱分析：与传统项目交付相比，最大的变化是什么？
时培昕：过去一个项目至少需要项目经理、前端和后端开发，项目经理还要懂代码、架构和系统设计。
现在，一个具备业务经验、咨询能力和实施能力的人，就可以承担前端交付。调整正确路径以后，大约半天就能搭出应用原型。
FDE不再负责把需求翻译成代码，而是把客户需求翻译成AI能够理解的输入。
爱分析：从原型变成生产系统，工程化问题怎样解决？
时培昕：一部分工作是数据接入，例如连接哪个数据源、使用哪张表，这是实施人员需要具备的能力。
另一部分是生成代码的健壮性、稳定性和出错概率。这不应该由每一名FDE单独解决，而取决于平台本身的工程能力。
FDE负责业务和现场，平台团队负责把重复出现的工程问题沉淀到底层。
爱分析：FDE需要具备哪些能力？
时培昕：FDE首先要懂业务，但不可能成为每个细分工艺的专家。工业场景太多，要求一个人熟悉所有行业并不现实。
更关键的是，他要理解平台怎样使用，能够把客户需求转化为准确输入，并纠正客户对AI能力的错误预期。
我们计划按照流程行业、离散行业和数据分析三个方向划分。离散行业的FDE最好做过MES、ERP实施或者咨询规划；流程行业更需要能源、设备可靠性和安全环保等经验。
目前寄云前端交付团队还不到10个人，主要由原来的项目经理和产品经理转型而来。原则上，一个客户由一名FDE负责，一个FDE可以支持3-5个客户。
爱分析：一名FDE负责3-5个客户，这种模式怎样扩大规模？
时培昕：不是所有的客户都需要FDE的全程支持。核心是把重复能力沉淀到平台，把行业方法沉淀成技能。
本体可以由技能生成。只要把解决问题的方法描述清楚，平台就能规划需要哪些实体、属性和关系。FDE不需要每次从头设计本体，而是调用和调整已有技能。
技能一定是平台的核心资产。我们正在规划技能市场和专家库，让行业专家贡献技能。后续还要解决技能审核、知识保护、权属和变现问题。
爱分析：商业模式也会围绕FDE和技能调整吗？
时培昕：我们希望以卖平台、卖工具为主，而不是长期依靠自己的团队承接所有定制项目。
寄云自己的FDE数量有限，不可能覆盖全部工业行业。真正熟悉客户业务的数科公司和行业伙伴，可以在寄云平台上为业务部门开发智能体。
寄云负责平台、技能体系和交付方法，合作伙伴负责更多行业和客户现场。只有这样，FDE模式才能规模化。
爱分析：基础模型厂商也在组建FDE团队，会不会替代工业智能体平台厂商？
时培昕：法律、金融和教育等行业，公域知识占比较高，基础模型厂商通过FDE进入相对容易。
工业不同。工业场景中的私域知识占主导，不同企业的设备、工艺和业务逻辑都不一样。要把这些知识转化成技能，再与本体和实际数据连接，仍然需要长期深入现场的业务型FDE。
工业市场还非常碎片化。同样投入一名FDE，在其他行业可能获得更高回报，工业项目的投入产出比未必有吸引力。专业厂商长期习惯做这些脏、难、碎的工作，反而愿意持续投入。
因此，我判断至少未来五年内，不会出现一家基础模型厂商进入工业以后，就把所有专业厂商替代掉的情况。
代码门槛降低以后，真正稀缺的不再是开发人员，而是能够理解工业业务、组织专家技能，并把需求准确交给AI的FDE。
精彩评论