cykj/hzdyjs
1
0 Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
Files
65d2d714693beccb68daed9dc123705166ebe6ba
hzdyjs/prompt.md
T

20 KiB
Raw Blame History

Cursor AI 提示词模板指南

🎯 文档目的：为开发人员提供标准化的 Cursor AI 提示词模板，确保高效的 AI 辅助开发和文档管理

📋 目录

🆕 新功能开发提示词

基础新功能开发

基于以下业务需求开发 [功能名称]：

**业务上下文**：
- 业务需求：docs/业务模块/[模块名称]/需求分析/
- 技术规范：docs/开发文档/README.md
- API规范：docs/开发文档/API.md
- 数据库设计：docs/设计文档/database/

**开发要求**：
1. 严格遵循项目编码规范
2. 使用标准的MVC分层架构
3. 实现完整的CRUD操作
4. 添加适当的权限控制
5. 编写单元测试
6. 添加详细的代码注释

**技术要求**：
- 后端：Spring Boot + MyBatis-Plus + Sa-Token
- 前端：Vue 3 + TypeScript + Element Plus
- 数据库：MySQL 8.0，使用雪花ID

**输出要求**：
1. 生成完整的后端代码（Controller、Service、Mapper、Entity）
2. 生成对应的前端页面（列表页、表单页、详情页）
3. 生成数据库SQL脚本
4. 立即更新相关文档

开发完成后请同步更新：
- docs/开发文档/API.md（新增接口文档）
- docs/业务模块/[模块名称]/相关文档
- docs/变更管理/code-adjust-record.md（记录变更）

复杂业务功能开发

基于业务模块文档开发 [复杂功能名称]：

**上下文文档**：
- 详细需求：docs/业务模块/[模块名称]/需求分析/业务需求说明.md
- 业务流程：docs/业务模块/[模块名称]/需求分析/用户故事.md
- 技术设计：docs/业务模块/[模块名称]/技术设计/
- 相关API：docs/开发文档/API.md

**特殊要求**：
1. 实现工作流引擎集成（使用Warm-Flow）
2. 支持多步骤审批流程
3. 实现实时消息通知
4. 考虑并发处理和数据一致性
5. 支持移动端访问

**性能要求**：
- 接口响应时间 < 200ms
- 支持1000并发用户
- 数据查询优化（合理使用索引和缓存）

请按照业务模块开发模板的标准结构进行开发，并确保与现有系统的良好集成。

🔧 代码重构优化提示词

性能优化重构

对 [模块/类名] 进行性能优化重构：

**当前问题分析**：
- 性能瓶颈：[具体描述性能问题]
- 响应时间：[当前响应时间]
- 资源使用：[内存/CPU使用情况]

**优化目标**：
- 目标响应时间：< [X]ms
- 内存使用优化：减少 [X]%
- 提升并发能力：支持 [X] 并发

**优化策略**：
1. 数据库查询优化（使用合适的索引和查询方式）
2. 缓存策略优化（Redis缓存热点数据）
3. 代码逻辑优化（减少不必要的循环和计算）
4. 异步处理优化（使用@Async注解）

**约束条件**：
- 不改变外部接口
- 保持业务逻辑不变
- 确保向下兼容
- 添加性能监控指标

请提供优化前后的性能对比数据，并更新相关技术文档。

代码结构重构

重构 [模块名称] 的代码结构：

**重构原因**：
- [具体的代码问题，如：代码重复、结构混乱、难以维护等]

**重构目标**：
1. 提高代码可读性和可维护性
2. 减少代码重复，遵循DRY原则
3. 改善代码结构，符合SOLID原则
4. 提升代码复用性

**技术规范**：
- 遵循项目编码规范：docs/开发文档/README.md
- 使用标准设计模式
- 添加适当的抽象层
- 保持单一职责原则

**注意事项**：
- 保持API接口不变
- 确保所有测试用例通过
- 逐步重构，避免大范围改动
- 记录重构过程和决策

重构完成后请更新代码注释和相关技术文档。

