前言

作为 Cursor 的重度用户，我现在已经离不开 AI 辅助编程了（没有 AI 都感觉不会写代码了 =-=）。

一、基础配置：让 Cursor 更懂你

工欲善其事，必先利其器。在开始使用 Cursor 之前，正确的配置能让 AI 更准确地理解你的项目，避免很多不必要的麻烦。

1.1 .cursorignore - 告诉 AI 该看什么（重要）

这是我使用 Cursor 学到的第一个重要经验：不要让 AI 看太多无关的东西。

为什么需要？

在没有配置 .cursorignore 时，Cursor 会索引项目中的所有文件。这意味着 node_modules、dist、.git 这些包含成千上万个文件的目录都会被读取，导致：

• AI 响应变慢
• 上下文被污染，理解偏差
• 浪费 token 额度

常见配置示例：

# 依赖包
node_modules/
vendor/
.venv/

# 构建产物
dist/
build/
out/
target/

# 版本控制
.git/
.svn/

# IDE 配置
.vscode/
.idea/

# 日志和缓存
*.log
.cache/
tmp/

# 大型数据文件
*.csv
*.db
*.sql

最佳实践：

• 新建项目时第一时间创建 .cursorignore
• 参考 .gitignore 的配置
• 定期检查和更新，保持精简

1.2 cursor rules - 定制你的编程规范（重要）

.cursorrules 文件就像是给 AI 的一份"工作说明书"，告诉它你的编码习惯和项目规范。

好处：

• AI 生成的代码更符合你的习惯
• 不用每次都重复说明要求
• 团队协作时保持统一标准

参考资源：

• awesome-cursorrules - 各种项目的规则模板
• Cursor Rules 使用 - 我之前写过 rules 的相关使用，可参考

1.3 memories - 让 AI 记住你的偏好

memories 会根据在 Chat 中的对话自动生成规则。它们作用于当前项目，并能在不同会话间保持上下文。

平常用的比较少，主要是使用的 rules，记得关注一下设置中的已记录的 memories，因为是自动记录的，如果有不合适的，记得手动删掉。

1.4 MCP（Model Context Protocol）- 集成外部工具

MCP 是 Cursor 的一个强大功能，它允许你将外部工具和数据源集成到 Cursor 中，大大扩展 AI 的能力边界。

MCP 是什么？

简单说，MCP 让 Cursor 可以调用外部服务，比如：

• 数据库查询工具
• API 接口
• 文件系统操作
• 自定义的业务工具

如何配置？

在项目根目录创建 .cursor/mcp.json 文件：

{
  "mcpServers": {
    "my-tool": {
      "command": "node",
      "args": ["path/to/tool.js"],
      "env": {
        "API_KEY": "${API_KEY}"
      }
    }
  }
}

使用场景举例：

1. 数据库查询：让 AI 直接查询数据库获取数据
2. API 调用：在编码时实时获取远程数据
3. 自定义工具：集成公司内部的开发工具
4. 文档检索：连接内部知识库

我的建议：

• 初学者可以先不用，专注于基础功能
• 有特殊需求时再研究配置
• 详细配置方法参考：Cursor MCP 官方文档

二、提示词工程：写出让 AI 秒懂的需求

提示词的质量直接决定了 AI 输出的质量。这是我半年来最深刻的体会：会问比会写更重要。

2.1 黄金公式：目标 + 具体要求 + 约束条件

很多人和 AI 对话时，习惯说"优化这个函数"、"修复这个 bug"这样模糊的需求，然后就抱怨 AI 理解不对。其实问题不在 AI，而在于你的表达不够清晰。

我总结的黄金公式是：明确目标 + 具体要求 + 约束条件，三者缺一不可。

❌ 错误示范：

"优化这个函数"

AI 不知道你要优化什么：性能？可读性？代码长度？

✅ 正确示范：

