← Retour aux guides

用 LLM 自动审查 Pull Request 的 7 个实战技巧

用 LLM 自动审查 Pull Request 的 7 个实战技巧

LLM 适合做 Pull Request 的第一轮审查：快速发现空指针、权限遗漏、异常处理缺失、测试盲区和可读性问题。但要让它真正进入工程流程，关键不在于“把 diff 发给模型”，而在于控制上下文、输出格式和自动化边界。

• 1. 只发送必要的变更上下文。优先获取 PR 的 unified diff，并附上修改文件路径、语言、相关测试文件和仓库编码规范。超大 PR 不应一次塞进模型；按文件或逻辑模块切分，再让模型输出可合并的结论。这样能降低 token 消耗，也能减少模型把无关代码当成问题的概率。
• 2. 先定义审查优先级。提示词应明确要求模型优先检查安全、数据一致性、并发、错误处理和回归风险，其次才是命名与格式。要求它忽略纯格式差异，避免 CI 评论区被低价值建议淹没。对于每个问题，规定输出严重级别、文件、行号、原因和可执行修复建议。
• 3. 用结构化 JSON 接住模型结果。让模型返回 problems 数组，每项包含 severity、path、line、title、reason、suggestion。CI 脚本解析 JSON 后，只将 high 和 medium 问题回写为 PR 评论，low 问题汇总到检查结果。这比直接发布一大段自然语言更稳定，也方便后续统计误报率。
• 4. 给模型补充“局部真相”。仅有 diff 时，模型常不了解函数调用链和业务约束。针对每个变更文件，额外提供被修改函数、接口定义、配置项说明及相邻测试；涉及鉴权、支付、删除操作时，再补充明确的不变量，例如“非管理员不能读取其他租户数据”。
• 5. 把测试建议变成可验证任务。要求 LLM 不只说“建议补测试”，而是指出缺失场景、输入、预期结果和应修改的测试文件。例如新增分页参数时，应覆盖默认值、边界值、非法值及排序稳定性。团队可以将这些结果转成待办，或让模型生成测试草案后由开发者确认。
• 6. 在 CI 中设置成本与失败保护。只在打开 PR、推送新提交或添加特定标签时触发审查；为每次运行设置文件数、diff 字符数和超时上限。模型调用失败时不应阻断合并，改为报告“自动审查未完成”，并保留人工审查流程。对敏感仓库还应先过滤密钥、令牌和生产数据。
• 7. 用低成本模型做分流，再升级复核。常规变更可先用快速模型进行筛查，检测到安全、数据库迁移或复杂并发逻辑时，再交给更强模型复核。59API 提供按量付费的 Claude Opus、Sonnet、Haiku、Fable 和 GPT 模型，并兼容 Claude Code、Codex 与 OpenAI SDK；将 base URL 配置为 https://api.59api.com 后，现有调用通常只需替换端点与密钥。官方质量模型与较低的中转成本，适合把 PR 审查从偶尔试用变成每次提交都能运行的工程能力。

最后，把自动审查当作辅助审查员，而不是合并批准人。每月抽样检查模型评论的采纳率、误报类型和遗漏问题，再迭代提示词与规则。需要为团队建立低成本 LLM 审查流水线时，可注册 59API，按实际调用量接入，并利用推荐返利进一步控制长期预算。

Tarifs · Docs