L2文档三大板块重构+评分细则不公开化；系统对齐：一键三轮评审、受验者注册表映射、提交状态探测工具

- 文档重构为 考核目的(1.x)/提交要求(2.x，含成果物需求)/考核内容(3.x) 板块编号体系
- 删除公开评分细则（7维表/合格线/难度赋分/功能拆分），保留验收基准与提交要求
- 自选题取消事前登记，改由 AGENTS.md 记录核心内容；前端同步移除登记字段
- 新增 l2-participants 注册表服务与 teams-config L2 URL 自动映射
- 新增 startReviewRounds 一键N轮评审（自动续跑+快照聚合中位数），前端「重新评审×3」
- 新增 check-repos.mjs 提交状态探测（API四态判定：已提交/空仓/未创建/未授权）
- 文档措辞与实现对齐（AI辅助评审）、修复引用/残片/格式问题

docs/L2考核成果物提交规范.md

@@ -1,4 +1,4 @@
-# L2考核成果物提交规范 · AI人才育成L2认证
+# L2考核成果物提交规范 · AI人才育成认证——L2
 
 > 适用范围：AI人才育成 L2 考核全部受验者（个人考核）
 >
@@ -12,41 +12,30 @@
 >
 > 超过截止时间未提交，按以下迟交规则处理：迟交 1~3 个工作日扣 5 分，4~7 个工作日扣 10 分，超过 7 个工作日**按 0 分处理、不再评审**。
 >
-> 请务必在截止前完成：账号登录 → 成果物放入仓库 → `git push` 到 main 分支，并确认服务器上能看到最新提交。
+> 请务必在截止前完成：**注册账号（用户名=员工编号）→ 授权评审拉取账号（只读协作者）→ 提交登记 → 成果物放入仓库 → `git push` 到 main 分支**，并确认服务器上能看到最新提交。
 
 ---
 
 ## 📑 目录
 
-**第一部分 · 考核说明**
-- **§1 考核目的、方式与内容** —— 目的定位 / 方式一览 / 三层目标 / 双轨选题制 / 命题题一览 / 自选题约束 / 选题声明
+**第一部分 · 考核目的**
+- §1.1 考核目的与定位 ｜ §1.2 考核方式与合格标准 ｜ §1.3 选题路径
 
-**第二部分 · 开发与提交规范**
-- §2 开发工具与模型 ｜ §3 Gitea账号规范 ｜ §4 仓库规范
-- §5 成果物清单与放置规则 ｜ §6 README编写要求 ｜ §7 设计文档要求
-- §8 AI协作过程留痕 ｜ §9 通用命名与内容红线
-- §10 独立完成与查重红线 ｜ §11 源码可运行前提
+**第二部分 · 提交要求**
+- §2.1 开发工具与模型 ｜ §2.2 Gitea账号与仓库（注册→授权→仓库名）
+- **成果物需求**：§2.3 成果物清单与放置规则 ｜ §2.4 README编写要求 ｜ §2.5 设计文档要求 ｜ §2.6 AI协作过程留痕 ｜ §2.7 命名红线与信息安全 ｜ §2.8 独立完成与查重红线 ｜ §2.9 源码可运行前提
+- §2.10 提交前自查清单 ｜ §2.11 违规后果
 
-**第三部分 · 考核标准与纪律**
-- §12 考核标准（7维评审要点 / 合格线与赋分 / 结果申诉）
-- §13 提交前自查清单 ｜ §14 违规后果
-
-**第四部分 · 命题题详细需求（选定题目后细读对应章节）**
-- §15 第一组：业务系统开发题（01~06）
-  - 题01 满意度调查数据分析 ★★ ｜ 题02 面谈问卷生成 ★★★ ｜ 题03 制度RAG检索 ★★★★
-  - 题04 合同智能审查 ★★★ ｜ 题05 法规收集爬虫 ★★★ ｜ 题06 外部风险收集 ★★★
-- §16 第二组：开发阶段AI评审工具题（07~11，含组内共通硬性要求）
-  - 题07 需求文档评审 ★★★ ｜ 题08 设计书评审 ★★★★ ｜ 题09 代码评审 ★★★
-  - 题10 测试用例评审 ★★★★ ｜ 题11 成果物评审 ★★
-
-**第五部分 · 自选题路径**
-- 见 §1.7（事前登记制 / ≥3个功能模块闭环 / 数据脱敏或虚构）
+**第三部分 · 考核内容**
+- **结果与流程**：§3.1 结果申诉
+- **命题题**：§3.2 命题题共通要求 ｜ §3.3 命题题·第一组（01~06）｜ §3.4 命题题·第二组（07~11）
+- **自选题**：见 §1.3.4 自选题路径要求（AGENTS.md 记录核心内容 / ≥3个功能模块闭环 / 数据脱敏或虚构）
 
 ---
 
-## 1. 考核目的、方式与内容
+# 第一部分 · 考核目的
 
-### 1.1 考核目的与定位
+## 1.1 考核目的与定位
 
 L2（Level 2）是 AI 人才育成体系中的能力等级，定义为：**能独立使用 AI 编码工具完成实际业务任务**。
 
@@ -54,21 +43,7 @@ L2（Level 2）是 AI 人才育成体系中的能力等级，定义为：**能
 
 **通过本考核 = 获得 L2 能力认证**，代表持证者具备独立运用 AI 编码工具、按工程化范式完成实际任务并留下可追溯协作记录的能力。
 
-### 1.2 考核方式一览
-
-| 项目 | 内容 |
-|------|------|
-| 形式 | 个人独立考核，禁止代做 |
-| 对象 | 完成 L2 课程学习的全部受验者 |
-| 选题 | 双轨制：命题题（01~11 选一）或自选题，**任选其一** |
-| 周期 | 提交截止 **2026年9月30日（9月底）**，以仓库最后推送时间为准 |
-| 平台 | 组委会 Gitea（gittea.dev）私有仓库 `l2-assessment`，main 分支 |
-| 开发工具 | 推荐 OpenCode / Claude Code / GitHub Copilot（不作强制）；LLM API 自备 |
-| 评审流程 | 系统自动拉取仓库 → 成果物齐全性自动检测 + 跨仓库查重初筛 → 评审者按 7 维框架人工评分 → 结果反馈 |
-| 合格标准 | 合格线 **≥60 分**（命题题含难度赋分，满分最高110） |
-| 未达标处理 | 评审结论为不合格（总分<60 或 功能完整性<15 地板线）；结果申诉见 §12.4 |
-
-### 1.3 考核目标：验证什么
+### 1.1.1 考核目标：验证什么
 
 L2 考核验证的是**落地能力**而非概念理解，具体分三个层次：
 
@@ -78,18 +53,36 @@ L2 考核验证的是**落地能力**而非概念理解，具体分三个层次
 | 检验范式运用 | AI 编码工具真实用于开发全程，过程可追溯 | AGENTS.md + `_AI_USAGE_LOG.md` 全程留痕 |
 | 产生实际价值 | 成果服务本职工作或日常场景，效能提升可感知 | README 中的痛点与效果说明 |
 
-### 1.4 双轨选题制（任选其一）
+## 1.2 考核方式与合格标准
+
+### 1.2.1 考核方式一览
+
+| 项目 | 内容 |
+|------|------|
+| 形式 | 个人独立考核，禁止代做 |
+| 对象 | 完成 L2 课程学习的全部受验者 |
+| 选题 | 双轨制：命题题（01~11 选一）或自选题，**任选其一** |
+| 周期 | 提交截止 **2026年9月30日（9月底）**，以仓库最后推送时间为准 |
+| 平台 | 组委会 Gitea（gittea.dev）私有仓库 `L2-assessment`，main 分支；账号**自行注册**（见 §2.2），仓库名统一，评审拉取账号需授权（见 §2.2） |
+| 开发工具 | 推荐 OpenCode / Claude Code / GitHub Copilot（不作强制）；LLM API 自备 |
+| 评审流程 | 系统自动拉取仓库 → 成果物齐全性自动检测 + 跨仓库查重初筛 → 系统评审（AI 辅助，支持人工修正）→ 结果反馈 |
+| 合格标准 | 合格线 **≥60 分** |
+| 未达标处理 | 评审结论为不合格；结果申诉见 §3.1 |
+
+## 1.3 选题路径
+
+### 1.3.1 双轨选题制（任选其一）
 
 | 路径 | 内容 | 适用 |
 |------|------|------|
-| **A 命题题** | 从下方 1.5 的两组共11道命题题中任选 1 题 | 希望按统一命题与验收基准完成 |
+| **A 命题题** | 从下方 1.3.2 的两组共11道命题题中任选 1 题 | 希望按统一命题与验收基准完成 |
 | **B 自选题** | 结合日常工作/生活中的效率痛点，实现一个提效工具或 Skill | 已有明确痛点，希望解决自己的实际问题 |
 
-两条路径共用同一评分框架，合格线均为 **≥60 分**。差异仅在得分上限：命题题按所选题目难度追加赋分（★★★满分105 / ★★★★满分110），自选题按基准100分计——即高难度命题拥有更大的失分容错空间，这是有意的难度补偿设计，选择前请知悉。
+两条路径共用同一套评审要求，合格标准均为 **≥60 分**。差异仅在得分上限：命题题按所选题目难度追加赋分（★★★满分105 / ★★★★满分110），自选题按基准100分计——即高难度命题拥有更大的失分容错空间，这是有意的难度补偿设计，选择前请知悉。
 
-### 1.5 命题题内容一览
+### 1.3.2 命题题内容一览
 
-命题题共两组 11 道（下方 §15、§16 为完整权威定义）：
+命题题共两组 11 道（下方 §3.3、§3.4 为完整权威定义）：
 
 **第一组｜业务系统开发题（01~06）**
 
@@ -114,42 +107,50 @@ L2 考核验证的是**落地能力**而非概念理解，具体分三个层次
 | 10 | 测试用例AI评审工具 | 测试设计 | ★★★★ | 110 |
 | 11 | 成果物AI评审工具 | 交付验收 | ★★ | 100 |
 
-> 各题的业务需求、验收基准、样本数据与植入问题要求的完整定义各题完整需求定义见 §15、§16（本文档最后两章），无需查阅其他文档。
+> 各题的业务需求、验收基准、样本数据与植入问题要求的完整定义见 §3.3、§3.4（本文档最后两章），无需查阅其他文档。
 
-### 1.6 命题题路径要求
+### 1.3.3 命题题路径要求
 
 - 从两组共11道题中任选 1 题，按该题的业务需求、验收基准、样本数据要求执行
 - README 首页标注「**选题路径：命题**」及「**选题编号与标题**」（如：命题 08｜设计书AI评审工具）
 
-### 1.7 自选题路径要求
+### 1.3.4 自选题路径要求
 
 自选题须满足以下三条约束：
 
