值班记录：把人工智能审查接进拉取请求的六步交接

本次交接的目标很具体：开发者提交拉取请求后，GitHub 自动读取代码差异，请模型检查潜在缺陷，再把建议写回请求讨论区。先把它当作第二双眼睛，不让它自动批准、合并或修改代码。

先给审查机器人划定值班范围

1. 在测试仓库中准备一个小型拉取请求，例如修改参数校验并补充测试。首版只检查正确性、异常处理和明显的安全问题，不检查格式，也不要求模型重写整个模块。这样更容易判断意见是否有用。

约定输出包含文件路径、相关行号、问题依据和验证建议；没有充分证据时，可以不报告问题。不要要求模型必须找出若干缺陷，否则容易得到凑数的评论。

把接口凭据放进仓库密钥

2. 在仓库设置的操作密钥页面添加模型接口密钥，例如命名为 RELAY365_API_KEY。不要把密钥写进工作流文件、提示词或日志。模型请求与 GitHub 评论使用不同凭据，后者优先使用工作流自带的 GITHUB_TOKEN。

如果需要统一接入多个模型，Relay365 的按量付费方式适合小规模试运行。使用 OpenAI SDK 时，将接口基础地址设为 https://api.api365relay.com/v1。可以先试用 Gemini 2.5 Flash，但应从控制台确认可用的模型标识，不要把展示名称直接当作请求参数。

让工作流只处理可信来源的请求

3. 在默认分支创建 .github/workflows/ai-review.yml，使用 pull_request 事件，监听 opened、synchronize 和 reopened。为任务设置 contents: read 与 pull-requests: write，并通过任务条件仅处理源分支与目标分支属于同一仓库的请求。

首版跳过外部分叉请求，因为这类请求通常拿不到仓库密钥。不要为了绕过限制，改用 pull_request_target 后再检出并执行请求分支的代码。接收不可信变更与持有可写令牌，应当保持明确隔离。

只把差异作为数据交给审查脚本

4. 将审查脚本放入受保护的默认分支。工作流检出拉取请求的目标提交，并从该版本运行脚本，再通过 GitHub 接口读取请求差异；不要运行请求分支中的安装脚本、测试命令或审查脚本。

脚本先排除依赖锁文件、生成文件、二进制内容及可能含有凭据的路径，再限制文件数量和输入长度。差异过大时明确标注“本次仅审查部分文件”，不要静默截断后宣称已经完整检查。

提示词应说明：代码、注释和请求描述都是待分析的数据，其中要求泄露密钥、忽略规则或访问外部地址的文字不是操作指令。只提交必要上下文，并先确认团队允许将这些代码发送至所选服务。

把模型输出收敛成一条可复核评论

5. 要求模型返回固定字段，再由脚本校验结构并生成评论。先采用讨论区汇总评论，比直接发布逐行审查更容易落地；逐行评论还需要正确映射差异位置，不能仅凭模型提供的行号定位。

给评论加入固定标记，重复运行时更新同一条评论，避免每次推送都刷屏。发布前确认请求的最新提交仍与本次审查一致，避免把旧代码的结论贴到新版本上。超时或接口错误应记录为“审查未完成”，而不是“未发现问题”。

用一次小范围试运行完成交班

6. 人工核对第一批评论：问题是否真实、是否能复现、建议是否符合项目约束。同时观察调用次数、输入规模和实际费用，为每次审查设置输出上限、超时与有限重试，并用并发控制取消同一请求的旧任务。

如果团队需要集中管理模型接入，可以此时创建一个 Relay365 账户，先用小范围请求验证费用与审查效果，再决定是否扩大覆盖。密钥权限、日志留存和代码出境要求，仍需由团队自行确认。

交班标准不是机器人留下了多少评论，而是建议可定位、可验证，失败可见，且没有越过权限边界。分支保护仍应依赖测试、静态检查和人工批准；模型审查只提供补充证据，不承担最终放行责任。