优化这个函数的性能（目标）
使用缓存减少重复计算（具体要求）
保持函数签名不变，添加注释说明优化思路（约束条件）

再看几个实际例子：

示例 1：函数重构（Go 语言）

将这个同步的文件读取函数改为支持并发处理（目标）
使用 goroutine 和 channel，添加 context 超时控制和错误处理（具体要求）
保持函数出入参数不变（约束条件）

示例 2：性能优化（Go 语言）

优化这个用户查询函数的性能（目标）
使用 map 做索引，避免嵌套循环查找，减少数据库查询次数（具体要求）
保持代码可读性，用中文注释说明优化思路（约束条件）

示例 3：功能开发（Go 语言）

实现用户登录功能（目标）
使用 JWT 认证，密码用 bcrypt 加密，添加请求参数验证（具体要求）
遵循项目现有的错误处理规范，返回统一的 JSON 格式（约束条件）

2.2 对话技巧：AI 既是实习生，又是老师

使用 Cursor 半年后，我总结出一个核心心法：AI 既是实习生，又是老师。

这听起来矛盾，但恰恰是正确的使用姿势：

角色 1：AI 是你的实习生 - 需要清晰的任务说明

就像给实习生分配任务一样，你必须把需求说清楚。模糊的指令只会得到模糊的结果。

❌ 错误示范：

我：优化这个函数
AI：（改了变量名，优化了格式...）
我：不是，我要性能优化！

✅ 正确示范：

我：优化 GetUserOrders 这个函数的性能

当前问题：
- 函数内有嵌套循环，时间复杂度 O(n²)
- 每次循环都查询数据库

优化目标：
- 降低时间复杂度到 O(n)
- 减少数据库查询次数
- 保持代码可读性，加中文注释

@file order_service.go

就像管理实习生，你给的信息越详细，产出质量越高。

角色 2：AI 是你的老师 - 不懂就要追问

但 AI 又不仅仅是实习生，它掌握大量知识。遇到不懂的技术点，要主动请教。

实战案例：Go 并发问题

有一次 AI 写了一段使用 sync.Map 的代码，我不太理解为什么不用普通 map：

// AI 生成的代码
var cache sync.Map

func GetUser(id int) (*User, error) {
    if val, ok := cache.Load(id); ok {
        return val.(*User), nil
    }
    // ... 查询逻辑
}

我的追问过程：

我：为什么这里用 sync.Map 而不是普通的 map + 互斥锁？

AI：sync.Map 针对两种场景优化：
1. 读多写少的场景
2. 多个 goroutine 读写不同的 key

我：那什么场景下不该用 sync.Map？

AI：如果是读写比例相当，或者经常覆盖相同的 key，
普通 map + RWMutex 性能会更好。sync.Map 内部实现较复杂...

我：能给个性能对比的例子吗？

AI：（给出了详细的 benchmark 对比和使用建议）

通过这样追问，我不仅学会了 sync.Map，还理解了它的适用场景和性能特点。

再举个例子：context 的传递

// AI 写的代码
func ProcessOrder(ctx context.Context, orderID string) error {
    // ... 处理逻辑
}

我：为什么函数第一个参数总是 context.Context？这不是增加复杂度吗？

AI：这是 Go 的最佳实践，context 用于：
1. 控制超时和取消
2. 传递请求级别的元数据
3. 避免 goroutine 泄漏

我：能举个 goroutine 泄漏的例子吗？

AI：比如启动了一个 goroutine 做耗时操作，
但请求提前结束了，没有 context 的话...
（给出了具体的泄漏案例和解决方案）

我的追问技巧：

1. "为什么"系列

   • “为什么要用这个数据结构？”
   • “为什么不直接用 XXX 方案？”
   • “为什么这里要加锁？”

2. "什么情况"系列

   • “什么情况下会出问题？”
   • “什么场景下不该这样用？”
   • “什么时候该用 channel，什么时候该用 mutex？”

