如何设计一个可靠的 AI 定时任务：检查、执行、验证、复盘

如果说「万象片场」正在搭建一套 AI 内容生产线，那么定时任务就是这条生产线的节拍器。它每天在固定时间启动，读取计划，检查已有内容，写文章，预览，构建，部署，再把结果同步到 GitHub。

但越是自动化，越不能只追求“到点就跑”。一个不可靠的定时任务，可能只是把错误稳定地重复一遍：标题重复、文件写错、部署失败、线上页面没更新、甚至把本该人工确认的动作直接发布出去。

所以我现在更关心的问题不是“AI 能不能自动做”，而是：如何把一个 AI 定时任务设计成可靠的数字员工？ 我的答案可以压缩成四个步骤：检查、执行、验证、复盘。

一、定时任务最怕的不是失败，而是无声失败

很多自动化系统一开始看起来很顺利，因为它们只做了“执行”这一层：时间到了，运行脚本；脚本结束，任务完成。

问题是，真实生产环境里的失败往往不是直接报错，而是无声发生：

• 计划文件没有读到最新版本，但任务继续写了旧主题；
• 已有文章没有检查完整，导致重复标题；
• Markdown frontmatter 格式不对，本地看似写完，构建才失败；
• 图片 URL 失效，页面有标题但封面空白；
• 部署命令成功返回，但线上还被缓存旧页面；
• Git 提交混入了不相关文件，后面很难追踪。

这些问题的共同点是：如果没有检查点，任务会以“成功”的姿态把错误带到下一步。

因此，可靠定时任务的第一原则是：不要把命令执行完等同于任务完成。 真正的完成，应该包括结果被验证，异常被记录，下一次任务能接着理解上下文。

二、第一步：检查，先确认自己该不该做

一个 AI 定时任务启动后，最先做的不是写内容，而是确认当前状态。

以万象片场的博客自动发布为例，早间槽的任务需要先检查三件事：

1. 内容计划文件是否存在，今天的槽位方向是什么；
2. src/content/posts/ 下已经有哪些文章，哪些标题已经发布；
3. 当前 Git 工作区是否干净，避免把别人的改动覆盖或混入。

这一步看似慢，但它决定了后面是否可控。一个没有检查阶段的 Agent，很容易凭记忆或默认模板行动；一个有检查阶段的 Agent，则更像一个认真上班的编辑：先看排期，再看库存，再决定今天发什么。

我会把检查阶段设计成明确问题：

• 这个主题是否已经发布过？
• 这个文件名是否和主题匹配？
• 今天的文章是否符合当前槽位？
• 是否触碰了不该操作的项目路径？
• 是否存在未处理的 Git 变更？

只有这些问题有答案，任务才进入执行阶段。

三、第二步：执行，把动作拆成可回滚的小步骤

执行阶段也不应该是一整块黑盒。可靠的做法是把任务拆成小步骤，每一步都留下可观察结果。

博客发布可以拆成：

选择主题
  ↓
生成 Markdown 文件
  ↓
本地预览
  ↓
检查首页、归档页、文章页
  ↓
检查图片加载
  ↓
运行构建
  ↓
部署 Cloudflare Pages
  ↓
线上验证
  ↓
Git 提交推送

这样拆分有两个好处。

第一，任何一步失败，都能停在明确位置。比如构建失败，就不部署；线上验证不通过，就不应该宣称发布完成。

第二，每一步都可以单独改进。今天发现图片检查不够细，就增强图片检查；明天发现同日文章排序不稳定，就调整日期精度或排序逻辑。自动化不是一次性写死，而是不断迭代的生产线。

在万象片场的工作流里，我尤其重视“写文件”和“部署”之间的隔离。文章写完以后，必须先经过本地预览和构建。这样可以避免把格式错误、空图片、错链接直接推到线上。

四、第三步：验证，不只看终端，还要看用户看到什么

很多自动化任务的验证只停留在命令行：npm run build 通过，npm run deploy 成功，就认为结束。

但对内容资产来说，用户看到的页面才是最终结果。

所以一个可靠的博客发布任务至少应该验证：

• 首页是否能看到新文章；
• 归档页或列表页排序是否正常；
• 文章页标题、导语、正文是否完整；
• hero 图片是否加载成功；
• 线上 URL 是否打开的是新内容，而不是旧缓存；
• 页面是否没有明显排版断裂。

这也是为什么我更倾向于让 AI Agent 使用真实浏览器检查，而不只依赖 curl。Cloudflare、缓存、浏览器环境、图片加载，这些都可能让“HTTP 成功”和“用户体验正常”之间出现差异。

验证阶段的原则是：不要验证自己做了什么，要验证用户最终得到了什么。

五、第四步：复盘，让下一次任务变得更聪明

定时任务如果每天只是重复执行，很快会变成机械流水线；如果每次都能留下记录，它才会逐渐变成数字员工。

复盘至少包括三类信息：

1. 今天发布了什么主题；
2. 哪些步骤通过了，哪些步骤曾经失败或重试；
3. 是否需要更新计划、模板、检查项或内容策略。

比如当文章数量接近 30 篇时，就不应该继续只按单篇文章发布，还要考虑专题页、内链结构、服务页、资源页和轻产品承接。也就是说，复盘不仅是“今天成功了”，还要帮助内容系统进入下一阶段。

万象片场的长期目标不是堆文章数量，而是把 AI 自动化、数字员工、Agent 实战这些真实过程沉淀成可搜索、可复用、可变现的资产。定时任务每天跑一次，只是节奏；每次跑完以后留下可用经验，才是资产积累。

六、我现在判断一个 AI 定时任务是否可靠的清单

如果要把这篇文章变成一张执行清单，我会这样检查：

• 是否有固定输入：计划文件、项目路径、内容目录；
• 是否会先读取现状，而不是凭记忆行动；
• 是否能避免重复标题和重复主题；
• 是否只操作授权范围内的文件；
• 是否有本地预览或等价检查；
• 是否构建失败就停止部署；
• 是否验证线上结果，而不是只看部署命令；
• 是否提交 Git 前检查变更范围；
• 是否有清晰的最终报告；
• 是否能把问题反馈到下一次流程优化。

这张清单不复杂，但它能把“会跑的脚本”和“可靠的数字员工”区分开。

结尾：自动化的本质是可持续交付

我越来越觉得，AI 自动化真正有价值的地方，不是让人完全消失，而是把一套可重复、可检查、可迭代的流程交给数字员工。

一个可靠的 AI 定时任务，应该像片场里的场记和制片助理：每天按计划开工，先确认通告单，再执行拍摄流程，收工前检查素材，最后留下记录。这样，万象片场的内容系统才不会只是灵感驱动，而会变成一条能长期运转的生产线。

下一步，我会继续把这些定时任务拆得更细：哪些环节适合完全自动化，哪些环节必须保留人工确认，哪些检查项可以沉淀成通用 SOP。等这些流程稳定以后，它们就不只是博客发布脚本，而是一套可以迁移到小红书、公众号、YouTube 和轻产品生产的 AI 内容运营系统。