Jev 生态观察（六）：代码质量评测——谁真金白银跑过数字，谁只是声称
生态里「用 Jev 做代码质量评测」的项目数十个，但真正跑过对照实验、公布成本与准确率的只有几个。我们拆了 agentjournal 的五发现实验、Supercov 的机械性教训和 Jev Review 的分阶段评审，给出什么场景该用、什么场景不该用的判断。
上一篇讲了决策原语的信任边界。这一篇深潜生态里最大的声称场景之一：代码质量评测。「用 Jev 来评审代码」「用它给 PR 打分」「让它判断测试是否充分」——这类项目在发布 72 小时内就冒出数十个，但真正做了对照实验、公布了成本数字和准确率边界的只有几个。本文只引用跑过数字的项目，不收口头声称。
为什么代码质量是 Jev 的天然场景
代码评审的三个特征恰好命中决策原语的甜点区：判断窄（这段代码是否满足某个具体标准）、高频（每次提交都需要）、输出可分支（通过/不通过/需修改）。传统 LLM 评审需要几十秒的推理，塞不进 CI/CD 流水线；Jev 的亚秒级延迟让「每次提交都评一遍」第一次在经济上成立。
但「天然场景」不等于「自动正确」。生态里的独立评测量化了几个关键边界。
agentjournal：$1.43 买来的五个发现
agentjournal 的评测是发布第一周里最扎实的一组对照实验——三个分类任务、5,477 个测试行、总成本 $1.43。五个发现里三个直接冲击代码质量场景：
第一，拆维度不总是更好。简单任务（200 条带陷阱的 B2B 回复）直问 100% 准确，拆 12 个维度反而降到 98%——多花的 token 买来了更差的结果。对代码评审的启示：如果你的判断标准已经很明确，不需要拆成多维度分别评。
第二，宽选项会崩。真实记账数据上，一次 Choice 给 12 个选项只有 39.98% 准确率。对 PR 分类的启示：不要让模型从十几个可能的修改类别里选一个，拆成多个是非题。
第三，置信度与正确性脱钩。在模型报告高置信（≥0.9）的行上，准确率只有 72.2%。对 CI 门禁的启示：不能把高置信当作通过的充分条件。
Supercov：作者把评审问题收窄到机械性检查
Supercov 是一个 Rust 写的代码质量评分工具，作者在 Reddit 上分享了被广泛引用的教训：扔整个文件问「质量如何」效果很差；只问机械性问题（duplicated_code、deep_nesting）就能追平商业工具、便宜 100 倍（作者自评，非独立基准）。
这条教训的实质是：Jev 的判断质量取决于你问的问题是否足够具体。
Jev Review：分阶段评审
Jev Review（2026-09-21 快照 417★）把代码评审拆成多个阶段——先判结构，再判逻辑，再判风格——每个阶段用不同的 Noul/Score 问题集。
什么场景该用，什么不该
- 该用：CI 门禁中的机械性检查（代码重复、嵌套深度、命名规范）；PR 的分阶段评审；测试覆盖充分性的是非判断。
- 不该用：架构设计的综合评价；安全漏洞的深度审计；「这段代码是否 production ready」这类复合判断。
- 组合判断：Jev 做第一轮快速筛选，通用 LLM 做第二轮深度分析。
与 EveryInfra 的组合
代码质量评测的输入是代码 diff 或文件内容。如果你需要在评审前先拿到目标仓库的最新代码、issue 评论或 CI 日志——这些数据采集是 EveryInfra 的能力范围。从统一数据 API 接入指南开始。
系列下一篇我们看生态的另一个大场景：内容评分与信息过滤。