从24年12月参加cursor航海第一次使用AI编程，到今天四个月时间了，我陆续开发了十几个iOS APP，上架了5个，其中两个付费App，分别是类目付费榜第9和第2。除此之外，最近我也做了也差不多快10个网站，有导航站、有AI生图网站，有纯工具站，有纯手搓的，也有从github找的源码套壳的。

今天主要是想大家分享一下，我这几个月以来使用cursor的一些经验和方法，因为我不懂任何技术和编程语言，虽然以前做过几年网站，但是我真看不懂一行代码，包括英语能力，我看一些纯英文的网站时，我也得靠着截图翻译+浏览器插件才能知道大概啥意思，不然也和看天书没区别。

目前，我已经有能力使用cursor开发一些代码总行数过万，涉及较复杂功能的应用，而且也不会像过去那样盲目跟着cursor去被动开发，也很久一段时间没有过修复一个bug修出来几十个，一个Bug几个小时搞不定的情况。

因为最近在参与iOS的航海，看到不少和我一样不懂技术的圈友，在使用cursor开发iOS APP时，遇见了和我过去一样的问题，所以，我就觉得有必要写一篇文章，来总结下我几个月的经验和方法。这些方法从专业编程的角度来说，可能不是很专业，但是对我在使用cursor过程中还是产生了很多帮助。

首先，代码和版本管理，我用的仍然是最原始的方法。

我没有去学git，至今不会用git去管理代码版本，用的仍然是最原始的复制粘贴大法，每当一个重要节点就将项目根目录在本地复制一份，回退代码，用的还是在对话窗口中点击Restore checkpoint的方法，虽然在程序员眼里这种方法有点傻，但是对于新手来说，足够用了，而且效果和用git我觉得没有本质区别。

我没去学git的主要原因，是因为我觉得学会了git，短期内对于提升代码质量没有很明显的帮助，而且在新手使用AI编程的过程中，有大量比学会git更重要的问题，所以基于主次矛盾，我短期内完全放弃了学习使用git管理代码版本。

其次，我也没有学任何一门编程语言。主要原因是我做的应用类型跨度太大，从iOS APP到web网站，从前端到后端，光语言种类我数过至少得学五六种，比如“html、css、javascript、php、mysql、python、linux命令、swiftUI、TypeScript...”。

从技术的角度来说，每一种编程语言在特定的应用类型中都有学习的必要，但这么一箩筐的编程语言，让我一个不懂技术的新手咋学，这个学习曲线和时间成本想象就恐怖。

所以，我的解决办法是变干边学，0帧起手，而不是学完了再干，不过，目前我觉得是否懂编程技术，和是否能开发出应用也没有完全的必要关系，也不像很多人说的不懂技术使用AI就只能做玩具。

我是用AI编程的经验和方法，总结来说一共五点：

（1）让AI去管理AI

（2）组件化设计

（3）分模块开发

（4）及时收手，及时止损

（5）管理上下文

第一点，让AI去管理AI。

因为我不懂技术，所以很多时候我想做一个应用，我压根不知道怎么做，我原来的思路要么是照着对标网站一顿抄，别人做什么我做什么，要么是直接让AI去实现功能。

但是后来发现，抄和直接做这两种方法有很大的问题，因为前者，你直接将别人网应用的截图发给Cursor模仿，但其实多数时候实现的效果并不理想，总会有很大的差距，而且你的整个思维会被局限在别人的页面中。

所以后来，我开发任何一个应用前，会先和另一个AI沟通，我经常和豆包打电话，让豆包帮我构思和完善我的想法，聊明白了后再决定做不做和怎么做，包括前端的样式设计也是一样，在聊完后，我会让AI为我总结成开发的prompt。

如果是iOS的话，就先让AI用HTML/CSS/JS画出产品原型图，这一步的目的我是让自己对想法有一个具像化的理解和呈现，然后再去做细微的调整，确认产品原型图和我的想法一致后，再去截图发给AI实现页面的UI。

而不是一上来直接就做一个功能，后面发现不对劲再去改，这样会很容易开发到后面将应用改崩，出现一个死活都解决不了bug将你劝退。

用截图实现产品原型图的这种方式，虽然不是效率最高的，但是基本上可以做到80%的还原度，对于我这种新手来说的话也很友好。我也没去研究怎么先去导入figma，再用mcp去从figma转换为swiftUI的项目文件，我觉得太麻烦，而且从实际效果来说，我觉得提升有限。

