很多自动化项目投入运行以后，真正熟悉系统整体运行逻辑的往往只有少数几名工程师。
设备可以正常运行，PLC 程序有注释，HMI 也能显示状态和报警。
但现场出现下面这些情况时：
- Ready 已经成立，但系统没有进入下一阶段；
- Waiting 持续较长时间，但无法直接判断正在等待什么；
- 多个系统都没有明显故障，但整体流程仍然无法继续；
- 异常已经解除，系统却没有恢复到预期执行状态；
现场通常仍需要熟悉项目整体逻辑的工程师判断。
很多关键关系并没有被完整表达在系统中，例如：
这个 Ready 只表示本机状态。
这里还需要另一个系统的许可。
这个状态虽然显示正常，但已经不是当前有效状态。
下游虽然在线，但当前还不能承接。
异常虽然已经解除，但系统还没有恢复到可以继续执行的状态。
这些判断本身就是工程知识。
长期的问题在于：
决定系统能否进入下一状态的关键知识，往往分散在程序、接口和少数工程师的经验中。
1. 程序存在，不代表状态迁移判断已经表达清楚
复杂自动化系统通常已经有大量程序、状态和控制机制，例如：
- PLC 顺序程序；
- Interlock；
- Handshake；
- 设备 Ready；
- 报警；
- 上下游接口；
- MES / WCS 状态；
- 调试参数；
- 异常恢复逻辑。
这些内容共同支撑系统运行。
但一次状态迁移所需要的判断关系，往往分散在不同位置：
- 一部分写在 PLC 程序中；
- 一部分来自上位系统；
- 一部分存在于设备接口中；
- 一部分形成于调试规则和项目习惯；
- 还有一部分由熟悉系统的工程师掌握。
所以，即使程序和文档都保留下来，新工程师接手以后仍然需要重新理解：
为什么这里可以继续，为什么那里必须等待。
需要确认这些状态迁移判断是否已经被明确表达。
2. 工程经验需要转化为可以继承的定义
工程经验本身非常重要。
复杂设备能够稳定运行，本来就依赖设计、调试和现场工程师长期积累的判断能力。
这些经验是否已经转化为可以长期保存和复用的工程定义？
如果没有，项目中就容易出现：
- 同类设备由不同工程师设计后，等待和异常处理方式不同；
- 项目交接以后，需要重新阅读大量程序才能理解关键逻辑；
- 相同问题在新产线再次出现时，需要重新讨论；
- 某次问题虽然已经解决，但只留下程序修改结果，没有留下原始判断依据；
- 系统运行多年以后，越来越少的人能够解释某些控制条件为什么存在。
长期最难继承的，往往是：
当初为什么这样设计。
3. 状态迁移判断最容易沉淀在个人经验里
复杂自动化系统中的很多判断，最终都会回到一个具体问题：
系统当前能否进入下一目标状态？
例如，机器人准备进入抓取阶段时，可能同时需要确认：
- 工件状态；
- 识别结果；
- 设备状态；
- 安全许可和区域许可；
- 上位系统状态；
- 下游承接状态；
- 与本次抓取有关的其他状态。
这些信息可能来自不同控制器、不同系统和不同责任主体。
如果这些关系没有按同一个目标状态入口整理，系统能否继续推进就容易依赖熟悉整体关系的工程师判断。
因此，个人经验最容易集中在：
一次状态迁移为什么可以成立，或者为什么不能成立。
4. 为什么系统越复杂，越容易依赖个人经验？
随着自动化系统复杂度提高，PLC、机器人、MES、WCS、安全系统、视觉系统以及各种设备接口越来越多。
一次状态迁移需要参考的状态也随之增加。
例如，一个设备能否进入下一阶段，可能同时涉及：
- 当前对象和工艺条件；
- 安全许可、区域许可和上位系统放行；
- 不同设备之间的 Handshake；
- 当前状态是否仍然有效；
- 下游是否能够继续承接；
- 当前路径无法继续时，是否存在等待、回流或异常处理路径；
- 多个条件同时出现时采用什么优先顺序；
- 异常解除以后，从哪个状态恢复运行。
这些逻辑通常不会集中在同一个地方。
有些写在 PLC 顺序程序中，有些来自机器人或设备接口，有些由 MES / WCS 提供，还有一些形成于调试过程中。
单独看每一段程序，都可能很清楚。
到了整条状态迁移链上，就需要把这些分散的状态联系起来，判断当前到底能不能继续。
项目规模较小时，熟悉设备的工程师通常可以把这些关系记住。
系统扩大以后，一个状态迁移可能同时跨越几台设备、几个控制器和多个上位系统。此时，熟悉项目的工程师实际上还在做一件程序和画面没有完整表达的工作：
把分散在各处的状态关系组合起来，判断当前状态能不能继续向下推进。
这部分关系如果没有在设计阶段整理清楚，后面就会逐渐变成项目经验。
所以很多复杂项目运行几年以后，经常出现一种情况：
PLC 程序还在，HMI 画面还在，报警记录也在，但遇到特殊状态时，还是要找当时参与调试的人确认。
比如：
为什么这个 Ready 已经成立了还不能动作？
为什么这个条件消失以后还要继续等待？
为什么报警已经复位，设备还不能恢复？
为什么两个设备都正常，交接却没有发生？
这些问题通常涉及多个状态之间的组合关系。
系统复杂以后，这些关系越来越多。其中一部分没有明确写进设计资料，后续能够完整理解的人就会越来越少。
5. 把目标状态入口作为明确的设计对象
处理这类问题，可以先把一次具体的状态迁移单独拿出来。
例如：
当前状态：机器人等待
目标状态：进入抓取阶段
围绕这一次状态迁移，把进入抓取阶段前需要确认的内容整理出来。
至少包括：
- 当前处于什么状态；
- 准备进入什么目标状态；
- 哪些现场条件需要成立；
- 哪些许可需要成立；
- 进入以后相关设备和下游能否继续执行；
- 参与判断的状态当前是否有效；
- 当前不能进入时，可以进入哪些处理路径；
- 本次判断和处理结果需要记录哪些内容。
这样做以后，一次状态迁移就有了明确的设计范围。
原来分散在 PLC、机器人、安全系统、MES、WCS 和下游设备里的状态，也可以按照这一次迁移重新整理。
项目交接时，就可以根据明确的状态迁移设计理解系统运行逻辑，而不必完全依赖原项目人员口头说明。
这对设备长期维护、产线复制、跨团队协作和工程复用都有直接价值。
6. 除了“怎么改”，还要留下“为什么这样设计”
个人经验可以快速解决具体问题。
如果问题处理后只留下程序修改履历，系统里仍会继续积累隐含判断。
完整的状态迁移设计还需要留下：
为什么这个状态允许进入，为什么那个状态不能进入。
这些判断被明确记录以后，工程经验才有可能从个人记忆转变为可以长期维护、复用和交接的工程知识。
进一步如何通过 PCN、PCN Trace 和状态迁移结构组织这些信息，可继续阅读：
工程结论
自动化系统越复杂，决定下一步能不能执行的条件就越容易分散在 PLC、设备接口、上位系统和调试经验中。
程序和信号都还在，并不代表后来的人还能马上看懂为什么这里可以继续、那里必须等待。
状态迁移设计需要把这些关系围绕具体目标状态整理清楚，包括进入条件、许可、后续执行条件以及不能进入时的处理路径。
这样，原来依赖熟悉人员解释的内容，才能变成可以维护、交接和复用的工程定义。
TPCA / PCN 就是沿着这个思路，把状态迁移入口作为明确的工程设计对象。
进一步阅读
文档信息
题目：“为什么状态迁移设计长期依赖个人经验？”
文档类型：工程问题
问题类型：状态迁移设计问题
版本：Public Question Version 1.3
首次发布日期：2026-07-04
最后更新：2026-10-06
作者：全野南政 / Nansei Zenno
当前 URL：https://zennns.com/zh/questions/why-state-transition-depends-on-experience/