一个连接器替代方案通过了验证，BOM也已经更新。

可到了后续装配，现场很快遇到一个更具体的问题：

“到底从哪台机器人开始用新件？”

仓库里还有旧料；一台机器已经领料但没有装；另一台已经完成装配，正在等待测试；还有几台已经交付，是否需要处理尚未判断。

大家都知道方案改了，却很难直接回答：谁仍按旧状态继续，谁必须切换，已经做完的机器要不要返工，前面的测试结论还能不能继续使用。

“改成什么”是方案内容；“从谁开始按新状态执行”才是生效边界。

BOM 更新了，现场不一定已经切过去

图纸升版、BOM更新、参数包发布，都能说明项目已经形成一套新的正式要求。

但文件发布的时间，不一定等于现场切换完成的时间。

文件更新时，物料可能已经发到工位，机器可能已经装了一半，软件可能已经写入，测试也可能正在进行。不同对象处在不同进度，无法只靠一个发布日期自动切成整齐的前后两批。

因此，看到“最新版已发布”，还不能直接推定所有机器都已经进入新状态。

真正需要说清的是：新要求从哪些对象开始执行，切换前已经形成的状态怎样处理，以及谁负责确认切换完成。

生效边界不只问哪一天，还要问哪一台

日期可以是边界的一部分，但机器人项目通常还需要对象边界。

同一次变更，可能对后续新装机器直接生效；对已经领料但未装配的机器要求换料；对完成装配但尚未测试的机器要求检查或返工；对已经交付的机器，则需要根据风险和验证结果决定是否筛查、升级或维持原状态。

所以生效边界至少要能把两件事接起来：

哪些对象属于新状态，以及旧状态对象接下来怎样处置。

边界可以落在机器编号、生产批次、工单、配置版本或明确时间节点上。具体采用哪一种，要结合项目的执行和追溯方式；最终必须让现场能够判断当前对象属于哪种状态。

最容易漏掉的，是“半旧半新”的机器

边界最清楚的通常是两端：很早完成的机器仍是旧状态，尚未开始的机器按新要求执行。

这些处在切换中的机器，最容易被漏掉。

它可能已经按旧BOM领料，却按新图纸装配；可能换了新部件，但仍加载旧参数；也可能在变更前完成测试，交付前又做了局部返工。

这些机器不能简单归入“旧版”或“新版”。它们需要明确当前实际状态，并判断原来的测试是否仍然适用、哪些项目需要补验；否则文件虽然完成升版，现场仍会留下难以解释的过渡状态。

新版开始用了，旧状态不会自动消失

宣布新方案开始使用，不代表旧状态自然消失。

旧料是否隔离、退回或允许在限定对象上继续使用？已经装机的旧方案是否接受、返工或继续观察？历史测试结论属于哪种状态？尚未处理的对象由谁继续跟踪？

这些问题如果没有结论，团队以后仍可能把旧料重新领出、把旧测试结论套到新状态，或者把没有完成切换的机器误认为已经升级。

一次变更真正落地，需要从批准的新要求一路走到明确的对象边界：

新要求发布 → 生效对象明确 → 过渡机器处置 → 必要验证完成 → 旧状态去向收住

这条线不是为了增加一套审批，而是防止“文件已经改了”替代“现场已经切换”。

随机抽一台，能不能直接判断它现在属于什么状态？

检查生效边界是否清楚，可以做一个很轻的验证。

从在制、待测或已交付对象中随机选一台，不先问原负责人，只依据机器标识和现有记录判断：它应该执行旧要求还是新要求？当前实际状态是否符合？原测试结论是否适用？如果还处在过渡状态，下一步由谁处理？

如果这些问题能够直接回答，至少说明现有记录已经能够支持现场判断这台机器的变更状态。

如果仍要靠“这台好像是在切换前做的”“当时可能已经换过”来判断，说明项目虽然记录了新版本，却还没有真正收住生效范围。

变更是否落地，不只看新版文件有没有发布，还要看任何一台机器人都能不能被明确判断为旧状态、新状态，或者受控的过渡状态。

你们项目里的变更，最常说不清的是从哪台开始生效，还是切换中的机器该怎么处理？