仓储机器人进场第三天，集成商按昨天的培训手册打开调试 App，发现地图按钮换了位置。研发昨晚发布了新构建，下载短链自动指向最新版。新版本修了一个遥测问题，却同时调整了任务配置界面。

现场已经按旧版跑过一半用例，今天的截图、操作步骤和结果突然不能直接比较。项目经理问是否需要全部重测，研发只回答：“最新版肯定更好。”

项目验收不验证抽象的“最好版本”，它验证双方同意的具体基线。

研发节奏和项目节奏不是同一只钟

研发按缺陷、迭代和发布窗口前进，项目现场按进场、联调、试运行、验收和签字前进。一个构建在研发侧成为最新，不等于它已经通过该仓库的地图、接口、流程和安全验证。

AMR 项目还涉及机器人软件、车队管理、地图、任务配置、上位系统接口、现场网络和安全设置。MiR 的官方支持页把资料覆盖到大型现场规划、调试与高级功能，软件页也区分机器人软件、车队管理和分析能力。这表明现场交付本来就是多系统工程。

手机或平板 App 只是其中一个操作入口，不能用它的“最新”替代整套项目基线。

自动跟随最新适合发现问题，不适合签字

在日常探索测试中，动态入口可以让测试人员尽快拿到当前构建。到了进场联调和正式验收，入口应固定到经过批准的版本。否则同一个二维码在不同日期对应不同软件，测试记录无法证明当时验证了什么。

蒲公英渠道链接支持自动跟随最新版本，也支持固定特定版本。项目团队可以把“研发试用渠道”和“现场验收渠道”分开：前者允许快速更新，后者必须经过变更审批后切换。

固定并不等于拒绝修复。发现阻断问题时，可以提出候选修复版，在旁路环境验证，再形成新的验收基线。关键是切换必须可见、有批准、有影响评估和回退点。

验收基线必须覆盖 App 之外的组件

最小基线至少包含机器人型号与序列号、机器人系统软件、车队管理版本、地图与配置版本、调试 App 构建、上位系统接口版本、现场网络与关键参数。若有安全控制器或第三方设备，也要列入。

每次测试记录引用基线编号，并注明用例、时间、操作人和结果。截图上最好能看到关键版本或设备标识，避免几周后只剩一张无法定位来源的界面。

蒲公英可以提供 App 固定版本链接、更新说明与发布记录；机器人与车队软件、地图、接口和安全设置仍由项目配置库与验收文档管理。两边用同一基线编号关联。

新版本进入现场要过一道变更门

候选版本先说明为什么要进场：修复阻断缺陷、满足合同功能，还是普通优化。普通优化通常可以留到验收后，避免无意义扩大测试范围。

随后评估影响：哪些页面、接口、权限和用例会变化；机器人、车队或地图是否也要升级；旧结果能否沿用。完成旁路回归后，由研发、测试、项目和客户代表按约定批准。

批准后再把验收渠道从旧构建切向新构建，发布新的基线编号和变更说明。蒲公英的通知或 Webhook 可以提醒相关人员发生了应用更新，但不能替代项目审批，也不能自动判断旧结果是否仍有效。

进场到签字的七步版本流程

第一步，进场前冻结初始基线，保存 App、机器人软件、车队、地图和接口信息。第二步，在现场用真实网络和设备完成冒烟测试，确认安装、登录、连接与基本任务。

第三步，把集成商验收入口固定到批准 App 构建，页面写明项目、版本、用途和负责人。第四步，所有测试记录引用同一基线，问题单不得只写“最新版”。

第五步，出现阻断缺陷时建立候选分支，先在不影响主验收的环境验证。第六步，变更批准后更新固定渠道和基线文档，明确需要重跑的用例。

第七步，验收签字时归档最终基线、遗留问题和后续升级计划。签字后升级进入运维流程，不继续沿用临时项目群的发包方式。

集成商切换版本前的十项问题

• • 当前入口是动态最新版还是固定验收版？

• • App 构建是否与机器人、车队和地图基线对应？

• • 新版本进入现场的理由是否足以打断验收？

• • 改动影响哪些接口、权限、用例和培训资料？

• • 是否在旁路环境完成真实设备回归？

• • 切换由谁批准，客户是否需要知情或签字？

• • 哪些旧测试结果可以保留，哪些必须重跑？

• • 通知到达是否被错误当成批准完成？

• • 回退时固定渠道、配置和机器人软件怎样恢复？

• • 最终基线是否进入项目档案与售后系统？

还有一类变更需要单独处理：现场为了临时排障而使用工程构建。它可以在限定设备和时间内验证假设，却不能因为问题暂时消失就直接成为验收版。排障包应有明确标识、访问对象和到期动作，验证完成后回到正式候选流程。否则项目会多出一条没有文档、没有批准、只有现场工程师记得的“特殊版本”。

验收后的升级也不能继续依赖项目群。进入运维期后，应重新定义发布窗口、现场联系人、回归范围、故障回退和服务记录。项目基线是运维的起点，不是让系统永远冻结；只是后续每次变化仍要能说清前后版本与责任。

“永远跟随最新版”听起来省维护，实际是把每一次研发发布都变成潜在的现场变更。验收阶段最宝贵的不是版本新，而是结果可以重复、差异可以解释、签字对象可以确定。

蒲公英能提供动态或固定渠道、版本记录、通知和事件接口。项目团队应利用这些能力把研发与验收分流，而不是把自动更新当作批准机制。

仓储机器人进场后，更新仍然可以发生，只是每次更新都要经过项目事实。最新版可以等待，验收基线不能漂移。

引用链接

1. 1. 蒲公英：应用渠道[1]

2. 2. 蒲公英：应用版本 API[2]

3. 3. 蒲公英：应用版本更新通知[3]

4. 4. 蒲公英：Webhook 设置[4]

5. 5. MiR：支持门户与调试资料[5]

6. 6. MiR：机器人、车队与分析软件[6]

引用链接

[1] 蒲公英：应用渠道: https://www.pgyer.com/doc/view/app_channel[2] 蒲公英：应用版本 API: https://www.pgyer.com/doc/view/api_version[3] 蒲公英：应用版本更新通知: https://www.pgyer.com/doc/view/receive_app_notification[4] 蒲公英：Webhook 设置: https://www.pgyer.com/doc/view/webhook[5] MiR：支持门户与调试资料: https://mobile-industrial-robots.com/support-portal[6] MiR：机器人、车队与分析软件: https://mobile-industrial-robots.com/products/software/