2026年9月23日至10月14日，我们在这个博客上发布的 13 篇故障排查文章，选题全部来自 GitHub issue。而在此前的三周里，9 篇中有 8 篇来自 Reddit。这次转变并非事先计划：一轮又一轮，官方仓库里本周评论最多的 issue 总能给出 Reddit 帖子给不了的东西，也就是原始报错信息、版本号，有时还有维护者的回复。
本文完整介绍这套方法：我们使用的四条 gh（GitHub CLI）命令、我们摸索出来的过滤条件，以及在动笔之前放弃一个 issue 的标准。如果你在维护文档、为某个工具做技术支持，或者只是想在问题落到自己头上之前知道大家都遇到了什么，这套方法都用得上。
用哪条命令列出仓库里评论最多的 issue？
用 gh search issues 加上 --sort comments，并按创建日期过滤。每一轮都从这条命令开始：
gh search issues --repo openai/codex --state open \
--created ">=2026-10-08" --sort comments --limit 5 \
--json number,title,commentsCount \
--jq '.[] | "\(.commentsCount)\t#\(.number)\t\(.title)"'2026年10月15日运行时，排在第一的是 #52407，六天内 93 条评论，内容是 Windows 上 Codex 的 MXC launcher ... HRESULT 0x80070003 报错。这个 issue 就是我们 10月14日那篇文章 的来源。
关键参数如下，已对照 2.100.0 版本的 gh search issues --help 核实：
| 参数 | 作用 | 为什么用它 |
|---|---|---|
--sort comments | 按评论数排序 | 评论意味着受影响的人在想办法解决，这是 GitHub 上最好的痛点信号 |
--created ">=YYYY-MM-DD" | 只看该日期之后创建的 issue | 排除只是最近又收到评论的老 issue |
--state open | 只看未关闭的 issue | 问题仍然存在。已修复并关闭的属于另一类文章 |
--json + --jq | 选择字段并格式化输出 | 每个 issue 一行，方便阅读，也方便交给脚本处理 |
命令帮助里还有一个细节：语义搜索（--search-type semantic 或 hybrid）按相关度排序，不接受 --sort。要按评论数排名，就用默认搜索。
为什么按 --created 过滤，而不是 --updated？
因为 --updated 会把昨天刚收到一条评论的老 issue 也带回来。2026年10月15日，我们在 Codex 仓库用同一条命令的两个版本跑了一次，截止日期都是10月8日：
| 过滤条件 | 前 5 名里出现了什么 |
|---|---|
--updated ">=2026-10-08" | 5 个里有 2 个是老的：一个6月18日提出的功能请求，另一个是1月14日的（要求恢复 /undo） |
--created ">=2026-10-08" | 5 个全是本周的，其中一个10月14日才创建，已经有 44 条评论 |
老的功能请求也可以是选题，但属于另一类。要找到眼下正在影响所有人的报错，关键是创建日期。
有一个过滤没法自动化：评论多不等于是 bug。同一天，anthropics/claude-code 的前 5 名里有一个要求恢复界面选项的请求，还有一个完全没有报错的吐槽。打开任何 issue 之前，先读标题。
怎样把一个 issue 扩展成同一错误的多个变体？
在同一个仓库里，用引号搜索原始报错信息。一个 issue 只是一个案例，搜索结果才能显示规律。
gh search issues "SIGSEGV" --repo anthropics/claude-code \
--created ">=2026-08-01" --limit 100 --json number,title,createdAt2026年10月15日，这条搜索返回了自8月1日以来创建的 58 个 issue。9月27日，一个看起来很小众的候选（只有一个 issue）就是这样变成了我们关于 Claude Code SIGSEGV 的文章：读完搜索结果后，同一条报错背后出现了三种不同原因，每种都有各自的解决路径。文章因此写成了按变体分类的表格，而不是只适用于三分之一读者的单一答案。
怎样不离开终端读完整个 issue？
用 gh issue view 加 --comments 参数，它会按顺序输出描述和全部评论：
gh issue view 52407 --repo openai/codex --comments我们在每个讨论串里按以下顺序寻找：
- 原始报错信息，从报告者的日志里复制。读者会把它粘贴到搜索框里。
- 准确的版本号，包括出现错误的版本和错误消失的版本。
- 维护者的回复、修复 PR 或提到的发布版本。
- 不止一个人确认过的临时方案。只有一个用户验证过的方案会注明出处，绝不当作解决方案。
想知道 issue 是否已经修复并关闭，又不想读完整个讨论串：
gh issue view 52407 --repo openai/codex --json state,closedAt,labels动笔之前怎样对照源码核实？
如果项目是开源的，就去读生成这条报错信息的文件。gh api 配上正确的 header 会返回原始内容：
gh api repos/openai/codex/contents/codex-rs/mxc-sandbox/src/windows.rs \
-H "Accept: application/vnd.github.raw" | grep -n "cannot locate required"2026年10月15日，这条命令指向该文件第 131 行，0x80070003 的报错信息就是在那里拼出来的。这就是“用户说错误来自启动器”和“错误来自这个文件里的这个函数”之间的区别。如果项目是闭源的，对应的来源就是官方错误文档（如果有的话）。
什么时候应该放弃一个 issue，而不是写它？
读完讨论串、查过来源之后，如果既没有确认的原因，也没有修复，就放弃。未经确认的报告不能成文，不管评论有多少。我们最常用的三种放弃理由：
| 情况 | 我们的做法 |
|---|---|
| 没有原因也没有修复，评论里只有猜测 | 放弃。10月11日，我们把一个只有 4 条评论、全是猜测的 403 错误，换成了另一个报错信息出现在官方文档里的 issue |
| 这个错误我们已经写过 | 跳到下一个。10月11日和12日，Codex 评论最多的 issue 都是我们10月10日已经发布过的错误 |
| 候选不错，但时机还早 | 把编号记进队列，下一轮再看。10月7日的文章就直接来自前一天记下的候选 |
为什么我们从 Reddit 转向了 GitHub issue？
因为 issue 一到手就是故障排查文章需要的格式。Reddit 帖子很适合感受这一周的情绪，但几乎总要再查一轮，才能变成可以核实的内容。
| 属性 | Reddit 帖子 | 官方仓库的 issue |
|---|---|---|
| 原始报错信息 | 有时有，通常是截图 | 几乎总有，是可复制的文本 |
| 受影响的版本 | 很少 | 通常是 bug 模板里的字段 |
| 维护者的回复 | 很少 | 如果有，就在讨论串里，并链接到 PR 或发布版本 |
| 需要事实核查 | 总是需要：9月5日，一个热门数字被证实不准确，文章角度随之改变 | 较少，因为可以对照代码 |
| 最适合 | 额度、价格、政策变化 | 带报错信息的错误、崩溃、版本回归 |
Reddit 并没有退出流程。对于额度和计费这类没有 issue 的话题，它仍然是合适的来源。但对于带报错信息的错误，13 轮里 issue 全部胜出。
能不能一次在多个仓库里跑完？
可以。下面这个循环会列出三个编程智能体仓库最近 7 天里评论最多的 5 个新 issue（在 macOS 上，把日期换成 date -v-7d +%F）：
for repo in openai/codex anthropics/claude-code google-gemini/gemini-cli; do
echo "== $repo"
gh search issues --repo "$repo" --state open \
--created ">=$(date -d '7 days ago' +%F)" --sort comments --limit 5 \
--json number,title,commentsCount \
--jq '.[] | "\(.commentsCount)\t#\(.number)\t\(.title)"'
done无法自动化的是判断：读讨论串、对照来源、站不住就放弃。这也是最消耗上下文的部分，因为一个 90 条评论的 issue 很长。终端里的编程智能体可以跑这个循环、打开讨论串并总结每个 issue 确认了什么，而每次阅读的成本就在这里累积：在 Verboo Code 上 token 不限量，所以读完整个讨论串和只读标题的成本一样。
