让你的Claude Code从"能用"到"能打"的AI提示词实战

写给Java/Spring Boot开发者的Claude Code提示词工程指南

---

一、背景：为什么单独聊Claude Code的提示词？

2026年了，AI编程工具已经像IDE一样成了开发者的标配。但你有没有发现一个现象——

同一个需求，隔壁工位的老张问AI三分钟搞定，代码规范、异常处理、单测全齐；你问AI，来回改了五六轮，最后还不如自己写。

差别不在智商，在"怎么问"。

很多人把ChatGPT那套"帮我写个XXX"的问法直接搬到了Claude Code上，结果发现效果大打折扣。这就像你拿着一把瑞士军刀，却只用来削苹果——不是刀不行，是你没用对场景。

Claude Code和普通聊天AI最大的区别是什么？

它不是一个"对话窗口"，而是一个能读你项目文件、能执行命令、能改你代码的终端助手。它能直接看到你的pom.xml、你的application.yml、你的整个包结构。这意味着你不需要每次都从头描述技术栈——但前提是你得"告诉"它你的项目规矩。

打个比方：普通AI像电话咨询医生，你得描述半天症状；Claude Code像医生直接翻你的病历本，但你得先把病历本整理好。

这篇文章就来聊聊：怎么把Claude Code从一个"能用"的工具，变成你手里的"能打"的开发搭档。内容全部围绕Java + Spring Boot场景展开，拿来就能用。

---

二、问题：你是不是也踩过这些坑？

先说几个我自己和身边同事经常遇到的情况，看看你中了几条：

2.1 “它写的代码跟我项目风格完全不搭”

你让它写个Service方法，它给你来个public字段直接暴露、没用BigDecimal处理金额、异常直接catch(Exception e)一把梭……功能倒是能跑，但Code Review的时候同事看了直摇头。

根因：AI不知道你们团队的编码规范。你没说，它就按"最大公约数"来。

2.2 “每次都要重复说一遍项目背景”

你是Spring Boot 3.x + JDK 17 + MyBatis-Plus的项目，每次新对话都得重新说一遍。更烦的是，你上次让它用的Lombok、统一返回格式Result<T>，这次它又忘了。

根因：普通对话没有"记忆"，每次都是从零开始。

2.3 “提示词写了一大段，AI还是理解偏了”

你想要一个带分页的列表查询接口，结果它给你生成了一堆if-else判断，连PageHelper都没用。你明明在提示词里写了"用MyBatis-Plus"，它还是按JPA的思路来。

根因：提示词缺少约束条件和输出格式的明确约定。

2.4 “让它改代码，改着改着把别的功能改坏了”

让AI重构一个方法，它顺手把你旁边没动过的代码也"优化"了，结果编译都过不了。

根因：没有明确告诉AI的改动范围和边界。

---

三、方案：构建你的Claude Code提示词体系

3.1 核心思路：STAR原则 + CLAUDE.md

解决问题的关键有两层：

第一层：给AI一本"项目说明书"（CLAUDE.md）

Claude Code有一个杀手级特性——它会在每次对话时自动读取项目根目录下的CLAUDE.md文件。这相当于给AI一份"长期记忆"，告诉它你的项目是什么技术栈、遵循什么规范、有什么约定。

第二层：用结构化的方式提问（STAR原则）

每次提问时，按STAR原则组织语言：

要素	含义	举例
Situation（背景）	你在做什么项目	“这是一个Spring Boot 3.x的订单管理系统”
Task（任务）	具体要干什么	“需要一个订单超时自动取消的功能”
Action（约束）	用什么技术、遵循什么规范	“用Redis延时队列实现，遵循阿里巴巴Java规范”
Result（输出格式）	要代码还是解释？加不加注释？	“输出完整代码，包含Javadoc注释”

打个比方：STAR原则就像你去餐厅点菜——“我在吃川菜（背景），要一份水煮鱼（任务），微辣不要香菜（约束），打包带走（输出格式）”。而不是只说"来个菜"。

3.2 CLAUDE.md 配置实战（Java/Spring Boot专用）

在你的项目根目录下创建CLAUDE.md文件，这是你的"AI项目手册"。下面是一份经过实战验证的模板：

# 项目概述

这是一个基于Spring Boot的企业级管理系统，用于混凝土拌和站的智能监控。

## 技术栈

