开发与工程 code-reviewsoftware-qualitymodel-context-protocolstatic-analysistypescriptlocal-firstdeveloper-tools

Jev Review

为编码智能体提供持续、结构化的软件质量评分。

FollowAgents 评估 · FARS-2.1
推荐
81/ 100 五分制 4.1 / 5
1 2 3 4 5 6
按维度查看评分与理由
1信任安全23 / 29 · 4.0/5

项目采用单一、聚焦的 MCP 工具,仅处理调用方明确提供的上下文,不自动读取仓库或修改代码;README 清楚说明 API 密钥、代码上下文及远程 Jev API 的流向,测试也验证密钥只进入直接请求的 Authorization 头。敏感数据警告、无遥测/存储声明和最小依赖集合表现良好。扣分在于没有每次远程提交前的交互式确认或可配置审批机制;依赖虽精确固定版本,但所给材料没有锁文件、漏洞扫描或更新策略;系统基本无持久状态,因此回滚需求很小,但也未描述取消、撤销或远程请求后的恢复机制;Jev、TypeSafe 和 MIT 许可归属清楚,但维护者仅笼统写为贡献者,发布者身份未获验证。

2可靠稳定11 / 14 · 3.9/5

README、package 配置和测试对 Node 版本、端点、模型、输入边界及本地比较行为相互一致;测试覆盖缺失密钥、上游令牌超限以及带有界退避的瞬态重试。扣分在于运行依赖外部 Jev API、有效密钥和 GitHub 直接安装,且没有离线降级;错误处理证据只覆盖少量场景,未展示超时、网络断开、非 JSON 响应、认证失败或所有 MCP 边界错误的用户消息。

3适用触发16 / 18 · 4.4/5

材料明确面向 Claude Code、Codex、Cursor 和 OpenCode,给出常见使用阶段、手动配置和 macOS GUI 环境变量注意事项。能力边界写得很清楚:只评分、不解释根因、不改代码、不自动读取文件,条件指标也会标记不适用。扣分主要在触发精度:README 描述了建议检查点和停止条件,但实际 SKILL.md 内容未提供,无法完整核实代理触发规则是否与说明一致。

4规范维护14 / 18 · 3.9/5

README 的导航、架构、客户端分节、开发命令和安全说明组织完善;安装路径覆盖插件与手动 MCP 配置,工具名和包名在各材料中稳定。MIT 正文与 package 元数据一致,限制条件也明确披露,包括远程数据传输、令牌上限的不确定性和不替代安全工具。扣分在于没有真正的 FAQ,响应示例也偏概念性;只有 0.1.1 版本号,没有变更日志、发布历史或兼容性演进说明;维护责任、支持渠道和安全报告路径不明确。

5有效结果10 / 13 · 3.8/5

结构化逐指标分数、置信度、不适用标志、弱项提示以及前后评估差异都能直接支持代理迭代,且避免含混的总分,输出可用性强。扣分在于材料没有提供真实评估样例、基准结果或案例来证明相对现有测试/静态分析的增量价值;还缺少延迟、API 费用、配额消耗和大型上下文成本数据,因此只能部分判断收益与成本。

6证据核验7 / 8 · 4.4/5

关键安全和输入行为得到测试文件与 README 的交叉印证,package 配置也支持运行时、依赖及版本声明;对约 32768 令牌的说法明确标注为实时观察、非正式文档并可能变化,事实与推断区分得当。扣分在于未提供核心 src 实现、锁文件、完整测试集或实际响应样本,因此一些重要声明(不记录密钥、无遥测、完整验证转换、所有外部效果)只能部分追溯到所给证据。

证据充分度: 评估于 2026年9月20日 审查版本 57690af54ef7
使用前请注意
  • 每次评审都会把明确提交的任务、差异、文件内容或仓库上下文发送到 TypeSafe 的 Jev API;不要包含密钥、无关专有代码或其他敏感信息。
  • 未提供逐次远程发送确认机制;启用自动调用前,应通过客户端权限或工作流规则限制何时允许上传上下文。
  • 运行依赖外部 API、有效的 JEV_API_KEY 和可能变化的上游令牌限制;应预期网络、认证、配额和服务可用性故障。
  • 所给证据缺少核心 src 实现、依赖锁文件和完整测试集,因此无遥测、无日志及完整输入输出验证等声明尚不能完全静态核实。
  • Jev 分数是辅助信号,不应替代测试、人工代码审查或专门的安全扫描。
评估证据 [1][2][3][4][5][6]
查看完整评分方法 →

这个 Agent 能做什么,适合哪些场景?

Jev Review 是一个本地运行的 MCP 服务器,为 Claude Code、Codex、Cursor 和 OpenCode 提供持续的软件质量评估。它通过 stdio 启动打包后的 dist/server.js,并公开单一工具 jev_review。调用方显式提交任务、聚焦后的 diff、文件内容或仓库上下文;服务器不会自行扫描仓库。它将这些上下文直接发送到 Jev API,再把 Jev 的类型化决策转换为各质量维度的 1–10 分、置信度、规则提示和前后评估差异。代码诊断、修改与验证仍由主编码智能体完成,本项目没有托管后端、数据库或遥测服务。

