# 大型项目Cursor使用技巧宝典 ✨




# 一、引言 🚀
欢迎来到 Cursor大型项目开发秘籍!💡 这里是帮你驾驭AI编程浪潮的终极指南,让你在复杂项目中游刃有余,轻松应对各种挑战!
💼 为什么你需要这份秘籍?
- AI编程工具正在飞速发展 🌊
- 大型项目中实践需求迫切 🏗️
- 系统化使用方法至关重要 🔑
核心观点精华: ✨
AI编程存在多种令人头疼的局限 🤯
- 随机性问题:让你的代码时好时坏
- "偏科"现象:有些语言它特别在行,有些却一窍不通
- "健忘症":上下文窗口有限,长对话就忘东忘西
- "消息滞后":训练数据总是跟不上最新技术
所有AI编程工具功能都是为了应对这些局限而生 🛠️
- Rules功能:降低随机性
- Context工具:对抗健忘症
- 外部集成:弥补消息滞后
掌握Cursor的秘诀:善用功能削弱这些局限 🎯
# 二、AI编程的局限性 🧩
了解敌人,才能制定战略! 👊
# 生成的随机性 🎲
- 代码需要精确性,容不得半点马虎
- 结构化要求高,不是随便拼凑就行
- 错误容忍度低,一个小bug可能导致整个系统崩溃
# "偏科"问题 📊
- 大众语言vs小众技术:Python无所不能,冷门框架就抓瞎
- 训练数据分布不均:有的领域例子多,有的少得可怜
- 新技术适应问题:最新框架?它还没来得及学习呢
# "健忘症" 🧠
- 上下文窗口限制:只能记住这么多,多了就忘
- 长对话记忆衰减:越往后聊,越记不清前面说了啥
- 跨会话信息丢失:关了对话窗口,一切从零开始
# "消息滞后" ⏰
- 训练数据截止日期限制:总是慢半拍
- 新版本兼容性问题:写出来的代码可能已经过时
- 安全性和漏洞风险:不知道最新的安全实践

# 三、Cursor如何应对这些局限 💪
# 1. 应对代码生成随机性 - Cursor Rules功能详解 📝
Rules是你的AI训练师,教会它按你的规则出牌! 🎮
# 方法论**:系统思维、思维树、迭代改进

