HCP 在 AI 时代的一些思考

过去，我们习惯把工业软件开发理解为一条由工程师驱动的流水线：理解需求、设计功能块、编写代码、编译、调试、测试，最后部署到设备。生成式 AI 出现之后，这条流水线最先发生变化的，是“写代码”这一步。

AI 可以很快生成一个滤波器、保护逻辑或控制模块，也可以解释接口、补全代码、修改变量。代码生成的速度被显著提高之后，一个更现实的问题开始浮现：在工业控制和电力控制保护领域，真正制约软件交付效率的，往往并不是“代码能不能写出来”，而是“写出来之后能不能被验证”。

尤其是控制保护软件，它不是一般意义上的业务系统。它运行在固定扫描周期、确定采样链路、受限嵌入式资源和严格工程规约之上，最终还要面对现场工况、异常边界和安全责任。一个功能块看起来逻辑正确，并不代表它能在目标平台上稳定编译、可靠运行，更不代表它在故障、闭锁、复归、边界输入和时序约束下都满足要求。

因此，我们对 HCP 在 AI 时代的判断是：AI 不应只是新的代码编辑器，它应当成为受工程约束、能够获得验证反馈的开发参与者。HCP 的价值，也不只是承载更多算法，而是为人和 AI 提供一套共同的工程语言与验证闭环。

一、工业控制软件的难点，不只是开发，更是让 AI 真正进入工程流程

在讨论验证之前，HCP 其实已经在更早阶段遇到了一个问题：即使大模型具备不错的代码生成能力，它也很难直接完成一个完整工业控制工程的开发。

第一个现实限制来自上下文窗口。工业控制项目天然具有规模大、周期长、约束多的特点，一个实际工程往往包含大量功能模块、接口定义、通信配置、控制逻辑以及各种运行约束。即便是当前能力较强的大模型，也很难一次性理解整个工程的全部上下文，更难在持续迭代过程中始终保持一致的设计思路和实现风格。如果直接让 AI 面对一个完整工程，它很容易陷入局部正确、整体失真的状态。

为了解决这一问题，HCP 很早就采用了功能块开发 + 可视化集成的两段式开发模式。一个完整工程被拆分为多个职责清晰、边界明确的功能块，每个功能块都聚焦于一个相对独立的问题，例如滤波器、保护判据或控制逻辑单元。这样一来，AI 不需要理解整个工程，而只需要围绕单个功能块完成需求理解、代码生成和逻辑修改。复杂工程被拆解为模型能够完整掌握的开发单元，而功能块之间又通过标准化接口保持连接，最终仍然能够通过可视化方式完成整体集成。从今天回头看，这种架构设计几乎天然适合 AI 参与开发，因为它恰好契合了当前大模型最擅长处理的任务规模。

然而，解决了上下文问题之后，新的挑战又出现了。即使 AI 能够生成逻辑正确的代码，它仍然无法直接生成 HCP 平台所要求的标准化功能块。HCP 功能块不仅包含代码本身，还包含变量定义、接口描述、类型信息、工程元数据以及符合平台规范的 POU 结构。早期实践中，我们尝试通过 MCP 将 AI 接入 HCP BlockEditor，希望模型能够像工程师一样操作开发工具，创建变量、编辑代码并保存功能块。但实际效果并不理想，问题并不在于工具本身，而在于当前阶段的大模型并不擅长长期稳定地操作面向人类设计的图形界面。它需要理解界面布局、识别控件状态、执行复杂交互，并持续维护操作上下文，这种方式不仅效率低，而且容易出现不可预测的问题。

本质上，GUI 是为人设计的，而不是为 AI 设计的。因此，我们后来调整了思路：既然 AI 不擅长操作图形界面，那么就应该为 AI 提供更适合机器调用的接口。基于这一思路，HCP 单独开发了 HCP BlockEditor CLI，将功能块创建、变量管理、类型定义、代码编辑和结构检查等能力全部封装为确定性的命令接口。AI 不再需要模拟点击按钮或寻找菜单，而是直接调用命令完成操作。这样不仅能够稳定生成符合 HCP 规范的标准功能块，使其立即进入工程集成流程，同时所有操作都具备确定性和可追溯性，也更容易与后续验证链路形成自动化闭环。从实践结果来看，CLI 的效果远好于让模型直接操作 GUI，它真正让 AI 获得了参与 HCP 工程开发的能力。

但当 AI 可以稳定生成标准功能块之后，一个更核心的问题开始浮现：如何证明这些功能块是正确的？至此，问题的重心开始从“开发”逐渐转向“验证”。

二、Skill：让 AI 真正理解 HCP RTExec 引擎

