说实话，接到邀请时我还有点忐忑，我是个I人，是那种小时候被老师点名起来回答问题，都会发抖的人。
现在倒是啥都无所谓了，但是临场的语言表达还是稍弱。
不过，我内心是有点兴奋的。
前几天，看到一位朋友的朋友圈，我特别认同其中一句话：体验世间的未知，才是生而为人的乐趣。
我觉得人生在于体验，我很愿意跳出自己的舒适区尝试新东西，当初从深圳裸辞回昆明all in AI，也是这股劲儿在推着我。所以，干了再说。
而且冷总给的选题（我的Vibe Coding实操与见解）我非常喜欢，不仅是因为我经常分享AI编程的文章，还因为25年也是AI编程飞速发展的一年（最近各大厂商也在疯狂卷AI IDE）
于是，跟冷总一拍即合，就有了这次成都之行。
在活动现场，我分享了一些自己的Vibe Coding的实操和见解。
在正式开始之前，我先给大家看了一个我最近用MiniMax Agent折腾的小项目。
这是一个有完整核心功能的虚拟商品平台，有前端，有后端，有数据库，甚至还打通了用户注册、登录和Stripe支付的全流程。
从一个想法，到一个能在线收款的电商网站，我只花了一个多小时，耗费100多¥。
这，就是Vibe Coding的魅力。
我偶然再次翻到，24年3月份靠ChatGPT Vibe Coding出来的一个小应用
再看了看最近用MiniMax Agent跑出来的电商平台
我才惊觉，这一年多以来，AI编程进化之神速，真是翻天覆地的变化！！
一、什么是Vibe Coding？
在展开之前，我们还得先弄明白，到底什么是Vibe Coding。
这个词最早是OpenAI的联合创始人，前特斯拉AI主管Andrej Karpathy在今年2月份提出的。我专门翻了一下他那篇X的推文。
翻译下来就是：
有一种全新的编程方式，我称之为：“氛围编程（vibe coding）”。在这种模式下，你完全沉浸于感觉（意识流），拥抱技术的指数级爆发，甚至彻底忘记代码的存在。
这之所以能实现，是因为像 Cursor Composer (搭配Sonnet模型) 这样的大语言模型已经强到离谱了。而且我基本上是用 SuperWhisper 语音输入和 Composer 对话，几乎都不用碰键盘。我会提一些懒到极致的要求，比如“把侧边栏的内边距减少一半”，因为我真的懒得自己去找那行代码。
我总是无脑点“全部接受”，早就懒得看代码差异（diffs）了。遇到报错信息，我连一个字都不加，直接就复制粘贴回去，通常这样问题就解决了。代码的体量会增长到超出我日常能理解的范围，我得花点时间才能真正读懂它。有时候大模型也修不好一个 bug，那我就绕开它，或者随便提些乱七八糟的修改，直到那个 bug 莫名其妙地消失。
这种玩法对于周末随便搞搞、用完就扔的小项目来说还不赖，而且真的挺有乐子的。我虽然在做一个项目或网页应用，但这感觉其实不算在写代码——我只是在看、在说、在运行、在复制粘贴，然后大部分时候，它就这么成了。
听起来是不是有点玄学，像意识流编程。
核心就一句话：通过自然语言指挥AI完成开发任务，忘掉代码本身，专注于想法，和创造。
你不需要成为一个逐行敲代码的码农，就能彻底放飞你的想法和创造力，只需要关注"为什么"做和"做什么"，至于"怎么做"，那是AI这个工具人操心的事儿。
当然，我要明确一点，Vibe Coding≠AI编程。
我认为AI编程的范畴更广（包含Vibe Coding），它需要关心统的架构设计，关心代码的扩展性和可维护性。而Vibe Coding，特指的是完全不需要关心代码的这种更彻底、更放飞自我的开发范式。
Vibe Coding这种新范式，和我们熟悉的传统开发流程，差异非常大。
传统开发中，一个项目启动，先拉上产品、设计、前后端、运维，开一场漫长的会议。产品的需求，在不同角色间来回传递，信息不断失真，效率极速下降。前后端联调，更是每个项目上线前的坎，有时候可能一个简单的接口参数命名不一致，就够两个人排查一下午。
我们大部分精力，都耗费在了解决人与人之间的沟通问题，和修补工具与工具之间的兼容问题上。
Vibe Coding的出现，直接把中间这些工作，压缩到了极致。
理论上，现在只需要一个人，一个大脑，就能和一个AI编程工具配合，就能快速完成过去一个小团队才能完成的工作。
开发者在这个过程中的角色，也发生了根本性的转变。
从一个代码的实现者，变成了AI的指导者。你的核心技能，不再是精通各种语法和框架，而是如何精准地描述需求，定义架构，以及有效的向AI提问。
所以，未来最流行的编程语言将是自然语言。
这个转变听起来很Nice，但实际操作起来，你可能又会发现，想用AI写好代码，也并不是一件容易的事。
很多人用AI写代码，感觉像在开盲盒，结果全凭运气。AI经常会误解你的意思，写的代码bug一堆，甚至把你的项目越改越乱。
那到底该怎么做？
PS：这篇不仅讲Vibe Coding，也讲AI编程
二、AI编程的见解
接下来分享的一些见解，并不完全是Vibe Coding的经验，也涉及到AI编程，因为会涉及到一些代码层面的经验（而Vibe Coding是要忘掉代码本身）
在分享现场，我给大家提了一个建议：要转变思维，不要当一个"只会提需求的甲方"，而要做一个"带徒弟的师傅"。
你想一哈，一个刚招进来的新兵蛋子，空有技术，但对项目一无所知。你是直接甩给他一句给我做个电商网站，还是会先跟他讲清楚项目的背景，需求细节，以及团队的技术规范？
答案显而易见。一句话需求，连人类都觉得头疼，更何况是AI呢？
想要AI能高效、准确地完成任务，你需要至少给它提供三大支持要素。
第一个要素，是告诉它做什么，也就是对齐需求。
最有效的办法，就是给它写一个清晰的README或者需求文档，把项目目标，核心功能，技术栈，甚至设计风格，都交代清楚。
当AI接收到需求之后，你要让它复述一遍，并向你确认。
这是最重要的第一步，给AI提供了完整的上下文，而不是让它空中阁楼。
第二个要素，是给它设定规则，规范动作。
比如在类Cursor这样的工具里，你可以配置一些开发约定，比如告诉它必须用Axios替代fetch，后台必须用Python，修改bug时，千万不要影响到其他现有功能等等。
这些规则，能约束它的行为，让它生成的代码符合你的预期。
第三个要素，是监督指导：要小步快跑，及时纠偏。
千万不要让AI一次性生成整个复杂的应用，翻车的概率很高。
可以先让它把复杂任务拆解得足够细，先建目录结构，再写单个功能模块，每一步都进行验证。这样你才能牢牢掌控开发过程，避免AI自由发挥导致项目失控。
当然，除了这些要素，还有一些更具体的操作。
比如，如果你的项目用到了一些开发框架（比如Java的springboot，mybatis等等），可以给AI搭配一个叫Context 7的MCP工具，它能让AI在写代码时，查阅官方文档和示例，大大提高生成代码的准确性和质量。
还有一个很重要的点，就是善用AI编程工具（比如Claude Code）的计划模式。
对于复杂的需求，先别着急让它写代码，先让它拆解需求，制定一个详细的执行计划。
你跟它几轮对话后，把思路和计划都对齐了，再让它动手，成功率会高很多。
另外，今天有个朋友问了我一个问题：
这个问题太经典了。
不要反复在有问题的代码上修修补补，要不然bug会越改越多，甚至到最后项目基本上就改废了..
有几个建议：
1.采用小步迭代的方式：每次只修改少量代码，便于快速定位和解决问题。
2.及时回滚：如果修改后问题更严重，要及时回滚到之前的版本，避免问题扩大化。
3.限制修改范围：限制AI的修改范围，只针对出现问题的部分进行修改，减少引入新问题的风险。
4.追问：在AI给出代码后，追问它选择该方式的原因、是否有其他方案及可能产生的影响，有助于理解它思考过程并、激发发现潜在问题。
5.模块化与低耦合：遵循单一职责原则，将函数和模块设计为只做一件事，以便于bug修改时影响范围小，同时AI也更容易理解和处理。
6.提供精准上下文：不仅要指出bug位置，还需提供完整错误日志、详细报错信息和相关截图；清晰描述期望效果与当前实际情况，帮助AI理解并修复bug。
如果一个bug，你让AI反复修改了三次还没解决，那就果断回滚代码，重新调整修补策略。
这说明你或者AI，对bug的根源理解出了问题。
回退代码后，重新给AI提供更充足的上下文，比如完整的错误日志，报错截图，清晰地描述期望效果和实际情况的差异，甚至可以追问AI的修改思路，让它自己审视会不会引发新的问题。
三、模型、AI编程工具选择
模型这块该怎么选呢？放张PPT的图吧
现在市面上的大模型太多了，大家经常会纠结，我这个任务，到底用哪个模型效果最好。但这本来不应该是用户操心的事。
我觉得，未来的趋势是智能匹配模型。
上周阿里新发布的AI IDE：Qoder就采用了这种方式，不过有点难受的是它不让用户看到内置了哪些模型，以及它内部的切换策略。
下面这个表格是我整理的，用过的部分主流AI编程工具对比（仅供参考）
我个人的建议是：
如果预算有限，或者小白刚接触AI编程，推荐Trae或者现在免费的Qoder
如果预算充足，推荐MinMax Agent
有一定技术能力，推荐Claude Code
AI编程工具现在很多了，也可以都试试，找到适合自己的就行。
四、Vibe Coding的局限性
前面我们聊了很多它的好处。但任何事物都有两面性，Vibe Coding也不例外。
目前它最大的局限性在于，对于企业级的，严肃的，大型复杂项目来说，Vibe Coding还不够看。
AI生成的代码，可能没有经过良好的设计，结构混乱，难以维护。
AI也可能在你看不到的地方，埋下隐藏的bug和安全漏洞。
长远来看，这种凭感觉快速开发出的项目，可能会积累大量的技术债（长期代码混乱，形成"屎山"），和及认知债：也就是团队里没人真正懂这些代码是怎么回事，以后谁都不敢动。
只能像下图这样🥲，这让人有点难受..
软件工程专家Dave Farley尖锐的提出："Vibe Coding是2025年最糟糕的想法！我们正在培养一代不会编程的开发者。"
目前来说Vibe Coding还不是银弹，它更像一把双刃剑。它在加速创造的同时，也在加速制造技术垃圾（当然，这个是用在企业内部核心项目的情况）。
目前Vibe Coding还主要适用于需要快速试错的初创企业或者个人MVP项目、以及概念验证（PoC）
但这归根结底还是模型的问题，不过后续应该可以通过工程优化（AI IDE）在一定程度上弥补上述的缺陷。
五、AI编程是银弹吗？
刚刚讲了Vibe Coding还并不适用于企业内重要项目使用。
那AI编程是否能成为企业中软件工程的银弹呢？
前几天看了@云中江树写的一篇公众号纯文字内容：
AI编程时代，软件工程真的没有银弹吗？
他表示在TRAE的活动现场，有嘉宾提到软件工程的真正瓶颈：
是想清楚做什么(设计思考)，而不是把想好的东西做出来(编码实现)。过去几十年所有的技术进步，包括现在的AI，都只是在优化编码这个次要任务，对设计思考这个根本任务的帮助有限。
这个观点，在过去四十年里，几乎是颠扑不破的真理。
但是，AI真的不能进行设计思考吗。
那篇文章里面，江树分享了一个Vibe Coding的真实案例，让我挺震撼的：
"有大佬的公司已经在用AI做架构设计，最终设计出的架构难以理解，也难以实现，但是硬着头皮去做，最终实现了30%，已经牛逼的不行了，根本无法想象完整的做出来会是怎样。"
我觉得AI能设计思考，至少现阶段，工程师可以跟AI多轮对话，思维碰撞后，极有可能产生比人类自己设计更牛逼的架构设计。
所以我认为AI编程是能成为银弹的。
但现阶段的Vibe Coding不能。
不过随着AI的能力会越来越强，以及工程优化（比如AI IDE的优化），带着Vibe Coding的上限也会越来越高，期待有一天，我们仅靠Vibe Coding就能完成非常复杂的大型企业项目。
「最后」
有意思的是，在活动现场，我从彭哥（@彭超）那里，看到了一台能跑本地大模型的性能猛兽。他给我演示了在本地流畅跑OpenAI最近才出的GPT-OSS 120B模型。甚至能跑更大参数量的。
120B啊！！！这个参数量，我之前想都不敢想，我的笔记本只配跑个8B模型😭。
进一步感受到，AI的发展，无论是软件还是硬件，都快到让人目不暇接。
我们每个人，都像是被时代洪流推着走的小船。你可以选择躺平，也可以选择奋力划桨，去看看更远处的风景。
但AI编程的这股浪潮已经来了（特别是最近大厂都纷纷下场AI IDE）
不要观望，不要害怕。今天就可以去下载一个AI编程工具，比如Trae，把你脑子里那些积攒已久的想法，在AI的帮助下变成现实。
在这个过程中，请记住：不要当一个"只会提需求的甲方"，而要做一个"带徒弟的师傅"。
这很重要。
