全面技术栈蓝图生成器

配置变量

${PROJECT_TYPE=”自动检测|.NET|Java|JavaScript|React.js|React Native|Angular|Python|其他”}
${DEPTH_LEVEL=”基础|标准|全面|可实现级”}
${INCLUDE_VERSIONS=true|false}
${INCLUDE_LICENSES=true|false}
${INCLUDE_DIAGRAMS=true|false}
${INCLUDE_USAGE_PATTERNS=true|false}
${INCLUDE_CONVENTIONS=true|false}
${OUTPUT_FORMAT=”Markdown|JSON|YAML|HTML”}
${CATEGORIZATION=”按技术类型|按层次|按用途”}

生成的提示词

“分析代码库并生成一份 ${DEPTH_LEVEL} 技术栈蓝图，全面记录技术和实现模式，以促进一致的代码生成。请使用以下方法：

1. 技术识别阶段

• ${PROJECT_TYPE == “自动检测” ? “扫描代码库中的项目文件、配置文件和依赖项，以确定所有使用的技术栈” : “专注于 ${PROJECT_TYPE} 技术”}
• 通过检查文件扩展名和内容来识别所有编程语言
• 分析配置文件（package.json、.csproj、pom.xml 等）以提取依赖项
• 检查构建脚本和流水线定义以获取工具信息
• ${INCLUDE_VERSIONS ? “从包文件和配置中提取精确的版本信息” : “跳过版本细节”}
• ${INCLUDE_LICENSES ? “记录所有依赖项的许可证信息” : “”}

2. 核心技术分析

${PROJECT_TYPE == “.NET” || PROJECT_TYPE == “自动检测” ? “#### .NET 栈分析（如果检测到）

• 目标框架和语言版本（从项目文件中检测）
• 所有 NuGet 包引用，包含版本和用途说明
• 项目结构和组织模式
• 配置方法（appsettings.json、IOptions 等）
• 身份验证机制（Identity、JWT 等）
• API 设计模式（REST、GraphQL、最小 API 等）
• 数据访问方法（EF Core、Dapper 等）
• 依赖注入模式
• 中间件管道组件” : “”}

${PROJECT_TYPE == “Java” || PROJECT_TYPE == “自动检测” ? “#### Java 栈分析（如果检测到）

• JDK 版本和核心框架
• 所有 Maven/Gradle 依赖项，包含版本和用途
• 包结构组织
• Spring Boot 使用情况和配置
• 注解模式
• 依赖注入方法
• 数据访问技术（JPA、JDBC 等）
• API 设计（Spring MVC、JAX-RS 等）” : “”}

${PROJECT_TYPE == “JavaScript” || PROJECT_TYPE == “自动检测” ? “#### JavaScript 栈分析（如果检测到）

• ECMAScript 版本和转译器设置
• 按用途分类的所有 npm 依赖项
• 模块系统（ESM、CommonJS）
• 构建工具（webpack、Vite 等）及其配置
• TypeScript 使用情况和配置
• 测试框架和模式” : “”}

${PROJECT_TYPE == “React.js” || PROJECT_TYPE == “自动检测” ? “#### React 分析（如果检测到）

• React 版本和关键模式（hooks 与类组件）
• 状态管理方法（Context、Redux、Zustand 等）
• 组件库使用情况（Material-UI、Chakra 等）
• 路由实现
• 表单处理策略
• API 集成模式
• 组件的测试方法” : “”}

${PROJECT_TYPE == “Python” || PROJECT_TYPE == “自动检测” ? “#### Python 分析（如果检测到）

• Python 版本和使用的关键语言特性
• 包依赖项和虚拟环境设置
• Web 框架详情（Django、Flask、FastAPI）
• ORM 使用模式
• 项目结构组织
• API 设计模式” : “”}

3. 实现模式与约定

${INCLUDE_CONVENTIONS ?
“记录每个技术领域的编码约定和模式：

命名约定

• 类/类型命名模式
• 方法/函数命名模式
• 变量命名约定
• 文件命名和组织约定
• 接口/抽象类模式

代码组织

• 文件结构和组织
• 文件夹层次结构模式
• 组件/模块边界
• 代码分离和职责模式

常见模式

• 错误处理方法
• 日志记录模式
• 配置访问
• 身份验证/授权实现
• 验证策略
• 测试模式” : “”}

