如何让标准作业程序 (SOP) 和控制叙述具备 AI 就绪能力

为了使工业 SOP 和图纸具备 AI 就绪能力，工程师必须使用标准化的标签字典、显式安全状态和因果矩阵，将非结构化的 PDF 转换为机器可读的控制数据。OLLA Lab 提供了一个受限环境，用于实践确定性控制编写，并验证生成的逻辑在仿真中是否表现正确。

AI 在处理工业文档时失败，并不是因为它“不够聪明”，而是因为大多数工厂文档是为人类解读、修订会议和经验传承而编写的，而非为了确定性的机器解析。一份带有三次停机前标记的扫描版 P&ID 并不是上下文，而是带有标题栏的熵。

在对 OLLA Lab Yaga Assistant 进行内部基准测试期间，使用结构化标签字典加状态转换矩阵进行提示，与仅使用基于段落的控制叙述进行提示相比，梯形图逻辑生成错误减少了 83% [方法论：针对泵、输送机、储罐和 HVAC 控制练习的 36 项场景生成任务；基准比较器 = 源自叙述性 SOP 文本的纯段落提示；时间窗口 = 2026 年 1 月至 2 月]。这支持了一个狭窄的结论：结构化控制文档在受限的梯形图生成任务中显著提高了 AI 提示的质量。它并不能证明通用的自动化安全性、现场可部署性或模型的普遍性能。

实际意义很简单：如果文档供应链含糊不清，AI 输出成为负担的速度远快于其成为生产力工具的速度。

LLM 是概率系统，而工业控制需要确定性解释。这种不匹配是根本问题。

标准的工业 PDF 通常包含混合文档类型、隐含假设、修订漂移以及为已经了解工厂的工程师编写的散文。人类读者会根据经验填补空白，而模型则用标记概率来填补。这对于控制哲学来说是一个糟糕的替代品。

是什么让遗留 PDF 成为 AI 的“死文件”？

死文件对人类并非毫无用处，但由于关键的控制含义被掩盖、暗示或相互矛盾，它无法作为可靠的机器输入。

常见的失效模式包括：

• 相互矛盾的修订
• 一份图纸上有红线标记，但主 SOP 中没有。
• 设定点在调试期间发生了变化，但从未传播到叙述中。
• 设备名称在 HMI 屏幕、I/O 列表和维护记录之间不一致。

• 语言歧义
• “当储罐满时启动泵”并未定义：
• 哪个储罐，
• 哪个液位仪表，
• 什么阈值，
• 什么去抖时间，
• 信号异常时会发生什么，
• 或者“满”是指报警高位还是允许高位。
• AI 看到的是一个句子，而工艺过程看到的是一个论点。

• 缺失安全状态
• 叙述性文档通常忽略故障开启 (fail-open) 与故障关闭 (fail-closed) 的行为。
• 它们很少定义通信丢失、模拟量故障或模式转换时的输出状态。
• 与安全相关的假设留在了经验丰富的员工脑海中，这在某些时候很有效，但并非总是如此。

• 执行层级坍塌
• 允许条件、联锁、跳闸、报警和操作员指令被描述在同一个段落中，仿佛顺序和优先级是显而易见的。
• 它们只有在第三次现场访问后才变得显而易见。

为什么散文对于控制生成来说特别薄弱？

散文擅长解释，但不擅长执行。控制逻辑需要显式的状态、优先级和条件处理。

语言模型可以优雅地总结一个段落，但仍会遗漏最关键的一点：`PMP_101` 是否必须在重启计时器到期前或到期后响应 `LSL_100_BAD`。在工业自动化中，这不仅仅是文体差异，而是滋扰行为与地面湿滑（甚至更严重后果）之间的区别。

标准在此意味着什么？

标准并没有说“使用 AI 就绪的 JSON”。它们确实暗示了清晰度、命名规范和显式逻辑结构的重要性。

相关的参考标准包括：

• ISA-5.1：用于仪表标识和命名规范。
• IEC 61131-3：用于正式的控制程序结构和指令模型。
• IEC 61508：用于更广泛的原则，即与安全相关的行为必须根据风险进行适当的规范、验证和确认。

