从9月份开始，我完全面向Cursor编程，开发了五六个小网站。非常感谢论坛中的朋友们提供的各种指南和技巧教程，我也想分享一下我的个人使用心得，希望能抛砖引玉。
这几个月，我主要利用Cursor进行个人项目的敏捷开发，开发周期基本在10天以内，因此项目体量并不大，基本都是从零开始一边规划一边实现，开发类型是LLM的长项：web，所以使用体验非常棒，最终呈现效果让我很满意。
我并没有使用太多Cursor提供的功能，实用至上，一味折腾工具并不能帮助你实现项目。论坛中有朋友分享的使用技巧，大家可以参考，写得非常好，我一直在用：
Ctrl+L：唤起聊天栏，最基础的功能。
Ctrl+K：编辑代码块。直接选中部分代码使用该快捷键，可以让LLM修改和实现代码，适合具体细节的改动，如调整方法或生成片段内容。
Ctrl+回车：使用整个项目文件作为上文进行提问。在聊天栏中使用该快捷键，Cursor会自动对项目内容进行量化，避免占用过多token。这个功能在进行一些大方向提问时非常好用，但不适合细节实现，因为会丢失细节，遗漏文件。根据需求选择性使用。
我没有选择使用composer，因为我需要在速度和效果中得到一个平衡，比起不动手，目前阶段还是手动实现更容易达到预期效果。
绝大部分时间，我使用claude-3-5-sonnet-20241022，这是我个人认为最好用的模型，响应快速，理解能力强，有时还能用诙谐的语气回答问题，我非常满意。
在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.
注意添加.gitignore文件，将.history之类的文件加入忽视清单，避免git追踪区域混乱。
写commit logs是一件很麻烦的事，但如果不好好写，没有人愿意回头去看代码，包括你自己。在聊天框中输入@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: :
Use these for : 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处，提交即可。
一开始我就明确了自己的角色定位：产品经理。我不懂编程语言和代码实现，我的职责就是设计指导LLM实现项目，在过程中通过咨询细节再调整具体的实现步骤。
在问答的过程中，一定要当一个好奇宝宝，不停地问怎么做和为什么，跟LLM客气什么？不懂就问，哪里不会问哪里！
我一开始对一切都不懂，然后在与LLM的交流基础上，以它的回答作为阶梯一步步优化提问内容。以下是我第一次做网站的对话过程：
怎么实现网站？
我想请求API，想用Vercel部署，用nextjs还是vue更合适？
怎么构建nextjs项目？
从npx开始给出构建命令
这些选项都是什么意思？应该选哪个？
至此，我就完成了Next.js项目的创建，十分钟前我一窍不通，十分钟后我觉得我已经了解了一个产品经理需要掌握的内容。
在实现项目前期一定要做好规划，这是与LLM配合顺利的基础。为了不重蹈项目混乱、无法调整的覆辙，在任何项目开始前，最好都要根据实现难度，花上时间与LLM梳理项目结构，让它给出项目的目录结构，而不是具体代码，这样你心里就有数，之后如果出现错漏，也能根据这个结构单独向LLM询问具体细节。
项目规划可以通过README来编写，一般情况下需要有：
项目介绍
技术栈
项目功能
目录结构
之后围绕README去实现就心里有底了。目录结构之后基本都是要改变的，只是作为参考，不用过于关注。大部分时间我一直修改的是项目功能，我会使用- []清单来管理功能实现列表，避免遗漏和关注点偏移，因为LLM很轻易地就能写出让你觉得很牛逼的代码，但切忌自我感动，在项目基础功能实现前，不要让LLM自我发挥，先把Demo完成再说其他。
一定要使用git管理代码，编程习惯决定了实现效率。我的经验就是：多暂存、勤提交、控版本。
在规划好项目系统架构后，让LLM实现一个基础的网站框架，我就会commit第一个版本，在这个基础上进行增删改查。因为使用LLM编写代码，最忌讳一口气用LLM实现太多功能，导致出现问题后积重难返。
每次在进行大规模改动或调整功能之前，一定要使用Stage All Changes暂存改动，避免影响已经实现的代码。
并且一定要做好功能拆分，克制克制再克制，只要实现一个功能就提交，不然牵一发而动全身，越改越乱。我已经在这上面吃亏太多次了。
以网站为例，拆分模块就是抽样代码功能，比如在page中有两个部分：顶栏和内容区域，那么我们最好拆分出HeadBar.tsx专门负责顶栏的逻辑；然后在顶栏中有头像、主页按钮、logo三部分，那么我就拆分出：Avatar.tsx、HomeButton.tsx、Logo.tsx，分别负责各自组件的功能。
按照这个思路，还可以拆分功能逻辑，比如创建网络请求组件、路由调用切片、工厂模式组件等。不要看名字高大上听不懂，实际上这些都是LLM会在实现过程中自然呈现的逻辑，目的就是为了抽样代码，避免重复实现和方便统一管理。
尽可能保证每个文件只负责单独的模块功能，代码行数控制在200行以内。
不要嫌麻烦，创建文件不需要自己动手，直接让LLM帮你拆分实现，你点击Apply按钮它就会自动创建并填入代码。
这是一个非常重要的习惯，先执行，等回过头来你自然会意识到它的价值。
上下文长度直接决定了LLM回答的质量。为了获得最佳回答效果，我会尽可能避免过长的对话内容，并且保证一次对话只解决一个问题，之后还可以通过回看对话历史来查缺补漏。
上面提到的拆分模块也能极大减少上下文，你只需要添加相关的代码，对话即可解决需求，而不需要每次携带多余的代码进行提问。如果在一次对话中一直没有解决问题，最好创建新对话，退后一步，让LLM从更多的角度思考问题出现在哪，然后你再根据它的回答，依次提问尝试解决。
我在实现telegram bot时就遇到过无法启动机器人的情况，LLM一直执着于解决时延和时序问题，但在一次回答中它提到了可能是代理设置错误，我捕捉到了这个答案，并且马上尝试，果然解决了问题。
依赖LLM，但要意识到它的局限性，错误的对话历史会让它越错越远，你要知道适时重启对话以避免“降智”。