01 / 目标口径
先把终点定下来：什么才算跑通一条
把自动发布理解成装一个软件、点一下开始，第一次基本都会卡在半路。真正要拿到的东西不是那一下点击，而是一条真实商品从素材到上架的完整链路：每一步都有日志、有回执、能重跑。链路跑通一次，后面的量才有意义；链路没通就加量，只是把同一个错误重复十遍。
这条教程按执行顺序走一遍完整发布。终点不是平台提示成功，而是下面三件事同时成立。
平台上有货
商品真实出现在平台上，标题、价格、图片、类目与你填的完全一致，链接能打开，别人能正常问到价。接口返回只代表请求被接受，不代表商品已经对外可见，这两件事必须分开确认，中间隔着平台的审核与展示延迟。
台账里有账
手机通道与网页通道写的是同一本台账，记录里必须有 item_id、标题、描述、价格、时间戳。没有进账的发布不算跑通，因为事后无法核对，出了偏差也定位不到是哪一条、哪一刻出的问题。
能重复
同样的素材、同样的流程配置，第二次执行得到一致的结果。一次成功说明不了什么，可能刚好赶上网络顺畅、页面结构配合。可重复才是工程结果。
还有一条边界要先说明：这套东西做的是把重复手工动作交给流程执行，不是绕过平台规则。发布节奏、商品合规、账号行为都要落在正常卖家的范围里。超出范围的做法短期可能看着有效，长期一定会以更麻烦的方式还回来，具体尺度在防封实操里单独讲。
顺序也不能颠倒。账号先确认干净，通道再接；通道通了流程才有意义；流程跑通素材才谈得上批量；素材齐了才轮到闸门判断。每一步都依赖上一步的结果，跳过任何一步，后面都要返工，而返工的成本比第一次做对高得多。
如果你现在还在手工发，第一条走完会有一个直观变化：你知道这条商品为什么被拦、被拦在哪一步。这个可见性比速度重要，速度是后面的事。
还有一个判断标准，建议一开始就写在纸上：这条流程失败的时候，你能不能只凭日志说出失败在第几步、属于哪一类问题。说不出来，说明证据留得不够，回不到现场。工程上把这种情况叫不可观测，它比失败本身更麻烦，因为失败还能重试，不可观测只能靠猜。日志、截图、界面树三样东西在第一次跑通时就要配齐，不要等到出了问题才想起来加。
02 / 开工准备
开工前把七项对齐，不要边发边补
通道接得再好，账号或素材没准备好照样发不出去。开始之前把下面几项对齐，缺哪项先补哪项，不要边发边补——边发边补的意思是每一条商品都带着同一个未解决的问题上路。
- 账号本身可用先在手机上手工发过至少一条商品，确认账号没有限制、没有待处理的违规提示。有历史提示的账号先处理提示，别急着上自动化
- 一台安卓设备真机或模拟器，系统设置里的调试开关打开，电脑能识别到设备。手机通道靠 ADB 驱动，模拟器同样适用
- 单链接 3–9 张图实拍为主，首图交代清楚是什么，后面几张补细节与瑕疵。同款的多条链接之间图片要有明显差异，不要一套图反复用
- 事实齐全的草稿品类、规格、成色、包含物、交易方式先写全。写不全就先别发，缺参数的商品发出去只能换来无效问价
- 价格与类目价格填最终售价，类目按商品本质选，不按想被谁看到选。类目选错的商品会进错流量池，后面改文案也补不回来
- 固定台账路径指定一个目录专门放台账，两条通道写同一本。一处一个文件的话，事后合并比重新发一遍还费时间
- 发布窗口与间隔窗口定在 09:00–21:59，相邻两条间隔不少于 30 分钟并带随机抖动，不要卡整点、不要卡半点
这七项里最容易出问题的是设备。驱动必须跑在 Windows 侧：WSL 到 Windows 的 TCP 不通，从 Linux 侧发起的连接会一直超时。看着像设备没响应，其实是链路走错了方向，查一晚上设备也查不出来。另外 uiautomator2 一个进程只绑一个 adb server 端口，同时跑多台设备必须给端口加锁，否则第二个进程会把第一个的连接抢掉，表现是两个任务一起失败。
准备阶段多花的时间，都是从返工里省出来的。素材不齐就开始发，最常见的结局是发了三条发现图不对，删掉重来，账号白白多了一次没有意义的操作记录，节奏也算白排。
设备和账号的对应关系也要在准备阶段定死：一台设备固定登录一个账号，不要两台设备轮流登同一个号，也不要在一台设备上频繁切换账号。切换会在平台上留下设备与账号绑定关系的变化，这类变化本身就会被记录，属于不必要的动作。多设备的情况见多设备并行管理，一台设备管一个账号是最省心的起点。
清单过完一遍之后，建议再反向查一次：这套流程失败时，你能付出多大代价。最坏的情况是发出了错误内容，次坏的情况是发出去了但字段缺失，再次是没发出去。三条里第一条必须靠闸门挡住，第二条靠回执核对挡住，第三条只是重试的成本。按这个顺序想一遍，你会知道哪几步不能省。
把这张清单存下来，每次换设备、换账号、换素材来源都重新过一遍。清单的价值在于它不依赖记忆，交接给人也能用，出问题时还能拿它当核对表倒推是哪一项没做。
准备做得越具体，后面越少返工。这几项都对齐之后，再往下读通道接入那一节。顺序没错，返工就少。
清单里第七项容易被忽略：发布窗口与间隔。窗口之外不发，是因为夜间发布在正常卖家身上很少见；间隔少于三十分钟，是因为连续两条紧挨着出现和人的操作习惯不符。这两条与商品无关，纯粹是行为形态，形态异常比内容异常更容易被看见。
03 / 通道接入
第一步：把通道接起来，逐项确认再往下走
两条通道选一条先用。手机通道走 ADB 驱动安卓设备、按 YAML 流程执行；网页通道走 HTTP 接口，不需要设备在手边。第一次上手建议先用手机通道，因为它把页面上的每一步都摆在你眼前，出了问题看得见、截得到图。两条通道的能力边界与分工见手机 APP 自动化通道与电脑网页版通道。
| 序号 | 动作 | 通过标准 | 失败先查什么 |
|---|
| 01 | 打开调试并连设备 | 电脑能列出设备序列号 | 换一根确定能传数据的线，充电线不行 |
| 02 | 启动 adb server 并显式寻址 | shell 往返有回包 | 端口被旧进程占着，先停掉再起 |
| 03 | 装设备端服务 | 能 dump 出当前界面树 | launcher 屏 dump 会失败，先试 --compressed 再退回普通 dump |
| 04 | 试一次中文输入 | 输入框里出现中文 | adb input text 打不出中文，改走 uiautomator2 通道 |
| 05 | 试一次页面跳转 | 点击落在目标控件上 | 选择器加 instance 序号，区分同名控件 |
| 06 | 写一条最小流程 | 从头到尾不中断 | 用 require 卡必要条件，用 if_exists 兜可选步骤 |
表格第 02 行值得多说一句：判断设备活着，只认 shell 往返有没有回包，不要用设备列表里有序列号就下结论。列表能列出设备，但 shell 通道已经断了的情况很常见，这时候流程会在第一次点击时失败，而错误信息指向的是控件找不到，会把你带到完全错误的方向。所有 adb 调用都要设超时上限，卡住就判失败重来，不要无限等。
第 04 行是新手最常踩的坑。中文输入必须走 uiautomator2 通道已验证的那条路，用 adb input text 打中文会静默丢失，输入框是空的，但流程不报错，最后发出去的商品标题为空。这类失败最麻烦，因为它不报错。接入阶段就要专门测一次中文，不要等发第一条商品时才发现。
通道接通的标志不是某一步成功，而是这条最小流程能连续跑三次都通过。三次是因为单次成功有偶然性，尤其是页面加载慢的时候，第一次成功、第二次超时很常见。连续通过说明重试和超时设置是合适的。
还有三件小事要在接入阶段一起处理掉：关掉自动锁屏、折叠通知、停掉系统更新的自动下载。这三件事不处理，会在跑批时集中爆发，表现是流程随机失败，而且每次卡住的步骤都不一样，很难归因。锁屏会让界面树取不到控件，通知会挡住点击落点，系统更新会在中途重启设备。都是环境问题，查代码是查不出来的。
04 / 流程配置
第二步：写最小流程，只做三件事
最小流程只做三件事：打开目标页面、填必要字段、提交。把这三件事写成一条能重复执行的 YAML，先不要加任何判断，也不要一上来就把整套发布塞进去。一次只让流程多走一步，错了才知道是哪一步错的。
流程引擎支持的动作不多，但每一个都有明确用途，写的时候按下面的分工用。
require：卡必要条件
登录态在不在、目标页面打没打开、关键按钮存不存在。条件不成立就直接停，不要带着错误状态往下走。这是流程里最该先写的动作。
by_any：多选择器兜底
同一个控件给几个候选选择器，按顺序试。页面改版、文案微调都会让某个选择器失效，by_any 让流程不至于因为一个改字全盘失败。
if_exists 与 if_enabled
可选步骤用 if_exists 包起来：弹窗、引导页、更新提示，出现就处理，不出现就跳过。按钮置灰的情况用 if_enabled 先判一次，避免点了没反应还继续往下走。
abort：该停就停
出现不可恢复的错误时立即终止这一条，不要重试到天亮。终止会留下失败标记，配合台账能看出是哪一类问题，比反复重试有价值。
reset：回到干净状态
每条流程开始时先回到首页或指定起点。上一条结束时页面停在哪里不确定，不 reset 就开始，等于让流程从上一次的残留状态出发。
dump 与 shot：留证据
失败时有一份界面树和一张截图，比一句点不到有用得多。这两个动作不需要每条都开，但关键节点前应该留一份。
还有一个顺序原则：先判断再操作，不要先操作再判断。先点提交再看结果，失败时已经产生了一次无效提交，账号上多了一条记录。先用 require 和 if_exists 把前置条件走完，提交是流程的最后一步，不是中间一步。
流程写完之后，先在测试商品上跑通，再换真实商品。测试商品也要按真实商品对待——图、标题、价格都是完整的，只是它本来就该发出去。用占位内容测试的做法会带来两个问题：占位内容一样要走平台审核，和真实商品没有区别；而且测完还得再清理一遍，等于多做一次操作。
流程配置里最容易写多的是等待。等得太短，页面没加载完就点，失败是随机的；等得太长，一条商品要跑十几分钟，批量时排不开。合理的做法是把固定等待换成条件等待：等到某个控件出现再继续，最多等一个上限。这样页面快的时候不浪费时间，慢的时候也不会抢跑。上限是必须的，没有上限的等待会把一个失败变成一次挂死。
选择器要写得宽一点，但不要宽到会命中错的东西。优先用页面上的固定结构定位，其次用控件文字，最后才用坐标。坐标定位在分辨率变化、字体大小变化之后立刻失效，而且失效时是点错地方，不是报错，属于最难查的一类问题。同一个控件准备两到三个候选，交给 by_any 按顺序试，页面小改版时流程还能活。
05 / 商品信息
第三步：填对字段，别在源头留坑
流程跑通之后，决定成败的就是填进去的内容。同一套流程，字段填错的商品发十条也没用；字段填对的，发三条就能看出方向。这一步的要点是把事实写全，而不是把话说漂亮。
标题怎么组
- 品类词放最前，让人一眼知道是什么
- 规格跟后面，型号、容量、尺寸按重要性排
- 成色用平台通用的表述，不用自造词
- 差异点放最后，套装、附赠、版本各说一句
- 不堆同义词，不写与商品无关的热词
图片怎么排
- 首图讲清楚是什么，背景干净
- 第二三张给正反面、接口、铭牌
- 瑕疵单独一张，位置拍清楚
- 包含物平铺一张，缺什么写明
- 单链接 3–9 张，同款多链接换图
价格与类目是两个容易被随意对待的字段。价格要填最终售价，把运费、赠品、议价空间都想清楚再填，发布后再改价会在平台上留下记录。类目按商品本质选，不按想被谁看到选；类目决定商品进哪个流量池，选错了后面改文案、改标题都救不回来，只能删了重发。
描述不要写成广告。买二手的人关心的是：现在什么状态、有哪些使用痕迹、配件齐不齐、能不能验、怎么交付。这五件事按顺序写清楚，问价的人会少一半，但问的人更准。具体到标题结构与描述骨架怎么排，写在文案与标题优化里，这里不重复。
字段填完之后对照一次台账的字段要求：item_id 由平台返回，标题、描述、价格是你填的。三者必须与提交的内容完全一致，中途改过就要回写台账。台账与实发不一致，后面所有的核对都失去意义，这一点在发布数据台账里讲得更细。
同一件商品要发多条链接时，差异要落在买家真能用上的信息里，不是落在措辞上。价格档位不同就改配置，成色不同就改瑕疵描述，配件不同就改包含物。只调标题词序、换几个近义词，属于形式差异，既过不了分散度检查，也不解决实际问题。买家看到两条措辞不同但内容一样的链接，只会觉得重复。
06 / 发布闸门
第四步：四道闸门，任何一道不过就停下
发布前有四道闸门，它们的作用不是拦你，是替你把明显会出问题的那一条挡在门外。四道都过才提交，任何一道不过就停，不要靠人工判断放行——人工放行的判据每次都不一样，等于没有判据。
GATE 01合规闸门
标题与描述里不能有绝对化用语、功效宣称、联系方式、侵权表述。这一道看的是措辞，不是商品本身好不好。改文案能过的就改，改不过的就换品。
GATE 02商品指纹去重
用标题、描述、价格等要素算出指纹，与台账里已发的记录比对。同一条商品重复发，指纹会撞上，直接拦下。撞了不是报错，是提醒你已经发过。
GATE 03分散度检查
类目、发布时间、标题、主图相似度四项一起看。四条链接同时出现在同一类目、间隔几分钟、标题结构一样、主图同一张，这种形态本身就异常，会被要求拆开。
GATE 04平台健康闸
平台侧出现异常时暂停发布，不硬发。硬发的代价是一条失败记录加上一段异常行为，比等半小时贵得多。恢复正常后再继续，进度不受影响。
还有一道时间点上的检查：到点发布之前，用当下的基线把合规闸门重跑一遍，不通过就不发。这是 fail-closed 的做法——拿不到确定结论时默认不发，而不是默认发。规则、词库、商品状态在这段时间里都可能变过，发布前那一刻的判断才算数。
被拦下之后怎么处理，按闸门分开。合规拦住就改措辞，改完重跑这一道；指纹撞了就说明这条发过，去台账里找原记录，不要另起一条；分散度不过就换时间或换主图；平台健康闸拦住什么都不用做，等。最不该做的是绕过闸门手工发一条，那等于把整套判断作废，还留下一次无法复盘的记录。
四道闸门的顺序也有讲究：先合规，再去重，再分散，最后平台健康。合规不过的商品，后面三道判断都没有意义；去重放在前面能省掉重复的分散度计算；平台健康闸放最后，因为它判断的是外部状态，与商品本身无关。顺序排对了，被拦下来时第一眼就能知道该改商品还是该等平台。
07 / 回执核对
第五步：看回执，不要只看界面提示
提交之后界面会给你一个提示，但提示不是结论。要确认这条商品真的上架了，按下面的顺序核对，一次核对下来通常不到一分钟。
拿 item_id
发布成功后平台会返回商品标识，把它写进台账。拿不到标识说明这条没有真正落地，不管界面提示什么。
打开链接
用返回的标识拼出链接，在浏览器里打开。能看到商品、价格、图片对得上，才算可见。这一步能挡掉大部分看起来成功实际没上架的情况。
对字段
标题、价格、类目、图片数量逐项与提交内容比。中文输入丢字、价格少一位、类目被平台改写，都在这一步发现。
看截图
流程在提交前后各留一张截图，出问题时这是唯一能回看的现场。截图里能看到当时页面停在哪、弹了什么提示。
确认入账
台账里出现这一条，字段完整，时间戳落在发布窗口内。入账失败要当成发布失败处理，因为后续所有核对都依赖这本账。
核对的意义在于建立对照。第一条发完，把自动化发出来的商品和你手工发的商品放在一起看：标题长度、图片顺序、描述分段、价格写法。差异明显的地方，多半是流程里某个字段映射错了，或者某段默认文案被带进去了。这种对照第一次做最有效，做三次之后就形成了你自己的标准。
如果核对发现商品上架了但字段不对，处理方式是改完再发一条新的，而不是在原链接上反复改。反复改会在平台上留下密集的编辑记录，和密集发布一样是异常形态。改之前先去商品合规检查把规则看一遍，确认不是规则理解错了。
核对还要留痕。把商品链接、截图、台账记录三者对应起来，形成一条能回看的证据链。以后出现争议，链上哪一环断了，问题就出在那一段：链接打不开是对不上平台，截图空白是流程没走到那一步，台账缺字段是写入环节的问题。这种定位方式比凭印象回忆可靠，也比重新发一条验证便宜。
08 / 加到日常
第六步：一条到十条，按阶梯加不按心情加
第一条跑通之后，最容易犯的错是一次把库存全铺上去。加量要按阶梯走，每一阶都留观察时间，出问题时能定位到是哪一阶引入的。
第一阶是一条：确认链路、回执、台账三件事都成立。第二阶是三条：同一批素材、不同商品，观察它们是否都能正常上架、字段是否都对。第三阶才进入日常节奏——每日 5–10 条，相邻间隔不少于 30 分钟并带抖动，发布窗口 09:00–21:59，单条服务线每日 2 条，单个账号每周上限 12 条。这些数字是节奏参数，不是目标值，能少不多。
为什么要留观察时间：加量之后出的问题，和单条时出的问题不是一类。单条时的问题多是配置错，加量后的问题多是节奏与形态问题——同一类目短时间集中出现、标题结构雷同、主图重复。这类问题在单条阶段看不出来，只有量上来才显形，所以每一阶都要停下来看一眼台账里的分布。
三个常见误区
一是把测试当成可以随便发。占位内容与真实商品走同一套审核，占位一样会被判定，测完还要清理，多做一遍还多一次风险。二是把加量当成目标。量是结果，链路稳定才是目标，链路不稳时加量只是加快暴露问题。三是出了问题先改流程再加量。要先弄清是哪一类问题，改流程只对配置类问题有效，对节奏类问题无效，改完还是会被拦。
日常跑起来之后，每天固定看一次台账，每周看一次分布：类目是否过于集中、发布时间是否挤在同一段、同款链接是否超过三条。这三项是形态问题的主要来源，也是发布节奏控制里反复强调的部分。看到异常就减速，不要等平台先动手。
最后一句：这套流程的价值是让你从重复操作里腾出手，去看选品和文案。如果跑通之后你还是在盯着每一条商品，那说明监控没配好，去看发布监控告警，把该自动发现的问题交出去。
加量的同时要同步提高观察频率，而不是反过来。量小的时候一天看一次台账够用；进入日常节奏之后，发布当天的分布要当天看，隔天再看就只能事后补救了。分布看三样：同类目占比、发布时间是否挤在同一段、同款链接条数。三样里任何一样明显偏了，先减速再查原因，不要一边偏一边加。
