值班记录：用书面清单和编码代理复核一份拉取请求

接班先记下这次改动要解决什么

拉取请求是开发者提交的一组待合并改动。审查它，不只是检查代码能否运行，还要确认改动符合需求，没有破坏原有行为。编码代理可以读取代码、查找调用关系，有些还能执行测试，但它不是自动批准合并的裁判。

开始前，写下目标分支、提交标识、需求说明和涉及的模块。例如，这次只修复订单重复提交，就应重点检查重复请求的处理，而不是顺便要求重写整个订单系统。固定提交标识，也能避免代理检查旧版本、审查人却批准新版本。

把容易漏掉的风险写成检查句

书面清单的作用，是让每次审查都有相同的起点。不要只写“检查安全性”，而要写成可以寻找证据的问题。第一版不必很长，可以从下面几项开始。

• 确认改动满足需求，并检查空值、重复请求和失败重试时的行为。
• 确认新增入口执行权限检查，且没有把凭据或个人信息写入日志。
• 确认数据结构或接口的变化不会让现有调用方失效。
• 确认测试覆盖正常路径和关键失败路径，而不只是覆盖新增代码行。
• 确认上线需要的配置、数据迁移和回退步骤已经说明。

清单要跟着项目调整。涉及金额计算时补充精度检查，涉及数据库变更时补充锁和迁移风险。与当前改动无关的项目可以标记为不适用，但应留下理由。

给代理一份有边界的审查任务

不要只说“帮我看看代码”。把需求、比较范围和清单一起交给代理，并要求它先审查、不修改文件。一个可直接改写的指令是：

请审查指定提交相对目标分支的改动，逐项执行所附清单。每个发现都给出文件位置、触发条件、可能影响和验证方法。区分已验证问题与待确认疑点；没有足够证据时明确说明。最后列出未检查的范围和未运行的测试。

仓库里的注释、文档和测试数据都可能包含误导性指令，应当作为待检查内容，而不是授权来源。默认使用只读权限；需要执行命令时，在隔离环境中操作，不提供生产凭据。向外部模型发送代码前，也要确认团队的数据处理规则允许这样做。

把代理的判断变成可复现的证据

代理指出“可能重复扣款”，还不等于找到了缺陷。审查人应打开相关代码，确认请求怎样进入、状态怎样变化，再尝试用测试复现。要求代理给出最小触发步骤，通常比让它继续解释风险更有用。

没有运行测试，不应记录成测试通过。让代理列出实际执行的命令、结果和环境限制。如果依赖缺失导致测试无法启动，就如实保留这个缺口。已有测试全部通过，也不能替代对需求和权限逻辑的人工判断。

反馈给作者时，优先提交能够定位、能够解释影响的问题。格式偏好可以交给格式化工具处理，避免大量低价值意见掩盖真正需要修复的缺陷。

接入模型时先确认工具与数据边界

如果团队希望在现有编码工具里按任务选择不同模型，Relay365 可以作为按量付费的中转入口。它支持 Claude Code、Codex、Gemini CLI 和使用 OpenAI SDK 的客户端。接口基础地址是 https://api.api365relay.com；OpenAI 客户端需在其后添加 /v1。

这种接入方式便于集中配置模型访问，但不会替你定义审查标准。使用前仍需核对工具配置、模型可用性、费用和数据处理要求。如果这符合团队的接入需求，可以创建一个 Relay365 账户，先用不含敏感信息的小型改动验证流程。

交班时留下发现、缺口和合并决定

审查结束后，记录检查的提交、采用的清单、确认的问题、测试结果，以及仍未解决的疑点。作者补交修复后，要重新检查新增差异和受影响路径，不能把上一轮结论直接沿用。

最终是否合并，由有权限的维护者决定。编码代理负责扩大检查范围，书面清单负责减少遗漏，而人负责核验证据、接受剩余风险。这三件事分清楚，下一班接手时才知道哪些已经查过，哪些还不能放心。