企业官网建设流程全解析

CIMPro 这类带“发布态”的平台，最容易被忽略的就是 AI 助手在发布态和开发态里的行为完全不同。很多人把 AI 助手接在编辑器里测试时一切正常，一旦发布到运行时环境，页面打不开、助手不回复、提示词失效、会话记录丢失，各种问题就出来了。这篇文章就围绕“CIMPro 发布态 + AI 助手”这个组合，讲清楚它们之间的关系、接入前需要准备什么、配置怎么调、发布后怎么验证，以及遇到问题按什么顺序排查。

如果你正在做 CIMPro 项目的部署交付，或者刚把 AI 助手功能从开发态切到发布态，这篇文章会比较适合你。我看过很多项目卡在同一个地方：不是模型能力不行，而是发布态的基础设施、权限、接口地址和会话策略没有跟着环境切换。下面按实际落地顺序拆开写。

1. 先搞清楚发布态里的 AI 助手和开发态有什么不同

1.1 发布态不是简单把开发态页面打包

很多平台产品都会区分“设计态”和“运行态”，CIMPro 的发布态本质上就是面向最终用户的实际运行环境。在这个环境里，AI 助手不再只是编辑器里的调试工具，它是要跟着系统长期跑、被多人使用、被业务数据驱动的功能模块。

开发态里调试 AI 助手，通常只关心“能不能回复”。发布态里要关心的问题就多很多：

• 发布态服务部署在哪个服务器，AI 助手的接口能不能访问到
• 终端用户用什么账号登录，有没有权限唤起 AI 助手
• AI 助手要读取哪些业务数据，数据权限怎么隔离
• 对话记录存在哪里，会不会因为服务重启丢失
• 如果多人同时使用，会不会出现排队或接口超时

所以，发布态里的 AI 助手，本质上是一个运行在正式服务里的业务功能，而不是一个 Demo。

1.2 发布态 AI 助手的能力边界

AI 助手在发布态里能做什么，取决于三块：模型接口、提示词策略、业务数据接入。

第一块是模型接口。发布态需要配置一个稳定可访问的模型服务地址。这个地址可能是云端模型 API，也可能是局域网内自建的本地模型服务。很多项目在开发态用的是调试地址，发布后忘记改成正式地址，这是最常见的启动失败原因。

第二块是提示词策略。开发态调试时可以用很宽松的提示词，怎么方便怎么来。发布态不一样，提示词要覆盖角色设定、回答范围、不可回答内容、结果格式等。否则用户随便问几句，AI 就可能给出不稳定或者超出业务边界的回答。

第三块是业务数据接入。如果 AI 助手只是闲聊，那不需要接数据。如果它要查设备状态、查项目进度、查报表数据，就必须在发布态配置数据源、权限和查询参数。

建议先画一张小图：用户在哪触发 AI 助手、请求发给谁、模型服务在哪、返回结果怎么展示、对话记录写到哪里。这张图画清楚了，后面配置不会乱。

2. 要让发布态 AI 助手能干活，先准备这几个前置条件

2.1 权限和账号：发布态不等于开放给所有人

发布态 AI 助手最容易被忽略的，不是模型配置，而是账号权限。

先确认几个问题：

• 当前登录用户是否在允许使用 AI 助手的角色组里
• 是否需要按部门、项目空间或业务域隔离数据和对话内容
• 访客账号能不能看到 AI 助手入口
• 权限变化后，已经打开的页面是否需要刷新才生效

我遇到过一种情况：发布后 AI 助手按钮在页面上能看到，但点击没有任何反应。检查日志发现，当前账号根本没有调用 AI 助手的权限，只是前端把入口渲染出来了。权限接口没有校验到这一层，按钮就变成了“假入口”。

所以发布态验证权限，不只看入口是否可见，还要看后端接口是否做了二次校验。

2.2 模型服务地址和本地模型：先解决能不能访问的问题

模型服务地址是发布态 AI 助手的命门。很多公司的发布环境是内网服务器，外网模型 API 可能不通，或者需要配置专门的调用入口。

这里要先分清三种情况：

• 使用云端模型 API：发布态服务器需要能访问外网，并且 API Key 要放到服务端配置里，不要硬编码在页面里，避免泄露。
• 使用内网模型服务：确认发布态服务器和模型服务之间的网络连通性，以及端口是否放通。
• 使用本地模型：要区分是部署在发布服务器本机，还是另一台机器。跨机器调用时，要确认地址、端口、鉴权方式都符合要求。

