证据链联动方案
目标：打通工程笔记本评分 ↔ 面试评分 ↔ 实物验证，形成完整的自证体系 工具：笔记本评分工具（已有）+ 面试评分工具（scorer.html）+ 本指南
核心逻辑：三角验证
笔记本说了什么
↕
学生口述 ←→ 机器人实物
三者必须一致。任何两者对不上 = 红旗。
| 对比 | 一致 = 安全 | 不一致 = 红旗 |
|---|---|---|
| 笔记本 vs 口述 | 学生说的和笔记本记录吻合 | 学生说的细节和笔记本对不上 |
| 笔记本 vs 实物 | 笔记本最新版设计图和机器人一致 | 笔记本画的和机器人长得不一样 |
| 口述 vs 实物 | 学生指着机器人解释，对得上 | 学生描述的和实际机构不符 |
笔记本评分 × 面试评分 交叉矩阵
用笔记本评分工具的各维度分数 + 面试评分工具的各维度分数做交叉验证
| 面试高分（≥4） | 面试中等（3） | 面试低分（≤2） | |
|---|---|---|---|
| 笔记本高分（≥4） | ✅ 安全 — 能写能说 | ⚠ 可能紧张 — 练习口述 | 🔴 高危 — 笔记本可能是别人写的 |
| 笔记本中等（3） | ⚠ 记录不足 — 补笔记本 | 🟡 两边都要提升 | 🔴 能力存疑 |
| 笔记本低分（≤2） | 🟡 会做不会记 — 补记录 | 🔴 两边都弱 | 🔴🔴 极高危 — 可能都不是学生做的 |
最危险的组合
笔记本高 + 面试低 = 评审会怀疑笔记本是大人写的、学生没有真正参与
这个组合比"两个都低"更危险，因为它暗示造假。
逐维度交叉验证清单
1. 设计维度
| 检查项 | 笔记本应该有 | 面试应该能说 | 机器人应该能看到 |
|---|---|---|---|
| 设计草图 | 手绘草图+标注 | "我画了这个草图，想法是..." | 实物和草图基本一致 |
| 方案对比 | 决策矩阵或优缺点表 | "我们比较了 A 和 B，选了 A 因为..." | 机器人用的确实是方案 A |
| 尺寸参数 | 标注了关键尺寸 | "这个间距是 XX，因为..." | 量一下确实是那个尺寸 |
不一致红旗：
- 笔记本有精美 CAD 图但学生画不出简单草图 → 图可能不是学生画的
- 笔记本写了"方案 B"但机器人是方案 A → 笔记本可能是编的
- 学生说的尺寸和笔记本/实物对不上 → 不了解自己的设计
2. 迭代维度
| 检查项 | 笔记本应该有 | 面试应该能说 | 机器人应该能看到 |
|---|---|---|---|
| 版本历史 | 不同版本的照片+日期 | "第一版有问题因为 X，改成了 Y" | 可能有旧零件/改动痕迹 |
| 测试数据 | 数据表格/图表 | "测了 X 次，成功率从 A 到 B" | 可以现场测一次验证 |
| 失败记录 | 记录了什么不行 | "这个方案失败了因为..." | — |
不一致红旗：
- 笔记本有 5 个版本但学生只说得出当前版本 → 迭代可能是补写的
- 笔记本数据太完美（100% 成功率） → 数据可能是编的
- 学生说"改了很多次"但笔记本只有一个版本 → 改动没记录
3. 代码维度
| 检查项 | 笔记本应该有 | 面试应该能说 | 代码应该能看到 |
|---|---|---|---|
| 代码架构 | 流程图或伪代码 | "代码分 X 个部分，分别做..." | 实际代码结构和描述一致 |
| 算法说明 | PID 原理+参数记录 | "P 是 XX 因为..." | 代码中的参数和口述一致 |
| 调试记录 | bug 记录+解决过程 | "遇到 X 问题，用 Y 方法解决" | 代码中能看到修复痕迹 |
不一致红旗：
- 笔记本有完整代码文档但学生解释不了 → 文档可能是别人写的
- 学生说参数是 X 但代码里是 Y → 不了解当前代码
- 笔记本没有任何代码记录 → 缺少编程过程的证据
4. 团队维度
| 检查项 | 笔记本应该有 | 面试应该能说 | 可验证 |
|---|---|---|---|
| 分工记录 | 团队成员+角色 | "我负责 X，XX 负责 Y" | 分开问队员，描述一致 |
| 会议记录 | 讨论内容+日期 | "我们每周讨论一次" | 队员回忆一致 |
| 个人贡献 | 每人做了什么 | 每人能说自己的具体成果 | 其他人能印证 |
不一致红旗：
- 笔记本分工写的和面试说的不一样 → 分工可能是编的
- 所有队员描述一模一样 → 背过稿
实操：怎么用这个方案
第一步：笔记本评分（用你现有的笔记本评分工具）
得到各维度分数：问题识别、头脑风暴、方案选择、建造与编、测试验证、设计迭代、创新原创、完整性、团队管理、笔记本格式
第二步：面试评分（用 scorer.html）
得到各维度分数：代码与编程、设计与机械、过程与迭代、团队与角色、G4d
第三步：交叉比对
填写以下表格，找出不一致的地方：
| 维度 | 笔记本分 | 面试分 | 差值 | 风险判定 |
|---|---|---|---|---|
| 设计 | /5 | /5 (B区) | ||
| 迭代 | /5 | /5 (C区) | ||
| 编程 | /5 | /5 (A区) | ||
| 团队 | /5 | /5 (D区) |
差值解读：
- 差值 ≤1：正常范围
- 笔记本 > 面试 + 2：🔴 笔记本可能造假，重点验证
- 面试 > 笔记本 + 2：🟡 笔记本记录不足，需要补充
第四步：针对红旗项做专项验证
对每个"笔记本高+面试低"的维度：
- 让学生打开笔记本对应页面
- 不看笔记本，用自己的话复述内容
- 问细节问题（日期、数据、具体步骤）
- 如果复述不出来 → 确认笔记本该部分有问题
第五步：出改进清单
针对每个问题输出：
- 问题描述（哪里不一致）
- 严重度（🔴/🟡/🟢）
- 补救措施（具体做什么）
- 截止日期
- 负责人（哪个学生）
多轮迭代流程
第一轮（普测）
├── 笔记本评分 → 各维度分数
├── 面试评分 → 各维度分数
├── 交叉比对 → 找出红旗
└── 输出：问题清单 + 改进任务
学生按清单改进（1-2 周）
├── 补笔记本记录
├── 重新理解自己不清楚的部分
├── 练习口述
└── 补做缺失的证据（测试数据等）
第二轮（复测）
├── 重新面试（针对上轮红旗项）
├── 重新交叉比对
└── 输出：更新后的状态
继续改进...
第三轮（最终确认）
└── 全面测试 → 判定是否可以上场
关键原则：每轮改进本身也是证据 — 学生说"我第一轮答不好，后来重新学了 XX，现在我理解了" 这本身就证明了学习过程（G2 合规）。
给学生的话
面试不是考试。评审不是要为难你，是想了解你。
如果你真的做了这个机器人，你只需要学会用语言描述你已经做过的事。
如果你某个部分确实不了解，现在花时间去学——这个学习过程本身就是 G2 和 G4 要求的。
最糟糕的不是"不会"，而是"假装会"。评审见过几百支队伍，他们能看出来。