代码仓库分析

jev-research-pipeline

单用户研究监测工具:代码抓取并管理证据版本,Jev 筛选评分,Qwen 起草带引用笔记供人工审阅。

E2 · 资料已核对已检查公开资料或源码证据;仅有固定提交链接并经对应源码核对,才可称固定版本核验。不代表本站运行过、认可性能或保证安全。
Stars
1
Forks
0
协议
MIT
最近提交
2026-09-23

Jev 在这里做什么

对每个(抓取来源、开放研究问题)二元组,Jev 先回答是否相关/方法可迁移/证据兼容等 Noul 门控,再给出加权 Score 维度,由代码按阈值路由到保留/待审/丢弃。

把来源判断与带版本问题、人工标签关联,阈值拟合只写提案,不静默改策略。

2026-10-24 核对固定版本的说明与实现材料。本站没有写入资料库、调用 Qwen 或在线 Jev。作者明确记录未完成的耗时/阈值目标,本评审不把它们认证为已达成。

这个项目适合解决什么任务?

监测长期研究问题,分开抓取证据、模型判断与生成笔记。

资料分析日期:

从输入到动作

  1. 代码抓取来源并绑定带版本的研究问题。
  2. Jev 筛选/评分来源与问题对,再选择相关原文句子。
  3. Qwen 带引用写笔记,人工复选框反馈用于提出阈值修改建议。

实现中值得检查的地方

schema 也是实验条件

core.py 对指令、实际发送的 schema 及 Score 级别名称做哈希;即使函数名不变,措辞或级别说明变了也是不同问题。

查看对应来源 ↗

拟合不静默改生产策略

README 说明 fit 只写提案而不应用。人工标注用于复核,不能据此倒推声称生产效果已提升。

查看对应来源 ↗

选择建议

适合有人持续审阅的单用户研究资料库。若无法检查生成论断或维护问题版本,简单订阅流可能更合适。

如何自行检查

阅读 core.py 的 Ask 问题身份逻辑与 README 的 fit/export-cases,确认 rubric 改动产生不同身份,阈值提案需要独立决定。

结论的适用边界

  • 本站没有写入资料库、调用 Qwen 或在线 Jev。
  • 作者明确记录未完成的耗时/阈值目标,本评审不把它们认证为已达成。
本次分析的原始资料