很多人第一次做内容自动化，最容易盯着“每天能生成几篇”。定时器一开，热点、标题、正文、配图都能按时出现，看上去终于摆脱了重复劳动。可运行几天后，麻烦往往才真正开始：同一条新闻被写了两遍，图片生成失败却照样进入发布队列，文章发出去了但后台仍显示待发布，第二天的任务又把昨天的半成品接着跑了一次。

问题并不是模型不会写，而是整条链路只有“执行”，没有“记账”。

真正省心的内容流水线，不该只是把提示词塞进定时任务。它更像一个小型生产系统：每份素材走到哪里、为什么停下、能不能重试、谁改过、最后发到什么地址，都应该说得清楚。否则产量越高，人工收拾残局的时间反而越长。

定时运行不等于工作流稳定

一条常见链路大概是这样：抓取新闻，筛选选题，核对来源，生成文章和配图，经过审核，再提交到平台。把它设置成每天早上运行并不难，难的是其中任何一步都可能只完成一半。

比如资料抓到了，来源却只有二手转载；正文写完了，配图接口超时；平台已经收稿，返回结果时网络中断；审核人员改了标题，系统却仍拿旧标题发布。若任务只认识“成功”和“失败”，这些中间状态就会全部混在一起。

更稳妥的做法，是先给每篇内容一个不会重复的任务标识，再把状态拆清楚。状态名称不用复杂，能回答当前发生了什么就行：collected表示素材已收集，verified表示来源已核验，drafted表示正文已生成，reviewed表示人工检查通过，published表示平台返回了可访问地址，failed则必须同时记录失败步骤和原因。

状态一旦落到存储里，任务中断后就不用从头再来。系统可以从最后一个有效节点继续，也能避免把已经发布的内容再次提交。

先解决重复，再谈全自动

内容自动化里最烦人的事故，通常不是少发一篇，而是重复发一篇。新闻标题每天都可能变化，只用标题去重并不可靠。比较实用的办法，是拿“规范化后的来源地址 + 主题关键词 + 日期窗口”生成幂等键。

下面是一段简化后的 Python 思路：

import hashlib from urllib.parse import urlsplit, urlunsplit def normalize_url(url: str) -> str: parts = urlsplit(url) return urlunsplit((parts.scheme, parts.netloc, parts.path.rstrip('/'), '', '')) def content_key(source_url: str, topic: str, day: str) -> str: raw = f"{normalize_url(source_url)}|{topic.strip().lower()}|{day}" return hashlib.sha256(raw.encode('utf-8')).hexdigest() def should_publish(store, key: str) -> bool: item = store.get(key) return item is None or item['status'] not in {'publishing', 'published'}

这里真正重要的不是哈希算法，而是提交发布前先查一次状态，并把“正在发布”也视为不可重复提交。因为平台收稿成功、客户端没收到响应的情况并不少见。如果网络一超时就立刻重试，很可能得到两篇一模一样的文章。

遇到这种模糊结果，应该先用平台返回的任务号、文章 ID 或标题与时间窗口做回查。只有确定平台没有收稿，才再次提交。

重试要挑对象，不能见错就重跑

图片接口超时、临时网络波动、平台限流，这些错误通常可以稍后重试；来源失效、账号权限不足、正文触发规则校验，则不适合机械重试。后者连续跑十次，结果大概率还是失败，还可能把账号推到更严格的风控里。

所以失败记录里至少要保留这些信息：失败发生在哪一步、原始错误、已经尝试多少次、下次运行时间，以及是否需要人工介入。对临时故障使用递增等待时间，对确定性错误直接停下来，比“失败后每分钟重跑”可靠得多。

发布也不应该是一个黑盒动作。系统最好保存平台名称、提交时间、返回的文章 ID、最终链接和内容版本。以后发现标题或正文不对，才能判断是生成阶段出了问题，还是发布时拿错了版本。

人工审核不是自动化的反面

不少流程一上来就追求无人值守，结果把最需要判断的环节也删掉了。实际上，自动化最适合接手的是查找、整理、格式转换、配图生成和状态同步；是否值得发、事实是否站得住、表达是否适合当前平台，仍然需要一道质量门。

审核也不必变成逐字重写。可以把注意力集中在来源、日期、关键数字、标题承诺、图片文字和平台规范上。通过后只改变一次状态，后面的发布任务只消费reviewed内容。这样创作和发布互不抢数据，临时改稿也不会把半成品送出去。

如果确实需要自动发布，建议先从风险较低、接口行为清晰的平台开始，并设置单日上限、异常熔断和回滚记录。连续出现来源为空、图片失败或发布被拒时，整条任务应暂停，而不是继续制造更多待处理结果。

每天真正该看的不是产量

一套内容流水线是否健康，不能只看生成了多少篇。更值得关注的是核验通过率、审核退回率、从选题到发布的耗时、重复拦截次数、各步骤失败率，以及发布后链接回填是否完整。

这些数据很朴素，却能很快指出瓶颈。审核退回率突然升高，可能是提示词或来源池发生了变化；配图失败集中在某个时段，可能是接口限流；发布成功但链接缺失，说明回查机制还不完整。比起继续增加模型和平台，先把这些信号看清楚，往往更能节省时间。

内容自动化的目标，从来不该是让机器每天准点制造更多文件，而是让人少做重复动作，同时仍然知道每篇内容从哪里来、经历了什么、最后去了哪里。

先把一条流程跑稳：素材有出处，任务能去重，中断可恢复，发布可回查，异常会停下。等这些基础环节都可靠了，再扩展更多平台和更高频率，才不会把自动化变成一台需要全天照看的机器。

参考链接

https://platform.acedata.cloud/blog/automate-daily-content-workflow?lang=zh-cn&inviter_id=484695ca-9aeb-43eb-93c9-cc4a9a94e363