利用GitHub Copilot API实现PR自动审查评论，核心思路清晰：通过API分析变更文件并生成精准反馈，避免人工逐行审查时遗漏关键问题。简而言之，让机器人自动审查代码，并将意见直接贴在代码旁边，方便开发者一键采纳或展开讨论。

配置GitHub Actions工作流触发PR事件

首先，在仓库根目录创建 .github/workflows/copilot-review.yml 文件。关键在于 on.pull_request.paths 要指定只监听 src/ 和 tests/ 目录下的变更——这样能大幅减少无关文件触发的API调用次数，有效节省计算资源与成本。

权限方面，permissions: contents: read 和 pull-requests: write 缺一不可。前者确保机器人能读取代码内容，后者则是提交评论的通行证。如果遗漏了 pull-requests: write，评论会悄然失败，连明确的报错提示都不会出现，排查起来非常耗时。

获取变更文件并提取待审查代码块

接下来，需要获取变更文件并提取待审查的代码片段。使用 git diff 对比base和head分支，配合 --name-only 参数获取所有修改文件的路径清单。

对每个变更文件，关键操作是用 git show HEAD:【文件路径】 提取最新版本内容，再结合diff补丁信息精准定位新增或修改的行范围。这里有一个常见陷阱：不要直接读取工作区文件，否则可能因未提交文件或忽略规则导致内容不一致，进而使审查意见偏离实际。

每处变更，最终应封装为一个标准对象结构：{filename, line_start, line_end, content}。这个结构是后续API请求的基本输入单元，每个单元对应一个待审查的代码片段。

调用Copilot API生成审查意见

调用Copilot API，有两种主流实现方式。

方法一： 使用最新的 @github/copilot-sdk 包，发送POST请求到 https://api.github.com/copilot/review，body中传入 language（例如"python"）、code（变更代码片段）、context（前5行和后5行上下文）。这种方式封装友好，推荐优先采用。

方法二： 如果SDK暂时不可用，可直接构造裸HTTP请求，携带 Authorization: Bearer 【GITHUB_TOKEN】。注意，header中必须包含 Accept: application/vnd.github.v3+json，否则会返回406错误，容易让开发者无从下手。

API返回结果后，建议进行一轮过滤：只保留置信度在0.7以上、且 severity 为"high"或"medium"的建议。低置信度的评论容易引发开发者质疑，长期来看会削弱整个自动化审查的可信度。

在PR对应位置发布内联评论

最后一步，将过滤后的审查意见精准贴到PR的对应位置。

第一步： 调用GitHub REST API的 POST /repos/{owner}/{repo}/pulls/{pull_number}/comments 接口，传入 body、path、line三个参数。这里有一个容易出错的细节：line 必须是变更文件中实际存在的行号，而非原始文件的行号，否则评论会悬浮到错误位置，完全失去意义。

第二步： 对每条Copilot返回的建议，提取其建议修改后的代码片段，用 ```suggestion 格式包裹。GitHub会将此格式渲染为一个可一键采纳的编辑框，开发者点击即可直接应用修改，体验极佳。

第三步： 批量提交全部评论，避免逐条发送，否则容易触发GitHub的速率限制。如果某条评论因 path 不存在而失败（例如文件被重命名或删除），直接跳过该条，继续处理剩余项即可。