编码智能体调用 jev_review,并至少提供 task、diff、files 或 repositoryContext 之一;需要比较迭代效果时还可传入 previousEvaluation。Jev Review 校验输入,将当前代码上下文通过 TLS 直接提交到 https://api.typesafe.ai/v1/systemone,并把 Score、Choice 和 Noul 决策转换成独立指标评分、0–1 置信度、适用性标记、弱项排序及预定义规则提示。提供 previousEvaluation 时,它会在本地计算各指标的变化、改进、退步和未解决弱项,不会把该历史评估加入当前代码上下文。评估覆盖正确性、复杂度、可读性、模块化、耦合、可变更性、API 设计、测试、可靠性、安全等维度,并在证据充分时评估性能、扩展性、兼容性和可观测性。它不生成根因分析、不自动读取文件,也不修改代码;主编码智能体负责解释分数并实施改进。

  1. 使用 Claude Code 或 Codex 实现非平凡功能的开发者,可在完成一个连贯改动后提交聚焦 diff,建立质量基线。
  2. 需要控制重构风险的团队,可传入 previousEvaluation,对比可读性、耦合、可变更性和其他指标的改进或退步。
  3. 使用 Cursor 的开发者,可通过插件安装并在 Agent Decides 模式或 /jev-review 技能中调用评估。
  4. 使用 OpenCode 的开发者,可手动注册本地 MCP 服务器,把同一评估流程接入现有编码工作流。
  5. 不希望把 API 密钥交给插件作者托管服务的用户,可在本机运行服务器,并让请求直接发送至 Jev API。
  6. 准备交付代码变更的开发者,可在测试通过后进行最终复评,检查尚未解决的重要质量弱项。

这个 Agent 有哪些优点和局限?

优点
  • 本地 MCP 进程没有作者托管的后端、数据库或遥测代理,API 密钥仅用于直接访问 Jev。
  • 同一 dist/server.js 可服务 Claude Code、Codex、Cursor 和 OpenCode,减少不同编码客户端之间的评审流程差异。
  • 按质量维度分别返回评分和置信度,不使用会掩盖差异的综合百分制总分。
  • 支持 previousEvaluation,可明确展示每项指标的改进、退步和未解决弱项。
  • 不会自动发现或上传仓库文件,发送范围由调用方通过 task、diff、files 和 repositoryContext 控制。
局限
  • 必须使用 Node.js 20 以上版本,并取得 Jev API 密钥;实际评估依赖 TypeSafe 的远程 Jev 服务和网络连接。
  • 评审上下文会离开本机并发送到 Jev API,因此不应包含秘密或无关的专有内容。
  • Jev 只给出标量信号和粗粒度提示,不提供低分原因的自然语言解释,也不负责修复代码。
  • 项目不发布到 npm,分发依赖 GitHub 仓库;OpenCode 还需要手动配置。
  • Jev API 的约 32,768 token 上限来自实际行为而非公开 API 文档,可能变化,并要求大型变更主动裁剪或拆分。
  • 它只是质量反馈环,不能替代专门的安全工具。

如何安装或部署这个 Agent?

准备 Node.js 20 或更高版本,并从 TypeSafe 控制台取得 Jev API 密钥。先执行 export JEV_API_KEY="your-key",再运行 npx plugins add NiazMorshed2007/jev-review,按提示选择 Claude Code、Codex 或 Cursor,然后重启客户端。也可直接指定目标:npx plugins add NiazMorshed2007/jev-review --target codex--target claude-code--target cursor。Codex 可运行 /mcp 验证连接,Claude Code 同样可通过 /mcp 检查;Cursor 在 Settings → MCP 中确认。OpenCode 需执行 git clone https://github.com/NiazMorshed2007/jev-review.git、进入目录后运行 opencode mcp add jev-review --global -- node "$PWD/dist/server.js",再用 opencode mcp list 验证。

如何使用这个 Agent?

完成一个连贯的实现片段并运行相关检查后,让编码智能体调用 jev_review。首次调用至少提交一个当前上下文字段,通常使用任务说明和聚焦后的 diff,例如概念上为 { "task": "实现具体变更", "diff": "相关差异" };只有理解变更确有需要时才补充完整 filesrepositoryContext。根据返回的低分重要维度,由编码智能体检查实际代码、提出原因假设并完成最小且合理的改进。再次调用时附上第一次返回的 previousEvaluation,检查 improvements、regressions、deltas 和 unresolved weaknesses。需求正确性与测试结果应优先于追分;若 Jev 返回 max_tokens_exceeded,应删除无关上下文或把改动拆成连贯的评审片段。

常见问题

它会自动扫描整个仓库吗?
不会。服务器只处理调用方显式提供的 task、diff、files 和 repositoryContext,至少需要其中一个当前上下文字段。
代码和 API 密钥会发送到哪里?
JEV_API_KEY 仅作为 TLS Authorization 请求头直接发送到 https://api.typesafe.ai/v1/systemone,项目声明不会存储或记录密钥。显式提交的当前评审上下文会发送给 Jev API。
使用评估是否会产生费用?
源材料没有说明 Jev API 的价格。它明确要求 TypeSafe 控制台签发的 Jev API 密钥;本地单元测试和 MCP 协议测试使用假实现,不消耗 Jev API 配额。
如果提交内容过大怎么办?
Jev API 的实时行为显示当前状态大约受 32,768 tokens 限制。收到 max_tokens_exceeded 时,应移除无关上下文,或把改动拆成多个连贯的评审片段。
它会直接修复发现的问题吗?
不会。Jev Review 返回评分、置信度、提示和对比结果;定位根因、修改代码及运行验证仍由主编码智能体负责。

对比同类 Agent

用同一套 FARS 评审,横向比较这个 Agent 所属的短名单。

相关 Agents