最佳实践

没有代码审查的团队

如果改动在无人阅读的情况下进入 main（因为智能体直接提交到 main，或 PR 在 CI 通过后即合并），就让 HeyDeer 来承担审查。这样，HeyDeer 批准后，PR 会自动合并。

风险

CI 只能发现测试覆盖到的问题。没有审查，有两类问题会被漏掉：

模型偏见。编写代码的模型往往会认同自己的推理、忽略自己的错误，即使你要求它检查自己的工作也是如此。
反复修改引入的错误。智能体一次次修改同一段代码时，每次改动都可能悄悄破坏之前已经正确的部分。

HeyDeer 带来什么

独立的意见。HeyDeer 独立于编写代码的智能体审查每个 PR，并在发布每个发现的问题之前对照代码进行验证。
专门的审查流程。每次推送都会得到审查，后续审查会重新检查此前的问题，HeyDeer Review 检查则在每个提交上记录结果。

推荐配置

智能体创建 PR

HeyDeer 审查每次推送

检查通过，HeyDeer 批准

GitHub 合并 PR

如果 HeyDeer 发现问题，检查会失败，PR 不会被合并。智能体推送修复后，HeyDeer 会审查新提交。

每项改动都创建 PR。让智能体推送到分支并创建 PR，而不是直接提交到 main。
审查每次推送。在“工作区设置 → 审查规则”中，将“审查时机”设为“每次推送时审查”。参见自动审查。
发现问题时让检查失败。在“发布结果”下，开启“发现问题时将检查标记为失败”。参见 HeyDeer Review 检查。
开启自动批准。在“发布结果”下，开启“自动批准”。完整审查后没有遗留问题时，HeyDeer 就会批准 PR。重大架构和关键行为变更仍需等待人工批准；如果这些变更也要自动批准，请将“需要人工批准的变更”设为“不额外限制变更类型”。参见自动批准。
在 GitHub 中保护 main。在 main 的分支规则中，开启“Require a pull request before merging”并要求 1 个批准，同时开启“Dismiss stale pull request approvals when new commits are pushed”。然后开启“Require status checks to pass before merging”，除 CI 检查外，再添加 HeyDeer Review。
自动合并。在仓库的 GitHub 设置中开启“Allow auto-merge”。然后为每个 PR 启用自动合并，或让智能体在创建 PR 后运行 gh pr merge --auto --squash。

HeyDeer 批准了这些变更

所有检查均已通过

HeyDeer Review — 审查完成，未发现问题必需

CI / test — 成功必需

已开启自动合并：满足所有要求后，GitHub 会合并此 PR。

HeyDeer 批准且所有必需检查都通过后，GitHub 会合并 PR。

将团队标准写成检查

规则由审查强制执行时，智能体会更可靠地遵循它。为每条规则在 .agents/checks/ 中添加一个 Markdown 文件，HeyDeer 会将它应用到每个修改了匹配文件的 PR。参见仓库检查。

.agents/checks/tenant-scope.md

---
files:
  - "src/db/**/*.ts"
  - "!**/*.test.ts"
---
Every query that reads or writes customer data must be
scoped to one tenant, taken from the request context and
never from request parameters.