价格这件事，先把计量口径说清

01  /  计量单位

计价单位是服务线与设备，不是发布条数

先纠正一个最常见的预期：这类工具不按“发布条数”卖，也不适合按条数卖。原因不在商业设计，在规则本身。发布节奏是按服务线算的：每日 5 到 10 条，条间隔不小于 30 分钟并带抖动，窗口 09:00 到 21:59，单服务线每日 2 条，周上限 12 条。条数是被这些规则压住的，不是可以自由放大的量。把它当售卖单位，等于承诺一件规则不允许的事。

所以计量单位落在三处：一是服务线数量，也就是要接几个账号；二是设备数量，也就是要接几台手机或模拟器；三是交付范围，也就是含不含部署、含不含值守与升级支持。这三项决定了工作量，也决定了报价。

服务线为什么是最小单位？因为同一份发布计划里，两条通道的槽位归属是算出来的——同一个函数对象算出结果，不是人工标注。一个服务线对应一套配额与一套计数，两个账号就是两套。合并成一个单位，账就没法算：条数按哪个账号算、闸门按哪个账号拦、周上限按哪个账号结。这些都不是抽象问题，直接决定能不能守住节奏。

设备数为什么单独算？因为设备带来的不是“更快”，而是运维面。每加一台设备，要多一个 adb server 端口、多一份租约、多一次自检、多一处可能隔离的位置，还要留备用机与供电余量。这些工作不会因为“同一套软件”而消失。所以按设备数量分档，比按台数打折更接近真实成本。

那“条数”在这个体系里起什么作用？它只作为运行结果出现在台账里，不作为计量依据。有人会问“能不能按条收费”，答案是不建议：一旦按条收费，双方的目标就从“稳定在规则内跑”变成“尽量多跑”，而这恰好是风控最敏感的方向。真正该谈的是“每天稳定跑满几个服务线的配额”，而不是“一个月发多少条”。

本页不列具体数字，也不做区间暗示。具体报价以联系沟通为准，因为同一套软件在不同交付范围下差别很大：只做部署验收，和包含值守、包含升级验证，是完全不同的两件事。

还有一层差别要提：通道组合。两条通道的成本结构本来就不同，手机通道花在设备、端口、供电与值守上，网页通道花在接口对接与请求节奏上。只做网页通道，设备侧的开销可以省掉大半；两条都要，设备池这一套就得完整建起来。所以报价里写清“含几条通道”是必要项，写“含自动化”则太笼统，等于没界定范围。

服务线数还有一个下限问题：少于一个服务线的说法不存在，一个账号就是一条服务线。所以不存在“半个账号”的折价空间，也不该出现“按条数折算成服务线”的算法，那只会把配额算乱。

02  /  版本边界

版本差在边界与责任，不在功能开关

常见的分档方式是“基础版少几个功能、专业版多几个功能”。这个方式在这类工具上不成立，因为核心模块是连着的：选品、文案、合规、节奏、台账、两条通道，缺一块就跑不出完整链路。把某个模块关掉，不是“少用一个功能”，而是整条链路断在那里。

所以分档的维度放在边界与责任上，三档的差别可以这样理解。

三档之间有一个容易忽略的分界：谁承担“出问题之后的第一反应”。单机档的第一反应是你自己，多设备档通常有一段陪跑期，代运营档是交付方。报价里如果没写清这一项，后面所有关于响应速度的期待都会落空。

还有一条判断标准：分档不应该影响“能不能守住规则”。合规闸门、指纹去重、同款链接不超过三条、到点复检 fail-closed，这些在任何一档都必须在。如果某份报价把“合规检查”当作高档才有的功能，说明它对这套系统的理解偏了——那些不是增值功能，是能不能安全跑起来的前提。

选档的方法很简单：先数账号，再数设备，再看你能投入多少值守时间。账号一个、设备一台、每天能看两次日志，单机档就够；账号三个以上、设备三台以上、没人整天盯着，就该进多设备档；自己完全不想碰设备和值守，才谈代运营。跳档买不会更快，只会多出用不上的配置。

还有一种情况要单独说：账号在养的阶段。这时节奏本来就该收紧，设备也不必一次配齐。先按最小配置把流程跑顺，等类目与配额稳定之后再谈加档，比一开始按满配买更省钱——多出来的设备与端口在闲置时同样要维护，还要占着备用机的位置。反过来做的人不少：先把设备买齐，再想办法把量跑上去，结果常常是设备空转，成本先到。

03  /  包含项

报价里通常包含这几层

把“包含什么”写清楚，比把价格说清楚更重要。下面是这套系统在交付时实际含的几层，判断一份报价是否完整，可以逐条对。

这五层里，最容易被漏掉的是“自检”。有些交付只承诺“装好能用”，不承诺跑完分层自检。区别在于：装好能用是当天能发一条，分层自检是知道它在什么情况下会坏、坏了怎么定位。前者省一天，后者省一个月。

