Cursor使用技巧：如何让AI成为你亲密无间的助手

之前我在尝试使用Cursor开发了一款简单的星座查询的小程序，由于功能有些简单，而且对于“用户”来说，可能并不知道自己的星座是什么，于是我计划给小程序迭代新功能：通过选择出生年月日、地区，查询出自己的星座，而这个返回结果必须包含自己出生时星座12宫的位置、对应是什么守护星、每个宫位影响着什么等等。

迭代这个功能的同时，我对现有的界面并不满意，因为它太粗糙了。所以还需要对此进行界面的UI优化。

确定功能迭代和UI界面优化

还是要请出我们的协助助手：README文件。这个文件起什么名字，并不重要，重要的是你需要将你要实现的部分在这个文件里写清楚。

“写清楚”是一个含糊的概念，或者说这是大部分人想利用AI工具成为自己助手的一大痛点。

简单描述一下这个文件的结构应该是怎样的：

1、定义Cursor的角色

2、你的开发项目的名称、功能清单、原型图、UI图

3、你希望达成的目的

这是我的新迭代的小程序写的README文档，可以进行参考：

1、你是一个经验丰富的微信小程序UI工程师，你熟悉微信的UI设计，设计风格优雅简约

2、你将负责设计微信小程序的UI

3、我需要设计一个界面：12星座顺序排列，使用优雅配色的icon轮播，中间有一个日期选择器用来选择出生日期和出生时间，日期选择器下方有一个地点选择器，供中国大陆内34个省、自治区、直辖市、特别行政区选择，完成出生日期和出生地点选择后，底部有个按钮，点击查询后调用API获取返回结果并且展示用户输入信息所对应星座的星盘、12宫位置、12宫主星、12宫对应宫位、12宫主宰的星座、性格特征。

4、保持所有界面设计简洁优雅、操作交互顺畅、动态效果流畅、各个组件的样式统一、各个动态的播放逻辑和动画效果逻辑统一，保证全局组件样式的对齐模式，以及层级排列

5、12星座的icon使用优雅且有辨识度的icon，星座名称使用优雅且有辨识度的字体，同时保证星座icon和星座名称的样式统一，中部对齐

6、日期选择器使用微信小程序的日期选择器，全部界面的输入框和按钮样式和布局要和整体风格保持一致，同时兼容溢出问题，保证所有组件的边距一致

7、查询结果调用大模型：（填写你的大模型名称）如果超过3000ms则调用（兜底大模型名称）串行查询，超过6000ms则返回“查询失败，请稍后再试”的toast

8、注意加密保护API地址和API密钥

9、用户使用过程中请不要收集用户数据、不要收集用户位置信息、网络信息和任何隐私信息

10、注意API调用次数限制，不要频繁调用API

11、注意兼容安卓和iOS的样式

12、注意兼容微信小程序的样式

13、注意考虑用户使用过程中的各种情况，比如网络异常、API调用失败、API调用超时等，并给出响应提示，收集用户日志

14、所有调整更新到readme.md

新旧版界面对比

可以看到1、2是对AI工具的角色定义；3-7是功能清单的拆解，如果是简单的小工具拆解，可以这样简单描述（因为整体页面只有1个），8-13是对业务逻辑的简单梳理。

拆解业务功能和逻辑

什么是业务功能？简单来说，就是你的这个项目，用户会怎样使用。用户的习惯是千变万化的，但是我们必须对一个功能有简单的、原始的拆解。以我开发的这个查询星座的工具来说，它的业务功能一共有3块。

整体业务功能的拆分

第一块：用户选择地区、选择出生年月日和时间，查询星盘结果

第二块：随机选择一个星座，返回3日内的查询结果

第三块：轮播星座知识

看似很简单对吧？实际在Cursor的编程中，它会认为业务功能中的第一块和第二块是并行的，也就是缺一不可。这就需要告诉它：这两者不是互斥的，用户可以只选择查询星盘而不查看星座的近日结果，同样的，用户可以选择既查星盘又查星座。

这就是Cursor使用的技巧，但很多人都忽略的：业务功能和逻辑的排布是怎样的？每个功能是单独进行、还是先进行A模块，再进行B模块才会有结果？所以这必须要在README里详细描述，这就是我在初始的时候没有进行描述，后来引发了来回几次的改动，因为Cursor不明白设计者的业务功能和逻辑，必须清晰告诉它。

