企业官网建设流程全解析

在非标自动化项目里，机器视觉、运动控制、上位机三块功能通常被当成三个独立系统来调试。视觉工程师管定位和检测，运动控制工程师管轨迹和速度，上位机开发则负责界面、通信和状态展示。BnlAiCtrl 这类无代码平台把这三块能力收敛到同一条配置链路上，确实减少了大量手写代码，但工程师仍然需要理解算法参数、坐标系关系和设备通信方式。第七篇要讲的 AI 助手集成，就是在这条链路上再加一层自然语言交互入口：让工程师用中文描述需求，平台自动生成视觉流程、运动控制配置和上位机界面草稿，再由工程师检查、修正、确认后执行。

这篇文章适合已经在用无代码平台搭过视觉或运动控制流程的工程师，也适合准备在自己项目的上位机软件里接入大模型能力的开发者。读完可以理解 AI 助手在工业自动化场景里应该承担什么职责，能够看懂一套基于提示词模板和工具调用的集成方案，并且知道生成结果如何校验、回滚和纳入版本管理。整个过程不涉及在产线上直接闭环，而是先把“建议生成”和“实际执行”分开，这是保证安全的关键前提。

1. AI 助手集成前，先想清楚它在自动化平台里的定位

1.1 无代码平台为什么需要 AI 助手

无代码平台解决的是“减少重复编码”的问题，但非标自动化项目真正消耗时间的往往不是编码，而是需求沟通和参数选型。同一个视觉定位需求，有的客户要检测引脚间距，有的要定位旋转角度，有的要识别表面缺陷。平台把算法封装成节点后，工程师仍然需要知道该拖哪个节点、节点之间怎么连接、阈值参数设多少。AI 助手在这里的价值不是自动写代码，而是把“我知道需求但不知道平台怎么配”的工程师直接带到配置结果面前。

四类任务最适合先交给 AI 助手：

• 视觉流程搭建：根据文字需求生成检测节点和参数初值。
• 运动控制序列：根据工艺描述生成轴运动顺序和速度。
• 上位机页面布局：根据监控需求生成控件和绑定关系。
• 异常诊断：根据日志给出排查建议或参数修正方向。

这四类任务的共同特点是“结果可以被工程师二次确认”，不会因为一次生成错误造成现场事故。这也决定了 AI 助手的输出必须设计成草稿、配置片段或诊断建议，而不是直接下发到运动控制器。

1.2 AI 助手不是替代工程师，而是减少配置试错

在无代码平台上，AI 助手实际承担的是“配置加速器”的角色。它把工程师从这样一段长流程里解放出来：查算法说明、找历史项目、回忆参数范围、反复试运行。

集成前，典型的视觉流程配置路径是：

1. 读取需求文档。
2. 回忆或搜索平台里哪个算法适合当前检测项。
3. 手动拖拽节点并连线。
4. 设置初始阈值。
5. 用样本图试跑。
6. 根据结果微调参数。

集成后，路径变成：

1. 输入自然语言需求。
2. AI 助手返回流程草稿和参数初值。
3. 工程师核对流程结构。
4. 试跑并微调。
5. 确认生成版本。

区别在于第 2 步和第 3 步。AI 不负责最后拍板，所有配置只有经过工程师确认才会进入运行态。

1.3 集成前后工作流对比

集成后真正的收益不是“不用人了”，而是把工程师从重复性翻译工作中释放出来，把精力放到那些 AI 无法判断的部分，比如工件材质变化、机构公差、现场光环境。

2. 集成前需要确定的技术架构和安全边界

2.1 五个核心组成模块

AI 助手集成不是简单调一个聊天接口。为了让生成结果能真正落入无代码平台的配置体系，需要拆成五个模块：

1. 客户端对话面板：工程师输入需求、查看结果、确认或修改。
2. 平台后端服务：负责鉴权、保存会话记录、把 AI 结果转换成中间配置。
3. AI 网关：统一管理模型请求、超时、重试和令牌用量。
4. 提示词引擎：按业务类型组装系统人设、场景模板和设备信息。
5. 领域知识库：存放算法参数范围、运动控制约束、历史排错案例。