-1. **事前登记制**：开工前向组委会提交题目登记（一句话题目名称 + 痛点描述 + 预期功能清单），经确认后方可开始开发。登记同时用于避免与他人撞题。提交渠道与登记模板由组委会另行通知。登记的功能清单具有约束力：README 功能声明不得低于登记范围的核心功能；确需缩减的，须在截止日前向组委会更新登记并说明理由，未经更新的缩减部分按未实现计分。开发起始时间以登记确认后的首次 git commit 为准，早于确认的开发记录不影响评审，但须在 AGENTS.md 中说明。
+1. **AGENTS.md 记录自选题核心内容**：自选题须在 AGENTS.md 中讲清楚以下核心内容——
+   - **选题名称与痛点背景**：一句话概括选题 + 解决什么痛点、给谁用
+   - **预期功能清单**：计划实现的核心功能模块（不低于「规模下限」要求）
+   - **功能边界**：明确哪些功能已实现、哪些不实现（诚实声明）
+   - **开发起始时间**：以首次 `git commit` 时间为准，早于确认的开发记录不影响评审
+   
+   AGENTS.md 中的功能清单具有约束力：README 功能声明不得低于其记录的核心功能；确需缩减的，须在 AGENTS.md 中说明缩减范围与理由，未说明的缩减部分按未实现计分。
 2. **规模下限**：至少包含「输入处理 → 核心逻辑 → 结果呈现」的完整闭环，功能模块不少于 **3 个**。功能模块指用户可感知的独立功能单元（如「文件导入」「规则配置」「报告导出」各计一个），纯工具函数与界面装饰不计入模块数；整体规模应明显超出单脚本范畴（通常数百行及以上）。
 3. **信息安全红线**：禁止使用真实业务数据、客户数据、公司内部代码作为样本或素材；示例数据必须脱敏或虚构。
 
 README 首页标注「**选题路径：自选**」，并附痛点背景与预期效果说明。
 
-### 1.8 选题声明（必填）
+### 1.3.5 选题声明（必填）
 
 无论哪条路径，README 首页须包含：
 
 ```
 选题路径：命题 / 自选
-选题名称：（命题题填编号与标题；自选题填登记的题目名称）
+选题名称：（命题题填编号与标题；自选题填 AGENTS.md 中记录的题目名称）
 使用AI工具：（实际使用的AI编码工具，如 OpenCode / Claude Code / Copilot）
 ```
 
 ---
 
-## 2. 开发工具与模型
+# 第二部分 · 提交要求
+
+## 2.1 开发工具与模型
 
 | 项目 | 要求 |
 |------|------|
 | AI编码工具 | **不作强制指定**，推荐使用 **OpenCode / Claude Code / GitHub Copilot** 之一，也可自行选择其他同类工具 |
 | 工具记录 | 实际使用的工具及版本须在 README「使用AI工具」处声明，并在 AGENTS.md 中记录运用方式 |
-| LLM 模型/API | 由受验者自备（推荐 DeepSeek 等免费方案）；海外服务使用注意信息安全（见 §9） |
+| LLM 模型/API | 由受验者自备（推荐 DeepSeek 等免费方案）；海外服务使用注意信息安全（见 §2.7） |
 | 课程技术 | VibeCoding / Superpowers / SpecKit / Skill / MCP自动化测试中**至少选 1 项**运用于开发过程，并在 AGENTS.md 记录运用方式 |
 | LLM异常处理 | 凡涉及 LLM/API 调用的功能，必须具备以下至少一项防护：超时设置、异常捕获、降级或显式错误提示。缺失将在功能完整性维度扣分 |
 | 评审期LLM支持 | 组委会为评审环节统一提供 DeepSeek API Key；同时受验者须在 `data/` 中留存关键 LLM 功能的真实响应样例，保证无 Key 环境也能核验核心逻辑 |
@@ -158,49 +159,59 @@ README 首页标注「**选题路径：自选**」，并附痛点背景与预期
 
 ---
 
-## 3. Gitea 账号规范
+## 2.2 Gitea账号与仓库
+
+> **本次考核由受验者自行注册 Gitea 账号**，组委会不统一下发账号。请按下述规则注册并完成授权登记，评审系统才能正常拉取你的仓库。
 
 | 项目 | 要求 |
 |------|------|
-| 用户名 | 使用组委会下发的**独立账号**，**禁止修改、禁止换绑** |
-| 密码 | 使用组委会下发的初始密码，**请勿修改**。修改后评审系统将无法拉取仓库，影响评审结果 |
+| 注册方式 | 受验者**自行注册**组委会 Gitea（`gittea.dev`）账号 |
+| 用户名 | **统一使用本人员工编号**（如 `SD0102`），便于身份识别与系统拉取；**注册后禁止修改、禁止换绑** |
+| 用户名格式注意 | Gitea 用户名**不能以数字开头**；若员工编号以数字开头（如 `0102`），请使用小写前缀形式（如 `sd0102`）注册 |
+| 密码 | 注册后自行保管，**请勿忘记**；密码修改不影响评审（评审系统使用授权协作者方式拉取，见下） |
 | 账号用途 | 仅用于本次 L2 考核成果物存放，禁止外借、禁止多账号混用 |
+| **授权登记** | 注册完成后，须将以下信息提交组委会登记（登记方式与渠道由组委会另行通知）：**员工编号、Gitea 用户名、仓库名**。未登记将无法拉取，按未提交处理 |
 
-> 评审系统使用每人的账号凭据自动拉取仓库；凭据被修改即拉取失败，按未提交处理。
+> **拉取机制（重要）**：评审系统使用组委会专用的**评审拉取账号**（只读）克隆各受验者仓库。请每位受验者**将自己仓库的「只读（Reporter）」协作权限授予评审拉取账号**。评审拉取账号名与操作指引随**报名确认通知**一并公布（未收到请联系组委会）。未授权 → 系统无法克隆 → 按未提交处理。
 
 ---
 
-## 4. 仓库规范
+### 2.2.1 仓库规范
 
 | 项目 | 要求 |
 |------|------|
-| 平台 | 统一使用组委会 Gitea（`gittea.dev`） |
-| **仓库名称** | **统一为 `l2-assessment`**（连字符，无空格） |
-| 可见性 | **Private（私有）**；评审系统使用下发凭据拉取，无需公开 |
+| 平台 | 统一使用组委会 Gitea（`gittea.dev`），**自注册账号**（见 §2.2） |
+| **仓库名称** | **统一为 `L2-assessment`**（连字符，无空格，英文） |
+| 可见性 | **Private（私有）**；评审系统使用评审拉取账号（协作者只读权限）克隆，无需公开 |
 | 默认分支 | **`main`** |
 | 提交方式 | 截止前 `git push` 到 main 分支，评审以仓库最新提交为准 |
-| 提交历史 | 鼓励小步多次 commit、保留完整演进历史（见 §10 过程真实性） |
+| 提交历史 | 鼓励小步多次 commit、保留完整演进历史（见 §2.8 过程真实性） |
+| **授权协作者** | **必须**将评审拉取账号（见 §2.2）添加为本仓库**只读（Reporter）**协作者；未授权将无法拉取，按未提交处理 |
+
+> 拉取 URL 格式：`https://gittea.dev/<你的用户名>/L2-assessment.git`（用户名 = 员工编号，见 §2.2）。评审系统将按此格式 + 登记信息自动拉取。
 
 ---
 
-## 5. 成果物清单与放置规则
+## 成果物需求
 
-在 `l2-assessment` 仓库 main 分支下放入下列文件 → `git add .` → `git commit` → `git push origin main`。
+## 2.3 成果物清单与放置规则
+
+在 `L2-assessment` 仓库 main 分支下放入下列文件 → `git add .` → `git commit` → `git push origin main`。
 
 | # | 成果物 | 放置位置（命名） | 内容要求 |
 |---|--------|----------------|---------|
-| 01 | 项目说明 | 根目录 `README.md` | 按 §6 要求详细编写：选题声明、痛点背景、功能说明、效果总结、安装运行方法 |
+| 01 | 项目说明 | 根目录 `README.md` | 按 §2.4 要求详细编写：选题声明、痛点背景、功能说明、效果总结、安装运行方法 |
 | 02 | 设计文档 | 根目录 `DESIGN.md`，或 `docs/`、`design/` 目录内 | 场景与价值、开发范式流程图、架构图、关键设计决策 |
 | 03 | 源码 | 仓库根目录，或 `src/` 目录内 | 可安装、可一键运行；安装步骤、运行方法写在 README.md |
 | 04 | 测试 | `tests/` 目录内，附测试执行日志或结果截图 | 测试用例清单 + 执行结果，覆盖核心逻辑的正常与异常路径；至少 3 个用例（命题题从其题目约定） |
-| 05 | AI 使用日志 | 根目录 `_AI_USAGE_LOG.md` | 覆盖需求/设计/编码/测试全环节，格式见 §8 |
-| 06 | AI 协作记录 | 根目录 `AGENTS.md` | 技术运用过程、prompt原文、人工修正点、问题与对策（见 §8） |
+| 05 | AI 使用日志 | 根目录 `_AI_USAGE_LOG.md` | 覆盖需求/设计/编码/测试全环节，格式见 §2.6 |
+| 06 | AI 协作记录 | 根目录 `AGENTS.md` | 技术运用过程、prompt原文、人工修正点、问题与对策（见 §2.6） |
 | 07 | 样本数据 | `data/`、`sample/` 或 `fixtures/` 目录 | 运行所需样例数据；命题题须含该题要求的缺陷标注清单等；全部数据须脱敏或虚构 |
 
 **仓库目录结构**
 
 ```
-l2-assessment/                         # 仓库根目录（main 分支）
+L2-assessment/                         # 仓库根目录（main 分支）
 ├── README.md                          # 01 项目说明
 ├── DESIGN.md                          # 02 设计文档（含架构图、范式图）
 ├── src/                               # 03 源码
@@ -216,41 +227,41 @@ l2-assessment/                         # 仓库根目录（main 分支）
 > 放置规则：
 > - 成果物须位于根目录或上表约定目录；评审系统不递归到任意深层目录。
 > - 文件名/目录名用 ASCII 小写字母、数字、连字符、下划线，禁止空格与中文。
-> - **不要求提交演示视频**，亦不接收仓库外的任何补充材料；Web 类作品按 §11 登记 service_url，供评审实测验证。
+> - **不要求提交演示视频**，亦不接收仓库外的任何补充材料；Web 类作品按 §2.9 登记 service_url，供评审实测验证。
 
 ---
 
-## 6. README 编写要求（重点）
+## 2.4 README 编写要求（重点）
 
 README 是评审者了解作品的第一个入口，**必须尽可能说清楚**。以下内容缺一项即视为项目说明不完整，对应维度扣分：
 
-### 6.1 痛点背景（为什么做）
+### 2.4.1 痛点背景（为什么做）
 - 解决什么问题、给谁用（目标用户/场景）
 - 现状是怎么做的、低效在哪里（自选题必须有此节，命题题为该题业务场景的理解分析）
 
-### 6.2 功能说明（做了什么）
+### 2.4.2 功能说明（做了什么）
 - 功能清单逐条列出，每条说明：功能是什么、怎么用、输入输出是什么
 - 有界面/命令行交互的，给出操作示例（示例命令、调用方式均可）
 - 明确说明哪些功能已实现、哪些未实现（诚实声明优于含糊其辞）
 
-### 6.3 效果总结（带来了什么价值）
+### 2.4.3 效果总结（带来了什么价值）
 - 提效对比：改造前后耗时对比、错误率变化等，能用简单数字说明最好（如「原来人工核对一份需 30 分钟，现在 2 分钟」）
 - **提效数字须附测量方式**（如何计时、对比的场景与步骤说明），关键原始记录建议放入 `tests/` 或 `data/`；无测量依据的夸大数据将在可信度上扣分
 - **命题题无真实历史基线时的诚实做法**：基于模拟场景做小样本试用并如实记录测得数据（试用步骤+计时即可）；**禁止凭空编造未经实测的数字**
 - 无法量化的，说明解决了的具体痛点和实际使用反馈
 
-### 6.4 安装与运行（怎么跑起来）
+### 2.4.4 安装与运行（怎么跑起来）
 - 环境要求（OS、语言版本、依赖）
 - 安装步骤（逐步可复制执行）
 - 运行方法（启动命令、参数说明）
 - 规则配置说明：涉及检查规则/标准配置的工具，说明配置文件位置与修改方法
 
-### 6.5 效果与功能的一致性
+### 2.4.5 效果与功能的一致性
 - README 声称的功能须能在代码和运行中找到对应实现；评审存在「声称 vs 实测」交叉验证，不符将扣分
 
 ---
 
-## 7. 设计文档要求
+## 2.5 设计文档要求
 
 | 内容项 | 说明 |
 |--------|------|
@@ -261,9 +272,9 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 
 ---
 
-## 8. AI 协作过程留痕（评审重点）
+## 2.6 AI 协作过程留痕（评审重点）
 
-### 8.1 AI 使用日志（`_AI_USAGE_LOG.md`）
+### 2.6.1 AI 使用日志（`_AI_USAGE_LOG.md`）
 
 每条记录包含以下字段：
 
@@ -282,7 +293,7 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 每次创建或修改代码文件后，在项目根目录的 `_AI_USAGE_LOG.md` 中追加一条记录，必须包含：日期时间、范式步骤、修改摘要、涉及文件、使用模型
 ```
 