# 如何编写高质量的Rules文档 ✍️
# 使用通用模板 📋
```
# 角色
你是一名精通 [领域] 开发的高级工程师,拥有10年以上的 [领域] 应用开发经验,熟悉 [技术栈列表] 等开发工具和技术栈。你的任务是帮助用户设计和开发易用且易于维护的 [领域] 应用。始终遵循最佳实践,并坚持干净代码和健壮架构的原则。
# 目标
你的目标是以用户容易理解的方式帮助他们完成 [领域] 应用的设计和开发工作,
确保应用功能完善、性能优异、用户体验良好。
# 要求
在理解用户需求、设计UI、编写代码、解决问题和项目迭代优化时,你应该始终遵循以下原则:
## 项目初始化
- 在项目开始时,首先仔细阅读项目目录下的 README.md文件并理解其内容
- 如果还没有README.md文件,请主动创建一个
## 需求理解
- 充分理解用户需求,分析需求是否存在缺漏
- 选择最简单的解决方案,避免过度设计
## UI和样式设计
- 使用现代UI框架进行样式设计
- 在不同平台上实现一致的设计和响应式模式
## 代码编写
- 技术选型:根据项目需求选择合适的技术栈
- 代码结构:强调清晰性、模块化、可维护性
- 代码安全性:考虑安全性,避免漏洞
- 性能优化:优化性能,减少资源占用
- 测试与文档:编写测试,提供清晰注释
## 问题解决
- 全面阅读相关代码,理解 * 应用的工作原理
- 根据用户的反馈分析问题的原因,提出解决问题的思路
- 确保每次代码变更不会破坏现有功能,且尽可能保持最小的改动
## 迭代优化
- 保持密切沟通,根据反馈调整
- 主动澄清需求或技术细节
- 及时更新文档
## 方法论
- 系统2思维:以分析严谨的方式解决问题。将需求分解为更小、可管理的部分,并在实施前仔细考虑每一步
- 思维树:评估多种可能的解决方案及其后果。使用结构化的方法探索不同的路径,并选择最优的解决方案
- 迭代改进:在最终确定代码之前,考虑改进、边缘情况和优化。通过潜在增强的迭代,确保最终解决方案是健壮的
🔥 快速生成专属Rules的秘诀!
请参考下面这份模板,给我写一份用于开发Python脚本应用的合格的cursorrules文档,这份模板中的*号是占位符,你需要补充相关的信息和技术栈和其它可能需要的信息,文档以markdown格式输出
角色
你是一名精通 开发的高级工程师,拥有10年以上的 应用开发经验,熟悉 等开发工具和技术栈。你的任务是帮助用户设计和开发易用且易于维护的 应用。始终遵循最佳实践,并坚持干净代码和健壮架构的原则。
目标
你的目标是以用户容易理解的方式帮助他们完成 应用的设计和开发工作,确保应用功能完善、性能优异、用户体验良好。
要求
在理解用户需求、设计UI、编写代码、解决问题和项目迭代优化时,你应该始终遵循以下原则:
项目初始化
在项目开始时,首先仔细阅读项目目录下的 README.md文件并理解其内容,包括项目的目标、功能架构、技术栈和开发计划,确保对项目的整体架构和实现方式有清晰的认识;
如果还没有README.md文件,请主动创建一个,用于后续记录该应用的功能模块、页面结构、数据流、依赖库等信息。
需求理解
充分理解用户需求,站在用户角度思考,分析需求是否存在缺漏,并与用户讨论完善需求;
选择最简单的解决方案来满足用户需求,避免过度设计。
UI和样式设计
使用现代UI框架进行样式设计(例如*,这里可以根据不同开发项目仔细展开,比如使用哪些视觉规范或者UI框架,没有的话也可以不用过多展开);
在不同平台上实现一致的设计和响应式模式
代码编写
技术选型:根据项目需求选择合适的技术栈(例如*,这里需要仔细展开,比如介绍某个技术栈用在什么地方,以及要遵循什么最佳实践)
代码结构:强调代码的清晰性、模块化、可维护性,遵循最佳实践(如DRY原则、最小权限原则、响应式设计等)
代码安全性:在编写代码时,始终考虑安全性,避免引入漏洞,确保用户输入的安全处理
性能优化:优化代码的性能,减少资源占用,提升加载速度,确保项目的高效运行
测试与文档:编写单元测试,确保代码的健壮性,并提供清晰的中文注释和文档,方便后续阅读和维护
问题解决
全面阅读相关代码,理解 * 应用的工作原理
根据用户的反馈分析问题的原因,提出解决问题的思路
确保每次代码变更不会破坏现有功能,且尽可能保持最小的改动
迭代优化
与用户保持密切沟通,根据反馈调整功能和设计,确保应用符合用户需求
在不确定需求时,主动询问用户以澄清需求或技术细节
每次迭代都需要更新README.md文件,包括功能说明和优化建议
方法论
系统2思维:以分析严谨的方式解决问题。将需求分解为更小、可管理的部分,并在实施前仔细考虑每一步
思维树:评估多种可能的解决方案及其后果。使用结构化的方法探索不同的路径,并选择最优的解决方案
迭代改进:在最终确定代码之前,考虑改进、边缘情况和优化。通过潜在增强的迭代,确保最终解决方案是健壮的
```
# 根据项目类型定制化 🛠️
Chrome插件开发示例: ``` # 角色 你是一名精通Chrome浏览器插件开发的高级工程师,拥有10年以上的浏览器扩展开发经验, 熟悉JavaScript、HTML、CSS、Chrome Extensions API、Webpack、React等开发工具和技术栈。
# 目标
你的目标是帮助用户完成Chrome浏览器插件的设计和开发工作,确保功能完善、性能优异。
# 要求
## UI和样式设计
- 使用React或Vue.js
- 遵循Material Design或Chrome扩展设计规范
## 技术选型
- JavaScript:主要开发语言,面向对象编程
- HTML:构建页面结构,语义化标签
- CSS:模块化样式设计
- Chrome Extensions API:符合浏览器要求
- Webpack:模块打包,易于维护
##### 技术栈和框架选择 💻
- 根据项目类型选择**最合适**的技术栈
- 遵循行业**最佳实践**,不要重复造轮子
- 考虑团队**技术水平**,别选太难驾驭的框架
- 关注技术**生态成熟度**,避免小众难维护的选择
#### Rules文档编写要点 📌
1. **角色扮演的重要性** 👤
- 让AI成为特定领域专家
- 帮助AI精准定位相关知识
- 提高生成代码的质量
2. **目标设定的作用** 🎯
- 类似公司OKR中的目标
- 为AI提供定性指导
- 确保输出符合预期
3. **具体要求的制定** 📋
- 项目初始化:熟悉历史文档
- 需求理解:查漏补缺
- UI设计:规范视觉交互
- 代码编写:技术选型、结构、安全、优化、测试
- 问题解决:小改动原则
- 迭代优化:及时沟通
- 方法论:系统思维、思维树、迭代改进
#### 使用Rules的注意事项 ⚠️
1. **模型局限性**
- 无法完全消除随机性
- 可能不严格遵守规则
- 需要人工干预和调整
2. **实践建议**
- 定期更新Rules内容
- 根据项目变化调整
- 收集使用反馈优化
```
# 2. 应对上下文限制("健忘症")🧠
让AI拥有超强记忆力的秘密武器! 💪
# Summarized Composers 📝
- 总结Composer对话功能:AI记忆力加倍!
- 使用时机判断:何时该用这个功能?
💡 实用小技巧:在.cursorrules中添加标记
每次回复,都以"收到,亲爱的帅哥,我是你的女仆小克"开头1当Cursor不再使用这个称呼时,说明对话已超出上下文限制!
- 多个Composer对话的管理:多线程工作不乱套
# Optional Long Context 📚
功能说明和开启方式 ⚙️
- 位置:Cursor Settings-Features-Chat&Composer
- 默认关闭,启用会消耗更多fast requests
使用场景 🎬
- 处理大型代码文件(>1000行)
- 需要理解更多上下文
- 分析复杂代码结构
- 处理复杂重构任务
最佳实践建议 👍
- 小型文件保持关闭
- 复杂任务时开启
- 根据响应准确度调整
# README.md项目结构管理 📘
- 记录项目整体架构:让新人快速上手
- 持续更新维护:保持文档与代码同步
- 与@File指令配合使用:精准定位代码
# Notepads常用逻辑保存 📒
动态模板生成示例:
# API Development Guidelines ## Endpoint Structure - Use RESTful conventions - Base URL: `/api/v1` - Resource naming in plural form ## Authentication - JWT-based authentication - Token format: Bearer {token} - Refresh token mechanism required1
2
3
4
5
6
7
8
9
10
11架构文档管理:一处修改,处处生效
开发指南维护:团队协作必备工具

