易于审查的 PR

让每个 PR 保持聚焦

只做一件事的 PR，得到的也是关于这件事的问题。把重构、重命名和文件移动与行为改动分开，否则它们会淹没真正改动的代码行。

说明意图并关联 Issue

HeyDeer 会阅读标题和描述。请说明改动的目的、你最没把握的部分，以及有意未包含的内容。如果作者拥有写权限，像“重试不在本次范围内；已在 #412 中跟踪”这样说明的取舍会被视为一项决定，与决定不处理发现的问题相同。

也请关联 Issue。开启“读取关联 Issue”（默认开启）时，HeyDeer 可以读取它，了解改动应满足的需求。参见 HeyDeer 读取的内容。

标记生成文件

在 .gitattributes 中用 linguist-generated 标记生成的代码，HeyDeer 就会跳过它。HeyDeer 从基础分支读取该属性，因此请先在单独的 PR 中合并这项改动。

迭代期间先创建草稿

自动审查默认会跳过草稿，在你将 PR 标记为可供审查后才会考虑它。如需尽早获得反馈，请在草稿上评论 @heydeer review。参见审查筛选条件。

以新提交的形式推送修复

后续审查会查看自上次审查以来的改动，修复以新提交的形式推送时效果最好。合并目标分支或变基到目标分支都没有问题。把相关的修复一起推送，可以减少自动审查次数。参见后续审查。

回复你决定不处理的问题

在讨论中回复并说明理由，而不只是写“不修复”，或者将讨论标记为已解决。有写权限的人做出的决定会告诉 HeyDeer 不要再提出该问题。参见减少噪音。