定时发布，排的是槽位不是时间点

01  /  节奏定位

定时发布控制的是四个量，不是一个时间点

给每条商品挑一个发布时间，只是这件事的最后一下。前面还有三个判断没做，做了也是白做：这一天还剩多少条额度、离上一条过去了多久、这个时间点落不落在允许的时段里。四项同时成立，这条才发得出去；任何一项不成立，正确的动作是顺延，不是硬塞。系统把这四项写成发布前的闸门，默认取值是这样的。

先接受一个容易被略过的点：每日发布量的区间有下限。很多人只盯着上限，觉得少发总比多发安全，于是账号连续几天零发布，某天一次补十几条。这在本账号的时间序列上就是一个明显的突变——安静了很久，然后集中出现。节奏的判断看的是分布的形状，不是单日的总量，所以下限和上限一样是判断条件。

这四项在实现上是并联的，不是先看一项再看下一项。也就是说，不是今天先判每日上限、明天再看间隔，而是每一条候选发布都要把四项全过一遍，任何一项不过就进顺延队列。理解这一点，后面所有排期动作才有依据：排期不是把商品塞进时间轴，而是让每一条都同时满足四项。四项以外的两道关——内容本身合不合规、账号状态允不允许——分别写在商品合规检查与防封控与账号安全里，这一页只管时间。

还有一个判断点值得先想清楚：你要控制的到底是发布的数量，还是发布之后的响应。数量可以靠调参数完成，响应不行——它需要有人真的在看。如果账号目前没有人能在白天回复问询，那么把窗口定在白天、把量铺开，只会让每一条发布之后都挂着一段没人处理的时间。这时候更合理的做法是把量压到有人在线的那一段，而不是照着默认窗口硬排。

02  /  发布窗口

窗口定在 09:00 到 21:59，理由不是玄学

窗口之所以是一个固定区间，而不是全天随便挑，有三个具体理由，每一个都能被验证。第一，发布之后的一段时间里，买家会问、会砍价、会要更多图，这段时间需要有人在场。夜里发布，前几个小时的互动没人接，等于把发布的效果浪费掉，也让这个账号在平台上留下一条从不回复的记录。第二，发布动作本身涉及设备与网络，出问题时需要当天能处理。窗口定在白天，异常能当天被发现，不会拖到第二天早上才看见一堆失败。第三，固定窗口让节奏有一个可比较的基线：同样的窗口、同样的上限，两周的数据才能横向对比，否则每周的形状都不一样，改了参数也看不出效果。

21:59 这个收口不是随手写的。窗口结束之后不再起新的发布，但已经在跑的那一条要允许它跑完——所以判断的是开始时间是否落在窗口内，而不是结束时间是否落在窗口内。如果把判断写成结束时间，一条在 21:55 开始、需要四分钟的发布会被判越界，实际上它完全正常。这类边界判断写错，表现出来是每天稳定少一条，很容易被当成偶发的设备问题，查几天都查不到。

窗口还有一层作用常被忽略：它是设备与人的共同窗口。多台设备并行时，槽位要落到具体设备上，而设备可能有维护时间、可能有系统更新的静默时段。窗口不统一、设备时间不统一，台账里的时间戳就会互相错位，事后核对这条到底几点发的要翻三份记录。所有设备统一对时，流程启动前读一次设备时间写进日志，这一条在手机 APP 通道和电脑网页版通道上都要做，只是取时间的位置不同：手机端取设备时间，网页端取请求发起的时间。

窗口内怎么分段，取决于你的回复能力，不取决于所谓的活跃时段。能全天在线回复的，可以把量往午后集中；只有晚上有空的，就把主要量放在晚间段，但要把量压到那一段能排完的条数。窗口和分段都不是固定答案，固定的是判断顺序：先确定人在场的时段，再确定窗口，再按间隔下限算这一段最多能排几条，最后才填商品。顺序反了，就会出现先排商品再找时间的情况，排完发现总量超出可行窗口，只能压缩间隔。

另一个细节是周末与工作日不必相同。周末在线的时段可能更靠后，工作日更靠前，这时候可以用两份窗口配置，但每份都要固定，不要每天都变。窗口一变，上周的间隔分布就没有可比性，复盘只能看总量，看不出节奏。

03  /  间隔与抖动

