在非标自动化项目里机器视觉、运动控制、上位机三块功能通常被当成三个独立系统来调试。视觉工程师管定位和检测运动控制工程师管轨迹和速度上位机开发则负责界面、通信和状态展示。BnlAiCtrl 这类无代码平台把这三块能力收敛到同一条配置链路上确实减少了大量手写代码但工程师仍然需要理解算法参数、坐标系关系和设备通信方式。第七篇要讲的 AI 助手集成就是在这条链路上再加一层自然语言交互入口让工程师用中文描述需求平台自动生成视觉流程、运动控制配置和上位机界面草稿再由工程师检查、修正、确认后执行。这篇文章适合已经在用无代码平台搭过视觉或运动控制流程的工程师也适合准备在自己项目的上位机软件里接入大模型能力的开发者。读完可以理解 AI 助手在工业自动化场景里应该承担什么职责能够看懂一套基于提示词模板和工具调用的集成方案并且知道生成结果如何校验、回滚和纳入版本管理。整个过程不涉及在产线上直接闭环而是先把“建议生成”和“实际执行”分开这是保证安全的关键前提。1. AI 助手集成前先想清楚它在自动化平台里的定位1.1 无代码平台为什么需要 AI 助手无代码平台解决的是“减少重复编码”的问题但非标自动化项目真正消耗时间的往往不是编码而是需求沟通和参数选型。同一个视觉定位需求有的客户要检测引脚间距有的要定位旋转角度有的要识别表面缺陷。平台把算法封装成节点后工程师仍然需要知道该拖哪个节点、节点之间怎么连接、阈值参数设多少。AI 助手在这里的价值不是自动写代码而是把“我知道需求但不知道平台怎么配”的工程师直接带到配置结果面前。四类任务最适合先交给 AI 助手视觉流程搭建根据文字需求生成检测节点和参数初值。运动控制序列根据工艺描述生成轴运动顺序和速度。上位机页面布局根据监控需求生成控件和绑定关系。异常诊断根据日志给出排查建议或参数修正方向。这四类任务的共同特点是“结果可以被工程师二次确认”不会因为一次生成错误造成现场事故。这也决定了 AI 助手的输出必须设计成草稿、配置片段或诊断建议而不是直接下发到运动控制器。1.2 AI 助手不是替代工程师而是减少配置试错在无代码平台上AI 助手实际承担的是“配置加速器”的角色。它把工程师从这样一段长流程里解放出来查算法说明、找历史项目、回忆参数范围、反复试运行。集成前典型的视觉流程配置路径是读取需求文档。回忆或搜索平台里哪个算法适合当前检测项。手动拖拽节点并连线。设置初始阈值。用样本图试跑。根据结果微调参数。集成后路径变成输入自然语言需求。AI 助手返回流程草稿和参数初值。工程师核对流程结构。试跑并微调。确认生成版本。区别在于第 2 步和第 3 步。AI 不负责最后拍板所有配置只有经过工程师确认才会进入运行态。1.3 集成前后工作流对比阶段集成前集成后需求表达先在文档或口头里描述再手动翻译成配置直接输入自然语言AI 生成配置草稿参数初值靠经验或历史项目模板由 AI 根据场景推荐附带范围说明排错方式逐节点检查参数和日志先让 AI 分析日志再定向检查节点配置产出纯手工操作草稿生成、人工确认、版本保存上线保护依赖人员经验和流程规范强制加入审核、预览、回滚机制集成后真正的收益不是“不用人了”而是把工程师从重复性翻译工作中释放出来把精力放到那些 AI 无法判断的部分比如工件材质变化、机构公差、现场光环境。2. 集成前需要确定的技术架构和安全边界2.1 五个核心组成模块AI 助手集成不是简单调一个聊天接口。为了让生成结果能真正落入无代码平台的配置体系需要拆成五个模块客户端对话面板工程师输入需求、查看结果、确认或修改。平台后端服务负责鉴权、保存会话记录、把 AI 结果转换成中间配置。AI 网关统一管理模型请求、超时、重试和令牌用量。提示词引擎按业务类型组装系统人设、场景模板和设备信息。领域知识库存放算法参数范围、运动控制约束、历史排错案例。这五个模块的分工可以概括为客户端负责交互服务端负责业务数据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 环境准备与依赖清单如果是在开发环境演示建议先准备以下基础环境依赖项作用备注BnlAiCtrl 平台服务配置引擎和节点库需要开启插件扩展接口Python 3.9 或 Java 17编写集成服务取决于平台现有技术栈Redis会话记录和流式输出中转可换用内存队列生产建议持久化大模型 API 或私有化模型服务自然语言理解和生成生产环境建议私有化部署向量数据库知识库检索用于参数范围和案例匹配实际集成时先确认模型服务是否支持流式输出和工具调用。不支持工具调用的模型可以通过结构化输出约束来补偿但解析稳定性会差一些。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 一段错误日志没有给设备状态和最近操作记录。推荐格式是日志摘要。最近 10 条关键操作。当前节点状态。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_modelChatResponse) 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(messagesmessages, toolsTOOLS) 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_asciiFalse) }) 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 结果写入配置结果现场试跑发现问题后才意识到缺了人工确认环节。正确的确认流程AI 生成草稿。前端以节点图、参数表和警告列表三种形式展示。工程师在节点编辑器中修改。修改完成后点击确认。平台保存为新的配置版本并记录 AI 会话 ID 和操作人。版本保存时AI 会话 ID 是重要信息。后续调试如果发现某个参数有问题可以回溯到当时的对话上下文而不是只看到一个孤立的配置版本。5.3 运行验证方法验证 AI 助手是否集成成功不建议只验证“能不能聊天”。更实用的验证步骤是验证项操作通过标准场景路由分别发送视觉、运动、上位机、诊断问题返回对应场景的结构化草稿参数校验让 AI 生成一个超速运动参数平台拒绝写入并提示限制值节点映射输入平台不存在的节点类型校验失败并返回未知节点提示变量绑定询问变量列表外变量绑定为空或提示变量不存在流式输出长需求下观察前端响应无长时间无响应有加载状态权限控制无权限账号调用接口返回 403验证时重点看异常分支。AI 助手的价值不在于正常情况下生成多准确而在于错误情况下是否能被平台拦截不让错误配置进入运行链路。6. 常见问题与排查路径6.1 高频问题对照表问题现象常见原因检查方式处理建议AI 返回的 JSON 无法解析模型输出被截断或加入了多余文本查看原始响应内容和 token 用量增加输出长度限制启用 JSON Schema 约束失败时重试一次生成的节点类型平台不识别提示词未注入节点列表或模型按经验编造检查请求中 node_list 是否完整把节点列表改为动态注入并加入工具查询运动参数超限AI 没有拿到轴行程数据查看工具调用记录强制先调用轴参数查询工具再生成建议上位机控件绑定错乱变量名是模型编造的检查变量匹配日志改为先从变量字典匹配再绑定不匹配则留空对话响应太慢流式输出未开启或请求内容过长测量单次模型耗时开启流式输出精简设备上下文生产环境无法调用外部模型网络隔离或 API Key 未配置检查 AI 网关日志生产环境改用私有化模型服务6.2 从现象倒推的排查顺序遇到 AI 助手集成问题时按照以下顺序排查比盲目改提示词更有效确认输入消息和场景参数是否正确。查看 AI 网关的原始请求和响应日志。确认模型服务是否正常返回是否熔断或超时。检查结构化输出解析层是否出错。检查业务校验层是否拦截了合法输出。最后再看提示词模板是否需要调整。实际项目里很大一部分“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 助手的正确落地方式是在明确的安全边界内用可校验的流程让工程师更快地把需求变成配置。