-### 8.2 AI 协作记录（`AGENTS.md`）
+### 2.6.2 AI 协作记录（`AGENTS.md`）
 
 记录内容：
 
@@ -319,7 +330,7 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 
 ---
 
-## 9. 通用命名与内容红线
+## 2.7 通用命名与内容红线
 
 1. **文件名**：统一使用 ASCII 小写字母、数字、连字符（-）或下划线（_）；禁止空格、中文、全角字符、特殊符号。**例外**：本规范约定的固定命名文件（`README.md`、`DESIGN.md`、`_AI_USAGE_LOG.md`、`AGENTS.md` 等）不受小写限制。
 2. **禁止提交**：密钥/token/密码/`.env` 等敏感文件；构建产物（`node_modules/`、`dist/`、`build/`、`target/`、`__pycache__/`）；单个 >50MB 的二进制文件。
@@ -329,7 +340,7 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 
 ---
 
-## 10. 独立完成与查重红线
+## 2.8 独立完成与查重红线
 
 **本次考核为个人独立考核。** 评审系统将对全部提交做跨仓库相似度初筛，以下情形将被标记并进入人工认定：
 
@@ -347,14 +358,14 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 
 - 初筛告警由评审者人工复核认定；单次全量 push 等行为信号本身**不构成违规认定**，仅作为复核参考——被标记者应能在 AGENTS.md 与 git 历史中给出独立完成的依据
 - **查实抄袭：本题按 0 分处理，处理结果记入考核档案**
-- 允许查阅公开资料与使用 AI 生成，但须如实记录（见 §8）；未记录的他人代码片段视为抄袭
+- 允许查阅公开资料与使用 AI 生成，但须如实记录（见 §2.6）；未记录的他人代码片段视为抄袭
 - 组委会保留对可疑情形**约谈核实**的权利：可要求受验者现场讲解任意一段核心实现的思路与取舍；拒绝配合或讲解与提交代码明显不符的，按查实抄袭处理
 
 ---
 
-## 11. 源码可运行前提（强制）
+## 2.9 源码可运行前提（强制）
 
-**源码无法按 README 启动运行的，属重大缺陷：功能完整性维度最高计 10 分、测试用例与测试结果维度最高计 5 分，并在评语中标注「不可运行」。仅当失败原因明确属于评审环境所致（如内网专用依赖），登记后改期复验。**
+**源码无法按 README 启动运行的，属重大缺陷，并在评语中标注「不可运行」。仅当失败原因明确属于评审环境所致（如内网专用依赖），登记后改期复验。**
 
 - 依赖随仓库可复现（含依赖清单/锁文件），不依赖外部不可达资源
 - Web 类作品建议在 README 登记 service_url，供评审实测验证
@@ -364,45 +375,17 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 
 ---
 
-## 12. 考核标准
+## 2.10 提交前自查清单
 
-### 12.1 评分维度与评审要点
-
-评审基于共通 7 维框架，满分 100 分：
-
-| 维度 | 分值 | 评审要点 |
-|------|:---:|---------|
-| 功能完整性 | 30 | 核心需求是否全部实现、主要功能路径可运行；命题题按该题验收基准表逐项评定，自选题按README声明功能清单核对实现情况 |
-| 设计文档 | 10 | 架构图清晰完整、范式流程图与AI日志逐步对应、关键设计决策有理由有取舍 |
-| 测试用例与测试结果 | 10 | 用例覆盖正常与异常路径、数量达标、执行结果真实可复现 |
-| AI协作过程记录 | 15 | prompt原文完整可追溯、人工修正点如实记录、AI日志字段齐全且与git历史一致（日志造假直接扣分） |
-| 技术选型与范式运用 | 15 | 课程技术至少1项真实运用且深度合理（非表面套用）、工具链选型有理由 |
-| 代码质量 + README | 10 | 结构清晰、命名规范、无硬编码密钥；README四部分（痛点/功能/效果/运行）完整说清 |
-| 业务场景理解与需求分析 | 10 | 对痛点理解准确、需求分析到位、效果总结可信不自夸 |
-
-### 12.2 合格线与赋分
-
-- **合格线：≥60 分**；命题题另按所选题目的难度赋分（★★★+5 / ★★★★+10），自选题按基准 100 分计（差异说明见 §1.4）
-- **功能完整性评分锚点**：命题题按该题验收基准表逐项评定；自选题按 README 声明的功能清单逐项核对实现情况评定（结合「声称 vs 实测」验证，未实现或与声明不符的功能不计分）
-- **功能完整性地板线**：该维度得分低于 15 分（不足满分一半）时，无论总分多少均判为**不合格**——防止「文档精美、功能空壳」的提交过线
-
-### 12.3 结果申诉
-
-- 对评分结果或查重认定有异议的，可在收到结果之日起 **3 个工作日内**向组委会提交一次复核申请（列明异议点与依据）
-- 由**未参与原评审**的人员进行复核，**5 个工作日内**书面答复；复核结论为最终结论
-- 复核仅核查评分是否与本规范及所选题目验收基准相符，不进行整体重新评审
-
----
-
-## 13. 提交前自查清单
-
-- [ ] 已在截止时间前 `git push` 到 `l2-assessment` 的 main 分支
-- [ ] 已用组委会账号登录 Gitea，密码未修改
+- [ ] 已在截止时间前 `git push` 到 `L2-assessment` 的 main 分支
+- [ ] 已用**自注册**账号登录 Gitea（用户名 = 员工编号，见 §2.2）
+- [ ] 已将员工编号 / Gitea 用户名 / 仓库名**提交登记**给组委会
+- [ ] 已将**评审拉取账号**添加为本仓库**只读（Reporter）协作者**（见 §2.2），并确认其可访问
 - [ ] README 首页有选题声明（路径/名称/使用AI工具）
-- [ ] （自选题）已完成事前登记，且README功能声明不低于登记范围的核心功能
+- [ ] （自选题）AGENTS.md 已记录选题名称、痛点背景、功能清单与功能边界，README 功能声明不低于其中核心功能
 - [ ] README 含完整的痛点背景、功能说明、效果总结、安装运行四部分
 - [ ] 效果总结中的提效数字已附测量方式与原始记录
-- [ ] 成果物齐全且按 §5 放置：README、DESIGN.md（含范式图与架构图）、src/、tests/、`_AI_USAGE_LOG.md`、AGENTS.md、data/ 样本数据
+- [ ] 成果物齐全且按 §2.3 放置：README、DESIGN.md（含范式图与架构图）、src/、tests/、`_AI_USAGE_LOG.md`、AGENTS.md、data/ 样本数据
 - [ ] `_AI_USAGE_LOG.md` 字段完整，范式步骤与范式图一致
 - [ ] AGENTS.md 含 prompt原文、人工修正点、问题与对策
 - [ ] 课程技术（VibeCoding/Skill/Superpowers/SpecKit/MCP）至少 1 项已运用于开发过程并在 AGENTS.md 记录运用方式
@@ -413,12 +396,12 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 
 ---
 
-## 14. 违规后果
+## 2.11 违规后果
 
 | 情形 | 后果 |
 |------|------|
 | 超过截止时间未提交/未push | 迟交 1~3 个工作日扣 5 分，4~7 个工作日扣 10 分；超 7 个工作日按 0 分处理、不再评审 |
-| 仓库名、分支、凭据不符合规范 | 评审系统无法拉取，按未提交处理 |
+| 仓库名、分支不符合规范，或**未登记 / 未授权评审拉取账号** | 评审系统无法拉取，按未提交处理 |
 | 必填成果物缺失或命名不符 | 对应成果物判定为未提交，相关维度扣分 |
 | README 声称功能与实测不符 | 真实性扣分 |
 | AI 日志缺失或空白 | 相关维度扣分 |
@@ -428,18 +411,39 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 
 ---
 
+# 第三部分 · 考核内容
+
+## 3.1 结果申诉
+
+- 对评分结果或查重认定有异议的，可在收到结果之日起 **3 个工作日内**向组委会提交一次复核申请（列明异议点与依据）
+- 由**未参与原评审**的人员进行复核，**5 个工作日内**书面答复；复核结论为最终结论
+- 复核仅核查评分是否与本规范及所选题目验收基准相符，不进行整体重新评审
+
 ---
 
-## 15. 命题题详细需求 · 第一组：业务系统开发题（01~06）
+## 3.2 命题题共通要求（每题均适用）
 
-> 本组6道题为「业务系统」类选题（数据统计/RAG检索/合同审查/爬虫/风险监控）。选定某题后，依次细读该题的【业务场景 → 考核技术 → 业务需求 → 验收基准 → 提交物清单 → 评分标准】六节。
-> 各题【提交物清单】为该题专属补充项；通用7项成果物（README / DESIGN / src / tests / `_AI_USAGE_LOG.md` / `AGENTS.md` / data样本数据）以 §5 为准，每题均须提交。> 各类**评分型指标**（置信度、影响度、准确率、「高频」阈值等）的具体计算口径由受验者自行定义，但必须在设计文档中写明；验收时以「口径清晰 + 结果可复现」为准，不要求与任何标准答案一致。涉及「与公司业务相关性」评估的题目，受验者须在 README 中给出虚构的公司画像（行业、规模、主要业务范围）作为统一评估基准。
+**成果物**：通用 7 项成果物（README / DESIGN / src / tests / `_AI_USAGE_LOG.md` / `AGENTS.md` / data 样本数据）以 §2.3 为准，每题均须提交。各题仅在「本题专属要求」中列差异项，未列出的均按 §2.3 通用要求执行。
 
+**考核技术（至少选 1 项）**：从以下 5 种课程技术中至少选 1 项真实运用于开发，并在 AGENTS.md 中记录运用方式（各技术通用的记录要求见 §2.1 与 §2.6）：
 
+| 技术 | 通用要求 |
+|------|---------|
+| **VibeCoding** | 记录 prompt 原文 / 生成过程 / 人工修正点 / 遇到的问题与对策 |
+| **SpecKit** | 先编写规格文档再实现；记录规格定义过程 / spec 与实现的对应关系 / 边界情况处理策略 |
+| **Skill** | 将功能封装为独立 Skill；记录各 Skill 接口定义 / 调用链路 / 复用方式 |
+| **Superpowers** | 用 Superpowers 组合构建管道；记录注册与组合逻辑 / 各 Superpower 职责边界 |
+| **MCP自动化测试** | 关键路径用 MCP Server 自动测试；记录 Server 配置 / 测试用例定义 / 执行结果与覆盖率 |
 