30 分钟是下限，抖动改的是形状

间隔这一项最容易被两个方向理解错。一个方向是把它当成目标，每条之间精确隔 30 分钟，结果一天的发布时间戳是 09:00、09:30、10:00、10:30，整整齐齐。另一个方向是把它当成安全阈值，觉得越慢越稳，于是把间隔拉到两三个小时，结果当天排不完，条目全堆到周末。两种做法错在同一个地方：把间隔当成了目的，忘了它只是把总量摊开的工具。

固定间隔的问题在于它构成一个可见的周期。一串等距的时间戳不需要任何复杂判断就能被看出来，而这恰恰是最容易被当成机器操作的形状。所以间隔的做法是：以下限为底，在底之上加抖动。落地时按三步走。

抖动要有一个可核对的落点：台账里记录的是实际发布的时间戳，不是计划时间。这一点看着琐碎，实际决定了两件事能不能做。第一，复盘时能看到真实的间隔分布，而不是一堆整齐的计划值。第二，出现这条为什么发晚了的疑问时，能分清是槽位本身就靠后，还是执行环节拖了。计划值和实际值混在一列里，这两种情况就永远分不开。台账的字段口径见发布数据台账。

还有一个反向的坑：随机源要能固定。调试阶段用固定种子，能复现同一串槽位；正式跑用真随机。如果随机源不可固定，这批条目为什么都排在晚上这类问题就只能靠猜。判断标准是：同一份计划跑两遍，调试模式下槽位应当一致，正式模式下不应当完全一致。两个都要能验证，才说明随机是被控制的，而不是在碰运气。

间隔不该为了更稳而无限拉长，还有一个现实原因：一天只有十三小时左右的窗口，间隔每加一倍，当天能排的条数就减一半。当日量排不完，条目溢出到第二天，第二天的额度又被挤占，一周下来形成堆积。堆积之后最常见的动作是一次清空——而这正是最不该出现的形状。间隔的正确位置是刚好看不出周期，而不是尽可能慢。这个位置可以自己验：把一天的发布时间戳列出来，如果有人能一眼读出规律，说明间隔或抖动还不够。

最后提醒一点：抖动不要做成固定序列循环。每三条一轮、每轮偏移量相同的写法，跑上几十次之后仍然是可辨的节律，跟等距没有本质区别。

04  /  上限关系

三个上限同时生效，取最紧的那个

每日 5 到 10 条、单服务线每日 2 条、单账号周上限 12 条，这三个数字不是三套并列的建议，而是三个同时生效的约束，实际能发多少取最紧的那个。理解它们的相互作用，比记住数字本身更有用。

三者的关系可以这样推。如果只做一条服务线，单线每日上限是 2 条，一周按七天排满是 14 条，已经超过周上限 12 条——所以周上限先触发，实际节奏是每周 12 条，也就是每天不到 2 条，必须留出至少一天不发。如果做三条服务线，单日上限是 2 乘 3 等于 6 条，落在每日 5 到 10 条的区间里，但一周按六天算就是 36 条，离周上限 12 条差了整整三倍。这时候的正确做法不是把日量砍到 2 条，而是先把这一周的 12 条摊到七天，每天不到 2 条，再按服务线分配。

这个推演说明一件事：服务线越多，周上限越早成为瓶颈，日上限反而形同虚设。所以排期的顺序应该反过来——先定这一周的总量（由周上限决定），再摊到七天，再按服务线分配每日份额，最后才落到槽位。先排日再排周，必然在第五天撞墙，撞墙之后通常出现两种坏做法：要么直接超发，要么把剩下的全堆到周末。

• 先算周，再算日周总量除七得到日均，日均低于下限就说明这一周不该排满七天
• 同一条线不留连续两天满额单服务线每日 2 条是上限，不是每日应发量
• 溢出条目进顺延队列不丢弃、不合并、不在同一时段连发
• 顺延队列要有排序依据按临期、库存、上新优先级排，不要按进队顺序
• 周与周之间留缺口上周撞了周上限，本周开头不要立刻补满

顺延队列还有一个隐藏风险：它会让计划发布时间与实际时间的差距越拉越大。差一两天是正常排期，差一周以上就要回头看是不是每日额度给少了，或者服务线划得太细导致单线限额用不满。这个偏差是排期质量的直接指标，比今天发了几条更能说明问题。

