先自己发一遍，再把它写成系统

01  /  主体

我们是谁：一家公司，一个产品

网鱼AI电商助手是烟台深度探知人工智能科技有限公司旗下的产品。公司主体在山东省烟台市，产品面向闲鱼与同类二手电商卖家，做的是铺货与发布这一段自动化：选品、文案改写、合规检查、发布节奏、风控参数、发布台账。

产品有两条执行通道。一条是手机 APP 通道，用 ADB 驱动安卓真机或模拟器，按 YAML 流程在屏幕上完成点按与输入；另一条是电脑网页版通道，走 HTTP 接口提交。两条通道共用同一套上层逻辑，包括同一份发布计划、同一套合规闸门、同一本台账。

这页不写下面这些内容，因为它们对判断产品没有帮助：团队人数、公司成立年限、客户数量、融资情况、媒体报道。这些数字即使写上去，也不能说明这套系统在你的账号上能不能跑通。想看能验证的东西，可以直接跳到产品功能总览，或者看下载与部署里的环境要求。

能自查的部分反而值得先看：两条通道各自解决什么问题、闸门在什么条件下拦下一条商品、失败之后日志里留下什么。这三样都能在部署试用里当场验证，比任何介绍文字都可靠。

最后说清关系：公司是主体，产品是工具。账号、素材、定价、客服始终在卖家自己手里，我们交付的是系统与部署，不接手你的账号，也不替你面对买家。

关于主体还有一点值得说明：以公司名义做这类工具，意味着合同、发票、售后都有明确的承担方。发布自动化涉及账号安全、素材留存与数据记录，一旦出问题需要有可追溯的责任主体，而不是一个找不到人的个人号。你可以把公司全称拿去公开渠道核对，这一步建议每个采购者都做一遍，成本很低。

还有一层是产品的独立性：系统不绑定账号，也不绑定设备品牌。换设备、换账号、换类目，流程与参数跟着改就行，数据仍然在本地。这一点决定了你以后想换工具时不需要导出，也决定了我们没法用数据把你留住——只能靠东西本身好用。

顺带说清一件事，免得误解：产品不是通用型的电商工具，它只做二手电商的发布这一段。范围窄的好处是每一条参数都能对应到具体场景，坏处是你不能指望它解决选品与客服。这两件事仍然要你自己做。

02  /  起点

为什么从自己手工发闲鱼开始

这个产品不是先有技术再找场景，顺序是反的：先自己发，发到烦，才动手写流程。

手工发闲鱼的烦不在写文案，在重复。同一批货，每条要填的字段几乎一样，成色、配件、包邮与否、发货地、议价空间，填几十遍之后人就会开始凭记忆走。凭记忆走的第一个后果是漏填：这条写了包邮那条没写，这条标了九成新那条忘了标。第二个后果更麻烦，是没有记录——三天后想回查某条商品当时怎么写的、什么价、几张图，只能去平台上一条条翻。

这四条加起来，指向同一个结论：该被写成流程的不是文案，是动作顺序。于是第一版只做一件事——把打开应用、进发布、填标题、选类目、传图、定价、提交这一串动作写成文件，跳过任何一步都会在日志里显出来。

这个起点决定了产品的重心：它更在意「每条都一样、每条都可回查」，而不是「发得多快」。所以你会看到每日 5–10 条这种看起来保守的参数，也能看到发布前复检这种宁可少发的设计。这些不是保守，是被手工经验推出来的。

早期也做错过一件事：一开始想把所有类目塞进同一套流程，结果每个类目的字段、图片要求、常见拦截原因都不一样，流程里堆满分支，改一处就影响另一处。后来改成按类目各写一套流程，共用底层的输入、点击与闸门，问题才收敛。这个教训留在了产品结构里：公共能力下沉，类目差异上浮。

还有一课是「不是所有类目都值得自动化」。字段越固定、重复度越高，流程的价值越大；字段每次都不同、一个季度只发几条的，写流程的时间比手工更长。这条判断标准后来变成了给客户的建议，写在适配那一节里，也写在选品与节奏两页里。

03  /  取舍

两条通道，各自放弃了什么

很多人问为什么不做一个万能入口。答案是做不出来：客户端与接口在字段层面就不完全等价，编辑页的字段展示顺序、图片上传后的裁剪位、草稿状态的保存时机、只在应用内出现的活动入口，这些差异不是接口封装能抹平的。所以产品选择承认差异，做两条通道。

放弃之外还有一层设计：两条通道的槽位归属是算出来的，由同一个函数对象决定，不是人在配置里标出来的。这样改一处节奏参数，两条通道的分配同时变化，不会出现一边改了另一边没改的情况。同一个发布计划交给两条通道执行，记录仍然写进同一本台账。

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

两条通道可以混用，但不建议同一个账号同时开两条。同一账号在两个入口提交，间隔会变密，登录态也可能互相顶掉。稳妥的做法是一个账号固定一条通道，账号之间再分散。通道的技术细节分别写在手机 APP 自动化通道与电脑网页版通道。

