自动化缺陷分诊 | Codex 使用场景

概览

让 Codex 检查最近的告警、问题、失败检查、日志和聊天报告，在一个线程中调整列表，然后按计划运行这轮排查。

适合场景

适合在 Sentry 告警、Slack 线程、Linear 问题、GitHub issues、失败的 PR 检查、支持工单或日志之间跟踪缺陷的团队。
适合你想先在一个 Codex 线程中手动运行、再安排为自动化的分诊工作流。

运行一次缺陷分诊排查

为 [仓库/服务/团队] 运行一次覆盖最近 [时间窗口] 的缺陷分诊。

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

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

输出格式：
首先说明你无法访问的输入来源。
然后返回一个按 P0 到 P3 排序的缺陷优先级列表。
如果没有发现缺陷，请说：未发现符合条件的缺陷。

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

规则：
- 不要发布、创建、分配、打标签、关闭、重新运行或编辑任何内容。
- 将重复报告合并到同一个缺陷下。
- 将观察到的证据与推测分开。

使用方法

让 Codex 检查缺陷已经出现的地方：Sentry 告警、Linear 问题、GitHub issues、PR 检查、部署日志、支持工单和 Slack 线程。先手动执行一次排查，在当前线程中调整报告，然后按计划运行它。

在整个分诊循环中使用同一个 Codex 线程：

按需运行一次排查并获得草稿列表。
审查该列表，并在同一个线程中提供反馈。
将同一个线程转换为自动化。
可选：当你对报告有信心后，让 Codex 起草 Linear 问题、Slack 更新、GitHub 评论或交接说明。

开始之前，请安装 Codex 所需的插件，例如 Sentry、Slack、Linear 或 GitHub。在起始提示中，将方括号中的插件列表替换为真实的 @ 插件标签。然后将每个方括号中的来源替换为要搜索的确切位置：Sentry 项目或告警 URL、Slack 频道或线程、Linear 团队、视图或查询、GitHub 仓库、issue 查询或 PR 检查、部署链接、日志文件、支持队列或仪表板。

阶段 1：运行排查

当本地上下文有帮助时，从拥有这些缺陷的仓库启动 Codex：例如测试、仓库工具、构建检查或 CI 失败。如果你的缺陷来源可通过插件、连接器、MCP servers、链接、导出、粘贴的日志或附件获得，你也可以从任何仓库运行这轮排查。

先运行上面的起始提示。只保留属于你这轮排查的插件和来源。

例如，填写后的提示可以指定要纳入排查的插件以及确切的队列、频道或仓库。

阶段 2：让报告更有用

在自动化之前，先确保这份报告足够有用，值得每天阅读。

一次有用的首次运行应具备：

按 P0 到 P3 排序的高信号缺陷。
重复报告被归并到同一个缺陷下。
每个缺陷都有关联证据或简短引文。
猜测与观察到的事实分开呈现。
每个缺陷都有简短的推荐后续操作。

在将其自动化之前，先在同一个线程中调整报告。你可以要求 Codex：

在对列表排序前再检查一个来源。
去掉团队已经知晓的噪声告警。
只返回 P0 和 P1 缺陷。
在 Slack 报告、Sentry 告警和 GitHub 失败指向同一个缺陷时将其合并。
为每个缺陷显示一个最佳链接。
添加足够的证据，让其他人能够复现或分派该问题。

阶段 3：将其自动化

当按需生成的报告已经有用时，留在同一个线程中并将它转换为自动化。Codex 可以利用你在线程中完善过的内容来编写周期性自动化提示。

创建自动化

阶段 4：安排后续处理

当定时报告已经足够有用时，决定接下来应将工作流转到哪里。Codex 可以为团队频道起草 Slack 更新，为你想跟踪的缺陷编写 Linear 问题，为失败的 PR 编写 GitHub 评论，或为值班人员生成交接说明。