评审真实性增强：前端硬规则+人工启动方案+文档-实现三级校验

- 前端存在性硬规则：detectFrontend 源码级判定，web形态无真实前端/不可访问 → 实现完整度封顶50%（CLI/插件豁免） - verify 多态：build_status 支持 done/failed/done_no_ui，前端按钮新增「无前端」 - 人工启动方案：评审环境自动启动失败 → awaiting_browse 暂停，评委手动启动后填 service_url 走 /verify-browse 恢复（SSRF 信任评委确认地址） - Gitea 稳定性：clone 自动重试×3（525抖动）+ 每队独立 token 回退（全局账号失效兜底） - A 阶段报告备份：feature_inventory.__stageA_report 防 B 阶段维度重复累积/A维度丢失 - tryTest 依赖预装：Python 项目自动 pip install（测试不再因缺依赖误判失败） - 运行验证压缩静态维度：前端缺失+测试失败 → 静态纸面维度封顶50%（防原型拿高分） - 文档-实现三级校验：claim-consistency 注入运行时证据（构建/测试/前端），识别「代码有但跑不起来」的虚报（逸飞冲天 61%→25%） - 赛事文档：中期20%+最终80%（AI=人工总分）、评审表/评审规则/赛事说明/07设计同步 - 清空 review_snapshots 测试污染数据，保留当前正式分（零号158/逸飞冲天126） - 测试 446 全通过（后端435+前端11）
2026-09-01 08:44:56 +08:00
parent f8b4e9d44d
commit 1b89743d77
43 changed files with 3362 additions and 290 deletions
@@ -0,0 +1,311 @@
+# AI 评审机制说明
+
+> 版本：2026-08-28 ｜ 适用范围：技术大赛 赛道一 / 赛道二 ｜ 读者：评委 / 管理员
+
+**核心一句话**：AI 评审 = **AI 维度打分 + 确定性证据校验**——AI 负责评"品质"，代码负责查"真假"，两者结合产出可审计、防作弊的评分。
+
+**评审目标**：对参赛成果物给出**公平、真实、可区分**的评分——（1）**公平**：同一标准、同一证据链，不因 README 写得漂亮而虚高；（2）**真实**：分数建立在"系统能跑、功能真实现、测试真通过"的硬证据上，AI 幻觉与文档包装无法加分；（3）**可区分**：权重向"功能真实"倾斜，让真做了的团队与只交文档的团队拉开差距。
+
+---
+
+## 一图看懂评审管线
+
+```
+克隆 → 分析 → 概览 → 子Agent分维度评审(并发3)
+        │                      ↓
+        │         校准(代码定调幅) → 硬规则(证据封顶) → 出分
+        │                          ↓
+        └→ 最近3次评审取中位数 → 聚合正式分 → 报告
+```
+
+**赛道一**（A/B 两阶段）：A 静态评审 → 评委人工确认构建 → B 动态验证（实现/效果维度）
+**赛道二**（单阶段）：一次管线完成全部 8 维
+
+---
+
+## 目录
+
+- [一图看懂评审管线](#一图看懂评审管线)
+- [0. 核心特点](#0-核心特点)
+- [1. 赛道一：Agent开发实战赛](#1-赛道一agent开发实战赛12维--200分)
+- [2. 赛道二：IDE+开发范式创新赛](#2-赛道二ide开发范式创新赛8维--100分)
+- [3. 确定性机制（保真实）](#3-确定性机制真实性验证)
+- [4. 评分与可信度](#4-评分与可信度)
+- [5. 评委操作流程](#5-评审流程操作评委视角)
+- [6. 人工评审（发表会）](#6-人工评审发表会)
+- [7. 已知边界](#6-已知边界与注意)
+
+---
+
+## 0. 核心特点
+
+| 特点 | 说明 |
+|:-----|:-----|
+| 🎯 **真实性优先** | 功能真实类维度占赛道一 **42.5%**，文档类仅 **13.5%**——评分看"系统能不能跑、功能真不真"，不看 README 写得多漂亮 |
+| 🛡 **AI 不判真假** | 构建结果、测试通过率、功能占位率、日志占位率、文档一致性均由**代码确定性判定**，AI 只在证据上评品质，编造无效 |
+| 🚫 **防作弊双保险** | 文档声称↔代码实现**一致性校验**（防补假文档）+ 空壳率/重复率/测试有效度**质量评估**（防空壳堆数量）。补真→加分，编造→降权 |
+| 📊 **结果稳定** | 最近 3 次评审取**中位数**聚合（2 次取平均）；标准快照隔离（评后改标准不影响已评结果） |
+| 🔍 **可审计** | 每维度分带评语+证据引用；校准/硬规则改动写入 `calibrationExplanation`；历次快照可对比 |
+| ⚡ **成本可控** | 并发3、功能发现分块扫描、确定性机制跨阶段复用，控制 LLM 调用量 |
+
+---
+
+## 1. 赛道一：Agent开发实战赛（12维 / 200分）
+
+### 1.1 维度权重表
+
+| # | 维度 | 分值 | 阶段 | 类型 |
+|:-:|:-----|:----:|:----:|:----|
+| 1 | 场景价值与技术合理性 | 15 | A | 设计/价值 |
+| 2 | 开发范式应用 | 8 | A | 过程 |
+| 3 | 架构设计 | 15 | A | 设计 |
+| 4 | 工具使用与Skill集成深度 | 10 | A | 能力 |
+| 5 | Agent核心能力 | 30 | A | 能力 |
+| 6 | **实现完整度与稳定性** | **35** | **B** | **功能真实** |
+| 7 | **规模与功能点** | **25** | A | **功能真实** |
+| 8 | 代码规范性 | 10 | A | 文档/规范 |
+| 9 | 演示与文档 | 8 | A | 文档/规范 |
+| 10 | AI使用日志 | 10 | A | 过程 |
+| 11 | **效果与数据** | **25** | **B** | **功能真实** |
+| 12 | 安全性 | 9 | A | 文档/规范 |
+
+**权重构成**（设计原则 2026-08-27）：
+- **功能真实类（85分，42.5%）**：实现完整度35 + 规模功能点25 + 效果数据25 —— 全部锚定确定性证据（构建/测试/功能发现/基准）。
+- **Agent能力（30分）**：代码模式确定性检测 + AI 评分。
+- **文档/规范类（27分，13.5%）**：代码规范10 + 演示文档8 + 安全9 —— 占比压低，且硬绑真实性（构建失败→半封顶）。
+
+### 1.2 采分点速查
+
+| 维度 | 采分点 | 关键规则 |
+|:-----|:------|:--------|
+| ① 场景价值(15) | 真实需求4·Agent不可替代4·ROI量化4·场景文档3 | 无文档→0；构建失败→≤4；**≤实现完整度** |
+| ② 开发范式(8) | 流程覆盖3·设计文档3·测试文档2 | 构建失败→≤2 |
+| ③ 架构设计(15) | 架构文档4·模块化4·数据流4·可扩展3 | 有文档+可构建→15；无文档有代码→≤8；构建失败→≤4；**≤实现完整度** |
+| ④ 工具使用(10) | 框架集成6·工具链4 | 无框架0→基本2→MCP/FC4→深度6；构建失败→≤3 |
+| ⑤ Agent核心(30) | 存在性5·工具调用8·规划6·协作4·可靠7 | **4门槛代码检测缺1→整维0**；构建失败→≤9 |
+| ⑥ 实现完整度(35,B) | 功能完整12·构建8·启动7·降级5·错误3 | 功能发现锚定；**构建失败→≤11** |
+| ⑦ 规模功能点(25) | 规模6·功能覆盖10·演示5·数据4 | 功能发现锚定；空壳>25%或测试弱→降档25% |
+| ⑧ 代码规范(10) | 命名2·硬编码2·重复2·安全2·注释2 | 重复>30%→≤1、>50%→0 |
+| ⑨ 演示文档(8) | README2·API文档2·启动说明2·一致性2 | 无README→0；**一致性<60%→≤50%**；≤实现完整度 |
+| ⑩ AI日志(10) | 记录4·调用细节4·真实性2 | **占位>50%→封顶30%**；声称无代码→扣2 |
+| ⑪ 效果数据(25,B) | 测试6·框架4·验证数据5·覆盖率5·复现5 | **三档封顶**：无基准/测试→C档≤7；构建失败→≤7 |
+| ⑫ 安全(9) | 密钥3·输入3·敏感2·依赖1 | 构建失败→≤2 |
+
+**证据锚定来源**：功能发现轮（功能数/占位率）· tryBuild/tryStart/tryBrowse（构建/启动）· tryTest（测试/覆盖率）· accept-runner（验收命令）· ai-log-audit（日志占位）· evidence-detect（Agent门槛）· claim-consistency（文档一致性）· code-quality（空壳/重复/测试有效度）
+
+---
+
+## 2. 赛道二：IDE+开发范式创新赛（8维 / 100分）
+
+### 2.1 维度权重表
+
+| # | 维度 | 分值 | 类型 |
+|:-:|:-----|:----:|:----|
+| 1 | 开发范式设计清晰度 | 20 | 设计 |
+| 2 | IDE集成深度 | 20 | 能力 |
+| 3 | 提效设计合理性 | 10 | 设计 |
+| 4 | 提效幅度 | 10 | 效果 |
+| 5 | 稳定性与易用性 | 15 | 功能真实 |
+| 6 | 规模与功能点与技术难度 | 10 | 功能真实 |
+| 7 | 演示与文档 | 5 | 文档 |
+| 8 | AI使用日志 | 10 | 过程 |
+
+### 2.2 采分点速查
+
+| 维度 | 采分点 | 关键规则 |
+|:-----|:------|:--------|
+| ① 开发范式设计(20) | 范式定义·落地一致性·工具链结合 | 定性维度，不参与 C 档封顶 |
+| ② IDE集成深度(20) | VSCode/IDEA插件·LSP·Webview·命令注册 | IDE 贡献点确定性提取注入 |
+| ③ 提效设计合理(10) | 设计思路合理性 | 定性维度，不参与 C 档封顶 |
+| ④ 提效幅度(10) | 基线对比数据 | **纯增益严格制**：无基线→C档≤30%；测试通过不构成提效证据 |
+| ⑤ 稳定性易用(15) | 构建可运行·测试通过·可访问 | 确定性证据锚定 |
+| ⑥ 规模功能点(10) | 真实功能数·占位比例 | 功能发现轮锚定 |
+| ⑦ 演示文档(5) | 文档质量·一致性 | **一致性<60%→封顶50%** |
+| ⑧ AI日志(10) | 记录·调用细节·真实性 | **占位>50%→封顶30%** |
+
+> 单阶段评审（无 A/B 拆分）；`extractIdeContributions` 提取 IDE 集成证据注入。
+
+---
+
+## 3. 确定性机制（真实性验证）
+
+核心原则：**AI 负责评"品质"，代码负责查"真假"**。以下机制全部由代码确定性计算，不依赖 AI 主观。
+
+### 3.1 构建 / 测试 / 运行验证
+
+| 机制 | 说明 | 封顶规则 |
+|:-----|:-----|:--------|
+| 人工确认构建 | 赛道一 A 后评委实际构建，verify 传 done/failed | 构建失败→实现完整度≤33%、效果≤30% |
+| 自动 tryBuild | 7 种构建系统探测，作辅助证据 | 构建失败→纸面维度≤33% |
+| tryTest 真跑 | pytest/jest/go 等，解析通过率+覆盖率 | 测试失败→效果≤50% |
+| tryBrowse/tryStart | Web(45s看门狗)/CLI 服务验证 | — |
+
+### 3.2 功能发现轮（Map-Reduce 全量扫描）
+
+对全部源码分块扫描，AI 提取功能点并标注 `real/partial/stub`，统计**真实功能数 + 占位比例**，作为功能类维度评分锚点。防"AI 只看 README 不看真实代码"。
+
+### 3.3 文档声称↔代码实现一致性（防补假文档）
+
+AI 从 README 提取声称功能 → 与功能发现轮**语义比对** → 一致性率：
+
+| 一致性率 | 判定 | 处理 |
+|:-------:|:-----|:-----|
+| ≥90% | 文档可信 | 正常给分 |
+| 60~90% | 基本可信 | ×0.8 |
+| <60% | **文档虚报** | 文档类维度封顶50% + 虚报项入评语 |
+
+> 补**真实**文档→加分；补**编造**声称→降权。
+
+### 3.4 代码质量评估（防空壳堆数量）
+
+| 指标 | 算法 | 封顶规则 |
+|:-----|:-----|:--------|
+| 空壳率 | 空函数/占位 ÷ 总函数 | >25%→规模维度降档25% |
+| 重复率 | 行级 MD5 去重 | >50%→代码规范≤3 |
+| 测试有效度 | 断言数 ÷ (测试函数×2) | <40%→规模维度降档25% |
+
+### 3.5 效果可验证三档
+
+| 档位 | 条件 | 处理 |
+|:---:|:-----|:-----|
+| A | 有基准证据(benchmark) | 正常给分 |
+| B | 测试通过或覆盖率非null | 正常给分 |
+| C | 数据缺位 | **封顶30%** |
+
+> **纯增益严格制**（提效幅度类）：测试通过不构成提效证据，无基线一律 C 档。**定性维度豁免**（设计合理性/清晰度）：不参与 C 档。
+
+### 3.6 其他确定性校验
+
+- **AI日志占位率审计**：占位>50%→AI日志维度封顶30%；声称技术须在代码找到。
+- **Agent核心门槛**：`evidence-detect` 代码模式匹配 4 项硬门槛（LLM调用/工具策略/重试降级/状态持久化），AI 只评品质要素。
+- **测量协议 / 验收命令**：检查 `data/measurement/` 齐备性；执行 README `## 验收` 命令块。
+
+---
+
+## 4. 评分与可信度
+
+### 4.1 校准（确定性）
+
+LLM 只输出跨维度语义矛盾方向（over/under），**调幅由代码按统计规则计算**，不信任 LLM 数值：
+
+| 级别 | 触发 | 调幅 |
+|:---:|:-----|:----|
+| L1 | 语义矛盾 | ±2 |
+| L2 | σ 异常（偏离>2σ）| ±4 |
+| L3 | 最不稳定维度（Agent核心/规模/效果）高估 | ×0.8 |
+
+> 效果类维度 under 一律丢弃（只降不升）；每次改动写入 `calibrationExplanation`（可审计）。
+
+### 4.2 硬规则（Phase 3c，校准后执行）
+
+| 规则 | 触发 | 封顶 |
+|:-----|:-----|:-----|
+| 构建失败 | buildFailed | 实现完整度≤33%、效果≤30%、纸面维度≤33% |
+| 测试失败 | testStepFailed | 效果与数据≤50% |
+| 重复代码>50% | duplicateRatio | 代码规范≤3 |
+| 无根目录README | !hasRootReadme | 演示与文档≤2（无README）或≤3 |
+| 文档虚报 | 一致性<60% | 演示与文档≤50% |
+| 空壳率>25% | stubRatio | 规模维度降档25% |
+| 测试有效度<40% | testValidity | 规模维度降档25% |
+
+### 4.3 总分与迟交
+
+- 校准 delta 用 `Math.round()` 取整。
+- 总分 = 各维度分数累加（`finalScore = totalScore - 迟交扣分`，上限 `max_score_cap`）。
+- 迟交判定：优先 git 最后 commit 时间；commit 缺失或早于条目创建 → 用条目创建时间兜底；`computeLateDays` 对比项目 deadline。
+
+### 4.4 排名与聚合
+
+- 排名用 `aggregateScores` / `aggregateEntryScores`：最近 N 次（默认3）快照 `score` 中位数。
+- 聚合前提：各快照 `standard_snapshot` 一致。
+- `<2 次标「初评（未达聚合样本）」`，排名区分正式/初评。
+
+### 4.5 人机标定
+
+- 见 `docs/design/06-人机标定方案.md`。
+- 绝对准确未验证前，分数用于排名（相对序）可信；绝对解读需标定偏差基线。
+
+---
+
+## 5. 评审流程操作（评委视角）
+
+### 5.1 赛道一（两阶段）
+
+```
+创建条目 → 启动评审(A) → A完成(status=a_done, 静态分)
+→ 评委实际构建项目 → verify(done/failed)
+→ B阶段(构建验证+实现类维度) → review_done → 2轮聚合
+```
+
+- **关键人工动作**：A 阶段后必须实际构建并确认 `done/failed`。Web 形态项目若未填 service_url，B 阶段降级"跳过浏览器测试"继续代码评审。
+
+### 5.2 赛道二（单阶段）
+
+```
+创建条目 → 启动评审 → 全部维度一次完成 → review_done → 2轮聚合
+```
+
+---
+
+## 6. 中期 + 最终评价（AI 评审 + 人工评审）
+
+技术大赛分**中期评价**与**最终评价**两个阶段，成绩按 **2:8** 加权合成。发表会上队伍通过 PPT、视频、讲解说明项目，评委按维度打分表独立评分。
+
+### 6.1 总分构成
+
+| 阶段 | 权重 | 评审方式 |
+|:-----|:---:|:---------|
+| **中期评价** | 20% | **仅 AI 评审**（无人工）|
+| **最终评价** | 80% | AI 评审 + 人工评审 |
+
+**最终成绩 = 中期评价（20%）+ 最终评价（80%）**。
+
+- **中期评价（20%，仅 AI）**：基于 8/31 中期仓库快照，使用与最终评审同一套 AI 维度标准执行一次 AI 评审，不安排人工评审。
+- **最终评价（80%，AI + 人工）**：AI 评审与人工评审两个独立评委，**AI 与人工总分一致**，成绩直接相加。
+
+| 赛道 | AI 评审 | 人工评审 | 最终小计 |
+|:----:|:------:|:------:|:------:|
+| 赛道一 | 12维 / 200 | 8维 / 200 | 400 |
+| 赛道二 | 8维 / 100 | 6维 / 100 | 200 |
+
+**最终成绩 = 中期 AI（20%）+ 最终（AI + 人工）（80%）**。AI 与人工完全独立，人工不覆盖 AI 分。
+
+### 6.2 赛道一人工维度（8维 / 200分）
+
+| 维度 | 分值 | 考察点 |
+|:-----|:----:|:-------|
+| 现场真实性验证 | 20 | 视频/提交与代码一致（无现场演示，占比压低）|
+| 演示完整性 | 30 | 核心功能展示到位、覆盖 README 声称 |
+| AI 协作真实性 | 40 | 讲解的 AI 使用 vs 提交日志吻合；人主导+AI辅助 |
+| AI 工具链理解 | 30 | Agent 架构/LLM/工具选择口头理解 |
+| 答辩与技术深度 | 40 | 实现原理、架构讲解、质疑回应 |
+| 演示与表达 | 20 | PPT、讲解、时间 |
+| 创新与价值 | 10 | 场景价值、Agent 不可替代性 |
+| 问题与改进意识 | 10 | 局限认知、改进计划 |
+
+### 6.3 赛道二人工维度（6维 / 100分）
+
+| 维度 | 分值 | 考察点 |
+|:-----|:----:|:-------|
+| 现场真实性验证 | 10 | 视频/提交与代码一致 |
+| 演示完整性 | 20 | 核心集成场景展示到位 |
+| 提效验证 | 30 | 提效幅度真实对比数据 |
+| 答辩与技术深度 | 20 | IDE 集成技术原理、质疑回应 |
+| 演示与表达 | 10 | PPT、讲解 |
+| 创新与价值 | 10 | 场景价值、ROI |
+
+> 中期评价不涉及人工评委；人工评审仅在最终评价（发表会）进行。5 名评委独立打分取平均。详细设计见 `docs/design/07-人工评审设计方案.md`。
+
+---
+
+## 7. 已知边界与注意
+
+1. **评分用于相对排序更可信**：绝对分数受 AI 波动影响，多轮聚合取中位数缓解。
+2. **确定性机制是"压制"而非"逐条证明"**：空壳率/一致性率等指标用于降档封顶，不逐条判定对错；重大存疑由人工复核。
+3. **文档权重已刻意压低**：赛道一功能真实类占42.5%、文档类13.5%，防止"假文档拿高分"。
+4. **评审结束删除 clone 目录**：只保留 review_snapshots（评分快照）与 feature_inventory（功能清单）。
+5. **并发限制**：MAX_CONCURRENT=3，第4个条目起排队。
+
+---
+
+*本文档由评审系统实现自动同步；如与 `server/config/standards/*.md` 标准文件冲突，以标准文件为准。*
@@ -373,6 +373,21 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 - 多步骤/多配置的功能（如企业标准A/B切换、检索策略对比），README 须提供分步命令清单，评审者将照此逐条执行
 - 文档声称的功能须能在代码/运行中找到对应实现（「声称 vs 实测」交叉验证）

+### 2.9.1 验收命令块（README 建议提供，2026-08-27 新增）
+
+**建议在 README 末尾提供 `## 验收` 命令块**，给出评审系统可自动执行的一键验收命令（构建 → 测试 → 启动核心功能）。系统会在评审时**真实执行**并留存输出，作为「功能完整」相关维度确定性证据：
+
+```markdown
+## 验收
+一键执行验收（构建 → 测试 → 启动核心功能）：
+\`\`\`bash
+npm run build && npm test          # 示例：按实际技术栈替换
+\`\`\`
+```
+
+- 命令须无需人工干预可执行；无法一键验收的也要给出可执行命令。
+- 无 `## 验收` 块不强制扣分，但缺少该证据时「功能完整性」维度的验收证据将不完整。
+
 ---

 ## 2.10 提交前自查清单
@@ -393,6 +408,7 @@ README 是评审者了解作品的第一个入口，**必须尽可能说清楚**
 - [ ] 所有 LLM/API 调用处均已设置超时或异常防护
 - [ ] 样本数据全部脱敏或虚构，无真实业务/客户数据
 - [ ] 源码可按 README 步骤运行；已 push 且本地远端一致
+- [ ] README 含 **`## 验收` 命令块**（建议提供一键验收命令）

 ---

@@ -283,6 +283,8 @@ A 阶段完成时写入**部分 ai_report**（含 A 维度 + scoreA），`a_done
 | `entries` 表 | migration 新增 `score_a REAL DEFAULT 0`、`score_b REAL DEFAULT 0`、`stage_b_status TEXT DEFAULT ''`（''=未执行 / done / failed / skipped）、`project_understanding TEXT DEFAULT ''`（§2.7 项目理解文档 JSON，A 每次重评覆盖） |
 | `review_snapshots` | migration 新增 `score REAL`（含迟交扣分的 final_score，多次评审聚合用，2026-08-19） |
 | `entries` 表 | migration 新增 `benchmark_json TEXT DEFAULT ''`（决赛圈基准证据按 entry 落库，2026-08-19） |
+| `entries` 表 | migration 新增 `feature_inventory TEXT DEFAULT ''`（全量功能发现结果 JSON 数组，2026-08-27） |
+| `ai_report.dimensions[n]` | 实现类维度子 Agent 返回的定向追踪 `checks` 数组（feature/entry/depth/evidence/reason，2026-08-27 P1 修正） |
 | `standards.max_score` | **不改**（仅上传校验上限，非实际满分，不影响出分） |

 ## 4. 影响面
@@ -0,0 +1,89 @@
+# 07 人工评审设计方案
+
+> 版本：2026-08-31
+> 状态：设计定稿
+> 关联：AI 评审机制（`docs/AI评审机制说明.md`）
+
+## 1. 背景与定位
+
+技术大赛分**中期评价**与**最终评价**两个阶段，成绩按 **2:8** 加权合成。最终评价阶段采用 **AI 评审 + 人工评审双轨制**：发表会上各参赛队伍通过 PPT、视频、现场讲解对项目进行说明与演示，人工评审据此进行独立评分。中期评价仅由 AI 完成，不涉及人工评审。
+
+**AI 与人工的定位**：
+
+| 评委 | 负责 | 无法覆盖 |
+|:-----|:-----|:--------|
+| AI 评审（独立评委）| 静态真伪：代码、构建、测试、功能发现、文档一致性 | 演示表达、口头答辩、专家判断 |
+| 人工评审（独立评委）| 发表会表现：演示、答辩、创新价值、AI 过程可信度 | 全量代码审查 |
+
+两者**完全独立评分**（人工不覆盖 AI 分、不设 AI 争议复核维），最终**直接相加**成总分。
+
+## 2. 总分构成
+
+| 阶段 | 权重 | 评审方式 |
+|:-----|:---:|:---------|
+| **中期评价** | 20% | **仅 AI 评审**（无人工）|
+| **最终评价** | 80% | AI 评审 + 人工评审 |
+
+**最终成绩 = 中期评价（20%）+ 最终评价（80%）**。
+
+| 赛道 | AI 评审 | 人工评审 | 最终小计 |
+|:----:|:------:|:------:|:------:|
+| 赛道一 | 12维 / 200 | 8维 / 200 | 400 |
+| 赛道二 | 8维 / 100 | 6维 / 100 | 200 |
+
+**最终小计 = AI 分 + 人工分**（直接相加）。**AI 与人工总分一致**（赛道一各 200、赛道二各 100）。人工评审由 5 名评委独立打分取平均。
+
+## 3. 人工评审维度设计原则
+
+1. **真实性维度占比压低**：发表会无现场演示环节（仅 PPT/视频/讲解），真实度不好评价——现场真实性维度占比两赛道均控制在 **10%**。
+2. **全维度分值 ≥5**：避免出现 2/3 分的琐碎维度，保证每个维度有实际考察分量。
+3. **按赛道差异化**：赛道一聚焦 AI 协作过程（Agent 开发核心），赛道二聚焦提效验证（IDE 提效核心）。
+4. **剔除不可靠评价项**：团队协作（无法从发表会证明）、产品体验（无法现场体验）不纳入。
+
+## 4. 赛道一：人工评审（8 维 / 200 分）
+
+| # | 维度 | 分值 | 采分点 |
+|:-:|:-----|:----:|:-------|
+| 1 | 现场真实性验证 | 20 | 视频/提交核验：功能展示与提交代码一致、数据可信 |
+| 2 | 演示完整性 | 30 | 核心功能是否展示到位、覆盖 README 声称功能 |
+| 3 | **AI 协作真实性** | 40 | 讲解的 AI 使用过程 vs 提交的 AI 日志吻合；人主导 + AI 辅助 |
+| 4 | **AI 工具链理解** | 30 | 对 Agent 架构、LLM 调用、工具选择/降级的口头理解深度 |
+| 5 | 答辩与技术深度 | 40 | 实现原理理解、架构讲解、对评委质疑的回应质量 |
+| 6 | 演示与表达 | 20 | PPT 质量、讲解逻辑、语言清晰、时间控制 |
+| 7 | 创新与价值 | 10 | 场景真实价值、Agent 不可替代性、技术先进性 |
+| 8 | 问题与改进意识 | 10 | 主动讲局限、改进计划、对评审意见的接纳 |
+| | **合计** | **200** | |
+
+## 5. 赛道二：人工评审（6 维 / 100 分）
+
+| # | 维度 | 分值 | 采分点 |
+|:-:|:-----|:----:|:-------|
+| 1 | 现场真实性验证 | 10 | 视频/提交核验：IDE 集成展示与提交一致、数据可信 |
+| 2 | 演示完整性 | 20 | 核心集成场景是否展示到位 |
+| 3 | **提效验证** | 30 | 提效幅度有真实对比数据支撑、基准可信 |
+| 4 | 答辩与技术深度 | 20 | IDE 集成技术原理（LSP/Webview/命令等）、质疑回应 |
+| 5 | 演示与表达 | 10 | PPT、讲解、时间控制 |
+| 6 | 创新与价值 | 10 | 场景价值、提效价值、ROI |
+| | **合计** | **100** | |
+
+## 6. 赛道差异说明
+
+| 差异点 | 赛道一 | 赛道二 |
+|:------|:-------|:-------|
+| 核心考察 | AI 协作过程真实性 | 提效验证 |
+| 专属维度 | AI 协作真实性(40) + AI 工具链理解(30) | 提效验证(30) |
+| 总分制 | 200（与 AI 一致）| 100（与 AI 一致）|
+
+## 7. 实施要点（待后续实现）
+
+- **评分录入**：发表会后评委按维度打分表录入（前端表单）。
+- **数据落库**：新增人工评审记录表（entry_id、赛道、各维度分、评委、发表会日期）。
+- **总分合成**：最终成绩 = 中期 AI（20%）+ 最终（AI + 人工）（80%）；人工取 5 名评委平均分。
+- **展示**：前端发表会评分页 + 详情页显示中期 AI 分、最终 AI 分/人工分、最终成绩。
+- **PDF 报告**：评审报告增加中期评价与人工评审部分。
+
+## 8. 已知边界
+
+1. 人工评审的"现场真实性"因无现场演示，仅能核验视频/PPT 与提交一致性，**无法完全验证 demo 真伪**——故占比仅 10%。
+2. 人工评分受评委主观性影响，采用 **5 名评委独立打分取平均**缓解。
+3. 最终成绩由中期 AI（20%）+ 最终 AI/人工（80%）加权合成，AI 与人工在最终评价中占比相同；权重比例需在试运行后校准。
@@ -61,19 +61,13 @@ export interface FileSignature {
  lang: 'ts' | 'js' | 'py' | 'other';
  symbols: string[];      // export/function/class 定义行原文（≤5条）
 }
-export function buildInventory(files: {path,content}[]): {
-  signatures: FileSignature[];       // 全部文本文件
-  totalLines: number;
-  coreFiles: string[];               // 按规则选出的"精读文件包"
-}
+export function extractSignatures(files: {path,content}[]): FileSignature[];  // 全部文本文件
+export function renderInventoryText(sigs: FileSignature[], budgetChars?: number): string;  // 紧凑索引文本
 ```

 - **语言范围**：ts/tsx/js/jsx/mjs + python（def/class 正则）；其余语言仅记 path+lines
 - **符号提取**：正则匹配 `^(export\s+)?(async\s+)?(function|class|const\s+\w+\s*=\s*(\(|async))` 与 python `^def |^class `
- **coreFiles 选择规则**（替代现"前 60 个文件"粗暴截断）：
-  1. 入口/路由/服务/控制器目录下的代码文件（src/、app/、api/ 等）
-  2. DIM_FILE_FILTERS 各维度命中的文件
-  3. 按行数降序补足至预算
+- **精读文件选择（coreFiles）**：实现中不单独产出 coreFiles 字段——精读包由 `filterFilesForDim` 的维度过滤（`DIM_FILE_FILTERS`）+ 40000 字符预算承担，**符号索引全量注入**所有实现类维度 prompt 头部，保证 100% 文件可见（2026-08-27 对齐实现，原 buildInventory/coreFiles 接口未落地，已废弃）

 #### 3.1.2 投喂策略改造

@@ -92,7 +86,8 @@ export function buildInventory(files: {path,content}[]): {
   [{feature:'一句话功能', files:['文件:行号'], depth:'real|partial|stub'}]"
 合并去重 → FeatureInventory：
  { features:[{name, files, depth}], totalFiles, analyzedChunks }
-落库：entries.project_understanding 附加字段（或新列 feature_inventory TEXT）
+落库：entries.feature_inventory TEXT（JSON 数组，2026-08-27 新增 migration），
+      同时返回文本注入实现类维度 prompt；落库失败非致命（不影响注入）
 ```

 - 注入**功能完整性/规模·功能点**维度 prompt：「以下是全量代码扫描发现的实际功能清单，请对照 README 声称与验收基准逐项核对」
@@ -172,7 +167,7 @@ README/验收基准声称的核心功能如下：
 真实=该项满分权重；部分=50%权重；占位=0分。
 ```

- **评分绑定**：子 Agent 返回的 checks 表存入 ai_report.dimensions[n].checks；解析失败回退现状（不崩）
+- **评分绑定**：子 Agent 返回的 checks 表存入 ai_report.dimensions[n].checks（2026-08-27 修复：runSubAgent 最终 prompt 对实现类维度要求 checks 字段，parseDimResponse 解析并透传，供详情页/PDF 展示）；解析失败回退现状（不崩）
 - 结合 3.3 信号：toPrompt 中的 stubFiles 作为"重点核查"提示一并注入

 ### 3.5 判档修正：定性设计维度豁免 C 档（解决问题 #4）
@@ -235,13 +230,18 @@ export function isQuantEvidenceDim(name): boolean  // 替代 isEffectDim 在三

 ## 7. P1 实施清单

- [ ] code-inventory.ts 符号索引器 + 单测
- [ ] discoverFiles 投喂策略改造（索引全量 + coreFiles 全文 + 预算 40K）
- [ ] discoverFeatureInventory Map-Reduce 功能发现轮 + 落库 + 注入
- [ ] ai-log-audit.ts + git 变更集采集 + 封顶应用 + 注入 + 单测
- [ ] code-signals.ts + 单测
- [ ] 实现类维度定向追踪 prompt 模板 + checks 解析 + 评分绑定
- [ ] standard-utils.ts 判档白名单重构（isQuantEvidenceDim）+ 相关单测更新
- [ ] 分支提醒
- [ ] AGENTS.md 同步
- [ ] 回归：§6 四场景实测 + 全量 vitest
+- [x] code-inventory.ts 符号索引器 + 单测
+- [x] discoverFiles 投喂策略改造（索引全量 + coreFiles 全文 + 预算 40K）
+- [x] discoverFeatureInventory Map-Reduce 功能发现轮 + 落库（feature_inventory 列）+ 注入
+- [x] ai-log-audit.ts + git 变更集采集 + 封顶应用 + 注入 + 单测
+- [x] code-signals.ts + 单测
+- [x] 实现类维度定向追踪 prompt 模板 + checks 解析 + 评分绑定
+- [x] standard-utils.ts 判档白名单重构（isQuantEvidenceDim）+ 相关单测更新
+- [x] 分支提醒
+- [x] AGENTS.md 同步
+- [x] 回归：§6 四场景实测 + 全量 vitest
+
+> **2026-08-27 修正记录**：P1 落地后审计发现 3 处文档-实现偏差，均已修正——
+> ① §3.4 checks 表：原实现只注入 prompt 不解析存储，已修复（runSubAgent 最终 prompt 要求 checks + parseDimResponse 透传 + 5 项单测）；
+> ② §3.1.3 功能发现落库：原仅内存注入，已新增 entries.feature_inventory 列落库；
+> ③ §3.1.1 coreFiles 接口：原设计 buildInventory/coreFiles 未落地，精读包由 filterFilesForDim + 40K 预算承担，文档已对齐实现。
@@ -48,7 +48,7 @@

 **验收标准：**
 - US-04-1 带 track 创建项目 → 自动导入对应赛道默认标准
- US-04-2 赛道一/赛道二 标准维度数与总分符合模板（赛道一 12维/150、赛道二 8维/100）
+- US-04-2 赛道一/赛道二 标准维度数与总分符合模板（赛道一 12维/200、赛道二 8维/100）

 ### US-05 选择官方选题的参赛者（A1-A6/B1-B6）
 **作为** 一名选择官方给定选题的参赛者，
@@ -137,6 +137,39 @@

 > **项目理解文档（评审必读）**：评审系统会读取仓库内文档与源码自动生成"项目理解文档"。因此代码与文档应真实反映实际实现，**文档声称的功能须能在代码/运行中找到对应实现**（存在"声称 vs 实测"交叉验证，不符将扣分）。

+### 7.1 验收命令块（README 必填，2026-08-27 新增）
+
+**README.md 末尾须提供 `## 验收` 命令块**，给出评审系统可自动执行的验收命令（一键构建 + 跑测试 + 启动，验证"声称的核心功能真实可用"）。系统会在评审时**真实执行**该命令并留存输出：
+
+```markdown
+## 验收
+一键执行验收（构建 → 测试 → 启动核心功能）：
+\`\`\`bash
+npm run build && npm test          # 示例：按实际技术栈替换
+\`\`\`
+```
+
+要求：
+- 命令须**无需人工干预可执行**（不依赖交互式输入、不依赖私有网络）。
+- 验收命令输出应能证明"核心功能跑通"（如测试通过汇总、服务启动日志）。
+- 无法一键验收的项目（如纯静态演示）也要给出可执行命令；**无 `## 验收` 块的项目，评审时该证据缺失，相关维度（实现完整度/效果与数据）无法获得验收证据分**。
+
+### 7.2 测量协议（data/measurement/，提效/效果类作品必填，2026-08-27 新增）
+
+**申报提效/效果数据的作品**（如"提效幅度 X%"）须在仓库内提交**可复现的测量协议**，供评审核查数据真实性：
+
+```
+data/measurement/
+├── baseline/            # 改造前基线：测量脚本 + 原始输出
+├── README.md            # 测量说明：环境、步骤、指标口径
+└── timing-log.*         # 逐次测量记录（时间戳 + 指标值）
+```
+
+- 无基线的提效声明：评审按"数据缺位（未证明）"处理，提效/效果类维度封顶（详见评审标准）。
+- 测量记录应包含：测量日期、运行环境、重复次数、单次结果与汇总。
+
+> 上述 `## 验收` 命令块与测量协议均系**确定性证据**——系统真实执行并留存输出，AI 评分必须据此，不得忽略或低估。
+
 ---

 ## 8. 成果物清单与放置规则
@@ -201,6 +234,7 @@
 - [ ] `_AI_USAGE_LOG.md` 字段完整，范式步骤与范式图一致
 - [ ] 文件名无空格/中文/特殊字符；无密钥/token/.env/构建产物
 - [ ] 源码可按 README 启动运行；已 `git push`，本地与远端一致
+- [ ] README.md 含 **`## 验收` 命令块**（一键构建+测试+启动）；申报提效数据的提交 `data/measurement/` 测量协议

 ## 11. 违规后果

@@ -134,6 +134,39 @@

 > **项目理解文档（评审必读）**：评审系统会读取仓库内文档与源码自动生成"项目理解文档"。因此代码与文档应真实反映实际实现，**文档声称的功能须能在代码/运行中找到对应实现**（存在"声称 vs 实测"交叉验证，不符将扣分）。

+### 7.1 验收命令块（README 必填，2026-08-27 新增）
+
+**README.md 末尾须提供 `## 验收` 命令块**，给出评审系统可自动执行的验收命令（一键构建 + 跑测试 + 启动，验证"声称的核心功能真实可用"）。系统会在评审时**真实执行**该命令并留存输出：
+
+```markdown
+## 验收
+一键执行验收（构建 → 测试 → 启动核心功能）：
+\`\`\`bash
+npm run build && npm test          # 示例：按实际技术栈替换
+\`\`\`
+```
+
+要求：
+- 命令须**无需人工干预可执行**（不依赖交互式输入、不依赖私有网络）。
+- 验收命令输出应能证明"核心功能跑通"（如测试通过汇总、服务启动日志）。
+- 无法一键验收的项目（如纯静态演示）也要给出可执行命令；**无 `## 验收` 块的项目，评审时该证据缺失，相关维度（实现完整度/效果与数据）无法获得验收证据分**。
+
+### 7.2 测量协议（data/measurement/，提效/效果类作品必填，2026-08-27 新增）
+
+**申报提效/效果数据的作品**（如"提效幅度 X%"）须在仓库内提交**可复现的测量协议**，供评审核查数据真实性：
+
+```
+data/measurement/
+├── baseline/            # 改造前基线：测量脚本 + 原始输出
+├── README.md            # 测量说明：环境、步骤、指标口径
+└── timing-log.*         # 逐次测量记录（时间戳 + 指标值）
+```
+
+- 无基线的提效声明：评审按"数据缺位（未证明）"处理，提效/效果类维度封顶（详见评审标准）。
+- 测量记录应包含：测量日期、运行环境、重复次数、单次结果与汇总。
+
+> 上述 `## 验收` 命令块与测量协议均系**确定性证据**——系统真实执行并留存输出，AI 评分必须据此，不得忽略或低估。
+
 ---

 ## 8. 成果物清单与放置规则
@@ -198,6 +231,7 @@
 - [ ] `_AI_USAGE_LOG.md` 字段完整，范式步骤与范式图一致
 - [ ] 文件名无空格/中文/特殊字符；无密钥/token/.env/构建产物
 - [ ] 源码可按 README 启动运行；已 `git push`，本地与远端一致
+- [ ] README.md 含 **`## 验收` 命令块**（一键构建+测试+启动）；申报提效数据的提交 `data/measurement/` 测量协议

 ## 11. 违规后果

@@ -0,0 +1,79 @@
+# 评审表（评委打分用）
+
+> 版本：2026-08-31
+> 用途：发表会人工评审打分（最终评价）
+> 说明：评委按档位打分（优秀 85-100% / 合格 50-84% / 不足 <50%），**5 名评委独立打分取平均分**。赛道一人工总分 200（与 AI 评审一致）、赛道二人工总分 100（与 AI 评审一致）。
+
+**队伍信息**：____________　**赛道**：□ 赛道一 　□ 赛道二　**评委**：____________　**日期**：____________
+
+---
+
+## 赛道一 · 人工评审表（8 维 / 200 分）
+
+| # | 维度 | 分值 | 打分区间 | 考察点 | 得分 |
+|:-:|:-----|:----:|:---------|:-------|:----:|
+| 1 | 现场真实性验证 | 20 | 优秀 17-20 / 合格 10-16 / 不足 <10 | 演示与代码一致、数据可信 | ____ |
+| 2 | 演示完整性 | 30 | 优秀 25.5-30 / 合格 15-25.4 / 不足 <15 | 核心功能展示到位、覆盖 README 声称 | ____ |
+| 3 | AI 协作真实性 | 40 | 优秀 34-40 / 合格 20-33 / 不足 <20 | 讲解 vs AI 日志吻合、人主导+AI辅助 | ____ |
+| 4 | AI 工具链理解 | 30 | 优秀 25.5-30 / 合格 15-25.4 / 不足 <15 | Agent 架构/LLM/工具选择/降级 | ____ |
+| 5 | 答辩与技术深度 | 40 | 优秀 34-40 / 合格 20-33 / 不足 <20 | 实现原理、架构讲解、质疑回应 | ____ |
+| 6 | 演示与表达 | 20 | 优秀 17-20 / 合格 10-16 / 不足 <10 | PPT 质量、讲解、时间控制 | ____ |
+| 7 | 创新与价值 | 10 | 优秀 8.5-10 / 合格 5-8.4 / 不足 <5 | 场景价值、Agent 不可替代性 | ____ |
+| 8 | 问题与改进意识 | 10 | 优秀 8.5-10 / 合格 5-8.4 / 不足 <5 | 局限认知、改进计划 | ____ |
+| | **合计** | **200** | | | **____** |
+
+---
+
+## 赛道二 · 人工评审表（6 维 / 100 分）
+
+| # | 维度 | 分值 | 打分区间 | 考察点 | 得分 |
+|:-:|:-----|:----:|:---------|:-------|:----:|
+| 1 | 现场真实性验证 | 10 | 优秀 8.5-10 / 合格 5-8.4 / 不足 <5 | 演示与代码一致、数据可信 | ____ |
+| 2 | 演示完整性 | 20 | 优秀 17-20 / 合格 10-16 / 不足 <10 | IDE 集成核心场景演示到位 | ____ |
+| 3 | 提效验证 | 30 | 优秀 25.5-30 / 合格 15-25.4 / 不足 <15 | 提效对比数据真实、基准可信 | ____ |
+| 4 | 答辩与技术深度 | 20 | 优秀 17-20 / 合格 10-16 / 不足 <10 | IDE 集成技术理解、质疑回应 | ____ |
+| 5 | 演示与表达 | 10 | 优秀 8.5-10 / 合格 5-8.4 / 不足 <5 | PPT 质量、讲解 | ____ |
+| 6 | 创新与价值 | 10 | 优秀 8.5-10 / 合格 5-8.4 / 不足 <5 | 场景价值、提效价值、ROI | ____ |
+| | **合计** | **100** | | | **____** |
+
+---
+
+## 评委参考问题（答辩提问）
+
+### 通用（两赛道）
+
+| 维度 | 参考问题 |
+|:-----|:---------|
+| 现场真实性 | "这个功能对应的代码在哪？演示数据怎么生成的、能复现吗？视频和提交是同一版本吗？" |
+| 演示完整性 | "README 声称的 X 功能演示一下？核心业务闭环完整演示了吗？" |
+| 答辩与技术 | "这个技术选型为什么这么选？模块边界/异常怎么处理？场景变化能支撑吗？" |
+| 演示与表达 | （观察 PPT 质量、讲解逻辑、时间控制） |
+| 创新与价值 | "为什么非这么做不可？传统方法解决不了吗？实际用在哪？" |
+
+### 赛道一专属
+
+| 维度 | 参考问题 |
+|:-----|:---------|
+| AI 协作真实性 | "哪个环节用了 AI？用了哪些模型？日志这条记录对应哪个改动？人写 vs AI 生成怎么分工？怎么把控质量？" |
+| AI 工具链理解 | "Agent 怎么决定调用哪个工具？LLM 失败怎么降级？多步任务怎么规划执行？" |
+
+### 赛道二专属
+
+| 维度 | 参考问题 |
+|:-----|:---------|
+| 提效验证 | "改造前基线怎么测的？前后环境一致吗？测了几次取什么值？提效 X% 怎么算的？" |
+
+---
+
+## 评分备注
+
+- **造假标记**：若发现演示与提交明显不符/数据伪造，在下方备注并上报组委会。
+- **AI 分复核建议**：如认为 AI 分与该队实际表现差异大，备注"建议复核"（不直接改 AI 分）。
+- **中期评价不涉及本表**：中期评价（20%）仅由 AI 完成，本表仅用于最终评价（80%）的人工评审部分；最终成绩 = 中期 AI（20%）+ 最终（AI + 人工）（80%）。
+- **5 名评委独立打分**，各队人工评审成绩取 5 人平均分。
+
+**备注**：____________________________________________________________
+
+---
+
+*配套文档：《赛事说明》《评审规则详细说明》。*
@@ -0,0 +1,313 @@
+# 评审规则详细说明
+
+> 版本：2026-08-31
+> 适用：技术大赛 赛道一 / 赛道二 评审
+> 读者：评委（重点）、组委会
+
+本文档详细说明评审规则：**中期评价（仅 AI）+ 最终评价（AI + 人工）** 的整体结构、AI 评审标准概览 + **人工评审（发表会）的详细评分指南**，帮助评委在发表会上准确、一致地评价各参赛队。
+
+---
+
+## 1. 评审体系总览
+
+技术大赛分**中期评价**与**最终评价**两个阶段，成绩按 **2:8** 加权合成：
+
+| 阶段 | 权重 | 评审方式 | 依据 |
+|:-----|:---:|:---------|:-----|
+| **中期评价** | 20% | **仅 AI 评审**（无人工）| 8/31 中期仓库快照，AI 静态评审 |
+| **最终评价** | 80% | AI 评审 + 人工评审 | AI 拉仓库静态评审 + 发表会现场人工打分 |
+
+**最终成绩 = 中期评价（20%）+ 最终评价（80%）**。
+
+- **中期评价（20%，仅 AI）**：基于 8/31 中期提交的仓库快照，由系统自动执行一次 AI 评审，只评已完成部分。**不安排人工评审**。
+- **最终评价（80%，AI + 人工）**：AI 评审（静态全面审查）与人工评审（发表会现场评价）两个评委构成，**AI 与人工总分一致**，成绩直接相加。
+
+**评分构成**：
+- 赛道一：AI 12 维 / 200 + 人工 8 维 / 200 = 最终 400；中期 20% + 最终 80% 加权合成
+- 赛道二：AI 8 维 / 100 + 人工 6 维 / 100 = 最终 200；中期 20% + 最终 80% 加权合成
+
+> 中期仅 AI 完成；人工评审只在最终评价（发表会）进行。两轨完全独立：人工评审不覆盖、不修改 AI 分。
+
+---
+
+## 2. AI 评审标准（概览）
+
+AI 评审由系统自动完成，评委主要了解其评什么、结果如何解读。详细采分机制见《AI评审机制说明》。
+
+> **中期评价**：使用与最终评审**同一套 AI 维度标准**，对 8/31 中期快照执行一次 AI 评审，作为最终成绩的 20% 权重。中期不涉及人工评委，其评分说明由系统自动生成。
+
+### 2.1 赛道一：AI 维度（12 维 / 200 分）
+
+| 维度 | 分值 | 一句话标准 |
+|:-----|:----:|:----------|
+| 场景价值与技术合理性 | 15 | 真实业务问题、Agent 不可替代 |
+| 开发范式应用 | 8 | AI 开发流程真实性 |
+| 架构设计 | 15 | 架构文档与代码质量 |
+| 工具使用与Skill集成深度 | 10 | AI 框架与工具链 |
+| Agent核心能力 | 30 | LLM 调用/工具/重试/状态 |
+| 实现完整度与稳定性 | 35 | 功能真实、构建可运行 |
+| 规模与功能点 | 25 | 真实功能数与占位 |
+| 代码规范性 | 10 | 命名/硬编码/重复 |
+| 演示与文档 | 8 | 文档质量与一致性 |
+| AI使用日志 | 10 | 日志真实性与占位率 |
+| 效果与数据 | 25 | 测试/覆盖率/对比数据 |
+| 安全性 | 9 | 密钥/输入/敏感信息 |
+
+### 2.2 赛道二：AI 维度（8 维 / 100 分）
+
+| 维度 | 分值 | 一句话标准 |
+|:-----|:----:|:----------|
+| 开发范式设计清晰度 | 20 | 提效范式定义与落地 |
+| IDE集成深度 | 20 | IDE 真实集成能力 |
+| 提效设计合理性 | 10 | 提效方案设计思路 |
+| 提效幅度 | 10 | 真实对比数据支撑 |
+| 稳定性与易用性 | 15 | 构建可运行、易用 |
+| 规模与功能点与技术难度 | 10 | 功能数与技术难度 |
+| 演示与文档 | 5 | 文档质量与一致性 |
+| AI使用日志 | 10 | 日志真实性与占位率 |
+
+### 2.3 AI 评审的确定性机制（要点）
+
+AI 评审的"真假判定"全部由系统确定性计算，不靠 AI 主观：
+
+- **构建/测试验证**：真实构建、真跑测试，解析通过率与覆盖率。
+- **功能发现轮**：全量扫描源码，统计真实/部分/占位功能。
+- **文档一致性**：文档声称的功能 ↔ 代码真实实现交叉比对。
+- **质量评估**：空壳率、重复率、测试有效度。
+- **硬规则封顶**：构建失败、测试失败、文档虚报 → 相关维度封顶。
+
+> 评委无需理解全部机制细节，重点是：**AI 分反映的是"静态代码质量"，人工分反映"发表会表现"**，两者互补。
+
+---
+
+## 3. 人工评审（发表会）
+
+### 3.1 发表会流程
+
+| 环节 | 时长 | 内容 |
+|:-----|:----:|:-----|
+| PPT 讲解 | 约 5-8 分钟 | 团队、主题、解决的问题、方案说明 |
+| 视频演示 | ≤10 分钟 | 项目主要功能演示 |
+| 答辩提问 | 约 5-10 分钟 | 评委按评审表维度提问 |
+
+**赛道一追加**：PPT 须说明 **Agent 的作用**（AI 角色、如何工作、Agent 闭环）。
+
+### 3.2 评分方式
+
+- 每位评委按评审表对每条目逐维度打分。
+- 打分采用**三档制**：评委先判断档位（优秀/合格/不足），再在该档位区间内给具体分。
+- **5 名评委独立打分，取平均分**作为该队人工评审成绩。
+- 打分区间（占该维度满分比例）：
+  - **优秀（85~100%）**：表现突出，明显超出基本要求
+  - **合格（50~84%）**：达到基本要求，无明显硬伤
+  - **不足（<50%）**：明显缺失或无法展示
+
+---
+
+### 3.3 赛道一人工评审评分指南（8 维 / 200 分）
+
+#### 维度 1：现场真实性验证（20 分）
+
+**考察**：视频/讲解展示的功能与提交代码是否一致，数据是否可信。
+
+| 档位 | 表现描述 |
+|:----|:---------|
+| 优秀 | 演示功能与代码完全对应，数据可追溯，讲解与提交一致 |
+| 合格 | 主要功能一致，个别细节模糊 |
+| 不足 | 演示与提交明显不符，或关键功能无法展示 |
+
+**评委参考问题**：
+- "请说明这个功能对应的代码位置？"
+- "这个演示数据是怎么生成的？能复现吗？"
+- "视频里演示的和仓库里提交的是同一版本吗？"
+
+#### 维度 2：演示完整性（30 分）
+
+**考察**：核心功能是否展示到位，是否覆盖 README 声称的功能。
+
+| 档位 | 表现描述 |
+|:----|:---------|
+| 优秀 | 核心功能全部演示，覆盖 README 声称，演示路径完整 |
+| 合格 | 主要功能演示，个别次要功能未覆盖 |
+| 不足 | 仅演示少量功能，或与声称功能差距大 |
+
+**评委参考问题**：
+- "README 声称的 X 功能能演示一下吗？"
+- "你们的核心业务闭环完整演示了吗？"
+
+#### 维度 3：AI 协作真实性（40 分）
+
+**考察**：讲解的 AI 使用过程 ↔ 提交的 AI 日志是否吻合；人主导 + AI 辅助。
+
+| 档位 | 表现描述 |
+|:----|:---------|
+| 优秀 | AI 使用过程讲得具体可信，与日志逐条吻合，人机分工清晰 |
+| 合格 | 大致吻合，细节不完整 |
+| 不足 | 讲解与日志明显不符，或说不清 AI 怎么用的 |
+
+**评委参考问题**：
+- "你们在哪个环节用了 AI？用了哪些模型？"
+- "AI 日志里这条记录对应哪个改动？"
+- "哪些部分是人写的、哪些是 AI 生成的？怎么把控质量？"
+
+#### 维度 4：AI 工具链理解（30 分）
+
+**考察**：对 Agent 架构、LLM 调用、工具选择/降级机制的口头理解。
+
+| 档位 | 表现描述 |
+|:----|:---------|
+| 优秀 | 能清晰讲清 Agent 架构、工具调用、异常降级原理 |
+| 合格 | 能基本讲清主要机制 |
+| 不足 | 说不清 Agent 怎么工作，或只是"套用" |
+
+**评委参考问题**：
+- "你的 Agent 怎么决定调用哪个工具？"
+- "LLM 调用失败时怎么处理？有降级吗？"
+- "多步任务怎么规划和执行的？"
+
+#### 维度 5：答辩与技术深度（40 分）
+
+**考察**：实现原理、架构讲解、对质疑的回应质量。
+
+| 档位 | 表现描述 |
+|:----|:---------|
+| 优秀 | 技术细节掌握扎实，能深入讲解原理，回应质疑有理有据 |
+| 合格 | 能讲解主要实现，回应基本到位 |
+| 不足 | 说不清实现原理，回避问题或答非所问 |
+
+**评委参考问题**：
+- "这个技术选型为什么这么选？有对比吗？"
+- "这个模块的边界/异常情况怎么处理？"
+- "如果数据量增大/场景变化，你的方案能支撑吗？"
+
+#### 维度 6：演示与表达（20 分）
+
+**考察**：PPT 质量、讲解逻辑、语言清晰、时间控制。
+
+| 档位 | 表现描述 |
+|:----|:---------|
+| 优秀 | PPT 专业、讲解流畅有感染力、时间控制好 |
+| 合格 | 表达清楚，个别环节平淡 |
+| 不足 | PPT 混乱、讲解不清或严重超时 |
+
+#### 维度 7：创新与价值（10 分）
+
+**考察**：场景真实价值、Agent 不可替代性、技术先进性。
+
+| 档位 | 表现描述 |
+|:----|:---------|
+| 优秀 | 解决真实痛点，Agent 不可替代性明确，有创新 |
+| 合格 | 有价值但创新性或必要性一般 |
+| 不足 | 场景价值弱，或用传统方法也能做 |
+
+**评委参考问题**：
+- "为什么非用 Agent 不可？传统脚本/工具解决不了吗？"
+- "这个场景真实存在吗？实际用在哪？"
+
+#### 维度 8：问题与改进意识（10 分）
+
+**考察**：主动讲局限、改进计划、对评审意见的接纳。
+
+| 档位 | 表现描述 |
+|:----|:---------|
+| 优秀 | 主动讲清局限与改进计划，接纳意见 |
+| 合格 | 能回应但不够主动 |
+| 不足 | 回避不足或拒不接纳 |
+
+---
+
+### 3.4 赛道二人工评审评分指南（6 维 / 100 分）
+
+#### 维度 1：现场真实性验证（10 分）
+
+| 档位 | 表现描述 |
+|:----|:---------|
+| 优秀 | 演示与代码一致、数据可信可复现 |
+| 合格 | 主要一致，细节模糊 |
+| 不足 | 明显不符或无法展示 |
+
+**参考问题**："提效数据怎么测的？能现场复现吗？"
+
+#### 维度 2：演示完整性（20 分）
+
+| 档位 | 表现描述 |
+|:----|:---------|
+| 优秀 | IDE 集成核心场景完整演示 |
+| 合格 | 主要场景演示 |
+| 不足 | 少量演示或演示失败 |
+
+#### 维度 3：提效验证（30 分）
+
+**考察**：提效幅度有真实对比数据支撑、基准可信。
+
+| 档位 | 表现描述 |
+|:----|:---------|
+| 优秀 | 有清晰的改造前/后对比数据，测量方法可信，提效幅度有说服力 |
+| 合格 | 有对比数据但方法或样本不够严谨 |
+| 不足 | 只有口头声称，无数据或数据不可信 |
+
+**评委参考问题**：
+- "改造前基线是怎么测的？和改造后环境一致吗？"
+- "测了几次？平均还是最优值？"
+- "提效 XX% 是怎么算出来的？"
+
+#### 维度 4：答辩与技术深度（20 分）
+
+| 档位 | 表现描述 |
+|:----|:---------|
+| 优秀 | 对 IDE 集成技术（LSP/Webview/命令等）理解深入 |
+| 合格 | 能讲清主要实现 |
+| 不足 | 说不清实现原理 |
+
+#### 维度 5：演示与表达（10 分）
+
+| 档位 | 表现描述 |
+|:----|:---------|
+| 优秀 | PPT 专业、讲解清晰 |
+| 合格 | 表达清楚 |
+| 不足 | 表达混乱 |
+
+#### 维度 6：创新与价值（10 分）
+
+| 档位 | 表现描述 |
+|:----|:---------|
+| 优秀 | 场景真实、提效价值明确、有先进性 |
+| 合格 | 有价值但一般 |
+| 不足 | 价值弱 |
+
+---
+
+## 4. 评分注意事项
+
+### 4.1 真实性是硬底线
+
+- 现场真实性维度虽然分值占比低（10%），但**若发现明显造假**（演示与提交不符、数据伪造），评委应在评分表备注中标注，并上报组委会。
+- 提效/效果数据必须追问**测量方法**，防"编数据"。
+
+### 4.2 三档制的使用
+
+- 先整体判断档位，再在档位区间给分，避免随意给分。
+- 档位区间：优秀 85-100%、合格 50-84%、不足 <50%。
+- 例：赛道一维度 3（AI 协作真实性，满分 40），优秀=34-40、合格=20-33、不足=<20。
+
+### 4.3 多评委一致性
+
+- 5 名评委各自独立打分，不互相讨论后统一给分。
+- 最终**取 5 人平均分**作为人工评审成绩。
+- 分差过大的维度（评委间差 >40%）提交组委会复核。
+
+### 4.4 与 AI 分的关系
+
+- 人工评审**只看发表会表现**，不因 AI 分高低调整人工分。
+- 评委如认为 AI 分与该队实际表现差异大，可备注"建议复核"，由组委会处理，不直接改分。
+- **中期评价仅由 AI 完成**，评委不参与；最终成绩 = 中期 AI（20%）+ 最终（AI + 人工）（80%）。
+
+---
+
+## 5. 评审表
+
+评委在发表会使用《评审表》打分（附维度、分值、打分区间、参考问题摘要）。见配套文档《评审表》。
+
+---
+
+*本文档与《赛事说明》《评审表》配套使用。*
@@ -0,0 +1,194 @@
+# 赛事说明
+
+> 版本：2026-08-31
+> 适用范围：技术大赛 赛道一（Agent开发实战赛）/ 赛道二（IDE+开发范式创新赛）
+> 读者：参赛选手、评委、组委会
+
+本文档说明技术大赛的**赛程计划、整体评审规则、主要特点与维度总览**。成果物提交流程详见《参赛成果物提交规范-赛道一/赛道二》；评审的详细采分规则见《评审规则详细说明》。
+
+---
+
+## 1. 赛事概况
+
+| 项目 | 赛道一 | 赛道二 |
+|:-----|:-------|:-------|
+| 名称 | Agent开发实战赛 | IDE+开发范式创新赛 |
+| 主题 | 用 AI Agent 解决实际业务问题 | 打造 IDE 集成 / 提效工具 |
+| 参赛规模 | 9 队 | 5 队 |
+| 评审方式 | AI 评审 + 人工评审（发表会）双轨制 | 同左 |
+| 评价结构 | 中期评价（仅 AI）+ 最终评价（AI + 人工） | 同左 |
+
+---
+
+## 2. 赛程计划
+
+| 阶段 | 赛道一 | 赛道二 |
+|:-----|:-------|:-------|
+| 中期提交截止 | **8/31（周一）** | **8/31（周一）** |
+| 组委会反馈采集情况 | 9 月首周 | 9 月首周 |
+| **最终提交截止** | **10/31** | **9/15** |
+| **发表会（即评审）** | **11 月中** | **9 月底** |
+| 评审结果公开 | 11 月 | 9 月底 |
+
+### 2.1 中期提交（两赛道相同）
+
+- **截止**：8/31（周一）前提交中期成果至 Gitea。
+- **内容**：成果物清单（§3）中任选部分即可，不要求全部；将已完成部分提交即可。
+- **方式**：`git push` 到 main 分支，确保服务器能采集。
+- **反馈**：8/31 后约 1 周内（9 月首周），组委会反馈各队成果物的采集情况。
+
+> **中期评价**：组委会将基于中期仓库快照执行一次 AI 评审（仅 AI，无人工），其结果按 §4.1 计入最终成绩。
+
+### 2.2 最终提交与发表会
+
+| 事项 | 赛道一 | 赛道二 |
+|:-----|:-------|:-------|
+| 最终提交截止 | 10/31 | 9/15 |
+| 提交内容 | 最终成果物（部分或全部）| **必须提交全部成果物（01-06）** |
+| 发表会 | 11 月中 | 9 月底 |
+| 发表材料 | PPT + 视频 ≤10 分钟 + 讲解 | PPT + 视频 ≤10 分钟 + 讲解 |
+
+**发表会材料要求**：
+- **PPT≤10 分钟**：介绍团队、项目主题、解决的课题、提效说明等。
+- **视频 ≤10 分钟**：对项目主要功能进行演示。
+- **赛道一追加**：PPT 中须**说明 Agent 的作用**（AI 在项目中扮演什么角色、如何工作、Agent 闭环）。
+- 发表会现场评委按评审表打分，作为**人工评审**成绩。
+
+> **状态锁定**：最终提交截止后系统锁定该队状态，进入评审流程。
+
+---
+
+## 3. 成果物提交（详细要求见《参赛成果物提交规范-赛道一 / 赛道二》）
+
+### 3.1 提交方式
+
+- 各队使用组委会下发的 Gitea 独立账号，提交到统一仓库 `2026Technology-Competition`（main 分支）。
+- 账号密码**请勿修改**（评审系统依赖固定凭据拉取）。
+- 提交后验证服务器能正常拉取；无法采集及时联系组委会。
+
+### 3.2 成果物清单（01-06）
+
+| # | 成果物 | 放置位置 | 内容要点 |
+|:-:|:------|:--------|:--------|
+| 01 | 项目说明 | 根目录 `README.md` | 项目性质声明、概述、功能说明、效果总结、团队分工 |
+| 02 | 设计文档 | 根目录 `DESIGN.md` 或 `docs/` | 场景与价值、开发范式流程图、架构图 |
+| 03 | 源码 | 根目录或 `src/` | 可运行源码，安装/运行方法写 README |
+| 04 | 实验报告 | `tests/` + `coverage/` | 测试用例、执行结果、覆盖率报告 |
+| 05 | AI 使用日志 | 根目录 `_AI_USAGE_LOG.md` | 覆盖需求/设计/编码/测试全环节 |
+| 06 | 演示视频 | `docs/demo.mp4` 或根目录 | 赛道一 ≤15 分钟、赛道二 ≤5 分钟（仓库内视频）|
+
+### 3.3 强制要求（摘要）
+
+- **README 必须为根目录文件**；源码须能按 README 启动运行（基础前提）。
+- README 末尾须含 **`## 验收` 命令块**（一键构建+测试+启动，供系统真实执行）。
+- 申报提效/效果数据须提交 **`data/measurement/`** 测量协议（基线+测量记录）。
+- 禁止提交密钥/token/.env/构建产物；文件名用 ASCII，禁止空格与中文。
+
+---
+
+## 4. 评审方式：中期（仅 AI）+ 最终（AI + 人工）双轨制
+
+技术大赛分**中期评价**与**最终评价**两个阶段，成绩按 **2:8** 加权合成。
+
+### 4.1 评分构成
+
+| 阶段 | 权重 | 评审方式 |
+|:-----|:---:|:---------|
+| **中期评价** | 20% | **仅 AI 评审**（无人工）|
+| **最终评价** | 80% | AI 评审 + 人工评审 |
+
+**最终成绩 = 中期评价（20%）+ 最终评价（80%）**。
+
+- **中期评价（20%，仅 AI）**：基于 8/31 中期仓库快照，由 AI 静态评审已完成部分成果物。
+- **最终评价（80%，AI + 人工）**：AI 评审（静态全面审查）与人工评审（发表会现场评价）两个评委构成，**AI 与人工总分相同**，成绩直接相加。
+
+| 评审轨 | 评审什么 | 依据 |
+|:-------|:---------|:-----|
+| **AI 评审** | 代码、构建、测试、功能真实性、文档一致性、Agent 能力等 | 自动拉取仓库，确定性证据 + AI 评分 |
+| **人工评审** | 发表会表现：PPT、视频演示、讲解、答辩、创新价值等 | 评委现场按评审表打分 |
+
+> **说明**：中期评价只由 AI 完成、不安排人工评审；人工评审仅在最终评价（发表会）进行。AI 与人工评审各自独立评分，总分一致。
+
+---
+
+## 5. 评审主要特点
+
+| 特点 | 说明 |
+|:-----|:-----|
+| 🎯 **真实性优先** | 评分以"系统能否真实构建、功能是否真实现、测试是否真通过"为硬依据，而非文档写得漂亮 |
+| 🛡 **AI 不判真假** | 构建结果、测试通过率、功能占位率、日志占位率、文档一致性由系统**确定性判定**，AI 只评品质 |
+| 🚫 **防作弊** | 文档声称↔代码实现一致性校验；空壳率/重复率/测试有效度质量评估。补真→加分，编造→降权 |
+| 📊 **结果稳定** | 最近 3 次 AI 评审取中位数（2 次取平均）；标准快照隔离 |
+| 🔍 **可审计** | 每维度分带评语+证据引用；历次评审可对比 |
+| 👥 **双轨制** | 中期仅 AI 评审 + 最终 AI/人工双评审；AI 与人工总分一致 |
+
+---
+
+## 6. 评审维度总览
+
+### 6.1 赛道一：AI 评审维度（12 维 / 200 分）
+
+| # | 维度 | 分值 | 一句话介绍 |
+|:-:|:-----|:----:|:----------|
+| 1 | 场景价值与技术合理性 | 15 | 解决真实业务问题，Agent 不可替代 |
+| 2 | 开发范式应用 | 8 | AI 开发流程是否真实覆盖需求→设计→编码→测试 |
+| 3 | 架构设计 | 15 | 架构文档与代码分层、模块化、可扩展 |
+| 4 | 工具使用与Skill集成深度 | 10 | AI 框架、MCP/Function Calling、IDE 集成 |
+| 5 | Agent核心能力 | 30 | LLM 调用、工具选择、重试降级、状态持久化 |
+| 6 | 实现完整度与稳定性 | 35 | 功能真实实现、构建可运行、服务可启动 |
+| 7 | 规模与功能点 | 25 | 真实功能数量与占位比例 |
+| 8 | 代码规范性 | 10 | 命名、硬编码、重复代码、安全规范 |
+| 9 | 演示与文档 | 8 | README/文档质量与一致性 |
+| 10 | AI使用日志 | 10 | 日志真实性、占位率、过程可溯源 |
+| 11 | 效果与数据 | 25 | 测试通过、覆盖率、效果对比数据 |
+| 12 | 安全性 | 9 | 密钥管理、输入验证、敏感信息保护 |
+
+### 6.2 赛道二：AI 评审维度（8 维 / 100 分）
+
+| # | 维度 | 分值 | 一句话介绍 |
+|:-:|:-----|:----:|:----------|
+| 1 | 开发范式设计清晰度 | 20 | 提效范式定义与落地的清晰度 |
+| 2 | IDE集成深度 | 20 | 插件/工具在 IDE 中的真实集成能力 |
+| 3 | 提效设计合理性 | 10 | 提效方案设计思路的合理性 |
+| 4 | 提效幅度 | 10 | 提效幅度有真实对比数据支撑 |
+| 5 | 稳定性与易用性 | 15 | 构建可运行、测试通过、易用 |
+| 6 | 规模与功能点与技术难度 | 10 | 真实功能数量与技术难度 |
+| 7 | 演示与文档 | 5 | 文档质量与一致性 |
+| 8 | AI使用日志 | 10 | 日志真实性、占位率、过程可溯源 |
+
+### 6.3 人工评审维度（发表会）
+
+> 人工评审总分与 AI 评审总分一致（**赛道一 200 分 / 赛道二 100 分**），细分维度分值构成详见《评审表》。
+
+| 维度 | 赛道一 | 赛道二 |
+|:-----|:------:|:------:|
+| 现场真实性验证 | ● | ● |
+| 演示完整性 | ● | ● |
+| AI 协作真实性 / 提效验证 | ● | ● |
+| AI 工具链理解 / 答辩与技术深度 | ● | ● |
+| 答辩与技术深度 / 演示与表达 | ● | ● |
+| 演示与表达 / 创新与价值 | ● | ● |
+| 创新与价值 | ● | — |
+| 问题与改进意识 | ● | — |
+
+---
+
+## 7. 常见问题
+
+- **账号密码能改吗？** 不能。修改后评审系统无法拉取仓库，影响评审结果。
+- **仓库是自己建吗？** 不用。组委会已统一创建，直接 push 即可。
+- **中期成果要全部吗？** 不用，任选已完成部分提交即可；最终提交赛道二必须全部。
+- **视频时长？** 发表会视频 ≤10 分钟；仓库内演示视频赛道一 ≤15 分钟、赛道二 ≤5 分钟。
+- **如何判断自己是否提交成功？** push 后验证服务器可拉取；8/31 后 1 周内组委会反馈采集情况。
+- **中期评价怎么算？** 中期仅 AI 评审（无人工），占最终成绩 20%；最终评价（AI + 人工）占 80%，AI 与人工总分一致。
+
+---
+
+## 8. 联系方式
+
+- 提交异常 / 采集异常：联系组委会（联系方式另行通知）。
+- 技术栈 / AI API 问题：参考提交规范 §9 所需资源。
+
+---
+
+*本文档与《评审规则详细说明》《评审表》配套使用。*
@@ -0,0 +1,134 @@
+# 逸飞冲天 评审问题分析
+
+> 版本：2026-08-31
+> 对象：赛道一 · 逸飞冲天（T1-SD0401，COBOL→Java/Spark 迁移验证平台）
+> 目的：记录评审中发现的作品缺陷，说明评分差距的成因，供后续修复参考
+
+---
+
+## 1. 结论速览
+
+**逸飞冲天是"工作量巨大但未完成交付"的典型**：代码量、测试用例、基准程序都是全赛最多，但**核心交付物无法真实运行**——测试一个都跑不起来、Web 服务无法启动。这导致其运行验证类维度（实现完整度、效果与数据）被正确封顶，总分明显低于真正可运行的作品。
+
+| 项 | 数值 |
+|:---|:---:|
+| 评审总分 | **126 / 200** |
+| A 阶段（静态） | 105 / 140 |
+| B 阶段（运行验证） | 21 / 60 |
+| 前端验证 | ❌ 服务无法启动 |
+| 测试验证 | ❌ 830 用例 7 处导入错误，无法运行 |
+
+---
+
+## 2. 发现的问题
+
+### 问题 1：测试用例无法运行（最严重）
+
+**现象**：`python -m pytest` 收集 830 个测试用例时 **7 处导入错误**，测试完全无法运行。
+
+**证据**：
+```
+ERROR tests/test_golden.py
+ERROR tests/test_orchestrator.py
+ERROR tests/test_preprocessor.py
+!!! Interrupted: 7 errors during collection !!!
+830 tests collected, 7 errors in 5.57s
+```
+
+**根因**：测试文件用**扁平模块导入**，但对应模块不存在或位置不对。例如 `tests/test_golden.py:15`：
+
+```python
+from preprocessor import CopybookPreprocessor   # ← 根目录没有 preprocessor.py
+```
+
+实际解析逻辑在 `cobol_testgen/read.py` 等子包内，测试引用的模块路径与真实结构不匹配。
+
+**影响**：
+- 声称的 830 个测试用例、覆盖率验证全部**无法执行**
+- "效果与数据"维度（测试通过、覆盖率）只能给最低分
+
+---
+
+### 问题 2：Web 服务无法启动（前端不可访问）
+
+**现象**：`python -m uvicorn web.api:app` 启动即报错，前端页面（upload.html / result.html）无法访问。
+
+**证据**：
+```
+ImportError: cannot import name 'check_coverage' from 'cobol_testgen'
+```
+
+**根因**：`orchestrator.py:12` 导入了不存在的函数：
+
+```python
+from cobol_testgen import extract_structure, generate_data, incremental_supplement, check_coverage
+```
+
+但 `cobol_testgen/__init__.py` 中**没有导出 `check_coverage`**（实际有 `mark_coverage` 等，函数名不一致）。
+
+**影响**：
+- Web 前端（上传页面、结果页面）**实际无法访问**
+- "实现完整度与稳定性"因前端不可访问被封顶
+
+---
+
+### 问题 3：Python 包安装结构不完整
+
+**现象**：`pip install -e .` 无法正确安装为可导入的包。
+
+**证据**：`pyproject.toml` 有 `[project]` 声明（name、dependencies），但**缺少 `[tool.setuptools]` 的 packages 配置**，且项目依赖 `from preprocessor import`、`from orchestrator import` 这类**根级扁平导入**——只有把项目根目录加入 `sys.path` 才能工作，标准安装包结构下无法运行。
+
+**根因**：项目组织为根级模块（main.py、orchestrator.py、config.py）而非规范包（src/ 布局），测试与 Web 层依赖 `sys.path.insert` 临时路径 hack，导致：
+- `pip install -e .` 装完仍无法导入（问题 1 的放大）
+- 缺少 setup.py/setup.cfg，打包配置不完整
+
+---
+
+### 问题 4：声称与实现不一致（文档一致性低）
+
+**现象**：README 声称大量能力，但部分无法验证或与实现不符。
+
+**证据**：
+- 声称"非阻塞路径枚举 O(N) 算法"、"MC/DC 条件覆盖"、"DB 种子键一致性"等，但测试跑不起来，无法验证
+- 之前评审中"文档声称-代码实现一致性"仅 36%，核心功能声称与实际存在出入
+
+**影响**：场景价值、演示与文档维度被降权（真实性绑定）。
+
+---
+
+## 3. 与可运行作品（零号）的对比
+
+| 维度 | 零号 (158) | 逸飞冲天 (126) | 差距原因 |
+|:---|:---:|:---:|:---|
+| 文件数 | 604 | 815 | 逸飞冲天更多 |
+| 测试用例 | 619 | 830 | 逸飞冲天更多 |
+| **测试可运行** | ✅ 依赖装好后 619 全过 | ❌ 830 用例 7 导入错误 | **逸飞冲天测试结构缺陷** |
+| **Web 可访问** | ✅ 服务真实启动可访问 | ❌ 服务启动即报错 | **逸飞冲天导入错误** |
+| **实现完整度** | 28/35 | 17/35 | 前端封顶 |
+| **效果与数据** | 21/25 | 4/25 | 测试无法运行 |
+
+**核心差异**：零号是"能跑起来的完整作品"，逸飞冲天是"写了大量代码但关键链路（测试、Web）跑不起来"。
+
+---
+
+## 4. 评分合理性说明
+
+新评审规则下，逸飞冲天 126 分是**合理**的：
+
+- **静态维度给分**（架构 11、Agent核心 22、规模 23）：认可其**工作量和设计投入**
+- **运行验证维度封顶**（实现完整度 17、效果数据 4）：反映其**关键交付物无法真实运行**
+
+这正是"代码量大 ≠ 完成度高"的区分——**工作量值得认可，但未达到可交付标准**。
+
+---
+
+## 5. 建议修复方向（供参赛队伍参考）
+
+1. **修正测试导入**：将 `tests/` 下的扁平导入（`from preprocessor import`、`from orchestrator import`）改为正确的包路径（如 `from cobol_testgen.read import ...`），或在 pytest 配置 `pythonpath` 指向正确模块
+2. **修正 web 导入**：`orchestrator.py` 的 `check_coverage` 改为实际存在的函数名（`mark_coverage` 或实现该函数）
+3. **完善包结构**：在 `pyproject.toml` 增加 `[tool.setuptools]` packages 配置，或改用 src/ 布局，确保 `pip install -e .` 后可导入
+4. **修复后重评**：修正上述问题后，测试应能运行、Web 应能启动，运行验证维度分数将恢复正常
+
+---
+
+*本文档基于 2026-08-31 评审与实测生成，证据可复现（clone 最新仓库后执行 pytest / uvicorn 可验证）。*