3. "能不能"系列

   • “能举个实际例子吗？”
   • “能解释一下这段代码的执行流程吗？”
   • “能说说性能差异吗？”

核心原则：

• 🎯 对 AI（实习生）：需求越清晰，输出越准确
• 📚 向 AI（老师）：不懂就问，打破砂锅问到底
• ❌ 不要盲目接受 AI 的代码
• ✅ 每个关键技术点都要理解透彻
• ✅ 理解了才能写出高质量代码

三、进阶技巧：从会用到用好

前面讲的是基础用法，这一章分享一些高级技巧，帮你把 Cursor 用到极致。

3.1 TDD 测试驱动开发

TDD（测试驱动开发，红-绿-重构）配合 AI 简直是绝配。就是消耗 token 比较狠，通常小功能就直接让它写了，自己审查一下就行。

传统流程 vs AI 辅助流程：

传统 TDD：

1. 手写测试用例（费时费力）
2. 运行测试（红灯）
3. 实现功能代码
4. 运行测试（绿灯）
5. 重构

AI 辅助 TDD：

1. 让 AI 写测试用例（快速且全面）
2. 运行测试（红灯）
3. 让 AI 实现功能代码
4. 运行测试（绿灯）
5. 让 AI 优化重构

实际案例：

我要实现一个用户注册功能，传统方式可能要写半小时的测试用例，但用 Cursor：

我：为用户注册功能写测试用例

需要测试：
- 正常注册流程
- 邮箱格式验证
- 密码强度检查
- 重复邮箱处理
- 数据库插入失败处理

使用 Go 标准库 testing，遵循 xxx_test.go 格式

AI 会生成完整的测试用例，然后我再让它实现功能代码。这样的好处是：

• ✅ 测试覆盖更全面（AI 会考虑到你可能遗漏的边界条件）
• ✅ 代码质量更高（有测试约束，不会乱写）
• ✅ 逻辑更清晰（先定义行为，再实现）
• ✅ 节省大量时间

小技巧：

• 先让 AI 列出需要测试的场景，你再补充遗漏的
• 运行测试时把错误信息贴给 AI，让它修复
• 定期让 AI Review 测试代码，提高测试质量

3.2 处理大规模代码修改

这是我踩过最大的坑，也是最宝贵的经验。

现在 cursor 有个 plan 的功能，可以协助做这种大任务的拆分。

真实案例：微服务拆分

我们有一个分析 App 的服务（单体应用），主要功能：

• 上传 APK/IPA 文件
• 静态分析（代码扫描、权限检查、组件分析）
• 生成分析报告
• 存储和查询历史记录

随着业务增长，静态分析部分越来越重，占用大量 CPU 和内存，影响其他功能。需要将静态分析拆分成独立的微服务。

原有结构：

// 单体应用结构
app-analyzer/
├── handler/
│   ├── upload_handler.go      // 上传文件
│   ├── analyze_handler.go     // 触发分析
│   └── report_handler.go      // 查询报告
├── service/
│   ├── file_service.go        // 文件处理
│   ├── analyze_service.go     // 静态分析核心逻辑 (需要拆出去)
│   ├── scanner_service.go     // 代码扫描 (需要拆出去)
│   └── report_service.go      // 报告生成
└── repository/
    ├── app_repo.go
    └── report_repo.go

目标结构：

1. app-gateway (API 网关)
   - 接收上传和查询请求

2. static-analyzer (新的微服务)
   - 独立的静态分析服务
   - 包含 analyze_service 和 scanner_service

3. app-storage (原有服务精简后)
   - 负责存储和查询

我一开始天真地问 AI：“帮我把静态分析部分拆成微服务”。结果：

• 😱 AI 一口气生成了几千行代码
• 😱 把文件搬来搬去，依赖关系全乱了
• 😱 数据库表结构要不要拆？AI 没考虑
• 😱 原有的函数调用变成了 RPC，到处报错
• 😱 搞了一周，代码乱成一团，最后放弃了