标准语言并非装饰。如果你的标签、状态和动作不够明确，无法通过结构化审查，那么它们也无法通过可靠的 AI 解读。

AI 就绪的文档是指无需依赖人类直觉来填补空白，即可解析为显式控制意图的文档。

这个定义必须保持可操作性。“AI 就绪”并不是任何数字化文档的溢美之词。

AI 就绪文档的操作定义

当控制叙述至少包含以下内容时，它就是 AI 就绪的：

• 显式 I/O 映射
• 输入、输出、模拟量值、指令、状态和派生状态均已命名并定义范围。
• 已定义的安全状态
• 每个受控设备在适用时都有已知的断电、故障或失效状态预期。
• 状态机转换逻辑
• 文档定义了导致空闲、启动、运行、停止、故障、复位、手动和自动状态之间转换的原因。
• 执行层级
• 跳闸、联锁、允许条件、报警和操作员指令按优先级和影响进行区分。
• 结构化可提取性
• 信息可以清晰地以表格、矩阵或 JSON 等结构化数据形式呈现。

如果一份文档无法回答“在什么确切条件下、以什么优先级、接下来会发生什么”，它就不是 AI 就绪的。它可能仍然有用，但对于安全的控制生成而言，它不够机器可读。

“AI 就绪”不意味着什么？

它不意味着：

• 仅仅因为数字化就合规，
• 未经审查就是安全的，
• 适合直接现场部署，
• 或等同于经过验证的功能规范。

它也不意味着 AI 会“理解工厂”。模型并不理解工厂。工程师在某些棕地项目中尚且难以完全掌握，而他们至少还亲临现场。

三个要素承担了大部分工作：标准化的标签字典、因果矩阵以及显式的联锁/允许条件定义。

这些并非新想法。其新颖之处在于，AI 暴露了跳过这些步骤的代价。

1. 为什么标准化的标签字典至关重要？

标签字典将命名从本地习惯转换为结构化的控制含义。

每个标签应至少定义：

• 标签名称，
• 描述，
• 数据类型，
• 相关工程单位，
• 源或目的地，
• 正常含义，
• 适用时的安全状态或失效预期，
• 以及与允许条件、报警或顺序步骤的关系。

一个受限示例：

• 标签：`PMP_101_CMD`
• 描述：主供料泵运行指令
• 数据类型：`BOOL`
• 安全状态：`0`
• 允许条件：`LSL_100_OK`, `VLV_102_ZSO`

这种结构并非魔法，它只是比“当条件正常时运行供料泵”更少歧义。

2. 为什么因果矩阵优于段落叙述？

因果矩阵将条件和响应强制转换为可观察的格式。

矩阵使以下内容变得明确：

• 触发条件，
• 阈值或离散状态，
• 受影响的设备，
• 所需动作，
• 报警行为，
• 锁存行为，
• 复位条件，
• 以及操作员可见性。

这一点很重要，因为当文档以关系而非散文表达逻辑时，AI 生成质量会提高。同样，人类审查也会因此改善。一个段落可以隐藏矛盾数周，而矩阵通常会立即引起注意，这很健康。

3. 为什么必须将联锁和允许条件分开？

联锁和允许条件通常被描述在一起，但它们的作用不同。

一个有用的区分：

• 允许条件 (Permissive)： 动作发生前所需的条件。
• 联锁或跳闸 (Interlock or trip)： 在运行期间阻止或强制状态改变的条件。
• 报警 (Alarm)： 通知性的条件；它可能会也可能不会采取行动。
• 安全功能 (Safety function)： 独立的风险降低行为，不应随意合并到标准过程控制逻辑中。

如果文档没有区分这些类别，AI 通常会将它们扁平化为一层控制逻辑。这就是为什么你会得到看起来优雅但判断力如湿纸板般的梯形图逻辑。

转换过程应该是分阶段的、可审计的，并且是有意为之的“枯燥”。在控制领域，枯燥是被低估的品质。

第 1 步：标准化源数据集

首先确定管理文档：

• 当前 SOP，
• P&ID，
• I/O 列表，
• 控制叙述，
• 报警列表，
• 回路图，
• HMI 对象参考，
• 以及调试记录。

然后解决明显的冲突：