-> 本组6道题为「业务系统」类选题（数据统计/RAG检索/合同审查/爬虫/风险监控）。选定某题后，依次细读该题的【业务场景 → 考核技术 → 业务需求 → 验收基准 → 提交物清单 → 评分标准】六节。
-> 各题【提交物清单】为该题专属补充项；通用7项成果物（README / DESIGN / src / tests / `_AI_USAGE_LOG.md` / `AGENTS.md` / data样本数据）以 §5 为准，每题均须提交。> 各类**评分型指标**（置信度、影响度、准确率、「高频」阈值等）的具体计算口径由受验者自行定义，但必须在设计文档中写明；验收时以「口径清晰 + 结果可复现」为准，不要求与任何标准答案一致。涉及「与公司业务相关性」评估的题目，受验者须在 README 中给出虚构的公司画像（行业、规模、主要业务范围）作为统一评估基准。
+> **技术组合规则**：鼓励在同一题中组合多项技术（如 VibeCoding 做前端 + Skill 做统计引擎 + MCP 做测试），组合使用在评分中会有加分。各题「考核技术」一节仅列出**本题推荐运用**的技术与示例，不代表限定。
 
+**评分型指标**：各类**评分型指标**（置信度、影响度、准确率、「高频」阈值等）的具体计算口径由受验者自行定义，但必须在设计文档中写明；验收时以「口径清晰 + 结果可复现」为准，不要求与任何标准答案一致。涉及「与公司业务相关性」评估的题目，受验者须在 README 中给出虚构的公司画像（行业、规模、主要业务范围）作为统一评估基准。
+
+## 3.3 命题题 · 第一组：业务系统开发题（01~06）
+
+### 3.3.1 组定位
+
+本组 6 道题为「业务系统」类选题（数据统计/RAG检索/合同审查/爬虫/风险监控）。选定某题后，依次细读该题的【业务场景 → 业务需求 → 验收基准 → 本题专属要求】各节。
 
 ### 题01｜年度满意度调查数据的自动处理与分析
 
@@ -456,15 +460,10 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 
 #### 考核技术（至少选1项）
 
-| 技术 | 本题中的运用示例 | AGENTS.md中需记录的内容 |
-|------|----------------|------------------------|
-| **VibeCoding** | 通过提示词直接生成模板解析+统计+看板的全套功能 | 使用的prompt原文 / 生成过程 / 人工修正点 / 遇到的问题与对策 |
-| **SpecKit** | 先编写规格文档再实现，覆盖所有边界情况 | 规格定义过程 / spec与实现的对应关系 / 边界情况处理策略 |
-| **Skill** | 将「模板解析」「统计引擎」「图表生成」封装为独立Skill | 各Skill的接口定义 / 调用链路 / 复用方式 |
-| **Superpowers** | 用Superpowers组合方式构建统计管道 | Superpower的注册与组合逻辑 / 各Superpower的职责边界 |
-| **MCP自动化测试** | 关键路径通过MCP Server自动测试验证 | MCP Server配置 / 测试用例定义 / 执行结果与覆盖率 |
-
-> **技术组合规则**：至少选择1项技术。鼓励在同一题中组合多项技术（如：VibeCoding做前端 + Skill做统计引擎 + MCP做测试），组合使用在评分中会有加分。
+> 课程技术共同要求见 §3.2 前言（VibeCoding/SpecKit/Skill/Superpowers/MCP 五选一，鼓励组合加分）。本题推荐运用：
+> - **VibeCoding**：通过提示词直接生成模板解析+统计+看板的全套功能
+> - **Skill**：将「模板解析」「统计引擎」「图表生成」封装为独立Skill
+> - **MCP自动化测试**：关键路径通过MCP Server自动测试验证
  
 #### 业务需求
 
@@ -498,7 +497,8 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 - 根据分析结论自动提出改善建议（如「XX部门的沟通满意度连续两年下降，建议加强部门内定期的1on1面谈」）
 - 改善建议应可量化、可执行、针对具体部门
 
-- 实现方式不限：规则引擎或 LLM 生成均可；若使用 LLM，须包含超时与异常降级处理（见 §2）。
+- 实现方式不限：规则引擎或 LLM 生成均可；若使用 LLM，须包含超时与异常降级处理（见 §2.1）。
+
 #### 验收基准
 
 | 验收项 | 最低合格线 | 满分标准 | 验证方式 |
@@ -509,31 +509,11 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 | 权限隔离 | 部门管理员看不到其他部门数据 | 纯前端方案说明生产替代方案 | 检查AGENTS.md中的权限说明 |
 | 分析深度 | 能标识得分最低的1-2个维度 | 能识别下降趋势、给出具体改善建议 | 在样本数据中植入下降维度，验证分析结果 |
 
-#### 提交物清单
+#### 本题专属要求（其余按 §3.2 通用要求）
 
-| # | 提交物 | 内容要求 | 必须/可选 |
-|---|--------|---------|----------|
-| 1 | 源代码 | 完整可运行的项目代码 | **必须** |
-| 2 | README | 环境要求（OS、语言版本、依赖）、安装步骤、运行方法、功能说明 | **必须** |
-| 3 | 设计文档 | 架构图 / 数据流图 / 技术选型理由 / 关键设计决策 | **必须** |
-| 4 | 测试用例 + 测试结果 | 至少3个测试用例，覆盖核心逻辑的正常路径和异常路径，附执行结果 | **必须** |
-| 5 | AGENTS.md | 技术运用过程记录、设计决策理由、遇到的问题与解决方案 | **必须** |
-| 6 | 样本数据 | 至少2个年度的模拟Excel数据（多Sheet），包含正常数据和边界数据（边界数据指：空值或缺失字段、重复记录、维度名前后不一致、评分超出合理范围等异常情形） | **必须** |
+**测试用例与测试结果**：至少 3 个测试用例，覆盖核心逻辑的正常路径和异常路径，附执行结果。
 
-#### 评分标准（100分）
-
-| 评审项 | 分值 | 评审方式 |
-|--------|:---:|---------|
-| 功能完整性 | 30分 | 模板管理5分（上传+自动识别+确认）/ 数据导入与统计10分（导入+多维度统计+年度对比）/ 权限区分5分（两种角色隔离）/ 看板展示5分（图表+下钻）/ 智能分析5分（薄弱维度识别+改善建议） |
-| 设计文档 | 10分 | 架构合理、图表达清晰、设计决策有依据 |
-| 测试用例与测试结果 | 10分 | 测试覆盖核心逻辑、测试结果可复现 |
-| AI协作过程记录（AGENTS.md） | 15分 | 技术运用过程记录完整、prompt原文和人工修正点可追溯 |
-| 技术选型与范式运用 | 15分 | 选型理由充分，VibeCoding/Skill等运用记录合理 |
-| 代码质量 + README | 10分 | 结构清晰、命名规范、README完整可运行 |
-| 业务场景理解与需求分析 | 10分 | 对满意度调查场景理解准确，需求分析到位 |
-| **合计** | **100分** | |
-
-> 本题为★★难度，满分100分，合格条件：≥60分。功能完整性30分中，模板管理(5分)+数据导入与统计(10分)+权限区分(5分)+看板展示(5分)+智能分析(5分)合计30分为必达项，为所有题目的基准难度。
+**样本数据**：至少 2 个年度的模拟 Excel 数据（多 Sheet），包含正常数据和边界数据（边界数据指：空值或缺失字段、重复记录、维度名前后不一致、评分超出合理范围等异常情形）。
 
 ---
 
@@ -553,13 +533,10 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 
 #### 考核技术（至少选1项）
 
-| 技术 | 本题中的运用示例 | AGENTS.md中需记录的内容 |
-|------|----------------|------------------------|
-| **Skill** | 将「规则引擎」「问卷生成」「话题分类」「共性问题提取」「改善建议生成」封装为独立Skill | 各Skill的接口定义 / 规则与LLM的分工 / 准确率验证 |
-| **MCP自动化测试** | 对规则判定逻辑和LLM输出质量进行自动化测试验证 | MCP Server配置 / 测试用例设计 / 准确率基准 |
-| **VibeCoding** | 用提示词直接实现导入→规则配置→分析→问卷生成→看板的完整流程 | 使用的prompt原文 / 生成过程 / 规则与LLM的分工策略 |
-| **Superpowers** | 用Superpowers组合构建分析管道（规则引擎 + LLM分析 + 报告生成） | Superpower的注册与组合逻辑 / 各Superpower的职责边界 |
-| **SpecKit** | 先定义规则配置规范、分析策略、输出格式规格 | 规格定义过程 / 规则与spec的对应关系 |
+> 课程技术共同要求见 §3.2 前言（VibeCoding/SpecKit/Skill/Superpowers/MCP 五选一，鼓励组合加分）。本题推荐运用：
+> - **Skill**：将「规则引擎」「问卷生成」「话题分类」「共性问题提取」「改善建议生成」封装为独立Skill
+> - **MCP自动化测试**：对规则判定逻辑和LLM输出质量进行自动化测试验证
+> - **VibeCoding**：用提示词直接实现导入→规则配置→分析→问卷生成→看板的完整流程
 
 #### 业务需求
 
@@ -617,32 +594,11 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 | 共性问题提取 | 植入5个高频话题，至少检出3个 | 全部检出且噪音少 | mock数据中控制话题分布，验证提取结果 |
 | 改善建议相关性 | 建议与发现的问题主题相关 | 建议可量化、可执行、针对具体部门 | 检查建议是否针对特定部门、有具体行动描述 |
 
-#### 提交物清单
+#### 本题专属要求（其余按 §3.2 通用要求）
 
-| # | 提交物 | 内容要求 | 必须/可选 |
-|---|--------|---------|----------|
-| 1 | 源代码 | 完整可运行的项目代码 | **必须** |
-| 2 | README | 环境要求（含LLM配置）、安装步骤、运行方法、功能说明 | **必须** |
-| 3 | 设计文档 | 架构图 / 规则引擎设计 / 规则与LLM的分工策略 / 分析模型选择依据 | **必须** |
-| 4 | 测试用例 + 测试结果 | 至少3个测试用例，覆盖规则配置、话题分类、共性问题提取 | **必须** |
-| 5 | AGENTS.md | 技术运用过程记录、规则调优过程、分类调优过程、LLM调优日志 | **必须** |
-| 6 | 样本数据 | 至少2个年度的满意度调查模拟Excel（用于验证「前年比下降」规则） + 至少30条模拟面谈记录（覆盖5个话题分类、3个部门） | **必须** |
+**测试用例与测试结果**：至少 3 个测试用例，覆盖规则配置、话题分类、共性问题提取。
 
-#### 评分标准（100分 + 难度赋分5分）
-
-| 评审项 | 分值 | 评审方式 |
-|--------|:---:|---------|
-| 功能完整性 | 30分 | 规则配置与低分识别10分 / 问卷生成10分 / 面谈数据导入5分 / 看板展示5分（智能分析的分数含在上述各项中：话题分类准确率→规则配置分、共性问题提取→问卷生成分、改善建议→看板展示分，不单独计分） |
-| 设计文档 | 10分 | 架构合理，规则与LLM分工策略清晰，选型有依据 |
-| 测试用例与测试结果 | 10分 | 覆盖规则配置、话题分类、共性问题提取，结果可复现 |
-| AI协作过程记录（AGENTS.md） | 15分 | 过程记录完整，规则调优、分类调优、LLM调优日志可追溯 |
-| 技术选型与范式运用 | 15分 | Skill/Superpowers/VibeCoding等选型理由充分 |
-| 代码质量 + README | 10分 | 结构清晰、命名规范、README完整 |
-| 业务场景理解与需求分析 | 10分 | 对面谈调查场景理解准确，需求分析到位 |
-| 难度赋分 | 5分 | ★★★难度追加 |
-| **合计** | **105分** | |
-
-> 本题为★★★难度，满分105分，合格条件：≥60分。
+**样本数据**：至少 2 个年度的满意度调查模拟 Excel（用于验证「前年比下降」规则）+ 至少 30 条模拟面谈记录（覆盖 5 个话题分类、3 个部门）。
 
 ---
 