# 3. UI生成优化策略 🎨
打造惊艳用户的界面,不再是设计师的专利! ✨
# 常见UI组件库/风格+文字描述 📚
主流UI组件库介绍 🧩
React UI组件库: - Material-UI - Ant Design Vue.js UI组件库: - Element UI 通用UI组件库: - Bootstrap1
2
3
4
5
6
7
8
9通用UI风格指定 🖌️
常见UI风格: - Apple Design:苹果设计风格 - Material Design:谷歌设计风格 - Ant Design:企业应用风格 - Glassmorphism:磨砂玻璃风格 - Flat Remix:扁平化风格1
2
3
4
5
6示例提示词 💬
参考Apple Design风格对UI进行重构优化,整体功能架构保持不变1或
参考Glassmorphism风格对UI进行重构优化,整体功能架构保持不变1
# 参考图+具体描述方法 🖼️
竞品参考示例 👀
这个小程序有三个页面,分别是首页、订单、我的。 三个页面共享底部的Tabs,点击Tabs上的三个按钮可以切换至不同页面, 我们目前已经有了"首页",请为"订单"和"我的页面"分别创建页面, 页面信息可以参考上传的图片(暂时不用考虑这两个新页面的功能实现), UI风格需要和原来的风格保持一致。1
2
3
4
5任务分离原则 ✂️
- 先完成UI再实现功能
- 避免同时处理多个任务
- 保持UI风格一致性
# v0生成前端UI,Cursor后期微调 🔄
- v0的优势 🚀
- UI审美在线
- 高度还原参考图
- 支持细节实现(如icon)
- 使用方法 📋
- 通过参考图生成
- 直接描述生成
- 代码集成方式:
- 复制终端指令运行
- 下载打包代码导入
# Figma/Pixso设计稿转代码 🔄
工具介绍 🛠️
Figma to code(需要会员)
Pixso to code(免费)
相关链接: - Pixso官网:https://pixso.cn/ - Pixso插件:https://pixso.cn/plugins/1
2
3
使用流程 📋
- 准备设计稿
- 使用插件转换代码
- 将代码集成到项目中
- 使用Cursor进行微调
# UI优化最佳实践 🏆
选择合适的优化方法 🎯
- 简单项目:组件库/风格描述
- 有参考产品:参考图+描述
- 高质量要求:v0/设计稿转换
避免常见问题 ⚠️
- 不要同时处理UI和功能
- 保持风格统一
- 注意组件复用
效率提升技巧 🚀
- 建立UI组件库
- 保存常用样式
- 记录优化模式
# 4. 项目结构优化 🏗️
好的架构是成功项目的一半! 💯
前期代码结构拆解的重要性 🧩
- 避免功能杂糅
- 降低重构风险
- 保持功能完整性
代码结构核心原则 📏
- 模块化:功能分离,降低耦合
- 职责分离:单一职责原则
- 可扩展性:便于添加新功能
- 可读性:清晰的目录结构
项目结构设计案例 📚
Web应用(博客网站)示例:
blog-project/ ├── client/ # 前端代码(React) │ ├── public/ # 静态文件 │ │ └── index.html # 入口HTML │ ├── src/ # 前端核心代码 │ │ ├── assets/ # 图片、CSS样式 │ │ ├── components/ # 可复用组件 │ │ ├── pages/ # 页面组件 │ │ ├── context/ # 状态管理 │ │ └── App.js # 主入口 ├── server/ # 后端代码(Node.js) │ ├── config/ # 配置文件 │ ├── models/ # 数据库模型 │ ├── routes/ # API路由 │ ├── middleware/ # 中间件 │ ├── controllers/ # 控制器 │ └── index.js # 后端主入口 ├── tests/ # 测试代码 └── README.md # 项目说明1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# 5. 应对"消息滞后" 🕰️
让AI跟上最新技术潮流的秘密武器! 🔮
- 外部工具集成 🧰
- @web实现联网搜索
- @docs阅读外部文档
- MCP (Model Context Protocol)工具
- Context7和其他第三方工具
# 四、Cursor官方最佳实践 🏆
直接采用官方推荐,少走弯路! 💼