正确做法：分 6 个阶段系统推进

阶段 1：梳理依赖关系（让 AI 做分析）

@codebase 分析静态分析相关的代码依赖

请分析：
1. analyze_service.go 和 scanner_service.go 依赖了哪些其他模块？
2. 有哪些函数调用了这两个 service？
3. 这两个 service 访问了哪些数据库表？
4. 有哪些共享的数据结构（struct）？
5. 有哪些配置项是静态分析专用的？

给出详细的依赖关系图和文件清单。

AI 会给出分析报告：

依赖分析：

analyze_service.go 依赖：
- repository/app_repo.go (读取 App 元数据)
- utils/file_helper.go (文件操作)
- config/analyzer_config.go (分析配置)
- model/app_model.go (数据结构)

被调用方：
- handler/analyze_handler.go:StartAnalyze()
- handler/report_handler.go:GetAnalyzeStatus()

数据库表：
- apps (读取)
- analyze_results (读写)
- scan_records (读写)

阶段 2：设计服务边界和接口

不要急着写代码，先定义清楚接口：

基于上面的分析，设计微服务接口：

新服务名称：static-analyzer

需要提供的 RPC 接口：
1. AnalyzeAPK(appID, filePath) - 分析 Android 应用
2. AnalyzeIPA(appID, filePath) - 分析 iOS 应用  
3. GetAnalyzeResult(taskID) - 查询分析结果
4. CancelAnalyze(taskID) - 取消分析任务

请给出：
1. 详细的接口定义（proto 或 Go interface）
2. 请求和响应的数据结构
3. 错误码定义
4. 接口之间的调用关系

先设计接口，不要写实现代码。

阶段 3：创建新服务的脚手架

创建 static-analyzer 微服务的项目结构：

要求：
1. 使用 gRPC 作为通信协议
2. 目录结构遵循 Go 标准布局
3. 包含配置文件模板
4. 添加 Dockerfile
5. 写好 README 说明依赖和启动方式

先生成项目骨架，不要迁移业务逻辑。

阶段 4：逐步迁移代码

关键点：不要一次性全搬，先做适配层

@file service/analyze_service.go

不要直接删除这个文件，而是改造成 RPC 客户端：

第一步：保持原有函数签名不变
第二步：内部改为调用 static-analyzer 的 gRPC 接口
第三步：添加失败重试和超时控制
第四步：记录详细日志，方便排查问题

这样改造后，调用方（handler）不需要修改，降低风险。

给出改造前后的对比代码。

改造示例：

// 改造前：直接在本地执行
func (s *AnalyzeService) AnalyzeAPK(appID int64, filePath string) error {
    // 本地执行静态分析逻辑（几百行代码）
    result := doStaticAnalyze(filePath)
    return s.saveResult(appID, result)
}

// 改造后：调用远程服务
func (s *AnalyzeService) AnalyzeAPK(appID int64, filePath string) error {
    // 调用 gRPC 服务
    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Minute)
    defer cancel()
    
    resp, err := s.analyzerClient.AnalyzeAPK(ctx, &pb.AnalyzeRequest{
        AppId:    appID,
        FilePath: filePath,
    })
    if err != nil {
        // 记录详细错误，方便排查
        log.Errorf("调用静态分析服务失败: appID=%d, err=%v", appID, err)
        return fmt.Errorf("分析失败: %w", err)
    }
    
    return s.saveResult(appID, resp.Result)
}

阶段 5：迁移业务逻辑到新服务

@file service/analyze_service.go (原有文件)

将原有的静态分析逻辑迁移到新服务：

源文件：app-analyzer/service/analyze_service.go
目标：static-analyzer/internal/analyzer/analyzer.go

