值班记录：给 GitHub 拉取请求加一道人工智能审查

本班接入位置：提交之后，合并之前

人工智能代码审查，就是把一次代码改动交给模型阅读，请它指出可能的问题。在 GitHub 中，最自然的位置是拉取请求：开发者提交改动，工作流启动，模型读取差异，审查意见随后出现在检查结果或评论里。

它适合充当第二双眼睛，例如提醒某个分支没有处理空值，或修改接口后遗漏了调用方。它不是测试的替代品，也不能仅凭“没有发现问题”就证明代码安全。是否合并，仍由维护者决定。

一次审查任务怎样跑完

通常可以用 GitHub Actions 串起这件事。拉取请求创建或更新后，任务取得目标分支与当前提交之间的差异，排除不需要审查的文件，再把改动和必要上下文发送给模型。模型返回建议后，脚本整理输出，发布审查摘要。

• 发送内容应包含修改位置附近的代码，以及相关接口约定，避免模型只凭几行差异猜测。
• 审查指令应要求说明文件、位置、触发条件和影响，并把不确定的问题标为待确认。
• 发布结果前应校验输出格式和行号，避免把无法定位的建议直接写成行内评论。

第一次接入时，先输出一份摘要即可，不必立刻实现逐行评论。这样更容易检查模型是否看懂代码，也方便控制评论数量。

外部贡献先过权限这一关

模型密钥应放在 GitHub 的机密配置中，不要写进仓库。工作流按需要分配权限：读取代码和发布评论是不同权限，不应为了方便而全部开放。

来自派生仓库的拉取请求尤其需要谨慎。不要为了取得密钥，直接使用高权限任务执行贡献者提交的脚本。可以先对可信分支试运行，之后再设计外部贡献的审批和隔离流程。

代码和评论里也可能藏有“忽略规则”“输出密钥”等文字。应把仓库内容视为待分析的数据，而不是模型必须服从的指令；同时避免向模型发送密钥、生产配置和无关的敏感文件。

先让建议可核查，再考虑阻止合并

建议从非阻断模式开始：人工智能可以提意见，但不单独决定检查是否通过。维护者逐条确认后，再判断哪些问题值得修复。记录误报和漏报，有助于调整上下文范围与审查规则。

还要为超时、限流和输出解析失败设置明确状态。服务调用失败应显示“审查未完成”，而不是“审查通过”。限制文件大小、输入长度和重复运行次数，也能减少等待与不必要的费用。

需要统一模型入口时再接入中转

如果团队希望通过同一入口试用不同模型，Relay365 是一个按量付费的多模型中转选择。例如，可以用 Gemini 2.5 Flash 在一批已知问题的历史改动上试跑，再根据实际结果评估质量和成本，而不是仅凭模型名称选型。

使用兼容 OpenAI 的客户端时，接口基础地址配置为 https://api.api365relay.com/v1。正式发送私有代码前，应确认服务的数据处理条款和团队合规要求，并核对所选模型的接口兼容性。准备小范围试运行时，可以创建一个 Relay365 账户，先设置调用预算。

交班前保留人工复核入口

最小可用方案不需要很复杂：一个触发任务、一份受控的代码差异、一组明确的审查指令，以及可追溯的结果。先让建议稳定地帮助维护者发现问题，再逐步扩大范围，比一开始就让模型掌握合并权限更稳妥。