代码审查风险

标记出高风险的合并请求,以便进行额外的人工审查。

运行这个演示 ▶获取 API key →

Jev 做出的决策

在一次调用中，Jev 针对同一份输入并行评估以下每一项：

scorerisk

按现状合并这个合并请求的风险有多大?

在一个有序量表上给它打分：

微不足道,可安全自动合并
低风险
需要仔细审查
高风险,可能引发线上事故

noultouches_money

这次改动是否涉及支付、账单或其他与资金处理相关的逻辑?

返回一个已校准的是/否概率。

choicerequired_reviewer

这次改动应指派给哪位审查者?

从这些选项中挑一个：

any — 任何同事都可以审查
senior — 应由一名资深工程师审查
payments_owner — 必须由支付代码负责人审查

确切的请求

这就是实时演示背后真实的载荷——复制它，改一下 state，你就开始构建了：

{
  "model": "jev-latest",
  "state": "合并请求标题:‘快速修复:提高支付重试上限’\n改动文件:services/billing/charge.py (+3 -1)\n描述:‘把最大重试次数从 3 提到 8,让失败的卡多重试几次,应该能降低流失率’。未添加测试。作者是首次贡献者。",
  "questions": {
    "risk": {
      "type": "score",
      "instructions": "按现状合并这个合并请求的风险有多大?",
      "criteria": [
        "微不足道,可安全自动合并",
        "低风险",
        "需要仔细审查",
        "高风险,可能引发线上事故"
      ]
    },
    "touches_money": {
      "type": "noul",
      "instructions": "这次改动是否涉及支付、账单或其他与资金处理相关的逻辑?"
    },
    "required_reviewer": {
      "type": "choice",
      "instructions": "这次改动应指派给哪位审查者?",
      "criteria": {
        "any": "任何同事都可以审查",
        "senior": "应由一名资深工程师审查",
        "payments_owner": "必须由支付代码负责人审查"
      }
    }
  }
}

把它接进你的代码

读取类型化的答案，用普通代码分支判断——无需解析。自动处理高置信度的情形，把不确定的路由给更大的模型或人工。这只是一次 API 调用，而且输出免费，所以把你需要的每个问题一次都问了吧。

构建你自己的

上面每个场景都是一次 API 调用。在 playground 里免费试用其中任意一个，然后拿一个托管 key 把它上线——无需 waitlist。

运行这个演示 ▶获取 API key →