# 设定清晰项目规则 📋
- 项目初期设定5-10条规则
- 根据项目规模调整规则数量
- 分层级:通用规则、语言规则、框架规则
# 编写具体的提示词 🔤
详细说明技术栈和约束
提示词案例分析
Web贪吃蛇游戏案例:
请帮我开发一个web版贪吃蛇游戏,尽量不引入外部依赖1Chrome图片转换插件案例:
请帮我开发一个"图片转png"Chrome浏览器插件,这个插件的功能是: 1、开启插件后,用户在浏览器图片鼠标右键后会出现插件入口"下载为png" 2、支持下载为png的图片格式包括JPG、JPEG、PNG、BMP、webp、svg 3、使用OffscreenCanvas避免阻塞主线程 4、通过Blob URL减少内存占用1
2
3
4
5登录页面UI优化案例:
请优化LoginPage的UI,使其符合现代简约风格, 具体要求: 1、布局:登录表单居中,使用卡片式设计(圆角8px,轻微阴影) 2、配色:主色调深蓝(#1E3A8A),背景浅灰(#F9FAFB) 3、字体:标题用Poppins加粗,正文用Inter常规 4、交互:输入框聚焦时边框变蓝,按钮悬停时轻微变深 5、参考风格:类似Notion的登录页面,但更简洁一些 整体功能架构保持不变1
2
3
4
5
6
7
8
# 按模块推进开发 🧩
小项目vs中大型项目的策略 📊
- 小项目:一次性生成全部代码
- 中大型项目:按模块逐步实现
功能模块化原则 📐
- 示例:电商系统模块拆分,推荐:先使用DDD划分模块
1. 用户模块:注册、登录、个人信息 2. 商品模块:列表、详情、搜索 3. 购物车模块:添加、删除、结算 4. 订单模块:创建、支付、查询 5. 后台管理模块:商品、订单、用户管理1
2
3
4
5逐个模块解决方案 🧠
- 先完成核心模块
- 逐步添加功能模块
- 注意模块间依赖
# 测试驱动开发 🧪
先写测试后生成代码 ✅
- 示例:用户注册功能测试
describe('User Registration', () => { it('should create new user with valid data', async () => { const userData = { username: 'testuser', email: 'test@example.com', password: 'Password123!' }; const response = await request(app) .post('/api/users/register') .send(userData); expect(response.status).toBe(201); expect(response.body).toHaveProperty('id'); }); });1
2
3
4
5
6
7
8
9
10
11
12
13
14使用.cursorignore保护测试 🛡️
为什么需要保护测试文件?
场景举例:假设你正在开发一个用户注册功能 1. 你先写了测试用例,确保注册时: - 用户名不能重复 - 密码必须包含大小写字母和数字 - 邮箱格式必须正确 2. 让Cursor生成实现代码时,如果不保护测试文件,可能会发生: - Cursor为了让测试通过,直接修改测试用例 - 比如把"密码必须包含大小写字母和数字"的测试改成"密码长度大于6" - 这就违背了测试驱动开发的初衷1
2
3
4
5
6
7
8
9
10配置示例和解释:
# 测试文件保护 **/*.test.js # 保护所有以.test.js结尾的测试文件 **/*.spec.js # 保护所有以.spec.js结尾的测试文件 __tests__/ # 保护测试目录 test/ # 保护测试目录 # 构建输出保护 build/ # 保护构建产物目录 dist/ # 保护分发目录 # 依赖保护 node_modules/ # 保护依赖包 # 环境文件保护 .env # 保护环境变量文件 .env.* # 保护所有环境变量文件1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16- 实际应用示例:
项目结构: my-project/ ├── src/ │ ├── user/ │ │ ├── register.js # 实现代码 │ │ └── register.test.js # 测试代码 │ └── auth/ │ ├── validation.js # 实现代码 │ └── validation.test.js # 测试代码 ├── .cursorignore # 保护配置 └── package.json 测试代码 (register.test.js): describe('User Registration Validation', () => { test('should reject duplicate username', async () => { // 测试用户名重复校验 const existingUser = { username: 'testuser', email: 'test@example.com', password: 'Password123!' }; await registerUser(existingUser); const duplicateUser = { username: 'testuser', email: 'another@example.com', password: 'Password456!' }; await expect(registerUser(duplicateUser)) .rejects .toThrow('Username already exists'); }); test('should validate password complexity', () => { const weakPasswords = [ 'password', // 没有大写字母和数字 'Password', // 没有数字 'password123', // 没有大写字母 ]; weakPasswords.forEach(password => { expect(validatePassword(password)).toBe(false); }); expect(validatePassword('Password123!')).toBe(true); }); }); 使用Cursor生成实现代码的提示词: @file src/user/register.js 请根据register.test.js中的测试用例要求,实现用户注册功能, 需要包含: 1. 用户名重复检查 2. 密码复杂度验证(必须包含大小写字母和数字) 3. 确保实现符合测试用例的要求 由于.cursorignore的保护,Cursor不会修改测试文件, 而是专注于实现符合测试要求的代码。1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
# 五、我常用的一些方式 💡
实战经验分享,让你直接起飞! 🚀
# 需求开发 📋
需求分析模板 📝
1. 功能描述 - 具体功能点 - 用户场景 - 预期效果 2. 技术要求 - 前端技术栈 - 后端技术栈 - 第三方依赖 3. 性能要求 - 响应时间 - 并发处理 - 资源占用1
2
3
4
5
6
7
8
9
10
11
12功能拆解示例 🧩
实现步骤规划 📊
# 方案+选择+优化+实现 🔄
系统化解决问题的流程,让开发更加高效! 🚀
# 需求设计方案阶段 📝
问题分析模式 🔍
例:前端状态管理问题 1. 需求场景:编辑模式下的状态管理 2. 痛点分析: - 状态标识需求(表单修改状态) - 数据修改类型区分(参数/其他数据) - 前端逻辑耦合度高 - 编辑状态下功能限制 3. 初步构想: - 提取store存储编辑态 - 记录/清空状态机制 4. 现有方案缺陷: - 视图组件状态变换代码重复1
2
3
4
5
6
7
8
9
10
11
12多方案对比思路 ⚖️
请求特性: 1. 三个解决方案 2. 各方案优缺点分析 3. 使用设计模式,遵循接口与抽象原则 4. 保证职责单一1
2
3
4
5需求细节再确认 🔄
主动询问: - 业务规则细节 - 拓展需求可能性 - 技术选择倾向(性能vs可读性) - 潜在知识点补充(如指令方式)1
2
3
4
5
# 方案选择与示例阶段 🔎
示例代码请求模式 👨💻
选定方案后: - 请求具体使用示例 - 不需完整代码,重点展示修改思路 - 结合现有代码给出实施路径1
2
3
4
# 范围调整与优化阶段 🔧
需求聚焦模式 🎯
例:渐进式开发需求 - 关注核心痛点(如保存时状态保持) - 预留拓展空间 - 寻求过渡方案1
2
3
4可视化理解请求 📊
请求内容: 1. 时序图(Mermaid语法) 2. 类图(Mermaid语法) 3. 简短调用示例1
2
3
4
# 实现与测试阶段 🧪
指定文件实现模式 📂
明确实现范围: - 指定实现文件路径 - 生成对应测试用例 - 测试覆盖关键逻辑1
2
3
4利用Cursor指令优化 ⚡
特殊提示语法: - 使用@file指定操作文件 - 使用v-指令添加公共逻辑 - 通过提示词引导AI思考1
2
3
4
# 代码阅读 📖
代码结构分析 🔍
@folder src 请帮我分析这个项目的代码结构,重点关注: 1. 核心模块及其职责 2. 模块间的依赖关系 3. 可能的性能瓶颈 4. 代码复用情况1
2
3
4
5
6关键流程追踪 🔄
性能优化点识别 ⚡
实际示例:
# 方案+选择+优化+实现
## 需求设计方案:
```
现在有一个需求,我在@xxx.vue 点击修改的时候,会进入修改模式,修改的时候,涉及众多组件在@composite 下。目前因为后端的接口粒度太大,导致前端需要承载业务部分,比如说:
1. 需要状态标识,表单是否进行了修改。
2. 需要知道修改的部分是参数,还是其他的数据修改了,方便针对性处理联动数据。
3. 目前逻辑的偶和在前端很大,需要解耦。
4. 我希望在修改状态下,需要限制其他模块或者当前模块的按钮功能。
我当前的想法是:
1. 提取一个store存储编辑态,在前端页面又修改的时候,则记录状态,取消或者保存的时候则清空状态。
我觉得不好的地方是:
1. 很多视图组件都需要加入状态变换,代码重复比较多。
给我三个方案,并且说明优缺点。
```
```
我想知道有没有更好的方案,或者可以解决我痛点的代码编写方式,可以使用一些合适的设计模式,尽量是有接口和抽象的方式设计方案,保证职责单一。
```
```
你需要再确认一些细节,防止后续的开发方案有变化,尽量方便拓展,可以问我相关的业务规则和细节,我会给你答案,看看方案是否需要更改。
```
> tip: 我想知道有没有更好的方案(知识点补充)? 有时候可能有惊喜。
>
> 我本来不知道有<指令>的方式,给组件加入公共逻辑。
> `<el-input v-placeholder-hint></el-input>`
> 代码性能问题优先?还是可读性优先?
## 查看方案+示例:
```
使用方案一的话,结合我的代码给我一个具体的使用例子,不需要完整代码,让我明白如何修改即可。
```
## 范围调整:
1. 方案优化
```
我想要快速完成需求,我想要的渐进式的开发,你现在的方案我感觉考虑的很多的东西,我希望预留拓展,但是目前我主要想解决的问题是:
在@bizcode_tree.vue 表单点击<保存>的时候,@bizCore_table_tree.vue 的勾选状态不要跟着我调用接口刷新后去掉。
你有没有更好的方式,支持我一步一步的过渡呢?
```
2. 画图理解
```
我觉得你的局限性说的很对,我希望能够统一管理,但是不需要考虑全,但是需要分模块,方便后续的功能拓展。重新设计一个方案,不用具体实现,给我画出时序图、类图(使用Mermaid语法),还有就是最后的简短的调用示例。
```
3. 指定文件及测试
```
在@codeFile下实现我的需求,并且@codeFile_test文件下生成对应的测试用例。
```
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
方案阶段以及阅读代码时,尽量让AI根据代码生成Mermaid语法的时序图/类图等。
# 六、高级使用技巧 🔥
进阶玩法,让你的AI开发能力再上一层楼! 🚀
# Agent系统理解与应用 🤖
你是一名功能强大的自主AI编码助手,由 Claude 3.7 Sonnet 提供支持。你只在世界上最好的 IDE——Cursor 中专门运行。
你正在与一位 USER 进行结对编程,以解决他们的编码任务。 该任务可能需要创建一个新的代码库、修改或调试现有代码库,或者只是回答一个问题。
每次 USER 发送消息时,我们都可能自动附加一些有关他们当前状态的信息,例如他们打开了哪些文件、光标位置、最近查看的文件、到目前为止会话的编辑历史、linter 错误等更多内容。
这些信息可能与编码任务相关,也可能无关,由你来决定。你的主要目标是在每条消息中遵循 USER 的指示。
<tool_calling>
你有可用的工具来完成编码任务。请遵守以下关于工具调用的规则:
始终严格按照指定的工具调用模式进行,并确保提供所有必要的参数。
此对话可能引用一些不再可用的工具。切勿调用未明确提供的工具。
在与 USER 交谈时,绝不要提及工具名称。 例如,不要说"我需要使用 edit_file 工具来编辑你的文件",只要说"我将编辑你的文件"即可。
只有在必要时才调用工具。如果 USER 的任务是一般性的,或者你已经知道答案,那么无需调用工具,直接回答即可。
在调用每个工具之前,先向 USER 解释你为什么要调用它。
</tool_calling>
<search_and_reading>
如果你对 USER 的请求答案不确定,或者不知道如何满足他们的请求,你应该收集更多信息。 这可以通过额外的工具调用、提出澄清性问题等方式完成……
例如,如果你进行了语义搜索,结果可能并不能完全回答 USER 的请求,或者需要收集更多信息,也可以随时调用更多工具。
同样,如果你进行了某个编辑,可能只能部分满足 USER 的请求,但你不确定,可以在结束回合前收集更多信息或使用更多工具。
倾向于不要向用户寻求帮助,如果你可以自行找到答案的话。
</search_and_reading>
<making_code_changes>
当需要进行代码更改时,除非被请求,否则绝不要向 USER 输出代码。相反,应使用其中一种代码编辑工具来实现更改。
每回合最多只能使用一次代码编辑工具。
让你的生成代码能够被 USER 立即运行是极其重要的。为确保这一点,请仔细遵循以下说明: 添加所有必要的 import 声明、依赖和端点,以便运行代码。
如果你是从头开始创建代码库,则需要创建一个合适的依赖管理文件(例如 requirements.txt),其中包含包的版本和有用的 README。
如果你从头开始构建一个 web 应用程序,请为其提供美观且现代的 UI,并带有最佳用户体验实践。
切勿生成非常长的哈希值或任何非文本代码(如二进制),因为这对 USER 没有帮助并且成本高昂。
除非你只是向一个文件追加一些很容易应用的编辑,或创建一个新文件,否则你必须先阅读你要编辑的文件的内容或你要编辑的部分,然后才能进行编辑。
如果你引入了(linter)错误,并且你清楚如何修复(或可以很容易地找到修复方法),就进行修复,不要盲目猜测。并且不要在同一个文件上针对 linter 错误循环超过 3 次。如果在第三次仍无法修复,你应该停止并询问用户下一步该怎么做。
如果你建议的一个合理的 code_edit 没有被应用模型跟进,你可以尝试重新应用该编辑。
</making_code_changes>
<calling_external_apis>
除非 USER 明确要求,否则可以使用最合适的外部 API 和包来完成任务。无需征求 USER 的许可。
当选择 API 或包的版本时,选择与 USER 的依赖管理文件兼容的版本。如果不存在此文件或其中没有该包,则使用你训练数据中存在的最新版本。
如果外部 API 需要 API Key,请务必向 USER 指明。遵循最佳安全实践(例如,不要在可能暴露的位置对 API Key 进行硬编码)
</calling_external_apis>
<user_info>
用户的操作系统版本是 darwin 24.3.0。用户工作区的绝对路径是 $PATH。用户的 shell 是 /bin/zsh。
</user_info>
回答 USER 的请求可以使用相关工具(如果可用)。请检查每个工具调用所需的所有参数是否已提供或可以从上下文中合理推断。
如果没有相关工具或缺少必要的参数,请让 USER 提供这些值;否则继续进行工具调用。
如果 USER 为某个参数提供了特定值(例如带引号),请确保精确使用该值。不要自行编造或询问可选参数。仔细分析请求中的描述性术语,因为它们可能表明应该包含一些必需的参数值,即使未明确说明。
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
🧐 透析Cursor的幕后系统!
1、首先从提示词的设计上看,应该不是最新的,模型驱动那块描述大概率是个变量,因为在Cursor新版中是支持自动选择模型的。
2、之所以在系统提示词中进行注明,是因为大模型有时候不会准确告诉我们它在用什么模型运行(大家之前可能就遇到过模型答非所问的情况),明确指出这一点大概率是为了避免用户投诉说他们指定用的计费模型和实际不一致。因为Cursor是按高级模型(Claude 3.5/3.7,GPT-4o等)以及非高级模型(如DeepSeek、GPT-4o-mini等)进行收费的。
3、如果大家经常用Cursor,应该可以从自己的使用经历中,发现很多和提示词相吻合的点,比如为了让我们可以更方便地运行Cursor生成的代码,它在代码生成后一般会同时给到相应的终端指令以及运行步骤;又比如需要调用外部API的时候,它会提示你不要暴露并给出最佳安全实践等等。
4、与此同时,大家可能也发现了另一点,就是系统提示词没法完全解决大模型生成随机性的局限,只能说降低这种随机性。大家平时大概率还是会遇到Cursor不遵守提示词的情况。
2
3
4
5
6
7
# 与其他工具组合使用 🛠️
强强联手,工具协同,效率翻倍! 💪
# 主流MCP工具集成 🔌
- GitHub:版本控制工作流集成
使用GitHub MCP可以: 1. 直接管理仓库和文件 2. 处理Issues和PR 3. 查看代码变更历史 🔗:https://github.com/github/github-mcp-server - Browser Tools:Web应用调试
Browser Tools功能: 1. 监控浏览器活动 2. 捕获屏幕截图 3. 分析网络日志 4. DOM交互操作 🔗:https://github.com/AgentDeskAI/browser-tools-mcp - File System:文件系统访问
File System MCP能力: - 获取文件元数据 - 检索修改时间 - 查看文件权限 - 识别文件类型 🔗:https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem - Git Tools:仓库操作自动化
Git Tools功能: 1. 状态查看和diff比较 2. 提交管理 3. 分支管理 4. 自动化Git任务 🔗:https://github.com/modelcontextprotocol/servers/tree/main/src/git - Sequential Thinking:结构化问题解决
Sequential Thinking特点: 1. 结构化推理 2. 复杂任务分解 3. 逐步解决问题 🔗:https://github.com/modelcontextprotocol/servers/tree/main/src/sequentialthinking
# 专业化MCP应用 🧰
- Context7:AI友好文档集成
使用Context7优势: 1. 自动获取最新技术文档 2. 降低文档复制粘贴成本 3. 提供准确的API参考 🔗:https://github.com/upstash/context7 - Perplexity:AI研究支持
Perplexity特点: 1. 智能研究辅助 2. 深度分析能力 3. 研究结果整合 🔗:https://github.com/ppl-ai/modelcontextprotocol - Magic UI:UI生成优化
Magic UI功能: 1. 智能UI生成 2. 界面优化建议 3. 设计模式应用 🔗:https://github.com/21st-dev/magic-mcp - Supabase:后端集成方案
Supabase集成优势: 1. 数据库操作简化 2. 认证服务集成 3. 实时功能支持 🔗:https://github.com/supabase-community/supabase-mcp
# 浏览器工具MCP 🌐
Fetch:网页内容获取
Fetch MCP用例: 1. 抓取HTML内容 2. 获取JSON数据 3. 下载Markdown文档 🔗:https://github.com/zcaceres/fetch-mcp https://github.com/modelcontextprotocol/servers/tree/main/src/fetchFireCrawl:高级网页抓取
FireCrawl功能: 1. 处理JS渲染页面 2. 批量数据抓取 3. 深度页面爬取 4. 结构化数据提取 🔗:https://github.com/mendableai/firecrawl-mcp-serverBrowser Use:浏览器控制
Browser Use特点: 1. 自然语言控制 2. 表单自动填写 3. 视觉内容理解 4. 复杂交互自动化 🔗:https://github.com/Saik0s/mcp-browser-usePuppeteer/Playwright:自动化测试
自动化测试工具特点:
浏览器自动化操作
页面交互模拟
截图功能
跨浏览器测试支持
🔗:https://github.com/modelcontextprotocol/servers/tree/main/src/puppeteer 🔗:https://github.com/microsoft/playwright-mcp
browser mcp 也挺好用~,基于 playwright 改的
# 七、总结 🎯
掌握了这些技巧,你就是AI编程高手! 🏆
# 工具使用关键在于理解工具本质 🧠
认识AI编程的固有局限 ⚠️
主要局限: 1. 代码生成随机性 2. 语言覆盖不均衡 3. 上下文记忆限制 4. 训练数据时效性1
2
3
4
5理解工具功能的设计初衷 💡
设计原则: 1. 降低随机性影响 2. 扩展上下文范围 3. 保持数据更新 4. 提供专业化支持1
2
3
4
5掌握局限应对的方法论 🛠️
# 所有AI编程工具都是围绕局限打造功能 🧩
Rules系统降低随机性 📏
实现方式: 1. 角色精确定位 2. 目标明确设定 3. 规则分层管理1
2
3
4Context工具扩展记忆 🧠
解决方案: 1. 对话总结复用 2. 文档结构管理 3. 模板系统建设1
2
3
4外部集成保持更新 🔄
# 善用Cursor功能来削弱这些局限 💪
- Rules功能应对随机性
- 上下文管理工具应对"健忘症"
- UI优化策略提升界面质量
- Agent系统提升协作效率
# 未来发展方向与趋势 🚀
更多细分工具涌现 🛠️
预期方向: 1. 专业领域工具 2. 效率提升工具 3. 协作增强工具1
2
3
4- 工具能力持续增强
- 用户使用门槛降低
- 生态系统不断完善
# 八、问答环节 ❓
有问题?我们来解答! 💬