这五个模块的分工可以概括为：客户端负责交互，服务端负责业务数据，AI 网关负责模型通信，提示词引擎负责把业务语言翻译成模型能理解的结构化描述，知识库负责把模型输出拉回到行业常识内。

2.2 安全边界：建议与执行必须分离

这是整个集成方案里最重要的一条原则。AI 助手可以生成运动控制参数，但绝不能直接写到 PLC 或运动控制器里。可以生成的包括：配置草稿、参数修改建议、流程检查清单、异常原因分析。不允许生成的包括：直接下发到位指令、修改正在运行节点的参数、绕过权限执行任何写操作。

在架构上，需要把 AI 服务的输出接口设计成“只读建议型”：

ai_assistant: role: suggestion_only can_generate: - flow_draft - parameter_suggestion - hmi_layout_preview - diagnostic_report can_execute: false approval_required: true review_path: node_editor

这段配置的意思是：AI 输出只能是建议，所有写操作都必须在平台界面里由有权限的工程师手动确认。即使 AI 推荐了某个参数，最终写入版本库的也是平台自身的校验逻辑，而不是 AI 的原始返回值。

2.3 环境准备与依赖清单

如果是在开发环境演示，建议先准备以下基础环境：

实际集成时，先确认模型服务是否支持流式输出和工具调用。不支持工具调用的模型，可以通过结构化输出约束来补偿，但解析稳定性会差一些。

3. 四类核心功能的设计与实现思路

3.1 视觉流程生成：从需求描述到节点草稿

视觉检测的难点在于需求描述往往不精确。同样是“检测螺丝有没有歪”，可能是角度检测，可能是同心度检测，也可能是边缘平行度检测。AI 助手要做的是先让用户补充关键信息，再生成流程。

设计上建议采用两步交互：

第一步收集条件。用户输入后，平台先检查信息是否完整，缺少检测区域、相机角度、精度要求时，AI 主动追问。

第二步生成草稿。完整需求进入提示词引擎后，输出一个结构化的节点列表：

{ "flow_name": "螺丝歪斜检测_草稿", "nodes": [ { "node_type": "image_source", "params": { "camera_id": "cam_01", "trigger": "hardware" } }, { "node_type": "calibration", "params": { "calibration_file": "calib_default.json" } }, { "node_type": "edge_find", "params": { "roi": {"x": 120, "y": 80, "width": 300, "height": 200}, "edge_polarity": "dark_to_light", "threshold": 40 } }, { "node_type": "angle_measure", "params": { "reference_axis": "horizontal", "tolerance_deg": 3.0 } }, { "node_type": "decision", "params": { "pass_condition": "angle_measure < tolerance_deg" } } ] }

这段 JSON 不是真正的平台运行配置，而是“配置草稿”。平台拿到后，需要把 node_type 映射到实际节点类，把 params 校验到合法范围，再显示在节点编辑器里。这里的关键点在于：AI 生成的节点类型必须落在平台注册表内，否则直接丢弃并提示用户。

3.2 运动控制参数推荐：必须带约束输出

运动控制最怕的是 AI 给一个“看起来合理但实际会撞机”的速度或加速度。因此运动控制类提示词必须带上设备机构信息、行程范围、减速比和当前限位。

典型参数输出格式：

{ "axis": "X", "motion_type": "point_to_point", "velocity_mm_s": 120, "acceleration_mm_s2": 300, "deceleration_mm_s2": 300, "jerk_mm_s3": 0, "constraints_checked": [ "max_velocity <= 200", "acceleration <= 500", "axis range [-500, 500] ok" ], "warning": "当前负载较重，建议先以 60% 速度试运行" }

平台拿到这个输出后，不是直接接受，而是把 velocity_mm_s、acceleration_mm_s2 和轴行程表再校验一遍。超出限制时返回校验错误，并把 AI 建议值替换为平台允许的上限值。

