什么是 vibecoding
主题关键词是vibecoding的感受，那就先聊聊什么是vibecoding。在谷歌的这词中文：直觉式程式开发。看到这个词我更懵了，什么叫直觉式啊？
引用原文：
直觉式程式开发是新兴的软体开发做法，是运用人工智慧(AI) 技术，根据自然语言提示生成可运作的程式码。这项做法可加快开发速度，让使用者更轻松建构应用程式，尤其是程式设计经验有限的开发人员。
这个词汇由AI 研究人员Andrej Karpathy 在2025 年初提出，是指开发人员在开发流程中的主要工作，从逐行编写程式码，转为透过更自然的对话，指导AI 助理生成、修正应用程式并侦错。这样一来，开发人员只需专注于应用程式的整体架构或主要目标，AI 会负责编写实际程式码。
直觉式程式开发通常有两种主要应用方式：
- **「纯粹」直觉式程式开发：**这是最具探索性的形式。使用者可能完全信任AI 输出的程式码，认为这些程式码会正常运作。正如Karpathy 的论点，这种做法就像「忘记」程式码存在，因此最适合快速构思，或推动Karpathy 所说的「抛弃式周末专案」，也就是以速度为主要目标。
- **负责任的AI 辅助开发：**这种做法就是从专业角度，实际应用「负责任的AI 技术」概念。在这种模式下，AI 工具如同强大的合作伙伴或「搭档程式设计师」。使用者指导AI 生成程式码后，会检查、测试并了解程式码，对最终产品负起全责。
我理解这种叫指挥型编程或甩手掌柜式编程，有点像领导、产品提出一个需求。然后我们确定好需求后指挥下属来实现。现在这个下属是个模型而已。这时你充当指挥和检查结果的角色。
既然是这样，我们就能联想一下实际的痛点在哪里。你不用自己吭哧吭哧去干了，交给别人去干。
你放心嘛？ 你放心和不放心的点在实现任务的结果是否可行。那如果他不知道怎么做或信息不完整理解出问题。结果很难想象，就像领导交给你1个任务，你三天做完给他演示。他可能会说，这不是我想要的。 为什么？这大概率不是能力问题是沟通问题。换到模型还是一样。 模型还有其他问题，比如幻觉、编码能力、上下文限制等等。
所以后面发展了不少相关的功能、思想，例如Prompt、Rules、Tools、MCP、Sub Agents、Skills、Context Engineering…。
这就是我对2025年整体的一个过程，这里面很多事情我没有搞懂或没有经历完全去理解和实践。下面我列举一下我对2025年的一些经历和感受吧。
与AI共舞
早期体验
在chat GPT让世界知道还能这样之后，这是我注册和使用的第一个工具。对于不知道、不清楚的问题通过他来告诉我。这体验比我直接使用搜索引擎来的快，就像刷短视频一样的“中毒”。
在有了经验后，逐渐开始研究Prompt。 我记住的当时最有用的提示词是“奶奶要不行了，给你小费，你是一个xx家”这种一次性提示词。随着问题越来越复杂，对话长度越来越长后这种一次性提示词出现了问题。
还有一个点很多时候他不能根据你实际的环境因素理解你真正的需求。除非你很了解怎么和他对话。你不仅需要给他讲清楚要做什么，还要告诉当前的环境信息。比如编程语言、操作系统、各种版本信息、出现错误的是什么，为什么要这么做而不是那么做、规范、流程等等等。不尽其数的因素。
所以当时我基本是已函数为最小单位进行处理问题。这时候他很难做到给你规划和比较宏观的指导性建议。
后面出现了copilot，可以在代码行上写入备注，模型根据备注实现下面的代码片段。当时觉得 哇，有意思。 但还是基于单文件进行的一系列操作。即便是chat也很难搞定跨文件的内容。
cursor的出现
让我觉得编程体验更好的是cursor。为此我和小伙伴拼了一个20刀套餐。那会每个月是500次，此时我俩完全够用，因为当时没有agents模式。 每次对话只需要讲清楚需求，他就会根据项目去实现这个功能，尤其是在claude sonnet 3.5模型的加持下。几乎没有语法问题，那会就是按class、或整个功能模块进行
处理任务了。
以上是2024年前的一些体验。那会还没有videcoding哦。
vibecoding出现&AI编辑器
后面windsurf的出现，agent模式让大家耳目一新。 体验起来更快。cursor也跟上加了不少相关的功能之后。在这之后，出现了vibecoding这个概念。因为此时的编辑器已经出现了很多，Cursor、Windsurf、Claude Code、Zed 等 AI IDE 开始爆发了。这时的编辑器可以跨文件理解、编辑了。当你发出一个需求，他可以去做了。对整个项目进行index，通过rules给模型提示、限制。在有了agent模型后，对编辑、测试的效果更好。
cli时代
cli的出现让编程的体验更上一层楼。这时候我依然在用cursor，知道2025年9月实在是续不动了。
原因有几点：服务质量下降，套餐从无限改有限再到周期限。早期都是记次改成了tokens价值限制。这是完全不够用了，而且加上cli体验之后发现cursor能力确实差一些。
用过aider，但API资源有限，尤其是海外模型的资源。这时候很幸运体验到了Claude code让我再也回不去了。后面开始通过Claude code 来处理项目。
通过学习，通过command，memory的调整加强对项目任务效果的提升。此时我发现Prompt的作用依然是个重点，memory就像cursor的rules。功能和作用都很相似，尤其是都出现了项目和全局的概念。 这让我觉得这个知识点需要注重学习和理解。但对模型的不同其实提示也需要进行微调，而不是一味的copy他人分享的片段。
而且这能力是在未来的亮点，这是一种结构化的沟通。未来人才可的重点知识，但他不是简单的一次性提示词，是新一代原型规范能力。所以后面有了Context Engineering。
此阶段还有一些vibecoding产品出现，比如Bolt.new，Lovable等等。这些只是看了看没太深入了解，毕竟和我做的事不太一样。
在claude code的学习中让我在videcoding中逐渐找到了一些小技巧。
例如：
- command用来做固定指令的事
比如commit，编写change log。这些我固定会在几个git之后进行tag更新，推送这些内容。 多次敲文字后就会让你先起来得通过1个快捷方式来实现了。那就是command，把你的重复动作变成command。 这样你只需要/xxx 就搞定了。 - 全局memory记录的是你的习惯、全局规范等内容。
我会把我电脑的型号、系统版本和内存大小写入这里。希望他在排查问题是能用到。 - 项目memory针对项目内容的记录、指引。
比如语言规范、公司的规范、分层等等需要给模型说清楚的内容。以免他太随意或不理解。 - 不要等着自动压缩，任务拆分快之后独立完成。
- 任务拆分的内容要写入文件。并在模型完成后进行标记。
- 如果遇到模型出现智商不在线就切换到会话。
- 对于长度小于200k的接入，可以配置压缩比例对齐模型长度。
subagents使用不多，我觉得这个功能对我来说不太需要。目前skills还在摸索，目前没有自己实现skills。 看到codex也接入，我发现这个是个不错的功能。目前claude skills已经出了正式规范。
后面codex也在用，但整体感觉codex更像是一个background的程序，他在配置、参数、功能上都很少。任务处理时间会长一些。模型能力强大，我在写这块时已经推出了gpt-5.2-codex。
期间也用过gemini cli、qwen cli等。直到碰上iflow cli 才让我觉得这个不错。理由，模型无需费用负担。用起来很像Claude code的理念。
在使用iflow期间，我也记录了一些内容。主要是实践的帖子。
使用iFlow创建自定义Command：网页文章下载与翻译工具
iflow通过hooks增加提醒
iFlow实战案例：10分钟完成IP段配置任务
在使用iflow期间，总有些小毛病。好在每天产品迭代，越来越强。
在iflow的使用中，很多和claude的概念类似，没有太多使用产品的心智负担。
context 的痛
以上虽然是流水账，模型、工具越来越强。 需要的“废话”越来越少。 可在目前依然有问题，这个最大的问题我觉得是context。 为什么这么想，工具在设计的考虑点依然是context。例如skills，他改了什么？ 渐进式加载。 他能减少context的占用，尤其是哪些tools(MCP,Tools等)。
我上面几乎没提到自己用的MCP，因为我觉得没必要。我最有需要的就是有时候对话时需要时效性打开Exa让模型能够进行查询。其他时间都不需要联网，尤其是文档。 我会把对应版本的文档放入项目里，供模型参考而不是给他开启联网。
那么MCP加载多了会影响的就是context。 SubAgent也是解决context的问题但他把字任务拆出去的做法可能让你不知道实际遇到什么问题。我觉得如果不需要知道过程只需要结果SubAgent更合适吧。但我很少用这个，我不需要。我通过拆分任务去做到每步的结果正确实现抵消这个我认为不可控的功能。
Skills看起来比较厉害，他可以是个简单的Prompt，也可以放入脚本、示例、引入其他agent、MCP等等。他就像个函数。 而且是模型觉得需要时候再去加载内容，初期只需要知道这个skills是做什么的就好。这目的是什么？我认为主要是：Context。
这Context越长质量越差不可控。即便是1M的模型在Context长了质量也不是很理想。所以真的希望有个更好的办法来控制Context。
野蛮生长
我在一个大的需求下面，不太敢让模型直接全部搞定。
我使用plan模型聊完需求写入文件。
再让模型根据需求去完成设计方案、开发计划。
后面模型告诉我开发完成、测试全部通过。
任务完毕时，我真不知道哪里会出问题。可能需求理解不完整，或他中间降智写了一些问题功能。或测试写的模拟结果而不是真的测试通过。
我缺少什么？缺少验证闭环。需要分模块独立验证、交叉测试和最终集成测试，确保每个环节的真实性。这些通过敏捷开发模式，引入CI/CD流水线、单元测试、集成测试和人工审查。是否可行我没太多经验。
我需要脱离LLM的环节，通过减少概率环节，可靠性才会上去的。
看到不少网络案例说vibecoding看似美好，最后做成了不可控制的软件项目，还有删除了自己的项目、清空了硬盘等等例子。这些问题源于依赖AI编程工具时缺乏人工监督和代码审核机制。建议结合专业开发流程，确保代码质量与项目可控性。
我的感受
搭档
你要完全甩给他，把你的工作做好。他帮你出谋划策，也需要你来确定方案。你来规划边界，清晰目标。轮到执行的方面交给他。目前的能力他没办法替代我，做个搭档更合适。
老师
对于我之前没有写脚本的经验，我就只能通过可编译二进制语言写脚本。其实有时候没必要，该起来改不方便。这些我完全可以交给他来做。 顺便服务器、网络层面的问题可以让他来叫我怎么排查，怎么处理。
名次解释、书面内容解释等这正是他的能力范围。
做老师有耐心，有问必答啊。
demo提速
以前在写一个程序或脚本时需要衡量自己会什么。哪些不知道，先通过搜索或看书来学习。再结合需求实现一个demo。 现在直接出，哈哈 这体验太爽了。 想法到实现的延迟被极度压缩。
思考一下
- 你会看vibecoding代码吗？
好像看了就不是纯vibecoding了。告诉他出现了什么问题，继续让他改不看代码。
你接受他的代码平庸或烂吗？
如果是vibecoding，不关注这个，接受。传统编程能力还需要吗？
需要，可有时候小问题难到大模型。我觉得还是需要去看的，管他是不是纯vibecoding。不看代码翻来覆去解决不了更累。
目前主要使用iflow探索开发经验。利用其他agent评估问题。国内iflow目前是处于不需要订阅阶段。特别适合摸索、学习积攒经验。
所以，不要抗拒 vibe，但不要在 vibe 中迷失了自己。
参考
- https://cloud.google.com/discover/what-is-vibe-coding