网络连通性测试不要等到页面发布后再做。可以在发布态服务器上用最简单的命令行或脚本直接调用模型接口，先确认通不通，再接入平台。

2.3 数据源和知识库：AI 要回答准确，先要有数据

AI 助手在发布态里如果只是做通用问答，数据准备可以简单一点。但如果它要回答业务问题，比如“当前项目有哪些未闭环的告警”“某个设备的维修记录”，就需要接入业务数据源。

常见做法有两种：

• 把数据通过接口实时查询，AI 根据查询结果生成回答
• 提前把文档、 FAQ、设备手册等内容做向量化，存到知识库，AI 检索后回答

第一种适合结构化数据，第二种适合文档类知识。CIMPro 这类偏向工程可视化、数字孪生的平台，通常更适合两种结合：结构化的设备状态走接口查询，操作手册和工程规范走知识库检索。

发布态配置数据源时，要注意服务地址、账号、超时时间、最大返回条数这几个参数。尤其是超时时间，数据量一大，查询超过模型接口等待时间，对话就会失败。

3. 从开发态配置到发布态运行，AI 助手接入流程拆解

3.1 开发态配置 AI 助手：先跑通单条对话

不管最终是在 CIMPro 哪个版本里做，我都建议先在开发态把最小链路跑通。最小链路就是：页面触发 AI 助手 → 发送请求 → 模型返回结果 → 页面展示。

这个阶段不要急着做复杂参数，重点验证三件事：

• 模型服务地址能通
• 请求和返回字段能对上
• 页面能正常渲染返回内容

如果模型返回的内容是标准 JSON，需要看一下页面组件是否能正确解析。比如有的模型服务返回choices[0].message.content，但 CIMPro 里的助手组件可能期望的是content直接返回，这时候就需要在中间层做字段转换。

3.2 发布态预览和验证：从页面触发到结果返回

开发态跑通后，切到发布态，先不要直接开放给用户。应该用管理员账号做一轮完整回归。

我一般会分成四个步骤验证：

1. 打开发布态页面，确认 AI 助手入口出现
2. 发一条最简单的问题，确认模型能回复
3. 发一条涉及业务数据的问题，确认数据源能返回结果
4. 连续发三条不同问题，确认会话记录能正常保存和轮转

这里最容易出现的问题是发布态和开发态的接口地址配置不一致。有的平台会在发布态自动使用相对路径，但 AI 助手配置里可能写死了开发态的 IP。遇到这种情况，把配置改成相对路径或环境变量最好。

3.3 把对话记录、权限和操作日志一起带上

发布态不是给一个人用的。对话记录、权限、操作日志对于后续问题的追溯非常重要。

对话记录至少要包含：用户身份、提问时间、提问内容、模型回复内容、耗时、是否成功。这样才能排查“某个用户问过什么、为什么没回复”这类问题。

操作日志则要记录 AI 助手被调用了多少次、谁在什么时间调用了、涉及哪些业务数据。尤其在工程类平台里，AI 助手如果读取了设备数据或项目数据，没有日志，出了问题很难追溯。

如果发布态平台自带日志组件，直接接入；如果没有，建议在调用 AI 助手的后端接口里埋点，或者把请求转发到统一的日志服务。

{ "userId": "u_1001", "sessionId": "session_20250101120000", "question": "当前项目有哪些未处理告警", "answer": "当前共有3条未处理告警……", "costMs": 2300, "success": true, "createTime": "2025-01-01 12:00:00" }

这个结构只是示例，实际字段根据平台日志能力调整。核心是能通过一条记录还原一次完整对话过程。

4. 参数配置不是越多越好，关键是几个判断标准

4.1 模型参数：temperature、max_tokens、system prompt

CIMPro 发布态的 AI 助手配置项里，最常用的是模型名称、temperature、max_tokens、system prompt。这几个参数直接影响回答质量和稳定性。

temperature 控制随机性。工程类平台里，我一般建议设置 0.2 到 0.4，不要太高。因为业务回答需要确定性，比如查告警、查设备信息，结果应该是稳定可复现的。temperature 调高后，同一个问题可能每次回答都不一样，这在业务场景里很麻烦。

max_tokens 控制最大输出长度。如果 AI 助手需要输出长报告，可以调大一些；如果只是简短问答，设置 512 或 1024 就够了。要注意的是，max_tokens 过大会导致接口响应时间变长，过小会导致回答被截断。

system prompt 是发布态最需要花时间调的参数。一个好的 system prompt 应该包含：

