当产品经理遭遇AI编程工具，从盲目编码到架构思维的转变带来截然不同的结果。本文通过一次竞品采集工具的开发历程，揭示跳过需求分析与架构设计的致命陷阱，并总结出六步Vibe Coding方法论——从MVP定义到模块化实施，展现产品思维如何成为AI时代开发者的核心优势。
“帮我做一个竞品信息采集工具，我输入一个网址，它帮我提取产品名称、核心功能、定价、用户评价，然后输出成表格。”
这是上个月，我对着 Cursor 说的第一句话。
AI 刷刷刷写了一个 Python 脚本，能跑。我当时特别兴奋，觉得 Vibe Coding 也不过如此，一句 prompt 搞定。
然后，噩梦开始了。
上个月我在做竞品分析，每天要从十几个网站上手动扒信息。
标题、功能亮点、定价策略、用户评价……每次都是同样的字段，但每次都要重新复制粘贴。
我心想：这不就是个信息提取加结构化输出的活儿吗？AI 最擅长的事。
于是我打开 Cursor，对着 AI 说了一句话。AI 很听话，刷刷刷给我写了一个 Python 脚本，能跑。
就这样，我开始了第一次 Vibe Coding 之旅。
第一面墙是脚本只能命令行跑。我想给团队里的实习生也用一下，发现她完全不会用命令行。我想做个界面，AI 给我加了个 Streamlit 前端，但跟原来的脚本怎么都接不上。
第二面墙是技术栈越改越乱。我让 AI 改用 Flask 做后端，它改了。第二天我又说要不用 FastAPI 吧，它又改了。到第三天，项目里同时存在三种框架的残留代码，我自己都看不懂哪段是在用的。
第三面墙是数据没地方存。一开始提取的结果直接打印在终端里，后来我想保存下来，AI 给我写了个 CSV，再后来我想做历史查询，又改成 SQLite。每换一次，之前的代码就要大面积重写。
第四面墙是本地能跑但分享不了。我在自己电脑上一切正常，但想发给同事用的时候，环境依赖、Python 版本、API Key 配置……全是坑。
折腾了将近一周，我看着一堆面目全非的代码，做了一个痛苦的决定：全部推翻，从零开始。
冷静下来之后，我开始回想这一周到底出了什么问题。
AI 写的每一段代码，单独拿出来看，其实都没什么毛病。问题是我从来没想清楚一件事：这个工具最终应该以什么形态存在。
我一上来就让 AI 写代码，就像没有设计图就直接盖房子。砖头一块块地砌，看着也在往上走，但越盖越歪，最后只能拆了重来。
这就是我踩进去的最大的坑：跳过了架构，直接跳到了编码。
而架构这个词，听起来很技术，但其实它只是要你回答几个简单的问题。它是什么形态？跑在哪里？数据放哪？做到什么程度？这些问题里没有一行代码，全是产品经理最擅长的事。
第二次，我换了一个完全不同的方式。
我没有一上来就让 AI 写代码，而是先跟它聊了一轮需求。我说我想做一个竞品信息采集工具，目标用户是我和团队里的非技术同事，核心功能就是输入网址、提取关键信息、输出成表格。我熟悉 Web 技术，但不太会后端部署。请先不要写代码，帮我比较几种可行的架构方案。
AI 给了我三个方案的对比。Python 脚本开发快但分享难。Web App 开发中速但分享容易、扩展性好。Chrome 插件是折中方案。
结合我的情况——要分享给非技术同事用，未来可能加更多数据源——AI 推荐了 Web App，并给出了具体理由。
接着我又问了几个问题。
技术栈怎么选？推荐 Next.js 加 Supabase，因为我熟悉前端，Supabase 免运维。
目录结构怎么定？标准的 app、components、lib、api 结构。
分几个阶段做？阶段一单页面提取，阶段二批量处理加历史记录，阶段三团队协作。
最后，我让 AI 把这些全部整理成一份可以直接用于 Vibe Coding 的架构提示词。
拿着这份提示词，第二轮开发顺利得让我自己都惊讶。两天就跑通了核心流程，第三天团队同事已经在用了。
回头看，第一次和第二次的区别，核心就一件事：我在写代码之前，先把骨架定了下来。
这里的骨架不是什么高深的系统架构设计，而是回答几个产品经理本来就该想的问题。
它是什么形态？网页、App、脚本、还是 Agent？不同形态决定了完全不同的技术路径。
它跑在哪？本地还是云端？这决定了你的部署策略和分享方式。
数据放哪？数据库、云存储、还是本地文件？这关系到后面的一切功能扩展。
做到什么程度？是一个 demo 还是一个可持续迭代的产品？MVP 的边界在哪？
这些问题看起来很简单，但如果你不先回答它们，AI 就只能猜你的意图。它猜对了是运气，猜错了就是返工。
基于这次踩坑经历，我总结了一套自己在用的流程。
第一步是定义目标。只做 MVP，砍掉所有”以后再说”的功能。问自己：这个东西最小做到什么程度，我就愿意用？
第二步是确定架构。让 AI 帮你比较几种方案，选最适合当前阶段的，不是最炫的。
第三步是拆任务。按功能模块拆成独立的小块，每个模块可以单独验证。
第四步是逐步实施。每次只让 AI 做一个模块。不要一次丢一堆需求给它，那样的代码你连看都看不过来。
第五步是边做边测。完成一个模块就跑起来试试，发现问题的成本越早越低。
第六步是优化迭代。先让它能用，再让它好用。先完成，再完美。
这几周做 Vibe Coding 下来，我最大的一个感受是：写代码这件事，真的已经没那么重要了。
AI 可以帮你写代码、改代码、重构代码，但它没法替你做一个决定——这个东西应该以什么形态存在。
这恰恰是产品经理最擅长的事情。
所以我的建议是：下次打开 AI 编程工具的时候，别急着让它写代码。先跟它聊聊，让它帮你想清楚架构。
先让 AI 做架构师，再让 AI 做工程师。路选对了，后面才能走得快、走得远。
本文由 @3Mz 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。