folder-structure-blueprint-generator

项目文件夹结构蓝图生成器

配置变量

${PROJECT_TYPE="自动检测|.NET|Java|React|Angular|Python|Node.js|Flutter|其他"}

${INCLUDES_MICROSERVICES="自动检测|true|false"}

${INCLUDES_FRONTEND="自动检测|true|false"}

${IS_MONOREPO="自动检测|true|false"}

${VISUALIZATION_STYLE="ASCII|Markdown 列表|表格"}

${DEPTH_LEVEL=1-5}

${INCLUDE_FILE_COUNTS=true|false}

${INCLUDE_GENERATED_FOLDERS=true|false}

${INCLUDE_FILE_PATTERNS=true|false}

${INCLUDE_TEMPLATES=true|false}

生成的提示词

"分析项目的文件夹结构，并创建一份全面的 'Project_Folders_Structure_Blueprint.md' 文档，作为保持代码组织一致性的权威指南。使用以下方法：

初始自动检测阶段

${PROJECT_TYPE == "Auto-detect" ? "首先扫描文件夹结构，查找可识别项目类型的关键文件：

• 查找解决方案/项目文件（.sln、.csproj、.fsproj、.vbproj）以识别 .NET 项目
• 检查构建文件（pom.xml、build.gradle、settings.gradle）以识别 Java 项目
• 识别带有依赖项的 package.json 以确定 JavaScript/TypeScript 项目
• 查找特定框架文件（angular.json、react-scripts 条目、next.config.js）
• 检查 Python 项目标识文件（requirements.txt、setup.py、pyproject.toml）
• 检查移动应用标识文件（pubspec.yaml、android/ios 文件夹）
• 记录发现的所有技术特征及其版本" : "将分析重点放在 ${PROJECT_TYPE} 项目结构上"}

${IS_MONOREPO == "Auto-detect" ? "通过查找以下内容判断这是否为 monorepo：

• 多个具有各自配置文件的独立项目
• 工作区配置文件（lerna.json、nx.json、turborepo.json 等）
• 跨项目引用和共享依赖模式
• 根级编排脚本和配置" : ""}

${INCLUDES_MICROSERVICES == "Auto-detect" ? "检查微服务架构指标：

• 多个具有相似/重复结构的服务目录
• 各服务专用的 Dockerfile 或部署配置
• 服务间通信模式（API、消息代理）
• 服务注册或发现配置
• API 网关配置文件
• 跨服务共享的库或工具" : ""}

${INCLUDES_FRONTEND == "Auto-detect" ? "通过查找以下内容识别前端组件：

• Web 资源目录（wwwroot、public、dist、static）
• UI 框架文件（组件、模块、页面）
• 前端构建配置（webpack、vite、rollup 等）
• 样式表组织（CSS、SCSS、styled-components）
• 静态资源组织（图片、字体、图标）" : ""}

1. 结构概览

提供 ${PROJECT_TYPE == "Auto-detect" ? "检测到的项目类型" : PROJECT_TYPE} 项目的组织原则和文件夹结构的高层概览：

• 记录文件夹结构所反映的整体架构方法
• 识别主要的组织原则（按功能、按层、按领域等）
• 记录代码库中重复出现的任何结构模式
• 在可以推断的情况下记录该结构背后的依据

${IS_MONOREPO == "Auto-detect" ? "如果检测到是 monorepo，说明该 monorepo 的组织方式以及各项目之间的关系。" : IS_MONOREPO ? "说明该 monorepo 的组织方式以及各项目之间的关系。" : ""}

${INCLUDES_MICROSERVICES == "Auto-detect" ? "如果检测到微服务，说明它们的结构方式和组织方式。" : INCLUDES_MICROSERVICES ? "说明微服务的结构方式和组织方式。" : ""}

2. 目录可视化

${VISUALIZATION_STYLE == "ASCII" ? "创建文件夹层级结构的 ASCII 树形表示，深度为 ${DEPTH_LEVEL} 级。" : ""}

${VISUALIZATION_STYLE == "Markdown List" ? "使用嵌套的 markdown 列表表示文件夹层级结构，深度为 ${DEPTH_LEVEL} 级。" : ""}

${VISUALIZATION_STYLE == "Table" ? "创建一个表格，包含 Path、Purpose、Content Types 和 Conventions 列。" : ""}

${INCLUDE_GENERATED_FOLDERS ? "包含所有文件夹，包括生成的文件夹。" : "排除自动生成的文件夹，如 bin/、obj/、node_modules/ 等。"}

3. 关键目录分析

记录每个重要目录的用途、内容和模式：

${PROJECT_TYPE == "Auto-detect" ? "对于每种检测到的技术，根据观察到的使用模式分析目录结构：" : ""}

${(PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect") ? "#### .NET 项目结构（如果检测到）

• 解决方案组织:

  • 项目如何分组和关联
  • 解决方案文件夹组织模式
  • 多目标项目模式

• 项目组织:

  • 内部文件夹结构模式
  • 源代码组织方式
  • 资源组织
  • 项目依赖和引用

• 领域/功能组织:

  • 业务领域或功能如何分离
  • 领域边界实施模式

• 分层组织:

  • 关注点分离（Controllers、Services、Repositories 等）
  • 层交互和依赖模式

• 配置管理:

  • 配置文件位置和用途
  • 特定于环境的配置
  • 密钥管理方式

• 测试项目组织:

  • 测试项目结构和命名
  • 测试分类和组织
  • 测试数据和 mock 位置" : ""}

${(PROJECT_TYPE == "React" || PROJECT_TYPE == "Angular" || PROJECT_TYPE == "Auto-detect") ? "#### UI 项目结构（如果检测到）

• 组件组织:

  • 组件文件夹结构模式
  • 分组策略（按功能、类型等）
  • 共享组件与特定功能组件

• 状态管理:

  • 状态相关文件组织
  • 全局状态的 Store 结构
  • 局部状态管理模式

• 路由组织:

  • 路由定义位置
  • 页面/视图组件组织
  • 路由参数处理

• API 集成:

  • API 客户端组织
  • 服务层结构
  • 数据获取模式

• 资源管理:

  • 静态资源组织
  • 图片/媒体文件结构
  • 字体和图标组织

• 样式组织:

  • CSS/SCSS 文件结构
  • 主题组织
  • 样式模块模式" : ""}

4. 文件放置模式

${INCLUDE_FILE_PATTERNS ? "记录决定不同类型文件应放置位置的模式：

• 配置文件:

  • 不同类型配置的位置
  • 特定于环境的配置模式

• 模型/实体定义:

  • 领域模型的定义位置
  • 数据传输对象（DTO）位置
  • Schema 定义位置

• 业务逻辑:

  • 服务实现位置
  • 业务规则组织
  • 实用工具和辅助函数放置位置

• 接口定义:

  • 接口和抽象的定义位置
  • 接口如何分组和组织

• 测试文件:

  • 单元测试位置模式
  • 集成测试放置位置
  • 测试实用工具和 mock 位置

• 文档文件:

  • API 文档放置位置
  • 内部文档组织
  • README 文件分布" : "记录关键文件类型在项目中的位置。"}

5. 命名与组织约定

记录项目中观察到的命名与组织约定：

• 文件命名模式：

  • 大小写约定（PascalCase、camelCase、kebab-case）
  • 前缀与后缀模式
  • 文件名中的类型标识

• 文件夹命名模式：

  • 不同文件夹类型的命名约定
  • 层级命名模式
  • 分组与分类约定

• 命名空间/模块模式：

  • 命名空间/模块如何映射到文件夹结构
  • import/using 语句的组织方式
  • 内部 API 与公共 API 的分离

• 组织模式：

  • 代码同置策略
  • 功能封装方式
  • 横切关注点的组织

6. 导航与开发工作流

提供有关如何导航和使用代码库结构的指导：

• 入口点：

  • 主应用入口点
  • 关键配置起始点
  • 用于理解项目的初始文件

• 常见开发任务：

  • 在何处添加新功能
  • 如何扩展现有功能
  • 在何处放置新测试
  • 配置修改位置

• 依赖模式：

  • 依赖如何在文件夹之间流动
  • import/reference 模式
  • 依赖注入的注册位置

${INCLUDE_FILE_COUNTS ? "- 内容统计：

• 各目录文件数量分析
• 代码分布指标
• 复杂度集中区域" : ""}

7. 构建与输出组织

记录构建过程与输出组织：

• 构建配置：

  • 构建脚本位置与用途
  • 构建流水线组织
  • 构建任务定义

• 输出结构：

  • 编译/构建输出位置
  • 输出组织模式
  • 分发包结构

• 特定环境的构建：

  • 开发与生产的差异
  • 环境配置策略
  • 构建变体的组织

8. 技术特定的组织方式

${(PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect") ? "#### .NET 特定的结构模式（如检测到）

• 项目文件组织：

  • 项目文件结构与模式
  • 目标框架配置
  • Property group 组织
  • Item group 模式

• 程序集组织：

  • 程序集命名模式
  • 多程序集架构
  • 程序集引用模式

• 资源组织：

  • 嵌入资源模式
  • 本地化文件结构
  • 静态 Web 资产组织

• 包管理：

  • NuGet 配置位置
  • 包引用组织
  • 包版本管理" : ""}

${(PROJECT_TYPE == "Java" || PROJECT_TYPE == "Auto-detect") ? "#### Java 特定的结构模式（如检测到）

• 包层级：

  • 包命名与嵌套约定
  • 领域包与技术包
  • 可见性与访问模式

• 构建工具组织：

  • Maven/Gradle 结构模式
  • 模块组织
  • 插件配置模式

• 资源组织：

  • 资源文件夹结构
  • 特定环境的资源
  • 属性文件组织" : ""}

${(PROJECT_TYPE == "Node.js" || PROJECT_TYPE == "Auto-detect") ? "#### Node.js 特定的结构模式（如检测到）

• 模块组织：

  • CommonJS 与 ESM 的组织
  • 内部模块模式
  • 第三方依赖管理

• 脚本组织：

  • npm/yarn 脚本定义模式
  • 实用脚本位置
  • 开发工具脚本

• 配置管理：

  • 配置文件位置
  • 环境变量管理
  • 密钥管理方式" : ""}

9. 扩展与演进

说明项目结构在设计上如何支持扩展：

• 扩展点：

  • 如何在保持约定不变的情况下添加新模块/功能
  • 插件/扩展目录模式
  • 自定义目录结构

• 可扩展性模式：

  • 结构如何随更大规模的功能进行扩展
  • 拆分大型模块的方法
  • 代码拆分策略

• 重构模式：

  • 观察到的常见重构方法
  • 如何管理结构性变更
  • 增量重组模式

${INCLUDE_TEMPLATES ? "### 10. 结构模板

提供用于创建遵循项目约定的新组件的模板：

• 新功能模板：

  • 添加完整功能的目录结构
  • 必需的文件类型及其位置
  • 应遵循的命名模式

• 新组件模板：

  • 典型组件的目录结构
  • 应包含的必要文件
  • 与现有结构的集成点

• 新服务模板：

  • 添加新服务的结构
  • 接口与实现的放置位置
  • 配置与注册模式

• 新测试结构：

  • 测试项目/文件的目录结构
  • 测试文件组织模板
  • 测试资源组织" : ""}

${INCLUDE_TEMPLATES ? "11" : "10"}. 结构约束

说明项目结构如何被维护和执行：

• 结构验证：

  • 用于约束结构的工具/脚本
  • 针对结构合规性的构建检查
  • 与结构相关的 lint 规则

• 文档实践：

  • 如何记录结构性变更
  • 架构决策记录在何处
  • 结构演进历史

在末尾包含一节，说明如何维护这份蓝图以及它最后更新的时间。