- JDK 17
- Spring Boot 3.2.x
- MyBatis-Plus 3.5.x
- MySQL 8.0
- Redis 7.x
- Maven 构建

## 编码规范

- 统一返回格式：Result<T>，包含code、message、data三个字段
- 异常处理：使用全局异常处理器（@RestControllerAdvice），业务异常用BusinessException
- 金额相关字段一律使用BigDecimal，禁止使用double/float
- 日期字段使用LocalDateTime，禁止使用Date
- 所有Service方法必须添加事务注解（@Transactional）
- 使用Lombok简化POJO，但禁止使用@Data（用@Getter/@Setter代替）
- 分页查询统一使用MyBatis-Plus的IPage

## 包结构约定

- controller  —— 接口层，只做参数校验和调用Service
- service     —— 业务逻辑层
- mapper      —— 数据访问层（MyBatis-Plus BaseMapper）
- entity      —— 数据库实体
- dto         —— 数据传输对象
- vo          —— 视图对象（返回给前端）
- config      —— 配置类
- exception   —— 自定义异常
- util        —— 工具类

## 命名规范

- 数据库表名：t_前缀 + 下划线命名（如 t_order_detail）
- Java类名：大驼峰（如 OrderDetail）
- 方法名：小驼峰（如 getOrderList）
- 常量：全大写下划线（如 MAX_RETRY_COUNT）

## 其他约定

- 接口路径统一使用 /api/ 前缀
- 所有接口必须有Swagger注解（@Tag、@Operation）
- 禁止在Controller中直接写业务逻辑
- SQL语句优先写在Mapper XML中，简单CRUD用MyBatis-Plus内置方法

为什么这份配置很重要？

有了它之后，你再让Claude Code写代码，它会自动遵循这些规范。你不需要每次都提醒"用BigDecimal"、“返回Result”——就像新来的同事看完项目文档就知道该怎么写代码一样。

3.3 提问的三层金字塔

我把提示词的使用分成了三个层次，从基础到高级逐步提升：

        ┌─────────────┐
        │  第三层：体系 │  ← CLAUDE.md + 自定义命令 + 工作流
        │  （长期记忆）  │
        ├─────────────┤
        │  第二层：模板 │  ← 结构化提示词模板，覆盖常见场景
        │  （即拿即用）  │
        ├─────────────┤
        │  第一层：直觉 │  ← "帮我写个接口"
        │  （能用但不好用）│
        └─────────────┘

大多数开发者停留在第一层，这篇文章帮你直接跳到第二层和第三层。

---

四、实现：10个Java/Spring Boot高频场景的提示词模板

下面是我整理的10个实战场景，每个都给出了提示词模板和Spring Boot项目中的具体案例。这些模板不需要死记硬背，理解结构之后可以灵活调整。

---

场景1：需求澄清——把一句话需求变成技术方案

痛点：产品说"加个功能"，你得自己想半天怎么做。

提示词模板：

作为Spring Boot后端架构师，请帮我分析以下需求，输出一份技术方案大纲：

需求：{需求原文}

要求：
1. 拆解成用户故事（As a... I want... So that...）
2. 列出涉及的数据库表和字段变更
3. 给出RESTful API端点设计（路径、方法、参数、返回值）
4. 指出潜在的技术风险和并发问题
5. 推荐使用的Spring组件或中间件

实战案例：

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

要求：
1. 拆解成用户故事
2. 列出涉及的数据库表和字段变更
3. 给出RESTful API端点设计
4. 指出潜在的技术风险
5. 推荐使用的Spring组件

Claude Code会输出：用户故事 → t_order表增加status和expire_time字段 → 延时队列（Redisson的RTopic或RocketMQ延时消息）方案对比 → 并发下单时库存超卖的处理策略 → 完整的API端点设计。

为什么好用：它不只是给代码，而是帮你"想清楚"。在动手写代码之前，先用这个模板过一遍，能省掉后面大量的返工。

---

场景2：代码生成——从接口到实现一条龙

痛点：写CRUD接口太枯燥，但手写又慢，复制粘贴容易出错。

提示词模板：

请为以下实体类生成完整的Spring Boot接口代码：

实体类：{粘贴实体类代码或描述字段}

