Claude Code 不是聊天机器人——你写的 Prompt 不是"提问"，而是"施工指令"。Prompt 质量直接决定生成代码的质量。本文给出一个简单公式和六个高频场景模板。

---

一个公式：四要素 Prompt

[做什么] + [在哪做] + [按什么规范做] + [做完怎么验证]

对比一下：

# 差：模糊，Claude 不知道你想要什么
> 加个搜索功能

# 好：四要素齐全
> 在 UserController 里加一个分页查询接口。
  支持按 username 模糊搜索和 status 精确筛选。
  参照 DeptController 的代码风格。
  做完跑 mvn test -Dtest=UserControllerTest 验证。

差的 Prompt 给 Claude 的是"开放式作文题"——它能发挥但方向可能不对。好的 Prompt 给的是"施工图"——它只需要照着做。

"做完跑测试验证"这点特别重要——它让 Claude Code 有机会自我纠正。测试失败了自己分析原因自己修，你不用盯着屏幕。

---

六个高频场景模板

1. 生成完整 CRUD

为 [表名] 表生成一套完整的 CRUD。
包括：Entity、Mapper、Service、ServiceImpl、Controller、
SaveDTO、UpdateDTO、QueryDTO、VO。
参照 [已有 Controller] 的代码风格。
做完跑 mvn test 验证。

2. 只加一个接口

在 [Controller] 里加一个 [功能] 接口。
接口路径 [POST/GET] [路径]。
入参：[字段描述]，出参：[字段描述]。
参照 Controller 里已有的接口风格。

3. 排查 Bug（有堆栈）

线上出现这个异常，帮我排查并修复。
异常堆栈：[粘贴完整堆栈]
相关代码在 [文件:行号]。
这个问题在 [什么条件下] 出现。

4. 排查 Bug（不确定原因）

[接口/功能] 偶尔报错，没有稳定复现条件。
以下是近两天的日志记录：[贴日志]
帮我分析可能的原因，不用急着改代码。

5. Code Review

Review 我未提交的代码变更。
重点看：空指针风险、事务边界、SQL 注入、异常处理。
输出按严重程度分类。

6. 代码重构

[方法名] 太长了，[N] 行，帮我拆成小方法。
先从"写测试"开始——先确保现有行为被测试覆盖。
然后再逐步拆分，每拆一步就跑一次测试。

---

五个最常见错误

错误	例子	正确做法
太模糊	“帮我优化一下”	说清方向：性能？可读性？拆分？
一次要太多	“重构整个订单模块”	拆成小任务，一个一个来
不给参照	“写个 Controller”	指定"参照 UserController 风格"
不写验收标准	“帮我改完”	加上"做完跑测试"或"检查输出"
规范写 Prompt 里	每次说"别用 @Autowired"	写到 CLAUDE.md，一劳永逸

---

进阶技巧

先计划再执行

涉及 3 个以上文件的修改，先让 AI 出计划：

/plan
把 OrderService.createOrder() 拆成小方法，不要改变业务逻辑。

审核计划通过后再让它动手。这比直接改然后返工效率高得多。

先写测试再重构

先为 createOrder 写单元测试，覆盖所有分支。
测试全部通过后再开始重构。
每提取一个方法就跑一次测试，确保每次都通过。

有了测试保护，重构坏了自己会修，不需要你盯着。

用 /btw 旁路提问

/btw Java 中 Stream 的 peek 和 map 有什么区别

/btw 后面的内容不进入主对话上下文，不会浪费 token 窗口。适合主任务中途临时查一个技术问题。

---

总结

1. 套公式：做什么 + 在哪做 + 按什么规范 + 怎么验证
2. 给参照：每次指定"参照 xxx 的风格"
3. 加验证：Prompt 末尾加上"做完跑测试"
4. 规范写 CLAUDE.md：不要在 Prompt 里重复纠正同样的规范问题
5. 大任务先 /plan：审核方案再动手，避免返工

---

系列文章：

• 第一篇：用 CC Switch 接入 DeepSeek，API 费用降低 90%
• 第二篇：CLAUDE.md 写法详解
• 第三篇：10 个必学斜杠命令
• 第四篇：2026 安装教程（原生安装器）
• 第五篇：第一次对话——5 个实战场景
• 第六篇（本文）：Prompt 公式与模板