把问题按七组答清楚，不用从头读到尾

01  /  费用

费用这类问题，先分清三类成本

问费用的人，多数想要一个数字。但同一个问题往下问一层，会变成「为什么和设备数量有关」。所以先把成本拆成三类，各自的决定因素不同，混在一起谈价格一定谈不清。

所以报价只能按「设备数 + 账号数 + 通道组合」来给。按条数报价在自动化里没有意义：系统不按条收费，按能同时挂多少条并行的设备收费。版本之间的差别在通道数量、设备数量与看板颗粒度，具体写在价格与版本里。

部署试用本身不收费，但需要你出一台设备或一个可用的网页版账号。试用期只做一件事：跑通一条真实发布，日志与台账都留下。跑通了再谈扩，跑不通就不该扩，这条比价格重要。

还有一种报价方式要先排除：按曝光或按成交分成。这类报价看起来把风险放在我们这边，实际上一定会把不确定性折进价格，最后你还是为「可能的曝光」付了一笔确定的钱。发布自动化能改变的是过程，不是平台分发。

判断贵不贵，把三类成本换成时间看更清楚：如果现在每天手工发布要花两小时，改成一小时核对加十分钟处理异常，省下的那部分时间值多少，才是这套系统对你的真实定价区间。至于设备本身要不要买，取决于你已经有几台闲置安卓机。

设备这一项可以先算清：一台能长期插电的安卓机，二手价格通常在几百元区间，跑满一年摊到每天不到两块。真正贵的是素材与时间，不是设备。所以谈价格时把这三类成本分开列，你会更清楚钱花在哪一段，也更容易判断该砍哪一项。

还有一句提醒：不要为了省设备费让一台日常手机兼跑。日常手机会弹通知、会锁屏、会被系统更新打断，一次中断就是一轮作废，省下的几百块最后会以返工的形式还回来。

02  /  合规

会不会被限流，看形态不看工具

这是问得最多、也最容易被含糊回答的一类。先把边界说在前面：我们不承诺绕开平台风控，也不承诺账号一定不出问题。平台规则与执行都在平台一侧，任何声称能保证的，都是在替别人的系统做承诺。

能承诺的是另一件事：把已知的风险项变成可检查的参数与闸门，让发布形态接近一个正常卖家，并且每一条都留下痕迹。具体落到这些取值上。

除了节奏，还有三道闸门：合规闸门查禁词与类目资质，商品指纹去重挡住重复内容，分散度检查把类目、发布时间、标题与主图相似度拉开。三条都在发布前跑，到点提交之前再用当下基线复跑一次，不通过就不发。这条策略叫 fail-closed，宁可少发一条，也不带着不确定的状态发出去。

另有一道平台健康闸：平台侧出现异常时暂停发布，不硬发。硬发的代价通常不是这一条失败，而是账号被连着看几天。具体判断与处理边界写在防封控那页，闸门的规则细节在商品合规检查。

还想说一句实话：形态做对了，只是把已知的风险项降到低位，不等于零风险。账号历史、类目竞争、图片质量、价格异常，这些因素系统控不了。把「不封号」当采购条件的，我们一般建议先不要上自动化。

还有三个常被误解的地方。第一，间隔带抖动不等于随机拖延，抖动是在下限之上加一点波动，下限本身不降；把间隔改成完全随机，反而会出现两条只隔几分钟的情况。第二，闸门拦下不等于这条商品有问题，多数是被相似度检查挡住，换主图或改措辞就能过，不需要重写整条描述。

第三点更实际：发布窗口是 09:00–21:59，你在凌晨跑批，系统会顺延到窗口内，这不是失败，只是排在后面。看到「没发出去」先看时间，不要先改参数。这三条弄清楚，大多数总觉得不对的担心会消掉一半，剩下的那一半才值得真去查。

03  /  稳定性

失败不可怕，日志要能指到具体一步

自动化跑到一定量，失败是常态。评价一套系统好不好，不看它会不会失败，看失败之后你能不能在三分钟内知道卡在哪。常见的故障就四类，每类的现象与处理都不一样。