• 重复的标签名称，
• 过时的设备参考，
• 不匹配的设定点，
• 不一致的单位，
• 以及未记录的现场修改。

不要让 AI 去协调你自己都没有协调好的文档集。那不是授权，那是推卸责任。

第 2 步：构建标签字典

为标签和信号创建一个单一的结构化来源。

包括：

• 设备和信号命名，
• 类型和单位，
• 地址或逻辑源，
• 指令/状态配对，
• 失效行为，
• 报警阈值，
• 以及任何顺序角色。

ISA-5.1 命名规范在这里很有用，因为一致性可以改善人类审查和机器提取。

第 3 步：提取状态逻辑

将叙述性的过程描述转换为显式的状态和转换。

对于每个子系统，定义：

• 运行模式，
• 进入条件，
• 退出条件，
• 超时条件，
• 异常转换，
• 以及复位行为。

这就是许多“AI 项目”悄悄变回工程项目的地方。这不是挫折，这是工作本身。

第 4 步：编写因果表

将每个过程原因映射到其所需的结果。

典型的列包括：

• 原因 ID，
• 触发条件，
• 阈值/值，
• 去抖或延迟，
• 受影响设备，
• 动作，
• 锁存/非锁存，
• 复位条件，
• 报警/HMI 响应，
• 以及备注。

第 5 步：将控制与安全相关行为分开

在存在安全功能的地方，应将其单独记录，并根据适当的生命周期和标准预期进行审查。

不要为了方便而将基本过程控制、停机逻辑和安全功能合并为一个叙述块。文档可能会变短，但风险论证不会。

OLLA Lab 在这里很有用，因为它训练了 AI 辅助控制工作所依赖的编写行为。它不会自动转换工厂文档，而这种边界很重要。

该平台的引导式构建结构要求学习者在将梯形图逻辑视为“完成”之前，先从明确的目标、I/O 映射、控制哲学、标签字典和验证步骤入手。这是正确的习惯。语法是在大多数人认为的之后才出现的。

OLLA Lab 在此工作流程中实际提供了什么？

在产品的受限范围内，OLLA Lab 提供：

• 带有标准指令类型的基于 Web 的梯形图逻辑编辑器，
• 从基本梯级到定时器、计数器、比较器、数学运算和 PID 的引导式梯形图学习工作流，
• 用于运行和停止逻辑并观察 I/O 行为的仿真模式，
• 用于标签、模拟量值和控制回路可见性的变量面板，
• 与真实设备行为挂钩的 3D/WebXR/VR 仿真，
• 针对场景模型的数字孪生验证，
• 包含目标、危险、顺序需求和调试记录的场景化实验室，
• 包含 I/O 映射、控制哲学和验证步骤的引导式构建说明，
• 以及在训练环境中提供受限 AI 指导的 Yaga Assistant。

这就是 OLLA Lab 变得具有操作价值的地方。它为工程师提供了一个地方，让他们练习从结构化意图编写逻辑，然后观察该意图在模拟设备上执行时是否能够存续。

为什么这对 AI 就绪文档很重要？

因为提高仿真质量的纪律同样能提高 AI 提示的质量。

当学习者必须定义：

• 每个标签的含义，
• “正确”行为的样子，
• 允许条件是什么，
• 应该注入什么故障，
• 以及失败后需要什么修订，

他们正在学习基于规范的控制思维。这就是文档与 AI 辅助之间的真正桥梁。不是抽象的“提示工程”，而是结构化的工程意图。

验证必须测试解释，而不仅仅是语法。编译成功并不等于证明正确。

AI 就绪的文档只是问题的一半。另一半是检查生成的逻辑在针对真实过程模型（包括故障、时序和异常状态转换）时是否表现正确。

“仿真就绪”在操作上意味着什么？

仿真就绪意味着工程师可以在逻辑到达实际过程之前，针对真实的过程行为证明、观察、诊断和强化控制逻辑。

这包括以下能力：

• 监控 I/O 和内部状态，
• 比较梯形图状态与模拟设备状态，
• 追踪顺序中的因果关系，
• 注入异常条件，
• 在故障后修改逻辑，
• 并验证修改后的行为是否仍然满足记录的控制意图。

这是至关重要的区别：语法与可部署性。许多逻辑在遇到第一个坏传感器、卡住的阀门或模式切换时，看起来就显得不再胜任了。

