批次预配的 Android 设备：交付之前会经历哪些环节？

批次预配复现的是已放行状态

批次预配是把一台已验收样机转化为一批状态一致设备的受控工作。它不是又一种注册方式，也不能证明每一种可能的工作流程都经过测试。它是一个项目控制层，目的是在有记录的条件下复现已放行状态，并把偏差暴露出来，交由指名的放行决策方裁定。关键词是复现。预配开始时，各项决策早已作出并冻结——确切型号与区域 SKU、固件构建、应用制品与版本、策略或配置文件版本、预配路径、标签、配件和包装规则。这份冻结下来的描述就是设备配置规范，而设备配置规范记录哪些内容、又如何在版本控制下变更本身就是一个独立话题；已验收样机则是该规范得到验证的那一台设备。预配不会为规范增加任何内容，它的全部工作是把相同的输入以相同的方式应用到批次中的每一台设备上，并留下确实如此的证据。Android 的运行时构建字段、预配模型和应用版本字段都能提供证据，但它们都没有定义通用的预配或抽样标准。“批次预配”是 Vantora 的项目用语；范围、设备覆盖面、证据和决策权限必须在项目中约定。下表界定的正是这些证据的边界。每个控制领域都记录了真实存在的东西，同时也各有一条批次记录不得夸大的界限——部署中代价最高的意外，多半来自把已记录的输入当成已验证的结果。

移交前的七个阶段

预配是一条产线，而不是一个瞬间，控制力大多来自顺序。有四条规则决定这条产线产出的是证据，还是仅仅产出设备。第一，预配路径在设备配置规范中就已定下，绝不在工位上临时选择——QR 或 NFC 流程、零接触分配、EMM 注册令牌和 OEM 工具在时间压力之下并不能互相替代，它们之间的比较属于Android 设备预配方式的范畴，早在开箱之前就应决定。第二，操作人员要等待状态稳定下来，而不是在命令下发时就宣布成功；排队等待的策略不等于已经生效的策略，批次与样机的悄然分化正是发生在这一间隙里。第三，结果未记录之前不得包装，因为设备一旦封入外箱，不拆包就无法再检查——因此标识符是在成套组装的同时采集的，而不是事后从采购单行项反推出来的。第四，出现不一致的设备立即退出放行流程，并一直留在流程之外，直到由有权作出决定的人裁定其影响和处置方式；这一失效模式代价最高的版本，是技术人员悄悄修好异常然后照常发货。项目可以合并阶段，或省略不适用的阶段，但只能通过约定范围和验收决策方来处理，而且省略要有记录，不能默认。

评估样机、试点批次、量产批次

一个项目中的预配不止一次，而且各次运行并不能互相替代。项目通常会经历其中三次：一到三台评估样机，用于证明所要求的状态在这一确切型号和构建版本上确实可以达成；一个试点批次，用于证明预配运行本身在真实条件下可重复；以及量产批次，用于在规模数量上复现已放行状态。Vantora 报价的设备项目规模从 500 台左右起，试点是该项目内部的一个批次——通常为二十到一百台——而不是另行下达的小额订单。把试点读作试购，是报价阶段最常见的认知错位来源，因为两者的计价方式和排期方式都不相同。样机回答的是状态能否达成。试点回答的是状态能否复现，同时还回答了样机在结构上无法回答的几个问题：一台设备在每个工位上实际要花多长时间、多大比例的设备会触发异常、包装方案在遇到真实外箱和真实快递之后是否还站得住、站点人员能否照着打印出来的说明完成首日激活、配件与交付状态下的设备是否匹配，以及标签是否会一直贴牢。这也是设备第一次到达真实用户手中，而没人写下来的需求往往正是在这时浮出水面。试点的结束标志是条件，而不是时长：一份认可的预配记录、一个审批方接受的异常率、一个确认的每台处理工时和一份签署的包装方案。凡是改变了重大假设的发现，都要作为新版本回写进设备配置规范；若涉及行为，则要重跑受影响的样机验收矩阵场景——而不是变成对预配操作人员的一句非正式交代。只有到那时，项目的剩余数量才会按同一冻结版本进行预配。

哪些检查逐台执行，哪些抽样执行