对于工业控制软件而言，功能块并不是脱离运行环境独立存在的代码片段，它必须依赖底层运行时引擎完成调度、状态管理、数据访问以及系统服务调用。在 HCP 中，功能块最终运行于 HCP RTExec 引擎之上，因此如果希望 AI 能够编写出真正可以投入工程使用的功能块，仅仅掌握 C 语言语法或控制逻辑知识远远不够，更重要的是理解 HCP RTExec 引擎提供的能力边界以及这些能力背后的工程语义。

这正是 Skill 发挥作用的地方。Skill 可以被理解为面向 AI 的工程知识体系，它不仅包含接口文档，更包含接口函数的使用场景、参数含义、调用约束、典型错误以及与运行机制相关的背景知识。通过 Skill，AI 不只是知道某个接口如何调用，更能够理解为什么要调用、应该在什么时机调用以及调用之后会产生怎样的行为。与此同时，Skill 还能够沉淀大量经过工程验证的功能块 Demo。这些 Demo 并非简单的示例代码，而是长期实践中形成的设计模式和最佳实践，涵盖变量组织方式、状态机设计方法、异常处理策略以及接口调用习惯。AI 可以从这些经过验证的实现中学习工程风格，从而生成与现有系统保持一致的功能块。

这种方式带来的价值在于，AI 不再只是根据自然语言猜测实现方案，而是在充分理解 HCP RTExec 引擎能力边界和工程规范的基础上进行开发。生成的功能块不仅逻辑正确，而且能够符合平台要求，顺利进入后续代码生成、编译和运行流程。从这个角度看，Skill 的目标并不是简单地向模型灌输更多知识，而是把原本掌握在资深工程师手中的引擎经验、接口语义和最佳实践系统化地传递给 AI，使其能够按照 HCP 的工程标准开展开发工作。

然而，即便如此，AI 生成代码的速度越快，验证的重要性反而越突出。传统开发中，代码编写往往是项目节奏的主要瓶颈，而当 AI 将这一环节大幅加速之后，需求是否表达准确、接口是否符合规范、行为是否满足预期以及修改是否引入回归问题，开始成为新的关注重点。在工业控制和能源电力场景中，这种变化尤为明显。AI 生成的代码可能语法正确、逻辑合理，但仍然可能忽略平台规范、状态保持机制、扫描周期约束以及各种边界条件处理，甚至无法通过真实的代码生成和交叉编译流程。更常见的情况是，它能够满足简单样例，却无法满足实际保护逻辑对于时序和行为的严格要求。

大模型擅长给出“看起来正确”的答案，但工业工程需要的是“能够被证明正确”的答案。两者之间缺少的并不是更长的提示词，而是一条机器能够执行、能够持续反馈结果的验证链路。尤其是在控制保护软件领域，验证本身就是最昂贵、最复杂的环节。验证一个功能块是否正确，不仅要确认接口和数据类型符合工程模型，还要确认代码能够通过真实代码生成流程、能够通过目标工具链编译和链接，并且在初始化、复位、闭锁、异常输入以及各种复杂采样条件下都表现稳定。同时，还必须验证动作延时、复归逻辑、状态保持以及修改后的回归风险。这些问题很难依靠人工走查彻底解决，也很难通过简单脚本一次性覆盖。

因此，HCP 在解决 AI 开发能力之后，开始把重点转向另一个问题：怎样让 AI 不只是生成代码，而是在明确的工程边界内修改代码，并通过可运行、可复现、可追溯的验证结果来证明修改是否成立。

三、HCP Verify：为 AI 建立一条可运行的反馈回路

如果说 Skill 解决的是“应该怎么做”，那么 HCP Verify 解决的就是“如何证明做对了”。

HCP Verify 面向单功能块提供了一条从工程模型到行为验证的完整路径：

POU 功能块
  → 结构校验
  → poucodegen 生成 C 代码与测试适配器
  → ARM GCC 编译和链接检查
  → 构建主机侧 dut_runner
  → 冒烟运行
  → Python DSL 注入输入与采样数据
  → 对输出、时序和状态行为做断言
  → 将诊断反馈给 AI 或工程师

这条链路的意义并不仅仅在于增加了一套测试工具，而在于把原本分散在不同阶段、依赖不同人员完成的验证活动连接成了一条连续的反馈回路。首先，它验证的是 HCP 实际使用的工程对象，而不是 AI 临时生成的一段孤立代码，POU 中的接口、数据类型以及功能块代码都会进入真实的代码生成流程。其次，它同时覆盖目标侧与主机侧验证，既能够确认代码是否能够进入实际工程工具链，也能够快速构造输入、驱动功能块并观察行为输出。更重要的是，Python DSL 将行为预期转化为可执行规格，使测试不再停留在人工描述层面，而能够直接表达输入波形、控制操作以及各种时序约束，并通过断言验证输出行为是否符合要求。

