如果你刚做完一个三维数字孪生项目场景、数据、动画都调试好了结果客户验收时问了一句“这个场景怎么切啊”“这个设备信息从哪里看”你会不会觉得前面白干了很多 CIMPro 项目在开发态做得花团锦簇一到发布态就露怯。原因不是建模不够精细也不是数据没打通而是最终用户根本没有办法理解你的操作系统。他们不是开发者不会看属性面板也不想去学配置逻辑。他们想要的是打开页面用一句话问到结果或者点一个按钮就把场景切过去。CIMPro 发布态里的 AI 助手解决的就是这个问题。这篇文章我会从概念讲起带你理解 CIMPro 里的开发态、发布态和 AI 助手之间的关系然后给出一个从创建 AI 助手、配置业务知识、接入场景操作到发布态实际演示的完整流程。文章末尾会补充排查思路和工程建议方便你直接拿到项目里用。1. 为什么要关注 CIMPro 发布态的 AI 助手先下一个判断在 CIMPro 这类三维组态平台里AI 助手能不能用好直接决定项目交付后的使用率。传统组态项目的交付模式是开发人员做好场景写一份操作手册然后培训客户。问题在于数字孪生项目往往对应复杂的业务场景设备点位几百上千页面几十个客户现场人员不可能把手册背下来。最后最常见的局面是项目上线时很热闹两个月后只剩几个核心页面还在被打开。AI 助手改变了这个交互链路。用户在发布态里不用再通过菜单一层层找功能而是用自然语言直接表达意图。比如我想看 3 号车间当前温度切换到大屏巡检模式今天有没有设备告警帮我打开水处理工艺流程页面。这个变化看似只是多了一个聊天框背后其实是交互入口从“功能菜单”变成了“语义理解”。对于数字孪生、智慧园区、智慧工厂这类场景AI 助手承担的不只是问答而是整个发布态的操作入口。所以这篇文章值得关注不是因为它能让你把 AI 助手配置出来而是因为你配置出来的 AI 助手能不能真正被客户用起来。这中间的差距恰恰是很多项目最大的坑。2. 开发态、发布态与 AI 助手的关系2.1 三个状态到底是什么意思CIMPro 项目通常会区分开发态和发布态。开发态是项目搭建阶段。用户在这个状态下编辑三维场景、绑定数据、配置交互、调试脚本。开发态面向交付人员能看能改但一般不会让最终用户直接使用。发布态是项目运行阶段。开发态配置完成后项目会经过构建、部署最终在浏览器中运行。发布态面向最终用户界面干净、交互连续、数据实时刷新通常不再带编辑操作。AI 助手并不是开发态的专用调试工具它同时服务于两个状态。在开发态AI 助手可以帮你快速生成脚本、补全配置、定位场景节点在发布态AI 助手则面向业务用户回答业务问题、控制场景展示、辅助运营决策。2.2 AI 助手在发布态里的本质是什么从实现角度看发布态中的 AI 助手通常会包含三层能力层级作用通俗理解对话层用户输入自然语言AI 理解意图并生成回复“人说的话”转成“机器能执行的任务”语义/知识层关联项目中的业务数据、模型节点、页面场景让 AI 知道设备、点位、告警是什么执行层调用场景切换、数据查询、状态控制等能力把 AI 的想法变成实际动作你可以把 AI 助手理解成一个“翻译官 操作员”的组合。翻译官负责把用户的自然语言翻译成项目能理解的操作指令操作员负责在三维场景里完成跳转、高亮、数据刷新。2.3 与通用大模型助手的区别很多人会问直接用 ChatGPT、通义千问、文心一言不就行了为什么要专门在 CIMPro 里配置 AI 助手关键区别在于业务上下文。通用大模型不懂你的项目不知道你场景里的设备 ID不知道你的点位结构也无法直接操作你的三维场景。CIMPro 的 AI 助手需要结合项目配置包括设备台账、场景节点树、业务指标口径、操作权限等才能让回答真正贴合项目。所以我们接下来要做的配置工作重点不是在“模型选型”而是在“把项目知识传递给 AI”。3. 使用 AI 助手需要做哪些准备在开始配置之前先确认环境是否满足条件。不同项目版本功能入口可能不同但以下几点是通用前提。3.1 平台与账号你需要一个可以正常编辑项目的 CIMPro 工程并且拥有该项目的开发权限。发布态访问则依赖项目部署环境可能是本机演示环境也可能是服务器部署环境。3.2 模型服务或 AI 引擎AI 助手需要大模型能力支撑。CIMPro 发布态的 AI 助手一般会对接平台自带的 AI 引擎或者项目方自建的模型服务。这里需要注意如果使用云端模型服务需要确认网络连通性如果使用本地化模型服务需要确认服务地址和端口如果在隔离内网部署必须提前规划模型服务的部署位置。一个常见误区是只在开发态配置了 AI 助手发布态没有配置模型服务地址结果发布会地址部署出来之后 AI 助手一直不响应。做项目交付时要重点关注本地部署环境的网络策略。3.3 数据与场景准备AI 助手能回答什么取决于你给它什么数据。在动手配置前先梳理项目里有哪些内容可以被 AI 助手使用比如场景页面列表及页面功能描述设备列表、设备名称、设备编号实时指标的查询口径或 API 地址业务操作项如开关阀门、切换巡检模式。准备得越规范AI 助手发布后的表现越好。不要指望 AI 在没有任何上下文的情况下自己“猜出”项目业务。4. 在 CIMPro 开发态创建你的第一个 AI 助手4.1 找到 AI 助手配置入口新建项目后在 CIMPro 开发态的项目配置中一般会有“AI 助手”“智能助手”“Agent 配置”一类入口。不同版本命名可能不同但核心配置项是相似的。本文以通用配置思路演示具体菜单名以你的工程版本为准。创建 AI 助手的步骤大致如下进入 AI 助手配置界面点击新建助手填写助手名称配置助手角色人设和回答风格关联业务知识库或业务数据保存并回到项目。4.2 配置助手身份这一步非常关键。身份配置决定了 AI 助手以什么角色面向用户。以智慧工厂项目为例一个合格的助手身份配置可以这样写assistant.name工厂运维助手 assistant.role你是某智慧工厂的运维助手负责帮助现场人员查询设备状态、查看告警信息、切换监控场景。 assistant.style回答简洁、专业每次回答先用一句话给出结论再补充关键数据。不要使用复杂术语除非用户主动询问细节。 assistant.limit只能回答与工厂生产、设备、安全相关的问题。对于与工厂运营无关的问题请礼貌提示用户重新提问。身份配置不是越多越好。很多项目失败的原因是 Prompt 写得像小作文AI 助手反而不知道重点是什么。更推荐的方式是角色清晰、风格一致、边界明确。上面这个配置里关键是最后一条 limit它让 AI 助手不越界避免发布态里用户问一句“今天天气怎么样”AI 助手开始脱离业务聊闲天。4.3 配置回答风格不同的行业回答风格差异很大。智慧园区项目可能更强调空间感和位置描述工业运维项目更强调数据精确性和安全提示。建议在开发态准备 2 到 3 套风格模板在演示时根据客户群体临时切换而不是一套配置走到黑。5. 让 AI 助手真正“懂”项目业务如果说身份配置决定了 AI 助手的“人设”那业务配置就决定了它的“能力上限”。只配置身份、不配置业务发布态里的 AI 助手就是一个空壳。5.1 业务知识接入CIMPro 项目中需要让 AI 助手了解的信息通常包括三类第一类是设备台账。设备名称、设备编号、所属区域、运行状态等。AI 助手知道这些信息后才能回答“3 号空压机现在什么状态”这类问题。第二类是页面与场景地图。每个场景页面的名称、功能、包含哪些核心设备。AI 助手知道这些后才能执行“切换到总览页面”这类操作。第三类是业务指标口径。比如“综合效率”怎么计算“告警级别”怎么划分。这类信息如果不提前告诉 AI 助手它给出的回答很可能与项目实际业务不一致发布后会被客户挑出问题。下面是业务知识配置的一个示意。{ scene_pages: [ { name: 工厂总览, keywords: [总览, 首页, 整体], description: 显示工厂整体生产状态、核心设备运行情况, action: switch_scene, target: factory_overview }, { name: 3号车间, keywords: [3号车间, 车间三, A3区域], description: 显示3号车间内设备布局和生产数据, action: switch_scene, target: workshop_3 } ], devices: [ { name: 空压机A, id: compressor_001, location: 3号车间东侧 }, { name: 冷却水泵B, id: pump_002, location: 动力站一层 } ] }以上配置是示意格式实际操作时以 CIMPro 提供的知识库或业务配置界面为准。关键不是 JSON 字段是否完全一致而是你要表达的数据结构是否覆盖了“页面、设备、指标”三类内容。5.2 助手指令与意图识别发布态里用户说“我想看 3 号车间”AI 需要能把这个意图映射到具体的页面跳转。这个过程在开发态通常通过“指令”或“意图”配置实现。每个指令至少包含三个要素触发词用户说哪些词时应该触发该指令执行动作触发后系统执行什么操作参数映射用户提到的对象名称对应哪个目标。以“切换页面”指令为例intent: switch_scene triggers: - 切换到 - 打开 - 看下 - 展示 required_params: - target_scene actions: - 调用场景切换接口参数为 target_scene examples: - user: 切换到3号车间 target_scene: workshop_3 - user: 打开工厂总览 target_scene: factory_overview这一段配置的意图是当用户输入包含“切换到”“打开”“看下”等触发词时AI 助手会尝试解析出目标场景然后调用场景切换能力。注意 expected examples 的作用——不是给程序用的是给模型理解用的。5.3 最小可用配置清单如果你从零开始建议不要一上来就配置几十条指令。先做最小可用配置跑通一条链路再说。一个典型的最小配置包括序号配置项是否必选说明1助手身份与角色必选决定回答风格与边界2至少 2 个场景页面必选用于演示场景切换3至少 5 个设备台账建议用于验证设备查询41 个业务指标建议用于验证业务口径51 个指令/意图必选最简单的跳转指令即可这个清单的意义是让整个链路短到有可能在十分钟内跑通。最怕的是配置了 100 条指令最后发布态一个都跑不通排查时根本不知道问题出在哪一环。6. 发布态中的 AI 助手交互体验开发态配置完成后接下来进入发布态验证环节。这一步往往比配置本身更容易出问题。6.1 构建并发布项目在 CIMPro 中完成开发态配置后通常需要经过保存、构建、发布三个动作。发布方式可能是本地演示发布、局域网部署、服务器部署具体以项目需求为准。发布完成后最终用户通过浏览器访问发布地址。此时 AI 助手应该出现在页面的固定位置例如右下角悬浮气泡或侧边栏。如果发布后 AI 助手没有显示优先检查项目构建日志看是否存在配置引用错误。6.2 发布态 AI 助手的典型使用方式发布态里的 AI 助手主要有三种使用方式对应的用户群体也不同。第一种现场交互演示。面向客户管理层或参观人员使用者输入“切换到大屏模式”“展示今天的产量趋势”AI 助手完成场景切换和数据展示。这种场景要求响应速度快、操作稳定不能演示到一半掉链子。第二种运维人员日常查询。面向值班人员用户习惯使用口语化表达比如“哪个设备报警了”“3号车间的温度”。这种场景要求回答包含准确的设备信息最好能附带定位或高亮。第三种辅助讲解与培训。面向新员工AI 助手承担带教角色。用户询问“这个场景怎么看”“这个参数是什么意思”AI 助手给出业务解释。这种场景要求知识库内容足够丰富。6.3 发布态演示注意事项发布态演示和开发态调试完全不同。开发态里你能随时改配置、看日志但发布态演示时页面是干净的操作是连续的用户输入是不可控的。因此有三点建议发布前准备一组“演示问题清单”。把客户最可能问的问题提前配置好并在发布态逐一验证。演示时优先使用带明确指令的短句。比如“打开工厂总览”比“我想看一下整体情况”更容易被 AI 准确理解。等演示稳定后再逐步尝试更口语化的表达。遇到识别失败时不要慌。可以提示用户换一种说法不要在一个问题上反复纠缠。7. 一个完整的发布态 AI 助手使用演练下面用一个典型场景串联整个流程假设你交付的是一个智慧工厂项目。第一步用户打开发布态页面点击页面右下角的 AI 助手图标弹出对话窗口。第二步用户输入“帮我切换到 3 号车间”。AI 助手根据指令配置识别用户意图是 switch_scene目标场景是 workshop_3随后页面从总览切换至 3 号车间场景并在对话窗口返回一句话“已切换到 3 号车间当前区域显示 26 台设备运行数据。”第三步用户继续输入“3号车间有没有设备报警”。AI 助手解析设备列表和告警数据返回结果“3号车间当前有 2 台设备存在报警空压机A高压告警、冷却水泵B振动超限建议立即前往动力站查看。”第四步用户输入“帮我把空压机A高亮显示”。AI 助手执行高亮操作三维场景中空压机A节点高亮闪烁同时对话窗口展示设备基本信息。这个流程中用户全程没有使用菜单没有学习系统操作只是用自然语言完成了场景切换、数据查询、设备定位三个操作。这就是发布态 AI 助手最核心的体验价值。8. 发布态 AI 助手常见问题与排查方法这里整理几个在项目交付中容易遇到的问题按“现象 → 原因 → 排查 → 解决”的方式展开。问题现象可能原因排查方式解决方案发布态页面没有 AI 助手入口助手未启用或项目未重新构建检查开发态 AI 助手是否启用查看构建日志启用助手后重新构建发布AI 助手打开后一直提示连接中模型服务地址不通或网络受限在发布环境测试模型服务连通性确认模型服务地址、端口、网络策略回答内容答非所问业务知识库未正确关联检查知识库关联的页面和配置重新关联知识库并同步能识别问题但无法执行场景切换指令配置中动作映射错误查看指令配置的动作和目标名称修正动作映射重新发布发布态识别速度慢模型服务响应慢或 Prompt 过长查看模型服务日志检查提示词长度简化已配置的 Prompt 和知识条目发布版本更新后 AI 行为没变化浏览器缓存了旧版本强制刷新或清理缓存使用无痕窗口验证排查这些问题时有一个原则先确认链路是哪一段断了。AI 助手完整链路是用户输入 → 意图识别 → 业务数据获取 → 场景动作执行 → 回复文本。任何一环出问题表现都会不同。比如能正常回复但无法切换场景问题大概率发生在动作执行环节而不是模型服务环节。9. 最佳实践与工程建议9.1 在项目初期就规划 AI 助手的边界很多项目是在开发结束、准备验收时才开始配 AI 助手这是很被动的做法。AI 助手的配置不是独立工作它依赖业务知识的梳理。如果设备台账、页面结构、指标口径在项目早期就没有规范化后期配置 AI 助手时就会反复返工。更稳妥的做法是在项目启动阶段就定义 AI 助手的服务边界哪些问题由 AI 回答哪些操作由 AI 执行哪些问题明确不处理。边界越清晰后期交付越稳定。9.2 Prompt 配置遵循“少而准”原则发布态 AI 助手不是竞赛题不需要一个 2000 字的提示词来炫技。从实际项目反馈看多数问题出现在角色和业务边界没写清楚、指令触发词覆盖不够、业务知识有冲突。建议每个 Prompt 控制在 200 字以内重点写明角色、风格、限制。业务知识部分用“清单 示例”的方式配置而不是用一段散文描述。9.3 发布态 AI 助手的安全与权限控制这里要特别提醒发布态是面向最终用户的环境必须考虑访问控制。如果项目涉及敏感设备数据或远程控制操作一定要在配置 AI 助手时考虑权限边界。具体建议包括对控制类操作配置二次确认AI 助手执行前让用户确认操作不同角色的用户AI 助手可执行的操作范围应不同记录 AI 助手的操作日志方便事后审计本地或私有化部署时模型服务的鉴权信息不要明文写在页面脚本中。这些建议不是让项目变得繁琐而是为了避免发布上线后出现安全事故。9.4 建立持续的迭代机制AI 助手不是配一次就完事的。客户使用后识别失败的案例、客户高频使用的问法、业务调整带来的数据变化都应该定期回填到配置里。建议每个月做一次 AI 助手配置更新把客户常见的新问法补充到指令触发词把新设备信息同步到知识库把不再使用的业务口径删除。这样才能让 AI 助手一直贴近真实业务。10. 从一个能跑的助手迭代出一个好用的助手回到开头的那个问题。你辛辛苦苦做的数字孪生项目客户不会用不是客户的问题是产品交互设计的问题。在 CIMPro 发布态里接入 AI 助手本质上是给客户配了一个“会操作系统的专属导览员”。但我要强调一点配置 AI 助手本身不是难事难的是让它稳定地服务于真实的项目。所谓稳定不只是模型不报错还包括意图识别准确、场景动作执行可靠、回答口径与业务一致。这要求你在开发态花时间梳理知识、配置指令、勤于测试验证在发布态做好权限控制、操作日志和持续的迭代更新。建议你拿到这篇文章后先做一个最小实验在项目里创建一个最简单的 AI 助手关联两个场景页面配置一个切换指令构建发布然后在发布态里用手机和电脑各访问一次体验完整链路。跑通之后再逐步增加设备查询、告警联动、指标讲解等能力。从能跑到好用中间隔的是对业务的持续理解和配置的持续打磨。希望这篇文章能帮你走出第一步。