关于Vibe coding的个人最佳实践 | 经验性、阶段性总结

01

前几篇文章是一些我对于Deep research类Agent的一些分析与思考，而实际上，AI coding agent（如cursor、windsurf、replit、bolt.new、lovable等）已成为Agent市场商业化最成功且很有前景的方向。

我在过往的几篇文章中进行过系统性的介绍与使用，进行vibe coding（氛围编程）。

本文是对于使用cursor agent的使用的经验性、阶段性总结。你可以看到，如何简单且最大化地感受Vibe coding。

02

先介绍一些我近期来自AI IDE（cursor）的成果，以便展示个人Vibe coding的最佳实践成果，同时会先说明一些不足，在03部分具体进行经验总结。

一个面向零基础用户的SaaS项目-MVPcode，旨在解决从0到1开发MVP的文档需求，即让用户通过问题明确需求，在由AI（后期准备替换为我搭建的Agent）个性化给出开发文档：

完成了一个文件转换MCP server的开发，并被mcp.so网站收录，该server是希望agent接收到用户要求转换文件的需求时，agent调用该server并执行。项目已经开源：

https://github.com/wowyuarm/file-converter-mcp

在OpenManus项目刚出现时，我进行过简单的代码逻辑拆分并总结出文章（开源项目OpenManus的深入拆解与思考）。后续，我一直使用cursor来帮助我完成这个项目的详细学习，并且为我规划学习路径并给出学习笔记。

这里的不足，是我对于现有的AI coding带来的收获与反馈的不满，同时，也有模型本身的能力限制。

这更多的是在与AI进行开发的过程中，负反馈是大于正反馈的。

当然，这个前提是开发的项目并不只是前端或简单的后端逻辑。在以往的编程中，写代码本身进入状态本就是一种正反馈，而Vibe coding中的我可能边提出要求，另一边就在看书等待结果，出现bug就再提出要求，以此循环。

我大概总是期望着点击一次accept就能够得到想要的结果，而事实大多相反。

一方面是过高的期待带来的落差，让本来需要进行理性输入prompt的大脑得到负反馈而阻碍继续的vibe coding；另一方面，是模型能力的限制，这是来自上下文的限制、成本的原因、工具调用的问题。

下面是我对于Vibe coding的经验总结。

03 方法论

关于更加概括性的开发过程，可以参考这一篇（从代码到上线：我总结的AI开发全过程）。以下是比较细碎的方法论总结：

我先说一些未来伴随模型能力会解决的问题，方法论是现阶段如何实践的要点总结。

先给出解读（为什么），再说明实践原则（怎样做）。

上下文长度的限制：

这里的理论基础是现有模型的上下文长度限制（受自注意力机制的计算复杂度影响），也有我对于cursor agent对于工具使用的认识(从Cursor出发：对于Agent更好的理解与运用)（参见下一点）。

实践：每开发一个功能单开一个窗口，并使用这个prompt“ 请合理使用工具熟悉整个项目，确保你清楚各个文件的代码逻辑与项目关联，如果你需要具体文件请告诉我。（并附上上一次的对话窗口总结，通过@触发）”

文件修改未生效，或重复创建了已有功能的文件：

前者是cursor在应用edit_files这一工具时传递的参数或者网络出现了问题；后者则是cursor对于这一功能文件内容的缺失，归根到底是没有使用read_file或其他来获取与这一功能相关的内容。

实践：输入中强调"请合理使用工具"，或者要求agent先理解与功能相关的文件，再去修改。很多时候，他很会偷懒，总是没有看完文件以至于不清楚项目具体逻辑。

甚至，README文档会限制agent对于项目具体文件的阅读。

上面两点简单来讲其实还是成本的问题，即服务商不愿意花巨量token来让agent理解项目的每一行代码，或者说是用户也不愿意花费很多。

这些是由于模型的能力造成的一些未来可能会解决的问题，随着推理模型的进步，我很看好未来的coding agent发展前景。

关于MCP，我很看好这一协议在agent市场的应用，关于其介绍就不赘述。我配置了有如图片生成、网页抓取、控制台监控等的server，这些均赋予了agent在模拟我的操作一样，极大地加快开发速度。但是，还是因为其处于早期阶段，这些server普遍不够成熟，有些时候仍会遇到很多问题。
关于一些交互的prompt，我曾有过总结（Deepseek+Cline零成本快速开发浏览器插件 | 附8点code with AI体会）。

这一次的3.7sonnet-thinking非常强大，能够自己思考规划。

然而，有些时候3.7不够稳定，甚至无故增添一些不必要的功能或实现方式，导致项目结构被打乱。这种时候就要求我们对于自己项目的了解程度了，当然，Vibe coding只需要accept就够了。

合理使用@文件，前面提到模型对于某些文件内容理解不足，如果你清楚的话就提供给agent；如果不清楚，开启Ask模式进行询问，再@提供给agent。

心态很重要，很多遇到agent一直无法解决的问题时，就先搁置。等一段时间后再重新梳理并继续开发。
文档的准备与cursor/rules。这是项目MVP开发前需要准备好的，前文提到的MVPcode就是我对于这一方面的自动化，面向的是Vibe coding的个体。开发稍微复杂的项目前，就需要合理的进行规划了，可以与chatbot进行探讨。
- 通常，我的文档分为：project_requirements（项目需求）、app_flow（应用交互流程）、tech_stack（技术栈）、file_structure（文件结构）、frontend_guide（前端指导原则）、backend_guide（后端指导原则）、implementation（实现）。
最后，我的感受是想要利用好一款工具，最重要的是先用，而不是知识付费营造自己已经拥有的假象。

我相信，以上的一些总结是付费内容也没有的，更多的都是我在实际使用中的体会与总结，为的是更进一步的提升与有价值的分享。

当然，这只是有关于Vibe coding的内容，我对于编程的未来持有乐观态度，我认为，编程的门槛降低了，价值仍然在不断提高。

来自AI总结：

本文分析了作者使用Cursor进行Vibe Coding的经验，既展示了成功案例，也直面了现有技术的局限性。作者成功开发了多个项目，但也遇到了模型能力限制与用户期望过高带来的挑战。

作者提出了实用方法论：

1)为克服上下文限制，每个功能单独开窗并指导AI使用工具；

2)解决文件修改未生效问题，强调让AI先理解项目；

3)善用MCP协议扩展AI能力；

4)掌握有效提示词技巧；

5)保持灵活心态；

6)做好前期文档规划。

作者认为，尽管AI编程助手有不足，但通过正确使用方法可显著提升开发效率，编程门槛虽降低但价值持续提高。