项目蓝图闭环整理
用途
使用本 Skill 将内容较完整、但写法偏逻辑思考或论文说明的中文 Word 项目资料，整理成适合后续软件开发使用的项目蓝图。整理时要保留原始文档和新开发视角之间的关系，不要直接修改原 Word 文档结构。
默认受众是用户自己，用于项目开发前的内部理解、判断和决策。
工作原则
- 默认使用中文输出，除非用户明确要求其他语言。
- 将 Word 文档视为主要事实来源。
- 重新建立一套面向开发理解的目录，不在原文目录基础上直接改写。
- 默认使用粗颗粒功能模块，先建立项目蓝图。除非用户要求，不拆到按钮、字段、接口或代码级别。
- 输出的多个文档必须彼此关联，避免生成无法互相追溯的孤立文档。
- 保持轻量原文追溯：主要引用文档名，不大量摘录原文。原文没有清晰标题或位置时，标注
来源位置不明确。 - 对不清楚、互相矛盾、无法直接开发，或只是隐含提到的内容，标为
待确认问题，并给出推荐处理方案。 - 如果某个功能只是隐含出现，原文没有明确把它作为需求提出，不要直接放进确认功能模块。
- 如果多个 Word 文档重复描述同一功能，合并为一个模块，同时列出差异和推荐版本。
- 只有当原文资料明确支持端口区分时，才按用户端、管理端、App 端、小程序端、网站端或后台分类；不要强行分端。
必须遵循的流程
分阶段工作。每个阶段结束后，给出简短阶段摘要，并等待用户确认后再继续下一阶段。
-
资料接收与索引阶段
- 如果用户提供的是.docx文件夹，先运行scripts/docx_inventory.py生成资料索引草稿。
- 识别文档名称、大致主题、可见结构和资料覆盖范围。
- 记录缺失或无法读取的文件。
- 输出简短资料索引摘要。 -
原文逻辑地图阶段
- 建立一套独立于原 Word 目录的“项目理解目录”。
- 提取项目目标、用户角色、核心概念、业务规则、核心场景和功能线索。
- 为重要逻辑点保留来源文档名。 -
功能模块拆解阶段
- 将原文明确支持的项目逻辑转换为粗颗粒软件功能模块。
- 为每个模块标注主依据，必要时补充辅助依据，依据以文档名为主。
- 合并重复或重叠模块，并列出差异。
- 将隐含、不清楚或缺少依据的功能放入待确认问题，不作为已确认模块。 -
闭环检查阶段
- 检查模块是否能回到项目目标，并能与其他模块形成连续关系。
- 检查用户流程、模块关系、数据流、状态流、权限逻辑、异常处理和开发交付是否断裂。
- 按高、中、低标注断裂点严重程度。 -
待确认问题与推荐方案阶段
- 集中整理不清楚、矛盾、缺失或无法直接开发的问题。
- 每个问题都要包含涉及模块或逻辑区域、来源文档、严重程度、为什么影响开发或理解，以及推荐处理方案。 -
开发交付蓝图阶段
- 生成方便后续开发使用的文档组索引。
- 包含开发优先级分类：第一阶段必须开发、第二阶段可延后、暂不开发但保留、需要确认后再决定。
- 总结进入正式 PRD、UI、数据库或工程开发前仍需决策的事项。
默认输出文档组
除非用户要求其他结构，否则默认生成以下文档组：
- 《项目总览与原文逻辑地图》
- 《功能模块拆解文档》
- 《用户流程与业务闭环文档》
- 《页面/端口/入口整理文档》
- 《数据与状态流转文档》
- 《待确认问题与推荐方案清单》
- 《开发交付索引》
撰写文档组时读取 references/output-templates.md。
检查逻辑断裂时读取 references/closure-checklist.md。
标注原文依据时读取 references/source-traceability.md。
判断每个阶段如何追问用户时读取 references/questioning-guide.md。
Word 资料索引脚本
面对大量 Word 资料时，在语义分析前优先使用 scripts/docx_inventory.py。
示例：
python scripts/docx_inventory.py /path/to/project-materials --output material-inventory.md
该脚本会提取文件名、大致文档结构、标题线索、段落数、字符数、表格数和短内容预览。它的输出只是资料索引，不是最终分析。如果某个文件提取失败，仍要保留在资料索引中，并标注为无法读取或需要人工确认。
阶段检查点格式
每个阶段结束后，按以下结构汇报：
本阶段完成内容发现的关键判断主要风险或待确认点建议下一步- 请用户确认后再继续。
阶段摘要要短，方便用户快速检查。
