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