需要说清楚的是，这三个上限是系统内置的默认闸门，不是平台公布的规则，也不是超过就一定出事的临界值。它们的作用是让节奏有确定的形状，而不是替代对账号状态的判断。账号状态该看什么信号，见防封控与账号安全。另外，上限的分母是账号，不是设备：两台设备各发五条，对这个账号来说仍然是十条，不会因为换了设备就重新计数。多设备并行时这一点尤其容易被算错，设备和账号的对应关系见多设备并行管理。

05  /  槽位排期

槽位是从计划算出来的，不是标上去的

排期最容易做错的一步，是给计划里的每一条手工标一个通道和一个时间。手工标的问题不在慢，在于不一致：同一份计划隔一天再标一次，结果不会相同；两个人各标一半，两半的规则也不相同。系统的做法是反过来的——槽位由计划、窗口、上限、间隔共同算出来，同一份发布计划跑两遍，得到的槽位分配是一致的。

这一点在两条通道并存时尤其重要。手机 APP 通道和电脑网页版通道执行的是同一份发布计划，谁在哪一条上执行、哪个槽位归谁，是同一个函数算出来的结果，不是两个地方各自标记的。原因是如果归属靠标记，就会出现两种具体故障：同一份计划在两个通道上算出不同的时间，或者同一条被两边各执行一次。用同一个函数算，是从结构上排除这种可能，而不是靠流程规范去约束操作的人。两条通道各自的执行细节分别写在手机 APP 自动化通道与电脑网页版通道里。

算出来的还有一个可验证的好处：可以离线预演。把未来一周的计划跑一遍，看每天落到几条、最小间隔是多少、有没有哪天撞上周上限，不用等到当天才发现排不下。预演结果应该和实际执行结果一致；如果不一致，说明执行环节有额外的时间消耗，这部分要被量出来，而不是被忽略。常见的时间消耗来自三处：设备启动、图片上传、提交后等待回执。哪一处占比高，就从哪一处优化，不要让这三处的不确定性吃掉整段间隔。

排到设备层之后，还会遇到一个现实约束：设备不是随时可用。一台设备正在跑上一条、正在维护、或者网络在抖，槽位就要让出去。这时候正确的处理是让槽位延后，而不是把这条换到另一台设备上立刻发——换设备会改变这条记录的执行环境，事后核对时通道与设备对不上，也分散了账号在设备侧的行为记录。

排期表本身要能被人读懂。一张表的列应该是：计划编号、服务线、计划时间、实际时间、通道、设备编号、结果、原因。少一列，复盘时就少一个能对上的锚点。这张表和台账是同一份数据的不同视图，不是两份数据；如果它们对不上，先修口径，不要两处一起改。

06  /  到点闸门

到点那一刻，还要再走一遍闸门

排期只是把条目安排到时间上，它不保证到点的时候这条还该发。从排期到实际执行之间可能隔几个小时甚至几天，这期间商品信息可能被改过、类目可能被调过、图片可能被换过、平台侧的状态也可能变了。所以到点发布之前，要用当下的基线把合规闸门重跑一遍，不通过就不发。这个判断是 fail-closed 的：默认拦住，只有明确通过才放行。

为什么不能只在排期时检一次？因为排期时的检查结果属于当时成立。把当时成立的结论用到几小时之后，中间任何一处变化都会让结论失效，而失效不会自己报错——它会安静地让一条不合规的商品发出去。复检的成本很低，漏检的代价很高，所以默认做法是每次发布前都重跑，而不是按天检一次。

第二道是平台健康闸。平台侧出现异常时暂停发布，不硬发。这一条的价值在于把发不出去和发出去了但状态不对区分开：前者是失败，可以重试；后者更麻烦，因为它会污染台账，也会在平台上留下一次异常记录。判断顺序应该是先看健康闸，再看闸门复检结果，最后看设备可用性。顺序反了会出现闸门过了、设备也空着、于是发了的情况，而平台那会儿恰好不正常。

暂停之后怎么恢复，是这套机制里最需要写清的一段。默认不自动重试，因为自动重试会在异常期间反复提交，反而放大问题。正确做法是：暂停时记录暂停原因与时间，把受影响的槽位标成未执行，等健康状态恢复后由人确认复位，再决定这些槽位是顺延还是放弃。顺延的条目要重新走一遍槽位计算，不要直接把原时间加个偏移就发——那样很容易撞上第二天的额度或最小间隔。

