官方教程中文版實戰場景
用 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。
- 自動化前已經手動跑過並調過報告格式。
- 任何釋出、建立、分派動作都先走草稿。