有人工审查员的团队

HeyDeer 承担的工作

• 细节和边界情况。HeyDeer 会在每个 PR 上检查错误处理、边界值、并发，以及被改动破坏的调用方。
• 减轻审查员的负担。审查员不再需要逐行排查错误，可以把时间和精力留给只有他们才能做出的决策。
• 细节上更准确。在 1000 个内部 PR 上，HeyDeer 对细节正确性的审查比人工审查员更准确。

推荐配置

1. 审查每次推送。在“工作区设置 → 审查规则”中，将“审查时机”设为“每次推送时审查”。参见自动审查。
2. 发现问题时让检查失败。在“发布结果”下，开启“发现问题时将检查标记为失败”。参见 HeyDeer Review 检查。
3. 在 GitHub 中将检查设为必需。在 main 的分支规则中，开启“Require status checks to pass before merging”并添加 HeyDeer Review。这样，PR 只有在发现的问题都已修复或被决定不处理后才能合并。
4. 在 HeyDeer 的结果基础上开始人工审查。请审查员在 PR 的检查通过后再打开它，并把时间花在设计、产品行为，以及 HeyDeer 标记为需要人来判断的内容上。

可选：自动批准常规变更

开启自动批准，并将“需要人工批准的变更”保持为“重大架构和关键行为变更”。这样，常规 PR 在没有遗留问题后由 HeyDeer 批准；重大变更则留给人处理，HeyDeer 会说明哪项决策需要人来做出。

如果分支规则要求 1 个批准，常规 PR 无需等待审查员即可合并。请开启“Dismiss stale pull request approvals when new commits are pushed”，确保每个批准都针对最新代码。

将团队标准写成检查

审查员在评论中反复强调的规则，应该写成检查。为每条规则在 .agents/checks/ 中添加一个 Markdown 文件，HeyDeer 会将它应用到每个修改了匹配文件的 PR。参见仓库检查。

.agents/checks/migrations.md

---
files: "migrations/**/*.sql"
---
The previous release keeps running while a migration
deploys. Report a migration that:

- drops or renames a table or column that code on the
  base branch still uses;
- adds a NOT NULL column without a default;
- creates an index on an existing table without
  CONCURRENTLY.