🐛 Bug 修复提示词

功能 Bug 修复

修复 [具体Bug描述]：

**Bug信息**：
- Bug现象：[详细描述Bug的表现]
- 复现步骤：[如何复现这个Bug]
- 影响范围：[Bug影响的功能和用户]
- 优先级：[高/中/低]

**上下文信息**：
- 相关代码文件：[列出相关文件路径]
- 相关API接口：[如果涉及API]
- 数据库表：[如果涉及数据库]
- 错误日志：[如果有错误日志]

**修复要求**：
1. 准确定位Bug根本原因
2. 提供最小化修复方案
3. 确保不引入新的问题
4. 添加防御性代码
5. 编写回归测试用例

**测试要求**：
- 验证Bug已修复
- 确保相关功能正常
- 进行边界条件测试
- 验证性能没有下降

修复完成后请更新：
- 相关代码注释
- 测试用例
- 变更记录文档

性能 Bug 修复

修复性能问题：[具体性能问题描述]

**性能问题分析**：
- 当前性能指标：[响应时间、吞吐量等]
- 性能瓶颈位置：[具体定位]
- 资源使用情况：[CPU、内存、数据库连接等]

**期望目标**：
- 目标响应时间：< [X]ms
- 目标吞吐量：> [X] QPS
- 资源使用优化目标

**优化方向**：
1. SQL查询优化
2. 缓存策略改进
3. 算法复杂度优化
4. 资源池配置调优

请提供性能测试报告和优化前后对比数据。

📚 文档更新提示词

API 文档更新

根据代码变更更新API文档：

**变更内容**：
[具体的代码变更内容，包括新增、修改、删除的接口]

**文档更新要求**：
1. 严格按照 docs/开发文档/API文档模板.md 的格式
2. 更新 docs/开发文档/API.md 主文档
3. 包含完整的接口信息：
   - 接口地址和HTTP方法
   - 详细的参数说明
   - 真实的请求和响应示例
   - 完整的错误码定义
   - 权限要求说明

**特别注意**：
- 确保示例数据真实有效
- 参数说明要详细准确
- 响应格式要与实际代码一致
- 错误码要覆盖所有可能情况

**验证要求**：
- 使用Postman验证API示例
- 确保文档与代码完全一致
- 检查所有链接和引用正确

更新完成后在变更记录中标注已同步更新API文档。

业务模块文档更新

更新 [模块名称] 业务模块文档：

**更新触发原因**：
- [功能新增/修改/重构等具体原因]

**需要更新的文档**：
1. docs/业务模块/[模块名称]/需求分析/ （如有业务变更）
2. docs/业务模块/[模块名称]/技术设计/ （如有技术变更）
3. docs/业务模块/[模块名称]/实现文档/ （代码结构变更）

**更新标准**：
- 使用 docs/业务模块/业务模块开发模板.md 作为格式参考
- 确保文档内容与实际实现一致
- 添加必要的流程图和架构图
- 更新相关的用户故事和功能清单

**质量要求**：
- 业务逻辑描述清晰准确
- 技术实现细节完整
- 包含完整的示例和说明
- 添加必要的注意事项

请确保文档可以为其他开发人员和AI提供充分的上下文信息。

👀 代码审查提示词

代码质量审查

对以下代码进行质量审查：

**审查范围**：
[指定具体的文件路径或代码片段]

**审查重点**：
1. **代码规范**：是否符合项目编码规范
2. **架构合理性**：是否符合MVC分层架构
3. **业务逻辑**：是否正确实现业务需求
4. **性能考虑**：是否有性能问题
5. **安全性**：是否存在安全隐患
6. **可维护性**：代码是否易于理解和维护

**具体检查项**：
- 命名规范（类名、方法名、变量名）
- 代码注释的完整性和准确性
- 异常处理是否合理
- 数据库操作是否安全（防SQL注入）
- 权限控制是否到位
- 单元测试覆盖率

**输出要求**：
1. 列出发现的问题及严重程度
2. 提供具体的改进建议
3. 给出代码质量评分
4. 重点关注业务逻辑正确性

