Vibe Coding 让零基础产品经理也能快速实现创意，但狂欢之后才是真正的考验。本文作者以5个实战项目为样本，揭秘从造物快感到碰壁期的完整心路历程，并给出用PM思维管理AI协作、版本控制等硬核解决方案，最后回归产品本质：降低开发门槛不等于降低成功门槛。
最近消失了很久，沉迷vibe coding，妆也不化了，视频也不录了，今天聊聊我的一些想法。
为什么写这篇：
很多人在聊 Vibe Coding 有多神奇：不会代码也能做产品。
但很少有人说：做出来之后呢？
我是一个零技术基础的产品经理，过去两个月用 Vibe Coding 做了5个小项目。
今天想聊聊这个过程中的几个阶段，遇到的问题和解决方案。
我做产品9年，和其他产品经理一样，入行做PM，最初都是带着热情的：
把想法变成实物，被人喜欢，那种”造物主”的成就感足够让人着迷。
Vibe Coding 把这种感觉放大了100倍。
我们只需要一个CC对话框，说出想法：
它帮你找对标、套方案、生成代码，快的时候几分钟就能跑起来。
这种速度会让人快速上瘾，程序员朋友说这段时间的我，和他刚学代码、第一次写出能跑的程序 那时候一样癫。
这个阶段你会觉得：我太强了我可以独立接单了商单找我！（bushi
开源项目不满足我的需求，当我需要后端、需要自定义逻辑、需要多个功能联动。
问题开始出现。
问题1：AI记忆断了
聊着聊着，AI 忘了之前说好的了，开始自由发挥。
做出来的东西跟你要的完全不一样。
你不懂代码，面对前端报错只能复制粘贴：黑盒不知道怎么定位问题，更不知道怎么改。
问题2：改错了 回不去了
你让它改一个东西，它顺手提交了。
你想退回去，发现退不了。
多个 agent 协作时，各自提交，大乱炖，代码直接一团乱麻。
问题3：搭起来容易，改起来难
为了快速跑通 MVP，用了很多”能跑就行”的方案。
等你想加新功能，发现根本加不进去。
这个阶段很多人会卡住，或者放弃，或者硬撑。
考过PMP的或者软考的我们会发现：这些问题不是新问题，传统行业和 IT 行业早就解决过了。
那是不是解法也一样：用标准PRD锁定方向
每次迭代前把产品文档PRD拿出来对齐。
目标变了就改文档，不能让 AI 自由发挥方向。
MVP 用简单技术跑通没问题。
但要提前想清楚：到什么规模需要换成熟技术栈。
避免后期功能根本加不进去的情况。
分支：
个人推荐三条分支：
另外：每次上线打一个版本包存档，想回退随时有快照。
版本：
我的版本管理比较通用简单：v1.2.3
1是大版本-比如加大功能；
2是中间 比如模块修改维度的 ；
3是小版本，比如改bug等。
设计、运营、开发、项目管理，找各自擅长的模型来做。
但分工越细，越需要文档把所有人“锁死”在同一个目标上。
就算规范做得再好，上线之后你会发现：
没有人用。
你以为酒香不怕巷子深，但市场不会自动找到你。同类产品做得更好的已经存在，你的精力全部清零。
此刻我终于明白:GitHub 上那些无人维护的项目，大多数都是这么来的…
不是技术问题，是从来没有人用过。
你浪费的不止是时间，不是金钱，是注意力。时间可以量化，金钱可以量化，注意力没法量化。
但它是你最重要的资源。
先做市场调研和竞品分析→验证这个东西值不值得做→再动手
研发成本低不代表注意力成本低。
熟悉吗？我们掉回了产品经理的饭碗里。
走到这里，我开始质疑：
零技术基础做 Vibe Coding，到底合理吗？
目前看来，跑通 MVP 是合理的。
但如果目标是做一个真正成熟的产品，后期的：
（1）报错定位
（2）性能优化
（3）架构调整
没有技术基础很难吞吐。
那么只有技术合理吗？
最好不要，毕竟做出来只是第一步。
用 Vibe Coding 快速验证想法，跑通就行，不追求做成成熟产品。
这样前面那套规范可以轻很多，产品经理更应该把重心放在”这个想法值不值得做”和“怎么建造护城河”等问题上。
回头看这整个过程，会发现：Vibe Coding 正在重走传统 IT 行业走过的路。
从野蛮生长到规范流程，从单人摸索到分工协作，连遇到的坑都一样。
区别只有一个：
传统 IT 走了二十年，Vibe Coding 一两年就踩完了。门槛低了，踩坑的人从工程师变成了所有人。
但没有人告诉他们前人已经解决过这些问题。
先验证需求，再动手做
MVP 够用就行，不要追求完美
学一点技术基础
用 PM 思维管理项目
或者找到你的技术搭档
Vibe Coding 降低了做产品的门槛，这是好事。但它没有降低做好产品的门槛。
想法变成代码很快，代码变成产品很难，产品变成有人用的产品更难。
这条路上，技术只是第一步。
本文由 @嘻嘻李 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。