应用场景
代码评审风险
标记那些不做安全审查就不该合并的 diff。
问题
评审员走马观花。一条“debug 日志把密码打出来”的变更会在周五溜进主干。
代码拿到答案后怎么做
当 `ship` 低或风险落入最高档时，阻止合并。
每次合并都该付得起的两个问题
diff 就是 state；ship 询问能否不经安全审查直接合并（yes/no），risk 则把严重度分级为 装饰性 → 需跟进 → 阻止合并。示例 diff — 把密码哈希换成自制的 XOR 辅助函数、并把明文“为调试”打进日志 — 是教科书案例：风险爬进阻止合并的区间而 ship 读出低值，CI 检查正是据此拦截。
评审员想要的检查
从 CI 对每个 PR 调用：ship 低于你的线或 risk 落入最高档时拦截；介于其间安静评论；其余放行。一次拦截型类型化调用花 1 积分、省下评审员的注意力，拦住那种“赶时间改出来的 diff”，后者通常在周五上线混过去。先在 playground 用合并历史里的五个真实 diff 验证 — 生成的原型和 lockfile 变动需要在闸门开启前配置豁免路径。
合并闸门专属的坑
闸门读的是 diff，不是周围的系统 — 单独看安全但组合起来是灾难的变更（一个去掉限流的提交撞上另一个待合并的 PR）需要把上下文放进 state 或让人类在环。绝不让闸门对拿不准的 diff 静默放行：有分歧的分数要给一条评论，而不是沉默。“可安全合并”的 criteria 措辞必须与你真实的合并政策一致 — 如果鉴权路径一律要评审，就把这句写进去。
请求结构
这是 playground 为该预设发送的完整请求 — 与你的服务器带 Bearer key 发往 /v1/systemone 的 JSON 相同。
curl
curl https://jevai.website/api/v1/systemone \
-H "Authorization: Bearer $JEV_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": "diff: replace password hashing with a custom XOR \"encrypt\" helper and log the plaintext password \"for debugging\".",
"questions": {
"ship": {
"type": "noul",
"instructions": "Is this change safe to merge without a security review?"
},
"risk": {
"type": "score",
"instructions": "How severe is the security impact?",
"criteria": [
"Cosmetic",
"Needs follow-up",
"Blocks the merge"
]
}
}
}'关于此用例的常见问题
- 对生成代码的误报怎么办？
- 在调用之前收紧 criteria 或在 CI 豁免路径。一条吵闹的路径是配置修复；一个吵闹的模型需要重写 criteria。
- 这是一个安全声明吗？
- 不是 — 它是一个分诊信号。它不能替代安全评审；它是在人类为评审付出代价之前，判断是否需要那次评审。
- 小 diff 也要跑吗？
- 要，便宜而快 — 但跳过来源明确的机器生成 diff；闸门读的是有风险的变更，不是在调度已知的机器人。