jev-review是一个基于 TypeSafe Jev 构建的开源分阶段代码审查工作流，它内置了 5 大审查维度（正确性、安全、可靠性、兼容性、测试缺口）和 10 个可量化的阈值参数，能审查 Git diff 或扫描完整代码库，并通过本地 Dashboard 呈现审查报告，帮助开发者在合并前快速定位真正的风险点。

它解决什么问题：AI 代码审查的"分寸感" 🎯

多数 AI 审查工具要么把整个代码库丢给模型"泛泛而谈"，要么逐行硬查、产出大量噪音。jev-review 的思路是：编排逻辑写在代码里，模型只负责有边界的判断——先打分筛选，再对高信号深入取证、定机制、评严重度，最后按阈值决定是否值得人工跟进。

整个流程可以概括为：

Noul 风险矩阵 → 文件画像(Choice+Score) → 证据选择(Choice) → 机制分类(Choice) → 严重度评分(Score) → 条件式审查人路由(Choice)

5大审查维度：一页看懂它查什么 📋

jev-review 用 5 个维度对每个文件打"风险概率分"，定义见 src/domain/config.ts：

每个维度还有一组具体的"机制词表"（含noIssue兜底项），模型必须从中做选择题而不是自由发挥，机制清单完整定义在 src/domain/config.ts。

10个阈值参数：审查策略的核心 ⚙️

所有阈值集中声明在 src/domain/config.ts，纯数据、无依赖，改一处即可调整整个审查风格：

两个关键路由规则在 src/review/judgments.ts 中生效：

• 严重度 ≥ROUTE_SEVERITY(1.5)：额外调用一次模型，从security/api/runtime/testing/maintainer中选择最合适的审查人；
• 严重度 ≥BLOCKING_SEVERITY(2)：发现的动作从"评论"升级为"请求修改"。

审查流水线：阈值如何串联每一步 🔍

共享编排逻辑在 src/review/workflow.ts，两个入口（变更审查 / 代码库扫描）共用：

1. 发现（discover）：changes 模式取 Git diff 的变更文件，并把变更测试作为上下文参与 testGap 判断；codebase 模式扫描作用域下所有非忽略源文件；
2. 筛选（screen）：并发为每个文件在 5 个维度上输出概率，形成"Noul 矩阵"；
3. 过滤与排序：只保留概率 ≥SCREEN_THRESHOLD的信号并按概率降序，取前MAX_FOLLOW_UPS个（见 src/review/workflow.ts）；
4. 画像（profile）：风险最高的前MAX_PROFILES个文件做变更类型 + 审查优先级评分；
5. 定位与分类：每个信号先选证据 hunk（置信度不足MIN_LOCATION_CONFIDENCE直接放弃），再选机制（noIssue则不算发现），最后按 0–3 量表评严重度。

这样，一次大规模扫描中真正消耗"深度判断"的，只有最可疑的少数信号——这也是阈值参数如此重要的原因。

快速上手：3步跑通审查 🚀

前置要求：Node.js 24+、Git 和 TypeSafe API Key：

npm install cp .env.example .env # 在 .env 中填入 TYPESAFE_API_KEY # 审查当前 Git diff 并保存报告 npm run review:changes:save -- /path/to/git/repository # 或扫描整个代码库 npm run review:codebase:save -- /path/to/git/repository # 启动本地 Dashboard npm run dashboard

打开http://127.0.0.1:4317即可查看报告。其他命令（直接打印 JSON 的review:changes/review:codebase、依赖检查的check等）见 README.md。

本地 Dashboard：只读、绑定回环、零额外攻击面 🛡️

Dashboard 服务刻意保持极简：

• 仅绑定127.0.0.1，只暴露固定 3 个静态资源 + 1 个报告 JSON 接口（src/dashboard/server.ts）；
• 响应带Cache-Control: no-store和严格 CSP，磁盘上其他文件一律不可达；
• 报告存储走原子写（src/adapters/report-store.ts），大报告在页面中以可折叠分区展示。

页面上能直接看到工作流漏斗（筛了多少 cells、跟了多少信号、定位了几个发现）和 5 维风险矩阵，与上文参数一一对应。

相关资料路径 📁

小结

jev-review 的价值不在"更多 AI 调用"，而在用 5 个维度把风险语言结构化、用 10 个阈值把判断流程量化。想更严格？调低SCREEN_THRESHOLD；想降噪？提高BLOCKING_SEVERITY即可。所有策略都写在代码里、可审计、可复现，这正是它作为审查工作流实验的起点。

⚠️ 提示：当前版本尚不集成编译器诊断与静态分析器，其发现是"审查提示"而非缺陷证明，请结合人工判断使用。