实际部署里最常见的组合是一个账号一条通道。两个账号以上才会考虑两条并用，此时按账号而不是按商品分通道，避免同一账号的登录态在两个入口之间来回顶。设备数量按并行条数算，不按账号总数算：一个账号每天五到十条，一台设备就够；三个账号要同时跑，才需要三台，或者把其中一部分挪到网页通道并行。

还有一个判断常被忽略：类目字段在客户端是否比接口更完整。是，手机通道就不是可选项；否，网页通道更省设备与时间。这个判断最好在试用时用一条真实商品验证，不要凭猜。两条通道各自的完整动作与失败处理，写在通道那两页里。

04  /  工程取舍

宁可少发一条：fail-closed 的选择

自动化系统有两类错误：一类是多发了不该发的，一类是少发了本该发的。第二类只是效率损失，第一类会把账号拖进麻烦。产品的默认选择是让错误偏向第二类，也就是 fail-closed。

• 发布前复检到点提交之前，用当下的基线把合规闸门重跑一遍，不通过就不发。计划是几分钟前定的，商品信息可能已经变了
• 平台健康闸平台侧出现异常时暂停发布，不硬发。硬发的代价通常不是这一条失败，而是账号被连着看几天
• 写生产先留备份写生产数据之前先留一份 .bak，出问题能回到上一个状态
• 自检不许碰生产自检进程带标记时向生产写入直接抛错，整轮自检前后对生产文件做哈希比对

最后两条来自一次真实事故：自检曾经污染了生产发布记录，根因是路径解析早于环境变量生效，自检写到了生产文件上。这类事故的特点是没有报错、没有异常提示，只是台账里多出几条并不存在的记录，几天后才被发现。之后才加上前面那三条防护。

同类经验还有几个，都是从坑里出来的：WSL 到 Windows 的 TCP 不通，驱动必须跑在 Windows 侧；uiautomator2 一个进程只绑一个 adb server 端口，多设备并行要加端口锁；界面树在 launcher 屏会取不到，需要先试压缩模式再退回普通 dump。这些细节不影响采购决策，但影响你部署当天的体验。

可核对的自检情况：引擎自检在 3 台设备上各 13/13，网页通道 82/82，主路径冒烟 26/26，手机通道 24/24，反向测试 PASS。这些是内部自检的通过情况，不是对外承诺的成功率，两者的区别请分清楚。发布前的闸门规则见商品合规检查。

fail-closed 是有代价的：某些天你会少发几条，某些批次会整批停在闸门前面。这个代价是刻意接受的，因为它的表现形式是「今天少发了几条」，而不是「账号被连着看了几天」。判断这套设计是否合理，只需回答一个问题：你更怕少发，还是更怕发错。做长线的人答案基本都是后者。

代价能承受，前提是失败原因写得清楚。被拦时要能回答三个问题：哪一条、哪一类原因、改哪里能过。答不出来，闸门就变成了黑箱，人会开始绕开它跑，那比没有闸门更危险。所以闸门的输出从来不是一句「不通过」，而是具体到判断项与字段。

05  /  边界

我们明确不做的四件事

边界写清楚，比能力列表更有用。下面四类需求，答复基本都是不行，原因也一并写出来。

另外三件小事也不做：不卖账号、不卖素材包、不做刷量与互动。前两件是把风险转给你，第三件是直接违反平台规则。这些决定让产品的能力看起来少一些，但省掉了大量事后解释。

与「不做」相对的，是明确会做的：把流程写清楚、把参数给全、把失败原因记下来、把台账口径统一。这四件事都能在部署当天验证。想看具体参数取值，去防封控；想看被拦之后怎么改，去常见问题。

偶尔会遇到要求把条数放宽到每天三十条的情况。这类需求不接，理由不是做不到，而是做到之后风险全落在你的账号上，我们拿不出对应的保障。可以把节奏理解成刹车：刹车不是限制车速，是让你需要停的时候停得住。参数被放宽之后，出问题时连回退的基准都没有。

还有一种请求是把闸门关掉「先跑起来再说」。这一条同样不接，因为闸门是这套系统里唯一能在提交前拦住问题的地方，关掉它，等于把所有判断都推到发布之后，而发布之后能做的只有补救。

这两条拒绝都写在部署说明里，不是临时口径。接受一个大客户的宽松需求，换来的是所有客户共用一套默认值的风险，这笔账不划算。

06  /  工作方式

团队怎么做事：先跑通一条

工作方式可以用一句话概括：先跑通一条真实发布，再谈铺量。这句话既是给客户的建议，也是内部排优先级的顺序。

具体落到四件事上。第一，问题按「会不会影响已经跑通的链路」排序，能挡住发布的先修，界面上的小毛病往后放。第二，任何新功能上线前要能在自检里复现，不能复现的不算完成。第三，参数改动写进更新日志，尤其是会影响发布形态的取值，默认只收紧不放宽。第四，交付边界写在部署说明里，哪些包含、哪些不包含写清楚，避免做到一半才开始谈范围。

响应方式：工作日 09:00–18:00，先文字说明现象，再决定要不要通电话。带着日志与台账截图来问的，通常一轮就能定位；只写「发不出去」的，要先花时间问清是哪一步。怎么描述需求最快拿到有效答复，写在联系我们那页，里面有需求摘要的填法。

