以下是关于 Cursor 相关报错原因及实践的一些内容：
在设置里面，Rules for AI的提示词[heading4][heading4]2.按照功能模块单独建立实现文档[content]--深入理解需求--技术实现--测试这是我当初一个功能模块技术实现文档的内容[heading4]3.最重要是学会看代码[content]知道每一步这个文件到底是做什么的，这样你对技术上会有一些新的理解和提升[heading4]4.cursor相关报错原因[content]--重复安装依赖项--重新创建文件--导入的路径不对--错误导入已经废弃的文件--突破AI记忆的东西--cursor缓存未更新[heading2]🔥推广一波💕[content]最后，当然要推广一波我千辛万苦开发的小程序《意图分析选择器》；啊，你问我为啥不叫原先的念选，或者天使恶魔选择器，当然是因为~~审核不让，说有侵权的风险呀。。。。。。。所以就。。。。。
举例：分阶段实现，效率更高，只考虑本阶段需求即可。这个日历同步需求中，我分成了4个阶段数据能同步，API调用成功数据同步不重复，且新增、更新、删除都同步分类同步到不同日历中定时自动同步[heading3]3.4.3、主动思考，大语言模型也有局限性[content]大语言模型的缺陷，上下文窗口限制、幻觉，在Cursor里也有体现，虽然可以通过@文件、Claude3.5-sonnet模型等方式缓解。比如数据同步的时候，总是每次脚本执行后，数据重复同步到日历。排查对比了很久，发现是唯一ID的问题，但是使用Cursor报错排查的时候，总是给我指引说是唯一ID没有问题都存在。这个时候就需要人工强介入，不断思考问题到底能出在哪。[heading3]3.4.4、细节操作要注意[content]每次修改完代码要保存，再去运行，我好几次报错都是因为这个原因。整体修改慎用，改好了这个bug可能带来新bug。新增其他功能的时候，可以新开一个对话，要不然之前的上下文比较影响新代码生成和调试。每个项目都新建一个文件夹，相关文件都放在里面，执行的时候方便相对路径。代码中尽可能多带日志，报错的时候方便调试。
我让Cursor基于需求文档开发我所负责的部分，大概1分钟（没错）就写完了第一版。就在我以为能马上进入调试期的时候，第一个麻烦开始了：为了进行单元测试，我们必须安装那些缺失的库；不确定是否因为我忘记给Terminal配置网络环境，安装进度特别慢，我很焦虑地看着它花了30分钟才完成了测试的前置准备。而在写单元测试脚本的时候，Cursor偶尔也忘记自己必须在指定文件夹下工作，导致一些关键的文档反复放错位置，并创建了很多垃圾文件。解决掉这些烦人的小问题后，跑了十来次运行→报错→AI改代码→运行→报错循环，终于通过了单元测试，此时元子和Lark也已经各自完成单元测试，激动人心的合并时刻到了。但是，哪有第一次就能跑通的代码？果不其然，合并后又需要安装环境，build再上传到Chrome后，又是30分钟过去了，此时，我满怀期待的点开了插件。[heading2]