请基于项目规范（docs/开发文档/README.md）进行审查。

安全性审查

对代码进行安全性审查：

**安全检查项目**：
1. **输入验证**：所有用户输入是否经过验证
2. **SQL注入防护**：是否使用参数化查询
3. **权限控制**：接口权限验证是否完整
4. **数据脱敏**：敏感数据是否正确处理
5. **会话管理**：Token管理是否安全
6. **错误处理**：是否泄露敏感信息

**重点关注**：
- @SaCheckPermission注解使用是否正确
- 数据库查询是否安全
- 文件上传下载是否安全
- 日志记录是否包含敏感信息
- 接口是否有越权访问风险

请提供详细的安全风险评估和修复建议。

🔌 API 开发提示词

RESTful API 开发

开发 [实体名称] 的RESTful API：

**基础信息**：
- 实体名称：[Entity]
- 模块路径：[module]
- 业务描述：[业务功能说明]

**API设计要求**：
1. **标准CRUD接口**：
   - GET /api/[module]/list - 分页查询列表
   - GET /api/[module]/{id} - 查询详情
   - POST /api/[module] - 新增
   - PUT /api/[module] - 修改
   - DELETE /api/[module]/{ids} - 批量删除

2. **业务接口**（如需要）：
   - [自定义业务接口列表]

**技术规范**：
- 使用 @RestController 和 @RequestMapping
- 统一响应格式：Result<T>
- 参数验证：@Valid 和 @Validated
- 权限控制：@SaCheckPermission
- 异常处理：全局异常处理器

**代码生成要求**：
1. Controller层：处理HTTP请求
2. Service层：业务逻辑处理
3. Mapper层：数据访问
4. Entity/VO/BO：数据传输对象

**文档要求**：
开发完成后立即更新 docs/开发文档/API.md，包含：
- 完整的接口定义
- 详细的参数说明
- 真实的请求响应示例
- 完整的错误码说明

复杂业务 API 开发

开发 [业务功能] 的复杂业务API：

**业务需求**：
- 参考：docs/业务模块/[模块名称]/需求分析/
- 业务流程：[具体业务流程说明]
- 特殊要求：[审批流程/状态流转/数据校验等]

**技术实现要求**：
1. **事务处理**：确保数据一致性
2. **并发控制**：处理并发访问问题
3. **性能优化**：合理使用缓存和异步处理
4. **错误处理**：完善的异常处理机制

**集成要求**：
- 工作流引擎：Warm-Flow（如需要）
- 消息通知：实时通知相关用户
- 数据同步：与其他模块的数据同步
- 日志记录：完整的操作日志

**测试要求**：
1. 单元测试：覆盖所有业务逻辑
2. 集成测试：测试完整业务流程
3. 性能测试：验证性能指标
4. 边界测试：测试异常情况处理

请确保API设计符合RESTful规范和项目技术标准。

🗄️ 数据库设计提示词

数据库表设计

设计 [业务模块] 的数据库表结构：

**业务需求**：
- 参考：docs/业务模块/[模块名称]/需求分析/
- 数据规范：docs/设计文档/database/README.md
- 现有表结构：docs/设计文档/database/hzdyjs_xg.sql

**设计要求**：
1. **命名规范**：
   - 表名：[module]_[entity] （如：sys_user）
   - 字段名：下划线命名法
   - 索引名：idx_表名_字段名

2. **标准字段**（所有业务表必须包含）：
   - id (BIGINT) - 主键，雪花ID
   - tenant_id (VARCHAR(20)) - 租户ID
   - create_dept (BIGINT) - 创建部门
   - create_by (BIGINT) - 创建人
   - create_time (DATETIME) - 创建时间
   - update_by (BIGINT) - 更新人
   - update_time (DATETIME) - 更新时间
   - deleted (TINYINT) - 逻辑删除标记，默认0

3. **性能优化**：
   - 合理设置索引
   - 考虑查询性能
   - 字段类型选择恰当
   - 预估数据量和增长

