好的提示词不是“请写代码”，而是带约束、给示例、明确输出格式。

优秀的提示词遵循STAR原则：
Situation——背景：我在做什么项目
Task——任务：具体要干什么
Action——约束：用什么技术、遵循什么规范
Result——输出格式：要代码or解释？加注释or不加？

所以熟悉项目：使用：3 , 8

1. 需求澄清：把模糊需求变成落地文档

适用场景：产品给你一句话，你需要转成详细设计。直接让AI帮你拆解。

提示词模板：
作为后端架构师，请帮我分析这个需求，输出一份技术方案大纲：
{需求原文}
要求：
1. 拆解成用户故事
2. 列出涉及的实体和关系
3. 给出API端点设计（RESTful风格）
4. 指出潜在的技术风险

案例：
需求：用户下单后30分钟未支付，自动取消订单并释放库存。

AI会生成：用户故事 → 订单实体增加status和expire_time字段 → 延时队列/定时扫表方案 → 并发风险、库存超卖风险的讨论。

2. 生成单测：覆盖正常/异常/边界

适用场景：写单元测试又烦又浪费时间，让AI按最佳实践帮你生成。

提示词模板：
为以下Java方法生成JUnit 5单元测试：
{粘贴方法代码}
要求：
- 覆盖正常场景、异常场景、边界场景
- 使用Mockito模拟依赖
- 每个测试方法命名清晰（should_xxx_when_xxx）
- 断言使用assertEquals，并输出失败信息

案例：
public BigDecimal calculateDiscount(BigDecimal amount, int vipLevel) {
if (amount == null || amount.compareTo(BigDecimal.ZERO) <= 0) {
throw new IllegalArgumentException("金额必须大于0");
}
// 业务逻辑...
}

AI生成的测试会包含：amount为null抛异常、amount负数抛异常、vipLevel边界值0和5、正常折扣计算等场景。

3. 代码解释：快速理解复杂逻辑

适用场景：接手老代码，或看开源项目某个方法看不太懂。

提示词模板：
解释下面这段代码的核心逻辑和设计意图：
{代码片段}
请用通俗语言说明：
1. 输入输出是什么
2. 关键步骤（用编号列出）
3. 使用了什么设计模式（若有）
4. 可能的坑或改进点

4. 重构建议：提升代码质量

适用场景：一段“祖传代码”看着难受，又不敢乱动。

提示词模板：
请作为资深Java架构师，审查以下代码并给出重构建议：
{代码片段}
重点关注：
- 违反SOLID原则的地方
- 重复代码
- 可读性问题
- 性能瓶颈
请提供逐条建议，并给出重构后的代码示例。

案例：AI识别出过长方法（超过100行）、多个if-else嵌套、重复的日志处理，建议提取方法、使用策略模式或守卫子句。

-- 排查和优化 --

5. 异常排查：根据堆栈定位问题

适用场景：线上报错，日志一堆，不知道哪里下手。

提示词模板：
以下是应用抛出的异常堆栈，请分析可能的原因并给出排查思路：
{粘贴堆栈}
已知：{补充业务上下文}
请输出：
- 最可能的根本原因
- 需要检查哪几个类（文件名+行号）
- 建议的临时修复和长期方案

案例：NullPointerException 发生在 OrderService.line58，AI根据上下文推断可能是user为null，建议检查user的获取逻辑或增加防御性判空。

6. 性能优化：分析慢接口

适用场景：某个接口响应慢，你怀疑SQL或算法有问题，让AI帮你扫描代码。

提示词模板：
以下是一个Spring Boot接口的实现，请帮我分析性能瓶颈：
{代码}
请特别关注：
- 循环内的数据库查询（N+1）
- 可并行化的地方
- 缓存使用机会
- 大对象/集合的创建
输出优化建议和示例代码。

案例：AI发现在for循环里调用了订单详情查询，建议改成批量查询或使用JOIN一次性取出。

7. 生成SQL与索引建议

适用场景：设计表结构或优化慢SQL。

提示词模板：
需求：{描述查询需求}
表结构：
{CREATE TABLE语句}
请：
1. 写出符合需求的SQL
2. 解释执行计划是否用到了索引
3. 推荐创建哪些索引（B-tree/Hash/复合）
4. 给出分页优化建议（若需要）

案例：AI分析WHERE status = 'PAID' AND create_time BETWEEN '2026-01-01' AND '2026-03-31'，建议创建复合索引(status, create_time)，并提醒覆盖索引可避免回表。

8. 生成结构化知识文档（RAG友好）

适用场景：为项目生成Markdown格式的接口文档或问题记录，方便后续被AI检索（RAG）。

提示词模板：
根据以下需求/代码，生成一份Markdown格式的技术知识文档：
{内容}
请包含：
- 标题和简短介绍
- 关键术语表
- 流程图或时序图（Mermaid格式）
- 示例请求和响应（若API）
- 常见问题与避坑

