用定时 Codex 任务生成可靠日报

我的大部分分析工作都不应该交给 LLM 来完成。

源指标、日期和可重复执行的转换都必须保持精确。我过去认为，这意味着整个定时任务都应该交给确定性代码处理，而现在我在某种程度上仍然认同这一点。

真正改变我想法的，并不是让模型计算报告，而是在可靠工具的外围加上一层定时运行的 Codex job：运行工具、检查结果、运用少量且边界明确的判断，最后留下一个 HTML 产物，解释整个过程中发生了什么。

现在，我用这种模式生成两份每日报告。一份主要用于数据分析，另一份则包含更多编辑判断。两者之间那条真正有用的边界非常相似。

让硬边界保持朴素

我的 billiem-analytics 项目会收集网站访客、边缘流量、Google Search Console、DEV 和 Hashnode 的数据，并将其保存为按日期划分的本地快照。

这些数据源提供的数字并不能相互替代。有些是每日流量数据，而 DEV 和 Hashnode 提供的是累计发布计数。真实的零值，与服务提供方不可用、缺少配置或采集失败，是完全不同的情况。

这些差异由确定性代码负责处理。它会重新构建私有 dashboard，并确保报告周期始终一致。Codex 无权掩盖缺失的数据源，也不能把不可靠的指标包装成可靠指标。

这一点很重要，因为最终报告的目的，是让人能够检查，而不只是把它生成出来。如果某个服务提供方发生故障，我希望这个状态能够一路保留下来，最终呈现在页面上。

把边缘处棘手的工作交给模型

定时任务负责外围工作：运行现有命令、检查命令输出、遵循边界明确的恢复规则，并决定如何呈现结果。

在数据分析工作流中，模型承担的角色很小。而在 Founder Brief 中，模型需要做的事情更多。

在这个流程里，一个 Python 采集器会收集候选材料并进行排序，然后生成一个编辑资料包。定时任务会读取这个资料包，检查最有价值的信息源和有用的讨论分支，剔除质量较低或带有推广性质的材料，最后撰写一份简短的 briefing。候选内容 ID 和验证机制能够确保最终结果始终与采集到的证据相关联。

这里确实存在判断，但判断的范围是有限的。固定的排序规则可以决定优先检查哪些内容，却无法自如地判断一则轶事是否有价值、两项观察是否构成某种模式，或者信息源的缺失是否会让某个结论显得过于武断。

Codex 可以依据成文的编辑规则，协助完成这些判断。但它仍然无法保证一定能够访问某个网站。身份验证、访问控制、速率限制和格式变化依然是真实存在的边界。灵活性并不等于拥有一个永远不会出故障的 scraper。

报告让自动化真正变得有用

两个任务最后都会以同一种刻意保持简单的方式收尾：直接把结果扔进一个 HTML 文件。

这样一来，我得到的是一个稳定的产物，而不是一段需要重新梳理的聊天记录或终端会话。日期、数据源状态、对比结果和注意事项都集中在一起，并且随时可以重新打开查看。

在有这份分析报告之前，要了解同样的整体情况，我需要打开多个浏览器窗口，自己对齐不同的时间周期。这个过程痛苦到让我经常懒得去做。现在，我可以在同一个私有视图中看到漂亮的图表和统一的日期。

这种整合让我能够从多个数据源中看出一段没有发布内容的平静时期。这并不是什么出人意料的新指标。真正有用的地方在于，我终于能把已有的信息放在一起查看。

我还把这份报告接入了 Raycast。输入 analytics，就会在 Chrome 中打开报告，并在适当的时候重新生成。这个微小的访问入口比听起来重要得多：我现在真的会打开报告，而不是告诉自己，手动查看 Search Console 这件事可以再等等。

恢复过程必须保持可见

分析任务中包含一条范围很窄的恢复规则。如果在 sandbox 环境中遇到 DNS 或 Keychain 故障，应该先使用正确的本地权限重试，然后才能断定服务提供方出现故障。完成这次重试后，每个服务提供方仍然会获得各自明确的状态。

这是有用的编排机制，并不意味着系统能够自我修复。当 Mac 处于睡眠或离线状态时，本地定时任务可能会错过执行时间。凭据会过期，服务提供方会发生变化，prompt 也可能出错。

模型可以应对已知的运行问题，同时不把真正的故障隐藏在一段语气笃定的总结背后。这就是我真正关心的界限。

对我来说，token 已经足够便宜，值得尝试增加这一层，而且这项工作并不需要 frontier model。如果一个便宜的模型能够包装可靠的代码、处理已知的故障路径，并且偶尔发现固定报告可能遗漏的情况，那我为什么不用它呢？

我并没有得出“每个定时任务都需要 LLM”这样的结论。很多任务仍然只需要一个普通的 scheduler 和一段脚本。这种模式之所以适合我，是因为需要精确完成的工作仍然保持精确，需要判断的部分始终边界明确，而最终产物则让整个运行过程都可以被检查。

想聊聊我写过或构建过的东西吗？欢迎与我联系。

本文在 AI 的协助下改编自 billiem.uk 上的一篇原始文章。原文在发布前经过了审核。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。