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

配置变量

${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 == “自动检测” ？
“首先扫描文件夹结构，查找能识别项目类型的关键文件：

• 查找解决方案/项目文件（.sln， .csproj， .fsproj， .vbproj）以识别 .NET 项目
• 检查 Java 项目的构建文件（pom.xml、build.gradle、settings.gradle）
• 识别带有依赖项的 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 == “自动检测” ？
“通过查找以下内容来确定这是否是一个 monorepo：

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

${INCLUDES_MICROSERVICES == “自动检测” ？
“检查微服务架构的指示器：

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

${INCLUDES_FRONTEND == “自动检测” ？
“通过查找以下内容来识别前端组件：

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

1. 结构概述

提供关于 ${PROJECT_TYPE == “自动检测” ？ “检测到的项目类型” ： PROJECT_TYPE} 项目的组织原则和文件夹结构的高级概述：

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

${IS_MONOREPO == “自动检测” ？
“如果检测到是 monorepo，请解释 monorepo 的组织方式以及项目之间的关系。” ：
IS_MONOREPO ？ “请解释 monorepo 的组织方式以及项目之间的关系。” ： “”}

${INCLUDES_MICROSERVICES == “自动检测” ？
“如果检测到微服务，请描述它们的结构和组织方式。” ：
INCLUDES_MICROSERVICES ？ “请描述微服务的结构和组织方式。” ： “”}

2. 目录可视化

${VISUALIZATION_STYLE == “ASCII” ？
“创建文件夹层次结构的 ASCII 树形表示，深度级别为 ${DEPTH_LEVEL}。” ： “”}

${VISUALIZATION_STYLE == “Markdown 列表” ？
“使用嵌套的 Markdown 列表表示文件夹层次结构，深度级别为 ${DEPTH_LEVEL}。” ： “”}

${VISUALIZATION_STYLE == “表格” ？
“创建一个包含路径、用途、内容类型和约定的表格。” ： “”}

${INCLUDE_GENERATED_FOLDERS ？
“包括所有文件夹，包括生成的文件夹。” ：
“排除自动生成的文件夹，如 bin/、obj/、node_modules/ 等。”}

3. 关键目录分析

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

${PROJECT_TYPE == “自动检测” ？
“对于每个检测到的技术，根据观察到的使用模式分析目录结构：” ： “”}

${(PROJECT_TYPE == “.NET” || PROJECT_TYPE == “自动检测”) ？
“#### .NET 项目结构（如果检测到）

• 解决方案组织：
  • 项目如何分组和关联
  • 解决方案文件夹组织模式
  • 多目标项目模式
• 项目组织：
  • 内部文件夹结构模式
  • 源代码组织方法
  • 资源组织
  • 项目依赖和引用
• 领域/功能组织：
  • 业务领域或功能如何分离
  • 领域边界强制执行模式
• 层组织：
  • 关注点分离（控制器、服务、仓库等）
  • 层交互和依赖模式
• 配置管理：
  • 配置文件的位置和用途
  • 特定于环境的配置
  • 密钥管理方法
• 测试项目组织：
  • 测试项目的结构和命名
  • 测试类别和组织
  • 测试数据和模拟的位置” ： “”}

${(PROJECT_TYPE == “React” || PROJECT_TYPE == “Angular” || PROJECT_TYPE == “自动检测”) ？
“#### UI 项目结构（如果检测到）

• 组件组织：
  • 组件文件夹结构模式
  • 分组策略（按功能、按类型等）
  • 共享组件与特定于功能的组件
• 状态管理：
  • 状态相关文件组织
  • 全局状态的存储结构
  • 本地状态管理模式
• 路由组织：
  • 路由定义位置
  • 页面/视图组件组织
  • 路由参数处理
• API 集成：
  • API 客户端组织
  • 服务层结构
  • 数据获取模式
• 资产管理：
  • 静态资源组织
  • 图像/媒体文件结构
  • 字体和图标组织
• 样式组织：
  • CSS/SCSS 文件结构
  • 主题组织
  • 样式模块模式” ： “”}

4. 文件放置模式

${INCLUDE_FILE_PATTERNS ？
“记录确定不同类型文件应放置在哪里的模式：

• 配置文件：
  • 不同类型配置的位置
  • 特定于环境的配置模式
• 模型/实体定义：
  • 领域模型定义的位置
  • 数据传输对象的位置
  • 模式定义的位置
• 业务逻辑：
  • 服务实现的位置
  • 业务规则组织
  • 工具和辅助函数的位置
• 接口定义：
  • 接口和抽象定义的位置
  • 接口如何分组和组织
• 测试文件：
  • 单元测试位置模式
  • 集成测试位置
  • 测试工具和模拟的位置
• 文档文件：
  • API 文档位置
  • 内部文档组织
  • README 文件分布” ：
    “记录项目中关键文件类型的位置。”}

5. 命名和组织约定

记录在整个项目中观察到的命名和组织约定：

• 文件命名模式：
  • 大小写约定（PascalCase、camelCase、kebab-case）
  • 前缀和后缀模式
  • 文件名中的类型指示符
• 文件夹命名模式：
  • 不同类型文件夹的命名约定
  • 层次结构命名模式
  • 分组和分类约定
• 命名空间/模块模式：
  • 命名空间/模块如何映射到文件夹结构
  • 导入/使用语句组织
  • 内部与公共 API 分离
• 组织模式：
  • 代码共置策略
  • 功能封装方法
  • 横切关注点组织

6. 导航和开发工作流程

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

• 入口点：
  • 主要的应用程序入口点
  • 关键配置起点
  • 理解项目的初始文件
• 常见的开发任务：
  • 在哪里添加新功能
  • 如何扩展现有功能
  • 在哪里放置新测试
  • 配置修改位置
• 依赖模式：
  • 依赖关系如何在文件夹之间流动
  • 导入/引用模式
  • 依赖注入注册位置

${INCLUDE_FILE_COUNTS ？
“- 内容统计：

• 每个目录的文件分析
• 代码分布指标
• 复杂度集中区域” ： “”}

7. 构建和输出组织

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

• 构建配置：
  • 构建脚本的位置和用途
  • 构建流水线组织
  • 构建任务定义
• 输出结构：
  • 编译/构建输出的位置
  • 输出组织模式
  • 分发包结构
• 特定于环境的构建：
  • 开发与生产环境的差异
  • 环境配置策略
  • 构建变体组织

8. 特定于技术的组织

${(PROJECT_TYPE == “.NET” || PROJECT_TYPE == “自动检测”) ？
“#### .NET 特定结构模式（如果检测到）

• 项目文件组织：
  • 项目文件结构和模式
  • 目标框架配置
  • 属性组组织
  • 项组模式
• 程序集组织：
  • 程序集命名模式
  • 多程序集架构
  • 程序集引用模式
• 资源组织：
  • 嵌入式资源模式
  • 本地化文件结构
  • 静态 Web 资产组织
• 包管理：
  • NuGet 配置位置
  • 包引用组织
  • 包版本管理” ： “”}

${(PROJECT_TYPE == “Java” || PROJECT_TYPE == “自动检测”) ？
“#### Java 特定结构模式（如果检测到）

• 包层次结构：
  • 包命名和嵌套约定
  • 领域与技术包
  • 可见性和访问模式
• 构建工具组织：
  • Maven/Gradle 结构模式
  • 模块组织
  • 插件配置模式
• 资源组织：
  • 资源文件夹结构
  • 特定于环境的资源
  • 属性文件组织” ： “”}

${(PROJECT_TYPE == “Node.js” || PROJECT_TYPE == “自动检测”) ？
“#### Node.js 特定结构模式（如果检测到）

• 模块组织：
  • CommonJS 与 ESM 组织
  • 内部模块模式
  • 第三方依赖管理
• 脚本组织：
  • npm/yarn 脚本定义模式
  • 工具脚本位置
  • 开发工具脚本
• 配置管理：
  • 配置文件位置
  • 环境变量管理
  • 密钥管理方法” ： “”}

9. 扩展与演化

记录项目结构如何设计以支持扩展：

• 扩展点：
  • 如何在遵守约定的情况下添加新模块/功能
  • 插件/扩展文件夹模式
  • 自定义目录结构
• 可扩展性模式：
  • 结构如何适应更大的功能
  • 分解大型模块的方法
  • 代码拆分策略
• 重构模式：
  • 观察到的常见重构方法
  • 结构变更如何管理
  • 增量式重组织模式

${INCLUDE_TEMPLATES ？
“### 10. 结构模板

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

• 新功能模板：
  • 添加完整功能的文件夹结构
  • 必需的文件类型及其位置
  • 要遵循的命名模式
• 新组件模板：
  • 典型组件的目录结构
  • 要包含的基本文件
  • 与现有结构的集成点
• 新服务模板：
  • 添加新服务的结构
  • 接口和实现的位置
  • 配置和注册模式
• 新测试结构：
  • 测试项目/文件的文件夹结构
  • 测试文件组织模板
  • 测试资源组织” ： “”}

${INCLUDE_TEMPLATES ？ “11” ： “10”}。结构强制

记录如何维护和强制执行项目结构：

• 结构验证：
  • 强制执行结构的工具/脚本
  • 用于结构合规性的构建检查
  • 与结构相关的代码检查规则
• 文档实践：
  • 结构更改如何记录
  • 架构决策记录的位置
  • 结构演化历史

在结尾处包含一个关于维护此蓝图以及最后更新时间的部分。
”