OpenClaw 如何承载工控项目开发

利用OpenClaw项目架构如何承载工控项目开发

不急着讲某个功能，而是先看整体架构。因为对工控项目来说，真正麻烦的往往不是某一段 ST 代码，而是这些东西长期散落在不同地方：

项目源码
程序框架
开发规范
电气方法论
HMI 设计规则
调试经验
培训资料
AI 调用规则
项目复盘记录

如果没有架构，AI 只能临时翻资料、临时猜上下文；有了架构，AI 才能稳定地参与 PLC 项目开发、项目立项和新员工培训。

一、整体架构：先分清“东西应该放在哪里”

当前工作区不是简单堆文件，而是按职责分层。

workspace/├── files/                  # 项目与资料资产│   ├── projects/           # 项目本体、源码、程序框架│   ├── resources/          # 规则、方法论、课程资料│   ├── documents/          # 输出文档、临时文章、报告│   └── archive/            # 历史归档│├── skills/                 # AI 可调用的能力入口├── skills-index/           # 技能目录与元数据│├── memory/                 # 每日记录，记录发生过什么├── memory-knowledge/       # 提炼后的长期知识└── MEMORY.md               # 长期架构记忆与导航

这套结构的关键不是“文件夹多”，而是每一层职责清楚。

项目源码不能塞进知识库，规则资料不能混进程序框架，临时文章不能污染长期记忆。否则时间一长，工作区就会变成一个看似丰富、实际难用的大杂烩。

二、工控项目三类核心资产

围绕 PLC 项目，目前最重要的是三类资产。

1. 项目本体：PLC-model

files/projects/PLC-model/

这里放的是 PLC 程序框架和源码。

它不是知识摘要，也不是教程，而是后续开发时真正要参考的工程资产。比如：

GVL 全局变量
FBblock 功能块
prg 流程程序
ST 代码模板
轴、气缸、电机、系统状态机等基础结构

AI 在写 PLC 程序时，首先应该读这里。

例如自动流程、CASE 步进、轴定位、气缸动作、电机控制，都要以 PLC-model 的接口和写法为准。

2. 规则资料库：plc-rules

files/resources/plc-rules/

这里放的是工控项目的方法论、规则和培训资料。

它回答的是另一类问题：

一个项目怎么立项？
点位表怎么做？
BOM 怎么整理？
电气方案怎么确认？
HMI 页面怎么规划？
调试验收怎么推进？
新员工应该按什么路线学习？

它下面保留三个子类：

rules/        # PLC/HMI 规则、任务模板method/       # 项目开发方法论operation/    # 课程讲义、教学步骤

这类资料不直接替代项目代码。它更像项目管理和工程方法的“资料底座”。

3. AI 技能入口：plc-engineering

skills/plc-engineering/

这个技能是 AI 使用前两类资料的入口。

它的作用不是保存所有正文，而是告诉 AI：

什么任务该读哪些文件
写代码时以谁为准
做项目规划时以谁为准
做 HMI 时参考哪里
做培训时参考哪里
资料冲突时怎么处理

没有这个技能入口，资料虽然都在，但 AI 仍然可能乱读、乱套、乱引用。

三、为什么一定要定义冲突优先级

工控项目资料天然会冲突。

比如：

课程资料中有一套命名规则；
历史项目框架中已经形成另一套变量结构；
HMI 规则希望页面完整；
当前项目时间紧，只允许先做核心页面；
方法论要求先做完整文档；
现场调试却要求先跑通机构。

不定义优先级，AI 很容易变成“谁说得都对”，最后输出一堆互相打架的建议。

所以当前架构中明确规定：

1. 用户当前明确要求2. 当前项目已有文档、代码和约束3. PLC-model 程序框架4. plc-rules/rules 规则资料5. plc-rules/method 方法论6. plc-rules/operation 课程讲义

换句话说：

写程序时，不能让课程资料破坏现有框架；
做立项时，不能只盯着代码而跳过点位和 BOM；
做培训时，不能直接把源码扔给新人让他自己悟。

这就是架构的价值：它不是让资料变多，而是让资料之间有秩序。

四、AI 如何利用这套架构做 PLC 开发

当用户提出 PLC 开发需求时，AI 不应该立刻写代码，而应该先判断任务类型。

如果是写程序

AI 应优先读取：

files/projects/PLC-model/README.md

然后按框架输出 ST 代码。

