为什么要 Vibe Coding
大概一年半前我离职的时候，Vibe Coding 刚有苗头。那会儿做应用主要用 Cursor，公司内部用的还是微软 Copilot 那一套。到了 2025 年 3 到 5 月，Manus 爆火，Claude 这些模型的能力又上了一个台阶，身边不少写代码的朋友开始担心，自己的职业是不是走到头了。
我当时的判断是，程序员很可能会变成第二个土木，到今天我还是这么看。我给朋友们的建议是多做产品，多接触真实的商业世界，把出卖时间换成出卖可以复制的产品。Vibe Coding 正好让这件事变得可行：一个人就能把一个软件从想法做到上线。
可以复制的产品是一种杠杆
《纳瓦尔宝典》讲过三种杠杆：别人的劳动、资本，还有复制成本几乎为零的产品，也就是代码和媒体。前两种要别人点头才能用，代码和媒体不用，做一次，边际成本为0。
只是做出来之后，马上会碰到分发的问题。当下最紧缺的是注意力：平台卖注意力，创作者生产内容，内容可以是视频、文章，也可以是软件。很多从大公司出来的人就卡在这一步，有想法，但不擅长让人看见。
擅长分发的人，靠的多半也是一些固定的技巧，还没到吃天赋的地步。这跟在公司里吸引同事注意、争取上面的资源倾斜是一个道理，你得先搞出点动静。Vibe Coding 让一个人就能把软件做出来、发出去，本身就是搞出动静的好办法。怎么让更多人看到，是另一个话题，我们下期讲。
为什么还要讲方法
今天「要不要 Vibe Coding」已经不用讨论了，大家都在用。但和大模型打交道久了就会发现，它智力很高，输出却不稳定，你没法指望它每次都按你的想法、按你团队的习惯交付。记忆、上下文、Skills 这些手段能让它更贴近你，可总还会有大大小小的毛病。
有人说 AI 迭代这么快，等一等就好了。我的看法是，不能只等着对方升级。了解它的边界，设计一些办法去引导它，这些办法我叫它「工程」。就算以后被新工具替代，你也攒下了经验，更懂这套系统，遇到问题解决得更快。
我草稿箱里有一篇 2025 年写的「用 Cursor 怎么做好 Vibe Coding」，现在回头看，里面很多观点仍然成立。工具换了好几轮，方法留了下来，这也是我想把这些做法写出来的原因。
我是怎么做的
下面是过去一年多，特别是最近半年高强度用 AI 写代码之后，我自己的做法。我把读者当成刚入职的新人来讲。
工具
国内国外都有各自的第一梯队、第二梯队产品，挑一个顺手的就行。
我自己目前主力用 Claude Code，其次是 Codex；写长文时用 Google 的 Antigravity；需要打开编辑器逐行细改时用 Cursor。四个 20 美元的套餐，AI 编程每个月花 80 美元左右。比不上在公司里敞开了用，但套餐确实好用，性价比很高。备用的是 API，通过 OpenRouter 调 DeepSeek 等模型。
国内的朋友，现在比较主流的做法是买国内模型厂商的编程套餐，一般叫 Coding Plan，智谱、Kimi、MiniMax、字节火山方舟、阿里云百炼、百度千帆都有。买了之后，可以在 Claude Code 这类工具里接 DeepSeek、GLM、Kimi、Qwen 这些模型。写代码我推荐 DeepSeek，Kimi 做出来的前端也挺好看。
工具去官网下载就行，剩下的注册账号、初始化项目，都是固定步骤。
建文件夹，接上 Git
新建一个文件夹，项目的所有东西都放在里面，可以在自己电脑上，也可以在远端服务器上。然后用 Git 把它管起来。
没写过代码的朋友可能没听过版本管理，但它在真实项目里躲不开：一个版本在线上跑着，另一个版本还在调试；或者刚改的版本出了问题，要退回上一版。公司项目和个人项目都一样。一开始不会没关系，做几个项目下来，常用的几个命令自然就熟了。
动手之前先调研
编程 Agent 都是这么宣传的：你说出想法，它马上开干。我刚开始也是这么用的，确实会有惊艳的时刻，忍不住想像博主一样发出来分享。
如果只是想体验这种开盲盒式的快乐，怎么玩都行。要做一个能提高生产力、能给别人用的东西，就得先把需求弄清楚。我们的需求里，有的是真需求，有的是拍脑袋想出来的，还有的别人早就做出来了，只是我们没看到。
所以动手之前先搜一搜，自己搜或者让 AI 搜都行，GitHub、小红书、搜索引擎都可以。这一步也叫竞品调研。搜完一般是三种情况：
- 别人大概率已经做了。这很正常，我更推荐直接用现成的，每个人的时间精力都有限，不是每个想法都值得从头做。
- 做出来的成本比收益还高，比如手工处理反而更省事。那就先放进待定池，别急着开发。
- 大方向很常见，但你有细分的需求，比如换个平台用、更快、更简洁。经过这一轮思考还有自己的东西，就值得往下做。
前两种情况放下不做，是在保护注意力。我们要争取别人的注意力，开发的时候也要守住自己的。
把需求说成一段话
调研的过程中，需求会从一句话慢慢变成一段完整的描述。比较好的状态是你能讲清楚：什么样的人，在什么情况下，用这个东西达成什么目的。你自己讲得清楚，AI 理解起来也容易，后面开发就顺。
这一步可以和 AI 聊着做，但要提防它的讨好型人格和幻觉，它可能顺着你说，也可能编出不存在的东西。我常用的办法是换一个 AI 再问一遍，交叉review。
写 PRD，用工单管住范围
需求清楚了，就写一份 PRD，也就是需求文档，把项目的整体框架交代清楚，分出哪些是核心必须的，哪些是锦上添花的。
这里最要提防需求蔓延。一件事可做可不做，因为 AI 太方便，就顺手做了，我认为这个思路是错的。我自己有时也忍不住，顺手做掉一件不一定有线上收益的事。现在的办法是先记下来，记成一个 Issue，也就是一张工单。
在大公司协作也是一样，玩法、关卡、奖励，每个人对产品都有自己的理解，所以决策权一定要收住。一个人做产品，决策权在自己手上，更要管住自己。我的做法是每周写周总结时，给手上的工单排一次序，尽量只做排序这一件事，上周看下来不够靠前的就放进待定。
让 AI 开干
工单写清楚之后，可以给 AI 配一些 Skills，也就是别人总结好的经验和流程，比如技术选型、框架路线、产品风格、文档风格，有现成的就拿来用。
如果用的是最新的模型，我建议先让它直接做一版，看看效果，再在这个基础上调。布置任务时顺便让它查一查，哪些东西已经有现成的，哪些根本不用做。然后就是一轮一轮地开发了。
做出来之后
做到这里，东西其实已经可以发布了。但你很快会遇到新的问题：应用哪里不对劲，有 AI 味，前端有毛病，后端也有毛病。
去年大家还在争论 AI 写前端还行、写后端一塌糊涂，现在后端也写得差不多了，数据模型方面还有点儿小毛病。只要训练数据够多、反馈够强，模型很快就能学会更好的写法。用什么框架也不太要紧，网页、App、浏览器插件都能写，关键是把指令描述清楚。想商业化的话，支付必不可少，我目前用 Stripe，接起来问题不大。
心路与结果
回头看整个链条，有了 AI 之后，把产品做出来反而是最容易的一步，所以才有那么多博主说「有手就行」。可真正跑出来、被大众认可的产品并不多，大部分只是在消耗 Token，更有跑出来宣扬自己消耗多少 Token 的 AI嘉豪。我认识不少朋友，写完之后稀里糊涂，不知道怎么继续优化，自己用卡住，给别人用也卡住。
所以这篇之后，我想写一个系列，从做产品的角度聊东西做出来之后怎么办：遇到 Bug 怎么排，迭代的优先级怎么定，哪些事能全交给 AI；总觉得哪里不对劲，是交付流程、定价还是 UI 的问题，该怎么改；上线后有了一点数据，该收集什么，这些数据说明了什么。SEO 怎么做、定价怎么定，也会聊到。
我的背景偏算法，也做过一些工程开发，前端和 SEO 方面会更多引用别人的资料。
如果你是零基础，想从第一个页面开始一步步做，可以看我整理的入门版：Vibe Coding 是什么意思？氛围编程能做到什么、要自己做什么。