从9月份开始，我完全转向使用Cursor进行编程，已经完成了五六个小网站的开发。非常感谢论坛中各位大佬分享的指南和技巧，我也想借此机会分享一些个人的使用心得，希望能为大家带来一些启发。
在这几个月里，我主要使用Cursor进行个人项目的敏捷开发，开发周期基本控制在10天以内。项目的体量并不大，大多是从零开始一边规划一边实现。由于开发类型是LLM擅长的Web领域，因此使用体验非常棒，最终的效果也让我非常满意。
我并没有过度使用Cursor的所有功能，而是秉持实用至上的原则。过度折腾工具可能会分散注意力，反而影响项目的实现效率。下面是我在开发过程中常用的一些功能和技巧，希望能对大家有所帮助。
Ctrl+L：唤起聊天栏，这是最基础的功能。
Ctrl+K：编辑代码块。选中部分代码使用该快捷键，可以直接让LLM修改或生成代码片段。适合具体细节的调整，例如修改方法或生成特定内容。
Ctrl+回车：使用整个项目文件作为上文进行提问。该功能会在聊天栏中自动对项目内容进行量化，适合大方向的提问，但不适合细节实现，因为可能会遗漏部分文件。
我没有使用
composer，因为我需要在速度和效果之间找到平衡。目前阶段，手动实现更容易达到预期效果。
绝大部分时候，我使用的是claude-3-5-sonnet-20241022模型。这是我个人认为最实用的模型，响应速度快，理解能力强，有时还能用诙谐的语气回答问题，非常满意。
在cursor setting - general - Rules for Al中，填入以下prompt：
markdown 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是一件繁琐的事情，但如果不认真写，后续回顾代码时会非常麻烦。在Chat聊天框中输入@commit，回车选择Commit (Diff of Working State)，它会自动将项目Git未提交区域的文件填入上文，然后粘贴以下Prompt：
markdown 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部署，用Next.js还是Vue更合适？
怎么构建Next.js项目？
从npx开始给出构建命令
这些选项都是什么意思？应该选哪个？
通过这些对话，我成功完成了Next.js项目的创建。短短十分钟，我从一窍不通到了解了一个产品经理需要掌握的内容。
在项目实现前期，一定要做好规划，这是与LLM顺利配合的基础。为了避免项目混乱、无法调整的情况，我通常会在项目开始前花时间与LLM梳理项目结构，让LLM提供项目的目录结构，而不是具体代码。这样，我心里有了底，后续出现错漏时也能单独询问具体细节。
项目规划通常通过README来编写，一般包括以下内容：
项目介绍
技术栈
项目功能
目录结构
之后，围绕README去实现项目会更加有章可循。目录结构之后可能会发生改变，但作为参考即可。大部分时候，我会使用- []清单来管理功能实现列表，避免遗漏和关注点偏移。
一定要使用Git管理代码，编程习惯决定了实现效率。我的经验是：多暂存、勤提交、控版本。
在规划好项目系统架构后，我会让LLM实现一个基础的网站框架，并提交第一个版本。在这个基础上进行增删改查。使用LLM编写代码时，最忌讳一口气实现太多功能，导致问题积重难返。每次进行大规模改动或功能调整前，一定要使用Stage All Changes暂存改动，避免影响已实现的代码。
以网站为例，拆分模块就是抽取代码功能。例如，在page中有顶栏和内容区域，最好将顶栏逻辑拆分为HeadBar.tsx，然后进一步拆分为Avatar.tsx、HomeButton.tsx、Logo.tsx等组件，分别负责各自的功能。
按照这个思路，还可以拆分功能逻辑，例如创建网络请求组件、路由调用切片、工厂模式组件等。这些逻辑在实现过程中会自然呈现，目的是为了抽取代码，避免重复实现和方便统一管理。
上下文长度直接影响LLM回答的质量。为了避免过长的对话内容，我通常保证一次对话只解决一个问题。之后还可以通过回看对话历史查缺补漏。拆分模块也能极大减少上下文，你只需添加相关代码即可解决问题。
如果在一次对话中一直未能解决问题，最好创建新对话，退后一步，让LLM从更多角度思考问题所在。例如，我在实现Telegram Bot时曾遇到无法启动机器人的情况，LLM一直执着于解决时延和时序问题，但在一次回答中提到可能是代理设置错误，我捕捉到了这个信息并成功解决了问题。
依赖LLM，但要意识到它的局限性。错误的对话历史会使其越错越远，适时重启对话可以避免“降智”现象。