生产使用场景

用于代码审查的 LLM API

一个 Pull Request 修改了鉴权中间件。审查服务把 Diff、附近函数、仓库安全规则和变更行映射发送给 codex-auto-review，模型只能返回能够说明具体故障路径的发现。

用于代码审查的 LLM API

生产方案

API、主模型与故障切换配置

生产选择	推荐配置	原因
API	POST /v1/chat/completions	从服务端发送 OpenAI 兼容请求
主模型	codex-auto-review	codex-auto-review 是当前模型广场中专门面向自动代码审查的首选路由。
备用模型	gpt-5.6-terra	需要更广仓库推理时使用 Terra；只有存在争议的高风险发现才升级到 Sol，而不是所有普通 PR。
升级模型	gpt-5.6-sol	只有主路由越过已定义的质量或复杂度边界时才使用
输出契约	经过验证的 JSON	JSON 发现列表：文件、行号、严重程度、标题、证据、故障路径和修复建议。

业务场景

代码审查在生产应用中的实际场景

没有文件、变更行、严重程度、证据和修复建议的评论会被服务丢弃。评估集中包含干净 PR，因此评论更多并不代表审查更好。

应用架构

代码审查工作流怎样运行

生成 Diff 和变更行映射。
只检索直接相关代码与仓库规则。
要求返回带证据和最小行范围的结构化发现。
丢弃格式错误和无依赖证据的 Diff 外评论。
把通过过滤的发现展示给人工审查者。

API 请求

通过 LLMFly AI 调用 codex-auto-review

请求应从服务端发送。请将示例内容和占位工具 Schema 替换为应用中的真实数据与工具。

request.example可复制示例

curl https://app.llmfly.ai/v1/chat/completions \
  -H "Authorization: Bearer $LLMFLY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "codex-auto-review",
    "messages": [
      {"role": "system", "content": "Review the supplied diff. Report only actionable defects introduced by this change. Each finding needs file, changed line, severity, failure path, evidence, and a minimal fix."},
      {"role": "user", "content": "Review this authentication middleware pull request against the attached repository rules."}
    ],
    "response_format": {"type": "json_object"}
  }'

模型选择

为什么主模型选择 codex-auto-review

codex-auto-review 是当前模型广场中专门面向自动代码审查的首选路由。

需要更广仓库推理时使用 Terra；只有存在争议的高风险发现才升级到 Sol，而不是所有普通 PR。

验收

代码审查的验收条件

指标	通过条件
真实缺陷召回率	能够发现测试集中预先植入的高风险缺陷
误报率	干净对照修改不会收到阻断性或编造的发现
行级定位准确性	每条发现定位到最小相关行范围，并解释故障路径
审查者采纳率	合格审查者认为评论正确、可执行且值得展示

失败处理

上线前必须处理的失败情况

以评论数量作为奖励
只测试有问题的样例
接受模糊的最佳实践建议
无证据地评论变更范围外代码

输出

返回结果与运行记录

JSON 发现列表：文件、行号、严重程度、标题、证据、故障路径和修复建议。

每次生产运行都应记录模型 ID、Request ID、Token 用量、重试、验证结果和最终处理状态。

常见问题

如何衡量误报？

加入干净修改，并统计被合格审查者判定为错误或不可执行的发现。

代码审查需要整个仓库吗？

不一定。先提供 Diff 和直接相关文件，需要时再检索更多上下文。

什么输出格式更合适？

使用包含文件、行号、严重程度、解释、证据和修复建议的 Schema。

使用你的真实输入测试这套方案

让主模型和备用模型使用相同请求、工具和验证规则。

比较模型