文章目录
基础知识
目前（25年11月）由于各种原因,国内的cursor即使充值了Pro，也无法直接使用GPT-5或claude code的最新模型,但Cursor 2.0中集成了自研的composer大模型也十分的好用，足以应对大多数开发场景，本文主要分享cursor在功能开发上的使用攻略。
什么是 Token？
Token 是 AI 模型处理文本的基本单位。可以这样理解：
- 1个英文单词 ≈ 1-2个 Tokens
- 1个中文字符 ≈ 1-2个 Tokens
- 1行标准代码 ≈ 10-20个 Tokens
什么是 上下文？
上下文也被叫做AI工作的记忆区
AI IDE的工作记忆区-200k Tokens 你打开的文件内容 当前的对话历史 你引用的代码 AI生成的代码和建议 项目结构信息 你提供的规则和约束 cursor自带的提示词
这个记忆区的工作原理：
- ✅ 你提供的所有信息都在这个区域内，AI 都能"看到"并运用
- ✅ 新加入的信息会不断填充这个空间
- ❌ 当空间不足时，AI会压缩上下文，可能会丢失关键信息，影响代码生成效果
技巧
掌握了基础认知后，我们来深入探讨具体的技巧。不同的开发场景需要不同的提问策略，就像使用不同的工具处理不同的材料一样。
即时切换上线文
通过上文聊到的基础可以很自然的知道控制上下文长度，及时的切换上下文是一个非常基础且重要的技巧
何时应该开启新会话（切换上下文）？
| 应该开新会话 | 可以继续当前会话 |
|---|---|
| 全新的功能模块开发 | 同一功能的迭代优化 |
| 不相关的Bug修复 | 相关功能的逻辑扩展 |
| 不同的技术栈任务 | 基于现有设计的实现 |
| 独立的代码审查 | 同一业务逻辑的深化 |
维护功能描述文档
在项目根目录维护README文档，包含项目的功能文件路径。背后的逻辑也是和上下文相关，一个合适的说明文档可以大大减少AI需要扫描的文件数量
每次会话聚焦单一任务
很多开发者容易犯的一个错误是：在同一个会话中处理多个不相关的任务。
混合多个任务 上下文污染 AI理解混乱 生成代码质量下降 开发者体验变差
反面案例：
开发者提问记录：
1. "帮我写一个用户登录的JWT验证"
2. "现在优化一下商品列表的查询性能"
3. "再帮我写个邮件发送的工具类"
4. "对了，刚才的用户登录还需要添加日志记录"
→ 结果：AI混淆了不同任务的要求，生成的代码包含各种不相关的逻辑简单功能：精准直接的"指令式"提问
指令式提问适用于逻辑清晰、范围明确的简单功能开发，比如：
- 基本的 CRUD 操作
- 工具函数编写
- 数据验证逻辑
- 简单的算法实现
技巧模板：三要素确保精准度
markdown
**目标清晰** + **关键信息完备** + **约束条件明确**| 要素 | 检查项 | 示例 |
|---|---|---|
| 目标 | 是否清晰说明了要做什么？ | "验证商品名称唯一性" |
| 上下文 | 是否提供了相关服务/类？ | @ProductService |
| 约束 | 是否包含业务规则？ | "名称不能重复，存在则抛异常" |
| 输出 | 是否明确了期望的输出？ | "返回布尔值" 或 "抛出异常" |
提问示例
❌ 模糊提问：
"写一个商品名称验证"✅ 精准提问：
python
# 在商品创建功能中，需要验证商品名称在数据库中的唯一性。
# 请为 @ProductService 编写相应的验证逻辑，要求：
# 1. 检查商品名称是否已存在
# 2. 如果存在则抛出异常
# 3. 使用适当的异常类型和错误信息相似功能：让cursor参考已存在的方法或者类
当项目中已存在类似实现时，模式复用式提问能确保代码风格和架构的一致性：
- 新增类似业务模块
- 扩展现有功能
- 保持项目代码规范统一
技巧模板：参考+差异的黄金组合
指明参考对象 + 说明差异点 + 保持一致性
提问示例
java
// 参考项目中 UserService.updateUserProfile 方法的实现风格和错误处理方式，
// 为 @ProductService 编写一个 updateProduct 方法。
//
// 差异点说明：
// 1. 需要同时更新 @ProductDetailService 中的商品名称和商品单位
// 2. 商品状态为"下架"时不允许更新
// 3. 需要记录操作日志，参考原有的日志格式复杂功能：化整为零的"任务拆解式"提问
对于涉及多个服务、步骤繁多的复杂功能，任务拆解式提问是最高效的策略：
- 完整的业务流程（如下单、支付）
- 跨模块的功能开发
- 系统集成场景
提问示例
三阶段拆解法：设计→实现→集成
第一阶段：顶层设计（架构层面）
提示词：
我需要开发一个"用户下单"功能，涉及以下服务：
- 商品服务：验证商品信息和库存
- 订单服务：创建订单记录
- 库存服务：扣减库存
- 支付服务：处理支付
请先帮我设计：
1. 模块交互的时序图使用mermaid格式返回
2. 主要的接口定义和方法签名
3. 异常处理机制和回滚策略AI 生成的架构设计：
用户 订单服务 商品服务 库存服务 支付服务 提交订单请求 验证商品信息 返回商品详情 检查库存 库存充足 生成订单(待支付) 发起支付 返回支付页面 用户 订单服务 商品服务 库存服务 支付服务
第二阶段：分步实现（编码层面）
** 分步骤提问：**
步骤1：基于上面的设计，先在 @OrderService 中创建 createOrder 方法框架。
该方法需要：
- 接收商品列表和用户ID
- 调用 @ProductService 验证商品信息
- 返回订单基本信息（不包含支付）第三阶段：集成与优化（完善层面）
** 完善性提问：**
现在为 createOrder 方法添加完整逻辑：
1. 调用 @InventoryService 进行预扣库存
2. 添加库存不足时的回滚机制
3. 考虑分布式事务的解决方案
4. 添加适当的日志记录