当AI代码错误导致设备停线甚至人身安全风险，工业领域的容错率与互联网有着本质不同。本文通过通信设备电源管理模块开发的真实案例，揭示工业AI协作必须突破的三道硬墙——编程语言规范、设备状态机不可逆性、安全完整性等级，并系统拆解Harness Engineering框架如何将功能规格书转化为AI可执行的约束体系。

那是一次真实的工业控制逻辑开发任务。

我需要为一套通信设备的电源管理模块生成控制代码。需求很明确：当检测到直流输入电压跌落至阈值以下时，自动切换至备用链路，同时触发告警上报。我把需求描述给 AI，它很快交付了一段 ST 语言代码。跑仿真，逻辑正确，切换时序也对。成就感拉满。

第二天，我追加了一个需求：在原有逻辑基础上，增加温度联锁保护——当模块温度超过 75°C 时，强制禁止切换操作，防止高温下的热插拔损坏硬件。AI 同样很快给出了修改版本。

我一测，原来的电压切换逻辑消失了。

不是报错，是静默失效——代码能跑，但电压异常时不再触发切换，备用链路永远不会被激活。如果这段代码上了真实设备，故障时主链路断了，备用链路也不切，设备直接断联，没有任何告警。

这不是 AI 不够聪明。这是我没有给它一套能让它稳定工作的运行环境。

互联网的”改A崩B”，最坏的结果是用户骂一句然后刷新页面。工业控制逻辑的”改A崩B”，后果可能是设备损毁、产线停工，严重时涉及人身安全。

这个量级的差距，决定了工业场景对AI协作框架的要求，远比互联网苛刻一个数量级。这套框架，叫做Harness Engineering。

一、工业的“裸奔“，代价不是报错，是停线

在互联网圈，”AI 裸奔”最近被反复提起。意思是：你把 AI 当成随叫随到的外包，没有稳定的规则体系，没有验收标准，没有反馈闭环——它每次都在从零开始乱跑。能力再强，也只是一匹没有缰绳的野马。

互联网场景下，这匹野马跑偏了，代价是代码返工、产品延期、用户体验下降，这些都是可以修复的。工业场景下，这匹野马跑偏了，是另一个量级的事情。

工业控制软件有三道互联网AI从未真正遭遇过的“硬墙“：

第一道墙编程语言规范不是风格偏好，是强制标准

IEC 61131-3 定义了工业控制系统的五种编程语言——梯形图（LD）、功能块图（FBD）、结构化文本（ST）、指令表（IL）、顺序功能图（SFC）。它们不是可以随意选择的工具，而是根据应用场景、设备类型、安全等级有明确适用范围的规范。AI 如果不理解这套规范的边界，生成的代码在语法上可能完全正确，但在工程规范层面是不合格的。

第二道墙设备状态机具有不可逆性

互联网系统的状态大多可以随时回滚。但工业设备的状态机不是这样的。一个电机的控制逻辑，不能从”运行”直接跳到”急停”再跳回”运行”，必须经过”减速”、”停止确认”等中间态，否则设备会进入不可预期的物理状态，轻则报警，重则损毁。AI 如果跳过了中间态，代码能跑，但设备会出事。

第三道墙安全完整性等级（SIL）的合规要求

在通信工业的某些场景下，控制逻辑的输出直接关联到人身安全或核心业务连续性。AI 的输出不能直接上线，必须经过形式化验证或人工复核。这不是信任问题，是合规要求。

这三道墙，不会因为模型更强大而消失，只会因为 Harness 设计得更完善而被更好地约束。

二、工业 PM 的隐藏资产：功能规格书，天然就是 Harness

这是这篇文章最核心的论点，也是工业背景 PM 在 AI 时代最容易被自己忽视的竞争优势。

Harness Engineering 的本质定义：把人类意图精确编码为 AI 可持续执行的系统规则。每当 Agent 犯了一个错误，你就设计一个机制，让它永远不再犯同样的错误。

这件事，工业 PM 其实一直在做，只是对象不是 AI，而是人。工业 PM 每天写的功能规格书（FDS，Functional Design Specification），做的正是同一件事——把工艺要求、设备约束、安全边界，翻译成结构化的、可执行的、可验收的规则体系。

FDS的三个核心组成部分，与Harness的三个维度是1：1

对应关系。

这意味着：工业 PM 不需要从零学习 Harness Engineering 的方法论，只需要把已经掌握的能力，从”写给人看”切换到”写给 AI 用”。这个切换的门槛，远比互联网 PM 从零构建 Harness 体系低得多。

三、三次范式跃迁，在工业场景里长什么样

AI 工程领域的三次范式跃迁——Prompt Engineering、Context Engineering、Harness Engineering——在互联网圈已经被讨论得很透彻了。但这个框架在工业场景里的对应，几乎没有人专门梳理过。

Prompt Engineering 阶段

工业工程师把需求口头描述给 AI，AI 生成一段梯形图或 ST 代码，工程师盯着看对不对。这和互联网 PM 对着聊天框打字本质相同——一次性、无记忆、没有任何约束体系兜底。

这个阶段最大的问题不是生成质量差，而是生成质量不稳定。同样的需求，今天代码逻辑清晰，明天引入了一个隐性的竞争条件。在互联网，这叫”玄学”；在工业，这叫”不可接受”。

Context Engineering 阶段

把设备手册、历史程序、工艺说明喂给 AI，让它生成时有参考。效果有提升，AI 开始能理解”这台设备的通信协议是 Modbus RTU，寄存器地址从 0x0001 开始”这类背景信息。

