很多自动化项目上线后，真正懂系统的人，往往只有少数几个工程师。

设备能运行，程序能维护，HMI 也能显示状态。
但一旦现场出现“Ready 了不动”“Waiting 查不清”“报警很多但不知道先看哪个”“MES / WCS 有记录但解释不了停滞”这类问题，最后通常还是要找熟悉项目的人。

因为他知道：

这个 Ready 只代表本机状态；
这个 waiting 实际在等上位许可；
这个报警通常是后续结果，不是源头；
这个下游 ready 不能代表真正可承接；
这个视觉 OK 超过一定时间后，就不能再用于抓取；
这个步骤虽然条件全绿，但进入后很容易卡在下一步。

这些判断非常有价值。

问题在于，它们通常存在于工程师脑子里、项目经验里、调试记录里、临时说明里，或者分散在 PLC 程序、HMI 画面、MES / WCS 状态、设备接口和现场习惯中。

项目能跑，但状态迁移设计没有形成统一结构。

现场现象

在制造现场和自动化项目中，经常能看到类似现象：

  • 同一类设备，不同工程师写出的等待逻辑不一样。
  • 同一类动作，不同项目中的异常处理路径不一致。
  • 有的项目检查信号时间戳，有的项目只检查 OK / NG。
  • 有的项目区分安全许可、上位许可和下游许可，有的项目全部压缩成 interlock。
  • 有的 HMI 能显示具体等待原因，有的 HMI 只显示“条件未满足”。
  • 有的项目会记录重试、回流、人工确认原因，有的项目只留下报警履历。
  • 新人接手后，需要重新理解 PLC 程序、HMI 画面、机器人逻辑和上位系统接口。
  • 项目复制到新产线时，同样的异常边界又要重新讨论一次。

这不说明工程师能力不足。很多现场系统能稳定运行，正是靠工程师用经验把大量隐含条件补上了。

问题是这些经验没有被整理成统一的状态迁移设计结构。

个人经验为什么会变成关键因素

状态迁移设计涉及的内容很多。一个动作能不能进入下一阶段，要同时看对象存不存在、工件位置合不合格、识别结果有没有效、前序状态完没完成、安全许可成不成立、上位放没放行、区域或资源许可成不成立、下游接不接得住、回退路径有没有、异常品能不能排出、结果能不能上传或回写、信号超没超时、当前是不是要人工确认。

这些内容不会自然集中在一个地方。有些在 PLC 里，有些在机器人控制器里，有些在视觉系统里，有些在 HMI 画面里，有些在 MES/WCS 里，有些在设备接口文档里，有些只存在于调试时的经验判断里。

系统表面上有程序、有报警、有状态、有日志，真正理解“为什么能进、为什么不能进”的人，仍然是熟悉整个项目的人。

这就是状态迁移设计长期依赖个人经验的原因。

传统控制逻辑为什么难以沉淀这类经验

传统控制逻辑围绕动作、步骤、互锁、报警、设备状态展开：step condition、interlock、ready、handshake、alarm、timeout、retry、manual reset、mode condition。

这些机制都很重要，也能支撑设备运行。但它们分散在不同位置——PLC 程序里写一部分，HMI 画面上显示一部分，机器人程序里处理一部分，上位接口里约定一部分，现场调试再补一部分。

项目规模小的时候，经验丰富的工程师能靠记忆把这些串起来。项目一复杂，条件越来越多，许可来源越来越多，设备接口越来越多，异常路径越来越多，上位与现场之间的状态关系越来越多，新人理解成本越来越高，不同项目之间复用越来越难。

状态迁移设计依赖个人经验，不是因为现场没有控制逻辑，是控制逻辑缺少统一的状态迁移表达方式。

经验依赖带来的问题

个人经验本身有价值。制造现场离不开经验。

但如果状态迁移设计过度依赖个人经验，会带来几个问题。

第一，排查路径不稳定。

同样是“不动作”，有人先查 PLC，有人先查机器人，有人先查安全，有人先查上位系统，有人先查下游设备。
排查结果依赖个人熟悉程度。

第二，设计标准不一致。

同样是视觉识别结果，有的项目检查 OK / NG，有的项目检查置信度，有的项目检查时间戳，有的项目检查工件跟踪 ID。
同样是下游 ready，有的项目只检查 ready，有的项目还检查可承接、满载、回写和异常路径。

第三，新人承接困难。

新人看到的是程序、报警、状态码和画面，但很难直接理解当初为什么这样设计。
很多判断依据没有写在结构里，只存在于老工程师的解释中。

第四，复盘价值不足。

问题解决后，如果只记录报警和处理结果，而没有记录状态迁移失败的结构原因，下次仍然要重新排查。

第五，项目复用困难。

同类设备、同类产线在新项目里重复设计。经验能迁移，缺少标准化结构时复用效率很低。

状态迁移设计需要显式化什么

要减少个人经验依赖，需要把状态迁移前的关键判断显式化。

至少需要明确以下内容。