注意事项：
1. 把 doStaticAnalyze 核心逻辑完整搬过去
2. 调整依赖的工具函数（file_helper 等）
3. 数据库访问改为参数传入，不要硬编码连接
4. 配置项统一读取，不要散落各处
5. 添加单元测试，确保逻辑正确

一次只迁移一个函数，迁移完就测试。

阶段 6：灰度发布和切流量

设计灰度发布方案：

1. 双写模式（过渡期）：
   - 同时调用本地逻辑和远程服务
   - 对比两边结果是否一致
   - 只返回本地结果给用户（降低风险）

2. 切流量策略：
   - 先切 10% 的流量到新服务
   - 监控错误率、响应时间
   - 逐步提升到 50%、100%

3. 回滚预案：
   - 配置开关，可以立即切回本地逻辑
   - 保留老代码 1 个月，确认稳定后再删除

请帮我实现双写模式的代码，包括结果对比逻辑。

实战经验总结：

微服务拆分是大规模重构，必须系统规划：

1. 先分析，后设计，最后编码（不要上来就写代码）
2. 定义清晰的服务边界（哪些功能属于新服务）
3. 接口先行（先定接口，再实现）
4. 适配器模式（保持原有调用方不变）
5. 逐步迁移（一个功能一个功能搬）
6. 灰度发布（先切小流量，验证没问题再全量）
7. 保留回滚能力（配置开关 + 保留老代码）

这样做的好处：

• ✅ 每一步都可验证，风险可控
• ✅ 出问题能快速定位是新服务还是老服务
• ✅ 灰度发布，线上用户无感知
• ✅ 可以随时回滚，不会陷入进退两难的境地

关键提示：

让 AI 做拆分时，千万不要问"帮我拆微服务"这种大而全的需求，而要：

• 先让 AI 分析依赖关系
• 再让 AI 设计接口
• 然后一个模块一个模块地迁移
• 每一步都明确告诉 AI 只做这一步，不要做多余的

记住：大规模重构不是技术问题，是工程管理问题。

3.3 利用 Git 管理 AI 修改

这是我现在每次使用 AI 大规模修改代码的标准流程，强烈推荐。

标准工作流：

# 1. 创建新分支进行修改
git checkout -b feature/ai-refactor

# 2. 让 AI 进行第一批修改
# ... (通过 Cursor 对话)

# 3. 查看修改内容
git diff

# 4. 如果满意，提交第一批
git add .
git commit -m "重构: 第一批修改 - 更新工具函数"

# 5. 继续下一批修改
# ...

# 6. 如果某次修改有问题，可以轻松回滚
git checkout -- .
# 或者回滚到上一个提交
git reset --hard HEAD^

# 7. 全部完成后，合并到主分支
git checkout main
git merge feature/ai-refactor

实战经验：

有一次我让 AI 重构一个大模块，分了 5 个批次提交：

1. 第 1 批：重构数据结构 ✅
2. 第 2 批：更新业务逻辑 ✅
3. 第 3 批：修改 API 接口 ❌（AI 理解错了）
4. 直接 git reset --hard HEAD^ 回滚第 3 批
5. 重新给 AI 更清晰的提示词，再次修改 ✅
6. 第 4、5 批顺利完成 ✅

如果不用 Git，这种情况就很难处理了。

核心好处：

• ✅ 修改可追溯（每次提交都有记录）
• ✅ 出错可回滚（一键恢复）
• ✅ 便于 Code Review（一批一批看）
• ✅ 降低风险（主分支不受影响）
• ✅ 团队协作友好（分支可以共享）

3.4 上下文不够时的处理策略

AI 说"上下文不够"或者理解偏差时，通常是你给的信息不足。

问题表现：

• AI 的回答太泛泛，不具体
• AI 提出的方案不适合你的项目
• AI 遗漏了关键的业务逻辑

解决策略：

1. 分步提问，逐步深入

❌ 错误方式：

"帮我实现一个用户管理系统，包括注册、登录、权限管理、数据导出等功能"