对每台设备执行每一项检查，很少是正确答案；而只做一次抽检，则从来都不是。批次验证的常态是一种分工：一小组快速、与单台设备相关的检查覆盖批次的 100%，而所有耗时较长或由行为推导出的检查则按约定抽样执行。这种分工的逻辑一旦说破就很直白。当一项检查所验证的对象可能因设备而异、且事后无法补救时，它就应当逐台执行——从未采集的标识符、从未进入设备所有者状态的设备、封箱之后才发现缺失的配件。当一项检查所验证的是构建版本的属性、而非单台设备的属性时，它就可以抽样执行：重启后锁定任务是否保持，取决于应用到整个批次的策略版本，因此某一台设备失败，几乎总是意味着参考基准有误，而不是那台设备运气不好。抽样比例本身几乎说明不了什么。要让记录站得住脚，还必须同时说明三件事：抽样所依据的总体范围、设备是如何抽取的（随机抽取、每个托盘取首尾各一台，还是按生产批号分层抽取），以及抽样设备失败时适用的停止规则。通常的停止规则是扩大覆盖面而不是继续往下走：抽样中出现失败即暂停本次运行，触发对参考基准和已应用输入的复查，然后要么把该项检查升级为 100% 验证，要么暂停预配直至查明原因。Android 和各管理平台都不会替您设定这一比例；它是一项项目约定，取决于工作流程的风险、现场故障的代价和试点观察到的异常率。

让批次可追溯的证据

一次有用的移交，能让接收团队回答三个问题：我们收到了哪些设备？它们本应承载哪一个已批准的状态？放行之前观察到了什么、例外处理了什么、又授权了什么？能否回答这些问题，正是批次记录与装箱单的区别所在。实践中，这份记录是一张每台设备一行的表格，外加一小组批次级附件——已放行的设备配置规范版本、验收证据、异常日志和包装方案——因为只有逐台成行的结构，才经得起六个月之后的追问：那时支持台手里只有一个序列号，没有任何上下文。Android Management API 设备记录可以在配置好的报告设置下呈现已应用策略、合规状态以及选定的软件或应用数据，但它并不是通用的 EMM 验收记录；而控制台导出的是当前状态的快照，不是放行时验证了什么的记录。应把平台报告与观察到的工作流程证据和实体证据结合起来。这一区别在记录的两端体现得最明显：控制台能告诉您某项策略当前已生效，却无法告诉您测试人员亲眼看着设备在重启之后仍保持该策略；它能列出应用版本，却无法告诉您外箱里装的是正确的配件。

移交资料包，以及各项记录的归属

移交资料包是随批次一同交付、并在交付之后仍然有用的那组文档。只存在于集成商系统里的记录，对客户而言不构成可追溯性，它只是一句“别人可以帮您查”的承诺。资料包应当以接收组织能够自行持有的形式移交——通常包括已放行的设备配置规范版本、样机阶段的验收证据、逐台的批次记录、异常日志、已知限制日志、包装与分配清单，以及写明支持责任方和升级路径的接收说明。它们各有不同的使用者，这也正是资料包是一组文件而不是一份报告的原因：采购要核对数量，IT 要把标识符导入资产管理系统，支持台需要知道哪些限制是已被接受的、而不是坏掉了，而负责下一单的人需要拿到冻结版本来报价。下表逐项说明每份记录记载什么、实际由谁使用，以及批次交付之后它存放在哪里。其中有一行尤其值得注意：移交之后，租户状态归客户的 EMM 管理员所有，因此持有这套凭据的人必须在批次发货之前就指定好，而不是等到第一次策略变更时才发现无人认领。Vantora 是否保留预配记录的副本、保留多久，属于项目中约定的范围问题，不能想当然。

明确何时停止、返工或重新验证

异常要被隔离，而不是被消化掉。检查未通过的设备会在两个意义上离开产线：物理上被移到远离放行库存的标记区域；记录上其标识符被打上标记并从放行数量中扣除，直到指名的决策责任方对其作出处置。四种处置方式几乎涵盖了所有情形——按获准路径返工、从备件库存更换、以记录在案的偏差放行，或者判退——而每一种都归属到具体的人，而不是归属到流程。返工后的设备从受影响的阶段重新进入产线，并从该阶段起重新验证，包括此前已经通过的检查，因为纠正措施可能扰动原本正常的状态；为修复注册失败而重置的设备，其应用和策略状态同样已经丢失。有两条规则维系着批次的可信度。其一，不得用未记录的临时手法修理任何设备，无论工位上看起来多么显而易见，因为一个未记录的步骤意味着这台设备已不再与参考基准一致。其二，算术必须在授权交付之前对得上：接收数量、放行数量、异常和更换件必须彼此核对一致。何时需要全量重测，并没有通用阈值。项目的验收决策方应评估影响，并在定向验证、扩大抽样、新的样机版本、附条件放行或判退之间作出选择——而一组相似的失败应被读作关于参考基准或来料硬件的信号，而不是一连串运气不好的设备。凡是被接受而非被修复的问题，都应连同其依赖责任方和重新验证触发条件一并写入已知限制库，好让下一个批次继承这项决定，而不是重新发现同一个症状。

• 当已放行的参考基准不完整、出现错误的 SKU 或构建版本、基础设施不可用，或某项必检结果无法安全评估时，应停止。
• 当某台设备特有的偏差可以按获准路径纠正、且不改变已验收基线时，应返工。
• 当纠正措施改变了设备版本型号、固件、应用或签名路径、策略、预配方式、配件、市场或工作流程行为等重大假设时，应重新验证。

