我在检查一次内容发布排期时，先看到列表最上面那条记录，页面显示的时间是10-29 08:00。它排在第1条，看起来很像“接下来最晚的一条”，于是我差点把它当成窗口校验的依据。
但再往后看，列表里其实还有一条11-09 17:30的记录。它没有因为时间更晚而排到最前面。真正把我拦住的不是页面显示异常，而是我默认了一个没有被页面承诺过的关系：列表顺序等于排期顺序。
这次事情表面上是网页列表看错了，实际上是在处理3种不同的顺序。平台按最近操作来排，业务要按排期时间来排，内容还要按它归属的人物和发布事实来判断。它们恰好都出现在同一个页面里，却不能共用一个“第一条”来代替。
第一条为什么看起来那么可信
列表第一条很容易获得额外的可信度。它位置最醒目，通常也是页面刚打开时最先能读到的记录。人在赶进度时，会自然把“最新看到的记录”理解成“时间上最新的记录”。如果页面字段又同时展示了操作时间、计划时间和内容摘要，这种误判就更难被察觉。
这次的问题在于，平台定时列表按最近操作先后排序，不按排期时间排序。旧内容只要被重新操作过，就可能被顶到前面；一条从未被重新触碰、但排期更晚的内容，反而会藏在后面。页面没有骗我，是我把展示规则误读成了业务规则。
页面的第一条只能说明它在当前展示规则下排在最前面，不能自动说明它是业务时间上的最新记录。
如果不处理这个区别，后面的错误不会只停留在一次人工查看。系统可能用10-29 08:00去判断11-09 17:30是否超出窗口，也可能因为误以为窗口还有空间而继续提交任务。等网页自动化真正开始运行时，时间判断已经晚了；失败可能表现成页面操作异常，根因却藏在最初的排序假设里。
表面问题是排序，真实问题是语义混在一起
刚开始我以为只需要把列表重新排序，或者直接取列表最后一条。后来发现，这两个做法都不够稳。列表的原始顺序仍然有用：它代表平台当前如何展示和组织记录，排查页面行为时需要保留它。真正缺少的是另一个独立的时间视图，而不是把原视图粗暴替换掉。
这里最容易误判的是，“最晚排期”与“最近操作”都可以被人说成“最新”。前者回答的是业务问题：已经排到哪个日期；后者回答的是页面问题：最近动过哪条。两个词在口语里很接近，在校验里却必须分开。如果两个含义共用一个字段，后续所有判断都会被一个看似合理的排序带偏。
所以我选择同时保留平台原始顺序和按时间排序的数据，是因为这能让两种事实各自承担自己的职责。原始顺序用于还原页面，时间排序用于计算窗口；它们并列存在，才不会为了得到一个方便的结果而丢掉排查线索。
这件事让我重新意识到，很多自动化错误并不是计算公式错了，而是输入字段在进入公式前已经换了含义。只要把“页面怎么排”当成“业务应该怎么排”，后面的最大值、最小值和窗口天数算得再准确，也是在准确地回答另一个问题。
先把排期时间算清楚
修复时，我把排期时间单独整理成时间字段，并明确计算最早排期和最晚排期。最晚排期用于判断当前内容会不会把窗口推得太远，最早排期则帮助确认已有任务从哪里开始。平台的展示顺序不再参与这两个值的计算。
这个拆分看起来很朴素，却改变了检查顺序。以前是先看列表第一条，再猜窗口；现在是先收集全部排期，再按时间求边界，最后才决定是否允许启动网页自动化。真正可靠的排期校验，不是找到一条“看起来最新”的记录，而是从完整时间集合中计算业务边界。
窗口也不能只用日期的粗略差值。这里按当天结束时间计算30天窗口，意味着边界判断必须保留时分，而不是把11-09简单压缩成一个日期编号。这样做的理由是，排期在同1天内仍然有先后；如果只比较日期，晚上的任务可能被错误地当成当天早上的任务。
超出30天窗口的任务，要在启动网页自动化前拒绝。这个位置很重要。若等到浏览器已经打开、页面已经填写，甚至已经触发提交后才发现超窗，系统就可能留下半完成状态，人工也要重新判断到底有没有创建成功。如果在入口处拒绝，失败是明确的，原有排期也不会被无意改动。
查重不能再靠全文包含
排期顺序的问题还牵出了另一个相似的偷懒：人物查重时，直接判断全文是否包含某个人名。这个规则写起来很短，却把“出现了相同文字”和“发布的是同一个人物”混成了一件事。
全文包含会误拦一些并非同人物的情况。历史人物名可能出现在比较、引用或组合词中，文本里出现某个字面片段，并不等于当前内容归属于这个人物。之前被误拦的样例就说明了这一点：看似命中了名字，实际上并不是同一发布对象。
我没有直接把模糊匹配改成更复杂的模糊匹配，是因为问题不在于匹配不够聪明，而在于查重缺少更可靠的事实来源。成功发布后已经形成的人物标签，比标题或正文里的偶然提及更接近“这条内容到底属于谁”。因此，查重优先比较已成功记录的人物标签；只有缺少标签时，才使用有边界的独立词匹配作为保守兜底。
查重应该优先比较成功事实留下的归属标签，文本匹配只能在事实缺失时承担有限的兜底职责。
这样处理后，原先误拦的历史人物样例可以放行，而真正属于同一人物的内容仍然保持拦截。这个结果并不是放松规则，而是把规则从“看到文字就拦”改成“先判断归属，再处理文字”。兜底规则也必须有边界，不能为了少漏一个而重新回到全文包含。
3种顺序要有3个位置
回头看，这次修复可以归结为3个独立字段。第1个是展示顺序，保留平台原始列表位置，用来理解页面和追查最近操作；第2个是业务时间顺序，保存按排期排序的数据，用来求最早、最晚和窗口边界；第3个是内容归属顺序，用成功发布后形成的人物标签表达“这条内容属于谁”。
这3个字段不一定要出现在同一个页面上，但必须在系统内部分开。展示顺序不能替代时间顺序，时间顺序也不能替代人物归属。把不同问题拆成不同字段，往往比给一个混合字段增加更多判断分支更安全。
我会把流程写成一条固定规则：先读取并保留平台原始记录；再提取所有有效排期，按时间计算最早值和最晚值；用当天结束时间检查30天窗口；超窗就在网页自动化前拒绝；成功发布后记录排期和人物标签；查重先比标签，缺标签时才做有边界的词匹配。
这条流程的价值不只是解决这一次的11-09 17:30。以后平台改变默认排序、增加新的操作按钮，甚至换成另一个列表页面，只要展示顺序仍然和业务时间分开，窗口判断就不会跟着页面位置一起漂移。若新来源没有人物标签，兜底也有清晰边界，不必临时发明一个更宽的全文搜索。
下次我会怎么做
下次遇到任何“列表里哪条是最新”的问题，我会先问“最新”指什么：最近操作、最晚计划，还是最近成功发布？如果答案不同，我就不会让它们共享一个字段，也不会用列表位置直接代替业务计算。
排期方面，我会先拿到完整时间集合，保留时分，计算最早和最晚，再按当天结束时间检查30天窗口。窗口检查会放在网页自动化之前，并明确记录拒绝原因。这样即使页面顺序变化，系统也能在真正产生外部操作前停住。
查重方面，我会先看成功事实有没有留下归属标签。标签存在时按标签比较；标签缺失时才启用独立词边界规则，并把它当成保守兜底而不是主判断。遇到误拦样例，我会检查它是否真的属于同一人物，而不是只看页面上有没有相同字面。
这件事让我重新意识到，一个流程成熟的标志，不是它能在某个页面上跑通一次，而是页面的偶然顺序变化后，业务判断仍然有自己的依据。真正难的不是把列表读出来，而是承认列表只是展示，把时间边界和内容归属重新交还给各自应该负责的字段。