无人零售柜换运营主体：下载入口迁移后，谁负责旧账号、旧链接和现场 App？

一批无人零售柜从原运营商移交给新的城市服务商。App 由原团队发布，现场手机仍保存旧账号，柜机云端、支付配置和商品后台分属不同负责人。大家以为把应用迁到新蒲公英账号就算交接完成，第二天却发现旧客服卡片还在流转。

还有一个容易被忽略的口径问题。页面访问可以说明入口被打开，下载可以说明文件被获取，但后续是否安装、登录、连接无人零售柜并完成真实任务，需要来自 App、设备云、业务后台或人工回执的下一层证据。不同系统的时间窗口、去重方式和失败重试也可能不同，不能把几组数字直接相减后写成"转化率"。

如果团队要做周报，稳妥的写法是分别呈现各层事实：多少人打开入口，多少次发生下载，多少台目标设备完成验收，多少问题仍待复现。层与层之间没有可靠标识关联时，就明确写"暂不能归因"。这比给管理层一个看似完整、实际无法复核的漏斗更有用，也能避免渠道和售后为一组定义不清的数字争论。

在这个无人零售柜场景里，首先要确认的不是文件有没有发出，而是"盘点应用、云端、支付、账号和资料资产"。下载只是交付链路中的一个节点；应用迁移不代表业务迁移，后面的账号、连接和真实任务才有可复核的起点。

应用资产只是运营体系的一层。短链接、二维码、历史版本、签名文件、开发者账号、柜机云、商品库存、支付、用户账号与售后资料都有独立所有者。迁移 App 可以解决分发管理权，却不会自动改掉现场登录、接口密钥和旧资料。

这个问题若继续靠群里补文件，最先丢失的是适用范围。给每项资产指定旧与新责任人之后，还要回答"旧链接出现位置有清单"。否则下一次换手机、换设备批次或换负责人时，团队只能重复猜测当初为什么能用。

建立"资产---当前所有者---新所有者---交接证据---回收动作"表。每条旧链接都要记录出现位置和面向对象；每个现场账号都要确认是否继续、重置或停用。不要用一张"迁移成功"截图代替整套运营系统的交接。

这张表要能支持无人零售柜的实际判断，而不是只做版本目录。建议把"按官方条件执行应用迁移并留证"对应的负责人、日期和证据放在同一行；结论分成安装、连接、任务和交付批准四档，避免一个"正常"遮住尚未完成的环节。

蒲公英应用迁移文档说明，满足条件时可把应用迁到另一账号，并保留下载链接、版本和用户等应用侧信息。迁移前后仍需核验目标账号状态、应用权限和链接。这个能力不迁移无人零售柜的设备云、支付商户号、商品数据或现场人员账号。

本文实际使用的是应用设置、渠道管理、版本管理、应用续期说明这些应用交付能力。它们能让无人零售柜相关人员找到明确入口、构建与说明；"支付与设备云单独交接"仍要靠设备、App 或业务系统的下一层记录来确认。

对无人零售柜，证据至少分成身份、过程和结果三组。身份记录型号、硬件修订、App 构建与使用角色；过程对应"逐个核验包装、售后卡和培训链接"的每一步；结果则要留下日志、批准人和下次变更条件。三组信息必须能通过同一个任务编号互相找到。

记录无人零售柜问题时，版本、系统、设备编号和错误现象属于事实，"可能由某项条件引起"只是判断。尤其是"现场旧账号完成回收"这类要求，必须由对应系统或真机证据确认；判断改变时追加新结论，不覆盖原始现场。

这套安排还需要退出动作：完成"重置或回收现场与后台旧账号"以后，谁关闭临时入口、谁回收旧说明、什么条件允许切换下一构建，都要在发布单上写明。对无人零售柜来说，一个没有期限和负责人的临时链接，很快就会变成售后不敢删除的遗留入口。

柜门控制、支付、库存、风控和设备远程管理属于运营平台。App 签名与商店开发者账号也可能另有归属。若新运营方没有取得必要授权，不能因为下载入口已经归属新账号就宣称整套业务完成交接。

还要保留一个时间边界。蒲公英官方续期说明明确，应用有效期根据账号等级计算；过期后应用不可下载，信息仍保留，续期或上传新版本后可恢复。因而"稳定入口"是持续维护方案，不能脱离账号状态与日常巡检做无期限承诺。

流程的终点是"在真实柜机完成开门支付和售后演练"，不是看到下载按钮亮起。网页、下载与安装都只产生中间证据；只有无人零售柜在目标环境完成本文所述任务，记录才能由待验证转为通过。

这七项最好直接放进无人零售柜的发布单。"真实柜机完成端到端验收"尤其要有负责人和证据位置；没有完成的项保留待验证，不用经验判断替代目标设备上的结果。

换运营主体不是把一个文件夹挪到新账号。只有下载入口、应用资产、柜机云、支付、人员和现场资料都完成交接，新的运营方才真正接过这批零售柜，并能对下一次版本变更负责。

最终要维护的是两套相连但不混同的资产：蒲公英侧的 App、构建、说明与入口，以及无人零售柜侧的硬件、固件、账号、云端和现场任务。把两边证据通过版本或任务号关联，后续更新才不会把一个下载问题误判成整套设备故障。