这一节实际传达的是：AI 给出的是推荐值，平台给出的是安全值，最终生效值永远以平台校验后的结果为准。

3.3 上位机界面生成：控件绑定和数据源映射

上位机界面的 AI 生成，重点是让控件与平台内部的变量绑定关系正确。比如用户说“要显示当前 X 轴位置，还要有一个启动按钮”，AI 应该生成：

{ "view": "main_operation", "controls": [ { "type": "label", "text": "X轴位置", "bind": {"variable": "axis.x.position", "format": "0.000"} }, { "type": "button", "text": "启动", "bind": {"action": "start_cycle"} } ] }

这里最容易出错的是变量名。AI 模型没有平台变量字典，所以必须把变量列表注入到提示词里，或者让 AI 先从变量列表里匹配候选，再生成绑定。没有匹配到变量时，宁可生成空绑定，也不要编造一个不存在的变量名。

3.4 异常诊断：日志分析要比生成配置更谨慎

异常诊断属于“读”操作，安全风险低，但误诊风险不低。常见的误诊原因是只给 AI 一段错误日志，没有给设备状态和最近操作记录。推荐格式是：

1. 日志摘要。
2. 最近 10 条关键操作。
3. 当前节点状态。
4. AI 输出建议列表。

输出建议里必须带置信度，避免工程师被 AI 的“自信语气”误导：

{ "diagnosis": "视觉定位超时", "confidence": "high", "possible_causes": [ {"cause": "相机触发信号丢失", "confidence": "high", "check": "查看 IO 触发寄存器"}, {"cause": "曝光时间过短", "confidence": "medium", "check": "检查当前曝光值和目标灰度"} ], "suggestion": "优先检查触发链路，再调整曝光" }

关键点是，AI 诊断结果永远只能作为线索列表，平台需要附带“如何检查”的可执行动作。没有检查路径的建议对现场工程师来说价值很低。

4. 服务端集成实现：从对话接口到配置落地

4.1 后端对话服务接口设计

为了统一处理视觉、运动控制、上位机和诊断四类请求，后端可以设计一个简单的会话接口。这里用 Python FastAPI 示例说明思路：

from fastapi import FastAPI, HTTPException from pydantic import BaseModel app = FastAPI() class ChatRequest(BaseModel): session_id: str scene: str # vision / motion / hmi / diagnose message: str context: dict = {} class ChatResponse(BaseModel): session_id: str reply: str drafts: list @app.post("/api/ai/chat", response_model=ChatResponse) def chat(req: ChatRequest): # 1. 检查会话权限 # 2. 根据 scene 加载对应提示词模板 # 3. 调用提示词引擎组装请求 # 4. 调用模型服务 # 5. 解析结构化输出并校验 # 6. 返回草稿给前端 return build_response(req)

这里把 scene 作为必填参数，是为了避免让模型同时处理多种业务逻辑。每个 scene 对应不同的提示词模板和输出校验规则，比一个大而全的对话接口更容易维护。

4.2 提示词模板结构

提示词模板不需要太长，但必须包含四部分：角色设定、业务规则、输入信息、输出格式。以视觉流程生成为例：

你是非标自动化平台 BnlAiCtrl 的视觉配置助手。 你的任务是根据用户需求生成视觉检测流程草稿。 业务规则： 1. 只输出 JSON，不要解释。 2. 节点类型必须来自平台节点列表。 3. 参数必须给出合理初值，并确保在平台允许范围内。 4. 信息不足时，先输出 questions 字段提问。 用户需求：{user_message} 设备信息：{device_context} 平台节点列表：{node_list} 输出格式： {output_schema}

output_schema 是随用户需求动态生成的结构化约束。模型对 JSON Schema 的跟随能力通常比自由文本好，所以这个字段越具体，解析成功率越高。

4.3 工具调用：让 AI 能查询设备参数和运行状态

