十个模块按一条顺序接起来，才叫铺货系统
铺货这件事坏掉，很少是因为某个功能不好用，而是因为顺序错了：先接了多设备，文案还是同一份；先上了定时，合规闸门还没装；先把量跑起来，台账里查不到哪一条是被拦下的。这页不重复每个模块的细节，只做一件别处不做的事——把十个模块摆成一条有先后的链，说清每一段依赖谁、跳过去会出什么问题、什么状态下才该接下一段。读完你可以对着自己的现状，判断现在该补哪一环，而不是把十个功能一次全开。
手机 APP 自动化通道
用 ADB 驱动一台安卓真机或模拟器，把客户端里的发布动作写成 YAML 流程，字段、顺序、配图位置都写死在文件里，跳过一步就在日志里显出来。适合必须在手机端走完的类目，也适合同一条商品在多个账号重复上架时保证每条配图顺序一致。设备要能长期插电、接固定网络。设备是长期资产，别用随手拿的备用机，系统版本与分辨率要固定下来。
02电脑网页版通道
走 HTTP API 提交发布，可以批量、可以并行，处理速度明显高于点屏幕。它和手机通道读同一份发布计划、写同一本台账，换通道不必重做选品与文案。但接口层与客户端并不完全等价，某些类目的编辑页字段只有 APP 里才完整，这类商品仍然要走手机端。接口字段与客户端不完全等价的类目，仍然回到手机端执行，这是分工不是二选一。
03AI 商品文案改写
把商品的实际参数改写成标题与描述两段：标题控制长度与关键词落位，描述按成色、配件、瑕疵、发货方式分段。改写的边界是只能基于你给的事实，不许补参数、不许写绝对化用语。文案是后面所有模块的输入，它没定下来，节奏和风控都没有意义。改写的输出要能逐句指回商品事实，指不回去的句子宁可不写；改完还要过一次闸门。
04智能选品助手
按类目、价格带、成色、竞争密度筛出候选池，再由人确认。工具只负责把候选收敛到一个能人工过一遍的规模，不负责替你决定卖什么。选品的输出是三条：这条商品能不能做、做哪个价格带、配几张图。它决定后面文案与节奏的输入质量。候选池超过五十条就要重新收窄，否则人工确认会变成走马观花。
05定时发布与节奏控制
把发布摊到一天里：每日 5 到 10 条，间隔 30 分钟以上并带抖动，发布窗口限定 09:00 至 21:59，单条服务线每天 2 条，每周上限 12 条。这些数字不是拍出来的，是把「像人在发」翻译成可执行的排期参数。节奏接早了没有意义，因为没内容可排。排期参数改过的第二天要看发布记录有没有断档，断档说明窗口设窄了；抖动幅度也不宜过大。
06防封控与账号安全
拟人化部分给的是具体数值：点击间隔 0.34 到 1.30 秒、滑动走 smoothstep 曲线、落点偏移 ±4 像素、按压 72 到 155 毫秒。此外是平台健康闸：平台侧出现异常时暂停发布，不硬发。风控要接在节奏之后，因为节奏本身就在承担一半的分散。参数不要自己覆盖，覆盖之后日志与实际就对不上；出现平台侧异常提示时，先停一天再看，不要边发边试。
07商品合规检查
合规闸门不是发布前跑一次就完事，而是在到点发布的那一刻用当下基线重跑一遍，不通过就不发，属于 fail-closed。检查项包括类目选择、发布时间分散、标题与主图相似度、同款链接数量、单链接图片张数。放在这条链的后段，是因为它检查的是最终要提交的那一份内容。拦下时会给出原因，改内容重试比改参数有效，参数不是用来绕过判定。
08发布数据台账
两条通道写同一本台账，由同一个模块统一口径，记录 item_id、标题、描述、价格与时间戳。同一份发布计划里，某一条归哪条通道是算出来的，不是人工标记的。台账是唯一能回答「这条到底发没发出去」的地方，也是自检与生产记录分开的前提。台账要能导出成按时间排序的表，交付时才拿得出手；记录只增不改。
09多设备并行管理
多台设备并行时，要处理的是端口与进程：uiautomator2 一个进程只绑一个 adb server 端口，必须加端口锁；adb server 要显式寻址，不能靠默认；设备存活只认 shell 往返，不看进程有没有起来。这一层接在最后，因为单设备都没跑稳时，并行只会放大错误。并行之前先确认单台能连跑二十条不出错，再复制第二台；机型不同要分组验证，不能一台过全过。
10价格与版本
价格按设备数与通道组合区分，不按发布条数抽成。判断该买哪一档的方法不是看条数上限，而是看你有几台设备、要不要两条通道同时跑、要不要多账号分线。这一页放在最后看，因为档位选择取决于前面九项里你实际接了几项。换档之后旧配置仍要留一个版本周期，回滚要用；档位只影响能跑几台设备、几条通道。
这十个模块不是并列的十项功能，而是一条有先后的链：先有商品与文案，才有东西可发；先有通道，发才落得下去；发出去之后，才谈得上节奏、风控与台账。顺序搞反的症状很好认——一上来就接多设备，结果每台设备发的文案一样、配图一样、间隔都是整三十秒，设备越多，被判定为批量操作的概率越高。所以下面按内容、通道、节奏、记录四段来排，每个模块都能落到其中一段。
| 编号 | 模块 | 解决什么 | 依赖谁 | 什么时候接 |
|---|---|---|---|---|
| 01 | 手机 APP 通道 | 客户端里那段必须手动点的发布 | 发布计划、文案 | 类目只能在 APP 内发完时 |
| 02 | 电脑网页版通道 | 批量、并行的提交 | 发布计划、文案 | 有接口可走的类目 |
| 03 | AI 文案改写 | 标题与描述成稿 | 商品事实、选品结论 | 第一条就要有 |
| 04 | 智能选品 | 候选池收敛 | 无，可最先做 | 第一条就要有 |
| 05 | 定时与节奏 | 把发布摊到一天里 | 文案、通道 | 稳定出稿之后 |
| 06 | 防封控 | 操作形态与暂停条件 | 通道、节奏 | 开始连续发之后 |
| 07 | 合规检查 | 提交前最后一道拦截 | 文案、类目、图片 | 与通道同时接 |
| 08 | 台账 | 发没发出去的唯一答案 | 两条通道 | 第一条发布之前 |
| 09 | 多设备 | 并行与端口管理 | 单设备已跑稳 | 单机不够用之后 |
| 10 | 价格与版本 | 档位选择 | 前面九项的实际情况 | 最后再定 |
把它们收成四个阶段，接入顺序就清楚了。
第一段：内容，选品与文案
先把「卖什么、怎么描述、配几张图」定下来。这一段没有依赖，一个人也能做完。判断标准很直接：同一条商品，你能否在两分钟内说清它的成色、配件、瑕疵位置和发货方式。说不清的部分就是文案会翻车的地方，也是后面合规检查最容易拦下的地方。具体到操作，智能选品给候选，文案改写给成稿。
第二段：通道，先把一条发出去
选一条通道，把第一条真实商品发出去，并且能在台账里查到它。这一段最容易犯的错是两条通道同时开工——手机端的中文输入还没通、网页端的字段映射还没对，两边都卡着，分不清是哪一边的问题。先把一条跑通，再决定要不要第二条，分工见手机 APP 通道与电脑网页版通道。
第三段：节奏与风控，把量摊开
能稳定发出十条之后，才谈得上节奏。节奏调节奏，风控调形态：前者管什么时候发、发几条，后者管点击怎么点、滑动怎么走、平台异常时停不停。这两段合起来才构成「像人在操作」，只做其中一件，另一件会把效果抵掉。
第四段：记录与并行，再扩规模
台账要早于并行接进来，理由很实际：设备一多，出错的形态从「发失败」变成「不知道哪台发成功了」。台账统一口径之后，槽位归属是算出来的，出问题是可定位的。设备并行的技术细节在多设备管理里写。
合规闸门的位置值得单独说一句：它不在这四段的末尾，而是横跨第二段到第四段，每一次提交前都要过。合规检查采用发布时刻复检，意味着你上午审过的内容，到晚上到点发布前还会用当下基线再跑一遍，标题与主图相似度、同款链接数量、单链接图片张数在这时候才最终定性。这条设计会让人不舒服——它确实会拦掉一些你以为已经过了的内容——但正是它让「发了但被平台清掉」这种事变成「没发，日志里有原因」。
不建议一次全接
十个模块全开听起来完整，实际会让变量同时变化：发失败了，你不知道是文案被拦、通道超时、节奏冲突还是设备掉线。接入的粒度建议是一次只加一层，每加一层先跑通十条真实商品并留下日志，确认这一层没有引入新问题，再加下一层。想按自己的现状挑起点，可以看应用方案总览；想按步骤走一遍，从使用指南总览开始。
最后是关于边界的说明：这套系统管的是发布链路上的重复劳动与判断前置，不管选什么货能卖出去、不管价格定多少合适、不管售后怎么谈。把这些指望工具，接得再顺也不会有结果。至于要花多少、买哪一档，等前面九项里你确实需要几项之后再去看价格与版本，那时候的判断才有依据。
接入判断
先补最缺的那一环，不要按清单从头接
十个模块的完整度不重要，缺的那一环才决定发布能不能稳定。判断方法在下面。
一句话自查
如果现在停发一天，你能说清昨天一共发了多少条、哪几条被拦下、拦下的原因吗？答不上来，先补台账。如果答得上来但每条都要手动点，先补通道。如果通道在跑但每天都在担心账号，先补节奏与风控。三个都答得上来，再去看多设备与档位。
先跑通一条真实发布，再谈铺量
把账号、设备、商品素材交给我们的部署流程，先跑通一条真实发布并留下可核对的日志，确认没问题再谈规模化。