用 Codex 做 Bug 分诊
把每天散落在 Sentry、Slack、Linear、GitHub、PR checks、support tickets、logs 和 dashboards 里的
把每天散落在 Sentry、Slack、Linear、GitHub、PR checks、support tickets、logs 和 dashboards 里的 bug 信号，交给 Codex 做一次只读扫查。先在一个线程里手动跑通报告，再把同一个线程沉淀成 automation。
官方页面：https://developers.openai.com/codex/use-cases/automation-bug-triage
适合什么任务
| 场景 | Codex 应该做什么 |
|---|---|
| bug 分散在多个系统 | 读取各来源，按 P0-P3 输出优先级列表 |
| 团队每天都要人工扫 alert、issue、failed checks | 先跑一次 on-demand sweep，再调报告格式 |
| 需要把重复 triage 自动化 | 把跑顺的同一线程转成 Codex automation |
| 还没有信心自动创建 issue 或评论 | 先只读，不 post、不 create、不 assign、不 label、不 close、不 rerun、不 edit |
使用的能力
| 能力 | 用法 | 链接 |
|---|---|---|
github | 读取 issues、pull requests、comments、review threads 和 failed checks | https://github.com/openai/plugins/tree/main/plugins/github |
$sentry | 查看 production errors、stack traces、affected releases 和 event context | https://github.com/openai/skills/tree/main/skills/.curated/sentry |
slack | 读取团队报告 bug 的 channel 或 thread，并准备团队频道摘要草稿 | https://github.com/openai/plugins/tree/main/plugins/slack |
linear | 读取 bug queues，查找已有 issues，草拟更新或准备 linked follow-up tickets | https://github.com/openai/plugins/tree/main/plugins/linear |
相关官方说明：
- Codex automations：https://developers.openai.com/codex/app/automations
- Codex plugins：https://developers.openai.com/codex/plugins
- Codex MCP：https://developers.openai.com/codex/mcp
- Use Codex in Linear：https://developers.openai.com/codex/integrations/linear
起始提示词
请为 [repo/service/team] 做一次 bug triage sweep，覆盖最近 [time window]。
使用这些 plugins：[@Sentry / @Slack / @Linear / @GitHub / none]
输入来源：
- Sentry：[project / alert link / none]
- Slack：[channel / thread links / none]
- Linear：[team / project / view / issue query / none]
- GitHub：[repo / issue query / PR checks / none]
- Other：[logs / support tickets / deploy link / dashboard / attached file / none]
输出格式：
先说明哪些输入来源无法访问。
然后返回按优先级排序的 bug 列表，从 P0 到 P3。
如果没有发现符合条件的 bug，请明确说明：没有发现符合条件的 bug。
每个 bug 包含：
- Priority：P0、P1、P2 或 P3
- Title
- Evidence：链接或简短引用
- Recommended next action
规则：
- 不要 post、create、assign、label、close、rerun 或 edit 任何内容。
- 重复报告合并到同一个 bug 下。
- 把已观察到的证据和推测分开。把方括号里的内容替换成真实项目、时间窗口和数据来源。plugin list 要用真实的 @ plugin chips；没有接入的来源就写 none。
准备输入来源
Bug triage 的质量取决于输入是否具体。不要只说“看一下最近 bug”，而要写清楚：
- Sentry project 或 alert URL。
- Slack channel 或 thread links。
- Linear team、project、view 或 issue query。
- GitHub repo、issue query 或 PR checks。
- deploy link、dashboard、support queue、log file 或 attached file。
如果某个内部来源 Codex 还不能直接读取，可以通过 plugins、connectors、MCP servers、repo CLIs、links、exports、attachments 或 pasted logs 提供。
| 需要说明 | 推荐默认值 | 原因 |
|---|---|---|
| bug context 聚集在哪里 | Sentry alerts、Slack channels、Linear views、GitHub issues、PR checks、support queues、on-call notes、logs、dashboards、deploy notes | Codex 需要明确扫哪些 queue、channel、view、repo、alert link、dashboard 和文件 |
| Codex 如何读取 | Slack、Linear、GitHub、Sentry plugins；connectors；MCP servers；repo CLIs；links；exports；attachments；pasted logs | 有现成集成先用集成；没有时再补小型 MCP、CLI、导出文件或 dashboard link |
Phase 1: Run the Sweep
如果本地 repo context 对判断有帮助，例如测试、repo tooling、build checks 或 CI failures，就从拥有这些 bug 的 repo 启动 Codex。
如果所有 bug 来源都来自 plugins、connectors、MCP servers、links、exports、pasted logs 或 attachments，也可以从任意 repo 启动。
第一轮只跑 starter prompt，保留实际参与本次 sweep 的 plugin 和 source，不要把所有可能来源都塞进去。
Phase 2: Make the Report Useful
自动化前，先把报告调到每天值得读。
一份可用的第一版报告应该满足：
- 高信号 bug 按 P0 到 P3 排序。
- 重复报告归并到同一个 bug 下。
- 每个 bug 都有 evidence links 或 short citations。
- 观察到的事实和推测分开写。
- 每个 bug 都有简短的 recommended next action。
可以在同一线程里继续要求 Codex：
- 再检查一个来源后重新排序。
- 去掉团队已经知道的噪声 alert。
- 只返回 P0 和 P1。
- 把 Slack 报告、Sentry alert 和 GitHub failure 中指向同一个问题的内容合并。
- 每个 bug 只保留最有价值的一个链接。
- 增加足够 evidence，让别人能复现或分派。
Phase 3: Automate It
当 on-demand report 已经有用时，不要换线程。继续在同一线程里让 Codex 创建 automation，这样它能复用刚刚调好的排序规则、来源范围和输出格式。
自动化前先确认：
- 输入来源稳定。
- 插件和连接方式可用。
- 输出格式不会太长。
- P0-P3 标准清楚。
- 只读边界仍然保留。
Phase 4: Route Follow-ups
定时报表稳定后，再决定后续流转。
Codex 可以继续起草：
- 团队 Slack update。
- 需要追踪的 Linear issues。
- failing PR 的 GitHub comments。
- on-call handoff notes。
这些动作建议先保持 draft。确认报告质量稳定后，再逐步放开创建、评论、分派或更新动作。