如何让claude生产出清晰的Xmind思维导图？
思维导图 / Xmind 生成提示词
1. 模式目标
当用户要求进入“思维导图模式 / Xmind 模式 / Markdown 思维导图模式”时，AI 的目标不是写面试问答稿，也不是简单总结已经看过的代码，更不是机械罗列包、类、接口、DTO、Entity、方法名。
该模式的目标是：
在阅读当前项目代码的过程中，主动把当前分析对象拆成一棵可以继续展开的代码理解树，并输出为适合导入 Xmind 的层级 Markdown 大纲。
最终产物应帮助用户做到：
- 看懂当前模块整体负责什么；
- 看出当前模块可以拆成哪些子模块；
- 看出每个子模块还能继续往哪些方向深入；
- 知道每个节点背后对应哪些代码事实；
- 知道下一步应该沿着哪些包、类、方法、流程继续追代码；
- 能为后续学习、复习、项目讲述、面试表达服务。
核心原则是：
分析视角偏 Java 后端面试准备，展示形式偏教学型学习资料。 输出结果不是横向总结，而是一棵可以继续拆解的代码理解树。
2. 核心工作方式
AI 在该模式下不能只读完代码后做一次静态总结，而应采用：
边读代码，边拆模块，边构建树。
阅读代码时，需要持续判断：
- 当前代码属于哪个业务能力节点；
- 当前类支撑哪个子模块；
- 当前方法支撑哪个流程环节；
- 当前配置支撑哪个技术机制；
- 当前逻辑是否值得提升为可继续拆解的节点；
- 当前细节是否只是普通实现，不值得进入主结构；
- 当前节点后续还能继续追哪些代码。
不要把“读代码”和“输出大纲”割裂开。
思维导图结构应随着代码阅读逐步生长，而不是最后把代码结果简单归纳成几个栏目。
3. 拆分原则
思维导图的拆法应遵循：
先模块，后能力； 先流程，后代码； 先主干，后细节； 先可拆结构，后代码支撑。
推荐拆分路径：
- 当前模块 / 当前主题；
- 模块定位；
- 可拆分子模块；
- 子模块职责；
- 子模块内部流程；
- 子模块关键技术点；
- 子模块代码支撑；
- 子模块后续可继续深入方向。
最终结构应尽量形成：
当前模块 / 当前主题
模块定位
可拆分子模块
子模块一
负责什么
内部流程
关键技术点
代码支撑
后续可继续追代码
子模块二
负责什么
内部流程
关键技术点
代码支撑
后续可继续追代码
模块主流程
整体技术重点
后续深入路线
4. 子模块拆分要求
“可拆分子模块”是该模式的核心。
AI 必须优先识别当前分析对象可以拆成哪些子模块，而不是直接写“核心能力、核心流程、关键技术点、代码支撑”这种横向栏目。
每个子模块都应尽量回答：
- 它负责什么；
- 它解决什么问题；
- 它在当前模块中处于什么位置；
- 它和其他子模块如何协作；
- 它背后有哪些关键流程；
- 它涉及哪些后端技术点；
- 它对应哪些关键包、类、方法、配置、表结构；
- 它后续还可以继续往哪里追代码。
也就是说，每个子模块都应该是一个可以继续展开的小树。
5. 代码支撑的使用方式
类名、方法名、DTO、Entity、配置类、表结构可以出现，但它们不能成为主结构。
错误倾向：
- UploadController
- UploadSessionService
- ChunkMergeService
- LocalChunkStore
- UploadProgressCache
这种结构更像类清单，不像思维导图。
更推荐：
- 上传入口
- UploadController
- 会话管理
- UploadSessionService
- UploadSessionRepository
- 分片存储
- LocalChunkStore
- 合并发布
- ChunkMergeService
- UploadPublisher
- 进度缓存
- UploadProgressCache
- 状态约束
- UploadSessionStateMachine
也就是说：
先有业务能力节点，再挂代码支撑。 先有模块理解，再出现类名方法名。 类名和方法名是证据，不是主干。
6. 拆分粒度判断
AI 应主动判断哪些内容值得提升为节点。
值得提升为节点的内容包括：
- 核心业务流程；
- 模块边界；
- 关键能力；
- 权限控制；
- 参数校验；
- 事务处理；
- 状态机；
- 缓存设计；
- 异步消息；
- 幂等控制；
- 文件处理；
- 数据一致性；
- 异常处理；
- 性能优化；
- 工程结构设计；
- 适合后续追代码的入口；
- 适合面试表达的实现设计。
不值得提升为主节点的内容包括：
- 普通 getter / setter；
- 普通字段；
- 纯 DTO 字段罗列；
- 没有特殊设计的 CRUD；
- 和当前模块主线无关的工具方法；
- 只有代码存在但没有理解价值的细节；
- 为了完整而强行展开的类和方法。
普通 CRUD 只有在体现权限、校验、事务、对象转换、缓存、性能、工程设计或面试表达价值时，才值得展开。
7. 输出组织方式
最终输出应以树状 Markdown 为主，不要写成解释性文章。
推荐结构：
当前模块 / 当前主题
模块定位
- 负责什么
- 解决什么问题
- 在项目中的位置
- 与其他模块的关系
可拆分子模块
子模块一
- 负责什么
- 解决什么问题
- 关键流程
- 关键技术点
- 代码支撑
- 后续可继续追代码
子模块二
- 负责什么
- 解决什么问题
- 关键流程
- 关键技术点
- 代码支撑
- 后续可继续追代码
子模块三
- 负责什么
- 解决什么问题
- 关键流程
- 关键技术点
- 代码支撑
- 后续可继续追代码
模块主流程
- 请求从哪里进入
- 经过哪些子模块
- 访问哪些数据或中间件
- 如何完成状态变化
- 最终返回什么结果
- 是否触发异步流程
关键技术点
- 技术点一
- 服务于哪个子模块
- 在当前代码中起什么作用
- 对应哪些代码支撑
- 技术点二
- 服务于哪个子模块
- 在当前代码中起什么作用
- 对应哪些代码支撑
后续深入路线
- 可以继续追的子模块
- 可以继续看的核心流程
- 可以继续分析的关键类
- 可以继续整理成面试表达的点
- 可以继续验证的工程设计问题
8. 输出风格要求
输出应适合直接复制到 Xmind 中形成清晰层级。
节点表达应满足：
- 短句化；
- 概念化；
- 层级清楚；
- 父节点能概括子节点；
- 子节点能继续向下拆；
- 同级节点表达风格一致；
- 不同模块边界清晰；
- 技术点服务于项目理解；
- 代码支撑服务于节点可信度；
- 不写大段解释性文章。
输出风格应像老师帮学生拆代码，而不是 AI 做项目总结。
9. 禁止事项
在思维导图 / Xmind 模式下，禁止以下行为：
- 禁止使用 mermaid；
- 禁止使用表格；
- 禁止使用调用链图；
- 禁止使用代码块；
- 禁止画流程图；
- 禁止写成面试问答稿；
- 禁止输出大段解释性文章；
- 禁止逐行翻译代码；
- 禁止机械罗列包、类、接口、DTO、Entity、方法名；
- 禁止把每个类、每个方法都展开成节点；
- 禁止直接用类名作为主干结构；
- 禁止堆砌和当前模块无关的技术名词；
- 禁止添加当前代码中不存在的功能；
- 禁止为了显得完整而扩展出项目没有实现的能力；
- 禁止把普通 CRUD 细节过度展开；
- 禁止只做横向总结；
- 禁止把思维导图做成代码清单；
- 禁止输出“综上所述”“本模块非常重要”等空泛总结。
10. 质量标准
最终输出应满足：
- 能直接复制到 Xmind 中形成清晰大树；
- 根节点、主干节点、子节点层级清楚；
- 用户能从根节点一路展开到子模块；
- 每个子模块都有继续深入的方向；
- 每个关键节点尽量有代码事实支撑；
- 代码支撑不抢占主结构；
- 技术点挂靠到具体能力或流程上；
- 内容来自当前项目代码事实；
- 不脑补项目没有实现的功能；
- 不把普通代码细节强行升级为节点；
- 输出结果能指导用户下一步追代码；
- 输出结果能服务后续学习、复习、面试表达。
11. 输出位置
最终输出位置为当前目录下：
./思维导图/
如果目录不存在，应先创建该目录。
文件名应根据当前分析对象命名，例如：
- 认证与权限.md
- 缓存模块.md
- 异常处理.md
- 分片上传.md
- 实验数据管理.md
- 数据接入流程.md
12. 一句话工作准则
在该模式下， 要做的不是：
把代码总结成一份漂亮大纲。
而是：
边读代码边把模块拆成一棵可以继续深入的大树，让用户能沿着每个节点继续追代码、理解模块、积累面试表达。