下载与部署，先看环境能不能撑住

01  /  交付形态

这里讲的是部署，不是装个安装包

先把预期摆正：这套系统不在公开渠道分发安装包。原因不是故作姿态，而是它装不起来。它依赖 ADB 驱动、依赖设备授权、依赖 adb server 端口分配、依赖一份写在绝对路径上的配置，还要跑通分层的引擎自检。这些环节里任何一步在这台机器上不成立，装完也用不了。所以交付形态是：由部署方把这套装到你的机器上，完成首次配置，跑通自检，交出验收结果。

这个形态决定了“下载”这件事在你这里长什么样：你不需要先找安装包，需要先准备一台机器、若干设备、一个账号，然后约一次部署。流程是准备、部署、验收、灰度四段，不是下载、安装、打开。

为什么不给一个压缩包让你自己解压？因为解压出来的是文件，装不上的是环境。最典型的三个卡点：驱动装在哪个系统上（WSL 到 Windows 的 TCP 不通，驱动必须跑 Windows 侧）、adb server 连哪个地址（不显式写就连到了另一个 server，看到一半设备）、设备授权是不是真的过了（授权弹窗点过不代表 adbkey 已写入）。这三处都要现场看，远程发文件解决不了。

还有一层边界要讲清：部署方负责让系统在你的机器上跑起来，不负责替你运营。账号归你、商品归你、发布节奏由双方的规则共同约束、平台侧的判定不由任何一方控制。部署完成的标志是分层自检全过，不是“能发出去一条”。这两者的差距，在一个月之后会变得很明显。

准备阶段的沟通成本也常被低估。把账号数、设备数、每天可投入的值守时间、类目范围这四项一次给全，端口、目录与节奏参数才能一次配到位；分几次补充，返工的是配置与自检，反而更慢。四项里最容易漏的是值守时间，它决定了故障响应落在谁那一侧。

这一段准备做得越细，部署当天越少返工。反过来，临时才发现少一台设备、没有集线器或者网络是共用的，整天的顺序都要重排，自检与灰度只能顺延到第二天。

02  /  环境要求

机器与设备，逐项对齐再开始

部署前一天把这些项对完，比部署当天现场补要省一半时间。下面每一条都写过不满足的后果，因为这几项几乎每一项都真实卡过人。

设备这一项要多说一句：不是所有安卓机都合适。界面层级稳定的机器更省事，定制系统改过界面结构的机器会让选择器失效得快。设备进池前要过三条判定：shell 往返、界面 dump、中文输入通道。中文输入这条尤其要注意，adb input text 打不出中文，这是实测结论，必须走 uiautomator2 那条通道。

模拟器可以用，但要单独规划。它没有实体 USB，掉线方式是进程被杀或端口回收，端口表要与真机分开维护，否则重启之后端口被别的进程占走，配置里还以为它在那儿。另外模拟器的序列号常是固定值，多开时会撞号，配置的键要用序列号加设备名的组合。

网络这一项容易被当成“能上网就行”。实际要求更具体：多设备同时上传图片时上行要撑得住；出网要稳定，不能频繁切换；设备池最好单独一条线路，不与办公网络混用。上传慢的直接后果是任务在窗口末端超时，而窗口末端正是最不该超时的位置。

最后是那台机器本身。它不需要很高配置，但需要稳定：不休眠、不自动更新重启、不跑别的重负载任务。把它当成一台设备看待，而不是一台办公电脑。

03  /  部署八步

部署顺序，不能颠倒

八步的顺序有依赖关系，跳过任何一步都会在后面变成难查的故障。照顺序走，每步都有可观察的结果。

这八步里，第一、第四、第七步最容易被简化，而它们恰好是后面所有麻烦的来源。第一是路径，第四是并发，第七是可核对性。省掉任何一步，症状都不会当场出现，而在两周之后的某次对账里出现。