@@ -663,15 +619,10 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 
 #### 考核技术（至少选1项）
 
-| 技术 | 本题中的运用示例 | AGENTS.md中需记录的内容 |
-|------|----------------|------------------------|
-| **Superpowers** | 用Superpowers组合构建RAG管道（文档加载 + 文本分割 + 向量化 + 检索 + 生成回答 + 质量评估） | Superpower的注册与组合逻辑 / 各环节参数调优 / 检索策略切换逻辑 |
-| **MCP自动化测试** | 对检索准确率、检索策略切换、质量评估逻辑进行自动化测试 | MCP Server配置 / 测试集构建 / 评估指标设计 / 各策略对比测试 |
-| **Skill** | 将「文档解析」「多种检索策略」「chunk管理」「质量评估」「制度关联」「分析看板」封装为独立Skill | 各Skill的接口定义 / embedding模型选择理由 / chunk策略 / 检索策略对比 |
-| **VibeCoding** | 用提示词直接实现文档上传→多种检索→质量评估→分析看板的完整流程 | 使用的prompt原文 / 生成过程 / chunk大小调优 / 检索策略切换的prompt设计 |
-| **SpecKit** | 先定义文档格式规范、多检索策略规格、质量评估标准、分析指标规格 | 规格定义过程 / 各检索策略与spec的对应关系 / 质量评估标准定义 |
-
-> **难度说明**：本题为★★★★难度，满分110分（含难度赋分10分），合格线60分。功能完整性30分中，基础检索(10分)+文档管理(5分)+无法回答处理(5分)+追问(5分)合计25分为基础必达项，在此基础上实现检索策略切换、质量可视化、Chunk管理、制度关联、分析看板中的任意1~2项即可达到合格线。
+> 课程技术共同要求见 §3.2 前言（VibeCoding/SpecKit/Skill/Superpowers/MCP 五选一，鼓励组合加分）。本题推荐运用：
+> - **Superpowers**：用Superpowers组合构建RAG管道（文档加载 + 文本分割 + 向量化 + 检索 + 生成回答 + 质量评估）
+> - **MCP自动化测试**：对检索准确率、检索策略切换、质量评估逻辑进行自动化测试
+> - **Skill**：将「文档解析」「多种检索策略」「chunk管理」「质量评估」封装为独立Skill
 
 #### 业务需求
 
@@ -754,34 +705,13 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 | 制度间关联 | 关联提示与检索内容相关 | 关联准确，管理员可手动管理关联 | 检查关联条款的准确性 |
 | 分析看板 | 显示高频搜索词 | 高频词+无法回答+质量趋势+文档热度全部显示 | 提交多个查询后验证看板数据 |
 
-> 注：上表中「检索策略切换」「检索质量可视化」「Chunk管理」「制度间关联」「分析看板」5 项为**加分项（任选其一，计 5 分）**，其余各项为基础必达项。
+> 注：上表中「检索策略切换」「检索质量可视化」「Chunk管理」「制度间关联」「分析看板」5 项为**加分项（任选其一）**，其余各项为基础必达项。
 
-#### 提交物清单
+#### 本题专属要求（其余按 §3.2 通用要求）
 
-| # | 提交物 | 内容要求 | 必须/可选 |
-|---|--------|---------|----------|
-| 1 | 源代码 | 完整可运行的项目代码 | **必须** |
-| 2 | README | 环境要求（含向量数据库/LLM配置）、安装步骤、运行方法、检索策略说明 | **必须** |
-| 3 | 设计文档 | RAG架构图、chunk策略设计、多种检索策略设计、质量评估方案、制度关联策略 | **必须** |
-| 4 | 测试用例 + 测试结果 | 至少5个测试问题，覆盖常见制度查询，附各检索策略对比结果 | **必须** |
-| 5 | AGENTS.md | 技术运用过程记录、chunk大小调优过程、检索策略对比、检索准确率改善记录、质量评估设计 | **必须** |
-| 6 | 样本数据 | 至少3份模拟制度文档（中/日文各至少1份），含多级章节结构，含可关联的交叉引用 | **必须** |
+**测试用例与测试结果**：至少 5 个测试问题，覆盖常见制度查询，附各检索策略对比结果。
 
-#### 评分标准（100分 + 难度赋分10分）
-
-| 评审项 | 分值 | 评审方式 |
-|--------|:---:|---------|
-| 功能完整性 | 30分 | 必达项（25分）：文档上传与解析5分 / 基础检索功能10分 / 无法回答处理5分 / 追问功能5分。加分项（5分，任选其一）：检索策略切换5分 / 检索质量可视化5分 / Chunk管理5分 / 制度间关联提示5分 / 检索分析看板5分 |
-| 设计文档 | 10分 | RAG架构清晰、检索策略设计合理、质量评估方案有依据 |
-| 测试用例与测试结果 | 10分 | 至少5个测试问题，覆盖常见制度查询，结果可复现 |
-| AI协作过程记录（AGENTS.md） | 15分 | 过程记录完整、chunk大小调优、检索策略对比、准确率改善记录 |
-| 技术选型与范式运用 | 15分 | Superpowers/Skill/MCP等选型理由充分，RAG管道设计合理 |
-| 代码质量 + README | 10分 | 结构清晰、命名规范、README包含LLM/向量库配置说明 |
-| 业务场景理解与需求分析 | 10分 | 对人事制度检索场景理解准确，需求分析到位 |
-| 难度赋分 | 10分 | ★★★★难度追加 |
-| **合计** | **110分** | |
-
-> 本题为★★★★难度，满分110分，合格条件：≥60分。
+**样本数据**：至少 3 份模拟制度文档（中/日文各至少 1 份），含多级章节结构，含可关联的交叉引用。
 
 ---
 
@@ -804,12 +734,10 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 
 #### 考核技术（至少选1项）
 
-| 技术 | 本题中的运用示例 | AGENTS.md中需记录的内容 |
-|------|----------------|------------------------|
-| **Superpowers** | 用Superpowers组合构建审查管道（文件解析 + 条款提取 + 风险分析 + 审批流程 + 报告生成） | Superpower的注册与组合逻辑 |
-| **MCP自动化测试** | 对条款提取准确率、审查等级判断、审批流程逻辑进行自动化测试 | MCP Server配置 / 测试用例设计 / 准确率基准 |
-| **Skill** | 将「合同解析」「条款提取」「风险规则库」「审批流程」「盖章管理」「提醒引擎」封装为独立Skill | 各Skill的接口定义 / 风险规则设计 / 审批流程状态管理 |
-| **VibeCoding** | 用提示词直接实现合同上传→审查→审批→盖章→签约的全流程 | 使用的prompt原文 / 生成过程 / 审批状态管理设计 |
+> 课程技术共同要求见 §3.2 前言（VibeCoding/SpecKit/Skill/Superpowers/MCP 五选一，鼓励组合加分）。本题推荐运用：
+> - **Superpowers**：用Superpowers组合构建审查管道（文件解析 + 条款提取 + 风险分析 + 审批流程 + 报告生成）
+> - **Skill**：将「合同解析」「条款提取」「风险规则库」「审批流程」「盖章管理」「提醒引擎」封装为独立Skill
+> - **MCP自动化测试**：对条款提取准确率、审查等级判断、审批流程逻辑进行自动化测试
 
 #### 业务需求
 
@@ -865,32 +793,11 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 | 签约与到期提醒 | 到期前30天正确标识 | 签约提醒+到期提醒+禀议提醒三种均正常触发 | 设置不同金额和到期日验证提醒逻辑 |
 | 分析报告 | 统计报告内容完整 | 统计报告和签署注意点报告均正确生成 | 对比报告内容与合同数据的一致性 |
 
-#### 提交物清单
+#### 本题专属要求（其余按 §3.2 通用要求）
 
-| # | 提交物 | 内容要求 | 必须/可选 |
-|---|--------|---------|----------|
-| 1 | 源代码 | 完整可运行的项目代码 | **必须** |
-| 2 | README | 环境要求（含LLM配置）、安装步骤、运行方法、审批流程说明 | **必须** |
-| 3 | 设计文档 | 架构图、审查等级判定逻辑、风险规则库设计、审批状态机设计 | **必须** |
-| 4 | 测试用例 + 测试结果 | 至少5份合同测试用例，覆盖不同审查等级和审批流程 | **必须** |
-| 5 | AGENTS.md | 技术运用过程记录、风险规则调优过程、审批状态管理设计 | **必须** |
-| 6 | 样本数据 | 至少5份模拟合同PDF（含正常合同和有问题合同），含不同金额场景，且必须包含「距到期日 ≤30 天」与「已过期」样本各至少1份，用于当场验证待续签标识与过期状态 | **必须** |
+**测试用例与测试结果**：至少 5 份合同测试用例，覆盖不同审查等级和审批流程。
 
-#### 评分标准（100分 + 难度赋分5分）
-
-| 评审项 | 分值 | 评审方式 |
-|--------|:---:|---------|
-| 功能完整性 | 30分 | 合同上传与信息提取5分 / 审查等级判断5分 / 条款提取与风险标记10分 / 审批流程5分 / 盖章审批5分（签约与到期提醒、分析报告的分数含在上述各项中，不单独计分） |
-| 设计文档 | 10分 | 风险规则库设计合理、审批状态机设计清晰 |
-| 测试用例与测试结果 | 10分 | 至少5份合同测试用例，覆盖不同审查等级和审批流程 |
-| AI协作过程记录（AGENTS.md） | 15分 | 过程记录完整、风险规则调优过程可追溯 |
-| 技术选型与范式运用 | 15分 | Superpowers/Skill/MCP等选型理由充分，审查管道设计合理 |
-| 代码质量 + README | 10分 | 结构清晰、命名规范、README包含LLM配置说明 |
-| 业务场景理解与需求分析 | 10分 | 对合同审查场景理解准确，需求分析到位 |
-| 难度赋分 | 5分 | ★★★难度追加 |
-| **合计** | **105分** | |
-
-> 本题为★★★难度，满分105分，合格条件：≥60分。
+**样本数据**：至少 5 份模拟合同 PDF（含正常与有问题合同、不同金额场景），必须含「距到期日 ≤30 天」与「已过期」样本各至少 1 份。
 
 ---
 
@@ -910,15 +817,10 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 
 #### 考核技术（至少选1项）
 
