调试记录、整改通知与复测编号联动

把一次异常的主问题编号贯穿调试记录、整改通知、复测记录和照片证据，避免每张表各起一套号。

调试阶段最容易失控的，不是没人发现问题，而是问题一旦离开最初那张表，就换了一套编号。调试记录里写的是 BAS-17，整改通知写成 整改单 032，复测表又只写“已恢复”，照片目录再按日期排。到交付或复盘时，谁也说不清这三份资料是不是在讲同一件事。

这篇内容只处理 问题级主编号联动。它不替代调试证据照片命名与取证顺序这种 照片级规则，也不替代调试问题销项清单与复测节奏这种 列表级派单节奏。这页解决的是：同一个问题，从发现到关闭，能不能一直被同一个主编号追下去。

什么时候必须生成主问题编号

• 首次发现异常，需要从“现场口头描述”转成正式记录时。
• 同一异常已经准备发整改通知或跨班组分派时。
• 同一个问题会经历多轮复测、临时措施和最终恢复时。
• 后面可能还要进周会、首周复盘、运维接手或责任追溯时。

如果只是一个无需整改、无需追踪的瞬时提示，不一定要起正式主编号；但一旦涉及整改、复测或交接，就不要再靠“今天那个问题”这种口头叫法。

主问题编号只回答一件事

主问题编号回答的是：这一整件异常，后面所有记录是不是都在追同一个对象

它至少要能把下面四条线锁在一起：

1. 调试记录里的首次发现。
2. 整改通知里的处理要求。
3. 复测记录里的验证结论。
4. 照片和截图里的证据归属。

如果这四条线里有任何一条脱离主编号，问题闭环就会开始断链。

一个主编号，不等于所有细节只剩一个号

很多团队会把“统一编号”理解成所有东西都只能有一个号，结果资料反而更难用。更稳的做法是：

• 主问题编号 只负责锁住这件异常。
• 照片序号、表单页码、整改通知单号 可以继续保留自己的局部编号。
• 但这些局部编号都必须回指同一个主问题编号。

也就是说，允许有子编号，但不允许再出现第二套平行主编号。

现场怎么联动，才不会中途换号

第一步：首次发现就把对象冻结

首次记录时，至少冻结四项：

• 系统/专业
• 区域/对象
• 异常现象
• 首次发现时间

这四项冻结之后，再给主问题编号。不要先起一个空号，后面再靠记忆补对象。

第二步：整改通知沿用主问题编号

• 整改通知可以有自己的单据号，但必须显式挂主问题编号。
• 若一张通知覆盖多个点位，应拆成一个主问题编号下的多个子项，不要把多个独立问题硬塞成一个号。
• 若同一问题跨多个班组执行，也不要因为换了责任人就重起编号。

第三步：复测记录不能只写“合格”

• 复测记录必须回写原主问题编号。
• 除了“是否恢复”，还应写本轮复测条件、是否同工况、是否再次出现。
• 多轮复测允许保留 Q023-R1 / R2 / R3 这类轮次标识，但主问题编号 Q023 不能丢。

第四步：照片和截图围着主编号转

• 文件名、编号板或记录表里都应带主问题编号。
• 同一问题的动作前后、整改前后、首次发现和复测，不应各拍各存。
• 如果当天照片很多，可再按 主问题编号 + 序号 管理，而不是重新发明一套照片主号。

哪些情况不能共用一个主问题编号

• 现象相似，但对象不同，且整改动作不同。
• 同一区域同时爆出多个独立缺陷，后续责任和复测路径不同。
• 前一个问题已经闭环，后续再次发生但根因、触发条件和处理动作都不同。

“看起来很像”不等于必须共用一个号。共用过度，后面会让每条证据都变得模糊。

最常见的断链点

• 整改通知另起一套编号，主问题号只留在原始调试记录里。
• 复测记录只写“已恢复”或“正常”，不回写原主问题编号。
• 照片按日期归档，无法反查到具体问题号。
• 同一问题跨班组交接时，被下一班当成新问题重新起号。
• 周会纪要和现场台账分别维护，两边号不一致。

资料和规范怎么挂

• 现场主台账直接使用调试记录与整改通知编号联动台账。
• 整改执行和闭环动作，继续挂到质量整改记录。
• 若当前问题还处在系统调试过程里，首次发现和复测条件最好同步写进系统调试记录。
• 控制口径优先查调试记录与整改通知编号联动控制。

关联页面

• 如果你现在主要卡在照片怎么命名、怎么拍成一组，先看调试证据照片命名与取证顺序。
• 如果你现在已经有很多主问题编号，下一步要做派单和复测节奏，继续看调试问题销项清单与复测节奏。
• 如果异常跨多轮调参和多班组处理，想把动作顺序补完整，再接异常事件分钟级时间线模板。

一句话收口：编号联动这件事，真正要守住的是 同一件异常只认一个主问题编号，其他所有表和证据都围着它转。