在配置生成场景中，AI 有时需要读取当前设备的轴行程、相机分辨率、变量列表等信息。与其把全部信息塞进提示词，不如让 AI 通过工具调用按需获取。伪代码如下：

TOOLS = [ { "name": "get_axis_limits", "description": "查询指定轴的行程、速度上限和加速度上限", "parameters": { "type": "object", "properties": { "axis": {"type": "string"} } } }, { "name": "get_variable_list", "description": "查询上位机变量列表，返回变量名和数据类型" } ] def call_llm_with_tools(messages, scene): # 组装带工具声明的模型请求 response = model_client.chat(messages=messages, tools=TOOLS) if response.tool_calls: for call in response.tool_calls: result = execute_tool(call.name, call.arguments) messages.append({ "role": "tool", "name": call.name, "content": json.dumps(result, ensure_ascii=False) }) return call_llm_with_tools(messages, scene) return response.content

工具调用让 AI 不再凭空编造行程上限，而是先查真实设备参数，再给出建议。这一点对于运动控制场景尤其重要，因为瞎编的行程上限会直接导致安全风险。

4.4 输出校验与配置落地

AI 返回的 JSON 不是最终配置。服务端需要经过至少三道校验：

def validate_draft(draft, scene): # 第一道：JSON 结构校验 if not is_valid_json(draft): return {"valid": False, "reason": "json_format_error"} # 第二道：字段范围校验 if scene == "motion": if not check_axis_limit(draft): return {"valid": False, "reason": "axis_limit_exceeded"} # 第三道：节点注册表校验 if scene == "vision": unknown_nodes = [n for n in draft["nodes"] if n["node_type"] not in NODE_REGISTRY] if unknown_nodes: return {"valid": False, "reason": "unknown_node_type"} return {"valid": True}

校验通过后，草稿进入前端预览阶段。没有通过的草稿返回给前端时，必须带上失败原因，并允许用户修改后重试。这里不要直接把失败原因丢给用户，建议转换为人类可读的提示，比如“最大速度超过 X 轴允许值”。

5. 前端交互设计与运行验证

5.1 对话面板的最小实现

前端对话面板不需要做成聊天机器人的样子，更实用的形式是“输入框 + 场景选择 + 结果卡片”。用户先选择场景，再输入需求，平台返回结构化卡片，卡片上直接显示可编辑的流程草稿。

一个简化版前端逻辑：

async function sendMessage(scene: string, message: string) { const response = await fetch('/api/ai/chat', { method: 'POST', headers: {'Content-Type': 'application/json'}, body: JSON.stringify({sessionId: currentSession, scene, message}) }); const result = await response.json(); renderDraftCards(result.drafts); } function renderDraftCards(drafts: Draft[]) { drafts.forEach(draft => { const card = createDraftCard(draft); card.confirmButton.onclick = () => applyDraft(draft.id); card.editButton.onclick = () => openNodeEditor(draft.id); }); }

前端只负责展示和确认，不负责写配置。applyDraft 操作会把草稿转换为可编辑节点，放到平台自身的节点编辑器中，由工程师继续调整。

5.2 生成结果的预览、确认与版本保存

预览是 AI 助手集成中最容易被忽略的环节。很多团队做完对话就直接把 AI 结果写入配置，结果现场试跑发现问题后才意识到缺了人工确认环节。

正确的确认流程：

1. AI 生成草稿。
2. 前端以节点图、参数表和警告列表三种形式展示。
3. 工程师在节点编辑器中修改。
4. 修改完成后点击确认。
5. 平台保存为新的配置版本，并记录 AI 会话 ID 和操作人。

版本保存时，AI 会话 ID 是重要信息。后续调试如果发现某个参数有问题，可以回溯到当时的对话上下文，而不是只看到一个孤立的配置版本。

5.3 运行验证方法

验证 AI 助手是否集成成功，不建议只验证“能不能聊天”。更实用的验证步骤是：

验证时重点看异常分支。AI 助手的价值不在于正常情况下生成多准确，而在于错误情况下是否能被平台拦截，不让错误配置进入运行链路。