-| 技术 | 本题中的运用示例 | AGENTS.md中需记录的内容 |
-|------|----------------|------------------------|
-| **Skill** | 将「爬虫引擎」「内容解析」「关键词筛选」「报告生成」封装为独立Skill | 各Skill的接口定义 / 爬虫策略 / 解析规则 |
-| **MCP自动化测试** | 对爬虫结果解析准确率和筛选逻辑进行自动化测试 | MCP Server配置 / 测试用例设计 / 解析准确率验证 |
-| **VibeCoding** | 用提示词直接实现爬虫+解析+筛选+报告的完整流程 | 使用的prompt原文 / 生成过程 / 反爬应对策略 |
-| **Superpowers** | 用Superpowers组合构建信息收集管道 | Superpower的注册与组合逻辑 |
-| **SpecKit** | 先定义数据源、解析规则、筛选条件的规格 | 规格定义过程 / 解析规则设计 |
-
-> **爬虫合规提示**：爬虫行为需遵守目标网站的 robots.txt 规定。AGENTS.md 中需说明爬虫策略（采集频率、并发数、User-Agent 设置）及反爬应对方案。
+> 课程技术共同要求见 §3.2 前言（VibeCoding/SpecKit/Skill/Superpowers/MCP 五选一，鼓励组合加分）。本题推荐运用：
+> - **Skill**：将「爬虫引擎」「内容解析」「关键词筛选」「报告生成」封装为独立Skill
+> - **MCP自动化测试**：对爬虫结果解析准确率和筛选逻辑进行自动化测试
+> - **SpecKit**：先定义数据源、解析规则、筛选条件的规格
 
 #### 业务需求
 
@@ -975,32 +877,11 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 | 风险判别与通知 | 高/中/低三级可区分，系统内突出显示 | 评估结果与人工评估一致率≥70%，通知自动发送 | 受验者自行标注20条模拟法规的影响度作为ground truth，对比系统评估结果，验证通知触发 |
 | 错误处理 | 数据源不可达时记录日志 | 自动重试3次后跳过，不影响其他数据源 | 故意配置无效URL验证 |
 
-#### 提交物清单
+#### 本题专属要求（其余按 §3.2 通用要求）
 
-| # | 提交物 | 内容要求 | 必须/可选 |
-|---|--------|---------|----------|
-| 1 | 源代码 | 完整可运行的项目代码 | **必须** |
-| 2 | README | 环境要求、安装步骤、运行方法、爬取频率说明 | **必须** |
-| 3 | 设计文档 | 架构图、爬虫策略设计、解析规则设计、反爬应对方案 | **必须** |
-| 4 | 测试用例 + 测试结果 | 至少3个测试用例，覆盖不同网站结构和解析场景 | **必须** |
-| 5 | AGENTS.md | 技术运用过程记录、解析规则调优过程、反爬应对经验 | **必须** |
-| 6 | 样本数据 | 模拟目标网页（至少3个不同结构的页面HTML） | **必须** |
+**测试用例与测试结果**：至少 3 个测试用例，覆盖不同网站结构和解析场景。
 
-#### 评分标准（100分 + 难度赋分5分）
-
-| 评审项 | 分值 | 评审方式 |
-|--------|:---:|---------|
-| 功能完整性 | 30分 | 数据源管理5分 / 信息自动收集10分 / 增量采集5分 / 结果展示5分 / 定期报告5分 |
-| 设计文档 | 10分 | 爬虫策略合理、解析规则设计清晰 |
-| 测试用例与测试结果 | 10分 | 至少3个测试用例，覆盖不同网站结构和解析场景 |
-| AI协作过程记录（AGENTS.md） | 15分 | 过程记录完整、反爬应对经验可追溯 |
-| 技术选型与范式运用 | 15分 | Skill/MCP等选型理由充分，爬虫引擎设计合理 |
-| 代码质量 + README | 10分 | 结构清晰、命名规范、README包含爬虫策略说明 |
-| 业务场景理解与需求分析 | 10分 | 对法规收集场景理解准确，需求分析到位 |
-| 难度赋分 | 5分 | ★★★难度追加 |
-| **合计** | **105分** | |
-
-> 本题为★★★难度，满分105分，合格条件：≥60分。
+**样本数据**：模拟目标网页（至少 3 个不同结构的页面 HTML）。
 
 ---
 
@@ -1021,15 +902,10 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 
 #### 考核技术（至少选1项）
 
-| 技术 | 本题中的运用示例 | AGENTS.md中需记录的内容 |
-|------|----------------|------------------------|
-| **Skill** | 将「爬虫引擎」「风险分类」「影响度评估」「报告生成」封装为独立Skill | 各Skill的接口定义 / 分类策略 / 评估模型 |
-| **MCP自动化测试** | 对分类准确率和风险判定逻辑进行自动化测试 | MCP Server配置 / 测试用例设计 |
-| **VibeCoding** | 用提示词直接实现收集→分类→分析→报告的完整流程 | 使用的prompt原文 / 生成过程 / 分类策略调优 |
-| **Superpowers** | 用Superpowers组合构建风险情报收集管道 | Superpower的注册与组合逻辑 |
-| **SpecKit** | 先定义风险分类体系、影响度评估标准、报告格式规格 | 规格定义过程 / 风险分类与spec的对应关系 |
-
-> **爬虫合规提示**：爬虫行为需遵守目标网站的 robots.txt 规定。AGENTS.md 中需说明爬虫策略（采集频率、并发数、User-Agent 设置）及反爬应对方案。
+> 课程技术共同要求见 §3.2 前言（VibeCoding/SpecKit/Skill/Superpowers/MCP 五选一，鼓励组合加分）。本题推荐运用：
+> - **Skill**：将「爬虫引擎」「风险分类」「影响度评估」「报告生成」封装为独立Skill
+> - **MCP自动化测试**：对分类准确率和风险判定逻辑进行自动化测试
+> - **SpecKit**：先定义风险分类体系、影响度评估标准、报告格式规格
 
 #### 业务需求
 
@@ -1091,56 +967,26 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 | 定期报告 | 报告自动生成、格式规范 | 报告含本期采集的全部数据（不限高关注法规），支持日报和周报两种粒度，Markdown报告内容完整、历史报告可查 | 检查报告内容与仪表盘数据一致 |
 | 全局关键词 | 高关注关键词能正确标记 | 包含/排除规则同时生效 | 配置关键词后验证过滤和标记结果 |
 
-#### 提交物清单
+#### 本题专属要求（其余按 §3.2 通用要求）
 
-| # | 提交物 | 内容要求 | 必须/可选 |
-|---|--------|---------|----------|
-| 1 | 源代码 | 完整可运行的项目代码 | **必须** |
-| 2 | README | 环境要求、安装步骤、运行方法 | **必须** |
-| 3 | 设计文档 | 架构图、风险分类体系设计、影响度评估标准、爬虫策略 | **必须** |
-| 4 | 测试用例 + 测试结果 | 至少3个测试用例，覆盖不同风险类型和影响度评估 | **必须** |
-| 5 | AGENTS.md | 技术运用过程记录、分类策略调优、影响度评估调整 | **必须** |
-| 6 | 样本数据 | 模拟信息源HTML/RSS（至少3个，覆盖不同风险领域），条目须包含不同发布日期以支撑趋势对比；若实现API类型信息源，附mock服务脚本 | **必须** |
+**测试用例与测试结果**：至少 3 个测试用例，覆盖不同风险类型和影响度评估。
 
-#### 评分标准（100分 + 难度赋分5分）
-
-| 评审项 | 分值 | 评审方式 |
-|--------|:---:|---------|
-| 功能完整性 | 30分 | 信息源管理5分 / 自动信息收集5分 / 增量采集5分 / 智能分类10分 / 风险仪表盘5分 |
-| 设计文档 | 10分 | 风险分类体系和评估标准设计合理 |
-| 测试用例与测试结果 | 10分 | 至少3个测试用例，覆盖不同风险类型和影响度评估 |
-| AI协作过程记录（AGENTS.md） | 15分 | 过程记录完整、分类策略调优过程可追溯 |
-| 技术选型与范式运用 | 15分 | Skill/MCP等选型理由充分，情报收集管道设计合理 |
-| 代码质量 + README | 10分 | 结构清晰、命名规范、README完整 |
-| 业务场景理解与需求分析 | 10分 | 对风险情报收集场景理解准确，需求分析到位 |
-| 难度赋分 | 5分 | ★★★难度追加 |
-| **合计** | **105分** | |
-
-> 本题为★★★难度，满分105分，合格条件：≥60分。
+**样本数据**：模拟信息源 HTML/RSS（至少 3 个，覆盖不同风险领域），条目须包含不同发布日期以支撑趋势对比；若实现 API 类型信息源，附 mock 服务脚本。
 
 ---
 
+## 3.4 命题题 · 第二组：开发阶段AI评审工具题（07~11）
 
----
+> 本组 5 道题统一实现「瀑布式各阶段的AI评审工具」。先读下方【组定位与背景】【组内共通硬性要求】（四条硬性要求对本组每道题都强制生效），再进入所选题目章节。
+> 各题【本题专属要求】为该题补充项；通用 7 项成果物（README / DESIGN / src / tests / `_AI_USAGE_LOG.md` / `AGENTS.md` / data 样本数据）以 §3.2 为准，每题均须提交。各类**评分型指标**（置信度、影响度、准确率、「高频」阈值等）的具体计算口径由受验者自行定义，但必须在设计文档中写明；验收时以「口径清晰 + 结果可复现」为准，不要求与任何标准答案一致。涉及「与公司业务相关性」评估的题目，受验者须在 README 中给出虚构的公司画像（行业、规模、主要业务范围）作为统一评估基准。
 
-## 16. 命题题详细需求 · 第二组：开发阶段AI评审工具题（07~11）
-
-> 本组5道题统一实现「瀑布式各阶段的AI评审工具」。先读下方【组定位与背景】【组内共通硬性要求】（四条硬性要求对本组每道题都强制生效），再进入所选题目章节。
-> 各题【提交物清单】为该题专属补充项；通用7项成果物（README / DESIGN / src / tests / `_AI_USAGE_LOG.md` / `AGENTS.md` / data样本数据）以 §5 为准，每题均须提交。> 各类**评分型指标**（置信度、影响度、准确率、「高频」阈值等）的具体计算口径由受验者自行定义，但必须在设计文档中写明；验收时以「口径清晰 + 结果可复现」为准，不要求与任何标准答案一致。涉及「与公司业务相关性」评估的题目，受验者须在 README 中给出虚构的公司画像（行业、规模、主要业务范围）作为统一评估基准。
-
-
-
-> 本组5道题统一实现「瀑布式各阶段的AI评审工具」。先读下方【组定位与背景】【组内共通硬性要求】（四条硬性要求对本组每道题都强制生效），再进入所选题目章节。
-> 各题【提交物清单】为该题专属补充项；通用7项成果物（README / DESIGN / src / tests / `_AI_USAGE_LOG.md` / `AGENTS.md` / data样本数据）以 §5 为准，每题均须提交。> 各类**评分型指标**（置信度、影响度、准确率、「高频」阈值等）的具体计算口径由受验者自行定义，但必须在设计文档中写明；验收时以「口径清晰 + 结果可复现」为准，不要求与任何标准答案一致。涉及「与公司业务相关性」评估的题目，受验者须在 README 中给出虚构的公司画像（行业、规模、主要业务范围）作为统一评估基准。
-
-
-### 组定位与背景
+### 3.4.1 组定位与背景
 
 公司推行AI辅助开发后，文档与代码的生成速度大幅提升，但人工review成为新的瓶颈——全量人审则速度优势归零，放弃审查则质量风险失控。
 
 本组题目围绕瀑布式开发的各个阶段，受验者**根据自身项目的实际痛点选择一个阶段**，实现该阶段的AI评审工具/Skill。目标是让工具承担全量预检并给出证据定位，人只复核被标记的例外，在不牺牲质量的前提下保持开发速度。
 