要求：
1. 生成Entity（使用Lombok的@Getter/@Setter，不要用@Data）
2. 生成DTO（创建用CreateDTO，更新用UpdateDTO，查询用QueryDTO）
3. 生成VO（返回给前端的视图对象）
4. 生成Controller（使用@RestController，包含Swagger注解）
5. 生成Service接口和实现类
6. 生成Mapper接口（继承BaseMapper）
7. 统一使用Result<T>返回格式
8. 查询接口支持分页（使用IPage）
9. 添加参数校验（@Valid + @NotNull等）

实战案例：

请为以下实体类生成完整的Spring Boot接口代码：

实体类：设备检测记录（DeviceInspect）
- id: Long（主键，自增）
- deviceId: Long（设备ID，非空）
- inspectDate: LocalDate（检测日期）
- result: Integer（检测结果：1合格/2不合格）
- remark: String（备注，最大200字）
- createTime: LocalDateTime
- updateTime: LocalDateTime

要求：
1. 生成Entity/DTO/VO/Controller/Service/Mapper全套
2. 查询接口支持按deviceId和日期范围筛选
3. 包含批量删除接口
4. 添加Swagger注解

关键技巧：把你的Result<T>、BaseEntity等通用类的代码也贴给Claude Code，它生成的代码就能直接融入你的项目结构。

---

场景3：性能优化——揪出慢接口的元凶

痛点：接口响应慢，你怀疑是SQL的问题，但又不确定。

提示词模板：

以下是一个Spring Boot接口的实现代码，请帮我分析性能瓶颈：

{粘贴代码}

请重点关注：
1. 循环内的数据库查询（N+1问题）
2. 不必要的大对象/集合创建
3. 可以并行化处理的地方
4. 缓存使用的机会（@Cacheable / RedisTemplate）
5. SQL层面的优化建议（索引、分页、JOIN）

请给出：
- 每个问题的具体位置（行号）
- 优化前后的代码对比
- 预期的性能提升幅度（量级估算）

实战案例：

你有一个订单列表查询接口，100条数据要3秒。Claude Code扫描后告诉你：

• 问题1：for循环里逐条查询订单详情，100条数据触发了100次SQL → 改成IN批量查询
• 问题2：每次都查用户信息，没用缓存 → 加@Cacheable注解，用Redis缓存用户信息
• 问题3：SELECT * 查了所有字段，包括大文本字段 → 改成指定字段查询

优化后：3秒 → 200毫秒，提升15倍。

---

场景4：异常排查——根据堆栈快速定位问题

痛点：线上报错，日志一堆，不知道从哪下手。

提示词模板：

以下是Spring Boot应用抛出的异常堆栈，请帮我分析：

{粘贴完整堆栈信息}

项目上下文：
- 框架：Spring Boot 3.x + MyBatis-Plus
- 数据库：MySQL 8.0
- 相关业务：{简述业务场景}

请输出：
1. 最可能的根本原因（不要只说NPE，要分析为什么是null）
2. 需要检查的具体类和行号
3. 建议的临时修复方案（快速止血）
4. 建议的长期修复方案（根治）
5. 如何添加防御性代码避免类似问题

实战案例：

异常堆栈：
java.lang.NullPointerException: Cannot invoke "java.lang.Long.longValue()"
because the return value of "com.xxx.entity.Order.getUserId()" is null
    at com.xxx.service.impl.OrderServiceImpl.cancelOrder(OrderServiceImpl.java:58)
    at com.xxx.controller.OrderController.cancel(OrderController.java:32)

项目上下文：
- Spring Boot 3.x + MyBatis-Plus
- 相关业务：订单取消功能

Claude Code会分析：可能是订单创建时userId未正确赋值，或者查询订单时关联的用户已被删除。建议检查订单创建逻辑，并在cancelOrder方法入口增加防御性判空。

---

场景5：单元测试——告别"测不动"的借口

痛点：写单测又烦又耗时间，覆盖率上不去。

提示词模板：

为以下Spring Boot Service方法生成JUnit 5单元测试：

{粘贴方法代码}

要求：
1. 使用JUnit 5 + Mockito
2. 覆盖以下场景：
   - 正常流程（Happy Path）
   - 参数为null的场景
   - 边界值（0、负数、超大值）
   - 业务异常场景（如订单不存在、状态不符）
   - 外部依赖抛异常的场景（如数据库连接失败）
3. 测试方法命名格式：should_{预期结果}_when_{条件}
4. 使用@MockBean模拟Mapper和外部依赖
5. 每个测试方法添加中文注释说明测试目的
6. 断言要包含失败提示信息