如果部署由对方执行，你至少要现场看三件事：数据目录的绝对路径写在哪一行、端口与设备的对应表长什么样、分层自检的输出是不是逐项列出来的。三项都看到了，才算真的装完。相关流程在闲鱼自动铺货教程里有面向操作者的版本。

部署当天的节奏也建议按这个顺序排：上午装环境与做设备授权，下午跑自检与灰度。原因是设备授权经常需要人工确认，一次不齐就要重来；自检跑一轮要一段时间，放在下午能留出修复的余地。反过来把自检排在最后一小时，一旦有一项不过，当天就没有复跑的机会，第二天还要重新确认环境有没有被改过。

04  /  首次配置

配置里必须写死的几项

首次配置不是填几个框，而是把几件以后不该再变的事定下来。下面这些项要写死，写死的意思是：写在配置文件里，不靠运行时推断，不靠环境变量，不靠“默认值应该是对的”。

这几项里最有争议的是把节奏参数写死在配置里。有人想留出“临时多发几条”的口子，这个口子不该留。节奏是账号侧的安全边界，留口子等于把边界交给当时的心情。真要调整，走配置变更、留记录、观察三周，而不是临时改一下再改回来。

配置里还有一处需要显式：自检标记。自检进程带标记，带标记的进程一旦尝试写生产数据直接抛错。这个判断要写在写入模块里，不能靠调用方自觉——自觉是最不可靠的一层防护。

配置写完要做的事只有一件：读回来核对。把配置文件读一遍，逐项确认写进去的是你以为的值。曾经出现过的错误是端口号写成字符串、路径末尾多了空格，两者都不会报错，只会在某次运行时表现为“设备未找到”。

配置改过一次就要留一条记录，写清改的是哪一项、为什么改、什么时候改的。否则下次出问题时会多出一个变量：到底是环境变了，还是配置被改过。这一条在多设备环境下尤其重要，因为改一处端口可能只影响其中一台设备。

05  /  验收

验收不是能发一条，是逐项有结果

验收标准要能被第三方复核。下面这份清单是交付时可以逐条对着跑的，每一条都有明确的可观察结果。

• 网页通道 82 项逐项跑完并列出结果，不是“整体通过”
• 主路径冒烟 26 项从选品到台账落盘的整条主路径
• 手机通道 24 项设备端流程的动作与等待
• 每台设备引擎自检 13 项三台设备就是三份 13 项，不能合并成一份
• 反向测试通过该拦住的情况确实被拦住，不是只测顺利路径
• 自检污染防护自检进程带标记，带标记写生产直接抛错
• 写前备份改动生产数据前生成备份，并读回验证行数一致
• 哈希比对整轮自检前后对生产文件做哈希比对
• 台账口径两条通道写同一本台账，字段含 item_id、标题、描述、价格、时间戳
• 槽位守恒成功加失败加跳过加取消等于当日槽位数
• 到点复检发布前用当下基线重跑闸门，不通过就不发
• 平台健康闸平台侧异常时暂停发布，不硬发

这份清单里，反向测试最容易被跳过，也最能说明问题。顺利路径跑通只证明“能用”，反向测试才证明“不会乱用”：闸门该拦的拦住了、超量的被挡住、间隔不足的被顺延、重复指纹的被去重。只测顺利路径的系统，在第一次遇到异常时就会做出错的决定。

槽位守恒这一条要现场算一次。把当天的槽位数、成功数、失败数、跳过数、取消数打出来，四态相加应当等于槽位数。不相等就先补状态，不要先分析原因——这一步能抓出程序中途退出没写记录的问题，而这类问题在日志里通常看不出来。

还有一个验收时容易忽略的点：截图。界面快照与界面结构 dump 是排查的原料，验收时要确认它们真的落盘了、能打开、带时间。这两样东西平时没用，出事时是唯一能还原现场的东西。台账与截图的对应关系，在发布数据台账里有说明。