但天花板很快到了。当控制逻辑涉及多个设备之间的联动时序时，AI 对上下文的理解会在复杂的多步骤任务中悄悄漂移——在第七步引入一个和第三步相矛盾的逻辑，而你很难在代码层面直接发现。

Harness Engineering 阶段

给 AI 一个完整的运行环境：标准化的工业知识库索引、IEC 规范的自动校验工具、基于 FDS 的验收测试集。AI 自己跑，自己看报错，自己修，跑通所有测试才交付。

人从”循环内”退到”循环上”——不是每一步都盯着 AI，而是在最终结果上做判断。这三个阶段不是线性替代，而是层层叠加。Harness 阶段并不废弃上下文工程，而是在其基础上加上约束体系和反馈闭环。

四、实操：为“通信设备故障诊断 Agent”搭一套工业 Harness

理论讲够了，说具体的。我选择”基站/交换机设备故障诊断”这个场景，因为它在通信工业中是 AI 落地频率最高的入口——告警码体系清晰、历史数据丰富、诊断逻辑相对标准化，适合作为第一个完整 Harness 的实验场。

Step 1：建索引地图，而不是知识大全

很多人第一次给 AI 搭环境，都会犯同一个错误：把所有的设备文档、历史故障案例、处理 SOP，全部整理成一个巨大文档，一股脑塞给 AI，心想”这下它什么都知道了”。

结果适得其反。信息太密集，AI 反而抓不住重点，关键约束被淹没在海量细节里，输出质量比什么都不给还要差。

这叫上下文稀释，是工业Harness最常见的第一个坑。

正确的做法是建一张索引地图。主文档只保留三类内容，整个主文档控制在 100 行以内，不写任何具体规则，只告诉 AI”遇到什么问题，去哪里找什么文档”：

• 设备分类索引（按设备型号和厂商分层）
• 告警码体系入口（按故障类型分类）
• 诊断流程导航（按处理优先级排序）

⚠工业场景特有细节工业设备的文档粒度必须精确到型号级别。同一品牌的交换机，不同代次的告警码体系可能完全不同，同一告警码在不同固件版本下的含义也可能不一样。索引只写到品牌级别，AI 面对具体设备时还是会找不到正确参考，生成”看起来对但实际上对错了型号”的诊断逻辑。互联网 Harness 的文章里几乎没有提到这一点。

Step 2：把 FDS 验收条件转化为自动化测试脚本

这是整个 Harness 体系里含金量最高的一步，也是工业 PM 最有优势的地方。不要写”AI 应该能诊断出电源故障”这种模糊描述。要写成可以被机器直接执行的断言：

测试用例 TC-001：PSU 故障诊断

输入：告警码 0x0A03，设备型号 XXX-5200G，固件版本 V3.2.1

期望输出：

fault_type : “PSU_MODULE_FAILURE”

affected_slot : “SLOT-2”

action_required: 非空字符串

severity : “CRITICAL”

response_time : ≤ 3000ms

关键转变：错误反馈不是写给人看的，是写给 AI 看的。

❌不要这样TC-001 失败，请检查输出格式。

✅要这样TC-001 失败：你的输出中 fault_type 字段值为 ‘POWER_FAULT’，不符合告警码规范 /docs/alarm-taxonomy-v3.2.json 中第 47 行定义的枚举值。请参照该文件修正字段值后重新提交。

错误信息越精确，AI 自我修复的成功率越高，人工介入的频率越低。这个细节，是工业 Harness 能否真正自动运转的关键分水岭。

Step 3：设定 AI 永远不能跨越的物理安全红线

这一步是工业 Harness 独有的，互联网场景里几乎不需要考虑。在诊断 Agent 的设计中，有一类操作必须被明确禁止：AI 不能自主下发任何会影响设备运行状态的指令，包括重启命令、配置变更、链路切换。诊断 Agent 的职责边界是”分析和建议”，不是”执行”。

这条红线不是靠提示词说清楚的。提示词可以被绕过，可以被遗忘，可以在复杂的多轮对话中漂移。正确的做法是在工具层面做硬限制——诊断 Agent 拥有的 API 权限只包括只读接口，写操作接口根本不在它的工具列表里。

把安全约束从“提示词层面的软约束“升级为“工具权限层面的硬约束“，是工业 Harness 和互联网 Harness 最本质的设计差异。

五、工业 AI PM 的新身份：意图架构师 + 安全守门人

当 AI 能够生成控制逻辑、编写诊断程序、自动处理告警，工业 PM 的价值不是消失了，而是发生了一次清晰的位移。位移的方向，是从”写规则的人”变成”定义规则边界的人”。

不可替代的事情一：把行业标准翻译成 AI 约束规则。

IEC 61131-3、GB/T 相关标准、通信行业的设备规范——这些不是 AI 能自己理解和遵守的，需要有人把它们翻译成 Harness 中的校验规则、测试用例、权限边界。这个翻译工作，需要真正懂工业的人来做。互联网 PM 做不到，AI 自己也做不到。工业背景的 PM，在这个环节有绝对的不可替代性。

不可替代的事情二：设定人类永远不会放手的判断权。

有一些决策，不管 AI 的分析多么准确、建议多么合理，最终的执行授权必须由人来给出。不是因为 AI 不够聪明，而是因为这个授权本身就是一种责任的承担，是组织对外部的承诺，是合规框架的要求。工业 PM 需要清晰地定义：哪些决策节点是 AI 的终止边界，哪些是必须人工确认才能继续的检查点。

当AI能写代码，真正的竞争力不再是“写得多快“，而是“边界定得多准“。这件事，从来都是工业PM的主场。