官方教程中文版实战场景
用 Codex 做 Bug 分诊
说明如何让 Codex 只读扫查 Sentry、Slack、Linear、GitHub 和 logs 中的 bug 信号。
Bug triage 的目标，是把散落在 Sentry、Slack、Linear、GitHub、PR checks、support tickets、logs 和 dashboards 里的信号，整理成可分派、可复现、可验证的优先级列表。
第一版 bug triage 必须只读：不 post、不 create、不 assign、不 label、不 close、不 rerun、不 edit。
Automation bug triage
官方 bug triage 场景。
Automations
手动报告稳定后，再沉淀为 automation。
MCP and plugins
读取外部系统前先确认权限和数据来源。
推荐流程
flowchart LR
Sources["sources"] --> Sweep["read-only sweep"]
Sweep --> Report["P0-P3 report"]
Report --> Refine["dedupe / evidence / priority"]
Refine --> Automation["automation"]
Automation --> Drafts["draft follow-ups"]适合 Codex 的分诊任务：
- 读取多个来源。
- 合并重复报告。
- 按 P0-P3 输出优先级。
- 分开事实和推测。
- 给每个 bug 附证据链接。
- 起草 follow-up，但先不发布。
不适合第一版就做：
- 自动创建 issue。
- 自动分派负责人。
- 自动关闭 bug。
- 自动重跑 CI。
- 自动给客户或团队频道发消息。
起始提示词
请为 [repo/service/team] 做一次 bug triage sweep，覆盖最近 [time window]。
输入来源：
- 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]
输出：
- 先说明哪些输入来源无法访问
- 按 P0 到 P3 返回 bug 列表
- 没有发现时明确写“没有发现符合条件的 bug”
每个 bug 包含：
- Priority
- Title
- Evidence
- Recommended next action
规则：
- 不要 post、create、assign、label、close、rerun 或 edit
- 重复报告合并到同一个 bug 下
- 已观察证据和推测分开把方括号替换成真实项目、时间窗口和数据来源。没有接入的来源就写 none，不要让 Codex 猜。
输入来源要具体
不要只说“看一下最近 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 按 P0 到 P3 排序。
- 重复报告归并到同一个 bug 下。
- 每个 bug 都有 evidence links 或 short citations。
- 事实和推测分开写。
- 每个 bug 都有 recommended next action。
- 无法访问的来源明确列出。
可以在同一线程里继续要求 Codex：
- 再检查一个来源后重新排序。
- 去掉团队已知噪声 alert。
- 只返回 P0 和 P1。
- 合并 Slack、Sentry、GitHub 中指向同一问题的内容。
- 每个 bug 只保留最有价值的一个链接。
何时自动化
当 on-demand report 已经有用时，不要换线程。继续在同一线程里让 Codex 创建 automation，这样它能复用刚刚调好的排序规则、来源范围和输出格式。
自动化前确认：
- 输入来源稳定。
- 插件和连接方式可用。
- 输出格式不会太长。
- P0-P3 标准清楚。
- 只读边界仍然保留。
后续流转
定时报表稳定后，再决定后续流转。Codex 可以起草：
- 团队 Slack update。
- 需要追踪的 Linear issue。
- failing PR 的 GitHub comment。
- on-call handoff note。
这些动作建议先保持 draft。确认报告质量稳定后，再逐步放开创建、评论、分派或更新动作。
验收清单
- 所有输入来源和不可访问来源都写清。
- 报告只读，没有外部写入动作。
- P0-P3 标准一致。
- 重复报告已合并。
- 每个 bug 有 evidence 和 next action。
- 自动化前已经手动跑过并调过报告格式。
- 任何发布、创建、分派动作都先走草稿。