这个需求太大，AI 无法一次性处理好。

✅ 正确方式：

第 1 步："先实现用户注册功能，需要邮箱验证"
第 2 步："现在添加登录功能，使用 JWT 认证"
第 3 步："基于 JWT 实现权限验证中间件"
...

2. 提供充分的上下文

使用 @file、@codebase 等功能：

@file user.go
@file auth.go

基于这两个文件的现有结构，添加忘记密码功能。

业务逻辑：
1. 用户输入邮箱
2. 发送重置链接（有效期 30 分钟）
3. 用户点击链接设置新密码
4. 重置成功后使旧链接失效

3. 说明业务背景

不要只说"怎么做"，还要说"为什么做"：

我们的系统是面向企业客户的 SaaS 平台，
用户数据敏感性很高，需要符合 GDPR 规范。

实现数据导出功能时：
- 只能导出用户自己的数据
- 导出格式要支持 CSV 和 JSON
- 敏感字段要脱敏处理

AI 理解了业务背景，生成的代码会更贴合需求。

3.5 Code Review 最佳实践

我现在养成了一个习惯：提交前让 AI 先审查一遍代码。

我的 Code Review 流程：

Code Review：@file user_service.go

请重点检查：
1. ✅ 代码质量和可读性
2. 🐛 潜在 Bug 和边界条件
3. ⚡ 性能问题（特别是数据库查询）
4. 🔒 安全漏洞（SQL 注入、XSS 等）
5. ✨ 可优化的地方

请给出详细的审查报告。

真实案例：

有一次，AI 指出了一个性能问题：

// 我的代码（N+1 查询问题）
for _, user := range users {
    orders := getOrdersByUserID(user.ID)  // 每次循环都查数据库
    // ...
}

// AI 的建议
userIDs := extractUserIDs(users)
orders := getOrdersByUserIDs(userIDs)  // 一次查询获取所有订单
orderMap := groupOrdersByUserID(orders)

注意事项：

• AI 的建议仅供参考，最终判断还是要靠自己
• 对于安全和性能问题，要特别重视
• 定期让 AI Review 老代码，会有新发现

四、避坑指南：我踩过的那些坑

血泪换来的经验。

❌ 坑 1：过度依赖 AI，不理解代码就提交

我的惨痛经历：

刚开始用 Cursor 时，我特别兴奋，觉得写代码太简单了。有一次让 AI 实现了一个数据处理功能，看起来能跑，测试也通过了，就直接提交了。

结果：

• 😱 上线第二天，测试环境报内存溢出
• 😱 排查了 3 个小时才发现是 AI 写的代码有内存泄漏
• 😱 因为我根本不理解那段代码的实现逻辑
• 😱 最后只能回滚，重新实现

问题根源：

• AI 生成的代码能跑就行，不管内部逻辑
• 出了问题不知道如何排查
• 代码质量和性能无法保证
• 埋下技术债，后续维护困难

正确做法：

现在我的流程是这样的：

1. AI 写完代码后，我会问：“请详细解释这段代码的逻辑”
2. 对于关键部分，再问：“为什么这样实现？有什么潜在问题吗？”
3. 不理解的地方继续追问，直到完全明白
4. 自己再审查一遍，想想边界条件
5. 写单元测试验证（让 AI 写测试用例）
6. 确认无误后才提交

核心原则：

• ✅ AI 是辅助工具，不是替代大脑
• ✅ 代码的责任人是你，不是 AI
• ✅ 理解了再用，不理解就问
• ✅ 对生产代码要有敬畏之心

❌ 坑 2：提示词太模糊，AI 理解偏差

典型场景：

我："优化这个函数"
AI：（优化了代码可读性，把变量名改长了）
我：不是，我要优化性能！
AI：好的（又优化了一遍）
我：还是不对...

浪费了 10 分钟，还是没达到目的。