另一个容易被含糊处理的是“升级”。规则会变，平台界面会变，流程要跟着改。升级是否包含、包含几次、验证到什么程度，必须写在报价里。写成“后续可协助升级”这种表述，等于没写。

还有一处要核对：交付是否包含换机重装。设备会坏，换一台要重新授权、重新分配端口、重新跑一次 13 项自检，这部分工时算不算在范围内，报价里常常没写，真正发生时就成了争议点。这一项写清楚，换机就不会变成一次扯皮；没写清楚，每换一次都要重新谈一次费用。

04  /  不含项

这些永远不在报价里

比“含什么”更容易引起争议的是“不含什么”。下面这些项默认不含，谈判时提前说清，能省掉后面大部分扯皮。

还有一类不含项容易被忽略：规则变化之后的适配。平台侧界面改版、字段调整、审核口径变化，都可能让某条流程需要改。报价里通常包含一段期限内的适配支持，超出这段期限或超出范围的改动按实际工作量另计。这不是推责任，而是这类工作的量无法预先估死——改一个选择器是半小时，改一整条流程可能是两天。

人力值守也要说清。系统能自动跑，但“没人看”和“有人看”是两种运行状态。值守要做的事很具体：每天看一次台账的四个数（槽位数、成功、失败、跳过）、看隔离列表、处理顺延队列、在平台异常时确认暂停是否生效。这些事在单机档通常由你自己做，在多设备档可以包含一段陪跑，在代运营档由交付方承担。报价里如果只写“系统自动运行”，要追问一句值守边界在哪。

数据归属也要提前写。台账、配置、流程文件、日志属于谁，退出时能不能带走，带走的是什么格式。这一条不影响报价数字，但影响你两年之后换不换得动。合理的约定是：数据归你，配置与流程文件可导出，台账以可读格式交付。

资质与账号手续这一项也要说清：账号实名、经营资质、售后责任都在使用方这一侧。工具侧可以提供操作流程与合规检查，但不能替账号承担责任，也不适合代为持有账号。这一条写进约定，双方边界清楚；不写，出问题时容易纠缠在“谁该负责”上，而这个问题的答案本来就在账号归属上。同理，商品描述里关于成色、保修、退换的承诺，也只能由卖家自己给。

05  /  附加成本

报价之外，还有这几笔钱

判断总成本时，软件那一笔往往不是最大的。下面这几笔加起来，可能超过软件本身，而且都是持续发生的。

设备与备用机这一项最容易低估。有人按“五个账号五台设备”配，结果一台隔离就有一天的槽位发不出去。合理配置是主设备按服务线数配，备用机按三分之一左右配，并且备用机也要过入池判定、也要有端口。备用机不是放在抽屉里等坏，它要能在十分钟内接管。

素材这一项常被当成内容问题，其实是成本问题。单链接 3 到 9 张图，同款链接不超过三条，类目要分散，主图相似度要拉开——这几条规则决定了你不能反复用同一组图。按类目批量拍、批量裁、批量命名，单条成本会明显下降；逐条临时找图，时间成本会翻几倍，而且质量不稳。

隐性成本里最贵的一项通常不写在表里：试错。第一版流程大概率跑不通，要改选择器、改文案模板、改节奏参数。这段时间的产出接近于零，但它决定了后面能不能稳定。把试错期算进计划，比事后压缩它更省钱。相关经验的整理见闲鱼自动铺货教程。

还有一项是账号风险。这条不适合量化，但必须承认：任何自动化都有被平台判定的可能，账号一旦受限，损失的是账号本身的积累。控制方式不是“跑得更快”，而是守住节奏与结构规则，并且在平台异常时暂停。这部分的做法在防封控里有完整说明。

电费这一项看起来小，但它跟运行时间成正比，而运行时间由窗口决定。窗口是 09:00 到 21:59，非窗口时段让设备休眠，能省下的不只是电费，还有设备的老化速度。反过来，如果为了“随时能接任务”让设备整夜在线，一年多下来的电费与损耗够换一台备用机。

06  /  费用结构

一次性费用与持续费用要分开谈

报价谈不拢，多半是把两类费用混成了一句总价。分开谈就清楚了：一次性的是把系统跑起来，持续的是让它继续跑。

这三段要分别有验收方式。部署段看自检项是否全过；值守段看响应时限与处理记录；升级段看变更记录与回归结果。三段里任意一段没有验收方式，这一段的费用就只能靠信任，而信任在出问题时不起作用。

还有一个分界线要谈清：什么算“故障”，什么算“变更”。设备掉线、端口占用、自检不过属于故障，属于运行范畴；新增一个类目的发布模板、改一套文案规则属于变更，属于工作量范畴。两者混在一起，会出现“每次小改都被算成故障保修”或者“设备坏了被算成变更收费”的争执。提前用一句话定清：系统按原配置跑不动是故障，改变配置内容才是变更。

