跳到主要内容
版本：Next

AI调试助手

AI调试助手面向开发版工程调试场景。用户只需用自然语言描述“变量读不到、事件未触发、归档没有数据、聚合结果异常”等问题，AI 就会自动判断调试类型，调用对应的变量、事件或服务调试能力，定位异常对象，解释可能原因，并给出下一步处理建议。

AI调试助手只读取工程配置、实时数据和日志进行诊断，不会自动修改工程配置，也不会自动执行可能改变测试数据的操作。诊断结果仍需由用户进行核对、修改和测试。

功能说明​

  • 统一自然语言入口：在 CMS Editor 中直接打开 AI 调试助手，输入问题、异常现象或日志内容，无需先判断应该进入变量、事件还是数据服务模块。
  • 调试类型自动识别：AI 根据用户描述判断调试场景，自动调用变量调试、事件调试或服务调试能力，并沿着工程对象关系组织诊断结果。
  • 变量读值测试：支持查询单个变量或一批变量当前是否能够读到值，并结合变量名称、数据类型、通道连接状态和质量码等信息，分别说明每个变量的异常原因。
  • 变量影响分析：针对已发现的异常变量，查询其对页面组件、事件动作、归档表、聚合表或计算公式的影响范围，帮助工程师判断处理优先级。
  • 事件异常判断：分析事件未触发、已触发但未成功执行或执行后报错等情况，检查触发条件、动作参数、脚本、权限和执行日志，并将技术日志转换为易理解的原因说明。
  • 归档服务检查：当归档表没有数据时，检查触发条件、归档字段、数据源和归档策略，判断配置是否存在异常并给出修改建议。
  • 聚合服务检查：当聚合表没有结果或结果异常时，检查聚合配置、数据源、时间窗口、任务调度和执行状态，辅助判断为什么没有生成预期数据。
  • 公式字段检查：当归档或聚合服务中的公式字段没有计算结果时，定位具体字段和公式，说明可能的字段类型、表达式或数据源问题。
  • 日志解读与翻译：支持直接粘贴错误提示或事件、服务日志，例如 action timeout、aggregation timeout，AI 会解释错误含义、分析可能原因并给出下一步排查方向。
  • 可理解的诊断结果：结果不只返回“失败”，还会展示核心结论、后台排查纪实和建议动作，方便工程师继续处理。
  • 只读诊断与人工校验：AI 不自动写入工程、不自动修改变量或服务配置；工程师需要根据建议在对应模块中完成修改，并通过实际测试验证问题是否解决。

核心优势​

1. 一个入口覆盖多类工程问题​

传统调试需要在变量管理、事件配置、数据管理、日志记录等多个页面之间来回切换。AI调试助手把这些调试场景统一到一个对话入口中，工程师可以直接描述现场现象，由 AI 负责判断应检查的工程对象和能力范围。

2. 从“异常现象”追到“影响链路”​

变量质量异常可能进一步影响页面展示、事件动作、历史归档和聚合公式；服务没有数据，也可能是源变量没有正常读值。AI调试助手会结合工程引用关系组织排查路径，帮助工程师从单点错误扩展到上下游影响，而不是只查看某一条孤立日志。

3. 把技术日志转换为工程师能执行的建议​

事件节点、动作参数、脚本异常、权限异常、时间窗口和任务调度等信息通常较为技术化。AI 会将错误提示翻译为更易理解的原因说明，并给出应该检查的配置项、变量或日志位置，降低 OT 工程师的排查门槛。

4. 提前发现问题，减少联调返工​

在开发版阶段完成变量连通性、事件逻辑和数据服务预检，可以尽早发现配置错误，把问题处理在工程交付前，减少到了现场联调或验收阶段才暴露问题所带来的返工风险。

5. 诊断过程安全可控​

AI调试助手以只读检查为边界，不会绕过权限直接修改工程，也不会把诊断结果当作现场验证结论。工程师可以先查看依据和建议，再在开发版中人工修改、测试和确认。

典型使用场景​

场景一：批量变量读值异常定位​

背景：一条产线包含多个通道、设备和变量组，工程师发现部分温度变量没有实时值，但逐个打开变量查看质量码需要花费大量时间。

AI方式：

  1. 打开 AI 调试助手，输入：“检查二号产线所有温度变量当前是否能读到值，列出读不到的变量和具体原因。”
  2. AI 根据变量范围读取当前状态、质量码、数据类型和所属通道信息。
  3. 对每个异常变量分别说明可能原因，例如变量不存在、数据类型不匹配、通道连接异常或对应设备断开。
  4. 工程师根据结果回到变量或通道配置中修正问题，并重新发起读值测试。