实战案例：

为以下方法生成单元测试：

public OrderVO createOrder(CreateOrderDTO dto) {
    // 1. 校验用户是否存在
    User user = userMapper.selectById(dto.getUserId());
    if (user == null) {
        throw new BusinessException("用户不存在");
    }
    // 2. 校验商品库存
    Product product = productMapper.selectById(dto.getProductId());
    if (product.getStock() < dto.getQuantity()) {
        throw new BusinessException("库存不足");
    }
    // 3. 创建订单
    Order order = new Order();
    BeanUtils.copyProperties(dto, order);
    order.setStatus(0);
    order.setCreateTime(LocalDateTime.now());
    orderMapper.insert(order);
    // 4. 扣减库存
    product.setStock(product.getStock() - dto.getQuantity());
    productMapper.updateById(product);
    return convertToVO(order);
}

Claude Code会生成6-8个测试用例：用户不存在抛异常、库存不足抛异常、正常创建订单、验证库存扣减、验证订单状态设置、验证返回值不为null等。每个用例都有清晰的注释和断言。

---

场景6：代码重构——给"祖传代码"做手术

痛点：接手了一段"祖传代码"，看着难受，又不敢乱动。

提示词模板：

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

{粘贴代码}

重点关注：
1. 是否违反SOLID原则
2. 方法是否过长（超过50行需要拆分）
3. 是否存在重复代码
4. 异常处理是否合理（禁止catch Exception）
5. 是否有更好的设计模式可以使用
6. Spring注解使用是否得当

请输出：
- 逐条问题说明（标注严重程度：高/中/低）
- 重构后的完整代码
- 重构前后对比说明

实战案例：

一段200行的OrderService.processOrder方法，Claude Code给出的重构建议：

• 高危：方法内直接操作了5个Mapper，违反单一职责 → 拆成validateOrder、createOrder、updateInventory、notifyUser四个方法
• 中危：10个if-else嵌套判断订单状态 → 使用状态模式（State Pattern）或策略模式
• 低危：魔法数字if(status == 3) → 定义枚举OrderStatusEnum.CANCELLED
• 低危：日志打印不规范，缺少关键业务参数 → 统一使用log.info("创建订单, orderId={}, userId={}", orderId, userId)

---

场景7：SQL优化——让慢查询无所遁形

痛点：接口慢，90%是SQL的锅。但EXPLAIN结果看不懂。

提示词模板：

需求：{描述查询需求}

当前表结构：
{粘贴CREATE TABLE语句}

当前SQL（如果有）：
{粘贴SQL}

请：
1. 写出符合需求的SQL（兼容MySQL 8.0）
2. 分析执行计划，指出是否用到了索引
3. 推荐创建哪些索引（说明类型：B-tree/复合/覆盖）
4. 如果涉及分页，给出深分页优化方案
5. 如果涉及多表关联，建议JOIN还是子查询

实战案例：

需求：查询某个工地近30天的混凝土浇筑记录，按时间倒序分页

