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

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

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

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

一个「发出去了」的误会，三种不一样的失败

「成功」这个词用得太宽。

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

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

记录显示成功，和用户能刷到这条，中间还隔着上传和审核。

三种失败，表现不一样，原因也不一样。

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

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

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

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

从执行记录里定位，补发不要整批重跑

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

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

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

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

只对失败的那几台重新执行。任务重新下发的时候，设备范围按失败的清单来选，不要选全部分组。

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

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

前两件对着记录看。第三件是抽样。抽样三五个就够。记录和实际不符，通常是整批性的问题，抽几台就能发现。

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

一张可以照做的核对表，和写脚本差在哪

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

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

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

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

这张表把「记得去看一眼」变成固定动作。绝大多数漏发，是当天事情多，收工时忘了对一遍。

发布这个环节，脚本又快又稳，一次写好长期用。发布量大、流程半年不变的团队，投入一次脚本是划算的。

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

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

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

每天重复、逻辑固定的发布，脚本更省人力。核对、补发、异常排查这些要临场判断的，描述式的方式更省事。两条路可以放在同一批设备上用。

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

他说这套东西说出来很朴素，但它把「以为发出去了」这个坑填掉了。没发出去的那几条，靠记录和再数一遍才能发现。