ttguy0707/codojo/dojo-plan

dojo-plan — S2 计划生成

一句话定位：根据能力评估结果，生成个性化学习计划和进度跟踪表。

何时使用

• ✅ S1 能力评估已完成，open-questions.md 已填答案
• ✅ 用户说"生成学习计划"、"制定计划"
• ❌ open-questions.md 不存在或未填答案 → 转 dojo-assess
• ❌ task.md 已存在且用户想开始学习 → 转 dojo-teach

前置条件

• <repo-root>/.codojo/open-questions.md 存在且末尾包含 <!-- ASSESS_DONE --> 标记

若前置条件不满足，提示用户并转到 dojo-assess。

工作流

Step 1：分析评估结果

读取 open-questions.md，提取：

• 用户已掌握的技术点（标记为"熟练掌握"）
• 用户部分掌握的技术点（"用过但不熟练"）
• 用户完全不了解的技术点（"完全不了解"/"听说过但没用过"）
• 用户的自由补充（学习目标、时间安排等）

Step 2：项目深度分析

在 Step 1 基础上，深入分析项目代码，梳理：

• 项目的模块划分和层次结构
• 模块间的依赖关系（先学什么后学什么）
• 每个模块涉及的核心概念和知识点
• 适合用来做实践练习的代码片段

Step 3：生成 task.md

根据 Step 1 + Step 2 生成 <repo-root>/.codojo/task.md：

强制规则：第一个知识点必须是「模块 0：项目全景」

无论用户水平高低，task.md 的第一个知识点固定为「0.1 项目全景」，让用户在钻进具体知识点之前先建立全局认知（先森林、后树木）。这是横向的整体视角，与后续逐个知识点的纵向深入互补。

「模块 0」是纯理论知识点（无实践任务），轻量讲解，1 个知识点讲完即可，内容聚焦三点：

• 分层结构：项目从根目录开始分了哪几层 / 哪几个模块
• 模块职责：每个模块/层各自负责什么
• 为什么这样分：这种分层/分包背后的设计意图（解耦、复用、职责单一等）

它由 S3 正常教学流程讲解，理论讲完用户确认理解即视为完成，不需要实践环节；用户学到一半想回看全局时，让 AI 重讲「0.1 项目全景」即可（S3 中断恢复机制本就支持跳回任意知识点）。

# 学习计划
 
> 根据你的能力评估自动生成，已掌握内容已跳过或简化。
 
## 学习概要
 
-**总知识点数**：N 个
-**预计学时**：约 X 小时
-**学习路径**：<简述先后顺序的逻辑>
 
## 模块 0：项目全景
 
### 0.1 项目全景：分层结构与模块关系
-**类型**：纯理论（无实践任务）
-**难度**：⭐
-**前置知识**：无
-**学习目标**：建立项目整体认知——知道项目分了哪几层/模块、各自职责、为什么这样分
-**理论要点**：从项目根目录出发，讲清分层结构、每个模块的职责、以及这种分层/分包的设计意图
-**涉及文件**：<项目根目录结构 + 各模块入口文件路径>
 
## 模块 1：<模块名>
 
### 1.1 <知识点名称>
-**类型**：理论 + 实践
-**难度**：⭐ / ⭐⭐ / ⭐⭐⭐
-**前置知识**：<依赖的知识点，如有>
-**学习目标**：<学完后能做什么>
-**理论要点**：<概述要讲什么>
-**实践任务**：<概述要做什么改动>
-**涉及文件**：<相关源文件路径>
 
### 1.2 <知识点名称>
...
 
## 模块 2：<模块名>
...

计划设计原则：

• 第一个知识点固定为「0.1 项目全景」，且无论用户水平高低都不可跳过、不可省略
• 已掌握的技术点标记为"跳过"或"快速回顾"（不占主要学时）
• 部分掌握的安排"巩固 + 补缺"
• 完全不了解的安排"完整讲解 + 充分实践"
• 知识点顺序遵循依赖关系（先基础后进阶）
• 每个知识点都要有理论和实践两部分
• 实践任务必须基于项目真实代码，而非虚构示例

Step 4：生成 schedule.md

生成 <repo-root>/.codojo/schedule.md：

# 学习进度
 
> 由 AI 自动维护，记录你的学习进度。
 
## 总进度
 
📊 ░░░░░░░░░░ 0% (0/N 知识点)
 
## 详细进度
 
| # | 知识点 | 状态 | 理论 | 实践 | 完成时间 |
|---|---|---|---|---|---|
| 0.1 | 项目全景：分层结构与模块关系 | ⚪ 未开始 | ⚪ | — | - |
| 1.1 | <名称> | ⚪ 未开始 | ⚪ | ⚪ | - |
| 1.2 | <名称> | ⚪ 未开始 | ⚪ | ⚪ | - |
| 2.1 | <名称> | ⚪ 未开始 | ⚪ | ⚪ | - |
| ... | ... | ... | ... | ... | ... |
 
**注意**：
-`0.1 项目全景` 必须作为第一行，且 N（总知识点数）需把它计入。
-`0.1` 是纯理论知识点，无实践环节，其「实践」列固定填 `—`（破折号，表示不适用）。S3 教学时该知识点理论讲完、用户确认理解即标记为 ✅ 已完成，不进入实践环节。
 
## 学习日志
 
<!-- AI 在每次教学后追加记录 -->

Step 5：输出并确认

向用户展示学习计划概要（不需要全文，摘要即可），输出完成自检：

## 📋 S2 计划生成 完成
 
**产出物** ✅
-`.codojo/task.md`（学习计划，共 N 个知识点）
-`.codojo/schedule.md`（进度跟踪表）
 
**计划概要**
-模块 0：项目全景（1 个知识点，建立全局认知）
-模块 1：<名称>（X 个知识点）
-模块 2：<名称>（X 个知识点）
-...
-已跳过：<已掌握的技术点>
-预计学时：约 X 小时
 
**下一步** → S3 正式教学
是否进入 S3 开始学习？

Gotchas

• 知识点数量容易失控——控制在 15-30 个之间，超过 30 个用户大概率半途放弃
• 实践任务不要脱离项目真实代码——禁止虚构示例文件或伪代码
• 学时估计要保守——宁可估长，不要估短，避免用户产生挫败感
• 模块依赖顺序要正确——如果 B 依赖 A 的概念但排在 A 前面，用户会完全听不懂
• 不要为"已掌握"的技术点生成大量内容——标记为"跳过"或"快速回顾（5 分钟）"即可
• schedule.md 的知识点编号必须与 task.md 一一对应——编号不一致会导致 S3 进度跟踪错乱
• 模块 0「项目全景」容易被漏掉或做重——它必须存在且只占 1 个知识点（轻量讲分层/职责/为什么这样分），不要展开成多个细分知识点，也不要因用户水平高就省略

不该做的事

• 🚫 生成超过 30 个知识点的学习计划（用户会放弃）
• 🚫 为已掌握的技术点安排完整的理论+实践（浪费时间）
• 🚫 实践任务引用不存在的文件或虚构的代码
• 🚫 在计划中包含与项目无关的通用知识（如"什么是变量"——除非评估结果显示用户确实需要）
• 🚫 生成 task.md 后不生成 schedule.md（S3 依赖两个文件同时存在）
• 🚫 在展示计划概要时输出 task.md 全文（摘要即可，全文用户自己打开看）
• 🚫 省略「0.1 项目全景」或把它排在其他知识点之后（必须是第一个知识点）
• 🚫 把「模块 0」拆成多个知识点或讲成大篇幅（保持轻量，1 个知识点）

产出

输出风格约束

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