应如何在 OLLA Lab 中进行验证？

OLLA Lab 中的实用工作流如下：

• 使用梯形图编辑器和场景定义。
• 确认指令、状态、模拟量值和允许条件可见。
• 观察顺序是否符合记录的控制哲学。
• 示例：低液位开关损坏、阀门反馈缺失、定时器超时、模拟量超量程。
• 逻辑是否安全失效？
• 报警、锁存和复位是否按预期运行？
• 如果生成的逻辑表现“错误”是因为文档含糊不清，请先修复文档。
• 目标不是打补丁的梯级，目标是强化的“规范到行为”链条。

1. 加载或构建控制逻辑
2. 将逻辑映射到显式标签和过程状态
3. 运行仿真
4. 注入故障
5. 比较预期行为与观察行为
6. 必要时修订规范
7. 修订后重新测试

最后一点很容易被忽略。如果文档规范不足，手动修复梯形图可能解决了症状，却在文档供应链中保留了缺陷。

工程师应该产生一套紧凑的证据，展示推理、行为、故障和修订过程。截图本身大多只能证明软件处于打开状态。

使用此结构：

1. 系统描述 定义子系统、过程目标、运行模式和受控设备。
2. “正确”的操作定义 陈述确切的预期行为，包括允许条件、跳闸、报警、时序和复位条件。
3. 梯形图逻辑和模拟设备状态 展示相关的梯级、标签以及仿真中相应的过程行为。
4. 注入的故障案例 记录引入的异常条件及其重要性。
5. 所做的修订 记录修正是在逻辑中、控制叙述中、标签字典中，还是三者中同时进行的。
6. 经验教训 陈述故障揭示了关于规范、顺序设计或验证假设的什么信息。

这种格式对于训练、内部审查和 AI 辅助工作流非常有用，因为它保留了从需求到行为的可追溯性。它还揭示了工程师是真正理解系统，还是仅仅令人信服地排列了符号。

AI 辅助控制编写很有用，但它不能自我证明。治理仍然很重要。

需明确的关键限制

• AI 输出不是验证
• 生成的梯形图逻辑仍必须根据工厂特定要求进行审查、测试和界定。
• 训练环境不是现场认证
• OLLA Lab 是用于高风险任务的排练和验证环境，而不是认证机制或现场能力的证明。
• 数字孪生仅与其建模假设一样好
• 仿真可以暴露许多缺陷，特别是顺序和故障处理缺陷，但它不能保证完全的工厂保真度。
• 安全相关功能需要单独的严谨性
• IEC 61508 风格的生命周期预期不会因为模型快速生成了代码而消失。

快速的错误答案仍然是错误的。AI 只是让错误以更好的格式呈现出来。

文档供应链决定了 AI 表现得像一个有用的绘图助手，还是一个昂贵的、看似合理的错误来源。

如果工程师希望在控制工作中从 AI 获得可靠的帮助，解决方案不是神秘的提示词，而是结构化的文档：标签字典、因果矩阵、显式状态逻辑，以及对允许条件、联锁、报警和安全相关行为的清晰区分。OLLA Lab 融入了该工作流，作为一个受限的场所，在任何逻辑接近实际过程之前，练习并验证针对模拟设备的确定性控制思维。

这就是 AI 就绪文档的真正标准：不是模型能否读取它，而是由此产生的行为能否被证明。

- 向下： 在 OLLA Lab 开始动手实践。

• 向上： 探索完整的 AI + 工业自动化中心。
• 横向： 相关文章 1。
• 横向： 相关文章 2。
• 横向： 相关文章 3。

- IEC 61131-3: 可编程控制器 — 第 3 部分 - IEC 61508 功能安全标准系列 - NIST AI 风险管理框架 (AI RMF 1.0) - 欧盟 AI 法案：监管框架 - ISA/IEC 62443 工业网络安全概述

本文由 OLLA Lab 工程团队撰写，专注于工业自动化中的确定性逻辑与 AI 辅助工程的交叉领域。

本文档中的基准测试数据基于 OLLA Lab 内部针对 36 项控制场景的受控实验。所有引用的标准（ISA、IEC）均为行业通用参考。