表结构：
CREATE TABLE t_pour_record (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    site_id BIGINT NOT NULL COMMENT '工地ID',
    pour_date DATE COMMENT '浇筑日期',
    concrete_grade VARCHAR(20) COMMENT '混凝土标号',
    volume DECIMAL(10,2) COMMENT '浇筑方量',
    status TINYINT DEFAULT 0 COMMENT '状态',
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Claude Code会建议：

• 创建复合索引：idx_site_date_status(site_id, pour_date, status)
• 深分页优化：避免LIMIT 100000, 10，改用基于游标的分页（WHERE id < #{lastId} LIMIT 10）
• 如果pour_date范围固定，可以考虑按月分表

---

场景8：文档生成——让代码自己"说话"

痛点：写文档比写代码还痛苦，但不写又不行。

提示词模板：

根据以下Spring Boot接口代码，生成一份Markdown格式的接口文档：

{粘贴Controller代码}

要求：
1. 包含接口URL、请求方式、请求参数、返回值
2. 每个接口给出请求/响应的JSON示例
3. 标注必填字段和校验规则
4. 列出可能的错误码和含义
5. 生成Mermaid格式的时序图（展示核心接口的调用流程）
6. 输出格式适合直接粘贴到Swagger或YApi

为什么强调Mermaid格式？因为Claude Code可以直接生成Mermaid图表，你粘贴到Markdown里就能渲染成流程图、时序图，比画图工具快10倍。

---

场景9：设计评审——让AI当你的"技术评审官"

痛点：你设计了一个方案，想找人Review，但同事都在忙。

提示词模板：

你是一位有10年经验的Spring Boot架构师。请评审以下技术方案：

{粘贴方案文档或描述}

请从以下维度提出问题和改进建议：

1. 【可扩展性】未来新增需求时，现有设计是否需要大改？
2. 【高可用】是否存在单点故障？降级和熔断方案是什么？
3. 【数据一致性】并发场景下是否有数据不一致的风险？
4. 【性能】是否有潜在的性能瓶颈？大数据量下会不会崩？
5. 【安全性】是否有SQL注入、越权访问等安全风险？
6. 【运维】部署、监控、扩容的复杂度如何？

请输出：
- 每个维度至少1个具体的疑问点
- 对应的改进建议
- 风险等级评估（高/中/低）

实战案例：你设计了一个"订单超时自动取消"方案，用定时任务每分钟扫描。Claude Code会指出：

• 高风险：定时任务在多实例部署时会重复执行 → 建议加分布式锁（Redisson）
• 中风险：扫描全表在数据量大时性能差 → 建议改用延时队列（Redis ZSET / RocketMQ）
• 低风险：取消和释放库存不是原子操作 → 建议用@Transactional保证一致性

---

场景10：技术选型——让AI帮你做方案对比

痛点：技术选型纠结半天，A方案和B方案各有优劣，拿不定主意。

提示词模板：

我在做一个Spring Boot项目，需要实现{功能描述}。

目前有两个方案：
- 方案A：{方案A描述}
- 方案B：{方案B描述}

请从以下维度对比两个方案：
1. 实现复杂度
2. 性能表现
3. 可维护性
4. 社区活跃度和文档质量
5. 与Spring Boot生态的集成程度
6. 学习成本

输出对比表格，并给出你的推荐意见和理由。

实战案例：

需要实现分布式定时任务：
- 方案A：Spring Boot + Quartz
- 方案B：Spring Boot + XXL-JOB

请对比分析。

Claude Code会给出一个清晰的对比表格，并推荐XXL-JOB（理由：可视化管理界面、开箱即用的集群方案、中文社区活跃）。

---

五、进阶技巧：让你的提示词"更上一层楼"

掌握了上面10个模板，你已经能覆盖80%的日常场景了。下面再分享几个进阶技巧，帮你把剩下的20%也搞定。

5.1 用分隔符隔离上下文

当你的提示词里既有指令又有代码时，用明确的分隔符把它们隔开，避免AI混淆：

请审查以下代码的异常处理：

--- 代码开始 ---
public void processOrder(Long orderId) {
    Order order = orderMapper.selectById(orderId);
    // ... 业务逻辑
}
--- 代码结束 ---

重点关注：
1. 是否有空指针风险
2. 异常是否被正确处理

这就像你跟同事说"你看这段代码"，然后指着屏幕上的代码块——有边界感，不容易理解错。

5.2 给示例胜过给描述

想让AI输出特定格式的内容，直接给一个示例比描述格式要求更有效：

反面：输出一个JSON格式的返回值，包含code、message、data字段。

正面：

请按以下格式输出返回值：
{
  "code": 200,
  "message": "操作成功",
  "data": { ... }
}

AI看到具体的示例，比看到抽象的描述理解得更准确。

5.3 一次只问一件事

反面：帮我写一个用户注册接口，要支持手机号和邮箱两种方式，还要发验证码，验证码要过期，过期时间可配置，另外帮我把登录也写了。

正面：先问注册 → 再问验证码 → 再问登录。分步骤来，每一步的质量都更高。

这就像你让同事帮忙，一次说一件事他做得又快又好，一次性塞10件事他就懵了。

5.4 让AI先列假设再写代码

这是一个降低"AI幻觉"的实用技巧：

在编写代码之前，请先列出你的假设：
1. 你认为这个方法的输入是什么格式？
2. 你假设了哪些外部依赖的行为？
3. 你认为的边界条件有哪些？

列出假设后，再开始写代码。

这样做有个好处：如果AI的假设跟你的实际情况不一致，你可以在它写代码之前就纠正，而不是等它写完一大段代码才发现方向错了。

5.5 利用CLAUDE.md的记忆特性做"渐进式规范"

不需要一次性把所有规范都写进CLAUDE.md。你可以随着项目推进，逐步补充：

• 第1周：写入技术栈和包结构
• 第2周：Code Review时发现团队有新的命名约定，补充进去
• 第3周：踩了一次BigDecimal的坑，把金额处理规范加进去
• 第4周：项目引入了Redis缓存，把缓存使用规范加进去

CLAUDE.md就像团队的Wiki，越用越完善，Claude Code也越来越"懂"你的项目。

---

六、结果：从"能用"到"能打"到底差多少？

我们用一个具体场景来对比，感受一下"能用"和"能打"的差距：

场景：实现一个设备管理的分页查询接口

"能用"的问法：

帮我写一个设备分页查询接口

AI给你的代码：能跑，但没有参数校验、没有Swagger注解、返回格式跟项目不统一、字段名用了驼峰但数据库是下划线没做映射……

"能打"的问法：

请基于以下实体类，生成设备管理的分页查询接口。

实体类：Device（对应表 t_device）
字段：id, deviceName, deviceCode, siteId, status, createTime

技术要求：
- Spring Boot 3.x + MyBatis-Plus
- 分页使用IPage，当前页和每页大小通过QueryDTO传入
- 支持按deviceName模糊查询、按status精确查询、按siteId筛选
- 返回格式统一使用Result<IPage<DeviceVO>>
- VO中需要包含siteName（从t_site表关联查询）
- Controller添加Swagger注解
- 参数校验使用@Valid

AI给你的代码：直接能融入项目，有参数校验、有分页、有联表、有Swagger注释、返回格式统一、字段映射正确。

差距在哪？ 不是AI的能力差距，是你的"提问精度"差距。

效率提升的量化对比

维度	不用提示词模板	使用提示词模板
单个接口开发时间	30-60分钟	5-10分钟
Code Review返工率	40-60%	10-20%
代码规范一致性	看心情	95%以上
单测覆盖率	临时补，30%左右	随代码生成，70%+
文档完整度	大概率没有	随代码一起出

---

七、总结与延伸阅读

核心要点回顾

1. CLAUDE.md是你的"AI项目手册"——花10分钟写好它，后面每个对话都能受益。就像你不会每次开会都重新介绍项目背景一样，AI也不应该每次对话都从零开始。

2. STAR原则是提问的骨架——背景、任务、约束、输出格式，四要素缺一不可。记住这个比记住10个模板更有用，因为它是"元方法"，可以推导出所有具体模板。

3. 一次只问一件事——复合问题拆开问，质量更高，速度更快。

4. 给示例胜过给描述——想让AI输出什么格式，直接给一个示例。

5. 让AI先列假设再写代码——这是降低幻觉风险最简单有效的方法。

6. 渐进式完善你的CLAUDE.md——不要追求一步到位，随着踩坑逐步补充，让AI越来越"懂"你的项目。

一张图总结

┌──────────────────────────────────────────────────────┐
│                  Claude Code 使用层次                    │
│                                                        │
│  ┌──────────────────────────────────────────────────┐  │
│  │  第三层：体系化                                    │  │
│  │  • CLAUDE.md 项目规范                             │  │
│  │  • 自定义 Slash Command                          │  │
│  │  • 团队共享提示词库                                │  │
│  └──────────────────────────────────────────────────┘  │
│  ┌──────────────────────────────────────────────────┐  │
│  │  第二层：结构化                                    │  │
│  │  • STAR原则提问                                    │  │
│  │  • 10个高频场景模板                                │  │
│  │  • 分隔符、示例驱动、单任务提问                      │  │
│  └──────────────────────────────────────────────────┘  │
│  ┌──────────────────────────────────────────────────┐  │
│  │  第一层：直觉式                                    │  │
│  │  • "帮我写个接口"                                  │  │
│  │  • "这段代码有啥问题"                              │  │
│  │  • 能用，但不好用                                   │  │
│  └──────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────┘

写在最后：AI不是魔法，它是你用得越顺手越强的工具。与其花时间研究"哪个AI更强"，不如花时间打磨你的提示词——这才是真正的"杠杆"。把提示词打磨好，你就能把时间花在更有价值的架构设计和业务思考上，而不是日复一日的增删改查。

共勉。