这四类之外，还有一类不是故障但看起来像：内容被闸门拦下。流程报的是提交被拒，真实原因写在闸门的输出里，两处不在同一个地方。找不到原因时先去闸门输出里翻，不要在流程日志里反复看。

排查顺序建议固定成六步：看失败在哪一步、看界面树与截图、判是选择器还是页面、判是内容还是流程、判是单条还是整体、改一处再跑。改多处再跑，成功了也不知道哪一处起了作用。这套顺序在监控与告警里有更细的展开。

关于「稳不稳」还有一个可核对的依据：引擎自检在 3 台设备上各 13/13 通过，网页通道 82/82、主路径冒烟 26/26、手机通道 24/24、反向测试 PASS。这些是内部自检的通过情况，不是对外承诺的成功率，两者的区别请分清楚。想了解单条发布具体经过哪些步骤，看手机 APP 自动化通道。

另一个判断稳定性的办法是看失败会不会收敛。第一周失败十次、原因分散；第二周失败五次、原因集中在两类；第三周只在页面改版时失败一次——这说明排查在起作用。反过来，失败次数不变但原因每周都在换，说明根本问题没找到，只是被不同的症状盖住了，这种情况要停下来查流程，不要继续加量。

日志里最该有的是失败时刻的现场：停在哪一步、当时的界面树、一张截图。有这三样，隔着屏幕也能判断；没有这三样只能靠猜，而猜出来的结论通常把人带到错误的修复方向上。

04  /  效果

能保证的是一致性，不是曝光

「用了之后流量能涨多少」这个问题没有可负责的答案。曝光由平台分发决定，涉及账号历史、类目供需、价格、图片质量与季节，这些都不在系统手里。任何给出具体涨幅的答复，都是把不可控的东西说成可控。

能确定的是另一组事情，而且可以逐条核对：字段不遗漏、配图顺序一致、节奏按参数执行、每条发布有记录可查、被拦的原因能归到具体一类。这五条的共同点是它们在发布侧，不在分发侧。

所以判断这套系统值不值，建议换一组过程指标：发布成功率、被拦原因分布、节奏偏离多少、同款链接条数、类目与时段占比。这五项每周看一次，比盯曝光曲线有用，因为它们指向的是你能改的地方。看板的字段与口径见发布数据台账。

还有一个常被忽略的事实：发布量不是越多越好。同一个账号一天从三条跳到二十条，形态变化本身就会被看见。节奏那页给的取值是 5–10 条，不是因为我们做不快，是因为再快就不像人在做。想扩量，正确做法是加账号与设备，不是提高单账号的条数。

如果连续两周发布都正常，而商品的浏览与咨询没有变化，瓶颈通常不在发布环节：可能是价格带不匹配、主图不行、类目选错，或者这条商品本身没有需求。这时候继续加量只会让一批没有需求的商品占满你的链接数，处理办法在选品方法里。

最后说清一件事：系统不刷量、不做互动、不代你回复买家。它只负责把「发布」这一段做得一致且可回查。把发布做对是必要条件，不是充分条件。

还有一个容易走偏的指标是每天发满上限。上限是风险控制的约束，不是产能目标。把发满当成任务，你会不自觉地放宽内容质量，最后得到的是一批同质链接，既占了链接数，也拉低了账号的整体印象。正确做法是把上限当红线，日常跑在六到八条。

至于多久能看出变化，建议按两周看一次，一次只动一个变量：这周只换主图，下周只调价格带。同时改三样，看到变化也不知道是哪一样起的作用。两周一次的节奏不会让你错过什么，反倒是每天看一次的人，容易把正常波动当成问题去改。

05  /  技术

两条通道怎么选，看发布动作落在哪

系统有两条执行通道，共用同一套选品、文案、闸门与台账，差别只在最后那一步动作落在哪里。

判断办法很简单：先看你要发的类目，字段在客户端是不是比接口更完整。是，手机通道就不是可选项；否，网页通道更划算。两条通道也可以混用，同一份发布计划照常走，台账还是一本。

