Jev Review
使用 jev_review 作为一个轻量级、可重复的高级工程审查循环。主要编码代理拥有实现、验证和最终判断的所有权；Jev Review 评估提交的变更，但绝不编辑文件。
审查节奏
对于非平凡任务，建议在整个工作过程中进行几次聚焦审查，而不是在最后进行一次大审查：
- 在每个连贯的实现切片完成后调用，该切片需足够实质以供评判，例如完成一个行为、模块、API 边界、迁移步骤或测试策略。
- 当新的控制流、状态处理、依赖、公共契约或安全敏感行为出现时调用。
- 在应用合理的反馈后再次调用，将先前的结果作为
previousEvaluation传入，以便 Jev 识别改进和回归。 - 在最终交付前，确保最近的审查覆盖了最终实现。
临时审查不必等待完整的测试套件。在可行时运行快速、相关的检查，并在 repositoryContext 中包含其状态；在最终审查前运行仓库的正常验证。不要重复相同的调用，不要审查仅格式化的噪音，也不要在没有连贯实现状态时调用。频繁的聚焦审查是有用的；空的审查则不然。
工作流程
- 理解用户的实际需求和约束。
- 检查仓库、其约定以及受影响的行为。
- 实现请求变更的一个连贯切片。
- 在可行时运行快速、相关的测试、类型检查、lint 或其他验证。
- 仅用评估当前切片所需的上下文调用
jev_review。 - 检查低置信度结果、薄弱维度、优先级问题以及任何回归。
- 确定哪些反馈得到代码和用户任务的支持。将评估视为证据，而非优化每个数字的指令。
- 在反馈识别出真正价值的地方改进实现，优先考虑正确性、认知复杂度、可变更性、耦合度、模块化、抽象质量、测试和安全性。
- 为下一个连贯切片重复实现、验证和审查循环。
- 在审查驱动或其他实质性变更后，再次调用
jev_review，并将先前的结构化评估作为previousEvaluation传入。 - 在最终交付前运行仓库的正常验证，如果最新的评估不再覆盖最终状态，则进行审查。
- 当重要风险得到解决且进一步更改增加的实际价值很小时停止。
选择上下文
优先使用聚焦的调用，形如：
{
"task": "用户请求的行为和相关的验收约束",
"diff": "实现的差异",
"files": [
{
"path": "src/example.ts",
"content": "仅当需要周围代码来理解 diff 时"
}
],
"repositoryContext": "相关的架构、约定、测试结果或不变性",
"previousEvaluation": {}
}
如果 Jev 报告其输入限制已超出，请减少不相关文件的内容或将实现拆分为连贯的审查切片。不要盲目截断代码，如果这样做会移除正确判断变更所需的契约、调用者或测试。
在大多数审查中使用 task 和 diff。仅在 diff 缺乏必要的周围行为时添加完整文件。使用 repositoryContext 提供评估者无法推断的简洁事实，例如已建立的模式或验证结果。
默认情况下不要发送整个仓库。排除不相关的文件、生成输出、厂商代码、密钥、凭证、私钥、环境文件以及干扰性的锁文件更改，除非它们直接与审查相关。
解读结果
- 正确性和用户的需求优先于所有分数。
- 低置信度分数是检查上下文的提示，而不是重写代码的理由。
- 标记为
applicable: false的条件指标无需操作。 - 使用
priorities查找最关键的薄弱维度，然后在更改之前检查实际代码。 - 比较评估时，调查有意义的回归和仍未解决的薄弱指标。不要追逐微小的分数变化。
- 继续依赖测试、类型检查、lint、安全工具和人工判断。Jev Review 是对这些的补充，而不是替代。
不要博弈分数
更高的分数绝不能成为以下行为的理由：不必要的抽象、推测性架构、范围扩大、破坏现有行为、重写合理的代码、无证据的非常规架构、无意义的测试、不必要的注释，或将内聚代码拆分以缩小文件。
不要假设短函数、小文件、单一职责类、零重复、更多抽象、更多测试或更多注释天生更好。要在此仓库中且针对此任务评估其后果。