ttguy0707/codojo/dojo-quiz

dojo-quiz — 知识检测

一句话定位：模块学完后用 3-5 道实战题验证用户是否真正理解，答错即时纠正，支持跳过。

何时使用

• ✅ S3 教学中某个模块所有知识点完成后（由 dojo-teach 自动触发）
• ✅ 用户主动说"考考我"、"测试一下"、"我学会了吗"
• ❌ 尚未完成任何知识点 → 提示"还没开始学习，先完成一些知识点再来测验"
• ❌ 用户正在 S1/S2 阶段 → 提示"评估/规划阶段不需要测验，S3 教学开始后会自动安排"

前置条件

• <repo-root>/.codojo/schedule.md 存在且至少有一个知识点状态为 ✅

跳过机制

用户有权跳过任何测验，不做任何惩罚或负面提示。

以下回复视为跳过（不区分大小写）：

用户跳过时，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 立即点评：

• 答对：简短肯定 + 出下一题

``markdown ✅ 正确！<一句话补充关键点> ``

• 部分正确：肯定对的部分 + 补充遗漏

``markdown ⚠️ 方向对了！<肯定的部分>。补充一点：<遗漏的关键点> ``

• 答错：不批评，给出简短要点提示（2-3 句话），不展开完整讲解

``markdown ❌ 不太对。关键点是：<简短解释核心概念，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 重学
• 🚫 用户跳过时劝导或暗示"你应该做测验"
• 🚫 给答错的用户负面评价（"你没学好"/"基础不扎实"）
• 🚫 测验结果打分后做"及格/不及格"判定（没有通过门槛，纯检测）

产出

输出风格约束

详见共用 reference：`../_shared/output-style-guide.md`

要点：题目用 📝 标记；答对 ✅、部分正确 ⚠️、答错 ❌；跳过 ⏭️。