一套**「工程级、可控、不翻车」的 Cursor 专用提示词**，专门用于：
在不破坏核心逻辑 & API 规范的前提下，提升 Spring Boot 项目的高并发、高可用能力
一、使用前的"正确姿势"（很重要，先看）
在 Cursor 里：
-
打开项目根目录
-
模型选择：
- 第一次分析：👉 Claude Opus
- 后续局部优化：👉 Claude Sonnet
-
第一次一定只让它"分析"，不要直接改代码
二、第一阶段：系统级分析 Prompt（必做）
👉 先用这个 【只分析，不改代码】 的提示词：
你现在是一名资深 Java 后端架构师，擅长高并发与高可用系统设计。
请先不要修改任何代码，仅基于当前 Spring Boot 项目进行分析，重点关注：
1. 在高并发场景下可能存在的瓶颈（线程、锁、IO、数据库、缓存）
2. 是否存在潜在的并发安全问题（共享状态、静态变量、非线程安全组件）
3. 在高可用层面存在的风险（单点、超时、重试、降级、熔断缺失等）
4. 事务使用是否可能在高并发下放大性能问题
5. 接口层是否存在可能被恶意或突发流量击穿的风险
请：
- 按「严重程度」排序问题
- 标注涉及的模块 / 类
- 给出"优化思路"，不要直接给代码📌 这一步的目标：
- 判断 Claude 是否真的"懂并发"
- 你先当 Reviewer
三、第二阶段：制定"安全改造范围"（关键防翻车）
分析结束后，用这个 Prompt 框住它的手 👇
接下来我们将对项目做高并发 / 高可用方向的改造，请严格遵守以下约束：
1. 不允许修改任何对外 API 的：
- URL
- 请求 / 响应结构
- 语义行为
2. 不允许改变核心业务逻辑与业务规则
3. 不允许引入破坏性架构调整（如大规模重写）
4. 所有改造必须是：
- 可逐步上线
- 可回滚
5. 优先使用 Spring Boot / Java 生态的成熟方案
在这个前提下，请给出一个【分阶段改造方案】，每个阶段说明：
- 目标
- 涉及模块
- 风险点
- 回滚方式📌 这一步：
直接把 AI 拉回"工程现实"
四、第三阶段：逐点落地改造 Prompt（最常用）
当你选定某一项（比如线程池、缓存、限流）后，用下面的模板。
示例 1：线程池 / 异步改造
请针对当前项目的线程使用情况进行优化，重点关注：
1. 是否存在使用默认线程池的风险
2. 是否存在阻塞操作占用业务线程的问题
3. 线程池参数是否适合高并发场景
在不改变现有业务逻辑的前提下：
- 建议合理的线程池拆分方案
- 明确每个线程池的使用场景
- 给出代码级改造建议（可生成 diff）示例 2：接口限流 / 保护
请分析当前 Controller 层接口在高并发或突发流量下的风险。
在不修改接口定义和业务语义的前提下：
1. 建议合适的限流策略（如本地限流、分布式限流）
2. 说明限流粒度与位置（Controller / Service）
3. 给出可配置、可开关的实现方式
4. 不要影响正常用户体验
请先给设计思路，再给代码改造示例示例 3：数据库与事务优化
请分析当前 Service 层事务使用情况，在高并发场景下是否存在：
- 事务范围过大
- 读写混用
- 不必要的事务嵌套
在不改变业务行为的前提下：
- 给出事务收敛与优化建议
- 指出可以安全拆分或下沉的点
- 生成最小改动的代码 diff五、第四阶段：让 Claude 自己"做风险自检"（高级技巧）
这是很多人不知道的用法👇
请你以 Code Review 的视角，审查刚才提出的高并发 / 高可用改造方案，重点检查：
1. 是否存在过度设计
2. 是否引入新的并发风险
3. 是否可能影响现有接口语义
4. 在真实生产环境中可能踩的坑
请指出你最不放心的 3 个地方📌 这一步：
用 AI 打 AI
六、一个"总控 Prompt"（可以长期复用）
可以把下面这个存成 Cursor Snippet：
你是资深 Java 架构师。
目标：在不影响核心业务逻辑和现有 API 规范的前提下，
提升 Spring Boot 项目的高并发与高可用能力。
约束：
- 不改对外接口
- 不改业务语义
- 改造必须可回滚
- 优先最小侵入方案
流程：
1. 先分析问题（不改代码）
2. 给分阶段方案
3. 单点改造时先给思路再给 diff
4. 每次改造后自检风险
请严格按上述流程执行。七、一句很重要的话
真正的高手用 AI，不是让它"放开改"，而是"被约束地改"