← 所有用例
代码审查风险
标记出高风险的合并请求,以便进行额外的人工审查。
在线试用
这是真实的东西,不是模型演示。编辑输入、点击运行,Jev 会在一次往返中返回每一个类型化答案——免费、无需注册。现在想象同一次调用并行地跑在数千条数据上。
state — 软件传给 Jev 的输入119c
questions — 你想拿回的类型化决策
scorerisk
按现状合并这个合并请求的风险有多大?
→ 0…3 · 4 个等级
noultouches_money
这次改动是否涉及支付、账单或其他与资金处理相关的逻辑?
→ 概率 0.0 … 1.0
choicerequired_reviewer
这次改动应指派给哪位审查者?
→ 其中之一: any, senior, payments_owner
真实 API · 免费 · 无需注册
类型化、已校准的输出将显示在这里。
选一个示例,调整输入,然后点击 运行 Jev.
选一个示例,调整输入,然后点击 运行 Jev.
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 调用，而且输出免费，所以把你需要的每个问题一次都问了吧。