前几天在成都做了一场关于AI编程的分享，说实话，接到邀请时心情有点复杂——一方面是兴奋，另一方面又暗自揣测：一个平时习惯躲在屏幕后面码字的人，真能把这事儿讲明白吗？

但转念一想，人生不就是体验各种未知么。当初从深圳裸辞回昆明all in AI，靠的就是这股劲儿。既然机会来了，那就干呗。

而且这个话题我确实有话想说。2025年，AI编程的进化速度实在太快了，各大厂商纷纷下场卷AI IDE，新工具、新范式层出不穷。尤其是最近用MiniMax Agent跑了一个电商平台之后，那种“翻天覆地”的感觉格外强烈。

再看一眼刚搭出来的这个电商页面，真的有点恍惚——一年多以前，这些事情还像科幻片。

一、什么是Vibe Coding？

在聊具体经验之前，得先把概念说清楚。

“Vibe Coding”这个词，是OpenAI联合创始人、前特斯拉AI主管Andrej Karpathy在今年2月提出来的。我专门翻了一下他那篇推文，翻译过来大概是这么个意思：

用Karpathy的原话说，这是一种“氛围编程”——你完全沉浸在直觉和意识流里，拥抱技术指数级的增长，甚至忘记代码本身的存在。

听起来有点玄学？其实核心就一句话：用自然语言指挥AI完成开发任务，把注意力从“怎么写代码”转移到“我想做什么”上。

你不需要逐行敲代码，不需要纠结语法和框架。你只需要想清楚“为什么做”和“做什么”，至于“怎么做”，那是AI这个超级工具人该操心的事。

但有一点得明确：Vibe Coding ≠ AI编程。AI编程的范围更广，它需要关心系统架构、代码的扩展性和可维护性。而Vibe Coding特指那种更彻底、更放飞自我的开发范式——完全不用管代码长什么样。

这种新范式，和传统开发的差异堪称天壤之别。

传统流程里，一个项目启动要先拉产品、设计、前后端、运维开会，需求在不同角色间来回传递，信息不断衰减。前后端联调更是每个项目上线前的鬼门关——有时候一个接口参数命名不一致，两个人能排查一下午。

大部分精力都耗在了人与人之间的沟通，和工具与工具之间的兼容问题上。

Vibe Coding的出现，直接把中间这些环节压缩到了极致。理论上，现在一个人、一个大脑，加上一个AI编程工具，就能完成过去一个小团队的工作。

开发者的角色也因此发生了根本转变：从代码的实现者，变成了AI的指导者。核心技能不再是精通各种语法和框架，而是如何精准地描述需求、定义架构、有效提问。

所以有人说，未来最流行的编程语言将是自然语言。

这个转变听起来很美好，但实际操作起来，很多人会发现：用AI写好代码，并不是一件容易的事。很多人用AI写代码像开盲盒，结果全凭运气。AI经常误解你的意思，生成的代码bug一堆，甚至越改越乱。

那到底该怎么搞？

（PS：以下内容不仅适用于Vibe Coding，也涵盖更广泛的AI编程经验。）

二、AI编程的见解

在分享现场，我提了一个建议：转变思维，不要当一个“只会提需求的甲方”，而要做一个“带徒弟的师傅”。

设想一下，一个刚招进来的新人，空有技术但对项目一无所知。你是直接甩一句“给我做个电商网站”，还是会先跟他讲清楚项目背景、需求细节、技术规范？答案不言自明。一句话需求，连人类都觉得头疼，何况AI？

想让AI高效准确地完成任务，至少需要提供三大支持要素：

第一，对齐需求。最有效的办法，是给它写一个清晰的README或需求文档，把项目目标、核心功能、技术栈、设计风格都交代清楚。AI收到需求后，要让它复述一遍并向你确认。这是最关键的第一步——给AI提供完整的上下文，而不是让它凭空猜测。

第二，设定规则。比如在Cursor这类工具里，你可以配置一些开发约定：必须用Axios代替fetch，后台用Python，修改bug时不能影响现有功能等等。这些规则能约束AI的行为，让生成的代码符合你的预期。

第三，监督指导。小步快跑，及时纠偏。千万不要让AI一次性生成整个复杂应用——翻车概率极高。先让它把复杂任务拆细，先建目录结构，再写单个功能模块，每一步都验证。这样才能牢牢掌控开发过程，避免AI自由发挥导致项目失控。

还有一些更具体的操作。比如，如果项目用到了某个开发框架（像Ja va的Spring Boot、MyBatis等），可以搭配一个叫Context 7的MCP工具，它能让AI在写代码时查阅官方文档和示例，大大提高代码准确性。

另一个重点是善用AI编程工具（比如Claude Code）的计划模式。对于复杂需求，别急着让它写代码，先让它拆解需求、制定执行计划。你跟它来回几轮对话，把思路和计划对齐了，再让它动手，成功率会高很多。

分享现场有个朋友问了一个非常经典的问题：

不要反复在有问题的代码上修修补补，否则bug会越改越多，最后项目基本就改废了。