4. 使用示例

${INCLUDE_USAGE_PATTERNS ?
“提取具有代表性的代码示例，展示标准实现模式：

API 实现示例

• 标准控制器/端点实现
• 请求 DTO 模式
• 响应格式化
• 验证方法
• 错误处理

数据访问示例

• 仓储模式实现
• 实体/模型定义
• 查询模式
• 事务处理

服务层示例

• 服务类实现
• 业务逻辑组织
• 横切关注点集成
• 依赖注入使用

UI 组件示例（如适用）

• 组件结构
• 状态管理模式
• 事件处理
• API 集成模式” : “”}

5. 技术栈映射

${DEPTH_LEVEL == “全面” || DEPTH_LEVEL == “可实现级” ?
“创建全面的技术映射，包括：

核心框架使用

• 主要框架及其在项目中的具体用途
• 特定于框架的配置和自定义
• 扩展点和自定义项

集成点

• 不同技术组件如何集成
• 组件间的身份验证流
• 前端和后端之间的数据流
• 第三方服务集成模式

开发工具

• IDE 设置和约定
• 代码分析工具
• 带配置的 linter 和格式化程序
• 构建和部署流水线
• 测试框架和方法

基础设施

• 部署环境详情
• 容器技术
• 使用的云服务
• 监控和日志记录基础设施” : “”}

6. 特定技术的实现细节

${PROJECT_TYPE == “.NET” || PROJECT_TYPE == “自动检测” ?
“#### .NET 实现细节（如果检测到）

• 依赖注入模式：
  • 服务注册方法（Scoped/Singleton/Transient 模式）
  • 配置绑定模式
• 控制器模式：
  • 基控制器使用
  • 操作结果类型和模式
  • 路由属性约定
  • 过滤器使用（授权、验证等）
• 数据访问模式：
  • ORM 配置和使用
  • 实体配置方法
  • 关系定义
  • 查询模式和优化方法
• API 设计模式（如果使用）：
  • 端点组织
  • 参数绑定方法
  • 响应类型处理
• 使用的语言特性：
  • 从代码中检测特定语言特性
  • 识别常见模式和惯用法
  • 记录任何特定的版本依赖特性” : “”}

${PROJECT_TYPE == “React.js” || PROJECT_TYPE == “自动检测” ?
“#### React 实现细节（如果检测到）

• 组件结构：
  • 函数组件与类组件
  • Props 接口定义
  • 组件组合模式
• Hook 使用模式：
  • 自定义 Hook 实现风格
  • useState 模式
  • useEffect 清理方法
  • Context 使用模式
• 状态管理：
  • 本地状态与全局状态的决策
  • 状态管理库模式
  • Store 配置
  • Selector 模式
• 样式方法：
  • CSS 方法论（CSS modules、styled-components 等）
  • 主题实现
  • 响应式设计模式” : “”}

7. 新代码实现蓝图

${DEPTH_LEVEL == “可实现级” ?
“基于分析，提供实现新功能的详细蓝图：

• 文件/类模板：常见组件类型的标准结构
• 代码片段：常见操作的可立即使用的代码模式
• 实现检查清单：端到端实现功能的标准步骤
• 集成点：如何将新代码与现有系统连接
• 测试要求：不同组件类型的标准测试模式
• 文档要求：新功能的标准文档模式” : “”}

${INCLUDE_DIAGRAMS ?
“### 8. 技术关系图

• 栈图：完整技术栈的视觉表示
• 依赖流：不同技术如何交互
• 组件关系：主要组件如何相互依赖
• 数据流：数据如何流经技术栈” : “”}

${INCLUDE_DIAGRAMS ? “9” : “8”}. 技术决策背景

• 记录技术选择的明显原因
• 记录任何标记为待替换的遗留或弃用技术
• 识别技术约束和边界
• 记录技术升级路径和兼容性考虑

将输出格式化为 ${OUTPUT_FORMAT}，并按 ${CATEGORIZATION} 对技术进行分类。

将输出保存为 ‘Technology_Stack_Blueprint.${OUTPUT_FORMAT == “Markdown” ? “md” : OUTPUT_FORMAT.toLowerCase()}’
”