用 HeyDeer 修复

发起修复

1. 在 GitHub 审查评论中选择“用 HeyDeer 修复”，或在 HeyDeer 审查页面选择“修复发现的问题”。从单个问题的链接进入时，会预先选中该问题。打开页面不消耗积分。
2. 选择要处理的问题。如果某个问题需要补充背景，例如希望采用的方案或需要保留的行为，可选择“添加指令”。
3. 使用选择列表下方的按钮发起修复。任务页面会显示进度、已用积分和结果。如果这个 PR 已有修复任务在运行，选择“查看修复”即可打开。

列表包括该 PR 历次审查发现的问题，以及仍需处理的先前问题。讨论中已明确决定不处理的问题不会列入。HeyDeer 会根据保存的代码版本重新检查所选问题，并可能跳过已不适用的问题。

检查并合并修复

HeyDeer 会创建新分支，并发起以原 PR 分支为目标的 PR。阅读摘要，再通过“查看修复 PR”检查代码修改。由你决定是否将修改合并到原 PR。

如果无需修改代码，任务可能直接完成，不会创建 PR。

摘要会说明代码修改、跳过的问题、本地测试结果，以及 HeyDeer 未能运行的检查。合并修复后，在原 PR 上发起后续审查，或等待自动审查按设置运行。仅创建修复 PR 不会解决审查中的问题，也不会让 HeyDeer Review 检查通过。

要求与限制

修复需要 PR 处于打开状态、两个分支位于同一仓库，并由具有仓库写入权限的人发起。暂不支持 Fork PR。HeyDeer 需要 Contents 和 Pull requests 的读写权限，详见GitHub App 与权限。每个 PR 同时只能有一个修复任务在运行。

HeyDeer 无法发布对 .github/workflows/ 中 GitHub Actions 工作流文件的修改。包含这类修改的修复会在发布任何文件之前停止。

本地检查与 CI

发起修复后，HeyDeer 可以在能够访问公网的隔离沙箱中修改代码、安装依赖并运行本地检查。它会使用工作区和仓库指令，以及仓库中的指引，但不会连接你的 MCP 服务器。代码执行的隔离方式详见安全。

你的 GitHub 自动化流程可能会在修复 PR 上运行。如果工作流只针对 main 等目标分支，可能要等修复合并到原 PR 后才会运行。HeyDeer 不会等待 CI，也不会在 CI 失败后自动重试修复。

积分与取消

修复使用工作区积分，并与审查共用并行执行容量。每次修复按当前标准审查的最低费用计费，再根据实际工作量消耗积分。工作区用量上限同样适用。详见积分如何使用。

在 HeyDeer 开始向 GitHub 保存修改之前，具有写入权限的人可以选择“取消修复”。智能体启动前的准备阶段不收费；启动后取消，仍会扣除最低费用和已使用的积分。积分耗尽时修复会停止，需要重新发起。

原 PR 发生变化时

修复使用发起时保存的提交和分支。后续提交或关闭原 PR 不会取消任务，合并前请检查是否存在冲突。如果目标分支被删除或重命名，可通过“查看修复提交”检查已保存的修改，再决定如何应用。