付款节奏不是本页的重点，但有一点值得提：把尾款与验收项挂钩，比与时间挂钩更合理。分层自检全过再结尾款，双方都清楚什么时候算完成。反过来，如果验收标准只写“交付可用”，尾款就只能凭感觉结。

合同期与折扣要按同一套逻辑看。按年签通常比按月签的总价低，因为交付成本集中在前段，合同越长摊得越薄。但要先问清两件事：合同期内设备数与服务线数能不能调整、怎么调价；提前终止时已付部分怎么处理。这两条不清楚，长期合约反而会变成负担——规模缩小了却仍按原档付费，是这类合约里最常见的一笔浪费。

07  /  比价方法

两份报价怎么逐项对齐

拿到两份报价，不要先比总价，先比口径。口径不同的两份报价，总价没有可比性。下面这张清单可以逐条对，十项对完，差异自然显出来。

• 计量单位按服务线、按设备，还是按条数；按条数的一律要先问清节奏规则怎么守
• 服务线上限含几个账号，超出怎么算，是加钱还是不能加
• 设备上限含几台设备，备用机算不算在内
• 通道范围两条通道都含，还是只含一条
• 部署方式是否含到场或远程部署，含几次（换机重装算不算第二次）
• 验收标准是否写到具体项，能不能逐项核对
• 升级条款含不含升级，含多久，回归怎么验证
• 响应边界故障多久响应，谁来处理，超出算不算变更
• 数据归属台账与配置归谁，退出能否导出、导什么格式
• 锁定条件是否绑定设备序列号或机器码，换机怎么处理，换机要不要另付费

这十项里，最容易被藏起来的是第九和第十。数据归属不清，两年后想换供应商时才发现台账导不出来；锁定条件不清，换一台设备就要重新付费，而设备是会坏的，这在长期是一笔确定的支出。

低价报价常见几种形态，看的时候要对上原因：一是只含部署不含值守，价格自然低，但你要自己承担每天的检查；二是设备上限写得很紧，实际用起来第一周就要加钱；三是验收标准写得虚，交付当天能发一条就算完成，后面出问题都算变更；四是不含升级，规则一变就要另付。这四种都不是骗，但都要在比较时还原成同一口径。

反过来，高价也不一定更完整。要问的是“多出来的钱买了什么”，如果答不出具体项（多几次部署、多长的陪跑、多快的响应、含不含升级），那部分溢价就没有依据。判断标准始终是那十项，不是总价高低。

对齐十项之后，如果两份报价还差得远，通常差在两处：值守人力和升级责任。这两项都与人有关，不随规模摊薄。所以更实际的做法是先定自己需要哪一档，再在同一档里比价，而不是把三档混在一起比。

成本判断还有一个常被忽略的角度：把每月总成本除以当月实际发布条数，得到一个单条成本，再看这个数跟单件商品的毛利比。这个算法不精确，但它能挡住一种冲动——为了摊薄软件费用而多上设备。设备加上去、条数上不去，单条成本反而更高，因为硬件、电费与值守是固定的。

08  /  决策清单

规模与成本的关系，和不该买的情况

有一件事需要说清：这类系统的成本不随规模线性下降。设备从三台加到十台，软件侧的边际成本可能变化不大，但硬件、供电、端口、值守、故障面都在涨，而且涨得不均匀。指望“买得多单价就低很多”，在这一类交付里通常不成立。

更接近实际的规律是：一台设备时，成本几乎全在部署；三到五台时，成本在设备池与值守；十台以上时，成本在并发、隔离与人力。这也解释了为什么分档的边界落在这些数字附近，而不是落在“功能多少”上。

最后这一类要说得更直白：任何自动化都不能保证账号不出问题。系统能做的是守住节奏与结构规则、在平台异常时暂停、把每一步留下可核对的记录。它不能保证结果，也不能替代选品与定价。把它当工具买，期望是“少花时间、少出错”；把它当结果买，期望一定会落空。

如果以上都对上了，下一步不是直接谈价，而是先把三件事准备好：要接几个账号、有几台设备可用、每天能投入多少时间值守。这三件事定了，档位就定了，报价才有可比性。具体报价以联系沟通为准，沟通时把这三点说清，能省掉一轮来回。产品侧的整体结构可以看产品功能总览，两条通道的分工看手机 APP 自动化通道与电脑网页版通道，设备规模对成本的影响看多设备并行管理。

需要逐项核对时，把这三点连同设备型号与网络条件写成一段说明发过去，比口头描述准确；信息越具体，给出的口径越准，来回也越少。说明写得具体一点，能省掉的不止一轮来回，也能避免按错误前提报出来的口径。