我现在也不会在产品UI样式的细节上死扣，因为我觉得用户其实不会在意你这个按钮是啥颜色，是大了一点还是小了一点，是放在左边还是放在右边，能够满足用户需求就行，至于好不好看，这个每个人的审美标准也不同，只要应用功能设计的不是那么反人类，能够直观的表达信息就行。

所以，我从不在样式设计上去纠结，原则就是能看的过去就行。

如果是网站的话，我就会先用Blot.new去做出网站的前端样式，然后导出项目文件，在cursor中再去实现网站的后端功能，这样分开实现，我发现能够很好的弥补cursor做出的样式不够美观的问题，而且前后端分开实现，效率也更高。

第二点，组件化设计。

这一点我觉得是对于新手使用cursor开发最实用的方法了。

在iOS APP航海的过程中，我经常发现有的圈友经常性一个文件动辄上千行的代码量，有的单个文件能做到五六千行，这个问题产生的影响非常致命，因为在cursor的agent模式下，AI最多单次看你200行的代码，而如果一个文件的代码行数过千，那么不仅影响AI生成的质量，而且会非常高频率的出现Bug。

过去，我的解决办法是让AI为我主动设计项目的目录结构，但是后来我发现这样的做法也并不合理，因为AI给你设计的目录是否合理是一回事，最重要的是他不一定完全遵循最初设计的目录执行，特别是开发到了后期阶段，因为一些新的需求和新的问题出现，所以经常和最初设计的目录结构不一致。

但是，我发现让AI去设计目录结构，很多时候不同文件的代码行数也很容易跑到上千行，而这个时候我的做法是让AI去主动拆分代码行数过多的项目文件，但是却又发现AI要么给拆的非常混乱，要么一拆完结果立马蹦出来几十个报错信息。

所以，近期我在开发网站的时候总结出一个经验，就是组件化设计。举例来说，比如你让cursor用html / css / js语言为你开发一个图片压缩工具，那么这个时候，会出现两种情况。

一种，是你没有创建任何.cursorrule的技术规范文件，Curosr就直接将html / css /js 三种语言都给你写进了一个文件里，也就是index.html这个文件中，虽然实现了了图片压缩的功能，但是这个文件的代码量会很多。

一种，是你创建了.cursorrule的技术规范文件，Cursor遵循规范，在实现图片压缩的网页工具时，将项目文件拆分为了index.html、script.js、style.css三个文件，这样整个项目的文件结构更合理了，根据不同文件的功能将原本一个文件拆成了三个，但是也有很大的局限性。

比如说你想增加一个导航栏，那么这个导航栏的所有代码也会被写进这个文件里；比如说你想增加一个banner，那么banner的代码也会被同时写进这三个文件里。

总之，当你的页面中功能越来越多，你的这三个文件代码量也会越来越大。最致命的问题，在于如果你想给这个图片压缩工具的网站新增几个不同的页面时，如果这几个页面都有导航栏的话，那么会出现的一种问题就是，Cursor在你的每个页面里都重复写了导航栏这个功能。

从结果来看，虽然每个页面都有导航栏，实际上是cursor在你的每个页面中重复给你写了一遍。两种方法从实现结果来看表面都一样，但实则有巨大的差异。

针对这一个问题，特别是文件代码行数过多的问题，我们也很难在开发之初就通过设计好目录结构解决，也很难在开发过程中主动拆分文件去解决问题。

所以，我的办法就是组件化设计，还是拿图片压缩网站的导航栏为例，比如说我现在的图片压缩网站已经有了几个页面，包括后续我还想再做一堆页面，那么这些页面一定需要一个导航栏，那么这个时候我会让ai将导航栏单独创建一个文件，写成一个组件，比如top.css、top.js文件，这样在后续我每一个新页面中，都可以通过1-2行代码去引用这个组件来实现导航栏的功能。

就是说，我们页面中的每个小功能，都可以单独做成一个小的组件，这么做最大的好处，不仅仅是减少了开发的代码量，不仅仅是有利于后期维护这个文件，对于新手来说，最重要的是减少了出现bug的可能性。

不至于说你因为改了导航栏，结果牵一发动全身，其他功能也受到影响，这样每个组件都是独立的，哪个文件有问题就改哪个文件就行了。

第三点，分模块开发

这一点我相信很多人并不陌生，其实就是一个实现顺序的问题。简单来说，就是尽可能在不同阶段做不同的任务，在一次对话框中只实现一个编程任务。

