L2考核落地：人才测评整合为L2考核track，新增查重初筛与e2e验证
- 新增 L2考核 track（7维标准/100分）：选题难度赋分cap、功能完整性地板线、合格判定 - 人才测评整合进 L2考核：移除 L2/L3 两级认定与 question_id 机制 - 新增 l2-topics 选题元数据服务与 config/l2-topics.json（11命题题+自选题） - 新增查重初筛 plagiarism-detect（MD5精确比对+归一化相似度+提交行为，仅告警） - 修复 L2 维度 DIM_FILE_FILTERS 缺失导致 AI 协作记录证据漏喂 - e2e：修复 Windows spawn、DB 隔离，L2 用例 27 项全绿
This commit is contained in:
hangshuo652
@@ -1,357 +0,0 @@
|
||||
## 功能完整性（40分）
|
||||
|
||||
检查以下5项：
|
||||
|
||||
1. 核心功能实现（12分）
|
||||
- 题目要求的主要功能全部实现且可运行 → 12分
|
||||
- 主要功能实现但有边角缺陷 → 9-11分
|
||||
- 部分核心功能实现，其余有框架或占位 → 6-8分
|
||||
- 仅有框架无实际功能 → 0分
|
||||
|
||||
2. 异常处理（8分）
|
||||
- 有错误提示且覆盖LLM超时/不可达等主要场景 → 8分
|
||||
- 有错误提示但不完整，或仅有降级处理之一 → 5-7分
|
||||
- 无错误提示但有显式错误反馈 → 3-4分
|
||||
- 无任何异常处理 → 0分
|
||||
|
||||
3. 边界情况（6分）
|
||||
- 空数据、异常输入均正确处理 → 6分
|
||||
- 部分边界场景处理 → 3-5分
|
||||
- 无边界处理但程序不崩溃 → 1-2分
|
||||
- 边界输入导致崩溃 → 0分
|
||||
|
||||
4. 业务逻辑正确性（8分）
|
||||
- 统计结果与手算一致，检索结果相关 → 8分
|
||||
- 大部分场景正确，个别边界有误 → 5-7分
|
||||
- 存在明显逻辑错误 → 0-4分
|
||||
|
||||
5. 可运行性（6分）
|
||||
- README步骤可直接运行，无启动报错 → 6分
|
||||
- 需少量额外步骤可运行 → 3-5分
|
||||
- 无法运行 → 0分
|
||||
|
||||
【交叉验证规则】
|
||||
- README声称的功能，必须在代码目录中找到对应的实现文件，否则视为未实现
|
||||
- 声称"支持异常处理"→代码中必须有try-catch或错误处理逻辑，否则扣4分
|
||||
- 声称"支持多种数据格式"→代码中必须有对应的格式处理逻辑，否则扣3分
|
||||
|
||||
## 设计文档（10分）
|
||||
|
||||
检查以下3项：
|
||||
|
||||
1. 架构图（4分）
|
||||
- 有架构图或数据流图（若无→0分）
|
||||
- 图表清晰、标注完整
|
||||
|
||||
2. 技术选型理由（3分）
|
||||
- 为什么选择该技术栈（opencode + 课程技术）
|
||||
- 各组件的作用说明
|
||||
|
||||
3. 关键设计决策（3分）
|
||||
- 设计上的取舍和理由
|
||||
- 边界情况处理策略
|
||||
|
||||
## 测试用例与测试结果（10分）
|
||||
|
||||
检查以下3项：
|
||||
|
||||
1. 测试用例数量（3分）
|
||||
- ≥3个测试用例（若无→0分）
|
||||
|
||||
2. 测试覆盖（4分）
|
||||
- 覆盖核心逻辑的正常路径和异常路径
|
||||
|
||||
3. 结果可复现（3分）
|
||||
- 测试结果附在提交物中
|
||||
- 评审者能按步骤复现
|
||||
|
||||
【交叉验证规则】
|
||||
- AGENTS.md或README中声称的"测试覆盖核心功能"，必须在代码中找到对应的测试文件（*.spec.ts, *.test.ts, test_*.py等），否则视为造假扣4分
|
||||
- 测试文件内容必须有断言（assert/expect/should等），仅有文件骨架而无断言视为无效测试，扣2分
|
||||
- 声称"测试全部通过"但测试代码中存在明显语法错误或引用不存在的模块 → 视为造假，该项0分
|
||||
|
||||
## AI协作过程记录（15分）
|
||||
|
||||
检查以下4项：
|
||||
|
||||
1. AGENTS.md存在（3分）
|
||||
- 项目根目录有AGENTS.md文件（若无→0分）
|
||||
|
||||
2. prompt记录（5分）
|
||||
- 记录了使用的prompt原文
|
||||
- 记录了生成过程
|
||||
|
||||
3. 人工修正点（4分）
|
||||
- 记录了AI生成代码后的人工修改
|
||||
- 记录了修改理由
|
||||
|
||||
4. 问题与对策（3分）
|
||||
- 记录了遇到的问题
|
||||
- 记录了解决方案
|
||||
|
||||
【交叉验证规则】
|
||||
- AGENTS.md中声称的"使用了XX技术"，必须在代码中找到对应的配置或调用文件
|
||||
- 如果AGENTS.md说"用SpecKit"，但代码中没有spec/PRD/TECH_SPEC.md文件 → 视为夸大，扣3分
|
||||
- 如果AGENTS.md说"对LLM输出做了质量验证"，但代码中没有对应的验证逻辑 → 视为虚构，扣3分
|
||||
- 如果AGENTS.md说"编写了测试覆盖核心逻辑"，但实际没有测试文件或测试内容与描述不符 → 视为造假，该项0分
|
||||
|
||||
## 技术选型与范式运用（15分）
|
||||
|
||||
检查以下4项：
|
||||
|
||||
1. 课程技术运用（5分）
|
||||
- 至少选择了1项指定技术（VibeCoding/Superpowers/SpecKit/Skill/MCP）
|
||||
- 技术运用方式合理
|
||||
|
||||
2. 选型理由（4分）
|
||||
- 说明了为什么选择该技术组合
|
||||
- 与题目场景匹配
|
||||
|
||||
3. 范式运用（3分）
|
||||
- 运用的范式（SpecKit/VibeCoding等）有明确记录
|
||||
- 范式选择与题目特性匹配
|
||||
|
||||
4. 技术组合深度（3分）
|
||||
- 组合多项技术的加分
|
||||
- 技术之间有明确的调用/协作关系
|
||||
|
||||
【交叉验证规则】
|
||||
- 声称使用了"Skill"→代码中必须有对应的Skill定义文件或注册代码，否则扣3分
|
||||
- 声称使用了"SpecKit"→项目中必须有spec/PRD/TECH_SPEC.md文件，否则扣3分
|
||||
- 声称使用了"MCP自动化测试"→必须有MCP Server配置或测试脚本调用代码，否则扣3分
|
||||
- 声称"组合了多项技术"→必须有明确的调用链路（如A技术调用B技术的代码），否则扣3分
|
||||
|
||||
## 代码质量 + README（10分）
|
||||
|
||||
检查以下3项：
|
||||
|
||||
1. 代码结构（4分）
|
||||
- 结构清晰、命名规范
|
||||
- 无大量重复代码（重复率>30%扣分）
|
||||
|
||||
2. README完整性（4分）
|
||||
- 包含：环境要求、安装步骤、运行方法、功能说明
|
||||
- README步骤能直接运行成功
|
||||
|
||||
3. 依赖管理（2分）
|
||||
- 依赖清单完整
|
||||
- 无多余/缺失的依赖
|
||||
|
||||
【交叉验证规则】
|
||||
- README声称的项目功能，必须在代码中有对应的入口文件或模块，否则视为夸大，扣2分
|
||||
- README声称的"支持XX平台/环境"，必须有对应的配置文件（Dockerfile、.nvmrc等），否则视为不实，扣1分
|
||||
|
||||
## 第二部分：问题别L3追加维度
|
||||
|
||||
L3为追加评审，仅在L2合格（共通≥60分）后自动触发。
|
||||
|
||||
|
||||
## [Q2] LLM生成问卷（15分）
|
||||
|
||||
检查以下3项：
|
||||
|
||||
1. 问卷生成逻辑（6分）
|
||||
- 代码中是否有LLM调用生成面谈问题的逻辑
|
||||
- 问卷内容是否与低分维度数据联动（非固定模板文案）
|
||||
|
||||
2. 定制化（5分）
|
||||
- 是否支持按部门/职级生成不同问题
|
||||
- 问卷内容是否可编辑
|
||||
|
||||
3. 问题质量（4分）
|
||||
- 生成的问题是否基于具体数据
|
||||
- 不是通用模板问题
|
||||
|
||||
## [Q2] LLM自由文本分析（10分）
|
||||
|
||||
检查以下两项：
|
||||
|
||||
1. 话题分类/摘要（5分）
|
||||
- 面谈分析页面是否包含AI生成的话题分类结果
|
||||
- 是否有自由文本的摘要/分析
|
||||
|
||||
2. 共性问题提取（5分）
|
||||
- 是否能跨面谈记录发现高频出现的问题主题
|
||||
- 提取的共性问题是否准确
|
||||
|
||||
## [Q2] prompt工程与调优记录（5分）
|
||||
|
||||
检查以下一项：
|
||||
|
||||
1. prompt调优过程
|
||||
- AGENTS.md中是否有prompt调优过程记录
|
||||
- 不同策略的对比
|
||||
- LLM输出质量验证方法
|
||||
|
||||
|
||||
## [Q3] LLM检索回答（11分）
|
||||
|
||||
检查以下两项：
|
||||
|
||||
1. LLM生成回答（7分）
|
||||
- 代码中是否有LLM生成回答的逻辑（非单纯关键词匹配）
|
||||
- 回答是否引用出处文档名/章节/页码
|
||||
|
||||
2. 置信度显示（4分）
|
||||
- 回答附带置信度分数
|
||||
- 可信度标识清晰
|
||||
|
||||
## [Q3] 上下文连续对话（10分）
|
||||
|
||||
检查以下两项：
|
||||
|
||||
1. 追问支持（5分）
|
||||
- 是否支持在上一轮基础上继续提问
|
||||
- 上下文理解是否正确
|
||||
|
||||
2. 对话管理（5分）
|
||||
- 代码中是否有上下文管理机制
|
||||
- 对话状态是否在UI中可见
|
||||
|
||||
## [Q3] 无法回答处理（10分）
|
||||
|
||||
检查以下两项：
|
||||
|
||||
1. 无法回答检测（5分）
|
||||
- 对制度文档中不存在的问题，是否明确返回"未在现有制度中找到相关信息"
|
||||
- 不编造答案
|
||||
|
||||
2. 合理引导（5分）
|
||||
- 是否给出合理解释或建议
|
||||
- 是否引导用户调整提问方式
|
||||
|
||||
## [Q3] RAG管道设计记录（19分）
|
||||
|
||||
检查以下4项：
|
||||
|
||||
1. chunk策略设计（5分）
|
||||
- AGENTS.md是否记录了chunk大小/重叠率选择理由
|
||||
- 不同分割策略的对比
|
||||
|
||||
2. embedding模型选型（5分）
|
||||
- 是否说明了embedding模型选择理由
|
||||
- 是否对比了不同模型的效果
|
||||
|
||||
3. 检索策略对比（5分）
|
||||
- 是否记录了关键词/向量/混合检索的对比
|
||||
- 检索准确率改善过程
|
||||
|
||||
4. 多语言处理策略（4分）
|
||||
- 是否说明了中日文混合检索的处理方案
|
||||
- 分词/索引策略的差异处理
|
||||
|
||||
|
||||
## [Q4] LLM条款提取（10分）
|
||||
|
||||
检查以下两项：
|
||||
|
||||
1. 关键字段提取（5分）
|
||||
- 代码中是否有通过LLM提取合同关键字段的逻辑
|
||||
- 提取字段包括：金额、期限、违约责任、管辖法院等
|
||||
|
||||
2. 提取准确度（5分）
|
||||
- 审查报告中提取的字段是否正确
|
||||
- 是否支持多份合同验证
|
||||
|
||||
## [Q4] LLM风险标记（10分）
|
||||
|
||||
检查以下两项：
|
||||
|
||||
1. 风险条款标记（5分）
|
||||
- 是否有AI自动标记风险条款的功能
|
||||
- 审查结果页面是否展示风险项
|
||||
|
||||
2. 风险判断理由（5分）
|
||||
- 每条风险标记是否附带判断理由
|
||||
- 理由是否合理
|
||||
|
||||
## [Q4] prompt工程与规则设计记录（10分）
|
||||
|
||||
检查以下两项：
|
||||
|
||||
1. 审查规则设计（5分）
|
||||
- AGENTS.md是否记录了审查规则设计过程
|
||||
- 风险标准定义的迭代
|
||||
|
||||
2. prompt调优（5分）
|
||||
- prompt调优过程记录
|
||||
- 不同策略的对比
|
||||
|
||||
|
||||
## [Q5] LLM内容提取（10分）
|
||||
|
||||
检查以下两项：
|
||||
|
||||
1. 法规字段提取（5分）
|
||||
- 代码中是否有AI解析网页内容提取法规字段的逻辑
|
||||
- 提取字段包括：法规名称、发布机关、发布日期、摘要
|
||||
|
||||
2. 提取质量（5分）
|
||||
- 提取结果是否准确
|
||||
- 是否支持不同的网页结构
|
||||
|
||||
## [Q5] LLM影响度评估（10分）
|
||||
|
||||
检查以下两项：
|
||||
|
||||
1. 影响度自动判断（5分）
|
||||
- 是否有AI自动评估高/中/低影响度的功能
|
||||
- 判断依据是否来源于LLM分析
|
||||
|
||||
2. 影响度展示（5分）
|
||||
- 影响度在结果列表中是否清晰标识
|
||||
- 高影响度是否突出显示
|
||||
|
||||
## [Q5] prompt工程与爬虫策略记录（10分）
|
||||
|
||||
检查以下两项：
|
||||
|
||||
1. 爬虫策略设计（5分）
|
||||
- AGENTS.md是否记录了爬虫规则设计
|
||||
- 反爬策略
|
||||
|
||||
2. 提取准确率改善（5分）
|
||||
- 提取准确率的改善过程
|
||||
- 不同网站结构的处理策略
|
||||
|
||||
|
||||
## [Q6] LLM风险分类（10分）
|
||||
|
||||
检查以下两项：
|
||||
|
||||
1. 自动分类逻辑（5分）
|
||||
- 代码中是否有AI自动将情报按领域分类的逻辑
|
||||
- 分类维度是否与预设一致（汇率/法规/日中关系/行业/技术）
|
||||
|
||||
2. 分类展示（5分）
|
||||
- 分类结果在界面中是否清晰展示
|
||||
- 是否支持按分类筛选
|
||||
|
||||
## [Q6] LLM影响度评估（10分）
|
||||
|
||||
检查以下两项：
|
||||
|
||||
1. 风险等级评估（5分）
|
||||
- 是否有AI根据内容评估风险等级的功能
|
||||
- 评估依据是否可追溯
|
||||
|
||||
2. 高风险处理（5分）
|
||||
- 高风险情报是否自动突出显示
|
||||
- 是否有通知机制（系统内/模拟邮件）
|
||||
|
||||
## [Q6] prompt工程与分类策略记录（10分）
|
||||
|
||||
检查以下两项：
|
||||
|
||||
1. 分类模型选择（5分）
|
||||
- AGENTS.md是否记录了分类模型选择理由
|
||||
- 影响度评估标准定义
|
||||
|
||||
2. 策略调优（5分）
|
||||
- 通知规则设计
|
||||
- 分类准确率改善过程
|
||||
|
||||
## 合格判定一览
|
||||
|
||||
| 题目 | 难度 | 共通满分 | 追加满分 | 总分上限 | L2合格 | L3合格 |
|
||||
|:----|:----:|:--------:|:--------:|:--------:|:------:|:---
|
||||
@@ -0,0 +1,79 @@
|
||||
## 功能完整性（30分）
|
||||
|
||||
评审基准：
|
||||
- 命题题：按系统注入的该题验收基准表逐项评定，未实现或与声明不符的功能不计分
|
||||
- 自选题：按 README 声明的功能清单逐项核对实现情况（结合登记功能清单快照，低于登记范围核心功能的缩减部分按未实现计）
|
||||
|
||||
分档锚点：
|
||||
- 核心功能全部实现且实测可运行：25-30分
|
||||
- 主要功能实现，个别非核心功能缺失或有边角缺陷：18-24分
|
||||
- 部分核心功能实现，存在占位/框架代码：10-17分
|
||||
- 仅框架无实际功能，或主要功能无法运行：0-9分
|
||||
|
||||
【交叉验证规则】
|
||||
- README 声称的功能，必须在代码目录中找到对应的实现入口/模块，否则视为未实现
|
||||
- 声称"支持异常处理"→代码中必须有 try-catch 或错误处理逻辑，否则扣4分
|
||||
- 声称"支持多种数据格式"→代码中必须有对应的格式处理逻辑，否则扣3分
|
||||
- 凡涉及 LLM/API 调用的功能，必须具备超时设置、异常捕获、降级或显式错误提示至少一项；全部缺失扣4分
|
||||
|
||||
## 设计文档（10分）
|
||||
|
||||
1. 架构图（4分）：有架构图或数据流图，模块划分与外部依赖（LLM API 等）标注清晰；无图计0-1分
|
||||
2. 开发范式流程图（3分）：本人开发过程的工作流设计；图中步骤名称与 _AI_USAGE_LOG.md 的「范式步骤」列逐步对应，对应不上酌情扣分
|
||||
3. 关键设计决策（3分）：重要取舍有理由；评分型指标（置信度/影响度/准确率/高频阈值等）的计算口径必须在设计文档中写明，未写明口径扣2分
|
||||
|
||||
## 测试用例与测试结果（10分）
|
||||
|
||||
1. 用例数量（3分）：至少3个测试用例（命题题从其题目约定）；无测试文件计0分
|
||||
2. 覆盖质量（4分）：覆盖核心逻辑的正常路径与异常路径；断言真实有效——仅有文件骨架而无断言（assert/expect/should）视为无效测试
|
||||
3. 结果可复现（3分）：测试以命令行方式可执行，执行结果附于 tests/ 或 README；评审系统将实际运行测试并与声明对照
|
||||
|
||||
【交叉验证规则】
|
||||
- 声称"测试覆盖核心功能"，必须找到对应测试文件（*.spec.ts / *.test.ts / test_*.py 等），否则视为造假扣4分
|
||||
- 声称"测试全部通过"但测试代码存在明显语法错误或引用不存在的模块 → 该项0分
|
||||
- 评审环境导致的测试失败（依赖缺失等）为中性证据，不据此扣分，但受验者声明的结果与实测矛盾时扣分
|
||||
|
||||
## AI协作过程记录（15分）
|
||||
|
||||
1. AGENTS.md 存在（3分）：项目根目录有 AGENTS.md；缺失计0分
|
||||
2. prompt 原文（5分）：记录核心功能生成过程的 prompt 原文，可追溯到具体功能
|
||||
3. 人工修正点（4分）：记录 AI 输出后自己改了什么、为什么要改
|
||||
4. 问题与对策（3分）：记录遇到的问题（幻觉API、超时缺失等）与解决方案
|
||||
|
||||
【交叉验证规则】
|
||||
- AGENTS.md 声称"使用了XX技术"，必须在代码中找到对应配置或调用文件
|
||||
- 说"用 SpecKit"但没有 spec/PRD/TECH_SPEC 类文件 → 视为夸大扣3分
|
||||
- 说"做了LLM输出质量验证"但没有对应验证逻辑 → 视为虚构扣3分
|
||||
- _AI_USAGE_LOG.md 声称的修改所涉及的文件路径，须在 git 历史中存在对应变更；凭空捏造的日志条目每处扣2分
|
||||
|
||||
## 技术选型与范式运用（15分）
|
||||
|
||||
1. 课程技术运用（5分）：VibeCoding / Superpowers / SpecKit / Skill / MCP自动化测试 至少1项真实运用于开发过程，运用深度合理（非表面套用）；一项都没有计0分
|
||||
2. 选型理由（4分）：说明了为何选择该技术组合、与题目场景的匹配性
|
||||
3. 范式运用记录（3分）：运用的范式有明确记录（AGENTS.md 课程技术运用节）
|
||||
4. 组合深度（3分）：组合多项技术时有明确的调用/协作关系
|
||||
|
||||
【交叉验证规则】
|
||||
- 声称 Skill → 代码中必须有 Skill 定义文件或注册代码，否则扣3分
|
||||
- 声称 MCP 自动化测试 → 必须有 MCP Server 配置或测试脚本调用代码，否则扣3分
|
||||
- 声称"组合多项技术"→ 必须有明确调用链路（A技术调用B技术的代码），否则扣3分
|
||||
|
||||
## 代码质量+README（10分）
|
||||
|
||||
1. 代码结构（4分）：结构清晰、命名规范、无硬编码密钥/绝对路径；文件级重复率超过30%酌情扣分，超过50%本项计0-1分
|
||||
2. README 完整性（4分）：含痛点背景、功能说明、效果总结、安装运行四部分，安装步骤逐步可复制执行；缺一部分扣1分
|
||||
3. 依赖管理（2分）：依赖清单/锁文件完整可复现，无多余缺失依赖
|
||||
|
||||
【交叉验证规则】
|
||||
- README 声称的项目功能必须有对应入口文件或模块，否则视为夸大扣2分
|
||||
- 声称"支持XX平台/环境"但无对应配置文件（Dockerfile、.nvmrc 等）→ 扣1分
|
||||
|
||||
## 业务场景理解与需求分析（10分）
|
||||
|
||||
1. 痛点理解（4分）：对业务场景痛点理解准确，目标用户/使用场景清晰（命题题为该题业务场景的理解分析，自选题必须有现状低效点分析）
|
||||
2. 需求分析（3分）：功能边界清楚，需求拆解合理
|
||||
3. 效果总结可信（3分）：提效数字附测量方式（如何计时、对比场景与步骤）；基于模拟场景的小样本试用如实记录即可；无法量化的说明具体痛点和实际反馈
|
||||
|
||||
【真实性规则】
|
||||
- 无测量依据的夸大数字在可信度上扣分（本项计0-1分）
|
||||
- 文档声称效果与实测明显不符 → 本项计0分并在评语标注
|
||||
Reference in New Issue
Block a user