问题根源：

• 提示词太模糊，没有明确目标
• AI 只能猜你的意图，猜错了就白费
• 反复沟通消耗时间和 token

正确做法：

用前面讲的黄金公式：

// ❌ 模糊的提示词
"优化这个函数"

// ✅ 清晰的提示词
"优化这个函数的性能（目标）
使用缓存减少重复计算，时间复杂度降到 O(1)（具体要求）
保持函数签名不变，添加注释说明优化思路（约束条件）"

经验总结：

• 花 30 秒想清楚需求，胜过花 10 分钟反复沟通
• 提示词越具体，AI 越准确
• 参考第二章的提示词模板

❌ 坑 3：没有利用 .cursorignore，上下文污染

血泪教训：

有一次我在一个前端项目中使用 Cursor，让 AI 帮我找一个组件的用法。结果 AI 给出的答案完全不对，因为它把 node_modules 里面的代码也读进来了，理解偏差很大。

问题表现：

• AI 响应特别慢（要读几万个文件）
• AI 的答案引用了第三方库的内部实现
• Token 消耗飞快
• 准确率明显下降

解决方法：

创建 .cursorignore 文件，示例见第一章 1.1 节。配置后：

• ✅ 响应速度提升
• ✅ 准确率明显提高
• ✅ Token 消耗减少

小贴士：

• 项目初始化时就配置好
• 大型项目尤其重要
• 定期检查是否需要更新

❌ 坑 4：忘记版本控制，AI 改错了不好回滚

这个坑在第三章 3.2 节详细讲过了，再强调一遍：

永远记住：

• ✅ 修改前先创建 Git 分支
• ✅ 分阶段提交，每批修改一次提交
• ✅ 重要修改前先备份
• ✅ 使用 git diff 检查修改内容

❌ 坑 5：不审查 AI 生成的代码就直接用

危险指数：⭐⭐⭐⭐⭐

这是最危险的坑，可能导致严重的生产事故。

真实案例 1：安全漏洞

我见过有人直接用 AI 生成的登录代码，结果有 SQL 注入漏洞：

// AI 生成的代码（有安全漏洞）
query := fmt.Sprintf("SELECT * FROM users WHERE username='%s' AND password='%s'", 
    username, password)

如果输入 username = "admin' --"，就能绕过密码验证。

真实案例 2：性能问题

AI 生成的代码有 N+1 查询问题，导致接口响应时间从 100ms 飙升到 10 秒。

真实案例 3：逻辑错误

AI 没有处理边界条件，空指针异常导致服务崩溃。

必须审查的重点：

1. 🔒 安全性：SQL 注入、XSS、CSRF、权限验证
2. ⚡ 性能：N+1 查询、内存泄漏、无限循环
3. 🐛 边界条件：空值、空数组、越界、并发
4. ✅ 业务逻辑：是否符合需求、是否有遗漏
5. 🧪 测试：是否有充分的测试覆盖

审查流程：

1. 仔细阅读 AI 生成的每一行代码
2. 让 AI 解释关键逻辑
3. 运行单元测试
4. 手动测试边界条件
5. 让 AI 做 Code Review（参考第三章 3.5 节）
6. 确认无误后再提交

❌ 坑 6：上下文管理不当

问题场景 1：信息过载

我：@codebase 优化整个项目的性能
AI：项目太大了，请缩小范围...

问题场景 2：信息不足

我：实现一个导出功能
AI：（生成了一个通用的导出，但不符合你项目的架构）

正确做法：

参考第三章 3.4 节的策略：

• ✅ 用 @file 指定具体文件
• ✅ 用 @codebase 配合关键词搜索
• ✅ 分步提问，逐步深入
• ✅ 提供业务背景和上下文

经验公式：

上下文太少 = AI 瞎猜 ❌
上下文太多 = AI 懵了 ❌
上下文刚好 = AI 准确 ✅

五、实战检查清单

