| name | dojo-quiz |
| category | process |
| stage | cross-stage |
| version | 0.1.0 |
| description | Codojo 知识检测 skill：每个模块学完后自动触发的小测验，验证用户真正理解了所学内容。
由 dojo-teach 在每个模块（非每个知识点）完成后自动调用，也可由用户手动触发。
用户有权跳过任何测验——回复"跳过"、"不用了"即可继续下一模块，不强制。
两种触发模式：
- auto : S3 教学中每完成一个模块自动触发（由 dojo-teach 调用）
- manual : 用户主动说"考考我"、"测试一下"
触发关键词：考考我、测测我、quiz、测验、检测一下、test me、
我学会了吗、验证一下。
跳过关键词：跳过、跳过测验、不用了、skip、算了、直接继续。
前置条件：至少有一个模块的知识点已完成（schedule.md 中有 ✅ 记录）。
后置产出：无独立文件，测验结果追加到 schedule.md 的学习日志中。
注意：本 skill **只做知识检测**，不做教学（答错时只给简短要点提示，
不展开完整讲解——完整讲解归 dojo-teach）。
|
dojo-quiz — 知识检测
一句话定位：模块学完后用 3-5 道实战题验证用户是否真正理解，答错即时纠正，支持跳过。
何时使用
- ✅ S3 教学中某个模块所有知识点完成后（由 dojo-teach 自动触发）
- ✅ 用户主动说"考考我"、"测试一下"、"我学会了吗"
- ❌ 尚未完成任何知识点 → 提示"还没开始学习，先完成一些知识点再来测验"
- ❌ 用户正在 S1/S2 阶段 → 提示"评估/规划阶段不需要测验，S3 教学开始后会自动安排"
前置条件
<repo-root>/.codojo/schedule.md 存在且至少有一个知识点状态为 ✅
跳过机制
用户有权跳过任何测验，不做任何惩罚或负面提示。
以下回复视为跳过（不区分大小写）：
| 跳过确认词 | 语义 |
|---|
| "跳过"、"跳过测验" | 明确跳过 |
| "不用了"、"算了"、"不测了" | 婉拒 |
| "skip"、"pass" | 英文跳过 |
| "直接继续"、"下一个模块" | 跳过并继续 |
用户跳过时，AI 的回复应简短友好：
好的，跳过本模块测验。继续下一个模块——
然后无缝回到 dojo-teach 流程。不要说"建议你做一下测验"之类的劝导，用户说跳过就跳过。
跳过的测验在 schedule.md 学习日志中记录为：
- [2026-06-05 16:30] ⏭️ 模块 1 测验 - 用户选择跳过
工作流
Step 1：确定测验范围
确定要测验的模块：
- 自动触发时：测验刚完成的模块
- 手动触发时：读取 schedule.md，找到最近完成的模块（所有知识点为 ✅ 且尚未做过测验的模块）
如果用户手动触发但所有已完成模块都测过了，提示：
你已完成的模块都测验过了！继续学习新知识点，完成下一个模块后会自动安排测验。
Step 2：出题
根据该模块包含的知识点和涉及的项目代码，生成 3-5 道题目。
出题原则：
- 题目必须基于项目真实代码，不出脱离项目的通用理论题
- 题型多样化：代码理解题、改动预判题、Bug 定位题、概念关联题
- 难度递进：第 1 题容易（确认基础理解），后面逐步加深
- 每题简短明确，给出足够上下文（代码片段 + 文件路径）
题型示例：
**题型 A — 代码理解**
看这段代码（`src/service/OrderService.java` 第 42-55 行）：
<代码片段>
问：这段代码的核心职责是什么？当 `status == null` 时会发生什么？
**题型 B — 改动预判**
如果把 `application.yml` 中的 `server.port` 从 8080 改成 9090，
除了端口变化外，还有哪些地方会受影响？
**题型 C — Bug 定位**
用户反馈"下单后库存没有减少"，基于你对模块 2 的理解，
你会从哪个类的哪个方法开始排查？为什么？
**题型 D — 概念关联**
在本项目中，Controller 层和 Service 层的职责边界是什么？
举一个本项目中违反了这个边界的例子（如果有的话）。
Step 3：逐题交互
一次只出一道题，等用户回答后再出下一道。
出题格式：
---
📝 **模块 N 测验** (1/4)
<题目内容，含代码片段和文件路径>
---
💬 说出你的答案，或回复「跳过」跳过整个测验。
Step 4：即时点评
用户回答后，AI 立即点评：
-
答对：简短肯定 + 出下一题
✅ 正确！<一句话补充关键点>
-
部分正确：肯定对的部分 + 补充遗漏
⚠️ 方向对了！<肯定的部分>。补充一点：<遗漏的关键点>
-
答错：不批评，给出简短要点提示（2-3 句话），不展开完整讲解
❌ 不太对。关键点是：<简短解释核心概念，2-3 句话>
💡 可以回看 `task.md` 中的知识点 N.M 复习一下。
注意：答错时不要强制用户回到 S3 重学——只给提示和回看建议，用户自行决定是否复习。测验的目的是帮助用户发现盲区，不是设置关卡。
Step 5：测验总结
所有题目回答完毕后（或用户中途跳过时），输出简短总结：
---
📝 **模块 N 测验完成**
| 题号 | 结果 |
|---|---|
| 1 | ✅ 正确 |
| 2 | ✅ 正确 |
| 3 | ⚠️ 部分正确 |
| 4 | ❌ 需复习 |
**得分**：2.5/4
**薄弱点**：<具体指出哪个知识点需要加强，如"Spring IoC 的 Bean 生命周期">
---
然后更新 schedule.md 学习日志，追加一条记录：
- [2026-06-05 16:30] 📝 模块 1 测验 - 2.5/4（薄弱点：Bean 生命周期）
Step 6：回到教学流程
测验结束后，无缝回到 dojo-teach：
继续下一个模块——
然后直接进入下一个模块的第一个知识点的理论环节，不需要用户额外操作。
Gotchas
- 不要每个知识点都出测验——只在模块级别触发（一个模块通常包含 3-8 个知识点），避免测验过于频繁让用户烦躁
- 不要出脱离项目的通用题——"什么是多态"这种题没意义，必须结合项目代码出题
- 不要一次把所有题抛出来——必须逐题交互，否则用户会被题量吓到
- 答错时不要长篇大论讲解——2-3 句话点到为止，完整讲解归 dojo-teach
- 答错时不要强制用户回去重学——给建议即可，尊重用户的选择
- 用户说跳过时不要劝导——说跳就跳，不带任何"建议你做一下"的话术
- 手动触发时要判断是否有"未测验过的已完成模块"——避免重复测验同一个模块
- 题目引用的代码片段必须当场读取确认存在——不要凭记忆引用可能已变动的代码
不该做的事
- 🚫 每个知识点都触发测验（只在模块完成后触发）
- 🚫 出超过 5 道题（3-5 道即可，多了用户疲劳）
- 🚫 出纯理论题（"解释什么是 AOP"）而不结合项目代码
- 🚫 答错后展开完整教学讲解（那是 dojo-teach 的职责）
- 🚫 答错后强制用户回到 S3 重学
- 🚫 用户跳过时劝导或暗示"你应该做测验"
- 🚫 给答错的用户负面评价（"你没学好"/"基础不扎实"）
- 🚫 测验结果打分后做"及格/不及格"判定（没有通过门槛，纯检测）
产出
| 文件 | 路径 | 说明 |
|---|
| 无独立文件 | — | 测验结果追加到 schedule.md 学习日志中 |
输出风格约束
详见共用 reference：../_shared/output-style-guide.md
要点：题目用 📝 标记；答对 ✅、部分正确 ⚠️、答错 ❌；跳过 ⏭️。
