794 lines
20 KiB
Markdown
794 lines
20 KiB
Markdown
# Cursor AI 提示词模板指南
|
||
|
||
> 🎯 **文档目的**：为开发人员提供标准化的 Cursor AI 提示词模板，确保高效的 AI 辅助开发和文档管理
|
||
|
||
## 📋 目录
|
||
|
||
- [新功能开发提示词](#新功能开发提示词)
|
||
- [代码重构优化提示词](#代码重构优化提示词)
|
||
- [Bug 修复提示词](#bug修复提示词)
|
||
- [文档更新提示词](#文档更新提示词)
|
||
- [代码审查提示词](#代码审查提示词)
|
||
- [API 开发提示词](#api开发提示词)
|
||
- [数据库设计提示词](#数据库设计提示词)
|
||
- [测试编写提示词](#测试编写提示词)
|
||
- [问题排查提示词](#问题排查提示词)
|
||
- [架构设计提示词](#架构设计提示词)
|
||
|
||
---
|
||
|
||
## 🆕 新功能开发提示词
|
||
|
||
### 基础新功能开发
|
||
|
||
```
|
||
基于以下业务需求开发 [功能名称]：
|
||
|
||
**业务上下文**：
|
||
- 业务需求：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. **持续改进**：根据项目发展不断更新和完善提示词
|
||
|
||
---
|
||
|
||
## 📖 相关文档
|
||
|
||
- **项目总览**：[docs/项目总览/README.md](docs/项目总览/README.md)
|
||
- **开发文档**：[docs/开发文档/README.md](docs/开发文档/README.md)
|
||
- **业务模块**：[docs/业务模块/README.md](docs/业务模块/README.md)
|
||
- **变更管理**：[docs/变更管理/README.md](docs/变更管理/README.md)
|
||
- **Cursor 规则**：[.cursorrules](.cursorrules)
|
||
|
||
---
|
||
|
||
**🎯 目标**：通过标准化的提示词模板，提升 Cursor AI 辅助开发的效率和质量，确保开发过程符合项目规范，实现代码与文档的同步更新。
|