第一，当前状态是什么。

例如等待阶段、抓取前、交接前、检测前、任务派发前、车辆执行前、模型调用前。

第二，目标状态是什么。

例如进入抓取阶段、进入压装阶段、进入检测阶段、进入交接阶段、进入任务执行路径、进入高成本推理路径。

第三，进入目标状态需要哪些条件。

包括对象条件、识别条件、任务条件、参数条件、前序状态和数据条件。

第四，进入目标状态需要哪些许可。

包括安全许可、区域许可、上位许可、资源许可、人工确认、对方设备许可。

第五，进入目标状态后执行链是否能够接续。

包括本体设备、末端执行机构、下游承接、返回路径、异常排出路径、结果上传或回写链路。

第六，相关信号是否有效。

包括时间戳、刷新周期、通信状态、信号冲突、状态切换、许可撤销和数据延迟。

第七，边界状态如何处理。

例如等待、重试、重识别、重采样、回流、降级、禁止进入、安全锁定、人工确认、异常隔离。

这些内容如果不显式化，就只能由工程师在项目中凭经验判断。

用 C / A / E 重新整理经验判断

很多工程师的经验判断，其实可以整理为 C / A / E 三类状态变量。

C：Condition，条件状态。
用于整理进入目标状态前的对象条件、识别条件、任务条件、数据条件和前序状态。

A：Authority，许可状态。
用于整理系统是否允许进入目标状态。安全许可、区域许可、上位放行、资源锁、人工确认、对方设备许可都属于这一类。

A 类状态中，关键许可应作为独立必要约束。只要关键许可未成立，即使条件和执行链看起来满足，也不应进入目标状态。

E：Execution Chain，执行链状态。
用于整理进入目标状态后，执行链是否能够接续。机器人路径、夹爪、下游承接、返回路径、异常排出路径、结果上传或回写，都属于这一类。

老工程师能快速判断问题，是因为脑子里已经隐含完成了这些区分。把它们写出来，状态迁移设计才能从个人经验变成可复用结构。

还需要 S / D / B 判定

仅仅把信号分成 C / A / E 还不够。

还需要判断问题性质。

S：Structure，结构完整性。
判断所需信号、接口、许可来源、映射关系、执行链边界是否已经定义、接入并可观测。

例如，项目中有下游 ready，但没有定义下游承接完成；有视觉 OK，但没有接入时间戳；有异常输送带，但没有接入可接收状态。

D：Dynamics，动态时序有效性。
判断信号当前是否有效、稳定、同步、未超时。

例如，视觉结果过期、状态未刷新、许可延迟、信号抖动、通信恢复后数据仍旧、设备状态处于切换中。

B：Boundary，控制边界。
判断边界状态下接下来应该怎么处理。

例如，继续等待、重试、重识别、回流、降级、禁止进入、安全锁定、人工确认或异常隔离。

S / D / B 的作用，是把经验中的“这个信号有没有”“这个状态现在还可信吗”“这种情况接下来怎么办”整理为可讨论、可记录的判定性质。

从个人经验到工程标准

状态迁移设计的目标不是否定工程师经验。经验仍然重要，但应该沉淀成可复用的设计结构。

每个目标阶段都有明确的进入条件，每个关键许可都有独立判断位置，每条执行链都有承接边界，每个状态信号都有有效性判断，每类边界状态都有控制路径，每次判定都有记录，每次异常都能复盘，新项目可以继承旧项目的判定结构而不是只复制程序片段。

这样工程师的经验才不只存在于个人脑中，而是沉淀为模板、矩阵、诊断画面、履历记录、项目标准。对新项目、新设备、新团队尤其重要。

工程结论

状态迁移设计长期依赖个人经验，根本原因在于：进入目标状态前的条件、许可、执行链、异常边界和控制路径没有被统一表达。

传统项目里这些东西分散在 PLC 程序、机器人程序、HMI 画面、MES/WCS 状态、接口文档、调试记录、工程师经验里。系统能跑，但状态迁移条件完不完整、异常边界清不清楚、执行链接不接得住，还是依赖熟悉项目的人判断。

更合理的做法，是把目标状态进入前的判断整理为前置判定节点，统一描述：

  • 当前状态和目标状态；
  • 多源状态信号；
  • C / A / E 状态映射；
  • S / D / B 判定性质；
  • 多路径控制输出；
  • 状态记录与追溯。

这样，状态迁移设计才能从个人经验，逐步转化为可表达、可审核、可复用、可培训、可承接的工程方法。

这就是 TPCA / CAE-SDB 所关注的核心问题之一。

进一步阅读

文档信息

题目 ： 为什么状态迁移设计长期依赖个人经验？
文档类型 ： 工程问题
问题类型 ： 状态迁移设计问题
版本 : Public Question Version 1.0
发布日期 : 2026-07-04
作者 : 全野南政 / Nansei Zenno
当前 URL : https://zennns.com/zh/questions/why-state-transition-depends-on-experience/