这里有几个实操建议：

1. 小步迭代：每次只修改少量代码，便于快速定位问题。

2. 及时回滚：如果修改后问题更严重，果断回滚到之前版本。

3. 限制修改范围：只针对出问题的部分修改，减少引入新风险。

4. 追问：在AI给出代码后，追问它选择该方案的原因、有无其他方案、可能产生的影响——这有助于理解它的思考过程，发现潜在问题。

5. 模块化与低耦合：遵循单一职责原则，函数和模块只做一件事，方便修改时影响范围小，AI也更容易理解。

6. 提供精准上下文：不仅指出bug位置，还要提供完整错误日志、报错信息、相关截图；清晰描述期望效果与实际差异。

如果一个bug让AI反复修改三次还没解决，果断回滚代码，重新调整策略。这说明你或AI对bug根源的理解出了问题。回退后，重新给AI提供更充足的上下文，甚至可以追问AI的修改思路，让它自己审视会不会引发新问题。

三、模型与AI编程工具选择

模型该怎么选？先放一张PPT上的对比图。

现在市面上的大模型太多，大家经常纠结某个任务到底用哪个模型效果最好。但这本来不应该是用户操心的事。未来的趋势应该是智能匹配模型——上周阿里新发布的AI IDE Qoder就用到了这种方式，不过有点遗憾的是，它不让用户看到内置了哪些模型以及切换策略。

下面这个表格整理了部分主流AI编程工具的对比（仅供参考）：

个人建议：

预算有限或刚接触AI编程：推荐Trae或现在免费的Qoder。

预算充足：推荐MiniMax Agent。

有一定技术能力：推荐Claude Code。

当然，AI编程工具现在很多了，都试试，找到适合自己的就行。

四、Vibe Coding的局限性

任何事物都有两面性，Vibe Coding也不例外。目前它最大的局限性在于：对于企业级、严肃的大型复杂项目来说，还不太够看。

AI生成的代码可能没有经过良好的设计，结构混乱、难以维护。它也可能在看不见的地方埋下隐藏的bug和安全漏洞。长远来看，凭感觉快速开发的项目，容易积累大量“技术债”（代码混乱形成的“屎山”）和“认知债”——团队里没人真正懂这些代码是怎么回事，以后谁都不敢动。

软件工程专家Da ve Farley甚至尖锐地批评：“Vibe Coding是2025年最糟糕的想法！我们正在培养一代不会编程的开发者。”

所以说，Vibe Coding不是“银弹”。它是一把双刃剑——在加速创造的同时，也在加速制造技术垃圾。目前它主要适用于需要快速试错的初创企业、个人MVP项目、以及概念验证（PoC）。

当然，这归根结底还是模型的问题，后续应该可以通过工程优化（比如AI IDE的改进）在一定程度上弥补这些缺陷。

五、AI编程是银弹吗？

刚刚提到Vibe Coding还不适用于企业内部核心项目，那AI编程本身，能成为软件工程的银弹吗？

前几天看到@云中江树的一篇文章，讲到一个观点：软件工程真正的瓶颈是想清楚做什么（设计思考），而不是把想好的东西做出来（编码实现）。过去几十年的技术进步，包括现在的AI，都只是在优化编码这个次要任务，对设计思考这个根本任务帮助有限。

这个观点在过去四十年里几乎是颠扑不破的真理。但问题在于——AI真的不能进行设计思考吗？

那篇文章里分享了一个真实案例：某大厂已经在用AI做架构设计，最终设计出的架构虽然难以理解、难以实现，但硬着头皮做下去，最终实现了30%，效果已经让人惊叹。无法想象完整实现出来会是怎样。

从实践来看，至少现阶段，工程师完全可以跟AI进行多轮对话、思维碰撞，极有可能产生比人类自己设计更优的架构方案。所以，AI编程是有可能成为银弹的。

但现阶段的Vibe Coding不行。不过，随着AI能力越来越强，加上工程优化（比如AI IDE的完善），Vibe Coding的天花板也会越来越高。期待有一天，我们仅靠Vibe Coding就能完成非常复杂的大型企业项目。

最后

有意思的是，活动现场从彭哥（@彭超）那里看到了一台能跑本地大模型的性能猛兽。他给我演示了在本地流畅跑OpenAI刚出的GPT-OSS 120B模型，甚至还能跑更大参数量的。120B啊！这个参数量之前想都不敢想——我的笔记本只配跑个8B模型。

进一步感受到，AI的发展，无论是软件还是硬件，都快到让人目不暇接。

我们每个人，都像被时代洪流推着走的小船。可以选择躺平，也可以选择奋力划桨，去看看更远处的风景。

AI编程这股浪潮已经来了——特别是最近大厂纷纷下场做AI IDE。不要观望，不要害怕。今天就可以去下载一个AI编程工具，比如Trae，把你脑子里积攒已久的想法，在AI的帮助下变成现实。

在这个过程中，请记住那句话：不要当一个“只会提需求的甲方”，而要做一个“带徒弟的师傅”。

这很重要。