大家好，我是智昊。一名普通的产品经理。
关于我与 AI 编程的历程
说来惭愧，我真正开始玩 AI 追溯到 2022 年GPT3.5 刚发布那会，那个时候我第一次知道生成式 AI，我当时非常兴致勃勃地到 Jango 那里学了机器学习和大语言模型，但是花了很长一段时间后我发现除了作为谈资以外没什么可以用得上的，再加上 OpenAI 那狗屎一样的模型命名规则，我后面就没继续往下玩。
之后我又陆续了解到 gemini、claude，国内的有智谱、文心一言、星火、Qwen还有 deepseek。是的，deepseek刚出 v2 那会我就玩过了，我当时和业内的一些朋友也聊，我说这家公司这个成本杀出来只是迟早的事情，果然 V3 成为了巨大的拐点。
那个时候我基本上就是拿星火帮我把 excel 表格转化成 markdown 扔到产品文档里，后面用 GPT4 写一些爬虫脚本，辅助我进行编程学习，至于 vibecoding 的转折点，实际上要追溯到去年 12 月。那个时候我第一次接触到 cursor这款神奇的 ide，我第一次发现这种需要我自己从对话框里把代码复制出来再用 git diff 对比一下然后看一下没什么问题再扔到我文件里面的事情被一款 ide 自己解决得是多么优雅的一件事。
在那之后，我才真正开始入门 vibecoding。我在一个对话框里输入一段话“请帮我用 pygame 生成一个贪吃蛇游戏”，然后过了 2 分钟就能玩了这件事实在是太酷了。那个时候我还找了几个开发帮我一起测试 cursor，结果我们遗憾地发现，它好像并不能适应较大的项目，因为它的上下文长度对于一个项目来讲还是太低了。所以我后面又改为自己玩，不怎么嚯嚯我们的技术同学了。
在这个期间，我一直在学习提示词工程，rules 编写，项目结构调整，模型测试，mcp 工具，然后补齐自己在编程上的一些短板（主要是前端还有数据库），在经历了半年之后，我发现我可以在一个周末跑通一个 demo 了。
我做Vibecoding的心得
我觉得是时候写一点东西出来了。那么我们就从这里开始吧。
心得一：可以零基础但不要以此为荣
带我入门 vibecoding 的教练主要有两位，一位是花生，一位是大铭。花生教练主要是搞零基础编程的，他现在在做 AI 自媒体；大铭则一直是做 vibecoding 的程序员。我一开始对零基础非常兴奋，我觉得我可以当甩手掌柜了，我只需要说要做成啥样子，它自己就会搞完，然后我验收成果就行。但是我后面发现根本不是这样子。哪怕我把提示词写得再好，再明确，再事无巨细，AI 一定会因为上下文的问题跑偏，执行十几分钟最后出来个垃圾。所以，一定要看代码，要学会看代码，要善于发现代码里面的业务问题，框架问题，细节上的逻辑问题。
心得二：show me the talk
之前就行一段话，叫“talk is cheap, show me the code”；现在这句话因为AI的编程能力提升巨大导致 code 的价值被完全拉下来了，特别是面向业务编程，写 CURD 这些东西已经变得十分廉价，可能现在在 coding 层面最值钱的只有架构、优化、bugfit。之前说的“我有特别棒的点子，就差个程序员了”的一群人也全部不见了，因为他们意识到自己的点子就是个垃圾。
只有被市场验证为优秀的好点子才能存活下来。但是现在的试错成本成倍数地下降，你可以很快地去验证自己的点子究竟是不是个垃圾。
心得三：不要让 AI 写产品方案
不要让 AI 写产品方案，至少，不要用 AI 生成一个方案就直接投入开发。我们要把 AI 当做一个老师、一个教练，而不是一个助手或者下属。是的，你没听错，时代变了大人，AI 已经在各个层面上打败了人类产品，你所掌握的知识和它所掌握的知识根本不是一个数量级的东西。多和 AI 讨论产品方案，讨论需求，把你和客户的聊天记录发给它，让它帮你突破自己的产品设计边界，找到你可能没有发现的问题，这是现阶段用 AI 做产品最大的价值。
心得四：面向 AI 编程
这句话的意思和上面那一条类似。在 coding 层面，你要熟练运用多个大模型来回切换，然后看情况开新窗口。比如，o3 的数学能力很强，搜索能力也很强，可以用来写特别复杂可参考内容少的逻辑，gemini 2.5 pro 的上下文很长，特别适合一开始了解项目全貌；claude 4 sonnet 的架构能力很强，起新项目可以用它，另外它对前端的适应性和微调能力很强，做后期优化可以用。所以一般对于小项目我们都是无脑 claude 用到开发完。
心得五：不要忠诚于任何Agent
最早我用 GPT 编程，之后我用 cursor 编程，然后我还尝试了 trae，也尝试过豆包，也用过 cline、roocode。如果你打算开始进行 vibecoding，你买的产品尽量都用月付的方式完成。因为它们实在太容易被超越了。谁家提示词好，谁家东西做的好，我们就用谁家的。比如我现在已经切换成 augment+claudecode 了。任何 Agent coding 产品应该都是可以拿来试的，不要局限于那么几个产品，有些时候，Agent 之间的差异比模型之间的差异还要大。你如果玩过的话，你就会发现，同样是 claude 4 sonnet，claude code 的发挥就很好，cursor 还能看，trae 就基本是个摆设。
心得六：多逛reddit
reddit 是国外版百度贴吧，我基本上都是高强度刷vibecoding 和 vibedev 两个子站，里面有很多人问问题，也有很多人分享自己的心得，我的很多 vibecoding 的能力和技巧都是在 reddit 上学的，相较于 X，reddit 才是更具有针对性的社区。
心得七：coding，not debugging
关于 debug 的问题。尽量让整个应用一次成型。我知道这很难，但是一定要往这个方向去做。我之前尝试过好几种控制模型能力范围的做法，比如做 todolist，比如限定它只做一点点地方，或者是让他先找到功能对应的代码位置然后我手动进行修改，但是都不尽如人意。
最近，我又更新了我的工作流。我发现，在这个工作流下，系统的完成程度相当高，而且几乎没有 debug 的过程，流程很顺畅地就跑完了。核心的要义就是事无巨细地让模型能够知道你要它做什么，甚至要它怎么干，干成啥样子，怎么检测，事无巨细地弄出来。怎么做呢？把它当成一个真正的程序员就可以了。
你要给它 PRD，要给它原型图，要给它技术方案，要给它开发计划，然后还要强调让它按照开发计划去完成工作，完成后自己更新开发计划。
经过这个动作，代码开发质量特别高，基本不会有 bug 出现，开发的需求也不会有反复。这一块我到时候会详细讲怎么做。
心得八：经常推翻，时时总结，偶尔满意
在现在这个阶段，code 的成本已经几乎趋近于没有，之前你要花一周做的东西，可能模型 2 个小时给你全做完了。这就意味着，它一旦 code 的结果不符合你的要求，你就可以回滚。这个时候，你需要额外注意使用git 来管理你的代码版本。每次大模型手搓完代码，你都要去检查一遍，确认业务没问题之后，就可以直接 commit，一旦发现错误，你就给它放弃掉。玩过竞速游戏的同学应该听说过一种叫做TAS 的模式，TAS 的意思就是回滚游戏画面到之前的特定帧后继续游戏。在 vibecoding 里，你也应该这么做。
当你做的应用足够多了之后，之前踩过的坑都会在之后的项目里有好处。比如你一开始不知道怎么做多语言，后面你知道了你就会直接把需求放到你的 PRD 里；之前你不会调 API，你学会了之后就会让 AI 自己去调 postman；之前你不知道 MCP 工具，你学会了之后就会自己安装 MCP 工具让大模型自己用。
不要做了一个应用就抛掉一个，一个一个做，做完了就做一下总结，它数据跑的好你就多迭代，跑的不好你就换下一个，换之前记得留档，这些东西都会有意义，可能开发 100 个应用只有 2-3 个是满意的，无所谓，反正开发速度快，就这么做下去就行了。
心得九：在满足别人前，先满足自己的需求
这是最后一条了。我觉得大家玩 vibecoding 的时候尽量不要太功利化，是的，我们可以做到 idea to business，但是如果 coding 本身没有让你感受到快乐，没有改变你自己的生活或工作方式，说明你还没有真正玩起来，没有洞察需求的能力。
没有洞察过自己的需求，何谈洞察他人的需求，做的产品多总是碰到几个死耗子并不是长久之计，而且一旦做了四五个应用之后没有什么好的反馈，你可能就自暴自弃就不玩了。尽量让这件事情开始的时候足够轻松，足够简单，有长时间的正反馈可能更重要。所以，先满足自己，再考虑别人，收钱的事情后面再说，自己用爽才是核心诉求。
一起加油吧！
