移交销项优先级矩阵与带病移交边界

把移交前的开放问题按运行风险和交付边界分层，不把日常调试清单、单问题编号和保修期观察项混成一个结论。

真正临近移交时，最容易出问题的往往不是“还剩多少问题”，而是“哪些问题今天必须清零，哪些问题可以带计划移交，哪些问题绝不能靠一句后续观察带过去”。如果没有一套明确的优先级矩阵，现场就会把不同性质的问题全堆在同一张清单里，最后不是过度保守，就是带病放行。

这篇内容只处理 移交前最后分层。它不替代调试问题销项清单与复测节奏这种 日常推进清单，也不替代调试记录、整改通知与复测编号联动这种 单问题主编号。这页回答的是：到了交付窗口，哪些问题必须先关、哪些问题可以带条件移交、哪些问题只能转入保修或观察计划。

矩阵先分两条轴

最实用的分法，通常是两条轴：

• 运行风险：这个问题如果现在不清零，会不会影响安全、联动、功能、连续运行或责任边界。
• 交付就绪度：这个问题现在是否已经有稳定临时措施、明确责任人、明确复测节奏和明确书面承接方式。

这两条轴交叉以后，问题大致会落在四类区间里。

四类问题怎么分

第一类：必须在移交前清零

典型特征：

• 涉及安全、送电、联锁、消防、保护、关键报警或正式运行风险。
• 没有稳定临时措施，或者临时措施本身就不可持续。
• 一旦带病移交，责任边界会立刻变得模糊。

这类问题不能靠“先接着用”带过去。

第二类：可带计划移交，但必须写清观察和复测条件

典型特征：

• 当前功能基本成立，但还需要跨班次、跨工况或首周运行继续验证。
• 已有稳定责任人、复测时间和升级门槛。
• 临时措施可控，且不会掩盖更大风险。

这类问题不是“没事”，而是 可以带着计划交。

第三类：可转入保修或优化项

典型特征：

• 不影响当前安全和核心功能。
• 已有明确记录，且不会导致接手方误判当前系统状态。
• 后续更适合作为保修、优化或体验提升项跟踪。

这类问题可以带走，但必须带着书面边界。

第四类：看似小，实际不允许混入观察项

典型特征：

• 表面只是“偶发”“轻微”“数量不多”。
• 但已经出现重复趋势、责任不清、证据不全或临时措施过重。
• 一旦移交，后面极易演变成“谁都说不是自己遗留的”。

这类问题最容易被误判，矩阵的价值就在于把它们从“先观察”里揪出来。

矩阵不是替代日常清单

日常调试清单回答的是：今天先做哪件事、谁去复测、什么时候再看

移交优先级矩阵回答的是：这件事现在到底能不能被正式带进移交边界

所以：

• 日常清单可以每天变。
• 移交优先级矩阵只在临近交付窗口时集中判断。
• 一条问题先在日常清单里推进，到了移交阶段再进入矩阵分层。

如果你把矩阵当 दैनिक清单用，现场会每天都在争论“能不能交”；如果你只用日常清单、不做矩阵，到了移交那一周就会所有问题一起拥堵。

最容易被误判成“可带病移交”的三类问题

• 重复性告警已经靠人工值守压住，但根因还没站稳。
• 参数看起来恢复正常，但趋势和复测窗口还不够。
• 现场临时旁路、手动模式、临时授权、临时挂牌还挂着，只是没再出新告警。

这些问题之所以危险，不在于它们一定马上出事，而在于一旦带过去，接手方会默认“系统当前状态已正式成立”。

矩阵评审时至少要看哪四份证据

1. 主问题编号链是否完整。
2. 最新复测和观察结论是否明确。
3. 临时措施和下一步动作是否书面化。
4. 责任边界和移交口径是否已同步到接手方。

缺少其中任何一项，矩阵结论都很容易沦为拍脑袋。

资料和规范怎么挂

• 问题主链继续挂在调试记录与整改通知编号联动台账。
• 移交讨论和责任分层，建议同步写入过程交接记录。
• 仍未关闭但允许带计划移交的事项，最好同时挂接系统调试记录和质量整改记录。
• 需要正式锁定下一步动作时，可用整改通知生成器把时限和责任写死。
• 主线控制口径可联查调试移交与验收记录、试运行台账核查、运维手册交付核查和项目管理资料。

关联页面

• 如果问题还在日常派单推进阶段，继续看调试问题销项清单与复测节奏。
• 如果当前更需要厘清一条异常到底是不是同一个问题，继续看调试记录、整改通知与复测编号联动。
• 如果移交后还要做首周稳定性复盘，继续看接管首周异常趋势复盘检查。

一句话收口：移交优先级矩阵这件事，真正要判断的不是“问题多不多”，而是 这个问题今天不清零，会不会把运行风险和责任边界一起带进正式接手。