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
+16
-21
@@ -10,7 +10,7 @@
|
||||
>
|
||||
> **提交截止：2026年9月底（9月30日）**。自题目发布日起至 9月30日，将成果物 `git push` 到 Gitea 仓库 main 分支（以仓库最后推送时间为准）。
|
||||
>
|
||||
> 超过截止时间未提交，按以下迟交规则处理：迟交 1~3 个工作日扣 5 分，4~7 个工作日扣 10 分，超过 7 个工作日本题按 0 分处理并需重做（重做细则见 §12.3）。
|
||||
> 超过截止时间未提交，按以下迟交规则处理：迟交 1~3 个工作日扣 5 分，4~7 个工作日扣 10 分，超过 7 个工作日**按 0 分处理、不再评审**。
|
||||
>
|
||||
> 请务必在截止前完成：账号登录 → 成果物放入仓库 → `git push` 到 main 分支，并确认服务器上能看到最新提交。
|
||||
|
||||
@@ -28,7 +28,7 @@
|
||||
- §10 独立完成与查重红线 ｜ §11 源码可运行前提
|
||||
|
||||
**第三部分 · 考核标准与纪律**
|
||||
- §12 考核标准（7维评审要点 / 合格线与赋分 / 重做细则）
|
||||
- §12 考核标准（7维评审要点 / 合格线与赋分 / 结果申诉）
|
||||
- §13 提交前自查清单 ｜ §14 违规后果
|
||||
|
||||
**第四部分 · 命题题详细需求（选定题目后细读对应章节）**
|
||||
@@ -66,7 +66,7 @@ L2（Level 2）是 AI 人才育成体系中的能力等级，定义为：**能
|
||||
| 开发工具 | 推荐 OpenCode / Claude Code / GitHub Copilot（不作强制）；LLM API 自备 |
|
||||
| 评审流程 | 系统自动拉取仓库 → 成果物齐全性自动检测 + 跨仓库查重初筛 → 评审者按 7 维框架人工评分 → 结果反馈 |
|
||||
| 合格标准 | 合格线 **≥60 分**（命题题含难度赋分，满分最高110） |
|
||||
| 未达标处理 | 按重做细则重做一次（5个工作日内），重做评分上限 80 分；细则见 §12.3 |
|
||||
| 未达标处理 | 评审结论为不合格（总分<60 或 功能完整性<15 地板线）；结果申诉见 §12.4 |
|
||||
|
||||
### 1.3 考核目标：验证什么
|
||||
|
||||
@@ -346,7 +346,7 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
|
||||
**处理规则**：
|
||||
|
||||
- 初筛告警由评审者人工复核认定；单次全量 push 等行为信号本身**不构成违规认定**，仅作为复核参考——被标记者应能在 AGENTS.md 与 git 历史中给出独立完成的依据
|
||||
- **查实抄袭：本题按 0 分处理并需重做（重做上限 80 分），处理结果记入考核档案**
|
||||
- **查实抄袭：本题按 0 分处理，处理结果记入考核档案**
|
||||
- 允许查阅公开资料与使用 AI 生成，但须如实记录（见 §8）；未记录的他人代码片段视为抄袭
|
||||
- 组委会保留对可疑情形**约谈核实**的权利：可要求受验者现场讲解任意一段核心实现的思路与取舍；拒绝配合或讲解与提交代码明显不符的，按查实抄袭处理
|
||||
|
||||
@@ -386,14 +386,7 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
|
||||
- **功能完整性评分锚点**：命题题按该题验收基准表逐项评定；自选题按 README 声明的功能清单逐项核对实现情况评定（结合「声称 vs 实测」验证，未实现或与声明不符的功能不计分）
|
||||
- **功能完整性地板线**：该维度得分低于 15 分（不足满分一半）时，无论总分多少均判为**不合格**——防止「文档精美、功能空壳」的提交过线
|
||||
|
||||
### 12.3 重做细则
|
||||
|
||||
- 未达合格线：自通知之日起 **5 个工作日内**重做，重做评分最高记 **80 分**，每题限重做 **1 次**；再次未达线则总评为不合格
|
||||
- 重做允许**更换命题**（在 01~11 中另行选择，自选题亦可修订原方案），按新选题的验收基准评分，难度赋分随新选题调整
|
||||
- 重做提交同样适用迟交规则：逾期扣分，超过 7 个工作日视为**放弃重做资格**，总评不合格
|
||||
- 查实抄袭者不适用正常重做流程，按 §14 违规后果处理
|
||||
|
||||
### 12.4 结果申诉
|
||||
### 12.3 结果申诉
|
||||
|
||||
- 对评分结果或查重认定有异议的，可在收到结果之日起 **3 个工作日内**向组委会提交一次复核申请（列明异议点与依据）
|
||||
- 由**未参与原评审**的人员进行复核，**5 个工作日内**书面答复；复核结论为最终结论
|
||||
@@ -424,13 +417,13 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
|
||||
|
||||
| 情形 | 后果 |
|
||||
|------|------|
|
||||
| 超过截止时间未提交/未push | 按迟交规则扣分；超7个工作日按0分并需重做 |
|
||||
| 超过截止时间未提交/未push | 迟交 1~3 个工作日扣 5 分，4~7 个工作日扣 10 分；超 7 个工作日按 0 分处理、不再评审 |
|
||||
| 仓库名、分支、凭据不符合规范 | 评审系统无法拉取，按未提交处理 |
|
||||
| 必填成果物缺失或命名不符 | 对应成果物判定为未提交，相关维度扣分 |
|
||||
| README 声称功能与实测不符 | 真实性扣分 |
|
||||
| AI 日志缺失或空白 | 相关维度扣分 |
|
||||
| 源码无法按 README 运行 | 后续所有评分项扣分 |
|
||||
| 查实抄袭/代做 | 本题 0 分 + 重做（上限80分），记入考核档案 |
|
||||
| 查实抄袭/代做 | 本题 0 分，记入考核档案 |
|
||||
| 使用真实业务/客户数据 | 视情节按信息安全违规处理，相关维度扣分至取消资格 |
|
||||
|
||||
---
|
||||
@@ -1152,9 +1145,11 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
|
||||
| # | 要求 | 说明 |
|
||||
|---|------|------|
|
||||
| 1 | **证据型报告** | 每个检出问题必须定位到具体位置（`文件名:行号` 或 `章节编号/条目原文摘录`），附问题描述；不允许只输出整体评价而无问题定位 |
|
||||
| 2 | **规则外置** | 检查规则必须写在独立配置文件中（YAML/JSON/Markdown均可），新增或修改一条规则不需要改动程序代码；演示时须现场新增1条规则并验证生效 |
|
||||
| 2 | **规则外置** | 检查规则必须写在独立配置文件中（YAML/JSON/Markdown均可），新增或修改一条规则不需要改动程序代码；须提交自动化验证脚本与运行日志（放 tests/），证明「新增一条规则后不改变代码即可生效」 |
|
||||
| 3 | **分级判定** | 问题分为 Critical / Major / Minor 三级；报告包含各级数量统计和明确的通过结论（通过 / 有条件通过 / 不通过） |
|
||||
| 4 | **企业标准外置** | 各阶段适用的企业内部标准（文档格式规范 / 编码规约 / 测试基准等）以独立配置文件提供，工具按配置执行检查；标准的具体条目由项目方定义，工具不得硬编码。样本数据须附「标准配置A/B两套」，演示切换B套后检出结果随之变化 |
|
||||
| 4 | **企业标准外置** | 各阶段适用的企业内部标准（文档格式规范 / 编码规约 / 测试基准等）以独立配置文件提供，工具按配置执行检查；标准的具体条目由项目方定义，工具不得硬编码。样本数据须附「标准配置A/B两套」，评审者切换B套后检出结果随之变化 |
|
||||
|
||||
> **组内共性提交物补充**：第 2、4 条的「规则/标准外置生效」验证，以自动化验证脚本 + 运行日志形式提交（放 `tests/`），脚本演示「新增/修改一条规则（或切换 A/B 标准）后不改变代码即可生效、检出结果随之变化」。评审系统按脚本可复现执行核验，不做现场演示。
|
||||
|
||||
---
|
||||
|
||||
@@ -1225,7 +1220,7 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
|
||||
| 可测试性评估 | 正确标识植入的不可测试需求 | 附具体可操作的改写建议 | 对照缺陷标注清单核对 |
|
||||
| 编写规范检查 | 配置的格式违规能正确检出 | 支持标准A/B切换，检出结果随之变化 | 对照缺陷标注清单核对+切换标准演示 |
|
||||
| 报告规范 | 分级+章节定位完整 | 定位含条目原文摘录 | 抽查报告中定位是否准确 |
|
||||
| 规则外置生效 | 规则在独立配置文件中维护 | 现场新增1条规则不改代码生效 | 演示验证 |
|
||||
| 规则外置生效 | 规则在独立配置文件中维护 | 新增1条规则不改代码生效，有自动化脚本+运行日志佐证 | 运行提交的验证脚本核验 |
|
||||
|
||||
#### 提交物清单
|
||||
|
||||
@@ -1321,8 +1316,8 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
|
||||
| 追溯矩阵映射 | 10条需求正确建立≥8条映射 | 全部建立且无误报 | 对照缺陷标注清单核对 |
|
||||
| 未覆盖与孤儿标记 | 两类问题均能正确标出 | 无误报 | 对照缺陷标注清单核对 |
|
||||
| 接口一致性 | 植入2处矛盾至少检出1处 | 全部检出并引用两处定义原文 | 对照缺陷标注清单核对 |
|
||||
| 矩阵可视化 | 表格形式展示完整映射关系 | 支持点击跳转到对应位置 | 操作演示验证 |
|
||||
| 规则外置生效 | 必备章节清单在配置文件中维护 | 现场调整清单后重新评审生效 | 演示验证 |
|
||||
| 矩阵可视化 | 表格形式展示完整映射关系 | 支持点击跳转到对应位置 | 运行提交的脚本/截图验证 |
|
||||
| 规则外置生效 | 必备章节清单在配置文件中维护 | 调整清单后重新评审生效，有自动化脚本+运行日志佐证 | 运行提交的验证脚本核验 |
|
||||
|
||||
#### 提交物清单
|
||||
|
||||
@@ -1416,7 +1411,7 @@ AI生成代码大量合入代码库后，出现特有的高频缺陷模式：
|
||||
| 空值防护 | 典型裸访问模式检出率≥70% | 全部检出且无误报 | 对照缺陷标注清单核对 |
|
||||
| 编码规约检查 | 配置的规约违规（命名/注释）能正确检出 | 支持规约A/B切换，检出结果随之变化 | 对照缺陷标注清单核对+切换规约演示 |
|
||||
| 扫描范围控制 | 配置的排除目录不被扫描 | 白名单机制生效 | 故意配置后运行验证 |
|
||||
| 报告规范与规则外置 | 分级+file:line定位完整 | 修复建议含示例代码；现场新增规则生效 | 抽查报告+演示验证 |
|
||||
| 报告规范与规则外置 | 分级+file:line定位完整 | 修复建议含示例代码；新增规则不改代码生效，有脚本佐证 | 抽查报告+运行验证脚本 |
|
||||
|
||||
#### 提交物清单
|
||||
|
||||
@@ -1513,7 +1508,7 @@ AI辅助生成测试用例后，测试数量激增但质量参差：
|
||||
| 无断言测试识别 | 无断言测试100%标记 | 附最小断言补充建议 | 对照缺陷标注清单核对 |
|
||||
| 基准符合性检查 | 配置的基准违规（缺预期结果等）能正确检出 | 支持基准A/B切换，检出结果随之变化 | 对照缺陷标注清单核对+切换基准演示 |
|
||||
| 用例评级 | 每个测试用例有A/B/C评级 | C级用例附针对性改进建议 | 抽查评级合理性 |
|
||||
| 报告规范与规则外置 | 评级结果+覆盖矩阵完整展示 | 评级标准在配置文件中可调整 | 演示验证 |
|
||||
| 报告规范与规则外置 | 评级结果+覆盖矩阵完整展示 | 评级标准在配置文件中可调整，有脚本佐证 | 运行验证脚本核验 |
|
||||
|
||||
#### 提交物清单
|
||||
|
||||
|
||||
Reference in New Issue
Block a user