在这样的体系下，AI 获得的不再是一个模糊的“测试失败”，而是明确的失败原因和失败阶段。它能够知道问题究竟出现在 POU 结构、代码生成、编译链接、初始化过程还是具体的行为断言上。反馈越具体，AI 后续修改的范围就越小，修复过程也越具有针对性。对于工程师而言，这意味着验证不再完全依赖个人经验，而是能够逐步沉淀为可复用、可执行、可审查的工程资产，并持续参与后续开发过程。

四、HCP 在 AI 时代可以继续演进的几个方向

基于现有 Skill 与 HCP Verify 所形成的闭环，我们认为 HCP 在 AI 时代仍然存在广阔的演进空间。

1. 让自然语言需求更顺畅地落到可执行规格

未来一个重要方向，是让自然语言需求能够更加自然地转化为可执行规格。AI 可以协助工程师将需求描述转换为变量定义、状态机约束以及 DSL 测试草案，但关键阈值、时间窗口和故障语义仍然需要工程师确认。对于控制保护软件而言，先形成可验证的测试规格，再生成具体实现，往往比先写代码再反向推测需求更加稳健，也更符合工程验证的思路。

2. 让验证结果成为持续积累的数据

另一个重要方向，是让验证过程本身成为知识积累过程。每一次生成、编译、修复和测试都会产生大量有价值的信息，如果能够将失败阶段、诊断结果、修复方式以及最终验证证据结构化保存下来，HCP 将逐步形成面向自身工程领域的高质量经验数据。这些数据不仅能够帮助工程师分析质量趋势，也能够为未来 AI 提供更加贴近实际工程场景的参考依据。

3. 从单功能块验证扩展到组合与系统行为

当前的单功能块验证非常适合作为 AI 闭环中的快速反馈机制，但随着能力提升，验证范围还可以进一步扩展到功能块组合、任务调度、通信交互、资源约束乃至硬件在环测试等更高层级的系统行为。单块验证解决的是局部正确性问题，而系统级验证则关注整体协同与运行稳定性，两者结合才能真正支撑复杂工业控制系统的可靠交付。

五、我们真正想构建的，不是一个“会聊天的 IDE”

把聊天窗口放进开发工具并不困难，困难的是让一次对话真正进入工程生命周期，并能够对最终交付结果产生实际价值。

理想中的 HCP AI 开发体验应该是这样的：工程师描述目标，AI 读取当前功能块与项目上下文，调用 HCP BlockEditor CLI 创建或修改标准功能块；随后通过 HCP Verify 自动执行结构检查、代码生成、编译以及行为验证；如果失败，它能够根据具体诊断继续修复；如果成功，它交付的不仅是一份代码，还包括完整的测试与验证证据。整个过程中，工程师始终能够看到 AI 为什么这样修改、验证了哪些内容以及还有哪些风险尚未覆盖。

这并不是让 AI 变得绝对可信，而是让 AI 的工作过程变得可审查、可复现、可否决。对于电力控制保护平台而言，这种能力远比单纯的代码生成更加重要，因为平台最终需要支撑的是长期工程交付、现场运行以及问题追溯，而不是一次性的技术演示。

结语：AI 负责提出可能，工程系统负责建立可信

AI 让软件生产第一次拥有了近乎无限的“候选实现”供给能力。但对于工业系统而言，候选方案的数量从来不是最终价值，真正重要的是能够快速识别错误、验证行为并沉淀证据，从而让系统从“能够生成”走向“能够交付”。

回顾 HCP 的实践路径，我们实际上经历了三个阶段：首先，通过功能块开发与可视化集成的两段式架构，将复杂工程拆解为 AI 可以理解和处理的开发单元；其次，通过 HCP BlockEditor CLI，让 AI 能够直接操作工程对象，生成符合平台规范的标准功能块；最后，通过 Skill 与 HCP Verify 建立完整验证闭环，使 AI 的每一次修改都能够接受工程验证并获得明确反馈。

Skill 让 AI 理解边界和规则，CLI 让 AI 真正具备操作工程对象的能力，HCP Verify 则让所有结果都能够接受验证和审查，而工程师始终掌握目标、风险以及最终决策权。当“生成—验证—反馈—修复”成为日常开发节奏时，AI 才真正从一个善于回答问题的工具，成长为能够参与可靠工程建设的伙伴。而这或许也是 HCP 在 AI 时代最重要的方向：不是让 AI 替代工程体系，而是让 AI 在工程体系中获得可信的工作方式。