需求
Bug 上下文汇聚之处
默认选项
Sentry 告警、Slack 频道、Linear 视图、GitHub issue、PR 检查、支持队列、值班笔记、日志、仪表盘和部署说明
为何需要它
指出 Codex 应该排查的确切队列、频道、视图、仓库、告警链接、仪表盘和文件。
Codex 用例
自动化 Bug 分流
将每日 Bug 报告转化为优先级列表，然后自动执行全面排查。
难度 中级
时间周期 1h
让 Codex 检查最近的告警、issue、失败的检查、日志和聊天报告，在一个线程中调整列表，然后按计划运行该排查。
适用场景
- 通过 Sentry 告警、Slack 线程、Linear issue、GitHub issue、失败的 PR 检查、支持工单或日志来追踪 Bug 的团队。
- 希望先在一个 Codex 线程中手动运行，然后再安排为自动化的分流工作流。
目录
自动化 Bug 分流
将每日 Bug 报告转化为优先级列表，然后自动执行全面排查。
让 Codex 检查最近的告警、issue、失败的检查、日志和聊天报告，在一个线程中调整列表，然后按计划运行该排查。
中级
1h
让 Codex 检查最近的告警、issue、失败的检查、日志和聊天报告，在一个线程中调整列表，然后按计划运行该排查。
中级
1h
适用场景
- 通过 Sentry 告警、Slack 线程、Linear issue、GitHub issue、失败的 PR 检查、支持工单或日志来追踪 Bug 的团队。
- 希望先在一个 Codex 线程中手动运行，然后再安排为自动化的分流工作流。
技能与插件
- 当 GitHub 是你的 Bug 收集渠道之一时，读取 issue、拉取请求、评论、审查线程和失败的检查。
- 当告警是排查范围的一部分时，检查生产环境错误、堆栈跟踪、受影响的发布和事件上下文。
- 读取队友报告 Bug 的频道或线程，并为团队频道准备一份草稿摘要。
- 读取 Bug 队列，查找现有 issue，草拟更新，或在分流通过后准备关联的跟进工单。
起始提示词
针对 [repo/service/team] 运行一次 Bug 分流排查，覆盖最近 [time window]。使用这些插件：[@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] - 其他：[logs / support tickets / deploy link / dashboard / attached file / none] 输出格式：首先，列出你无法访问的任何输入源。然后返回一个优先级排序的 Bug 列表，从 P0 到 P3。如果未发现 Bug，请说明：No qualifying bugs found。针对每个 Bug，包含：- 优先级：P0、P1、P2 或 P3 - 标题 - 证据（链接或简短引述）- 建议的下一步操作 规则：- 不要发布、创建、分配、标记、关闭、重新运行或编辑任何内容。- 将重复报告合并在一个 Bug 下。- 将观察到的证据与猜测区分开来。
针对 [repo/service/team] 运行一次 Bug 分流排查，覆盖最近 [time window]。使用这些插件：[@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] - 其他：[logs / support tickets / deploy link / dashboard / attached file / none] 输出格式：首先，列出你无法访问的任何输入源。然后返回一个优先级排序的 Bug 列表，从 P0 到 P3。如果未发现 Bug，请说明：No qualifying bugs found。针对每个 Bug，包含：- 优先级：P0、P1、P2 或 P3 - 标题 - 证据（链接或简短引述）- 建议的下一步操作 规则：- 不要发布、创建、分配、标记、关闭、重新运行或编辑任何内容。- 将重复报告合并在一个 Bug 下。- 将观察到的证据与猜测区分开来。
如何使用
让 Codex 检查已经出现 Bug 的地方：Sentry 告警、Linear issue、GitHub issue、PR 检查、部署日志、支持工单和 Slack 线程。先进行一次手动排查，在线程中调整报告，然后按计划运行它。
使用一个 Codex 线程完成整个分流循环：
- 运行按需排查并获取草稿列表。
- 在同一线程中审查列表并提供反馈。
- 将同一个线程转换为自动化。
- 可选：当你对报告有把握时，让 Codex 草拟 Linear issue、Slack 更新、GitHub 评论或交接说明。
在开始之前，请安装 插件 Codex 所需的插件，例如 Sentry、Slack、Linear 或 GitHub。在起始提示词中，将括号内的插件列表替换为真实的 @ 插件标签。然后将每个括号内的来源替换为确切的搜索位置：Sentry 项目或告警 URL、Slack 频道或线程、Linear 团队、视图或查询、GitHub 仓库、issue 查询或 PR 检查、部署链接、日志文件、支持队列或仪表盘。
阶段 1：运行排查
当本地上下文（如测试、仓库工具、构建检查或 CI 失败）有帮助时，从拥有这些 Bug 的仓库启动 Codex。如果你的 Bug 来源可通过插件、连接器、MCP 服务器、链接、导出、粘贴的日志或附件获取，你也可以从任何仓库运行排查。
首先运行上面的起始提示词。仅保留属于你排查范围的插件和来源。
例如，一个填写完整的提示词可以指定你希望包含在排查中的插件以及确切的队列、频道或仓库。
阶段 2：让报告发挥作用
在自动化之前，确保报告有足够的价值让你每天都愿意阅读。
一次有价值的首轮运行包含：
- 按 P0 到 P3 排序的高价值 Bug。
- 重复报告合并在一个 Bug 下。
- 每个 Bug 都有链接的证据或简短引述。
- 猜测与观察到的事实明确区分。
- 每个 Bug 都有简短的建议下一步操作。
在自动化之前，先在同一个线程中调整报告。你可以让 Codex：
- 在对列表进行排序之前检查多一个来源。
- 过滤掉团队已经知悉的噪音告警。
- 仅返回 P0 和 P1 Bug。
- 当 Slack 报告、Sentry 告警和 GitHub 失败指向同一个 Bug 时，将它们合并。
- 展示每个 Bug 最佳的单个链接。
- 添加足够的证据，以便其他人可以复现或路由该问题。
阶段 3：实现自动化
当按需报告发挥作用时，留在同一个线程中并将其转换为自动化。Codex 可以使用你在线程中提炼的内容来编写定期执行的自动化提示词。
创建自动化
根据我们在此线程中完善的工作流创建一个 Bug 分流自动化。计划：[every hour / every weekday morning / daily] 使用此线程中相同的来源、优先级规则、重复项分组、证据样式和 P0-P3 报告格式。在编写自动化提示词时，包含提及插件或连接来源的说明，以便定期运行的任务能够再次读取这些来源。保持自动化为仅生成草稿。不要发布、创建、分配、标记、关闭、重新运行、开始修复或编辑代码。在创建之前，向我展示自动化提示词、计划、来源和操作策略。
阶段 4：路由后续事项
一旦定期报告发挥出作用，决定下一步工作该去向何处。Codex 可以为团队频道草拟 Slack 更新，为你想要跟踪的 Bug 编写 Linear issue，为失败的 PR 编写 GitHub 评论，或者为值班人员生成交接文档。
更新此 Bug 分流自动化。每次运行后，草拟我需要的后续事项：- 为 [channel] 草拟 Slack 更新 - 为 [which bugs should become issues] 草拟 Linear issue - 为 [issue / PR / failing check] 草拟 GitHub 评论 - 为 [team / on-call / owner] 草拟交接说明 规则：- 先在 Codex 中草拟后续事项。- 在我明确批准该操作之前，不要发布到 Slack、创建 Linear issue 或在 GitHub 上评论。- 尽可能包含指向现有 Linear、GitHub、Slack 或告警来源的链接。- 对任何未明确批准的操作保持仅生成草稿的行为。
技术栈
需求
默认选项
为何需要它
需求
Codex 如何读取它
为何需要它
有现成集成时安装它。为 Codex 尚无法读取的内部来源，构建或配置小型 MCP 服务器、CLI、导出或仪表盘链接。
