全部逻辑挤在 OB1
主程序几百个网络，没有功能划分，任何改动都要通读全篇才能判断影响范围。
什么样的程序需要重构：不是“写得不好看”，而是已经产生实际成本——改一处崩三处、新人三个月上不了手、停线排查靠猜、同一个故障反复出现、想加一个功能发现无处下手。出现三条以上，重构的投入通常一年内就能从停机和人力里省回来。
六个典型症状
变量名是裸地址
M10.3、DB2.DBD14、VW100 直接写在逻辑里，没有符号名，也没有单位与量程说明。
同一动作多处实现
同一条工艺在不同工位各写一遍，改一处漏三处，版本之间开始漂移。
报警只有缩写
报警文本是“E-07”“故障3”，操作工看不懂，排查全靠老员工的经验。
参数不在配方里
工艺参数散落在 DB、HMI 和纸质记录里，换型靠手抄，容易出错。
没有版本管理
程序只存在一台笔记本上，文件名是“最终版-改3-真的最终”。
重构怎么走
六个阶段，每个阶段都有可验收的产物；不要求一次停线做完。
- 基线建档（1–2 天）：读取并归档原程序，记录关键动作的节拍与参数，录屏存证。之后所有比对都以这份基线为准。
- 结构测绘（3–5 天）：画出实际调用树与数据流，标出重复实现、死代码、跨块耦合点，形成《重构范围与风险清单》。
- 规范定义（2–3 天）：和你们的维护负责人一起定命名规则、块划分粒度、接口约定、报警编号规则——规范要能被你们的人执行，不是我们单方面规定。
- 分段重构（主体工作）：按设备单元或工位逐个拆分为 FB，统一接口，参数进配方 DB，报警集中到报警表。每拆完一段，在仿真或备用 CPU 上做行为比对。
- 验证与回归：逐工位验证动作顺序、互锁、急停与安全回路；输出《行为差异清单》，任何与原来不同的地方都单独列出并说明原因。
- 交付与交接：程序包、变量字典、功能说明、版本库、改动指南；用半天时间对着你们的工程师走一遍代码。
交付物清单
重构后程序完整工程 + 可上载的归档包
变量字典符号名 / 地址 / 类型 / 单位 / 量程 / 所属单元
块结构说明调用树、每个 FB 的职责与接口
报警表编号规则、触发条件、处置建议
行为差异清单与原程序的逐项对比及原因
版本库Git 仓库或版本化归档，含提交说明
改动指南以后加功能该改哪里、不该改哪里
三档规模（未税）
按程序行数、工位数与耦合程度综合判断，最终以评估后的书面报价为准。
| 档位 | 适用范围 | 参考价 |
|---|---|---|
| 小规模 | 单台设备、≤3,000 行、≤2 个工位 | ¥28,000 – 45,000 |
| 中规模 | 单条线、3,000–10,000 行、3–8 个工位 | ¥45,000 – 120,000 |
| 大规模 | 整线或车间、>10,000 行、多单元联动 | ¥120,000 – 300,000 |
值得做
设备还要用五年以上；每年因程序问题停机超过 3 次；要接 MES / 上位机 / 数据采集；要把维护交给内部团队或第三方；准备做出口或多语言。
设备还要用五年以上；每年因程序问题停机超过 3 次；要接 MES / 上位机 / 数据采集；要把维护交给内部团队或第三方；准备做出口或多语言。
不建议做
设备两年内报废或整体替换；只是为了“看起来规范”没有实际问题；程序本身很小（几百行）且无扩展需求——这种情况做文档化就够了。
设备两年内报废或整体替换；只是为了“看起来规范”没有实际问题；程序本身很小（几百行）且无扩展需求——这种情况做文档化就够了。
一条边界：重构只改结构，不改工艺。如果评估中发现工艺逻辑本身有缺陷（互锁缺失、安全回路依赖软件、节拍与机械不匹配），我们会单独列出来，由你们决定是否另立改造项目——不会顺手改掉再告诉你。