工艺修订
工艺开发process revision
异常发生后回过头改工艺文件——闭环的最后一环，也最容易断。
AI 工程师视角
事后复盘产出的 action item：真正的价值不在报告写得多好，在于有没有变成合入的修改。链路越长，越容易停在报告阶段。
质量异常查清原因之后，真正让组织变好的动作是把结论写回文件。改哪一份，取决于根因在哪一层：
| 根因 | 修订对象 |
|---|---|
| 性能目标本身定得不合理 | 内控标准 |
| 跨工序的控制思路有问题 | 控制要求 |
| 某道工序参数不合适 | 工艺卡 / 工艺规程 |
| 现场根本执行不了 | 工艺卡（可执行性） |
| 判据本身有歧义 | 技术协议（下次签订时） |
这一环最容易断。异常处理完、产品处置完，事情看起来就结束了，修订往往被推迟或遗忘。结果是同一类问题反复出现，每次都重新查一遍。
修订链路长也是断裂的原因之一：从发现异常到确认根因到修订文件到新版本生效，可能跨越几个部门和好几周。链路越长，中途丢失的概率越大。
对做质量类 AI 的人来说，这里有个反直觉的判断：溯因能力再强，如果结论回流不到文件，价值就会大打折扣。闭环的价值不在查得多准，在改得多快。