验收结果要写成一份可以存档的记录：日期、设备清单、每项的通过情况、失败项的编号与原因、修复后的复跑结果。这份记录在三个月后仍然有用，因为它是唯一能证明“当时是什么状态”的东西。

这份记录还要与运行目录对得上：自检输出、每台设备的 13 项结果、反向测试明细，都落在同一个归档目录里按日期分开。散在各处的截图与临时文件，三个月后基本没人找得到。归档目录用日期加版本命名，不用人名，这样换人值守也不用问。

06  /  排查

连不上、读不到、打不出中文

部署之后最常见的四类问题，按出现频率排。每一类都给了排查顺序，顺序比结论重要，因为症状往往指向错误的地方。

这六类的共同排查原则是：先确认环境层（系统、地址、供电），再确认设备层（会话、界面、输入），最后才看流程层。反过来的顺序会把时间花在读流程配置上，而问题在环境。

还有一类问题不在这六条里：平台侧异常。表现是任务都跑得动，但发布失败集中出现。这时候正确的动作是让平台健康闸生效、暂停发布，而不是加大重试。硬发的代价通常比停一天高。相关判断口径在防封控与商品合规检查里。

07  /  灰度

上线第一天，只发一两条

部署完成不等于可以按满负荷跑。第一天要做的是灰度：先一条服务线、一台设备、一到两条，观察完整链路，再逐步放开。

灰度期最常见的错误是“先发够量再说”。发布量上去之后，一旦结构出问题，就要回头删或改已经发出去的链接，成本比一开始慢两天高得多。另一个错误是灰度期不看台账，只凭“看着发出去了”判断成功——看界面和看台账是两回事，前者只能说动作执行完了。

灰度期还要刻意制造一次失败：故意让某台设备断连，看隔离是否生效、任务是否顺延、台账是否记下失败原因。这一次演练的价值很高，因为真正的故障总是在不方便的时候发生。演练过之后，值守的人才知道该看哪里。

如果第一天就出现“闸门拦下大量商品”，不要急着放宽规则。先看拦下的原因分布：如果集中在某一类目或某一类标题模板，改模板；如果分散在所有类目，可能是阈值设得太紧，需要按实际类目结构调，而不是整体关掉。相关方法在商品合规检查里。

放开到满负荷之后，节奏的意义才真正显出来。每天 5 到 10 条不是目标，是一个区间：低于下限说明产能没用上，高于上限就是在拿账号换量。真正要看的是每个服务线当天有没有跑满它那 2 条，以及周上限 12 条有没有被提前用完。提前用完的那一周，剩下几天就该停，而不是换台设备补上。

08  /  升级与归属

升级、回滚，和东西归谁

部署是一次性的，升级是长期的。这两件事要分开安排，否则一次升级就能把稳定状态打回原点。

版本记录不要只记在脑子里。每次变更写进更新日志，写清版本、日期、改动项、影响面。三个月后回看某次数据异常时，这份记录是唯一能对上时间的依据。

最后是归属。这件事在部署阶段就要写清，不要等到换供应商时再谈。合理的约定是：机器与设备归你，账号归你，台账与日志归你，配置与流程文件可导出，导出格式是能直接读的文本。交付方保留的是软件本身。数据归属不清的后果很具体：台账导不出来，历史就带不走，换一套系统等于从零开始。

还有一条容易被忽略的归属问题：截图与界面 dump。这些是排查原料，也是运行记录的一部分，应当与台账放在一起、按同一套时间标记归档，不要散在各个临时目录里。归档策略定了之后不要随意改，改一次就等于断了一段历史。

归档目录的权限也要提前定：谁能读、谁能删，删除要不要留痕。没有这条约定，某天发现截图不见了，也查不出是谁清理的，而那时候恰好是最需要它们的时候。

需要更细的环境核对或安排部署，可以走联系我们；产品各模块的关系见产品功能总览，两条通道的差别见手机 APP 自动化通道与电脑网页版通道，多台设备怎么规划见多设备并行管理。