用 Codex 自动化 Bug 分流

把 issue、日志和代码上下文整理成可执行的修复优先级。

官方概览

让 Codex 检查 bug 已经出现的地方：Sentry 告警、Linear issue、GitHub issue、PR 检查、部署日志、支持工单和 Slack 线程。先跑一次手动扫描，在同一个线程里调整报告，然后再设为定时自动化。

整个分流循环建议放在一个 Codex 线程里完成：先运行按需扫描，得到草稿列表；在同一线程里 review 并反馈；最后把这个线程转成自动化。

可选地，当你对报告足够有信心后，让 Codex 起草 Linear issue、Slack 更新、GitHub 评论或交接说明。
开始前安装必要插件，例如 Sentry、Slack、Linear 或 GitHub。
在 starter prompt 中，把占位插件和来源替换成真实项目、频道、视图、查询、日志或附件。

阶段 1：运行扫描

当本地上下文有帮助时，从拥有这些 bug 的仓库启动 Codex，例如测试、仓库工具、构建检查或 CI 失败。

如果 bug 来源可以通过插件、连接器、MCP server、链接、导出、粘贴日志或附件访问，也可以从任意仓库运行扫描。

阶段 2：让报告有用

自动化之前，先确认报告值得每天阅读。一个有用的首次结果应该包含高信号 bug，按 P0 到 P3 排序，重复报告合并，每个 bug 有链接证据或简短引用，并把猜测和事实分开。

在同一个线程里调优报告。可以让 Codex 多检查一个来源、丢弃团队已知的噪音告警、只返回 P0/P1、合并指向同一 bug 的 Slack/Sentry/GitHub 证据，或为每个 bug 提供最好的一个链接。

阶段 3：自动化它

当按需报告已经有用时，留在同一个线程，把它转成自动化。Codex 可以复用你在这个线程里调整过的规则，写出周期性自动化 prompt。

自动化应该默认保持草稿行为：不要发布、创建、分配、打标签、关闭、重跑、开始修复或编辑代码。创建前，先让 Codex 展示自动化 prompt、时间表、来源和动作策略。

阶段 4：路由后续动作

当定时报告稳定可用后，再决定工作流下一步去哪里。Codex 可以为团队频道起草 Slack 更新，为需要追踪的 bug 起草 Linear issue，为失败 PR 写 GitHub 评论，或为值班同学生成交接说明。

所有外部动作都应先在 Codex 中生成草稿，在你明确批准前，不要发布到 Slack、创建 Linear issue 或评论 GitHub。

官方 Starter Prompt 中文翻译

请为 [仓库/服务/团队] 运行一次 bug 分流扫描，覆盖过去 [时间窗口]。

使用这些插件：[ @Sentry / @Slack / @Linear / @GitHub / none ]

输入来源：
- Sentry：[项目 / 告警链接 / none]
- Slack：[频道 / 线程链接 / none]
- Linear：[团队 / 项目 / 视图 / issue 查询 / none]
- GitHub：[仓库 / issue 查询 / PR 检查 / none]
- 其他：[日志 / 支持工单 / 部署链接 / dashboard / 附件 / none]

输出格式：
首先说明你无法访问的输入来源。
然后返回一个按 P0 到 P3 排序的 bug 优先级列表。
如果没有找到 bug，请说：No qualifying bugs found.

每个 bug 包含：
- 优先级：P0、P1、P2 或 P3
- 标题
- 证据（链接或简短引用）
- 建议的下一步动作

规则：
- 不要发布、创建、分配、打标签、关闭、重跑或编辑任何东西。
- 把重复报告归并到同一个 bug 下。
- 把观察到的证据和推测分开。