PR解释器+理解测验

PR解释器+理解测验 是做什么的？

AI辅助编码让你很容易就批准了自己从未真正理解的代码。此技能以审阅者需要的水平解释变更，然后通过几个精准问题检查理解——这样“LGTM”才真正有意义。

1. 收集变更

选择适用的命令：

gh pr view <num> --json title,body,baseRefName,headRefName,files   # GitHub PR
gh pr diff <num>
git diff <base>...<head>                                            # 分支
git show <sha>                                                     # 单个提交

阅读PR描述和任何关联的issue。然后阅读受影响函数的周围代码（调用者、被调用者、测试）——仅看差异会隐藏重要的上下文。

2. 解释——按此顺序

1. 一段摘要：对用户或调用者的行为有何变化。不是文件列表。
2. 原因：描述/issue/提交消息中所要解决的问题。如果任何地方都没有说明原因，请明确指出——这是一个审查发现。
3. 图表：Mermaid的sequenceDiagram或flowchart，展示新的流程，突出显示新增/变更的部分（使用注释或:::changed class）。保持在约15个节点以内；为核心路径绘制图表，而非全部内容。
4. 按概念而非文件进行讲解：将相关的代码块分组（例如“重试逻辑”、“新配置标志”）。针对每个分组说明其功能以及任何非显而易见的内容（并发、错误处理、边界情况、性能）。
5. 风险说明：审阅者应重点关注的内容——变更的公共接口、迁移、删除的测试、被吞掉的错误路径、安全敏感代码、新分支缺少测试。使用file:line格式具体指定。

3. 测验

提出3-5个问题，一次一个，等待回答后再问下一个。好的问题需要理解而非记忆：

• “如果<依赖>在<操作>期间超时，现在会发生什么？”
• “哪个现有调用者会受到签名变更的影响？如何影响？”
• “为什么<行号>必须出现在<行号>之前？”
• “如果我们在迁移运行后回滚此更改，会破坏什么？”

避免琐碎问题（例如“新函数叫什么名字？”）。混合提问：至少一个关于失败/边界行为的问题，一个关于设计选择原因的问题。

每个回答后：指明是否正确，并用1-3句话和代码引用给出正确解释。如果他们在重要问题上答错，建议重新阅读差异的哪一部分。

4. 总结

给出分数（例如4/5）和一个简要结论：“可以审阅”，或者“在批准前重读X部分”。主动提出为任何发现的风险起草审阅评论。

根据请求调整范围

完整流程（摘要→原因→图表→讲解→风险→测验）是“带我过一遍”或“帮我审查”的默认模式。当用户缩小请求范围时，请尊重：

• “不要测验”/“跳过测验”：仅执行步骤1-2，跳过步骤3。
• “仅需摘要和风险”：只给出段落摘要和风险说明，不包含图表和讲解。最后用一句话提示是否提供其余内容。
• “仅需图表”：给出图表外加两句话说明。

列出的第一个风险应该是改变用户行为或金钱相关的风险（例如静默错误收费），而非技术上最有趣的风险。