比如流程程序要遵守：

使用 CASE 步进；
步骤号从 10 开始，跨 10 递增；
轴、气缸、电机通过既有 Cmd 和 Tip 变量交互；
并行动作拆分为“触发步骤”和“确认步骤”；
不在流程程序里直接写系统状态；
到位确认和指令复位要清楚。

这让 AI 写出来的代码能进入现有工程，而不是另起炉灶。

如果是做项目规划

AI 应优先读取：

files/resources/plc-rules/method/

然后按项目链路输出：

需求分析
点位统计
BOM 整理
电气方案
图纸与地址分配
流程梳理
程序架构
HMI 规划
调试验收
标准化沉淀

如果是做 HMI

AI 应参考：

files/resources/plc-rules/rules/HMI-rule.md

但仍然要和 PLC 程序变量对齐。

HMI 不是孤立设计。页面按钮、状态显示、报警列表、参数输入，最终都必须落到 PLC 变量上。

如果是做培训

AI 应参考：

files/resources/plc-rules/operation/

然后按新人学习路径组织内容，而不是把所有资料一次性丢给新人。

五、项目立项：AI 不是代替工程师，而是防止漏项

PLC 项目立项阶段，AI 最有价值的地方不是“给答案”，而是做系统化检查。

比如它可以反复追问和整理：

控制对象是否拆全？
每个动作有没有命令、反馈、报警？
安全信号有没有进入系统状态？
点位是否和电气图纸对应？
BOM 是否覆盖扩展模块和安全元件？
HMI 是否有手动、自动、报警、参数、维护页面？
调试验收是否有记录模板？

这些工作看起来琐碎，但它们决定项目后面会不会返工。

工程师可以继续做判断，AI 负责把流程拉直、把遗漏暴露出来。

六、新员工培训：从“看资料”变成“走流程”

很多公司培训新人，最大问题是资料不少，但路径不清楚。

新人可能同时看到：

一堆历史程序；
一堆电气表格；
一堆 HMI 截图；
一堆调试记录；
一堆老师傅口头经验。

结果就是：资料都有，但不知道先学什么。

OpenClaw 架构可以把培训拆成三层：

第一层：项目方法

先理解项目怎么从需求走到交付。

重点看：

files/resources/plc-rules/method/

第二层：程序框架

再学习团队统一的 PLC 写法。

重点看：

files/projects/PLC-model/

第三层：模拟交付

最后用一个小项目完整走一遍：

写需求分析；
做点位表；
做 BOM；
写流程说明；
写 ST 程序；
规划 HMI；
输出调试文档。

这样培训就从“看资料”变成了“走一遍真实项目流程”。

七、记忆系统：让经验真正留下来

除了文件和技能，OpenClaw 还有记忆层。

memory/              # 每天发生了什么memory-knowledge/    # 从事件中提炼出的知识MEMORY.md            # 长期架构导航

这对工控项目尤其重要。

比如一次调试中发现：某类伺服回原必须先判断安全门状态。这个事情如果只存在聊天里，下个项目还会踩坑。

正确做法是：

当天记录到 memory/；
如果形成长期规则，再提炼到 memory-knowledge/lessons.md 或 howtos.md；
如果影响架构决策，则进入 decisions.md。

这样经验不是“记住了”，而是真的进入系统。

八、这套架构的最终目标

这套架构最终不是为了把文件整理得好看。

它的目标是让工控项目形成一个闭环：

项目资料 → AI技能 → 开发输出 → 调试反馈 → 知识沉淀 → 下个项目复用

有了这个闭环，AI 才能真正参与工程，而不是只做一个临时问答工具。

对 PLC 项目来说，它带来的变化是：

项目立项更完整；
程序开发更统一；
HMI 规划更规范；
调试经验能沉淀；
新员工培训有路径；
团队资产可以复用。

结语

工控项目的难点，从来不只是“会不会写一段 PLC 程序”。

真正难的是：

如何让项目经验不散、程序框架不乱、资料能复用、新人能接上、AI 能读懂。

OpenClaw 架构做的，就是把这些东西放到正确的位置，并让 AI 按规则调用它们。

当项目、资料、技能和记忆形成闭环，PLC 开发就不再只是一次性的工程交付，而会逐渐变成可复用、可培训、可持续优化的工控开发体系。

利用OpenClaw项目架构 如何承载工控项目开发