霍风风早上到公司的第一件事，不用猜，大部分团队都一样：打开 Sentry，看昨晚又挂了什么。我这边业务线略多，项目加起来十几个，Sentry 里堆栈看半天，经常是同一个报错在不同版本、不同用户里反复出现，新问题被旧问题淹没。每天光是筛选一遍新 bug 就要花二十几分钟，更麻烦的是看了也不一定判断得出该立刻修还是能缓缓。
后来我琢磨了一下，能不能把“拉日志”和“读日志”这两件事完全交给程序跑。正好 Codex 这个终端里的 AI 智能体成熟了不少，支持非交互模式，可以像命令一样被别的脚本调用。于是就有了今天这套东西：每天定时让 Codex 拉取 Sentry 最近 24 小时的日志，自动做聚合、分析、定位，最后生成一份“今天有哪些 bug 值得看、最可能的原因是什么、修复建议是什么”的日报，直接推到团队群。
这篇文章我分成四块写：整体设计思路、核心准备、落地脚本、以及我在实操中踩过的坑。涉及的代码我会直接贴出来，你可以照着改一版用在自己项目上。
1. 整体设计与思路拆解
1.1 这活儿真正难的不是“拉日志”，是“读日志”
如果要给这件事拆步骤，原来的手动流程大概是这样的：
- 打开 Sentry 项目首页，点 Issues。
- 按“最近出现”排序，扫一遍列表里新冒出来的报错。
- 点进每一个看起来陌生的 issue，看堆栈的栈顶几行。
- 对照源码定位是哪个模块抛出来的。
- 根据影响人数、出现频率、是不是最近上线的新代码，判断优先级。
这套流程里，第 1 步和第 2 步本质上就是“拉日志”，用 Sentry API 十分钟就能搞定。真正耗费精力的是第 3 到第 5 步——“读日志”和“判断优先级”。一个堆栈可能横跨十几个调用帧，里面还穿插着框架内部的方法，如果对代码不熟，光是把“哪个函数是真正业务侧的”提取出来就得花不少时间。
所以我的核心思路是：把“拉日志”交给脚本，把“读日志”交给 Codex。脚本负责按时按点把数据准备好，Codex 负责像一个不睡觉的同事一样，把堆栈信息消化掉，输出人能直接看懂、能直接拍板的结果。
这个定位很重要。如果你也想搭这么一套，别把重心放在“怎么把日志拉下来”，那只是最初级的体力活；把思路放在“怎么让 Codex 分析得更准、输出更稳定”，这决定了这套自动化到底是真的提效，还是另一个玩具。
1.2 为什么选 Codex 而不是自己写一套规则脚本
在决定用 Codex 之前，我其实先评估过另外两条路：Sentry 自带的 Alert 通知，和自己写规则过滤脚本。
Sentry 的 Alert 能做的是：当某个 issue 满足条件时，发邮件、发 webhook。它只告诉你“有问题”，不会告诉你“这个问题的堆栈指向哪个模块、大概率是什么原因、要不要叫后端同事看一眼”。而且多项目、多环境下的告警规则维护起来非常琐碎，规则写松了吧，天天轰炸；写紧了吧，真正的问题又漏了。
自己写规则脚本则是另一个极端。你可以按标题关键字分组、按用户量排序、定期对比新旧 issue 集合。这套东西确实能做，但有一个致命问题：规则是死的。今天服务端抛了一个新串格式的错误，明天前端某个 SDK 升级后堆栈风格变了，你的关键词过滤规则就失效了，又得去加规则。等于这套“自动化”的长尾维护成本，比它省下来的时间还高。
Codex 的路子不太一样。它是语言模型，不需要你预先写死什么“规则”，你只要把堆栈信息丢给它，它自己理解上下文。更关键的在于 Codex 是一个 CLI 程序，支持非交互式调用，天然适合嵌进脚本链里。我可以用 cron 定时触发一个 Python 脚本，脚本拉完数据后直接调 codex exec，把分析结果拿回来，再推送出去。整个链路上没有人在中间拦一下，真正的全自动。
1.3 方案选型：把“能用”和“好维护”分开看
技术栈我最终选的是 Python + Shell 的组合。Sentry 日志拉取用 Python 的 requests 库，分析环节调 Codex CLI，定时任务用系统自带的 crontab。这个组合最大的好处是“每一环都能单独调试”。
我见过不少团队一上来就上 Jenkins、上 K8s CronJob、上容器编排，把一个很轻的需求搞得很重。定时拉日志分析这件事，最重的依赖其实是 Sentry API 和 Codex 的调用，逻辑本身不复杂，没必要为了“显得正规”引入一堆基础设施。开发期内你在本地手动跑，验证稳定了再扔进 crontab，这才是最快的路径。
| 方案 | 优点 | 缺点 | 结论 |
|---|---|---|---|
| Sentry Alert | 配置简单，官方支持 | 只能通知，不能分析，多项目规则繁琐 | 做补充可以，做主力不行 |
| 自研规则脚本 | 可控性强，不依赖外部模型 | 规则写死，堆栈一变就失灵，维护成本高 | 适合当滤波层，不适合当分析层 |
| Codex 分析 | 能理解上下文，输出像人话，适配新报错 | 需要调 prompt，偶尔输出不稳定 | 主力方案 |
架构上就四条线：cron 定时触发、Python 拉取日志、Codex 分析、webhook 推送。下面一步一步展开。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心环节准备：Sentry API 与 Codex CLI
2.1 申请 Sentry API Token 并确认项目标识
先准备一个能读取 Sentry 数据的 Token。如果你是 Sentry SaaS 用户，打开组织首页后进 Settings，找到 Auth Tokens（在 Developer Settings 下），点 Create New Token。如果是自建 Sentry，路径类似，只是域名换成你自己的。
Token 的权限不能乱给。我们这个场景只需要读取项目事件和 issue，勾上 `project:r