-### 组内共通硬性要求（07~11每道题都必须满足）
+### 3.4.2 组内共通硬性要求（07~11每道题都必须满足）
 
 | # | 要求 | 说明 |
 |---|------|------|
@@ -1173,13 +1019,10 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 
 #### 考核技术（至少选1项）
 
-| 技术 | 本题中的运用示例 | AGENTS.md中需记录的内容 |
-|------|----------------|------------------------|
-| **Skill** | 将「歧义检测」「一致性检查」「可测试性评估」「报告生成」封装为独立Skill | 各Skill接口定义 / 规则配置方式 / 检出率调优过程 |
-| **SpecKit** | 先定义规则配置规范和报告格式spec再实现 | 规格定义过程 / 规则与spec的对应关系 |
-| **MCP自动化测试** | 用缺陷标注清单对检出率做自动化回归验证 | MCP Server配置 / 检出率基准与回归结果 |
-| **VibeCoding** | 提示词直接实现解析→检查→报告全流程 | prompt原文 / 生成过程 / 误报调优记录 |
-| **Superpowers** | 组合构建评审管道（解析→各检查器→汇总报告） | Superpower注册与组合逻辑 / 各检查器职责边界 |
+> 课程技术共同要求见 §3.2 前言（VibeCoding/SpecKit/Skill/Superpowers/MCP 五选一，鼓励组合加分）。本题推荐运用：
+> - **Skill**：将「歧义检测」「一致性检查」「可测试性评估」「报告生成」封装为独立Skill
+> - **MCP自动化测试**：用缺陷标注清单对检出率做自动化回归验证
+> - **SpecKit**：先定义规则配置规范和报告格式spec再实现
 
 #### 业务需求
 
@@ -1222,32 +1065,11 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 | 报告规范 | 分级+章节定位完整 | 定位含条目原文摘录 | 抽查报告中定位是否准确 |
 | 规则外置生效 | 规则在独立配置文件中维护 | 新增1条规则不改代码生效，有自动化脚本+运行日志佐证 | 运行提交的验证脚本核验 |
 
-#### 提交物清单
+#### 本题专属要求（其余按 §3.2 通用要求）
 
-| # | 提交物 | 内容要求 | 必须/可选 |
-|---|--------|---------|----------|
-| 1 | 源代码 | 完整可运行的项目代码 | **必须** |
-| 2 | README | 环境要求（含LLM配置）、安装步骤、运行方法、规则配置说明 | **必须** |
-| 3 | 设计文档 | 架构图、各检查器设计、规则与标准配置文件结构说明、误报控制策略 | **必须** |
-| 4 | 测试用例 + 测试结果 | 至少3个测试用例（含基于标注清单的检出率回归对比） | **必须** |
-| 5 | AGENTS.md | 技术运用过程记录、歧义词词典调优过程、LLM判断改善记录 | **必须** |
-| 6 | 样本数据 | 2份模拟需求说明书（1份正常，含约10条编号需求；1份植入至少20处已知问题：歧义词≥10处、矛盾≥2组、不可测试需求≥3处、量化缺失≥2处、编写规范违规≥3处）+ 缺陷标注清单（问题位置/类型/级别）+ 《需求文档编写标准》配置A/B两套 | **必须** |
+**测试用例与测试结果**：至少 3 个测试用例（含基于标注清单的检出率回归对比）。
 
-#### 评分标准（100分 + 难度赋分5分）
-
-| 评审项 | 分值 | 评审方式 |
-|--------|:---:|---------|
-| 功能完整性 | 30分 | 文档导入与解析4分 / 歧义检测8分 / 一致性检查5分 / 编写规范检查5分 / 可测试性评估4分 / 评审报告与规则外置4分 |
-| 设计文档 | 10分 | 架构合理，规则引擎与LLM分工策略清晰，企业标准配置化设计有依据 |
-| 测试用例与测试结果 | 10分 | 检出率回归对比可复现，含标准A/B切换验证 |
-| AI协作过程记录（AGENTS.md） | 15分 | 过程记录完整、误报调优过程可追溯 |
-| 技术选型与范式运用 | 15分 | 选型理由充分，Skill/MCP等运用合理 |
-| 代码质量 + README | 10分 | 结构清晰、命名规范、README含规则配置说明 |
-| 业务场景理解与需求分析 | 10分 | 对需求评审痛点理解准确 |
-| 难度赋分 | 5分 | ★★★难度追加 |
-| **合计** | **105分** | |
-
-> 本题为★★★难度，满分105分，合格条件：≥60分。
+**样本数据**：2 份模拟需求说明书（1 份正常含约 10 条编号需求；1 份植入至少 20 处已知问题：歧义词≥10 处、矛盾≥2 组、不可测试需求≥3 处、量化缺失≥2 处、编写规范违规≥3 处）+ 缺陷标注清单 + 《需求文档编写标准》配置 A/B 两套。
 
 ---
 
@@ -1270,15 +1092,10 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 
 #### 考核技术（至少选1项）
 
-| 技术 | 本题中的运用示例 | AGENTS.md中需记录的内容 |
-|------|----------------|------------------------|
-| **SpecKit** | 先定义必备章节规范、追溯矩阵规格、报告格式spec再实现 | 规格定义过程 / 追溯映射规则与spec对应关系 |
-| **Skill** | 将「规范检查」「追溯矩阵构建」「接口一致性检查」封装为独立Skill | 各Skill接口定义 / 语义匹配策略 |
-| **MCP自动化测试** | 用缺陷标注清单对矩阵映射正确率做自动化验证 | MCP Server配置 / 映射正确率基准 |
-| **VibeCoding** | 提示词直接实现解析→检查→矩阵→报告流程 | prompt原文 / 语义匹配prompt迭代记录 |
-| **Superpowers** | 组合构建预审管道 | Superpower注册与组合逻辑 |
-
-> **难度说明**：本题为★★★★难度，满分110分（含难度赋分10分），合格线60分。设计书解析、规范符合性检查、评审报告为基础必达项；需求追溯矩阵与接口一致性检查为本题核心考察点，其中需求追溯矩阵（10分）权重最高，建议优先实现。
+> 课程技术共同要求见 §3.2 前言（VibeCoding/SpecKit/Skill/Superpowers/MCP 五选一，鼓励组合加分）。本题推荐运用：
+> - **SpecKit**：先定义必备章节规范、追溯矩阵规格、报告格式spec再实现
+> - **Skill**：将「规范检查」「追溯矩阵构建」「接口一致性检查」封装为独立Skill
+> - **MCP自动化测试**：用缺陷标注清单对矩阵映射正确率做自动化验证
 
 #### 业务需求
 
@@ -1319,32 +1136,11 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 | 矩阵可视化 | 表格形式展示完整映射关系 | 支持点击跳转到对应位置 | 运行提交的脚本/截图验证 |
 | 规则外置生效 | 必备章节清单在配置文件中维护 | 调整清单后重新评审生效，有自动化脚本+运行日志佐证 | 运行提交的验证脚本核验 |
 
-#### 提交物清单
+#### 本题专属要求（其余按 §3.2 通用要求）
 
-| # | 提交物 | 内容要求 | 必须/可选 |
-|---|--------|---------|----------|
-| 1 | 源代码 | 完整可运行的项目代码 | **必须** |
-| 2 | README | 环境要求（含LLM配置）、安装步骤、运行方法、规范清单配置说明 | **必须** |
-| 3 | 设计文档 | 架构图、追溯映射算法设计、语义匹配策略、误报控制方案 | **必须** |
-| 4 | 测试用例 + 测试结果 | 至少3个测试用例（含映射正确率回归对比） | **必须** |
-| 5 | AGENTS.md | 技术运用过程记录、语义匹配prompt迭代过程、映射正确率改善记录 | **必须** |
-| 6 | 样本数据 | 需求清单1份（10条编号需求）+ 模拟设计书1份（含正常内容，植入2处必备章节缺失、2条需求未覆盖、1处孤儿设计、2处接口矛盾、图表/编号格式违规≥2处）+ 缺陷标注清单 + 《设计书格式标准》配置A/B两套 | **必须** |
+**测试用例与测试结果**：至少 3 个测试用例（含映射正确率回归对比）。
 
-#### 评分标准（100分 + 难度赋分10分）
-
-| 评审项 | 分值 | 评审方式 |
-|--------|:---:|---------|
-| 功能完整性 | 30分 | 导入与解析5分 / 规范符合性检查5分 / 需求追溯矩阵10分 / 接口一致性检查5分 / 矩阵可视化与报告5分 |
-| 设计文档 | 10分 | 架构合理，追溯映射算法设计有依据 |
-| 测试用例与测试结果 | 10分 | 映射正确率回归对比可复现 |
-| AI协作过程记录（AGENTS.md） | 15分 | 过程记录完整、语义匹配prompt迭代可追溯 |
-| 技术选型与范式运用 | 15分 | 选型理由充分，SpecKit/Skill等运用合理 |
-| 代码质量 + README | 10分 | 结构清晰、命名规范、README完整 |
-| 业务场景理解与需求分析 | 10分 | 对设计书评审痛点理解准确 |
-| 难度赋分 | 10分 | ★★★★难度追加 |
-| **合计** | **110分** | |
-
-> 本题为★★★★难度，满分110分，合格条件：≥60分。
+**样本数据**：需求清单 1 份（10 条编号需求）+ 模拟设计书 1 份（植入章节缺失×2、未覆盖×2、孤儿设计×1、接口矛盾×2、格式违规≥2 处）+ 缺陷标注清单 + 格式标准 A/B 两套。
 
 ---
 
@@ -1367,13 +1163,10 @@ AI生成代码大量合入代码库后，出现特有的高频缺陷模式：
 
 #### 考核技术（至少选1项）
 
-| 技术 | 本题中的运用示例 | AGENTS.md中需记录的内容 |
-|------|----------------|------------------------|
-| **Skill** | 将「secrets检测」「LLM调用检查」「空值防护检查」「报告生成」封装为独立Skill | 各Skill接口定义 / 正则规则库设计 / 误报白名单机制 |
-| **SpecKit** | 先定义规则格式规范、分级标准、报告格式spec | 规格定义过程 / 规则分级与spec对应关系 |
-| **MCP自动化测试** | 用缺陷标注清单对检出率和误报率做自动化验证 | MCP Server配置 / 检出率与误报率基准 |
-| **VibeCoding** | 提示词直接实现扫描引擎和规则匹配 | prompt原文 / 规则调优过程 |
-| **Superpowers** | 组合构建扫描管道（遍历→各检查器→汇总） | Superpower注册与组合逻辑 |
+> 课程技术共同要求见 §3.2 前言（VibeCoding/SpecKit/Skill/Superpowers/MCP 五选一，鼓励组合加分）。本题推荐运用：
+> - **Skill**：将「secrets检测」「LLM调用检查」「空值防护检查」「报告生成」封装为独立Skill
+> - **SpecKit**：先定义规则格式规范、分级标准、报告格式spec
+> - **MCP自动化测试**：用缺陷标注清单对检出率和误报率做自动化验证
 
 #### 业务需求
 
@@ -1413,32 +1206,11 @@ AI生成代码大量合入代码库后，出现特有的高频缺陷模式：
 | 扫描范围控制 | 配置的排除目录不被扫描 | 白名单机制生效 | 故意配置后运行验证 |
 | 报告规范与规则外置 | 分级+file:line定位完整 | 修复建议含示例代码；新增规则不改代码生效，有脚本佐证 | 抽查报告+运行验证脚本 |
 
-#### 提交物清单
+#### 本题专属要求（其余按 §3.2 通用要求）
 