价值：从逐个查看变量变为按设备、通道或变量组批量预检，快速定位异常点位。

场景二：事件已经写入，但动作没有触发​

背景：工程师确认某个变量已经成功写入 0.9，但关联事件没有执行预期动作，不确定是触发条件、动作参数、脚本还是权限导致的。

AI方式：

  1. 输入：“变量已经成功写入 0.9，为什么动作还是没触发？请检查事件条件和执行日志。”
  2. AI 检查事件触发条件、关联变量、执行节点和动作配置。
  3. 如果事件已经触发但执行失败，AI 继续分析动作参数、脚本异常、权限限制或执行日志。
  4. AI 用非技术语言说明原因，并给出应检查的配置项和处理建议。

价值：将“没有动作结果”拆解为“未触发”或“触发后执行失败”，减少在多个配置页面之间反复猜测。

场景三：归档表没有数据​

背景：工程师配置了生产数据归档，但运行后归档表为空，需要判断是触发条件、归档字段、变量读值还是归档策略配置不正确。

AI方式：

  1. 输入：“生产数据归档表运行后没有数据，请检查归档字段、触发条件和归档策略。”
  2. AI 检查归档配置、字段来源、触发条件和相关变量状态。
  3. 如果发现源变量本身无法正常读值，AI 会提示先处理变量连接问题；如果变量正常，则继续检查归档策略和服务执行状态。
  4. 工程师根据诊断建议在数据管理或历史库模块中修改配置，再进行验证。

价值：把“表里没有数据”还原为变量、触发、字段和服务执行等多个可能环节，缩短数据链路排查时间。

场景四：聚合结果或公式字段异常​

背景：日电耗聚合表已经运行，但没有生成结果，或者某个公式计算字段始终为空，工程师需要知道到底是哪个字段或哪段公式出了问题。

AI方式：

  1. 输入：“日电耗聚合表运行后没有数据，请检查时间窗口、数据源、任务调度和公式字段。”
  2. AI 检查聚合表的数据源、时间窗口、任务执行状态、字段类型和公式配置。
  3. 对公式字段异常时，AI 明确指出异常字段、涉及的公式以及可能不匹配的输入字段。
  4. 工程师修改数据管理配置后，再次运行或等待下一次调度验证结果。

价值：避免只看到“聚合失败”或“字段为空”，能够进一步定位到配置项和公式字段。

场景五：直接理解英文错误日志​

背景：工程师在事件或服务日志中看到 action timeout、aggregation timeout 等提示，不清楚错误含义和后续应该检查什么。

AI方式：

  1. 将错误提示直接粘贴到对话框中。
  2. AI 解释错误术语、结合 CMS 工程语境分析可能原因。
  3. AI 给出下一步排查顺序，例如查看动作执行状态、任务调度、时间窗口、数据源和相关变量。

价值：不必先查阅底层技术文档，就能获得与当前工程配置相关的排查方向。

5分钟快速上手​

步骤1：打开 AI 调试助手​

打开全局 AI 助手入口，选择或进入 AI调试助手。该助手适用于开发版工程的配置预检和问题定位。

调试助手1

步骤2：描述异常现象或粘贴日志​

直接用自然语言描述问题，也可以将事件日志、服务日志或错误提示粘贴到对话框中。建议同时提供工程对象名称、变量范围、时间窗口和预期结果。

调试助手2

例如：

请检查二号产线的日电耗聚合表。
运行后没有生成数据，时间范围是今天 00:00 到现在。
请重点检查数据源变量、时间窗口、任务调度和公式字段，并说明下一步应该怎么处理。

步骤3：AI 自动判断调试类型​

AI 会根据输入内容判断当前属于变量调试、事件调试还是服务调试，并调用对应的只读检查能力。

步骤4：查看诊断结果​

重点查看以下信息：

  • 异常对象：具体变量、通道、事件、动作、归档表、聚合表或公式字段
  • 异常现象：当前读值、质量码、触发状态、执行状态或服务结果
  • 原因解释：根据配置、引用关系和日志推断出的异常原因
  • 影响范围：受影响的页面组件、事件动作、归档表或聚合公式
  • 处理建议：应该回到哪个模块检查或修改哪些配置