因为开发一个应用从分为前端、后端、数据库，也分为样式、交互、功能、数据四个方面，所以分模块开发就是先做网站的前端，然后做前端的过程中先去实现页面的样式，样式调整结束后，再去实现样式中按钮的交互，交互做完了，再去实现交互的实际功能，功能实现了再去解决功能产生的数据存储到哪里的问题。

做完前端后，再去做后台，后台其实本质上和前端一样，只是前端是给用户看的，后台是给管理者用的，两者本质上都是对于数据库在实现增删改查，所以开发后台的过程和开发前端本质上一样，只是样式上没有必要做的太过于精致。

然后再去创建数据库，实现前端+数据库的连接，实现后台+数据库的连接，数据库的作用其实就是一个excel表的作用，后台通过增删改查这个excel表实现对于前端内容的管理和查看，前端应用通过API接口获取表格里的内容，来向用户展示数据，这个逻辑也不难理解，理解了逻辑后，就能够很容易的实现一个前端+后端+数据库的全栈应用了。

最后，在开发到不同的阶段时，我会让Cursor主动将当前开发的进度、注意事项、技术细节总结至Readme.md文档中，避免因为对话上下文超出最大token后AI出现失忆的情况，特别是在实现前端+数据库连接、后台+数据库连接时，尤为重要，因为你需要用这个文件记录过程的一些细节，比如数据库API创建了哪些表、字段，返回的数据格式是啥。

第四点，及时收手，及时止损

在使用cursor开发应用的过程中，你总会发现有解决不完的问题，总会有加不完的功能，所以在使用cursor开发产品的过程中我觉得不要有任何的完美主义，做到60分及格就行，因为如果这个应用不具备市场价值，花再多的时间精力也是浪费，还不如快速开发一个demo版本扔到市场上快速验证需求和用户付费意愿，如果成立再投入，不成立就直接放弃。

还有一点，就是每当我实现一个新的功能时，每当我对已经初步成形的应用做改动时，我除了一次对话只实现一个任务外，如果实现这个功能产生了Bug，这个Bug如果我用3次对话还解决不了的话，那么我会果断点击Restore checkpoint，然后重新编辑提示词，或者重新和AI对话去沟通如何实现这个功能，因为AI生成的结果具有随机性，就像抽盲盒一样，有时候一次效果不满意，我也会重新让它生成直到满意为止。

第五点，管理上下文

众所周知，任何一个AI大模型都有上下文的最大Token限制，claude3.7上下文是200k，一个token不是一个字符的意思，有可能是一个字，有可能是一个字母，有可能是一个词组，不过这不重要，重要的是因为上下文有最大的token限制，所以AI会出现失忆和幻觉，而产生幻觉最大的问题，就是因为当前任务被历史上下文污染，影响了生成的质量，这是因为每次对话AI会回顾历史对话，而历史对话会对当前任务产生影响，如果是相关的上下文的话，那么对于当前的任务是有利的，如果是不想干的内容，则生成就会产生负面的结果。

举例来说，我们在实现一个应用前端+数据库连接、后台+数据库的连接过程中，我会尽量在一个对话窗口中实现，原因就是之前的上下文对于AI理解当前的任务是有用的。反之，如果我是在实现某一个新的功能，解决一个Bug时，我就会新建一个对话窗口去实现，因为没有必要关联的话，会影响我修复Bug的效率。

所以，什么时候新建Chat对话框，什么时候延用过去的对话框非常重要。

其次，就是每次新建Chat对话框，会丢失过去的上下文，这个时候我们就得要主动构建上下文，让AI去理解我们的项目是做什么的，过去常用的方法就是构建README.MD文件来和AI说明，这样的方法有用，但是也有一定的局限性。

所以，我会主动的构建上下文，在每次新建对话框后，我都会先用ASK模式，让AI完整阅读整个项目所有的文件，让cursor输出对于这个项目每个不同文件、目录的作用做解释、以及对于项目的理解。如果我这个新的对话框是涉及到某一个新功能的实现，如果这个新的功能和项目中原有的代码、组件有关联的话，我会让AI再根据这个组件做针对性的解释。

我这么做的目的，就是让AI主动构建上下文去，方便在我们后续的任务中，可以快速、正确的理解项目，而不是仅仅是在Agent模式下用Read查看项目代码的方式去理解项目。

最后，在修复Bug的时候，很多人会直接将报错信息发给AI处理，实际上我发现这种方式存在严重的问题，如果是一些简单的Bug还好，Curosr能够有效处理，但是很多时候会有些棘手的问题，AI不能在一次对话中完美解决，所以这种情况下我会用主动构建上下的管理方法解决Bug，具体的流程如下图所示。