中文输入这一环要单独说明。用 adb 直接注入文本打不出中文，这是底层限制；系统里备了三条输入通道，其中 uiautomator2 那条已验证可以输入中文，另外两条是按键注入与输入法模拟。发布中文标题会失败，八成是这里的问题。

还有一个容易被当成手工配置的细节：同一份发布计划里，两条通道的槽位归属是算出来的，由同一个函数对象决定，不是人在配置里标出来的。这样改一处参数，两条通道的分配同时变，不会出现一边改了另一边没改的情况。完整动作与流程写法见手机 APP 自动化通道与电脑网页版通道。

还有个常被问到的问题：能不能两条通道同时跑同一个账号。技术上可以，但不建议。同一个账号在两个入口同时提交，间隔会变得很密，形态比单通道更难解释，而且两条通道的登录态可能互相顶掉，一方把另一方挤下线。稳妥的做法是一个账号固定一条通道，账号之间再分散。

模拟器与真机的差别也值得说一句：模拟器部署快、可复制，但部分客户端功能在模拟器上的表现和真机不同。遇到真机能发、模拟器发不出去的情况，先怀疑这一层，不要急着改流程。两条通道并存的意义不在互相替代，而在让每个账号都能选到适合自己的那一条路径。这个判断比任何参数都省事，因为它先解决了用哪条的问题。

06  /  上手

上手要准备的四样，缺一样都跑不动

部署不是装个软件就完事。下面四样缺任何一样，流程都会停在半路，而且停的位置每次都不一样，很难排查。

• 一个能正常登录的账号手机通道要能在这台设备上走完整个发布链路；网页通道要有可用的登录态。账号本身有异常提示的，先处理账号，不要急着上自动化
• 一台长期在线的设备安卓真机或模拟器，长期插电、固定网络、关闭自动更新与锁屏。临时用一台日常手机跑，第二天就会因为弹窗失败
• 一批可对外发布的素材每条商品 3–9 张图，图片要是自己的或已获授权。素材不合规，闸门会拦，这不是系统问题
• 一个每天花二十分钟核对的人不看台账的自动化等于没装监控。这个人不需要懂代码，但要看懂失败原因

部署的顺序固定：先装环境并确认驱动跑在 Windows 侧（WSL 到 Windows 的 TCP 不通，驱动放错边会表现为一直连不上），再跑通一条真实发布，然后按你的类目调闸门参数，接着把节奏开小跑一周，看台账没问题再加量。跳过第三步直接开量，是被拦最多的一种开局。

需要多久取决于素材准备。环境和单条跑通通常在一天之内，慢的是把一批商品的主图与描述整理成可以填进流程的样子。这一步没人能替你省，因为判断成色、写清瑕疵、定价格只有你知道。

安装包、环境依赖与版本要求写在下载与部署，从零开始的操作步骤在自动铺货教程，建议按那个顺序读，不要跳。

部署当天的验证要落到看得见的结果：一条商品真的出现在账号里、有链接、有编号、台账里能查到对应记录，四样齐了才算跑通。只看到流程日志显示成功不算，日志可能是流程跑完而提交没成功，用平台上的实际内容核对最可靠。

至于要不要一次把所有类目都接进来：不要。先接一个类目跑一周，把这个类目的字段、图片要求、常见拦截原因摸清，再接第二个。一次接五个类目，出问题时你分不清是类目规则不同还是流程写错了。一个类目跑熟了再接下一个，这个顺序看上去慢，实际上是最快的。类目一多，参数就没法统一取值，节奏也跟着乱，最后哪个类目都没跑好。

07  /  数据

数据留在一本账上，问题才查得动

两条通道一起跑，最怕各记各的账。手机通道一个文件、网页通道另一个文件，出问题要人工对，对完还不知道哪份是对的。系统的做法是两条通道写同一本台账，由同一个写入模块处理，口径只有一套。

