---
title: "用 Codex 做 Bug 分診"
description: "說明如何讓 Codex 只讀掃查 Sentry、Slack、Linear、GitHub 和 logs 中的 bug 訊號。"
verifiedAt: "2026-05-06"
---

import { Cards, Card } from 'fumadocs-ui/components/card';

Bug triage 的目標，是把散落在 Sentry、Slack、Linear、GitHub、PR checks、support tickets、logs 和 dashboards 裡的訊號，整理成可分派、可復現、可驗證的優先順序列表。

> [!IMPORTANT]
> 第一版 bug triage 必須只讀：不 post、不 create、不 assign、不 label、不 close、不 rerun、不 edit。

<Cards>
  <Card title="Automation bug triage" href="https://developers.openai.com/codex/use-cases/automation-bug-triage">
    官方 bug triage 場景。
  </Card>
  <Card title="Automations" href="/zh-Hant/docs/codex/official/01-products/35-app-automation">
    手動報告穩定後，再沉澱為 automation。
  </Card>
  <Card title="MCP and plugins" href="/zh-Hant/docs/codex/official/03-extensions/08-mcp-integration">
    讀取外部系統前先確認許可權和資料來源。
  </Card>
</Cards>

## 推薦流程

```mermaid
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。
- 自動給客戶或團隊頻道發訊息。

## 起始提示詞

```text
请为 [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。
- 自動化前已經手動跑過並調過報告格式。
- 任何釋出、建立、分派動作都先走草稿。

## 官方資料

- [Automation bug triage](https://developers.openai.com/codex/use-cases/automation-bug-triage)
- [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)
