账号弄错以后，才看见真正的问题
这次批量处理口播视频时，我先收到一个很具体的纠正：任务理解错了，视频应该发到另一个目标账号，而不是当前默认账号。等我回头核对，错误的发布任务已经在错误账号上排起了队。事情的第一反应当然是停掉任务、删除错误排期，再确认正确账号是否可用。但越往后查，我越觉得这不只是一次“记错账号”。
后面还接连出现了几个看似分散的问题：同一个平台堆了多个重复列表页，页面没有被复用；平台提示操作过于频繁，原本的加载失败被误以为是页面故障；测试发布时，内容又被默认加上了不合适的标签；追问或终止后台任务后，回复文字还出现重复。表面上，这是几处执行细节出了错，实际上，它们都在说明同一件事：发布目标没有被当成一个完整的路由来管理。
多平台发布最先要锁定的不是“发什么”，而是“以谁的身份、从哪个入口、带着什么状态发出去”。
自然语言里的账号名不够可靠
最容易误判的地方，是以为把账号名写进任务描述，就已经完成了目标确认。人在读这句话时，通常会自动补上上下文：这是哪个平台、哪一个浏览器实例、对应哪个内容批次。执行系统却未必能补对，尤其当当前页面刚好还停留在另一个账号时，操作很容易沿着默认入口继续下去。
这次错误正是这样暴露出来的。任务名称指向的是一批视频，真正重要的账号身份却没有成为不可跳过的前置条件。结果不是视频内容错了，而是内容被送到了错误的归属地。错误一旦进入排期，后续就不只是撤回一条内容，还要暂停补排、检查已经写入的状态，再重新建立正确通道。
如果不处理这个缺口，后果会越来越难收拾：同一批内容可能在错误账号留下发布记录，正确账号又继续重复提交；排查时还会把“没发成功”和“发到了别处”混在一起。前者可以重试，后者却需要先止损。它们在表面上都像失败，恢复动作完全不同。
我选择把账号身份从自然语言中拆出来，是因为它应该参与发送前的判断，而不是只作为给人看的备注。一个可执行的目标，至少要明确身份键、平台入口、内容批次和当前状态。账号显示名可以帮助人阅读，稳定的账号键才适合用来守卫操作。
3 层路由把目标拆开
我后来把发布目标分成3层。第一层是身份：这条内容属于哪个账号，使用哪个稳定账号键。第二层是平台：要走视频号、小红书还是抖音，以及对应的正式入口和浏览器实例。第三层是标签：这次内容是否需要某种平台标记，哪些默认标签必须关闭，发布后又要回读什么状态。
这3层不能互相代替。账号对了，不代表平台入口对了；平台对了，也不代表标签符合内容事实。比如这次测试发布确实落到了目标账号，但系统默认加上了“含AI生成”标注，而实际内容是真人口播。若只看到账号正确就继续批量执行，错误标签会跟着整批内容扩散。
身份、平台、标签是3个不同的判断层，任何一层没有核对，都不能把“目标正确”当成已经成立。
我判断这样拆分是必要的，因为它把原来一句模糊的“发到某账号”，变成了几个可以分别验证的事实。身份守卫回答“有没有发错归属”；平台守卫回答“有没有走错入口或复用了错误页面”；标签守卫回答“发布内容的声明是否与事实一致”。出现问题时，也能知道应该停在哪一层，而不是把所有异常都归结为平台不稳定。
发送前先过账户守卫
真正的路由不是写在任务开头就结束，而要在每次发送前重新检查。第一步是读取当前页面或会话所对应的账号身份，把它和任务里的账号键比较；不一致就停止，不允许自动回落到默认账号。第二步是检查平台入口，确认当前页面属于目标平台，优先复用已经存在的正式页面，关闭同类重复页面，避免多个列表页互相遮蔽状态。
第三步才是检查内容批次和标签。当前内容是否已经提交过，是否处于排队、成功、失败或冷却状态，都应该先读回来。标签不能只用平台默认值，应该由任务明确声明：需要的保留，不需要的关闭，无法确认时停下来。这里的“停”不是降低效率，而是把不可逆的错误挡在发送之前。
这次处理里，目标账号的守卫通过后，才尝试发第一条测试内容；发现默认标签不适合，又先停下修改，再考虑后续批量。这个顺序很重要。若一开始就把所有内容推过去，后面即使能批量编辑，也会把“发布成功”与“发布正确”混为一谈。
限流和重复页面也是路由状态
平台出现“操作过于频繁”时，最容易走的错误捷径是反复刷新，或者换一个看起来相似的页面继续点。这样做可能暂时看到新内容，却会让平台继续把请求识别为高频操作，也让执行者失去对当前状态的判断。
我没有把它当成一次普通加载失败，是因为错误提示本身已经说明了原因。正确做法应该是把限流记录成路由状态，让当前目标进入冷却队列；冷却期间不重复提交，不新开同类页面，不把“暂时读不到”当作“还没有发送”。等冷却结束，再从正式入口读取状态，确认上一次动作究竟落在什么结果上。
重复标签页也应该进入同一套规则。页面越多，不代表通道越多，反而可能让不同页面各自维护一份过期列表。复用已有页面、每条任务完成后关闭重复页面，目的不是整理桌面，而是确保下一次读回的是同一条状态链。
一个可靠的发布流程，不是遇到阻塞就继续尝试，而是能把限流、重复页面和冷却时间都记录成可判断的状态。
发送后必须回读并去重
发送按钮被点击，只能证明发起了动作，不能证明内容已经到达正确位置。发送后至少要回读账号、平台、标签和平台返回的状态；如果返回失败或暂时不可读，就保留处理中状态，不立刻重试。等状态明确后，再决定是修正、等待还是补发。
这里还需要一个幂等键，把账号键、平台、内容批次和目标内容组合起来。相同幂等键再次出现时，系统先查已有记录：已经成功就跳过，正在冷却就等待，失败且允许重试才重新发送。这样即使后台任务被追问、终止或重新派发，也不会把同一条内容当成新任务。
追问导致文字重复的现象，也提醒我不能只在发布脚本里做幂等。任务本身需要区分“原任务仍在执行”“用户在询问状态”和“用户要求重新提交”这3种意图。追问应该读取原状态并返回结果，不能顺手再次创建发布动作；终止之后如果要恢复，也要沿用原幂等键，而不是生成一条看起来全新的指令。
我更愿意把这看成发布系统的基本记忆能力。没有回读，执行者只能依赖自己记得刚才点过什么；没有幂等，系统就无法判断重复请求是不是同一件事。工具真正改变的不是点击速度，而是能不能把一次动作留下可验证的身份和结果。
下次我会怎么做
下次遇到同一批内容要同步到多个平台，我会先建立一张最小路由记录：身份键、平台入口、内容批次、标签策略、当前状态和幂等键。任务开始前先做账户守卫，确认页面没有错；进入发送阶段后复用正式页面，遇到重复页面就收敛；平台提示限流，就进入冷却，不用刷新掩盖状态。
我会先发一条测试内容，并在发送后回读账号、平台和标签。只有这3层都正确，才把同一条路由扩展到后续内容。每次扩展前检查批次是否已有成功记录，追问只读状态，终止后的恢复也不能绕过原有幂等键。
这件事让我重新意识到，批量发布的风险不在于动作太多，而在于每个动作都可能悄悄带着错误的身份继续运行。一个流程成熟的标志，不是它能顺利发布一次，而是下次遇到多账号、多平台和限流时，仍然不依赖临场记忆。
我最终要保留的不是一串操作提醒，而是一条能被核对的路由：先确认是谁，再确认从哪里发，接着确认带什么标签，最后回读结果并拒绝重复。这样即使平台状态变化，系统也知道该等待、该停止，还是该继续。