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