台账每条至少五项字段：商品编号、标题、描述、价格、时间戳。缺一项就断一环核对：没有编号打不开链接，没有标题算不出指纹，没有时间戳看不出节奏。字段要一开始就定全，因为补字段比补数据容易。

数据存在本地，不上传云端，也不做统计埋点。这一点对卖家很重要：商品素材、描述、价格都在你自己的机器上，换工具不需要导出。代价是备份要自己做，建议把台账目录纳入你现有的备份习惯。

还有一条经验值得单独讲：自检曾经污染过生产发布记录，根因是路径解析早于环境变量生效，自检写到了生产文件上。之后加了三道防护——写生产数据前先留备份、自检进程带标记时向生产写入直接抛错、整轮自检前后对生产文件做哈希比对。同类问题之后再没发生过。

发现台账与平台对不上时，先怀疑记录，再怀疑执行。记录涉及路径、权限、编码、并发写入，出错概率更高，而且出错时通常没有明显现象。检查顺序是：写入路径对不对、路径解析是否早于环境变量、有没有并发写、时间基准与编码是否统一、有没有自检数据混进来。

反查能力也值得先确认：给定一条商品或一个时间段，能不能立刻翻出当时的完整记录。这个能力取决于字段是否完整，不取决于用什么工具存。字段与看板的读法在发布数据台账。

台账还有一个容易被忽略的用途：核对人工改动。发布之后你在平台上改过标题或价格，就要回写台账；不回写的话台账记的是旧内容，后面所有比对都是错的。这类不一致最难查，因为两边看起来都正常，只是对不上。发现对不上时先假定台账是错的，用平台上的实际内容去校。

备份的做法很朴素：每天发完把台账目录复制一份到另一块盘，保留最近两周。文件不大，成本几乎为零，真出问题时能救回一整周的记录。不要用「平台上反正有」当备份理由，平台上的内容会被你自己改掉，台账记的是当时的提交内容。

08  /  边界

这几种情况，我们会直接说做不了

写这一节不是为了显得克制，是为了减少无效沟通。下面几类需求，答复基本都是不行，原因都写清楚了。

• 要求保证不封号账号在平台一侧，规则与执行都由平台决定。能承诺的是把已知风险项变成可检查的参数，不是结果
• 要求绕开平台审核不做。这类需求即使技术上能实现，代价也落在你的账号上
• 只有几条商品要发写流程、调参数、跑通单条的时间，比手工发这几条更长。这种情况手工更快，也更省心
• 素材靠搬运他人图片合规闸门会拦，而且风险不在系统侧。素材的授权问题只能由发布者解决
• 要拿去做站外引流不在产品范围内。系统只做站内发布与发布数据，不做导流内容
• 要求代发、代管账号不做。账号始终在你手里，我们只交付系统与部署

反过来，下面三类通常适合：一个人管一个账号、每天要发五到十条同类商品；一个小团队管几个账号、素材多但人手不够；做二手数码这类字段固定、成色描述重复度高的品类。三类方案分别写在个人卖家、品牌与商家、二手数码铺货里。

如果你现在还没想清楚属于哪一类，先看关于我们里我们怎么判断适配，再看联系我们里的需求摘要。把账号情况、类目、素材、设备、目标条数写清楚，比问「能不能用」更容易得到有用的答复。

最后提醒一句：自动化解决的是重复动作，不解决选品。发布再稳，商品没有需求也不会有咨询。这一点在选品方法里写得更细。

还有一类需求介于行与不行之间：想先看看效果再决定是否部署。这种情况建议走试用，但试用期的目标要定死——不是发一批看看有没有流量，而是跑通一条并确认台账、日志、闸门三样都在工作。前者两周也未必有结论，后者一天就能验完。

另外，如果账号近期刚有过提示或限制，先处理账号，不要上自动化。带着不确定状态的账号跑批，一旦出问题，你分不清是账号本身的问题还是系统造成的，排查会变成互相解释。先把账号处理干净，再谈自动化，这个顺序不能倒。账号状态不稳的时候，任何自动化都会显得不可靠，连正常的失败也没法归因。