-| # | 提交物 | 内容要求 | 必须/可选 |
-|---|--------|---------|----------|
-| 1 | 源代码 | 完整可运行的项目代码 | **必须** |
-| 2 | README | 环境要求、安装步骤、运行方法、规则库与白名单配置说明 | **必须** |
-| 3 | 设计文档 | 架构图、规则匹配引擎设计、分级标准定义、误报控制策略 | **必须** |
-| 4 | 测试用例 + 测试结果 | 至少3个测试用例（含检出率/误报率回归对比） | **必须** |
-| 5 | AGENTS.md | 技术运用过程记录、正则规则调优过程、误报处理经验 | **必须** |
-| 6 | 样本数据 | 1个小型模拟项目代码包（至少10个源码文件，植入硬编码密钥×8、LLM调用无保护×3、空值裸访问×4、编码规约违规×4）+ 缺陷标注清单 + 《编码规约》配置A/B两套 | **必须** |
+**测试用例与测试结果**：至少 3 个测试用例（含检出率/误报率回归对比）。
 
-#### 评分标准（100分 + 难度赋分5分）
-
-| 评审项 | 分值 | 评审方式 |
-|--------|:---:|---------|
-| 功能完整性 | 30分 | 扫描配置与执行3分 / secrets检测6分 / LLM调用专项检查7分 / 空值防护检查5分 / 编码规约检查4分 / 报告与门禁5分 |
-| 设计文档 | 10分 | 规则引擎设计合理、分级标准定义清晰、企业规约配置化设计有依据 |
-| 测试用例与测试结果 | 10分 | 检出率/误报率回归对比可复现，含规约A/B切换验证 |
-| AI协作过程记录（AGENTS.md） | 15分 | 过程记录完整、规则调优过程可追溯 |
-| 技术选型与范式运用 | 15分 | 选型理由充分，Skill/MCP等运用合理 |
-| 代码质量 + README | 10分 | 结构清晰、命名规范、README含规则配置说明 |
-| 业务场景理解与需求分析 | 10分 | 对AI生成代码特有缺陷模式理解准确 |
-| 难度赋分 | 5分 | ★★★难度追加 |
-| **合计** | **105分** | |
-
-> 本题为★★★难度，满分105分，合格条件：≥60分。
+**样本数据**：小型模拟项目代码包（≥10 个源码文件，植入硬编码密钥×8、LLM 无保护×3、空值裸访问×4、规约违规×4）+ 缺陷标注清单 + 规约 A/B 两套。
 
 ---
 
@@ -1461,15 +1233,10 @@ AI辅助生成测试用例后，测试数量激增但质量参差：
 
 #### 考核技术（至少选1项）
 
-| 技术 | 本题中的运用示例 | AGENTS.md中需记录的内容 |
-|------|----------------|------------------------|
-| **Skill** | 将「测试集解析」「覆盖分析」「断言强度审查」「评级报告」封装为独立Skill | 各Skill接口定义 / 断言强度判定标准设计 |
-| **SpecKit** | 先定义评级标准和覆盖矩阵规格再实现 | 规格定义过程 / 评级标准与spec对应关系 |
-| **MCP自动化测试** | 用缺陷标注清单对弱断言检出率做自动化验证 | MCP Server配置 / 检出率基准与回归结果 |
-| **VibeCoding** | 提示词直接实现解析→分析→评级全流程 | prompt原文 / 断言判断prompt迭代记录 |
-| **Superpowers** | 组合构建测试评审管道 | Superpower注册与组合逻辑 |
-
-> **难度说明**：本题为★★★★难度，满分110分（含难度赋分10分），合格线60分。测试集解析、评级报告为基础必达项；需求覆盖分析（7分）与断言强度审查（9分）为本题核心考察点，其中断言强度审查依赖LLM对业务语义的理解，权重最高；测试基准符合性检查（4分）体现企业标准定制化能力。
+> 课程技术共同要求见 §3.2 前言（VibeCoding/SpecKit/Skill/Superpowers/MCP 五选一，鼓励组合加分）。本题推荐运用：
+> - **Skill**：将「测试集解析」「覆盖分析」「断言强度审查」「评级报告」封装为独立Skill
+> - **MCP自动化测试**：用缺陷标注清单对弱断言检出率做自动化验证
+> - **SpecKit**：先定义评级标准和覆盖矩阵规格再实现
 
 #### 业务需求
 
@@ -1510,32 +1277,11 @@ AI辅助生成测试用例后，测试数量激增但质量参差：
 | 用例评级 | 每个测试用例有A/B/C评级 | C级用例附针对性改进建议 | 抽查评级合理性 |
 | 报告规范与规则外置 | 评级结果+覆盖矩阵完整展示 | 评级标准在配置文件中可调整，有脚本佐证 | 运行验证脚本核验 |
 
-#### 提交物清单
+#### 本题专属要求（其余按 §3.2 通用要求）
 
-| # | 提交物 | 内容要求 | 必须/可选 |
-|---|--------|---------|----------|
-| 1 | 源代码 | 完整可运行的项目代码 | **必须** |
-| 2 | README | 环境要求（含LLM配置）、安装步骤、运行方法、评级标准配置说明 | **必须** |
-| 3 | 设计文档 | 架构图、断言强度判定标准设计、覆盖映射算法、评级体系说明 | **必须** |
-| 4 | 测试用例 + 测试结果 | 至少3个测试用例（含弱断言检出率回归对比） | **必须** |
-| 5 | AGENTS.md | 技术运用过程记录、断言判断prompt迭代过程、检出率改善记录 | **必须** |
-| 6 | 样本数据 | 需求清单1份（10条编号需求）+ 测试代码集1份（至少20个测试用例，植入无断言测试×3、弱断言×8、用例要素缺失或命名违规×3）+ 缺陷标注清单 + 《测试基准》配置A/B两套 | **必须** |
+**测试用例与测试结果**：至少 3 个测试用例（含弱断言检出率回归对比）。
 
-#### 评分标准（100分 + 难度赋分10分）
-
-| 评审项 | 分值 | 评审方式 |
-|--------|:---:|---------|
-| 功能完整性 | 30分 | 测试集导入与解析3分 / 需求覆盖分析7分 / 断言强度审查9分 / 边界完整性提示2分 / 基准符合性检查4分 / 质量评级报告5分 |
-| 设计文档 | 10分 | 架构合理，断言强度判定标准设计有依据，测试基准配置化设计合理 |
-| 测试用例与测试结果 | 10分 | 检出率回归对比可复现 |
-| AI协作过程记录（AGENTS.md） | 15分 | 过程记录完整、断言判断prompt迭代可追溯 |
-| 技术选型与范式运用 | 15分 | 选型理由充分，Skill/MCP等运用合理 |
-| 代码质量 + README | 10分 | 结构清晰、命名规范、README完整 |
-| 业务场景理解与需求分析 | 10分 | 对AI生成测试的质量风险理解准确 |
-| 难度赋分 | 10分 | ★★★★难度追加 |
-| **合计** | **110分** | |
-
-> 本题为★★★★难度，满分110分，合格条件：≥60分。
+**样本数据**：需求清单 1 份（10 条编号需求）+ 测试代码集（≥20 个用例，植入无断言×3、弱断言×8、要素缺失或命名违规×3）+ 缺陷标注清单 + 基准 A/B 两套。
 
 ---
 
@@ -1554,12 +1300,10 @@ AI辅助生成测试用例后，测试数量激增但质量参差：
 
 #### 考核技术（至少选1项）
 
-| 技术 | 本题中的运用示例 | AGENTS.md中需记录的内容 |
-|------|----------------|------------------------|
-| **VibeCoding** | 提示词直接实现清单核对→要素检查→报告生成全流程 | prompt原文 / 生成过程 / 人工修正点 |
-| **Skill** | 将「清单核对」「要素检查」「交叉一致性」封装为独立Skill | 各Skill接口定义 / 清单模板设计 |
-| **SpecKit** | 先定义清单模板格式和报告格式spec | 规格定义过程 / 清单与spec对应关系 |
-| **MCP自动化测试** | 对核对逻辑做自动化测试 | MCP Server配置 / 核对准确性验证 |
+> 课程技术共同要求见 §3.2 前言（VibeCoding/SpecKit/Skill/Superpowers/MCP 五选一，鼓励组合加分）。本题推荐运用：
+> - **VibeCoding**：提示词直接实现清单核对→要素检查→报告生成全流程
+> - **Skill**：将「清单核对」「要素检查」「交叉一致性」封装为独立Skill
+> - **SpecKit**：先定义清单模板格式和报告格式spec
 
 #### 业务需求
 
@@ -1593,31 +1337,11 @@ AI辅助生成测试用例后，测试数量激增但质量参差：
 | 清单可切换 | 加载另一套清单模板能正常工作 | 模板格式有文档说明 | 切换模板演示 |
 | 报告与结论 | 核对表+缺失明细完整 | 结论判定逻辑正确（Critical缺失→不通过） | 构造场景验证 |
 
-#### 提交物清单
+#### 本题专属要求（其余按 §3.2 通用要求）
 
-| # | 提交物 | 内容要求 | 必须/可选 |
-|---|--------|---------|----------|
-| 1 | 源代码 | 完整可运行的项目代码 | **必须** |
-| 2 | README | 环境要求、安装步骤、运行方法、清单模板格式说明 | **必须** |
-| 3 | 设计文档 | 架构图、清单模板设计、要素匹配与一致性检查逻辑 | **必须** |
-| 4 | 测试用例 + 测试结果 | 至少3个测试用例，覆盖核对正常路径和异常路径 | **必须** |
-| 5 | AGENTS.md | 技术运用过程记录、清单模板设计决策、遇到的问题与解决方案 | **必须** |
-| 6 | 样本数据 | 1个残缺的模拟项目提交包（故意缺失部分文件、README缺要素、技术栈声明与依赖不一致）+ 缺陷标注清单 + 另一套备用清单模板 | **必须** |
-
-#### 评分标准（100分）
-
-| 评审项 | 分值 | 评审方式 |
-|--------|:---:|---------|
-| 功能完整性 | 30分 | 成果物清单配置5分 / 存在性核对8分 / 要素齐全性检查8分 / 交叉一致性检查5分 / 准入报告与结论4分 |
-| 设计文档 | 10分 | 架构合理、清单模板设计规范 |
-| 测试用例与测试结果 | 10分 | 覆盖核对正常和异常路径、可复现 |
-| AI协作过程记录（AGENTS.md） | 15分 | 过程记录完整、设计决策可追溯 |
-| 技术选型与范式运用 | 15分 | 选型理由充分，VibeCoding/Skill运用合理 |
-| 代码质量 + README | 10分 | 结构清晰、命名规范、README完整 |
-| 业务场景理解与需求分析 | 10分 | 对交付核对痛点理解准确 |
-| **合计** | **100分** | |
-
-> 本题为★★难度，满分100分，合格条件：≥60分。组内共通硬性要求（证据型报告 / 规则外置 / 分级判定 / 企业标准外置）同样适用于本题，未满足将在对应维度扣分。
+**测试用例与测试结果**：至少 3 个测试用例，覆盖核对正常路径和异常路径。
 
+**样本数据**：1 个残缺的模拟项目提交包（故意缺失部分文件、README 缺要素、技术栈声明与依赖不一致）+ 缺陷标注清单 + 另一套备用清单模板。
 
+> **注意**：本题同样须遵守 §3.4.2 组内共通硬性要求（证据型报告 / 规则外置 / 分级判定 / 企业标准外置）。