• 角色定位：你是 CIMPro 平台里的智能助理，负责解答 XX 业务问题
• 回答范围：只能基于已接入的数据和文档回答
• 回答格式：先给结论，再给原因，必要时列出数据来源
• 拒绝策略：超出范围的问题，明确回复无法处理

一个简单的 system prompt 示例：

你是一个工业可视化平台助理。你可以查询设备状态、项目进度和告警记录。 回答要求： 1. 先给结论，再解释依据。 2. 如果查询不到数据，直接说“暂时无法获取该数据”，不要编造。 3. 涉及安全操作的内容，只提示操作步骤，不提供直接执行建议。 4. 回答使用中文，长度控制在 200 字以内。

4.2 发布态的并发、会话超时和失败重试

单用户测试没问题，不代表多人使用时没问题。发布态如果会遇到多人同时唤起 AI 助手，要考虑并发和超时。

先看一个简单场景：

• 模型接口单次调用耗时 2 秒
• 同一时间有 10 个人提问
• 如果接口不支持并发，10 个请求会排队，最后一个人可能等 20 秒

这种情况用户感知就是“AI 助手卡死了”。实际上不是死，是排队。

处理思路有几类：

• 给 AI 助手的接口调用设置超时时间，比如 15 秒，超过就返回提示
• 开启并发配置，让多个请求可以同时发给模型服务
• 在中间层做请求队列，避免瞬时大流量打满模型服务

另外要配置失败重试策略。模型接口偶尔会出现 500 或者超时，重试一次通常就好。但重试次数不要过多，一般 1 到 2 次即可。重试时还要注意避免重复写入会话记录，否则会出现“回答一次，但记录里多了两条同样问题”的情况。

4.3 发布态参数速查表

以上是通用参考值，不是固定标准。真实环境要看模型服务能力和业务要求，发布前先按这套分类去确认，能少走很多弯路。

5. 发布后 AI 助手不回复或答不准，按这个顺序排查

5.1 先看现象，再分两类

AI 助手在发布态出问题，通常分成两类：一类是“功能性问题”，比如打不开、点了没反应、请求报错；另一类是“效果性问题”，比如能回复但答不准、答非所问。

功能性问题优先排查链路，效果性问题优先排查数据。不要混在一起处理，否则很容易调了半天参数，结果发现是接口服务没通。

5.2 排查链路：先看日志再改参数

我的排查顺序一般是这样的：

第一步，看请求有没有发出去。打开浏览器开发者工具，看网络请求。如果点击 AI 助手后根本没有请求发出，那就是页面配置或权限问题，不是模型问题。

第二步，看请求返回什么。如果请求发出去了，但返回 404、405、500，那就看后端日志和接口路径。尤其要注意发布态服务是部署在不同环境下，接口的完整路径可能不一样。

第三步，看模型服务是否正常。单独用测试工具直接请求一次模型服务地址。如果直接调用也是失败，那就是模型服务本身的问题，跟 CIMPro 无关。如果直接调用正常，那就是 CIMPro 到模型服务之间的网络、鉴权或字段转换出了问题。

第四步，看提示词和数据。如果功能正常但回答不准确，大概率是提示词没有限定范围，或者知识库/数据源没有覆盖用户的问题。

第五步，看会话记录。如果之前问过类似问题，可以翻一下会话记录，确认是第一次就答不准，还是多轮对话之后答案开始偏。

最后一步，看资源占用。如果发布态服务器 CPU、内存占用长期很高，AI 助手请求慢、超时、无响应，往往是服务资源不足，而不是配置问题。

5.3 常见问题对照表

6. 单用户跑通之后，再考虑批量、日志和多端访问

6.1 从单机演示到多用户访问：账号、角色、数据隔离

项目验收阶段，AI 助手往往只需要在演示环境里跑通。但到了正式使用，多用户、多角色、多数据域的问题就出现了。

最基础的要求是做到“不同角色看到不同答案”。比如普通用户问“告警”，只返回自己负责区域的告警；管理员问同样的问题，可以看到全局告警。这里不是靠提示词去控制，而是靠后端的数据权限去过滤。AI 助手拿到用户身份后，查询数据源时带上用户权限条件，查询结果再交给模型总结。

CIMPro 发布态里如果已经做了用户权限体系，AI 助手要尽量复用同一套权限，不要自己再造一套。否则会出现“页面权限控制得很好，但 AI 助手能绕过页面直接查数据”的问题。

6.2 接入日常使用场景：悬浮入口、快捷键、页面内嵌

