ttguy0707/codojo/dojo-hack

dojo-hack — S4 魔改阶段

一句话定位：推荐魔改方向，制定计划，动手改造项目，直到用户满意。

何时使用

• ✅ S3 教学 100% 完成，用户选择进入 S4
• ✅ 用户说"我想魔改"、"给项目加功能"、"改造一下"
• ❌ S3 未完成 → 提示先完成 S3，转 dojo-teach
• ❌ 用户只是想学习不想改代码 → 不强制进入

前置条件

• <repo-root>/.codojo/schedule.md 存在且显示 100% 完成

若前置条件不满足，提示用户先完成 S3 教学。

工作流

Step 1：项目深度分析与推荐

全面分析项目代码，从以下维度推荐魔改方向：

• 功能扩展：基于项目已有能力，可以新增哪些实用功能
• 代码重构：哪些地方可以优化结构、提升可读性
• 性能优化：有没有明显的性能瓶颈可以改进
• 测试完善：缺少哪些测试覆盖
• 工程化改进：CI/CD、日志、监控、文档等

输出推荐列表：

## 🎯 魔改方向推荐
 
根据项目分析，为你推荐以下魔改方向（可多选，也可以自己提需求）：
 
### 功能扩展类
1.**<功能名>**：<一句话描述 + 预估工作量>
2.**<功能名>**：<一句话描述 + 预估工作量>
 
### 代码优化类
3.**<优化点>**：<一句话描述 + 预估工作量>
4.**<优化点>**：<一句话描述 + 预估工作量>
 
### 工程化改进类
5.**<改进点>**：<一句话描述 + 预估工作量>
 
---
请回复你想做的编号（如「1 3 5」），或者直接告诉我你想做什么改动。
回复「不了」可以跳过 S4，结束整个学习流程。

推荐原则：

• 推荐 5-8 个方向，不要太多造成选择困难
• 每个方向要有具体可落地的改动点，不要空泛
• 按难度从低到高排列
• 预估工作量帮助用户做选择

Step 2：制定 plan.md

根据用户选择（可多选 + 自定义），生成 <repo-root>/.codojo/plan.md：

# 魔改计划
 
> 根据你的选择生成，AI 将按此计划协助你改造项目。
 
## 概要
 
-**选定方向**：<列出>
-**预计总工作量**：约 X 小时
-**当前状态**：进行中
 
## 任务清单
 
### 任务 1：<任务名>
-**目标**：<达成什么效果>
-**涉及文件**：<文件路径列表>
-**实施步骤**：
  1.<具体步骤>
  2.<具体步骤>
  3.<具体步骤>
-**验证方式**：<如何确认改动生效>
-**状态**：⚪ 未开始
 
### 任务 2：<任务名>
...
 
## 变更日志
 
<!-- 每次有新需求或计划变更时追加记录 -->

生成后向用户确认：

plan.md 已生成，共 N 个任务。先从「任务 1：<名称>」开始？

Step 3：执行改造

按 plan.md 任务顺序，逐个协助用户完成改造。

代码改动确认协议：

每个任务开始前，AI 必须先向用户展示改动方案并等待确认：

## 🔧 任务 N：<任务名>
 
**改动方案**：
1.修改 `<文件路径>` — <改动说明>
2.新增 `<文件路径>` — <说明>
3....
 
**影响范围**：<哪些现有功能可能受影响>
**验证方式**：<如何确认改动生效>
 
确认开始？回复「开始」执行，或提出修改意见。

用户回复"开始"、"可以"、"执行"后，才能动手修改代码。

执行流程：

1. 讲解思路：这个改动要做什么、为什么这样做、会影响哪些文件
2. 协作实施：AI 生成代码改动，解释每处修改的含义，引导用户理解
3. 验证结果：指导用户验证改动效果（编译、运行、测试等）
4. 更新 plan.md：将任务状态更新为 ✅，记录完成时间

每完成一个任务：

---
✅ 任务 1「<名称>」已完成！
 
📋 **魔改进度**: 1/N 任务完成
⏭️ 下一个：任务 2「<名称>」
 
继续？或者有新想法随时告诉我。
---

Step 4：持续迭代

S4 阶段不设终点，持续接受用户新需求：

• 用户新增需求 → 追加到 plan.md 任务清单，在变更日志中记录
• 用户修改需求 → 更新 plan.md 对应任务，在变更日志中记录
• 用户取消某个任务 → 标记为 ❌ 已取消，在变更日志中记录
• 用户说"满意了"/"结束" → 输出完成总结

Step 5：完成总结（用户主动结束时）

## 📋 S4 魔改阶段 完成
 
**成果总结** ✅
-完成任务：X 个
-取消任务：X 个
-涉及文件：X 个
 
**改动清单**：
-✅ 任务 1：<名称> — <一句话成果>
-✅ 任务 2：<名称> — <一句话成果>
-...
 
🎉 整个学习+魔改流程圆满结束！这个项目现在是你的了。

产出

Gotchas

• 魔改最容易翻车的点是破坏原有功能——每个任务完成后必须引导用户做回归验证（至少编译通过）
• 一次改动太多文件会让用户跟不上——即使一个任务涉及多个文件，也要逐个文件讲解和修改，不要一次性全改完
• plan.md 与实际改动容易脱节——每次代码改动后必须同步更新 plan.md 的任务状态和变更日志
• 用户新增需求时容易忘记更新 plan.md——任何新需求、取消、变更都必须先写入 plan.md 再执行
• 推荐魔改方向时不要推荐超出用户当前能力的方向——参考 open-questions.md 的评估结果判断用户水平
• 不要把"用户说可以"误判为"用户说开始"——确认协议要求用户明确回复"开始"、"可以"、"执行"才能动手改代码

不该做的事

• 🚫 在 S3 未完成时直接进入 S4
• 🚫 不经用户确认就修改项目代码（必须遵循代码改动确认协议）
• 🚫 忘记更新 plan.md 的任务状态和变更日志
• 🚫 一次做太大的改动（每次聚焦一个任务，逐文件讲解）
• 🚫 用户提出新需求时不更新 plan.md
• 🚫 改完代码不引导用户做回归验证

输出风格约束

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