编程神器 Cursor:怎么用 AI 写一个完整的项目?出了城,吃着火锅还唱着歌,突然就把项目写完了!
我坚信 AI 是普通人变强的“外挂”,特别是 AI 分析、AI 写作、AI 编程、AI 自动化。
已是编程大佬
AI 编程工具:Claude 3.5 sonnet、o1 Pro、Cursor
在淘宝上买的,27 块钱一个月。
使用体验:
现在写代码方面 Cursor 和 Claude 3.5 结合,不需要编程技能就能编程,太好用了!
- Claude 3.5 和通用场景不同,专为解决企业问题,ta的编程能力要好于 GPT4o
- cursor 的 codeBase 是整个工程,和copilot、通义灵码基于当前文件不同
- 分析了你整个工程的代码基础之上给的建议,那是非常精准啊
- cursor 的逻辑是,先将工程内的所有代码进行索引和向量化(Embedding),再之后你的所有提问都是基于整个工程给你答案,它会将你的提问结合整个工程的代码一起提交给 LLM
- 完全可以替代人了,我不需要招那么多人来干那些 “脏活累活” ,我只需要几个高级并且会使用高级工具的人才就可以了,他们创造的人效是原来的 10 倍以上
Claude 3.5 Sonnet提供最长200k token的上下文长度,代码项目经常不够。
Cursor 解决了这个问题:
-
第一个重磅升级,堪称代码界的"精准狙击手"!
不再是漫无目的地抓取代码,而是像经验丰富的老司机一样,精准锁定任务相关的核心代码。
这样的智能筛选让上下文长度大幅缩减,直接让你的多步骤任务调优如丝般顺滑,一口气做完都不带喘的!
-
第二个王炸级更新,简直就是开发者的"省心利器"!
巧妙避开了所有"不必要"的代码内容,不仅让任务调优更加高效,更是帮你的钱包减轻了不少负担。
这波操作,对于我们这些追求极致性价比的程序员来说,简直是雪中送炭啊!
中文版 Cursor
下载 Cursor,找到扩展(Ctrl+Shift+X) -> 搜索 Chinese -> 中文插件:
然后点击这个插件,上面有使用说明书,3个步骤改成中文版 Cursor。
左下角好了后会弹出,猛击后,重启就是中文版。
Ctrl+L,打开 LLM 聊天面板。
o1 Pro、Claude 3.5 sonnet 分析需求
你要完成一个项目,关键在于分析清楚需求。
一般我们要和 AI 进行多轮讨论。
我的需求分析框架(我喜欢用 o1 Pro 分析):
## 问题解决框架
### 通用流程框架
1. 确认目标
2. 分析过程(使用目标-手段分析法)
3. 实现步骤
4. 代码封装(适用时)
### 目标-手段分析法
1. 确认最终目标(问句形式)
2. 层层分解问题
- 将大问题分解为小问题(按照公式法、要素法、流程法、列举法、二分法拆解,问句形式)
- 确保每个小问题都有对应解决手段
3. 代码实现
- 面向过程,还是面向对象
- 写出框架即可,每个函数的定义和中文注释,不具体实现
我想设计 xxx,要 yyy
请帮我设计一下,不写代码,只是用文字把需求搞清晰
去创造去完成一个产品的过程,也是你思考的过程。
你没办法完全想清楚了才行动。
你需要行动中各种返回你才有机会想清楚。
真正的产品成长来自于:快速发布、收集反馈、持续改进、定期更新。
Cursor 写代码经验
在 Cursor 找到 AI 聊天界面,把需求给 TA,代码是 python。
就在 Cursor 中运行,出了问题,一直丢报错信息、你的预期和现状,最终就能完成了。
让 Cursor 从项目一开始就写 README.md 文档,记录清楚产品功能、实现技术栈等,并且让它在完成关键节点后及时更新。
让 Cursor 写代码时写清楚各个代码块的注释,帮助你自己学习和理解实现逻辑。
使用 Composer 和 Chat 功能时,尽量多 @codebase,否则 Cursor 常有幻觉,不知道项目内容是什么。
分步提示词:
- 明确功能:用 python 设计冒泡排序算法
- 分析逻辑:写出实现逻辑步骤
- 生成代码:根据上述逻辑编写完整代码
- 整体关联:添加注释并解释每行代码的作用
在 Cursor 中找到 Fearures 打开 composer(允许用户通过自然语言命令,进行多文件编辑和代码生成)。
Cursor 编程心态
回想我学习编程的过程,经常是在惊讶中学习的。
我自认为自己理科不错,逻辑缜密。但是在学习计算机的过程中,却经常惊讶地发现:用我“缜密”的逻辑,编写出的“完美”的代码,竟!然!是!错!的!
这怎么可能?!
我无法置信。一定是计算机有问题!
于是,我开始调试,开始跟踪,开始认真看我“完美”的程序在计算机中的每步执行,看每一个变量在如何变化。我小心地去寻找,一定要找到,计算机究竟哪里出了问题。
直到我找到了自己的问题,我又学到了新东西。
说出来可能很多人不相信,我是非常喜欢 debug 的。
这其中的原因就在于:但凡是我写出的代码,我坚信已经思考得很清晰了。但为什么会出错?这太不可思议了!我一定要把这个错误找出来!
这种惊讶,让我保持着学习的动力。
错误、Bug 也是非常有趣的。
在踏入编程领域后,你会发现一个有趣的现象:实际开发工作中,80%以上的时间并非在编写新功能,而是在与AI协作解决各种技术难题和bug。
但是我想告诉你这很正常。
现在大厂内资深程序员的大多数时间也是在解bug,维护代码屎山,而非在写代码。
然而,AI的出现给这个"困境"带来了转机。
在AI的协助下,现代程序员在以下方面都获得了显著提升:
- 问题诊断和修复的效率
- 复杂系统的维护能力
- 新项目的上手速度
你依然会遇到很多问题,但你能比以往任何时候都快10倍、100倍学会。
改 bug 提示词
请一步步思考,仔细审查现在的报错提醒和相关代码,分析发生这个问题的原因是什么,并给我提供三个最solid地解决方案,不要急着改代码。
代码是一个项目,整体是关联的。
不能哪里报错就改哪里,而是要深度分析:
问题究竟是什么 -> 有哪些解决思路 -> 对比来看不同解决思路的优缺点为何 -> 我该选择哪个解决方案
通过这种让Cursor深度思考 + 提供多套解决方案的方式实现思维链,相比直接改代码,效果其实有了相当大的提升。
如果老是一个 Bug 循环,基本上是你提示词没写好
你那一两句话缺乏上下文背景,缺乏对问题思考的提示词才是造成问题的关键
必须为AI提供丰富完整的背景信息,包括你的目标是什么,你遇到了什么问题,你希望如何解决的信息。
1、你们正在做一个什么样的项目(如果对话上有上下文了,可以暂时忽略)
2、你是在期望完成什么功能,或调整什么内容时遇到的bug
3、现在这个bug的表现,在用户使用层是什么样的?
4、在控制台或者终端,你获得了什么样的代码输出?
5、你判断这次错误和哪些代码文件有关,通过 @ 的方式去提供给AI作为上下文。
6、你希望以什么样的方式解决,你对解决方式有哪些特殊要求(建议在一次无法修复完成的复杂bug场景下让AI先不要急着改代码,先给你提供不同的解决方案)
但上下文也不能太多。
每完成一个新功能,或者解决一个bug后,做新的对话,避免过长上下文。
尽量在项目初期和完成任何关键节点的功能之后,让Cursor去写包含项目目标、功能、技术栈、文档结构等内容的Readme文档,你在必要的时候更多@reademe文档而不是整个代码项目,这样既能实现同样的让AI理解项目的效果,同时也不会太占用上下文的token。
解决新 bug,又把老 bug 搞出来了
AI 在修复新的 bug 时,有时会重新引入之前已经修复过的 bug,似乎没有"记忆"或全局搜索的能力。
两个解决方案:
-
针对单个项目的解决方案:
- 在项目的 README 文档中记录主要需要避免的错误类型
- 在与 AI 对话时,经常引用(@)这个文档,提醒 AI 注意这些已知问题
-
针对多个项目的通用问题:
- 将需要规避的常见错误写在 “rules for ai”(AI 规则)文档中
- 这样可以作为跨项目的通用指导
由于 AI 模型不能记住所有历史对话和修改,所以需要通过文档的方式来持续提醒 AI 注意特定的问题和规则。这是一种使用文档来扩展 AI "记忆"的变通方法。
system prompt
# Role & Background
你是一位拥有 20 年经验的全栈技术专家,精通产品设计与工程实现。你需要用简单易懂的方式与用户交流,因为他们可能不擅长表达技术需求。把每个任务都当作价值 10000 美元的重要项目来对待。
# Core Principles
1. 主动性:主动思考和补充用户需求,而不是被动等待指示
2. 简单性:始终选择简单可维护的解决方案
3. 文档驱动:所有决策和变更都要反映在文档中
# Workflow
## 1. 项目理解
- 优先阅读/创建 README.md
- README.md 必须包含:
* 项目目标和架构
* 功能说明和接口文档
* 使用示例和注意事项
## 2. 任务处理
### 需求分析
- 透彻理解用户真实需求 --- 站在用户的角度思考,如果我是用户,我需要什么?
- 主动发现和补充需求盲点 --- 作为产品经理理解用户需求是否存在缺漏,你应当和用户探讨和补全需求,直到用户满意为止;
- 通过提问确认需求完整性
### 代码开发
- 遵循 SOLID 原则和设计模式
- 添加清晰的注释和错误处理
- 实现可监控和可维护的代码
### 问题排查
- 全面分析代码上下文 --- 理解所有代码的功能和逻辑
- 提供可验证的解决方案 --- 思考导致用户所发送代码错误的原因,并提出解决问题的思路
- 通过交互式沟通完善方案 --- 应当预设你的解决方案可能不准确,因此你需要和用户进行多次交互,并且每次交互后,你应当总结上一次交互的结果,并根据这些结果调整你的解决方案,直到用户满意为止
## 3. 持续优化
- 记录解决方案要点 --- 在完成用户要求的任务后,你应该对改成任务完成的步骤进行反思,思考项目可能存在的问题和改进方式
- 更新在readme.md文件中
- 提供改进建议
# Quality Standards
- 代码:简洁、可维护、有注释
- 文档:完整、清晰、易理解
- 沟通:主动、耐心、专业
Rules for AI
这是 Cursor 编辑器的 AI 规则设置界面,用来配置 AI 助手的行为规则和工作方式。具体来说:
-
Rules for AI(AI 规则)
- 这些规则会在所有聊天和 Ctrl-K(快捷命令)会话中显示给 AI
- 你可以在文本框中输入具体的规则,比如示例中提到的 "always use functional React(总是使用函数式 React)"等
-
Include .cursorrules file(包含 .cursorrules 文件)
- 这是一个开关选项
- 如果关闭,则不会在你的 AI 规则中包含任何 .cursorrules 文件
- .cursorrules 文件可以理解为是一个单独的规则配置文件
这个设置的作用是让你能够:
- 统一定制 AI 助手的行为方式
- 设置编程风格偏好(如示例中提到的使用函数式 React)
- 规定输出格式(如示例中提到的用葡萄牙语回答)
- 设置其他工作习惯和规范
比如,你可以设置规则让 AI:
- 始终使用特定的代码风格
- 按照特定的架构模式写代码
- 用特定的语言回答问题
- 遵循项目特定的开发规范
这就像是给 AI 助手一个统一的"工作指南",确保它始终按照你期望的方式工作。
.cursorrules 相当于给cursor的readme,在每次调用api的时候,除了现在的代码结构和上下文之外,再增加一个规则的限定(每次执行AI命令都需要在这个规则下限制执行)。
要是没这个,cursor老是会忘记自己在用哪个框架或者一些限制,改起来也会乱七八糟的。
这个文件的建立很简单,就在项目的根目录下建立.cursorrules文件即可。
写法就和t提示词一样,可以包括的是角色(比如python的fastapi框架的专家、架构师等)、规则(每次生成的时候一些规则和规范,可以个性化)、目录结构(比如解释下这个框架下什么代码放在什么目录之下)、参考文档(每次写的时候需要参考那些文档)。
要是你不会写,可以参考这里:https://cursor.directory/
Cursor 设置方案
挽弓当挽强,用模当用长。
不牛逼的模型都关了。
全部 enabled。
关闭联网搜索。
通通 enabled。
上传 git
cursor 终端 输入命令:
# 初始化Git仓库
git init
# 代码更改后 输入命令 会把更改的代码 放到暂存区
git add .
# 提交更改
git commit -m "提交说明 - 这次更改了什么内容"
# 查看提交历史
git log --oneline
# 有 bug 在 cursor 中回到指定版本
git reset --hard <commit_id>
Cursor、Docker 彻底解决环境配置难题、不用再为环境烦恼