程序员必备 AI Prompt 模板：Java / Spring Boot / MySQL 场景合集

Updated on in ai

为什么我要写一篇 Prompt 模板合集

我用 AI 辅助开发大概两年了，从最早 ChatGPT 到现在 Claude Code、DeepSeek、GLM 切着用。我发现一个规律：真正提升效率的不是哪个模型更聪明，而是你手里有没有一套经过验证的、能直接抄的 Prompt 模板。

每次新需求来了，我不想再从零想"这次该怎么问"。所以我把自己高频用到的场景固化成了下面这套模板，都是 Java / Spring Boot / MySQL / Redis 这套我每天都在摸的技术栈。

（实测）这套模板我用了大半年，覆盖了 CRUD、SQL 优化、单元测试、异常排查、代码审查、缓存设计这些日常 80% 的场景。你直接抄，改改表名、字段名就能用。

这篇是 2026 AI 编程工具与大模型终极指南 的 Cluster 文章。如果你想先理解"为什么这么写 prompt"，建议先看 DeepSeek 高级用法：10 个 Prompt 技巧，这篇是它的落地版。

通用骨架

每个模板都遵循这个结构，你照着填就行：

【角色】你是 X 年经验的 Java 后端工程师
【上下文】技术栈 + 相关表结构 / 现有代码
【任务】具体要做什么
【约束】输出格式、不要什么、关键注意事项

记住一句话：上下文给得越具体，AI 翻车概率越低。

模板 1：根据表结构生成实体类 + DTO

我最常用的一招。建完表后，让 AI 一次性把 Entity、VO、DTO 都生成好。