6. 常见问题与排查路径

6.1 高频问题对照表

6.2 从现象倒推的排查顺序

遇到 AI 助手集成问题时，按照以下顺序排查比盲目改提示词更有效：

1. 确认输入消息和场景参数是否正确。
2. 查看 AI 网关的原始请求和响应日志。
3. 确认模型服务是否正常返回，是否熔断或超时。
4. 检查结构化输出解析层是否出错。
5. 检查业务校验层是否拦截了合法输出。
6. 最后再看提示词模板是否需要调整。

实际项目里，很大一部分“AI 生成不对”的问题，其实是提示词和校验逻辑不一致造成的。比如提示词要求输出 JSON，但输出 Schema 里又写了多余字段，或者校验器要求字段必填但提示词没有明确说明。这类问题通过检查原始请求和校验日志可以快速定位。

6.3 关于“AI 幻觉”的边界控制

在工业自动化场景里，AI 幻觉不能靠“再训练一个模型”解决，更现实的做法是从流程上控制：

• 所有设备参数通过工具查询获得，不允许 AI 自由生成。
• 所有节点类型从注册表获取，AI 只能选择不能发明。
• 所有参数必须经过范围校验。
• 所有诊断建议必须附检查路径。
• 所有写操作必须人工确认并记录版本。

这五条规则可以看作 AI 助手的“安全护栏”。模型的能力会变，但护栏不变。

7. 最佳实践与后续扩展方向

7.1 可执行的落地清单

在准备把 AI 助手接入 BnlAiCtrl 或类似平台时，建议逐项检查：

• AI 输出是否全部为只读建议，无任何直接执行能力。
• 视觉、运动、上位机、诊断四类场景是否分别定义提示词和校验规则。
• 设备参数、变量列表、节点注册表是否通过工具调用动态获取。
• 每个 AI 会话是否有唯一标识，并关联到最终配置版本。
• 参数校验是否在平台侧强制执行，而非依赖 AI 正确性。
• 前端是否提供预览、修改、确认、回滚完整操作链。
• 模型服务是否支持流式输出和结构化输出。
• 生产环境是否使用私有化模型，避免外部网络依赖。
• 日志是否记录原始请求、原始响应、校验结果和操作人。
• 是否有针对 AI 生成失败的降级方案，比如退回手工配置模式。

这十条不是可选项。前三条涉及安全边界，后几条决定了这个功能能不能长期稳定运行。

7.2 容易忽略的三个坑

第一个坑是让 AI 直接生成最终配置，而不是生成草稿。一旦模型输出和平台规则不一致，运行态就会出现问题，而且因为链路长，排查成本很高。

第二个坑是没有记录 AI 会话和配置版本之间的关联。运营一段时间后，某个参数被改过多次，工程师无法知道最初是由哪次 AI 建议引入的。

第三个坑是提示词模板长期不更新。平台新增了算法节点或变量后，如果提示词和节点注册表没有同步，AI 会继续按旧知识生成，出现“平台明明支持，AI 却说没有”的情况。

7.3 扩展方向

后续可以考虑做三件事。第一是把历史确认记录变成反馈数据，用于评估 AI 建议的采纳率，筛选出经常被工程师修改的模板和参数，定向优化。第二是引入“项目模板召回”，当用户描述的需求和历史项目相似时，直接推荐历史项目的可视化配置结构，这比从零生成更符合非标项目的复用习惯。第三是把 AI 助手延伸到离线调试阶段，通过模拟相机图像和虚拟轴，在不上电的情况下验证生成的流程是否符合预期。

对于正在做 AI 助手集成的团队，建议从小范围试点开始。先选视觉流程生成一个场景，跑通草稿、校验、确认、版本保存的完整链路，再逐步扩展到运动控制、上位机和诊断。不要一次性接入所有能力，否则问题会叠加，排查难度会成倍上升。AI 助手的正确落地方式，是在明确的安全边界内，用可校验的流程让工程师更快地把需求变成配置。