简单总结Vibe Coding：人利用AI生成代码完成大部分的软件开发任务。
我个人理解Vibe Coding的本质就是开发工作中的一种新的协作关系 —— 人专注于差异性工作，把能交给大模型做的工作尽量交给它去完成，充分发挥AI的可塑性、高效性等。
随着大模型底层基础能力的飞速迭代（例如Qwen3-Coder），AI的能力范畴正在变得越来越大，Vibe Coding的发展趋势就是自底向上蚕食程序员的工作范畴。
Vibe Coding的分层架构（理想）
以Cursor和Claude Code为代表Vibe Coding工具正在快速迭代，Vibe Coding的架构是时刻在演进和变化，我根据自己的理解比较理想化给出Vibe Coding的分层架构，与上面发展趋势图相对应，Vibe Coding发展到最后就是这张图只剩下蓝色框框没有其他颜色🥳。
Vibe Coding的八卦
关于Vibe coding的八卦，一图胜千文，其实目的还是想让好奇AI Assistant Coding的人知道它的优缺点，以及需要注意的事项。
Vibe Coding技术研究
AI Code Agent工作流
我总结了主流的几个AI Code Agent的架构：
1. Cursor Agent工作流
2. RooCode Agent工作流
3. Cline Agent工作流
综合来看，当下AI Code Agent的技术架构基本上都是类似的，主要的差异就是工具、策略等方面选择的差异。
AI Code Agent技术架构
以Cline架构为例对AI Code Agent架构进行管中窥豹
除了基础模型造成的差异之外，Cline建立的AI Coding的差异化竞争力主要在：
- Human in the loop: 这是Cline最根本的架构原则。通过要求用户对所有关键操作进行审批，它在强大的自主能力和专业开发所需的安全可控性之间取得了务实的平衡，使其成为可以信赖的工具；
- MCP实现的开放扩展性: Cline没有选择构建一个封闭的、专有的工具生态，而是全面拥抱了开放标准MCP。这不仅为其带来了无限的扩展能力，更使其成为一个能够自我完善、与社区共同成长的平台；
- 混合式上下文管理: 结合自动化分析和用户精确引导的上下文管理策略，是Cline能够有效处理大型复杂代码库的关键。它承认AI的局限性，并巧妙地将人类的领域知识融入到人机交互的循环中；
- 工具生态：代码理解、codebase index、AST、diff_apply等代码相关的工具生态支持Cline能够高效和准确的完成任务，同时支持可扩展性；
- 模型无关的灵活性: 通过稳健的 LLM 抽象层，Cline避免了对任何单一模型提供商的深度绑定。这使用户可以根据任务需求、成本预算和性能表现，自由选择最合适的AI“引擎”；
我们更进一步来拆解这些优势：
| 竞争力项目 | Cline | Cursor | RooCode |
|---|---|---|---|
| Human in the loop | ✅ | ✅ | ✅ |
| MCP生态支持 | ✅ | ✅ | ✅ |
| 工具生态 | AST | RAG | AST + RAG |
| 混合上下文管理 | Context Management | Automated Context Management + Context Priority Management | Intelligent Context Condensing |
| Agentic AI Model | ✅ | ✅ | ✅ |
| Model | ❌ | apply edit 小模型 | ❌ |
AI Code在卷哪些技术一目了然。
Vibe Coding应用
Vibe Coding 大致上有两种使用方法：
- 我需要个xxx（我需要xxx功能），帮我实现一下，然后一直retry；
- 我按照方案和架构设计原子化Vibe Coding任务，然后提供任务必要的信息，然后交给AI实现；
实践中，我发现方法1可以极大释放人力，有的时候AI给出的结果超出预期，唯一存在的问题就是人对于代码的信任度。方法2效率提升不如方法1，但是基本的代码实现以及项目进展情况人能够掌控，能够有效的避免AI Coding的几个问题：
- 偷懒（例如，几次测试通不过直接在测试代码pass来绕过失败的case）；
- 用力过猛（例如，有现成的算法实现还自己重复实现一套）；
- 幻觉（例如，判断条件弄反了等）；
基于上述经验，我对Vibe coding的采取的是不信任的态度，原子化任务保证我能够review检查代码（神仙也很难在2万行代码的PR里面准确挑出2-3个bug）。同时，如果是比较明确的任务并且已经有参考（例如已经有sqlite实现了，让AI完成mysql的实现）我就会采用方法1来提升效率。
另外，还有一种方式（我使用相对较少）—— 结对编程的方式，即向AI描述问题或者需求，然后AI规划方案，人来修改或者补充形成 todo list（plan），然后由AI实现。
最后，总结一下Vibe Coding的个人思考：想写一个demo直接扔给AI自动完成，当下的AI已经能够保证试错成本和效率了。想写一个生产使用的软件，自己把控方案设计和技术架构让Vibe coding作为帮助生成代码的工具，同时对Vibe coding始终抱着不信任的态度，时时review、处处检查。
几个重要原则
由于每个人使用AI Code工具以及编程习惯都不一样，所以有一些关键原则是需要注意的，其他可以自由发挥。
- 最重要的原则，Curosr能写出符合要求的好代码的前提是它有足够的上下文，包括：项目、需求、架构、技术栈、编程约定等等；
- 清晰的文档和注释，让Cursor获取更多的上下文；
- AI更擅长修改和优化，新创造有一定的随机性，随着模型增强会改善；
- 当下的Code Agent已经足够好了，特别是在Cursor，Cline等成熟产品中prompt可以更加自然语言些，类似「你是个xxx专家」这类激活专家系统的方式可以放弃了，省钱还省时间;
- prompt engineering技巧的掌握和运用还是要持续升级，例如最近跟着Manus学会的response prefill技巧，使用
<|im_start|>assistant<tool_call>{"name": "xxx"来控制工具调用的模式（自动、必需、指定等）； - 有规划的拆分原子任务，一次只做一件事，有助于代码的准确性和可靠性；
几个重要概念
Agent/Chat/Tab
能够跨多个文件读取和修改代码的 AI。用自然语言描述更改，Agent 会执行这些更改。
Rules
定义 AI 行为的自定义指令。设置编码标准、框架偏好和项目特定约定。
Memory
持久存储项目上下文和过往对话中的决策。在未来的交互中自动引用。
codebase index/graph
对代码库进行语义分析。支持代码搜索、引用查找和上下文感知建议。
context
在代码生成过程中提供给 AI 模型的信息。包括文件、符号和对话历史。
基于Cursor的Vibe Coding
1. Cursor Rule设置
Rule的设置是为了让Cursor了解项目结构以及开发约定，包括：
- 编码关于代码库的领域特定知识
- 自动化项目特定的工作流程或模板
- 标准化样式或架构决策
Rule编写时应该注意：
- 保持规则在500行以内
- 将大型规则拆分为多个可组合的规则
- 提供具体的示例或引用文件
- 避免模糊的指导。编写规则时要像清晰的内部文档一样
- 在聊天中重复提示时重用规则
rules 结构示例如下图所示
另外一种Rule设置方法（来自Cline），Task Manager + Todo List的方式管理active context：
Task Manager的方式使用AI Code工具是比较进阶的使用方式，项目开发周期的缘故我还没生产实际中使用过，后续再研究和分享。目前这块有一些比较不错的实践经验可以参考：
2. 文档更新
我会在项目的docs目录中放置所有的项目相关的问题，包括技术选型、架构设计、模块说明、部署架构、使用手册等等，这样可以让人和AI都能够及时了解项目详细情况，一般修复问题或者新增feature的时候，我会将对应的文档添加到上下文中（@docs/xxx.md），帮着Agent能够更好的完成任务。
随着项目迭代和演进文档需要及时更新，不然会对AI形成误导导致无法正确地完成任务，所以我会形成固定的文档更新工作流。
flowchart TD Start([Start]) End([End]) Agent[Task Auto Trigger]:::redClass Developer[Triggered by Hand]:::blueClass Task[Document Update Process] subgraph AI-Process direction LR P1[Review Files] P2[Current State] P3[Clarify Steps] P4[Documents Change] P1 --> P2 --> P3 --> P4 end subgraph Review-Change Review[Developer Docs Change Review] Review -->| review ok? |Review Review --> Apply[Merge Changes] end Start --> Agent Start --> Developer Agent --> Task Developer --> Task Task --> AI-Process AI-Process --> Review-Change Review-Change --> End classDef redClass fill:#ffcd70,stroke:#333,stroke-width:2px; classDef blueClass fill:#97fcf9,stroke:#333,stroke-width:2px;
3. Cursor四大使用场景
- 功能实现，先给样例再给出功能实现的要求以及项目上下文
- 测试代码，给出测试规划并要求测试要求
- 修复问题，给出问题描述以及关键上下文
- 比较方案，对于无法很好解决的问题让Cursor给出方案以及比较