步骤5：人工修改并重新验证​

AI 调试助手只提供诊断和建议，不会自动修改工程。工程师需要在变量、事件、数据管理或历史库等对应模块中完成修改，再重新进行读值、事件执行或服务运行验证。

提问与操作技巧​

技巧一：说明“对象、现象、时间和预期”​

一个完整的问题最好包含以下信息：

  • 对象：变量、通道、事件、动作、归档表、聚合表或公式字段名称
  • 现象：读不到值、没有触发、执行报错、没有归档、聚合为空或结果异常
  • 时间：发生时间、查询时间范围或任务调度时间
  • 预期：希望读到什么值、应该触发什么动作、应该生成什么数据
  • 证据：质量码、错误提示、事件日志或服务日志

例如：

变量 Line2_Power 已经有写入值，但日报聚合表的电能汇总字段为空。
请检查这个变量的读值状态、聚合数据源、时间窗口和公式字段，并说明影响范围。

技巧二：批量变量调试时明确范围​

如果需要检查一批变量，建议同时说明产线、设备、通道、变量组或变量前缀。例如：

请检查 Line2_Mixer 通道下所有温度和压力变量的当前读值。
按变量列出质量码、异常原因，并标记会影响页面、事件或归档的变量。

技巧三：事件问题要区分“未触发”和“执行失败”​

“动作没有发生”可能有两类原因：事件条件没有满足，或者事件已经触发但动作执行失败。提问时可以明确要求 AI 分别判断：

请先判断这个事件有没有触发；如果已经触发，再检查动作参数、脚本和权限为什么执行失败。

技巧四：服务调试要提供数据链路​

归档或聚合问题通常涉及变量、字段、触发条件、时间窗口、公式和任务调度多个环节。建议在首次提问中说明数据源表或变量、目标表、字段名称、公式和时间范围，减少 AI 追问。

技巧五：先看诊断依据，再执行修改​

AI 的建议用于缩短排查路径，不等于已经完成现场验证。修改前请确认异常对象、判断依据和影响范围；修改后要在测试工程或开发版中重新运行验证。

常见问题​

Q1：AI调试助手支持哪些调试类型？​

A： 当前需求范围包括三类：变量调试、事件调试和服务调试。变量调试包含读值测试和影响分析；事件调试包含异常判断和日志解读；服务调试包含归档检查、聚合检查、公式字段检查和服务日志翻译。

Q2：AI 能否直接修复变量、事件或数据表配置？​

A： 不能。AI调试助手的定位是只读诊断和建议，不自动修改工程配置，也不自动执行会改变测试数据的动作。请根据诊断结果回到对应模块人工修改并重新测试。

Q3：变量读不到值时，AI 只会告诉我“失败”吗？​

A： 不会。AI 会尽量按变量分别说明异常原因，例如变量不存在、数据类型不匹配、通道连接异常、设备断开或其他质量码对应的问题。对于暂时无法确认的原因，也会说明还需要补充检查哪些信息。

Q4：能否分析一个异常变量会影响哪些地方？​

A： 可以。在工程引用关系完整且当前能力可读取的范围内，AI 可以查询变量被哪些页面组件、事件动作、归档表或聚合公式引用，帮助判断异常影响范围和处理优先级。

Q5：事件已经触发但没有动作结果，应该怎么提问？​

A： 建议明确说明“请先判断是否触发，再检查执行失败原因”，并提供事件名称、关联变量、变量当前值、动作类型和日志。例如：“变量已写入 0.9，但动作没有结果，请检查事件是否触发、动作参数、脚本和权限。”

Q6：归档表或聚合表没有数据时，应该先查变量还是先查表？​

A： 建议让 AI 同时检查源变量和目标服务。源变量质量异常会导致归档或聚合没有有效输入；在变量正常时，再重点检查字段、触发条件、时间窗口、公式和任务调度。这样可以避免只修改表配置，却遗漏底层变量连接问题。

Q7：调试任务进行中可以在哪里查看？​

A： 在支持任务进展展示的版本中，可以在 AI助手进展/任务中心 查看调试任务状态和结果入口。具体展示内容以当前 CMS 版本和账号权限为准。

Q8：AI 给出的诊断结论可以直接作为交付结论吗？​

A： 不可以。AI 输出的是基于当前工程数据、引用关系和日志的辅助诊断。正式交付前仍需由工程师在开发版完成配置核对、实际运行验证和必要的现场联调。