我是如何用 Codex 定时任务生成每日报告的
我的大部分分析工作本不该由大语言模型（LLM）来做。原始指标、日期和那些可重复的转换过程必须保持精确。以前我认为这意味着整个定时任务都得交给确定性代码处理，这一点我现在也基本同意。真正让我改变想法的，不是让模型去计算报告，而是把定时 Codex 任务放到可靠工具的外围：运行这些工具、检查结果、施加一点点有限度的判断，最后留下一个能说明来龙去脉的 HTML 产物。如今我用这种模式构建两份每日报告：一份基本是纯分析，另一份在中间环节有更多编辑工作。两者的有效边界是相似的。
硬边界就该简单可靠
我的 billiem-analytics 项目会把网站访客、边缘流量、Google Search Console、DEV 和 Hashnode 的数据收集到按日期命名的本地快照里。这些来源的数据并不是能互相替换的数字。有些是每日流量，而 DEV 和 Hashnode 提供的是累计发布计数器。真实的零和“提供者不可用”“配置缺失”“采集失败”是两回事。这些区分全部由确定性代码负责。它会重建私有仪表盘，并保持报告周期一致。Codex 不能把缺失的来源一笔带过，也不能把一个不可靠的指标变得可靠。这一点很重要，因为最终报告是要拿来检查的，而不是仅仅生成出来。如果某个提供者失败了，我希望这种失败状态能一路保留到最终页面。
把边缘的麻烦事交给模型
定时任务负责的是周边工作：运行现有命令、检查输出、遵循一套有限的恢复规则，并决定如何展示结果。在分析工作流里，这个角色很小。Founder Brief 给模型安排了更多活儿。在那里，一个 Python 收集器会收集并排列候选材料，打包成一个“编辑包”。定时运行时会读取这个包，核查最强的来源和有用的讨论分支，剔除内容薄弱或带推广性质的材料，然后写出一份简短的简报。候选 ID 和校验机制让最终结果始终与已收集的证据挂钩。这种判断是真实存在的，但范围有限。
固定的排序规则能决定先检查什么，却很难判断一条孤证有没有用、两个观察是否构成规律、某个信源缺口会不会让结论下得太重。Codex 可以对照成文的编辑规则来协助这些判断，但它依然无法保证能访问某个网站。身份验证、访问控制、速率限制和格式变化始终是真实存在的边界。灵活并不等于一个永远不坏的爬虫。
报告才是这套自动化真正有用的地方。两个任务都以同样刻意朴素的方式收尾：直接往 HTML 文件里一扔。这给我留下一个稳定成品，而不是需要事后拼凑的聊天记录或终端会话。日期、信源状态、对比和注意事项都汇集在一起，随时可以重新打开。在分析报告出现之前，想核对同一份数据，得打开好几个浏览器窗口，自己手动对齐不同时间段，麻烦到我常常索性不做。现在我能在同一个私有视图里看到漂亮的图表和一致的日期。这种整合让一段没有新内容发布的平静期在各个信源之间清晰可见。这并非什么出人意料的新指标，有用之处在于终于能把已有的信息放在一起看了。
我还把报告加进了 Raycast。输入 analytics 就会在 Chrome 中打开它，并按需重新生成。这条小小的访问路径比听上去重要得多：我真的会去打开报告，而不是想着“手动去 Search Console 查一下也不迟”。
恢复过程必须可见。分析任务里有一条范围很窄的恢复规则：当沙盒化的 DNS 或钥匙串（Keychain）出现失败时，应该先用正确的本地权限重试一次，再判定服务商出了问题。重试之后，每个服务商依然会得到各自明确的状态。这是有用的编排逻辑，而不是声称系统能自我修复。本地定时任务在 Mac 休眠或离线时会错过执行时间；凭证会过期，服务商会变动，提示词也可能出错。模型可以应对已知的操作小状况，但不该把真正的失败藏在一份笃定的总结背后。这才是我在意的界线。
我用定时 Codex 任务做每日报告
我觉得 token 的成本已经低到值得加这一层了，而且也不一定非要用最强的模型。只要一个便宜的模型能稳稳地包住可靠代码、处理已知的失败路径，偶尔还能发现固定报表里漏掉的东西，那为什么不用呢？
我并没有得出结论说每个定时任务都必须上大语言模型（LLM）。很多任务其实只要一个普通调度器加脚本就够了。对我来说，这套模式成立的前提是：核心操作依然精确、判断范围保持可控、最终产物让整个过程都能被检查。
想聊聊我写或做过的东西？欢迎联系我。本文由 billiem.uk 上的一篇文章改编而来，改编过程中使用了 AI 辅助，原文在发布前经过审阅。