很多人第一次做内容自动化最容易盯着“每天能生成几篇”。定时器一开热点、标题、正文、配图都能按时出现看上去终于摆脱了重复劳动。可运行几天后麻烦往往才真正开始同一条新闻被写了两遍图片生成失败却照样进入发布队列文章发出去了但后台仍显示待发布第二天的任务又把昨天的半成品接着跑了一次。问题并不是模型不会写而是整条链路只有“执行”没有“记账”。真正省心的内容流水线不该只是把提示词塞进定时任务。它更像一个小型生产系统每份素材走到哪里、为什么停下、能不能重试、谁改过、最后发到什么地址都应该说得清楚。否则产量越高人工收拾残局的时间反而越长。定时运行不等于工作流稳定一条常见链路大概是这样抓取新闻筛选选题核对来源生成文章和配图经过审核再提交到平台。把它设置成每天早上运行并不难难的是其中任何一步都可能只完成一半。比如资料抓到了来源却只有二手转载正文写完了配图接口超时平台已经收稿返回结果时网络中断审核人员改了标题系统却仍拿旧标题发布。若任务只认识“成功”和“失败”这些中间状态就会全部混在一起。更稳妥的做法是先给每篇内容一个不会重复的任务标识再把状态拆清楚。状态名称不用复杂能回答当前发生了什么就行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?langzh-cninviter_id484695ca-9aeb-43eb-93c9-cc4a9a94e363