你是一个 10 年经验的 Java 后端工程师。
【上下文】Spring Boot 3.2 + MyBatis-Plus 3.5 项目，Java 17。
表结构：
CREATE TABLE t_order (
  id BIGINT PRIMARY KEY COMMENT '订单ID',
  order_no VARCHAR(32) NOT NULL COMMENT '订单号',
  user_id BIGINT NOT NULL COMMENT '用户ID',
  amount DECIMAL(10,2) NOT NULL COMMENT '金额',
  status TINYINT NOT NULL COMMENT '状态:0待支付,1已支付,2已取消',
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

【任务】生成：


    

  1. Order 实体类（@TableName、字段映射、status 用枚举）
    2. 

  2. OrderVO（对外返回，隐藏 userId）
    3. 

  3. OrderCreateDTO（创建请求，带 jakarta.validation 校验注解）
    4. 

  4. OrderQueryDTO（分页查询，含分页参数）
    5. 



【约束】


    

  • 用 Lombok 注解
    • 

  • 金额用 BigDecimal，不要 double
    • 

  • 状态字段用枚举 OrderStatus 映射 TINYINT
    • 

  • 只输出代码，不要解释

（实测）要点：强调 BigDecimal、枚举映射这两条，否则它默认给你 double 和裸 Integer，上线就是隐患。

模板 2：慢 SQL 优化

DBA 找上门"这条 SQL 慢了"，你不会调，就交给 AI。

你是一个 MySQL 性能优化专家。

【上下文】MySQL 8.0，表 orders 约 2000 万行，已有索引：

idx_user_created (user_id, created_at)

idx_status (status)


慢 SQL：

SELECT * FROM orders

WHERE DATE(created_at) = '2026-07-10'

AND status = 1

ORDER BY created_at DESC

LIMIT 20;


EXPLAIN 结果：

type=ALL，key=NULL，rows=18900000


【任务】


    

  1. 指出这条 SQL 的核心问题（为什么没用上索引）
    2. 

  2. 给出改写后的 SQL
    3. 

  3. 说明是否需要新增索引，新增的话索引该怎么建
    4. 

  4. 量化预期提升
    5. 



【约束】改写后的 SQL 要保持结果集一致，别改查询语义。

（实测）关键提示是"DATE(created_at) 函数导致索引失效"——AI 通常能准确指出这一点并给出范围查询改写。这个模板我基本每周用一两次，省了我翻执行计划的时间。

模板 3：写单元测试

最省时间的场景。给一段实现代码，让它补 JUnit5 + Mockito 测试。

你是 Java 单元测试专家。

【上下文】JUnit 5.9 + Mockito 4.11 + Spring Boot Test。

下面是 OrderService.refund 方法：


（粘贴你的方法代码）


【任务】为 refund 写单元测试，覆盖：


    

  1. 正常退款成功
    2. 

  2. 订单不存在
    3. 

  3. 订单状态不允许退款（已取消）
    4. 

  4. 退款金额超过原金额
    5. 

  5. 调用支付网关失败时回滚
    6. 



【约束】


    

  • 用 @ExtendWith(MockitoExtension.class)
    • 

  • 不要起 Spring 容器（不写 @SpringBootTest）
    • 

  • 用 verify 断言交互，用 assertJ 做结果断言
    • 

  • 异常场景用 assertThrows
    • 

  • 每个 @Test 方法名用中文描述场景，如 退款金额超过原金额时应抛异常()

（实测）要求"方法名用中文"是灵机一动加的，后来发现中文方法名在测试报告里可读性极好，团队 review 时一眼看懂每个用例测什么。Mockito 不起容器这一点也重要，否则测试跑得慢。

模板 4：报错堆栈排查

线上告警贴过来，直接喂给 AI。

你是 Java/Spring Boot 排障专家。

【上下文】


    

  • Spring Boot 2.7（团队老项目），JDK 8
    • 

  • 现象：高并发下接口偶发 500
    • 

  • 报错堆栈：
    • 



（粘贴完整堆栈）


【任务】


    

  1. 用一句话说清根因
    2. 

  2. 拆解：这个问题在什么条件下触发
    3. 

  3. 给出修复方案，分临时止血和根本修复两类
    4. 

  4. 指出怎么验证修复有效
    5. 



【约束】如果是框架层 bug（如 Hibernate），给出对应版本号和升级建议，别让我瞎升。

（实测）这个模板救过我一次夜班——HikariCP 连接泄漏的堆栈，它直接定位到是某处 @Transactional 套了 RPC 调用导致连接占用时间过长。临时止血调连接池参数，根本修复是去掉事务里的远程调用。

模板 5：Code Review

提交前让 AI 当 reviewer。

你是资深 Code Reviewer，标准参考阿里 Java 开发手册。

【上下文】

（粘贴待 review 的代码）


【任务】按这几个维度审查：


    

  1. 正确性：逻辑 bug、边界、空指针
    2. 

  2. 性能：N+1、循环里查库、不必要的对象创建
    3. 

  3. 并发：线程安全、锁粒度
    4. 

  4. 健壮性：异常处理、参数校验
    5. 

  5. 可读性：命名、方法长度
    6. 



【约束】


    

  • 每个问题标明严重等级：🔴阻塞 / 🟡建议 / 🟢可选
    • 

  • 不要夸"代码写得好"，只说问题
    • 

  • 最后给修订后的完整代码

（实测）"不要夸代码写得好，只说问题"这一句能省掉一堆客套话。让 AI 按严重等级分级也很实用，我通常只看 🔴 阻塞项。

模板 6：REST API 设计 + 参数校验

设计新接口时用。

你是一个 RESTful API 设计专家。

【上下文】用户积分模块，需要设计：


    

  1. 查询用户积分
    2. 

  2. 积分扣减（下单消费）
    3. 

  3. 积分流水查询（分页）
    4. 



【任务】为这 3 个接口设计：


    

  • HTTP 方法 + URL 路径（符合 RESTful）
    • 

  • 请求参数（DTO，带 validation 注解）
    • 

  • 响应结构（统一包装 Result<T>）
    • 

  • 关键错误码
    • 



【约束】


    

  • 扣减接口要考虑幂等（前端可能重试）
    • 

  • 路径用复数名词，版本前缀 /api/v1
    • 

  • 列出每个接口的 HTTP 状态码使用规范

（实测）要求"考虑幂等"这个点，会让它主动给 idempotency-key 方案，这点我一开始老忘，AI 提醒后才补上。

模板 7：Redis 缓存设计

缓存不是 set 一下就完事，防穿透、防击穿、一致性都得想。

你是 Redis 缓存架构专家。

【上下文】商品详情接口，QPS 峰值约 3000，MySQL 扛不住。

读多写少，商品数据由后台管理系统更新。


【任务】设计缓存方案：


    

  1. 缓存 key 结构和数据结构选型
    2. 

  2. 缓存穿透防护（不存在的 key）
    3. 

  3. 缓存击穿防护（热点 key 过期）
    4. 

  4. 缓存与 DB 一致性策略（更新商品时怎么处理缓存）
    5. 

  5. 给出 Java 伪代码（用 Redisson）
    6. 



【约束】


    

  • 一致性方案要说明选"延迟双删"还是"Canal 订阅 binlog"，并说理由
    • 

  • 别给"先更新库再删缓存"然后不处理删失败的情况

（实测）最后那条约束很关键，AI 默认会给"更新库→删缓存"，但不处理删失败就等于没做一致性。逼它说清楚失败补偿，方案才完整。

模板 8：Docker Compose 部署配置

本地起一套开发环境。

你是 DevOps 工程师。

【上下文】本地开发环境，需要起：


    

  • MySQL 8.0
    • 

  • Redis 7
    • 

  • Spring Boot 应用（jar 包在 ./target/app.jar）
    • 



【任务】写 docker-compose.yml：


    

  1. 三个服务 + 自定义网络
    2. 

  2. MySQL 挂载数据卷 + 初始化 SQL
    3. 

  3. Redis 配置密码
    4. 

  4. 应用依赖 mysql 和 redis 健康检查后启动
    5. 

  5. 端口映射：MySQL 3306、Redis 6379、App 8080
    6. 



【约束】


    

  • 用 healthcheck 做依赖管理，不要用 depends_on 的简单形式
    • 

  • 给出 .env 文件示例
    • 

  • 注释说明每个配置项的作用

（实测）要求"用 healthcheck 不用简单 depends_on"是踩过坑——depends_on 只保证容器启动，不保证服务就绪，应用起来时 MySQL 还没 ready 就连接失败。加 healthcheck 才对。

模板 9：MyBatis-Plus 复杂查询

MP 的 LambdaQuery 写复杂条件容易乱。

你是 MyBatis-Plus 专家。

【上下文】Entity 是 Order，需要查询：


    

  • 状态为"已支付"
    • 

  • 创建时间在最近 7 天
    • 

  • 金额大于 100
    • 

  • 按创建时间倒序，分页第 2 页每页 20 条
    • 



【任务】用 LambdaQueryWrapper 写这段查询，并说明：


    

  1. 哪些条件适合放数据库查，哪些可以放内存过滤
    2. 

  2. 这个查询有没有索引使用建议
    3. 



【约束】不要用 XML 写 SQL，只用 LambdaQueryWrapper 链式 API。

（实测）让它顺带说"哪些适合库查哪些适合内存过滤"很有用——它常常会建议把枚举映射这种轻量转换放内存，减少 SQL 复杂度。

模板 10：异常类设计

业务系统总缺一套统一的异常体系。

你是 Java 架构师。

【上下文】Spring Boot 3 项目，目前业务代码里到处是 throw new RuntimeException("xxx")，

没有统一异常体系，前端拿不到统一错误码。


【任务】设计一套业务异常体系：


    

  1. 基础 BizException + 错误码枚举
    2. 

  2. 3-4 个典型子类（参数异常、权限异常、资源不存在、限流）
    3. 

  3. 全局异常处理器 @RestControllerAdvice，统一返回结构
    4. 

  4. 给出使用示例
    5. 



【约束】


    

  • 错误码用 int，分段规划（如 1xxxx 参数类，2xxxx 权限类）
    • 

  • 异常要带业务上下文，不能只有一个 message
    • 

  • 全局处理器要区分业务异常和系统异常，系统异常不能把堆栈抛给前端

（实测）"系统异常不能把堆栈抛给前端"这条约束很重要，否则生产环境分分钟信息泄露。错误码分段这个建议也是 AI 给的，我之前自己设计都是乱编号。

用这套模板的正确姿势

观点：模板是脚手架，不是越界护栏。

  • 改，别照抄：每个模板里的上下文（表名、字段、版本号）必须换成你真实的。AI 不知道你的项目，喂假上下文等于让它编。
  • 分轮，别一锅端：复杂需求拆成多轮，每轮聚焦一个目标，效果比一次性全塞进去好得多。
  • 让它先反问：模板末尾加一句"有模糊处先问我"，能避免它硬猜方向。
  • 结果要校验：AI 给的代码，尤其涉及事务、并发、SQL 的，必须自己过一遍。它写的 SQL 有时候语义对、性能差，得审。

这套模板我会持续补充。如果你更关心"怎么用 AI 编程工具本身"而不是写 prompt，可以看 Claude Code 深度评测，那篇讲的是直接用 AI 编辑器干活，和这篇的"对话式 prompt"是两种不同打法，各有场景。

附：10 个模板速查

# 场景 模板核心
1 实体类+DTO 生成 给 DDL，强调 BigDecimal 和枚举映射
2 慢 SQL 优化 喂 SQL+EXPLAIN，逼它量化提升
3 单元测试 覆盖正常+异常，方法名用中文
4 报错排查 喂堆栈，要"止血+根本修复"两层方案
5 Code Review 按严重等级分级，禁止夸奖
6 REST API 设计 强制考虑幂等
7 Redis 缓存 逼它说一致性失败的补偿
8 Docker Compose 用 healthcheck 不用裸 depends_on
9 MyBatis-Plus 查询 区分库查 vs 内存过滤
10 异常类设计 错误码分段，系统异常不抛堆栈
↑ ↓