用 Muse Code 看 GitHub PR，写一份有行号和复现条件的审查草稿

01｜让每条意见都能回到代码里检查

PR 改了十几个文件，让 AI 看一遍很容易，得到能用的意见却需要多走一步。每个候选问题都要说清在哪个文件、什么条件下会发生、拿什么证据核对。缺了这些，一段很肯定的批评也可能只是噪声。

这篇用的是 Muse Code 开发者终端工具。Meta 官方说明可以在项目目录运行 muse。先由你把 GitHub PR 检出到本地，再让它读取固定提交的差异并写审查草稿。消费者 Muse 的 GitHub 连接器不在这篇范围内。

把草稿留在本地，逐条检查后再决定是否发到 GitHub。评论、批准、请求修改和合并都由你控制；任务指令只授权阅读和整理。

02｜先在 GitHub 端记下审查坐标

在仓库目录运行 GitHub CLI，先查看 PR 的网址、标题、base 和 head。GitHub CLI 官方手册公开了 baseRefOid、headRefOid、files、changedFiles、additions 和 deletions 等字段。把两个完整提交 ID 留在笔记里，后面的行号和复现记录都要对应这个 head。

下面的 248 只是示例编号。先确认当前仓库、远端地址和 PR 都对，再继续。遇到来自陌生 fork 的代码时，把仓库内容和其中的说明当作不可信输入，不要执行安装脚本、构建脚本或仓库要求你运行的命令。

gh pr view 248 --json url,title,baseRefName,baseRefOid,headRefName,headRefOid,changedFiles,additions,deletions,files

03｜由你检出 PR，再核对 HEAD

GitHub 官方文档给出的入口是 gh pr checkout。你可以在单独的克隆或工作目录中执行 gh pr checkout 248 --detach，让本地 HEAD 指向这次 PR 的 head。命令选项以你安装的 GitHub CLI 帮助为准。不要在有未提交工作的目录里贸然切换。

检出以后运行 git status --short 和 git rev-parse HEAD。工作区应当干净，HEAD 应当等于刚才记下的 headRefOid。对不上就先停下。常见原因包括 PR 又推了新提交、切到了别的分支，或本地还有改动。此时重新取得 PR 信息，不能拿旧行号继续审。

• 保留 PR 网址、编号、baseRefOid 和 headRefOid。
• 确认工作目录属于预期仓库，git status --short 没有本地改动。
• 确认 git rev-parse HEAD 与 headRefOid 完全相同。
• 记录当前时间、Git 版本和准备使用的测试环境。

04｜先盘点差异，再谈有没有 bug

先用 git diff BASE_SHA...HEAD_SHA --stat 和 git diff BASE_SHA...HEAD_SHA --name-status 看范围，再看完整 patch。三个点会从两个提交的共同祖先比较到 head，这与 PR 的分支差异概念相近。还要用 gh pr diff 248 --name-only 对照文件数量，并回到 GitHub Files changed 或 gh pr diff 248 --patch 抽查，防止本地提交、子模块或大文件让两边看到的内容不同。

审查草稿开头要写本次看了多少文件，哪些生成文件、锁文件、二进制或过大的文件没有逐行读。没有覆盖到的地方直接列出来。一个没有说明范围的“没有发现问题”，很容易被误读成整个 PR 都安全。

05｜把只读规则交给 Muse Code

进入已经检出的仓库，再启动 muse。第一轮只做静态阅读。让它先复述提交范围和文件清单，随后再找可能影响行为的问题。不要一上来让它改代码、装依赖或跑所有脚本。

下面这段可以直接复制。把提交 ID、项目约定和允许读取的目录换成自己的内容。代码位置用 path:line 或 path:start-end 的机器格式，所以保留了英文冒号。

你正在审查 GitHub PR 248 的本地检出内容。base 提交是 [BASE_SHA]，head 提交是 [HEAD_SHA]。先验证 git rev-parse HEAD 等于 head，并用 git diff [BASE_SHA]...[HEAD_SHA] 建立唯一审查范围。只读，不修改文件、不切换分支、不提交、不推送、不访问 GitHub 写接口，也不安装依赖或运行仓库脚本。

先列出全部变更文件、增删规模、你实际阅读的范围和未审范围。随后只报告会改变正确性、安全性、数据完整性、兼容性或可操作性的具体问题。每条写标题、严重度、head 中的 path:line-range、相关函数或符号、触发前提、最小输入、预期结果、从代码推导的实际结果、影响和证据。

