上周，一个粉丝给我发私信：

"你之前说Cursor很牛，但我用了两周，感觉也就那样。写代码还是要自己改很多，速度也没快多少。"

我当时就笑了。

因为我刚开始用的时候，也是这种感觉。

用了3个月，踩了一堆坑之后，我才搞清楚：Cursor不是一个更好的代码补全工具，它是一个需要你重新学会"提问"的编程范式。

大多数人用Cursor，只用到了它10%的能力。

今天我把自己摸索出来的工作流，完整地写出来。

一、我的效率提升到底是怎么来的？

先说结论，再说方法。

用Cursor之前，我一天的有效编码产出大概是200-400行。 用Cursor之后，同等质量下，产出稳定在800-1200行。

提升了3-4倍，不是吹的，是实测数据。

但这个提升不是从第一天开始的。

第1周：感觉没什么用（效率几乎没变）
第2周：开始有感觉（提升约50%）
第3周：找到节奏（提升约150%）
第4周后：进入正循环（提升300%+）

为什么会有这个曲线？

因为用好Cursor需要重新建立一套工作习惯。你原来的习惯是"先想清楚，再动手写"，而Cursor的正确用法是"先描述清楚，让AI起草，再迭代优化"。

这是两种完全不同的节奏。

二、我踩过的3个最贵的坑

在讲工作流之前，先说说我交过的"学费"。

坑1：把Cursor当高级补全工具用

错误用法：

写几个字，等AI补全，不满意就删掉重写

问题：

• 补全粒度太小，AI没有上下文
• 效率提升有限，还经常打断思路
• 和直接用IDEA没什么差别

正确姿势： 不要等AI补全，要主动描述需求，让AI生成完整的代码块。

坑2：Prompt写得太简单

错误用法：

"写一个登录接口"

AI生成的：

// 最基础的登录逻辑，没有任何业务细节
public String login(String username, String password) {
    // ...
}

需要自己改的：太多了

正确用法：

"写一个用户登录接口，要求：
1. 支持用户名+密码登录
2. 密码用BCrypt加密
3. 登录失败超过5次锁定账户30分钟
4. 登录成功返回JWT token，有效期7天
5. 记录登录日志（IP、设备、时间）
6. 异常要用统一的Result包装返回"

AI生成的： 80%可以直接用的代码。

区别在哪里： 你给的上下文越丰富，AI生成的质量越高。这是废话，但大多数人就是懒得写清楚。

坑3：AI生成完就直接提交

这是最危险的坑。

我第一个月有一次，让AI写了一个文件上传接口，看了一眼能跑，就提交了。

结果被同事review的时候发现：

• 没有文件大小限制
• 没有文件类型校验
• 上传路径直接拼接用户输入（路径穿越漏洞）

AI写的代码功能上是对的，但安全性是有问题的。

这让我建立了一个铁律：AI生成的代码，安全相关的部分必须人工review，不能偷懒。

三、我现在的完整工作流

踩完坑之后，我建立了一套稳定运行的工作流。

第一步：需求拆解（用Claude，不用Cursor）

拿到需求之后，我第一步不是打开Cursor，而是打开Claude。

为什么？

Cursor适合生成代码，Claude适合分析和思考。我会把需求丢给Claude，让它帮我：

我要做一个xxx功能，需求是：[粘贴需求文档]

请帮我分析：
1. 这个需求有没有遗漏的边界情况？
2. 建议的数据库表结构是什么？
3. 有哪些技术风险需要提前考虑？
4. 推荐的实现步骤是什么？

这一步花15-30分钟，但能省去后期大量的返工。

一个真实的例子：

需求：做一个优惠券系统

我以为很简单，Claude帮我分析后发现了7个我没想到的问题：

• 优惠券能不能叠加？
• 退款时优惠券怎么处理？
• 库存扣减有没有并发问题？
• 过期未使用的优惠券如何清理？
• ……

这些坑，提前想清楚，比上线后修复便宜10倍。

第二步：架构设计（自己来，AI辅助）

需求想清楚之后，我会自己画出：

• 核心的数据库表结构
• 主要的接口设计
• 关键的业务流程

这一步不能完全交给AI。

架构设计需要结合你的团队现状、技术栈、业务场景做判断。AI给的方案往往是"教科书级别的正确"，但未必适合你的实际情况。

我会让AI做的是：

"根据这个表结构，帮我检查有没有明显的设计问题"
"这个接口设计有没有RESTful规范的问题"

用AI做review，而不是做设计。

第三步：编码实现（Cursor主导）

这一步才是Cursor发挥威力的时候。

我的Prompt模板（Java后端）：

基于以下信息，帮我实现[功能名称]：

技术栈：Spring Boot 3, MyBatis-Plus, Redis, MySQL 8
已有的相关代码：[粘贴相关实体类/接口]

需要实现：
1. [具体功能点1]
2. [具体功能点2]
3. [具体功能点3]

要求：
- 异常用GlobalExceptionHandler统一处理
- 返回值用Result<T>包装
- 需要加事务的地方加@Transactional
- 写清楚注释
- 不要写单元测试（我单独让你写）

为什么要粘贴已有代码？

这是很多人忽略的关键点。Cursor能看到你的项目上下文，但你要让它知道你项目的规范和风格，最好的方式是直接粘贴示例代码。

AI会自动学习你的代码风格，生成的代码和你的项目融合度会高很多。

第四步：单元测试（全交给AI）

这是我觉得收益最大的地方。

写单元测试是我最讨厌的工作之一，现在全部交给Cursor：

