关于Vibe Coding和AI Agent的一些个人体验和思考
0. 引言
在这个大语言模型飞速进化的时代，人们似乎已经习惯了每天和AI进行各类对话，几乎达到了使用AI代替思考的地步。这个现象在计算机行业尤为明显，特别是编程开发领域，AI Coding Agent工具已经是程序员的标配了。
何为Vibe Coding？直译过来就是“氛围编程”。那么有人就要问了，什么是“氛围”呢？如果是刚刚读大一的我，可能无法回答这个问题。但是随着项目经验的丰富，我逐渐体会到，编程是一种极其需要专注的工作，专注力有助于我们加强对于项目上下文的记忆和理解，这就有点像大语言模型一样。你的上下文记忆越多，你的开发效率越高，出错的概率就越低。
这种专注就需要一种氛围来达成，一种舒适的心流状态是每个程序员所追求的。而 Vibe Coding 之所以能让我很快进入这种“氛围”，正是因为 AI 可以帮我快速理解当前项目架构和接下来的工作。
更加方便的做法便是，告诉AI一个模糊的需求，和AI一步步地打磨需求直到需求详尽，便可以让AI全权负责开发，自己则在一边看手机，刷视频了。
我是在2023年的年底接触到大语言模型的，我印象中当年还是ChatGPT 3.5，虽然现在看起来它十分智障，但是在当时已经足以帮助我写一些功能性函数，这对于我的毕业设计很有帮助，但是我也可以很自豪地说，我的本科毕业设计的代码AI率仅不到10%，大部分还是古法手工一行行敲出来的。
但是在最近开发的项目中，这个AI率到了多少呢？99.9%。
那0.1%，是我认为没必要为了一点点小的修改而耗费额度或Token时，选择手敲的内容。
我使用Vibe Coding完全负责了前后一共四个项目，有大有小，最后一个已经进行了数月之久，代码量已经到了20万行+。
当然，在此期间我的Token消耗量也是惊人的，根据不完全统计，从2025年6月份开始Vibe Coding，到现在2026年4月底，Token消耗量最少也有40亿了。而为了Vibe Coding所耗费的金钱也有上万人民币了。
所以，说了这么多，我想以一名全栈开发者的身份，谈谈我对于当前Vibe Coding的具体体验和看法，以及一些思考。
1. 我使用过的模型和工具
由于仅凭印象编写，如果有模型和发布时间对不上，请见谅。
在2023年底，刚开始接触ChatGPT 3.5时，我们只有一个在现在看来比较“简陋”的网页上和AI进行交流，你问我答的形式。
在24年，我接触到了ChatGPT 4o, o1, o3, Claude 3系列等工具，但此时大语言模型的使用还仅限于网页端的形式。令我印象深刻的是，Claude当时推出了一个叫project的功能，此时已经可以将自己的代码库的部分文件上传到一个project中，直接在Project中询问AI相关信息，AI就可以根据项目文件进行更精准的回答。现在思考了一下，可能是通过RAG实现的相关功能吧。
在2025年，我便接触到了Codex和Claude Code，这两个AI Agent开发工具，这对于我的硕士毕业可谓立下了汗马功劳（也埋雷了，后文会提到）。
时间到了今年，我现在主力的编程模型是Claude Opus 4.7，辅助模型GLM 5.1，测试中的模型是DeepSeek V4 Pro（最近又降价了，梁圣的恩情还不完了）。
由于留学生活的便利性，我能够非常简单地使用最新的模型，我十分感谢这段经历，如果不是这段经历，我也不会对Vibe Coding如此感兴趣并如今如此灵活的运用。
下面我来说说我对于Vibe Coding理解的逐渐变化。
2. 逐渐走偏
在那个模型上下文只有128K的时代，想要让模型在多轮对话后依然能够保持对前文的理解几乎是一件不可能的事情。每次在讨论问题时就会发现，模型在对话轮次递增之后，注意力的缺失导致模型开始前言不搭后语，于是我只能在一个对话窗口内，专注于一件事，或是在多轮compact之后完成目标。
例如在一个对话窗口内，提出一个需求，进行需求拆分，进而产生一份需求文档。
在另一个窗口内，上传需求文档，并明确要实现哪个模块的哪个功能，让AI产出一个函数，然后自己再修改一下细节使得整个文件能够跑通。
在这个时候，人类还在开发中占主导地位，注意，我这里说的是编码部分。
而在模型上下文逐渐提升后，有意思的事情来了。
我开始逐渐变得大胆，例如在Claude的Project中，我敢于把整个项目的项目文档上传，甚至会上传很多代码文件让Claude理解，一开始我惊叹不已，“程序员完蛋了”。但是随着使用深入，我逐渐发现，我的项目好像变成我无法理解的样子了，说人话就是，变成“屎山”了。
一般而言，对于“古法编程”来说，作为开发者的我是拥有对于整个项目的所有上下文的，甚至于说如果需要我去找到一个模块的一个函数，我都能在十几秒内找到。但是随着AI逐渐接管我的项目开发，我开始对整个项目的实现方法不了解了，这也就是说，项目变成了一个黑盒。
我对于开发失去掌控了。
这种状况持续了很长时间，直到我在开发了多个项目之后，我才逐渐掌握了一些开发的方法，并让我的项目开发逐渐重回正轨。
下面我就我自己的一些经验进行简单的分享。
3. 让Agent更懂你的项目
3.1 文档管理
首先，我们要知道一个大前提：AI不是许愿池。我一直坚信一点：即如果你不知道你的需求，那么AI也不知道，更无法理解，也不可能做好。
所以我首先会在每个项目开始前，充分调研，主要集中在以下内容：
- 我的创意是否已经有人做过？
- 如果有人做过，效果如何？
- 如果没人做过，为什么？
- 这个创意是否值得我从0开始做一个项目来实现，还是说现有轮子的组合已经够用？
- 如果确认实施，那么项目最适合的技术栈是什么？
- 项目需求分析、用户故事编写。
- 项目工时预估。
其中最重要的三点就是4，5和6。
如果我们盲目地追求造轮子，不仅仅耽误了时间，更浪费了钱，最后做出来的东西，很可能只是别人已有成熟产品的拙劣仿制品。
从使用AI Coding以来，我一直有一个原则：坚决不使用我不熟悉的技术栈进行开发。为什么？道理很简单：你看不懂AI的输出，也无从纠错。如果你不能给AI前进的方向进行纠错和指引，开发顺利还好，一旦遇到了疑难杂症，连最基础的排查都会成为问题，到头来还得被迫去学习这门语言的基本知识，得不偿失。
需求分析是重中之重，在我们的“古法编程”时代，软件工程就一直强调这一点了。如果需求不清晰，用户使用场景不明确，那么做出来的产品也是模糊的、质量低且很难使用的。后期打磨所要花费的时间更是难以想象的。所以我的每个项目的起点，都会是一份内容详细的PRD文档。
一般来讲，我的项目的根目录下会有一个CLAUDE.md/AGENTS.md（用于Claude Code或Codex）的总约束，这里面包含了：
- 项目的简介。
- 项目技术栈。
- Agent在开始前的注意事项和检查内容。
- Agent编码中的注意事项。
- Agent完成编码后的SOP。
- Agent编码规范（代码风格，变量名风格等）。
- 杂项说明。
- 单元测试说明。
- 保密说明。
事实证明，Agent在这些约束下，能够更快地、更准确地开展工作。
在项目的根目录下，还会包含一个docs文件夹，里面包含了该项目的所有相关文档，一般以文件夹区分不同的模块文档，docs根目录下会保存整个项目的代码结构文档：project_structure.md，让Agent一目了然。
3.2 Prompt构建
看到这里可能会有人想问：Prompt不就是使用自然语言和AI聊天似的沟通吗？如果是这样的话，那么对于Prompt的理解还是存在偏差的。
一个好的Prompt可以帮助AI Agent快速找到重点，确定方向，提升开发效率。而不是让AI Agent去猜用户的需求，然后人和AI来回拉扯对齐几轮，再开始干活。
目前我个人使用的实践是：描述具体需求，开发方向，具体的操作方法（git分支切换，commit规则等），并让AI和我确认细节并等待实施。
更好的实践是，尽量多地使用 CLAUDE.md / AGENTS.md，在这些文件的约束下，和Agent的对话会更加的快捷和简单。
尤其是最近，Claude Code也支持memory了，如果你认为某个经验教训值得记忆但是又不值得写到文档里，可以告知Agent记下来。
3.3 Plan before Execute
现阶段所有的Agent都会有Plan模式，也有类似superpower这类的skill来约束Agent。这些东西万变不离其宗：都是Plan before Execute。
Plan的意义在于让Agent慢下来，拿到足够的上下文，确保和用户的思考对齐后再进行编码操作，否则，轻则需求没实现，重则直接乱改代码，删库跑路都有可能。
所以，Plan的作用非常明显。从我的开发体感上，除非是非常小的任务（如修改一行配置或代码），否则在较大的改动上，开不开 Plan 差距巨大。不开Plan，Agent在执行的过程中时常会因为上下文不全做出错误的判断，对于我们人类来讲反而更加劳神。
4. 让Agent更省钱
Tokens 是在Vibe Coding时代消耗最大的东西了，背后全都是真金白银。虽然现在各个大厂（除了DeepSeek）都有Coding Plan，但是限额是实打实的。
所以要让开发更加的高性价比，一些措施还是有必要执行的。
4.1 缓存管理
观察各个大厂的API费用就会发现：未命中缓存的输入/输出往往意味着很高昂的价格，但命中缓存后，价格就会大幅下降。
简单来说，我们常说的缓存就是KV Cache，如果我们的Prompt使用前缀匹配的方式命中了缓存，那么厂商就不用再计算我们前缀部分的KV，而是直接将新内容的KV计算出来后，拼接到之前缓存好的KV Cache后，并得出最终的结果，这样可以大幅地节省计算资源并提高输出速度。
在我个人的AI Agent项目中，为了提升缓存命中率所做的工程非常多，例如将不变的Prompt尽可能地提前，并尽量在同一时间内尽可能多地调用同类型任务以最大限度地利用缓存。因为厂商可不是大善人，缓存都是有时限的，超过时限不调用就没了。
同理，在Vibe Coding中，我们如果从零一步步地把上下文堆到一个很庞大的水平时，我的实践就是尽量不要让Agent停太久的时间。我们的每一轮对话是存在缓存的，如果说我们停止了过长的时间，缓存失效了，那就意味着我们将会把一个长达几百K Tokens的无缓存上下文直接发送给模型，那么这些输入内容的价格就很美丽了，同样反映在Coding Plan上就是用量突然涨了一大截。
* 在这里不得不感叹DeepSeek的缓存做得真好，在AI Agent Coding时的命中率能到90%+，而我的AI Agent项目也能做到60%+，真的节省了很多开销，尤其是DeepSeek的缓存价格简直像白送一样，我只能说真香了。
4.2 上下文管理
* 这方面主要是在AI Agent开发时要解决的问题，即如何控制tool calling时的返回规模以及多轮tool use后的Prompt膨胀问题，但和本文章的主旨并不贴合所以不展开说了。
上下文管理在Vibe Coding中也很重要，具体表现在1M上下文模型还没有普及前，大部分厂商提供的都是256K的上下文模型，动不动就满了，任务干一半Agent罢工。
最佳的实践就是对于每个任务都派发Subagent执行。这样可以节省主Agent的上下文空间，使得其更能专注于任务本身。
即使进入到了1M时代，由于注意力机制的问题，我认为仍然不要放开使用主Agent包揽一切任务，不然再大的上下文也不够用的。
5. 多用脑
很多程序员（包括我）都对于AI的迅猛发展表示过担忧，但我在Vibe Coding一年之后，如今得出了其他的结论：多用脑。
我目前认为，AI在工程能力、项目规划、功能验收等方面，仍然不如人类。至少我不敢只给AI一个PRD文档让其全程自驱执行，因为这必然伴随着大量的黑箱内容，项目的健壮性难以得到保证。
Vibe Coding出来的产品在大部分时候对于开发者来说是一个黑箱，即不知道项目的具体架构，以及AI是否在编结果，也就是面向结果编程。
我曾经深受Vibe Coding残害。在我硕士毕业项目中，当时还没有Coding Agent，AI在给我的实验代码中大量使用硬编码数据或Magic Number，要不是我及时检查，就可能被扣上学术不端的指控了。
而在我硕士毕业后的第一个探索项目中，由于没有使用项目文档规范开发，整个项目结构相当狂野，以至于最后我竟无从下手，只能是AI说什么我都回复“没问题”。实际真的没问题吗？估计没人知道了。最后这个项目成为了屎山，所有的改动都是在已有内容上缝缝补补。后来因为项目的价值存疑，所以也被我关停了。
所以我经过一系列的摸爬滚打，最终摸出来了一套较为稳定的Agent约束文档，也就是上面提到的CLAUDE.md / AGENTS.md，和相应的文档管理体系，最终使得Agent的输出内容更加的有迹可循。
这也是我最新的项目达到了20万+行代码，而我仍能对项目有较强的掌控力，同时还能时不时地Review一下Agent输出的代码的原因。
所以，我认为在项目立项、管理、架构设计中一定要亲力亲为，多动动脑子。AI不是万能的解决方案，至少在现在还不是。如果放任AI自由开发，那它只会堆一座漂亮的巧克力味的屎山。
所以，人类还没有那么早完蛋。