补单为何会发生漂移，以及靠什么把它固定住

让有经验的采购方栽跟头的失效模式，是批次之间的悄然漂移。它不会发出任何信号：订的是同一个料号，到的是同样的数量，外箱看起来一模一样，而第一个症状要在几周之后才出现——某个原本可用的工作流程，在部分设备上不再可用。成因都是寻常的供应与软件行为，并没有什么离奇之处。OEM 可以在商用型号名称不变的情况下更换某个元器件——显示面板、摄像头模组、内存或 Wi-Fi 供应商；区域版本可能轮换；产线上刷入的固件可能向前推进，使到货设备搭载的构建版本比验收时更新；应用自样机之后可能已经发布了好几个版本；策略可能被某位管理员为解决无关问题而在控制台里改动过；包装或配件供应商可能替换了某个零件。这些事情单独来看都合情合理。合在一起，它们意味着“和上次一样的设备”描述的是一份订单，而不是一种状态。真正把补单固定住的，是一对制品，而不是供应商的口头承诺。第一件是冻结的设备配置规范版本，在新订单上明确引用，使到货的硬件和软件是对照书面参考基准核查，而不是对照记忆。第二件是上一份批次记录，它提供了逐行比对的基线：上次实际放行的固件构建、应用版本和策略版本。随后，新批次的首批设备先按该基线做一次简短的重新验证，再对其余设备进行预配——实质上是一次小型试点，其规模按风险确定，而不是按百分比确定。平台侧的管控能够收窄漂移，但无法消除漂移：在设备和管理平台支持的前提下，带冻结期的系统更新策略可以在部署窗口内把固件固定住，而受控的应用更新设置可以阻止自动更新、设定设备必须达到的最低版本，并先向设备群的一个子集分阶段发布。请注意这套手段不包含什么：受管渠道强制的是版本下限，而不是某个确切版本，因此“这一批次运行的是 4.2.1 版”是关于已预配并验证过什么的陈述，而不是平台事后会替您守住的一项管控。这两项能力都取决于 OEM、Android 版本和 EMM，应在样机上确认，而不是想当然。硬件替换则不在这两项能力的覆盖范围之内，因此对物理版本型号的来料检查仍应保留在计划之中。

• 在补单上引用冻结的设备配置规范版本，而不是写“和上一批一样”。
• 在对其余数量进行预配之前，先把到货的固件、应用和策略版本与上一份批次记录比对。
• 重新验证少数几项对漂移最敏感的行为：固定的工作流程、外设配对、权限和重置恢复。
• 把未事先告知的元器件或固件变更当作有具名责任方的重新验证触发条件，而不是可以自行消化的偏差。

把责任写清楚

批次预配触及的输入分属多家组织，而移交环节的大多数争议，实质上都是关于某项输入归谁所有的分歧。在确认的范围之内，Vantora 可以统筹设备选型、应用就绪配置、管理需求、预配、QA、批次预配和移交等设备项目工作。它并不独立控制客户的应用、EMM 租户、Google 或 OEM 服务、运营商或主管机构的决定，也不控制买方的验收。在首个批次进入预配之前就把这一分工写下来，异常才可能在数小时内完成处置，而不是演变成一周的往返函件——预配操作人员只能执行已放行的指令，因此指令不清就会按设计停线。

交付前放行检查清单

只有在批次、异常和接收方需执行的操作都与已放行参考基准核对一致之后，才能授权交付。下面的清单刻意做得简短，也刻意具有终局性：每一行都是由指名决策责任方确认的条件，而不是操作人员打勾的任务；只要其中任何一项尚未闭合，批次就不得离开预配环节。

• 确切的构建版本和预配版本已由指名决策责任方放行。
• 接收设备符合已批准的 SKU、构建版本和允许偏差规则。
• 使用的是已批准的预配、应用、配置和策略路径。
• 要求的逐台检查和抽样检查均已完成，并有可追溯的证据。
• 异常已隔离、已处置，并已反映在放行数量中。
• 标签、配件、包装和站点分配与包装方案一致。
• 接收团队已掌握批次标识、限制、激活步骤、支持责任方和恢复路径。

在预配开始之前界定批次范围

预配的规划成本很低，临场发挥的代价却很高，因此范围讨论要在第一台设备开箱之前完成。请提供设备类型、预期数量、目标国家、应用状态、管理路径、已验收的样机状态、必需的检查项、标签与配件、站点分配和移交预期。初步可行性评估不需要终端客户名称和商业信息。预配在更大流程中的位置——项目简报、设备配置规范、已验证样机、验收矩阵、批次预配、移交——在经验证的 Android 设备部署如何运作中有完整说明，而预配和批次预配工作本身，则归属于部署与预配。值得特意把试点批次纳入第一次对话，因为它的规模、它的验收条件，以及项目其余数量在哪个时点放行，既是技术决定，也同样是商务决定。