基于上面实现的代码，帮我写完整的单元测试：
- 使用JUnit5 + Mockito
- 覆盖正常流程、边界情况、异常情况
- 每个测试方法要有清楚的中文描述
- 覆盖率目标：核心业务逻辑 > 80%

AI写测试的质量出乎我意料的好。它会自动想到很多边界情况，比我手写的覆盖更全面。

时间对比：

• 以前手写测试：1小时
• 现在让AI写：5分钟生成 + 10分钟review

提升：4倍。

第五步：Code Review（最重要的一步）

这一步绝对不能省。

我的review清单：

功能性检查：

• 业务逻辑是否正确？
• 边界情况是否处理？
• 异常是否合理抛出？

安全性检查：

• 有没有SQL注入风险？（MyBatis-Plus基本没有，但自定义SQL要看）
• 有没有敏感信息泄露？
• 接口有没有做权限校验？
• 文件操作有没有路径穿越风险？

性能检查：

• 有没有N+1查询？
• 循环里有没有数据库操作？
• 大数据量的场景有没有分页？

规范性检查：

• 命名是否符合团队规范？
• 注释是否清楚？
• 是否有魔法数字需要抽成常量？

这个review过程，我平均要改掉AI生成代码的20-30%。

但这20-30%的修改，比从零写节省了太多时间。

四、一个完整的实战案例

上个月做了一个消息通知系统，我把完整过程记录下来了。

需求： 支持站内信、短信、邮件三种通知方式，根据用户偏好发送

Day 1上午（2小时）：需求分析

用Claude分析后确定：

• 通知模板系统（不同类型通知的内容模板）
• 用户通知偏好设置
• 通知发送记录（便于排查问题）
• 失败重试机制（发送失败自动重试3次）
• 策略模式实现不同渠道（方便扩展新渠道）

Day 1下午（1.5小时）：架构设计

自己设计了4张表：

• notify_template（通知模板）
• user_notify_config（用户偏好）
• notify_record（发送记录）
• notify_retry（重试队列）

Day 2（4小时）：编码实现

用Cursor生成：

• 4个Entity类：10分钟
• Mapper接口：15分钟
• NotifyService核心逻辑：45分钟（包含review）
• 三个渠道的具体实现类：30分钟
• Controller层：20分钟
• 单元测试：15分钟生成 + 20分钟review

总编码时间：约2.5小时

Day 2下午（1小时）：联调和修复

发现并修复了2个bug：

• 一个是AI在并发场景下的幂等性没处理好
• 一个是重试逻辑的指数退避实现有问题

总耗时：1.5天

如果纯手写：我估计要3-4天。

五、几个让效率翻倍的小技巧

技巧1：给Cursor建一个项目规范文件

在项目根目录创建.cursorrules文件，写清楚你的项目规范：

# 项目规范

## 技术栈
- Spring Boot 3.x
- JDK 17
- MyBatis-Plus 3.5.x
- Redis（缓存）
- RabbitMQ（消息队列）

## 代码规范
- 所有接口返回Result<T>
- 异常统一用BusinessException抛出
- 日志用Slf4j，不要用System.out.println
- 常量放在对应模块的Constants类里

## 命名规范
- 接口文件名以I开头：IUserService
- 实现类不加Impl：UserService
- DTO类名以DTO结尾

配置之后，Cursor生成的代码会自动遵循这些规范，review工作量减少一半。

技巧2：用@符号引用文件

在Cursor里，用@文件名可以直接引用项目中的文件：

参考@UserService的实现方式，帮我实现OrderService的退款逻辑

这样AI能直接看到你的代码风格，生成的代码一致性更强。

技巧3：让AI解释它自己的代码

看到AI生成了不熟悉的写法，不要直接用，先问清楚：

你这里用了CompletableFuture.allOf，能解释一下为什么这样写吗？
有没有更简单的替代方案？

这样做有两个好处：

• 避免引入自己不理解的代码
• 顺便学习了新的写法

技巧4：分步骤生成，不要一次要太多

不好的方式：

帮我实现整个用户模块，包括注册、登录、修改密码、找回密码、注销账户

好的方式：

先帮我实现用户注册功能
[review后]
好，现在帮我实现用户登录，注意复用刚才的密码校验逻辑
[review后]
继续，实现修改密码功能

分步骤生成，每一步都能review和调整，最终的代码质量高很多。

六、我的工具链全貌

用了3个月，我的工具链已经固化：

需求分析阶段：Claude（思考和分析）
架构设计阶段：自己来，Claude辅助review
编码实现阶段：Cursor（主力）
代码调试阶段：IDEA（断点调试无可替代）
API测试阶段：Bruno（轻量，比Postman好用）

IDEA我现在每天只用1-2小时，专门用来调试。

其他时间全在Cursor里。

七、一个重要的提醒

用Cursor提高效率之后，省出来的时间，要花在刀刃上。

很多人提效之后，摸鱼的时间多了。

这是最大的浪费。

我省出来的时间，用在：

• 深入理解需求和业务（以前没时间做）
• 做架构设计和技术选型（以前赶时间跳过）
• 做Code Review（以前互相review没时间）
• 学习新技术（以前下班太累）

AI提升的是执行效率，但不会替你做思考。

多出来的时间，要用来做AI做不了的事。

写在最后

用Cursor3个月，最大的感受不是"代码写得更快了"，而是工作方式变了。

以前：想清楚 → 动手写 → 调试改bug 现在：描述清楚 → AI起草 → 我来优化

以前花在"打字"上的时间，现在花在"思考"上了。

这才是AI工具真正的价值。

---

你现在用的是什么AI编程工具？有什么心得？欢迎评论区分享。

---

后端AI实验室 不讲概念，只谈实战 代码开源，每周更新