把这个清单保存下来，每次使用 Cursor 时对照检查，养成好习惯。

📋 开始编码前

• 配置了 .cursorignore 文件（排除无关文件）
• 设置了 .cursorrules 规范（定义编码标准）
• 创建了 Git 功能分支（便于回滚）
• 明确了本次的开发目标

💬 与 AI 对话时

• 提示词包含：目标 + 具体要求 + 约束条件
• 使用了合适的 @ 符号（@file、@codebase 等）
• 提供了足够的上下文（业务背景、技术栈）
• 问题拆解得足够细（不要一次问太复杂的）

📝 收到 AI 回复后

• 完全理解了代码逻辑（不懂就追问）
• 检查了边界条件和异常处理
• 考虑了性能影响（数据库查询、内存使用）
• 审查了安全问题（SQL 注入、XSS、权限）
• 运行了单元测试
• 手动测试了核心功能

🚀 提交代码前

• 让 AI 做了 Code Review
• 自己再完整审查一遍
• 运行了完整的测试套件
• 检查了代码规范（linter 通过）
• 写了清晰的提交信息
• 更新了相关文档（如有必要）

🔄 定期维护

• 每月更新 .cursorignore（排除新增的无关文件）
• 每季度优化 .cursorrules（总结新的规范）
• 收集常用提示词模板（建立自己的模板库）
• 分享团队最佳实践（统一团队使用方式）

六、总结

核心要点回顾

半年的使用经验，浓缩成这 5 条核心要点：

1. 配置先行
   .cursorignore 和 .cursorrules 是基础，决定了 AI 的理解质量。就像给 AI 配了一副合适的眼镜，让它看得更清楚。

2. 精准提问
   目标 + 要求 + 约束，三要素缺一不可。花 30 秒想清楚需求，胜过花 10 分钟反复沟通。

3. 理解优先
   不要盲目相信 AI，代码的责任人是你。把 AI 当成老师，不懂就问，理解了再用。

4. 版本控制
   Git 分支是你的安全网。做大修改前先创建分支，分批提交，出错了一键回滚。

5. 审查必不可少
   AI 生成的代码必须审查，重点关注：安全、性能、边界条件、业务逻辑。提交前让 AI 做 Code Review，双重保险。

一句话心得

Cursor 不是让你不动脑子写代码，而是让你有更多时间思考架构和业务逻辑。

它把重复性的编码工作交给 AI，让你专注于更有价值的事情：

• 设计系统架构
• 理解业务需求
• 优化用户体验
• 解决复杂问题

我的使用感受

用了半年 Cursor，我的开发效率确实提升了很多：

• ✅ 重复性代码（CRUD、测试用例等）节省 70% 时间
• ✅ 学习新技术更快（直接问 AI，比看文档快）
• ✅ 代码质量更高（AI 帮忙 Review，发现更多问题）
• ✅ 更敢尝试新技术（反正 AI 可以辅助）

但同时也要保持警惕：

• ⚠️ 不能过度依赖，基本功不能丢
• ⚠️ 核心逻辑必须自己理解
• ⚠️ 安全和性能问题不能大意
• ⚠️ AI 是工具，思考才是核心竞争力

写在最后

Cursor 只是工具，真正重要的是：

1. 持续学习的能力 - 技术在变，工具在变，学习力是根本
2. 解决问题的思维 - AI 只能执行，思考和决策还是要靠你
3. 对代码质量的追求 - 不要因为 AI 快就降低标准
4. 团队协作的意识 - 分享经验，共同进步

---

参考资料

• Cursor 官方文档
• Cursor 首席设计师 Ryo Lu 的文章，关于如何正确使用Cursor
• 程序员如何用好 Cursor 工具？- 知乎讨论
• Cursor官方指南：如何在Cursor中处理大型代码库？
• Cursor 使用技巧完全指南 - 知乎
• awesome-cursorrules