还有一种情况要提前想好：健康闸在窗口快结束时才恢复。这时候剩下的时间可能只够发一两条，其余必须顺延到次日。不要因为今天额度没发满就压缩间隔硬塞。每日量的下限是长期节奏的判断条件，不是当天必须凑齐的指标；这一点和第一节讲的四个量是一致的，任何一项不成立，顺延就是正确动作。

07  /  计划对账

计划与实际：三种差异要落到原因

排期做得再好，计划和实际也不会完全一致。差异是正常的，不正常的是不知道差异从哪来。把差异分成三类，每一类有固定的原因归属，核对才有意义。

这三类的处理方式完全不同。跳过要回看闸门结果，看是哪一条规则挡住的，然后决定改文案还是改类目；失败要看执行日志，定位是设备问题还是界面变化；顺延要检查排期本身，看是不是额度给少了。如果三类混在一起统计成未按计划发布，每周都会看到十几个数字，但一个都修不了。

对账的锚点应该是槽位，不是条目。同一个条目可能这一周跳过、下一周顺延、第三周才发出去，按条目对账会把三次都算进同一条记录里，看起来一直是没发，实际上已经发了。按槽位对账，每个槽位只有四种终态：成功、失败、跳过、取消，加起来等于当日槽位数。这个等式成立，说明账是平的；不成立，说明有槽位丢了状态，先修记录再谈指标。

台账里每条成功发布都带 item_id 和实际时间戳，这是能对上账的最小集合。有 item_id 才能证明这条商品确实在平台上存在，有时间戳才能和槽位对齐。缺任何一项，这条记录只能当疑似成功，不能进统计。字段口径和 item_id 回读的做法见发布数据台账。

对账的频率建议跟排期同步，一周一次，不要每天看。每天看会看到大量瞬时差异——今天的槽位还没跑完——反而分不清是真问题还是进度。一周一次，看的是三件事：槽位成功率、三类差异的比例、顺延队列的深度。这三项里任意一项连续两周恶化，才值得动排期参数。单项指标波动一次就改参数，是所有排期里最常见的坏习惯：改完这一周，下一周的基线又没了，等于每周都在重新开始。

最后要留一份可回查的记录：这一周的参数是什么、改过哪里、改之前的数字是多少。参数自己会说话，但只有和改之前的数字放在一起才有意义。没有这一行记录的调参，本质上是在赌，而赌赢了也复现不了。

08  /  落地清单

几个常见误区，和上线前的核对项

排期这件事的误区集中在把约束当成建议这一类。下面五条是反复出现的。

上线前把下面这几项逐条过一遍，比事后翻日志省事得多。

• 窗口已确定开始时间落在窗口内才判通过，结束时间不参与判断
• 最小间隔与抖动分开配置两项合成一个开关，出问题时分不清是哪一项调过头
• 周上限先算周总量摊到七天，再看每日是否落在 5 到 10 条区间
• 单服务线限额独立计数按服务线分别算，不是全账号共用一个计数器
• 槽位可离线预演未来一周跑一遍，看有没有撞上限或间隔过近
• 随机源可固定调试模式能复现同一串槽位，正式模式不复现
• 到点复检默认拦截不通过即不发，不做先发后改
• 健康闸暂停不自动重试记录原因与时间，人工复位后再排
• 台账分列计划值与实际值两个值不要混成一列
• 参数变更留记录改了什么、改前数字是多少，写进当周复盘

还有一项不在这十条里，但每次上线都值得单独确认：窗口、间隔、上限这些参数，改的时候一次只动一项。三项一起改，观察到的变化归不到任何一项身上，下一周还得重来。改完至少让一批完整的发布走完再看结论，几条就改一次参数，看到的永远是自己制造的噪声。

把这十项做完，排期就从给每条挑个时间变成了一套可以被检查的规则。剩下的判断——发什么、怎么写才合规、账号状态是否允许——分别属于选品、合规与风控，见智能选品与商品合规检查。四个模块之间的关系在产品功能总览里有一张总览，判断自己该从哪一块先动，可以对着那张图看。