数据如何处理

很多人开发的过程中没有意识到一个问题：数据处理的合规性。有些开发可能在日常项目中时时会碰到，每次用户的点击、查询之后的数据都回保存在本地，让服务器的压力不至于过大。但在互联网中还有一个问题是不能忽视的：个人信息的保护。因此我在使用Cursor进行开发的时候着重要求它“不要收集用户数据、不要收集用户位置信息、网络信息和任何隐私信息”（见上文）。有人可能也会质疑：那这个工具的第一个功能不就是涉及到用户的隐私了吗？实际开发中我是让Cursor进行了加密和不保存的处理，这也意味着每次进入用户都需要重新选择，不会对输出的结果进行保存。

同样的，使用Cursor开发时可能涉及到API数据的调用，也同样需要告诉它进行加密的保护以防泄露。

还有一点非常重要但可能对新手来说容易忽略的问题就是：请求时机的设置。我们都知道去请求服务器的结果，不一定会实时返回，有可能是网络原因，也有可能是用户使用频次过高带来的问题，那就需要让Cursor设置一个请求时机的机制，也可以自己进行设置，如上文，我就进行了设置，请求超时之后调用别的大模型来填充数据，避免用户总是获取不到结果。

这就是第二版的效果

其他注意事项

1、哪个大模型更“智能”？

目前Cursor已经发布了0.4.99，已经支持到Claude 3.5 sonnet2024/10/22（我简称为新3.5）的版本。这个版本可以理解为Claude 3.5 sonnet（我就简称为老3.5）的进阶版本，在10月22日的发布会当天，官方称这个模型甚至可以进行简单的网页浏览和操作。

最新版本支持最新的Claude

在以上提到的项目里，我在开发进度完成了80%的时候切换了4o，让它对照README中的开发计划进行，但它只是一遍遍回复：请提供开发进度，我将根据开发进度进行规划。所以个人并不建议使用4o。老3.5不好的地方在于，它会反复询问：我已经列好了12345个计划，你希望先从哪一部分开始？新3.5比老3.5智能的一点在于：它在自行梳理了开发计划之后，不需要再反复的进行确认。如，它同样返回结果：我已经列好了12345个计划，你想从哪部分开始，还是我按照顺序逐步进行？回复按照顺序逐步进行，它将会自己跟随着开发进度一步步进行。

2、已经写好了功能清单、拆解了业务功能和逻辑，为什么大模型还是“很不听话”？

在实际的操作中，我比较喜欢在开始的时候先这样和Cursor对话：请仔细阅读README文档，确认你已经清楚功能清单的需求，如果确认，请进行开发计划并随时更新到README。

新3.5和老3.5都能够根据详细的功能清单进行规划，但老3.5会更“健忘”一些，同时非常喜欢在项目中偷偷删减功能。新3.5的响应速度和依从性更好一些，但也难以避免这个问题。所以我的建议是：在进行了一个页面或者几个组件的完成之后，让Cursor再重新梳理功能清单列表，它再次学习，能有效降低“健忘症”。

3、打开YOLO模式以及及时保存

YOLO模式下自行运行命令的结果

最新的版本支持了YOLO模式，简单来说打开它就能够自行运行命令行，有时候在开发过程中需要用到一些工具本地没有的，老3.5会弹出一条指令，需要手动点一下“Run command”来安装。打开YOLO模式后碰到这些问题就不会再需要人工点击。

在每次发起请求时，底部会出现几个按钮，需要先点击“Accept All”、再点击：Save All。同时，一个请求最多只能进行25次的代码编写，超过会请求失败。

4、编译时总出现相同类型错误

有时候编译时会报一些相同类型的错误，如在index.json中未能找到某个组件，可以使用“请系统性解决”的指令让Cursor全面解决（但偶尔会失效）。

大小写的低级错误Cursor也会犯，但新3.5自行发现并解决的响应能力要强很多。

老3.5出现这种问题概率更大，且很难发现

容器的溢出、组件的对齐问题

这个问题是最常见、同时Cursor并不是非常在意的问题，所以最好还是在初始时进行规定、强调。

总的来说，搭载了Claude 3.5 sonnet 2024/10/22大模型的Cursor比之前更好用一些，如果想让它成为自己的开发助手，细节上还需要多加把控。