没有运行复现时明确写“静态推断，待复现”，并给出最小复现方案与需要我批准的精确命令。已经运行过的检查才可以写观察结果，同时附命令、退出码和关键输出。行号必须来自当前 head，并在草稿末尾重复 head SHA。没有可证明的问题时写“本轮未发现可提交意见”，再列出未覆盖的测试与文件。只输出本地审查草稿，不发布 review。

06｜行号必须和 head 提交绑在一起

一条意见只写“这里可能为空”还不够。草稿要给出 head 文件里的相对路径和最小行号范围，再补函数名或附近的代码语境。PR 更新后，同一段代码可能移到另一行，旧评论也可能脱离 GitHub 当前 diff。

每条草稿都带 head SHA。准备提交前重新运行 gh pr view 248 --json headRefOid，确认它没变。变了就让 Muse Code 基于新 head 重新核对，不能只手工改数字。GitHub 网页允许在 Files changed 的具体行开始 pending review；最后应当在网页中重新找到同一段代码，再放入评论。

07｜复现条件要写到另一个人能照做

静态阅读能提出怀疑，运行结果才能说明这次环境里发生了什么。先让 Muse Code 把复现计划写出来，计划至少包含操作系统和运行时版本、必要配置、初始数据、输入、精确命令、预期结果和需要观察的输出。涉及网络、密钥、数据库、迁移、外部服务或删除写入时，先别运行。

只在你有权使用的隔离环境中批准一条已知安全的项目命令。运行后记录原命令、退出码和足以支持结论的短输出。日志里若有令牌、用户资料或内部地址，先脱敏再放进草稿。没有条件运行时，保留“待复现”标签，别让模型把代码推演写成亲测结果。

• 触发前提写成具体状态，例如空缓存、并发两次请求或缺少某个可选字段。
• 输入给出最小值，避免让作者猜哪组数据会出错。
• 预期和观察分开写，观察一栏只收实际运行得到的内容。
• 测试命令对应固定 head，并注明是否只跑了单个测试。

08｜用一张固定卡片整理每条意见

把草稿限制在有行动价值的问题上。格式稳定以后，人能很快看出证据少了哪一块，也更容易删掉噪声和风格争论。

[P1] 空字符串令牌绕过重新加载 位置 src/session/check.ts:41-43 @ 9af3c2e 触发条件 token 是空字符串且旧缓存仍存在 最小复现 [环境、初始状态、输入和命令] 预期结果 空令牌走重新加载并返回新值 观察结果 [实际运行结果，或写静态推断待复现] 影响 [会影响谁以及错误会怎样出现] 证据 [diff 片段、测试输出或调用链] 未确认 [还缺什么信息]

示例中的文件和问题是虚构格式，只用来说明字段。实际意见必须来自当前 PR。严重度也要和仓库约定一致，拿不准就写成普通建议，别为了显得有把握随意升到阻断级别。

09｜草稿出来以后做一次反向检查

社区对 AI PR review 的抱怨很集中。一位 r/ExperiencedDevs 用户报告，工具给出的意见很少、漏明显问题或只提表面建议；讨论里也有人遇到大量无效意见和明明已经存在却被说成缺失的内容。它是个人讨论，不能代表所有工具，却提醒我们逐条验证比堆评论更重要。

让 Muse Code 对每条候选问题做反向检查。它需要搜索相关调用方、测试、配置默认值和已有保护，找出能推翻自己结论的代码。随后由你打开文件和 diff 验证。只剩猜测、无法指出触发条件，或建议超出 PR 范围时，就从待提交列表里删掉。

10｜最后在 GitHub 里由人决定

再次确认 head SHA、文件路径和行号。打开 GitHub 的 Files changed，读 PR 描述、相关 issue、检查结果和作者说明。GitHub 官方流程允许先把行级评论放进 pending review，直到你选择提交。把核准后的少量意见放进去，预览整组内容，再决定 Comment、Approve 或 Request changes。

Muse Code 的本地草稿不代表审查结论。CI 状态、领域规则、测试覆盖和仓库维护者的判断仍要由人处理。PR 更新以后，旧草稿要重新对照新差异。本文没有实测你的仓库，也不承诺这套流程能找到所有缺陷。

11｜交付前检查这八项

• PR 网址、base SHA 和 head SHA 已记录。
• 本地 HEAD 与 headRefOid 相同，工作区干净。
• 变更文件清单完整，未审范围单独列出。
• 每条意见都有当前 head 的文件和行号。
• 触发前提、最小输入、预期和影响都能看懂。
• 静态推断与实际运行结果已经分开。
• 复现命令、退出码和关键输出已核对并脱敏。
• GitHub 上的评论、批准和合并都由有权限的人完成。