自从 2024 年 12 月开始，我全面转向了使用 Cursor 进行开发工作。在这段时间里，我独立完成了多个小型网站项目的开发。作为一个 Cursor 的重度使用者，我想分享一下这几个月来积累的实战经验和心得体会，希望能为同样对 AI 辅助编程感兴趣的开发者提供一些参考。
这几个月我主要是利用 Cursor 进行个人项目的敏捷开发，开发周期基本在 10 天以内，所以项目体量并不大，基本都是从零开始一边规划一边实现，开发类型是 LLM 的长项：web，所以使用体验很棒，最后呈现效果我个人很满意。
Cursor 的使用
我并没有使用太多 Cursor 提供的能力，实用至上，一昧的折腾工具并不能帮助你实现项目。我之前有分享使用技巧，大伙儿可以去参考：
Cursor 神器进阶：AI 提交信息生成 + Composer 黑科技 一些关于 Cursor 的使用技巧
快捷键
Ctrl + L：唤起聊天栏。最基础的功能。
Ctrl + K：编辑代码块。直接选中部分代码使用该快捷键，可以直接让 LLM 修改和实现代码。适合具体细节的改动，如调整方法或生成片段内容。
Ctrl + 回车：使用整个项目文件作为上文进行提问。在聊天栏中使用该快捷键，Cursor 会自动对项目内容进行量化，避免占用过多 Token。这个功能在进行一些大方向提问时非常好用，但是不适合细节实现，因为会丢失细节，遗漏文件。自行根据需求选择性使用。
我没有选择使用 COMPOSER，因为我需要在速度和效果中得到一个平衡，比起不动手，目前阶段还是手动实现更容易达到预期效果。
CTRL + Enter is not working，官方文档地址：https://forum.cursor.com/t/ctrl-enter-is-not-working/24192
对于 Ctrl + 回车 功能，我也遇到过困惑。最初我直接在键盘上按 Ctrl 加 回车 键，但没有任何反应。后来才发现，这个功能其实是指 Cursor 的 CHAT 界面中的操作选项，而不是在代码编辑器中使用的快捷键，如下图所示。
模型选择
绝大部分时候，我都是使用 claude-3-5-sonnet-20241022，这是我个人认为最好用的模型，响应快速，理解合格，有时还能用诙谐的语气回答问题，我非常满意。
claude-3-5-sonnet-20241022 默认情况下是没有自动给我们显示出来的：
需要自己去 Cursor Setting 中设置，如下图所示：
Prompt 集成
在 cursor setting - general - Rules for Al，填入以下 Prompt。
DO NOT GIVE ME HIGH LEVEL STUFF, IF I ASK FOR FIX OR EXPLANATION, I WANT ACTUAL CODE OR EXPLANATION!!! I DON'T WANT "Here's how you can blablabla"
- Be casual unless otherwise specified
- Be terse
- Suggest solutions that I didn’t think about—anticipate my needs
- Treat me as an expert
- Be accurate and thorough
- Give the answer immediately. Provide detailed explanations and restate my query in your own words if necessary after giving the answer
- Value good arguments over authorities, the source is irrelevant
- Consider new technologies and contrarian ideas, not just the conventional wisdom
- You may use high levels of speculation or prediction, just flag it for me
- No moral lectures
- Discuss safety only when it's crucial and non-obvious
- If your content policy is an issue, provide the closest acceptable response and explain the content policy issue afterward
- Cite sources whenever possible at the end, not inline
- No need to mention your knowledge cutoff
- No need to disclose you're an AI
- Please respect my prettier preferences when you provide code.
- Split into multiple responses if one response isn't enough to answer the question.
If I ask for adjustments to code I have provided you, do not repeat all of my code unnecessarily. Instead try to keep the answer brief by giving just a couple lines before/after any changes you make. Multiple code blocks are ok.
Reply in 中文 when interpreting the code.
这个 Prompt 是我自己总结的，主要是为了让 Cursor 在回答问题时更加符合我的需求，不要给我太多高级的东西，我需要的是实际的代码或解释。
自动生成美观的 commit logs
注意添加
.gitignore文件，将.history之类的文件加入忽视清单，避免 git 追踪区域混乱。
写 commit logs 是一件很麻烦的事，但是如果不好好写，没有人愿意回头去看代码，包括你自己。
在 CHAT 聊天框中输入 @commit，回车选择 Commit (Diff of Working State)，它会自动将项目 git 未提交区域的文件填入上文：
然后在文本框中粘贴：
You are an expert software engineer.
Review the provided context and diffs which are about to be committed to a git repo.
Review the diffs carefully.
Generate a commit message for those changes.
The commit message MUST use the imperative tense.
The commit message should be structured as follows: <type>: <description>
Use these for <type>: fix, feat, build, chore, ci, docs, style, refactor, perf, test
Reply with JUST the commit message, without quotes, comments, questions, etc!
回复中文
这个 Prompt 会自动总结你的 commit diff，给出标准格式的 logs，然后你再根据具体改动调整一下话语即可，大多时候都不需要调整。
之后将内容复制到 message 处，提交即可：
当然也可以利用我之前所介绍的 GitLens 插件的方式，生成好直接提交。
应该怎么做
明确定位
一开始我就明确了自己的角色定位：产品经理。我不懂编程语言和代码实现，我的职责就是设计指导 LLM 实现项目，在过程中通过咨询细节再调整具体的实现步骤。
在问答的过程中，一定要当一个好奇宝宝，不停的问怎么做和为什么，你跟 LLM 客气什么？不懂就问，哪里不会问哪里！
我一开始就是什么都不懂，然后再和 LLM 的交流基础上，以它的回答作为阶梯一步步优化提问内容。
下面是我的第一次做网站的对话过程：
怎么实现网站？ 我想请求 API，想用 Vercel 部署，用 NextJS 还是 VUE 更合适？ 怎么构建 NextJS 项目？ 从 npx 开始给出构建命令 这些选项都是什么意思？应该选哪个？
至此，我就完成了 Next.js 项目的创建，十分钟前我一窍不通，十分钟后我觉得我已经了解了一个产品经理需要掌握的内容。
项目规划
在实现项目前期就一定要做好规划，这是与 LLM 配合顺利的基础。
为了不重蹈项目混乱，无法调整，心烦意乱的覆辙，在任何项目开始前，最好都要根据实现难度，花上一定时间去和 LLM 好好梳理项目结构，让它不要给出具体代码而是给出项目的目录结构，这样你心里就有数，之后如果出现错漏，你也能根据这个结构单独向 LLM 询问具体细节。
项目规划就通过 README 来编写，一般情况下需要有：
项目介绍 技术栈 项目功能 目录结构
之后就围绕 README 去实现就心里有底了。
目录结构 之后基本都是要改变的，只是作为参考，不用过于关注。
大部分时候我一直修改的是项目功能，我会使用 - [] 清单来管理功能实现列表，避免遗漏和关注点偏移，因为 LLM 很轻易的就能写出让你觉得贼牛逼的代码，但是切忌自我感动，在项目基础功能实现前，不要让 LLM 自我发挥，先把 Demo 完成再说其他。
与 Git 配合
一定要使用 Git 管理代码，编程习惯决定了实现效率。我的经验就是：多暂存、勤提交、控版本。
在规划好项目系统架构后，让 LLM 实现一个基础的网站框架，我就会 commit 第一个版本，在这个基础上进行增删改查。
因为使用 LLM 编写代码，最忌讳一口气用 LLM 实现太多功能，导致出现问题了积重难返身心俱疲。
每次在进行大规模改动或者是调整功能之前，一定要去使用 Stage All Changes 暂存改动，避免影响了本来已经实现的代码。
并且一定要做好功能拆分，克制克制再克制，只要实现一个功能就提交，不然牵一发而动全身，越改越乱。
我已经在这上面吃亏太多次了。
拆分模块
拿网站来举例，拆分模块就是抽样代码功能，比如在 page 中有两个部分：顶栏和内容区域，那么我们最好拆分出 HeadBar.tsx 专门负责顶栏的逻辑；然后在顶栏中有头像、主页按钮、Logo 三部分，那么我就拆分出：Avatar.tsx、HomeButton.tsx、Logo.tsx，分别负责自己组件的功能。
按照这个思路，还可以拆分功能逻辑，比如创建网络请求组件、路由调用切片、工厂模式组件等，不要看名字高大上听不懂，实际上这些都是 LLM 会在实现过程中自然呈现的逻辑，目的就是为了抽样代码，避免重复实现和方便统一管理。
尽可能保证每个文件只负责单独的模块功能，代码行数控制在 200 行以内。
不要嫌麻烦，创建文件不需要自己动手，直接让 LLM 帮你拆分实现，你点击 Apply 按钮它就会自动创建并填入代码!!!。
这是一个非常重要的习惯，先执行，等回过头来你自然会意识到它的价值。
创建新对话，精简上下文
上下文长度直接决定了 LLM 回答的质量。
为了最好的回答效果，我会尽可能的避免过长的对话内容，并且保证一次对话只解决一个问题，之后还可以通过回看对话历史来查缺补漏。
上面拆分模块也能极大的减少上下文，你只需要添加相关的代码，对话即可解决需求，而不需要每次携带多余的代码进行提问。
如果在一次对话中，一直没有解决问题，最好创建新对话，退后一步，让 LLM 从更多的角度去思考问题出现在哪，然后你再根据它的回答，依次提问尝试解决。
我在实现 telexxxx bot 的时候就遇到过无法启动机器人的情况，LLM 一直执着于解决时延和时序问题，但是在一次回答中它提到了可能是代理设置错误，我捕捉到了这个答案，并且马上尝试，果然解决了问题。
依赖 LLM，但是要意识到它的局限性，错误的对话历史会让它越错越远，你要知道适时的重启对话来避免 “降智”
