TikTok 发完之后，怎么确认哪几条真的发出去了？

有个做跨境服装的人，跟我说他做过一次统计。

他在记录表上看到二十七条发布任务，状态全是成功。他随手点开几个账号看，发现有八个账号上什么都没有。

从那天起，他每次发完都会自己再数一遍。他说数一遍花十分钟，但能避免整天的产出变成零。

一个「发出去了」的误会

问题出在“成功”这个词被用得太宽。

发一条 TikTok，中间至少有三步。第一步是动作执行完，也就是脚本点完了发布按钮、填完了文案。第二步是内容传完，文件真的到了平台那一侧。第三步是审核通过，内容对外可见。

脚本只能确认第一步。它点完了按钮，返回一个“执行完毕”。后面两步发生在平台那边，本地的记录看不到。

所以“记录显示成功”和“用户能刷到这条”之间，隔着两道。

三种不一样的失败

分清楚这三种，排查会快很多。它们的表现不一样，原因也不一样。

第一种是根本没触发。到点了什么都没发生，手机上还是原来的画面。这类多半是设备状态的问题，比如那台手机掉线了、或者当前不在自动化服务里。

第二种是跑到一半停住。文案填了一部分、上传进度卡在中间。这类通常是网络波动，也可能素材体积太大，传不过去。

第三种是传完了但没公开。动作全部走完、进度也到百分之百，但内容不在主页上。这类是平台那一侧的事，可能是审核没过，也可能是素材本身不符合规范。

三种的补法完全不同。第一种要回去查那台设备，第二种换时间重传，第三种得先看平台上给了什么提示，再决定改素材还是重发。

从执行记录里定位

不用挨个点开手机看。执行记录里每一步都有结果。

跑完一批之后，先看这一批的日志，找到所有不是“完成”的条目。记录会写明是哪一台、卡在哪一步、报的什么。三十台里坏两台，两分钟就能找出来。

如果记录显示全部完成，但你在平台上找不到内容，那就属于第三种。这时候要看手机上的实际画面。几十台投到电脑上并排看，哪台主页是空的、哪台的草稿箱里躺着一条，一眼就能看出来。

补发不要整批重跑

这一条最容易犯。

发现有几台失败，直觉反应是把整个任务再跑一遍。结果是没失败的那二十几台又发了一次，账号上出现两条几乎一样的内容。

正确做法是先看一下失败清单，只对这几台重新执行。任务重新下发的时候，设备范围按失败的清单来选，不要偷懒选全部分组。

如果用的是定时任务，也可以给失败的那几台单独建一个小任务，跑完就删掉，不要留着。

每天固定的核对动作

把它做成一个固定动作，就不会漏。

每天收工前花十分钟看三件事。第一件，今天计划发多少条。第二件，记录里显示成功多少条。第三件，随机点开三五个账号，确认主页上真的有内容。

前两件对着记录看，第三件是抽样验证。抽样不用多，三五个就够，因为如果记录和实际不符，通常是整批性的问题，抽样能发现。

发现对不上，当天补掉。拖到第二天，你连是哪一批出的问题都要重新查。

一张可以照做的核对表

把上面这些动作收成一张表，贴在工位上，新来的人也能照着做。

发之前看三行。素材是不是最新的一版、设备是不是都在线、今天的任务是不是都建好了。

发之后看三行。任务有没有按预定的时间启动、成功和失败各多少条、随机抽三个账号确认内容真的在主页上。

出问题之后看三行。失败的是哪几台、记录里卡在哪一步、补发的范围只圈这几台。

每周再看一次。这一周的失败率是多少、有没有某一台设备反复出问题。反复出问题的设备不用等它坏，提前换掉比临时救火便宜。

这张表的价值在于它把“记得去看一眼”变成了固定动作。绝大多数漏发不是因为技术做不到，是因为当天事情多，收工时忘了对一遍。

和写脚本比，这条路差在哪

发布这个环节，脚本是很好用的工具。固定的动作它做得又快又稳，一次写好长期用。发布量大、流程半年不变的团队，投入一次脚本是划算的。

脚本的短处出在排查上。失败原因往往是临场的，比如某个素材格式不对、某台设备状态异常。写死的脚本遇到这类情况只会报一个笼统的错误，你得回去读日志、翻代码，才知道它卡在哪。

用 AI 操作手机是按描述执行。排查的时候你可以直接问它“刚才那台手机上传到哪一步了”，它会看着屏幕给你答案，不用你翻译日志。

还有个差别在改动成本。发布流程要微调，比如文案里的位置换一下、话题标签多加一个，脚本要改代码，描述式的只要把那段话重说一遍。

比较实际的判断是这样：发布这类每天重复、逻辑固定的活，脚本更省人力。核对、补发、异常排查这类需要临场判断的活，描述式的方式更省心。两条路可以放在同一批设备上用，不用二选一。

最后

那个做服装的人现在有一套固定动作。发完不看手机，先看记录；记录对不上再看屏幕；找到失败的几台单独补。

他说这套东西说出来很朴素，但它把“以为发出去了”这个坑填掉了。

发布这件事真正的成本不在于发，在于发现不了没发出去的那几条。记录下来，数一遍，事情就有头有尾了。