AI 助手在发布态里的入口形式会影响用户是否愿意使用。常见的接入方式有三种。

第一种是页面右下角悬浮按钮，类似很多平台里的帮助助手。这种入口轻量，用户随时可以唤起，也不占页面空间。适合做通用问答和操作指导。

第二种是页面内嵌面板，AI 助手固定出现在页面某个区域。这种更适合和当前页面内容结合，比如用户查看某个设备详情时，旁边直接问“这个设备最近有没有异常”。

第三种是快捷键唤起，比如按快捷键弹出对话窗口。这个适合熟练用户，日常频繁操作的场景更顺手。

设计入口时，要避免把所有功能都堆在一个入口里。发布态 AI 助手如果既能查数据、又能控制页面视角、还能做报表解读，交互会变得很复杂。建议先聚焦一个高频场景，比如“设备信息问答”或“操作指导”，跑熟之后再扩展。

实际经验：先把入口做得再简单一点，用户更容易接受。入口太复杂，反而没人用。

6.3 从单进程到可运维：日志、监控和批量处理思路

发布态 AI 助手不是配一次就结束。长期运行后，要像维护其他服务一样维护它。

日志方面，至少要能回答这几个问题：

• 今天有多少人用了 AI 助手
• 成功率多少，失败集中在哪些时段
• 哪些问题反复出现但回答质量不高
• 有没有用户触发了超出范围的问题

监控方面，要关注模型接口的调用量和延迟。如果模型服务支持配额限制，要留意每天的调用上限。很多云端模型服务都有流量限制，一旦超过，用户侧就会看到异常。

批量处理方面，如果 AI 助手要做的是批量分析任务，比如“给 100 个设备生成状态摘要”，不要直接在对话里逐条提问。建议通过后台任务或接口调用来处理，把结果写入文件或数据库。对话式 AI 适合低频交互，不适合大批量计算。把批量任务放到对话里，既慢又容易超时。

7. 几个容易被忽略的发布细节

7.1 发布态环境要单独配置，不要复用开发态配置

很多平台支持多环境配置，CIMPro 如果也有类似设定，强烈建议把开发态、测试态、发布态的 AI 助手配置分开维护。

开发态可以随便改提示词、调高 temperature 测试效果；发布态必须使用稳定配置。否则开发态调试时改了某个参数，发布态也跟着变，线上效果就不可控。

如果平台不支持多环境隔离，至少要做一个配置记录，每次发布前人工确认一次。

7.2 模型版本和服务商变更时要重新回归

AI 助手的回复效果和模型版本强相关。同一个提示词，用不同版本模型，可能得到完全不同的回答。如果发布态的模型服务突然更换了版本，或者从本地模型换成云端 API，一定要重新跑一遍之前的测试用例。

建议维护一份回归用例清单，至少包含：

• 3 个基础问答，验证助手能正常回复
• 3 个业务数据问答，验证数据源正常
• 2 个超出范围的问题，验证拒绝策略生效
• 1 个多轮对话场景，验证会话记忆正常

这样每次变更后，花几分钟就能完成快速回归。

7.3 发布态 AI 助手的安全和合规提示

工程类平台里的 AI 助手如果涉及设备数据、项目资料，要注意信息边界。不要把所有数据无条件暴露给模型接口，尤其是数据会发送到外部模型服务时，要确认数据脱敏或脱密策略。

如果平台支持把模型服务部署在内网，优先采用内网模型，数据不出域。如果必须用云端模型，建议先在模型接入层做数据过滤，只发送必要的问题内容，不发送完整业务数据。

这不仅是技术问题，也是发布后长期稳定运行的基础。很多项目前期没考虑数据边界，后期合规检查时被迫返工，成本比一开始配置高得多。

最后说一点我的看法

CIMPro 发布态里的 AI 助手，能不能真正用起来，不在于模型多强，而在于基础配置是否干净。接口地址、权限、数据源、提示词、超时、日志，这些东西在开发态里不明显，一到发布态就会全冒出来。

我一般会建议按这个顺序推进：

1. 先画链路：用户入口、请求方式、模型地址、数据源、日志位置
2. 再做最小验证：一条简单问题跑通
3. 再补业务数据：让 AI 能回答真实业务问题
4. 再管权限和日志：确保多用户可用、可排查
5. 最后做回归和监控：每次变更后有据可查

只要前面几步不出错，后面扩展入口、批量任务、多端访问都会顺利很多。如果一开始就直接调参数，大概率会把时间浪费在无意义的试错上。