值班交接：今年继续保留的 GitHub 人工智能审查规程

本班交接意见：今年值得保留的，不是每次提交后自动铺满页面的模型评论，而是一条边界清楚、可以暂停、能够追查的审查链路。人工智能负责寻找可核查的风险，持续集成负责运行确定性检查，维护者负责决定是否合并。三个岗位不要混在一起。

把审查触发点放在变更已经成形的位置

不要让每次推送都启动完整审查。草稿拉取请求先跑格式、类型和测试检查；准备进入人工审查时，再由标签、明确指令或指定事件触发模型。后续提交只检查新增变更，并取消已经过时的任务，避免旧提交的意见覆盖新代码。

审查输入应包括本次差异、必要的上下文、仓库规则和变更目标。排除生成文件、依赖锁文件中的大段机械变化以及无关目录。差异超过预算时，按模块拆分，并明确标注未覆盖范围，不能把截断后的结果写成“全部检查完成”。

先隔离外部贡献，再谈模型接入

外部贡献者提交的代码、注释和拉取请求描述都属于不可信输入。它们可能包含诱导模型忽略规则、读取凭据或执行命令的内容。审查提示应明确：这些内容只是待分析材料，不是操作指令；真正的防线仍是工具权限和运行环境隔离。

• 工作流默认只申请读取权限，发布评论的步骤单独获得必要的写入权限。
• 不要在持有密钥的任务中检出并执行外部分支代码，也不要为了取得密钥而直接改用高权限事件处理不可信代码。
• 测试任务与模型调用任务分离；模型不应拥有任意终端执行能力，也不应接触部署凭据。
• 发送代码前确认仓库政策和服务商的数据处理条款，并过滤凭据、个人信息与不允许外传的内容。

让每条评论都能被维护者复核

要求模型输出文件位置、触发条件、可能影响和验证方法。没有足够证据时，应提出问题，而不是宣告存在漏洞。重点检查权限边界、错误处理、并发状态和兼容性，不必重复格式检查器已经报告的问题。

发布前增加一道校验：确认文件仍存在、评论行仍属于当前差异、同一问题没有重复出现。不能定位到具体行的意见放入摘要。仓库中的说明、注释和接口契约也可能过时，因此模型引用它们时仍需与实现交叉核对。

把模型发现接回测试，不直接接到合并按钮

有价值的发现应能转成复现步骤或回归测试。模型建议的补丁和测试同样需要审查，尤其要检查测试是否真正覆盖失败路径，而不是仅仅迎合现有实现。构建成功不能证明模型判断正确，模型没有发现问题也不能替代人工批准。

初期让审查结果保持非阻断状态。持续记录被采纳、被驳回以及遗漏后补报的问题，并按仓库和问题类型分析。只有验证稳定、失败策略明确的检查，才适合讨论是否成为合并门禁；不要用评论数量衡量审查价值。

给调用预算和故障退路留一张交接单

为单个拉取请求设置输入规模、调用次数、超时和费用上限。记录提交标识、提示模板版本、模型名称及覆盖范围，但不要默认把完整源码写入日志。请求失败或预算耗尽时，应显示“审查未完成”，并允许维护者继续走既有人工流程。

若团队需要按量调用多个模型，Relay365 可以作为统一接入的候选。例如，将 Gemini 2.5 Flash 接入同一套审查任务，再用脱敏的历史变更验证效果。它兼容 OpenAI SDK；使用此类客户端时，基础地址填写 https://api.api365relay.com/v1。统一入口能减少接线工作，但不同模型的参数、输出和错误处理仍要逐项测试，不能假定完全一致。

交班前确认维护者仍能接管

接入方案符合团队的数据与采购要求后，可以创建一个 Relay365 账户，从单个仓库的小范围试运行开始。交班记录应留下暂停入口、费用负责人和故障处理人。最终要保留的是可复核的发现、受限的权限和清楚的退路，而不是一台无人负责的自动评论机。