**输出要求**：
1. 完整的CREATE TABLE语句
2. 必要的索引创建语句
3. 表和字段的详细注释
4. 数据字典说明

设计完成后请更新 docs/设计文档/database/ 相关文档。

数据库优化设计

优化 [表名/查询] 的数据库性能：

**当前问题**：
- 性能瓶颈：[查询慢/死锁/资源占用高等]
- 影响范围：[受影响的功能]
- 性能指标：[当前响应时间/QPS等]

**优化目标**：
- 查询响应时间：< [X]ms
- 并发支持：> [X] QPS
- 资源使用：减少[X]%

**优化策略**：
1. **索引优化**：
   - 分析慢查询日志
   - 设计合适的复合索引
   - 清理无用索引

2. **查询优化**：
   - 优化SQL语句
   - 避免全表扫描
   - 合理使用JOIN

3. **表结构优化**：
   - 字段类型优化
   - 分表分库考虑
   - 归档历史数据

**验证要求**：
- 提供优化前后性能对比
- 确保数据正确性
- 验证业务功能正常

请同时更新数据库设计文档和性能优化说明。

🧪 测试编写提示词

单元测试编写

为 [类名/方法名] 编写单元测试：

**测试目标**：
- 被测试类：[完整类路径]
- 业务功能：[功能描述]
- 覆盖要求：> 80%

**测试框架**：
- JUnit 5 + Mockito
- Spring Boot Test
- TestContainers（如需要数据库测试）

**测试用例设计**：
1. **正常流程测试**：
   - 正常输入的预期输出
   - 边界值测试
   - 典型业务场景

2. **异常流程测试**：
   - 异常输入处理
   - 业务规则验证
   - 错误边界处理

3. **Mock对象**：
   - Mock外部依赖
   - Mock数据库操作
   - Mock第三方服务

**测试数据**：
- 使用真实但脱敏的测试数据
- 覆盖各种数据场景
- 准备充分的边界数据

**质量要求**：
- 测试用例独立性
- 可重复执行
- 清晰的断言
- 详细的测试注释

请确保测试用例能够充分验证业务逻辑的正确性。

集成测试编写

编写 [模块名称] 的集成测试：

**测试范围**：
- API接口测试
- 数据库集成测试
- 模块间集成测试
- 第三方服务集成

**测试环境**：
- 使用Spring Boot Test
- 配置测试数据库
- Mock外部服务
- 准备测试数据

**测试场景**：
1. **API接口测试**：
   - 所有HTTP接口
   - 参数验证
   - 权限控制
   - 错误处理

2. **业务流程测试**：
   - 完整业务流程
   - 数据流转验证
   - 状态变更测试

3. **数据一致性测试**：
   - 事务回滚测试
   - 并发访问测试
   - 数据完整性验证

**性能测试**：
- 接口响应时间
- 并发访问能力
- 资源使用监控

请提供详细的测试报告和问题分析。

🔍 问题排查提示词

系统问题诊断

诊断系统问题：[问题描述]

**问题信息**：
- 现象描述：[详细的问题现象]
- 发生时间：[问题开始时间]
- 影响范围：[受影响的功能和用户]
- 错误信息：[如果有错误日志]

**环境信息**：
- 部署环境：[开发/测试/生产]
- 系统版本：[当前系统版本]
- 相关配置：[可能相关的配置信息]

**诊断步骤**：
1. **日志分析**：
   - 查看应用日志
   - 分析错误堆栈
   - 检查系统监控数据

2. **代码分析**：
   - 分析相关代码逻辑
   - 检查最近的代码变更
   - 验证业务逻辑正确性

3. **环境检查**：
   - 数据库连接状态
   - 缓存服务状态
   - 网络连接状况

**解决方案**：
- 提供临时解决方案
- 制定根本解决方案
- 预防措施建议
- 监控改进建议

请提供详细的问题分析报告和解决步骤。

性能问题排查

排查性能问题：[具体性能问题]