在hrm2_cp,hrm2_app_aotu,hrm2_web_aotu三个项目中，订单后的保险理赔流程，从买保险开始，从买保险开始到理赔，所有的流程。

9. 设计评审：帮忙找架构设计漏洞

适用场景：你设计了一个方案，想让AI扮演“技术评审”角色。

提示词模板：
你是一位资深的系统架构师。请评审以下设计文档：
{文档或描述}
从以下角度提出问题：
- 可扩展性（未来新增需求会破坏现有设计吗？）
- 高可用（单点故障？降级方案？）
- 数据一致性（是否有并发写冲突？）
- 运维复杂度（部署、监控、扩容）
输出：至少3个疑问点和改进建议。

10. 跨语言翻译：把Python代码转成Java

适用场景：找到一份优秀的Python/Go示例，想转成Java。

提示词模板：
将以下{语言}代码转换成Java代码：
{代码}
要求：
- 使用Java 17+特性（var、record、switch表达式等）
- 保留原逻辑和变量命名风格
- 补充必要的异常处理
- 输出完整类定义

使用技巧与避坑指南

给示例胜过给描述：想让AI输出特定格式的JSON，直接给一个例子最有效。
用分隔符隔离上下文：例如用“— 我是代码 —”标记代码块，避免跟指令混在一起。
一次只问一件事：复合问题分开问，产出的质量和速度更稳。
开启联网搜索：最新API、依赖版本更新，建议让AI先检索网络再回答。
把纠错成本前移：先让AI列出假设再写代码，可以有效降低幻觉风险。

在AI编程时代，“会提问”比“会写代码”更稀缺。

这10个提示词覆盖了程序员日常工作的核心场景，建议收藏下来，下次面对具体任务直接套用。
AI不是魔法，它是你用得越顺手越强的工具。
把提示词打磨好，你就能把时间花在更有价值的架构设计上，而不是重复的增删改查。

-- DEMO --

提示词
1.代码review，检查是否存在明显的bug或错误

2.请为当前打开的项目 app和order 分析“车型保险保障费定价、赔付范围”的需求和逻辑
要求如下：
- 以“车型保险保障费定价、赔付范围的需求和逻辑”为题。
- 详细梳理定价规则和流程。
- 使用表格和 Mermaid 图来展示流程和状态。
- 最后给出一个阅读代码的建议路径。
请用中文输出，以 Markdown 格式组织。

3.请为当前打开的项目 cp,app_aotu,web_aotu 分析“订单后的保险理赔流程，从买保险开始到理赔，所有的流程”的需求和逻辑
要求如下：
- 以“流程系统保险理赔的需求和逻辑”为题。
- 详细梳理保险理赔流程，保险购买，出险，理赔报案阶段，查勘定损阶段，核损处理阶段，费用结算阶段，单证处理阶段，结案处理阶段规则和流程。
- 使用表格和 Mermaid 图来展示流程和状态。
- 最后给出一个阅读代码的建议路径。
请用中文输出，以 Markdown 格式组织。

3.在cp,app_aotu,web_aotu三个项目中，有涉及到外部APP和保险理赔相关的使用吗？如果有，需要罗列出来
- 使用表格和 Mermaid 图来展示流程和状态。
- 最后给出一个阅读代码的建议路径。
请用中文输出，以 Markdown 格式组织。

4.根据以下需求/代码，生成一份Markdown格式的技术知识文档：
在cp,app_aotu,web_aotu三个项目中，订单后的保险理赔流程，从买保险开始，从买保险开始到理赔，所有的流程。
请包含：
- 标题和简短介绍
- 关键术语表
- 流程图或时序图（Mermaid格式）
- 示例请求和响应（若API）
- 常见问题与避坑

5.作为后端架构师，请帮我分析这个需求，输出一份技术方案大纲：

在memberAuth项目中，目前会员认证的第三方服务接口已经停用，需要更换一家新的供应商
要求：
1. 拆解成用户故事
2. 列出涉及的实体和关系
3. 给出API端点设计（RESTful风格）
4. 指出潜在的技术风险

6.为以下Java方法生成JUnit 5单元测试：

app_aotu项目中SendSmsGpsService类中cancelOrder方法
要求：
- 覆盖正常场景、异常场景、边界场景
- 使用Mockito模拟依赖
- 每个测试方法命名清晰（should_xxx_when_xxx）
- 断言使用assertEquals，并输出失败信息

7.解释下面这段代码的核心逻辑和设计意图：

app_aotu项目中SendSmsGpsService类中cancelOrder方法
请用通俗语言说明：
1. 输入输出是什么
2. 关键步骤（用编号列出）
3. 使用了什么设计模式（若有）
4. 可能的坑或改进点

8.请作为资深Java架构师，审查以下代码并给出重构建议：

app_aotu项目中SendSmsGpsService类中cancelOrder方法
重点关注：
- 违反SOLID原则的地方
- 重复代码
- 可读性问题
- 性能瓶颈
请提供逐条建议，并给出重构后的代码示例。