还有一点要说明：我们不承诺即时响应。发布链路的故障通常需要看现场（日志、界面树、截图），隔着屏幕猜结论只会浪费双方的时间。把现场留下来，比催得更紧有用。

交付时会留三样东西：一份部署说明（环境、账号、设备、常见故障）、一份参数表（当前节奏与闸门取值，以及为什么取这个值）、一份台账字段说明。三样都是文字，不依赖谁记住。这样即使换人接手，也不用从头问一遍。文档比口头交代可靠，多人协作时这一点尤其明显。

内部也一样：任何结论要能被第二个人复现，否则不算结论。自检能跑出同样的结果，日志能指向同一步，台账能查到同一条记录，这三样齐了，才把一个问题标成已解决。这个习惯是从前面那次污染事故之后定下来的。

写下来还有一层好处：新人接手时不用靠问。发布链路上大量问题是重复出现的，同一个失败原因第二次出现的处理时间应该比第一次短得多，差别就在有没有把上一次的结论写下来。

07  /  版本

版本与更新：默认只收紧

发布自动化有一个特殊性：平台侧的页面结构与审核规则会变，系统必须跟着变。所以版本管理不是加功能，主要是两件事——修选择器、调闸门判断项。

每次更新的内容写在更新日志里，分三类记录：修了什么（选择器、流程步骤）、改了什么参数（节奏、条数、相似度阈值）、加了什么判断项（新的拦截原因）。这三类分开写，是因为它们对你的影响不同：修选择器是恢复功能，改参数会影响形态，加判断项会让你看到更多「被拦」。

参数默认只收紧不放宽。平台侧的规则变严时，默认值跟着变严；反之不会自动放宽，需要你确认。这条规则看起来保守，但能避免一种情况：某天平台松了一点，系统自动把条数加上去，等到规则再收紧时，账号已经在高位跑了一段时间。

更新之前建议做一件事：把台账目录复制一份。文件不大，成本几乎为零，但真出问题时能救回一整周的记录。更新之后第一轮先跑小量，确认单条能通，再恢复日常节奏。这个习惯在下载与部署的升级说明里有对应步骤。

还有一类更新不算版本：你自己的类目与素材变了，闸门参数要跟着调。比如从二手数码换到家居，图片要求、标题写法、常见拦截原因都不一样。这类调整不写进更新日志，但建议自己记一笔，下次换类目时能少走一遍。

更新频率取决于平台侧变化，不按日历排。平台稳定的时候可能几周只改一处，改版频繁的时候一周要修两次选择器。不做的事情也很明确：不做界面上的花活，不做与发布无关的附加功能。功能每加一个，出问题时要排查的面就宽一层，对一个要长期无人值守跑的系统来说，这是负担而不是好处。

出问题时的顺序也固定：先看是不是平台改版，再看设备与网络，最后才怀疑流程代码。顺序反了会白改一通代码，改完发现原因是设备休眠。这套排查顺序在监控那页有完整版本。

版本号本身不用记。判断自己是不是最新版，看更新日志最后一条的日期即可；跨版本升级不需要逐版打补丁，装最新一份、跑一轮自检、确认台账能读，三样成立就算升级完成。

08  /  适配

判断适不适合：三类适合，三类不适合

把适配问题拆成两个清单，比看功能介绍快。

不适合的三种也要说清。只有几条商品要发的，写流程、调参数、跑通单条的时间比手工更长；素材靠搬运他人图片的，闸门会拦，而且风险不在系统侧；想用自动化做站外引流的，不在产品范围内。这三种情况下，手工更快也更省心。

判断自己属于哪一类，有个简单的问法：你的发布动作里，有多少可以被写成「先判断、再执行」？这个比例越高，接进来的收益越明显；如果绝大多数步骤都要临场决定，那先别接。三类方案的细写在个人卖家、品牌与商家、二手数码铺货里。

想先看价格与版本的差别，去价格与版本；想先确认环境与设备要求，去下载与部署。这两页看完还有问题，再带着账号情况、类目、素材、设备、目标条数来问，答复会具体得多。

试用期的目标建议定成三句话：一条商品跑通、台账能查到这条记录、失败时能看到原因。三条都成立，再谈扩量；有一条不成立，先别扩。这个标准比「发一批看看有没有流量」有用，因为后者两周也未必有结论，前者一天就能验完。

最后提醒一句：自动化解决的是重复动作，不解决选品。发布再稳，商品没有需求也不会有咨询；这一点写选品那页更细。如果你现在还没有明确的类目与素材，先把这两样理清，再来谈部署，会省掉一轮返工。

还想补一句关于规模的判断：先跑一个账号、一个类目，跑顺了再加第二个。一次上五个账号的，通常第二周就会因为分不清哪个账号出了问题而全部停下来，回头做的第一件事还是逐个跑通。顺序反过来，成本只会更高。

按这个顺序走，第一周的产出通常只是一条能复现的发布记录，看起来不多，但后面每一步都建在它上面。