**性能指标**：
- 当前响应时间：[X]ms
- 期望响应时间：[X]ms
- 并发用户数：[X]
- 错误率：[X]%

**排查维度**：
1. **应用层面**：
   - 代码执行效率
   - 算法复杂度
   - 内存使用情况
   - GC性能分析

2. **数据库层面**：
   - 慢查询分析
   - 索引使用情况
   - 锁等待分析
   - 连接池状态

3. **系统层面**：
   - CPU使用率
   - 内存使用率
   - 网络I/O
   - 磁盘I/O

**分析工具**：
- JProfiler/Arthas
- MySQL Performance Schema
- 应用监控平台
- 系统监控工具

**优化建议**：
请提供具体的性能优化方案和预期效果。

🏗️ 架构设计提示词

系统架构设计

设计 [系统/模块] 的技术架构：

**业务背景**：
- 业务需求：[核心业务需求]
- 用户规模：[预期用户数量]
- 数据规模：[预期数据量]
- 性能要求：[响应时间、并发量等]

**技术选型**：
- 遵循项目技术栈：docs/开发文档/README.md
- 后端：Spring Boot + MyBatis-Plus + Sa-Token
- 前端：Vue 3 + TypeScript + Element Plus
- 数据库：MySQL + Redis
- 中间件：[根据需要选择]

**架构原则**：
1. **可扩展性**：支持水平扩展
2. **可维护性**：模块化设计，低耦合
3. **高可用性**：容错和降级机制
4. **安全性**：完善的权限控制

**设计要求**：
1. 分层架构设计
2. 模块依赖关系
3. 数据流转设计
4. 接口定义
5. 部署架构

**输出要求**：
1. 架构图（使用Mermaid）
2. 模块说明文档
3. 接口设计文档
4. 部署方案

请确保架构设计符合现有系统和项目规范。

微服务拆分设计

设计微服务拆分方案：

**拆分原则**：
1. **业务边界**：按业务领域拆分
2. **数据独立**：每个服务独立数据库
3. **团队结构**：符合团队组织架构
4. **技术栈**：统一技术栈，便于维护

**当前系统分析**：
- 现有模块：[列出当前系统模块]
- 依赖关系：[模块间依赖关系]
- 数据关系：[数据表依赖关系]

**拆分策略**：
1. **服务识别**：识别候选微服务
2. **边界定义**：明确服务边界
3. **数据拆分**：设计数据分离方案
4. **通信机制**：设计服务间通信

**技术方案**：
- 服务注册发现：[选择方案]
- 负载均衡：[选择方案]
- 配置管理：[选择方案]
- 监控告警：[选择方案]

**迁移计划**：
1. 分阶段拆分策略
2. 数据迁移方案
3. 风险控制措施
4. 回滚方案

请提供详细的拆分方案和实施计划。

📝 使用说明

提示词使用原则

  1. 选择合适的模板：根据当前开发阶段和任务类型选择对应的提示词模板
  2. 补充具体信息：将模板中的占位符替换为具体的项目信息
  3. 添加上下文：根据需要添加相关的文档路径和业务背景
  4. 明确要求：清晰描述期望的输出和质量要求
  5. 文档同步：强调文档更新的重要性和具体要求

自定义提示词

基于以上模板，开发人员可以根据具体场景进行调整和扩展：

  1. 项目特定信息：添加项目特有的技术栈和规范要求
  2. 团队协作要求：根据团队协作流程调整提示词
  3. 质量标准：根据项目质量要求调整验收标准
  4. 性能要求：根据项目性能目标调整性能相关要求

最佳实践

  1. 逐步细化：从基础提示词开始，逐步添加具体要求
  2. 反馈优化：根据 AI 响应效果优化提示词
  3. 团队共享：将有效的提示词在团队内分享
  4. 持续改进：根据项目发展不断更新和完善提示词

📖 相关文档

🎯 目标：通过标准化的提示词模板，提升 Cursor AI 辅助开发的效率和质量，确保开发过程符合项目规范，实现代码与文档的同步更新。

Reference in new issue View Git Blame Copy Permalink