从一句话需求到能跑的原型:AI PM 的 Vibe Coding 实战方法论
为什么这是一项硬技能
2025 年初,Andrej Karpathy 提出"Vibe Coding"一词,描述一种新的开发方式:不再逐行写代码,而是用自然语言描述意图,让 AI 生成代码,自己专注判断"方向对不对"。
💤
这个词后来被 Collins 词典评为 2025 年度词汇——它描述的不只是编程潮流,更是一项正在下沉到产品岗位的能力。
对 AI PM 来说,这项技能打通了一个长期存在的断点:过去,一个想法从"我觉得可以这样做"到"证明这个方向靠谱",中间隔着一份 PRD、一次排期、一轮开发。现在 PM 可以自己把想法做成能点、能用、能让人一眼看懂的原型——验证交互是否顺畅,或说服业务方一个方向值得投入。这也是为什么 转型行动计划 把"亲手搭一个小 demo"列为转型早期的必做产出。
但 Vibe Coding 不是"把需求丢给 AI,等它吐出一个完整应用"。真正决定原型能不能做出来、做得好不好的,是 PM 有没有一套靠谱的工作方法。
一、完整工作流总览
代码块
Plain Text
① 需求澄清:把"一句话需求"追问成"谁在什么场景下,要解决什么问题,做完什么样子算成功"
↓
② 拆解成可执行步骤:拆成 3-6 个可独立验证的小步骤,而不是一个大而全的任务
↓
③ 选工具:按原型形态选合适的 AI 编程工具,够用就好,不追求最强
↓
④ 迭代式提示:一步一步喂给 AI,每步验证通过再往下走
↓
⑤ 调试与自查:遇到报错、卡住、结果不对时有章法地定位,而不是反复重新生成
↓
⑥ 打磨到可演示状态:补齐空状态、错误提示、演示路径
第④、⑤步会反复循环好几轮,这正是"迭代式"的核心含义。
二、六个阶段的具体打法
① 需求澄清:拿到需求先想清楚——谁在用(自己验证想法,还是给业务方演示)、解决什么具体问题("客服平均要翻 3 分钟 Excel"比"帮客服提效"更可拆解)、做完什么样子算成功。这一步和 PRD 的"背景与目标"是同一个动作,想清楚、能对自己讲明白即可,详细提问方式可参考 AI PRD 怎么写。
② 拆解成可执行步骤:新手最容易犯的错误,是把想清楚的完整需求原封不动丢给 AI,期待一次生成"成品"。生成的代码量越大,出问题时越难定位,越容易陷入"改一处坏三处"的死循环。正确做法是像搭积木一样先做出"能跑但很糙"的最小版本,再逐层加功能,每一步都要能在几分钟内肉眼验证对不对。
③ 选工具:2026 年的 AI 编程工具大致两类——Lovable、Bolt、Replit Agent 这类"浏览器全栈生成器",输入描述就能生成带界面、可部署的完整应用,几乎不用碰命令行,对零代码基础的 PM 最友好;Claude Code、Codex、Antigravity、Cursor 这类"编程 Agent",操作真实代码库,形态可以是独立桌面端、终端或 IDE,并不一定绑编辑器,更适合精细控制或在已有项目上迭代。具体对比见 Vibe Coding 工具全景图。第一次做原型优先选前者,等确实需要对接已有代码库或长期维护,再考虑后者。
④ 迭代式提示:整套方法论的核心,四个技巧——
•
描述交互,不代替 AI 决定实现:与其说"用数组做过滤",不如说"输入关键词后列表要实时更新,不用点搜索按钮"。前者你大概率说不准,还可能限制更优方案;后者才是你真正在意的产品效果。
•
一次只加一个功能:把拆解好的步骤一步一个 Prompt 喂给 AI,做完自己先验证,再继续下一步。
•
给具体例子而非抽象描述:"检索要准"没有标准;"客服输入'退货要多久',应该排最前的是讲时效的那条,而不是讲流程的那条"才可执行。
•
主动设定边界:AI 倾向"贴心地"多做——加登录页、加数据库、加后台。不需要就在 Prompt 里明说"不需要账号登录,先不接数据库",否则容易在无关功能上耗掉大量轮次。
常用句式:
代码块
Plain Text
描述交互而不是实现:
"点击这条结果后,原文要能一键复制到剪贴板,按钮上要有'已复制'的文字反馈,
不需要弹窗提示。"
限定范围:
"这一步只做搜索和展示,不用加登录、不用接数据库,数据先写死在代码里。"
给出判断标准:
"如果一个问题在 FAQ 库里找不到足够相关的答案,就显示'没有找到相关答案,
⑤ 调试与自查:遇到问题按这个顺序处理,比反复重新生成效率高得多——把完整报错信息原样贴给 AI,不要自己转述(关键线索常藏在具体措辞和行号里);要求 AI 先解释原因再给方案,而不是直接"帮我修好";一次只让 AI 改一处,改完立刻验证;卡住超过几轮就换思路或退回上一个能跑的版本,不要在一个细节上死磕。
代码块
Plain Text
"刚才这段代码报了这个错:[完整粘贴报错内容]
先不要急着改,用大白话跟我解释一下这大概率是什么原因导致的,
以及你打算怎么改、为什么这么改。"
这个习惯不仅为了解决当下报错,更是让你始终清楚"原型现在是怎么运作的"——这一点在第四节"何时交给工程师"会用到:你至少要能讲清楚原型的大致逻辑,而不是甩过去一堆自己也不懂的代码。
⑥ 打磨到可演示状态:功能跑通只是及格线,至少还要补齐空状态(无数据/无结果时的提示)、加载状态(请求等待时的反馈)、边界输入处理(空输入、超长文本、连续提交不能让页面崩溃),以及一条提前验证过的"傻瓜式"演示路径。
三、案例走查:给客服团队做一个 FAQ 检索小工具
以下走查为虚构但贴近真实场景,展示提示词如何一轮轮演化。最初的一句话需求:"客服同事现在靠 Ctrl+F 翻一个几百行的 Excel 找话术,太慢了,能不能做个工具直接搜。"
第 1 轮 · 限定范围
代码块
Plain Text
我要做一个网页小工具。客服同事输入客户问题的关键词,工具从 FAQ 库
(先用我给的 10 条示例数据)里找出最相关的 3 条答案,按相关度排列,
点击可一键复制。不用管账号登录、不用接数据库,先做一个能在浏览器
里跑起来的单页面就行。
问题:AI 按"关键词精确匹配"实现,客服输入"退货要多久"完全搜不到标题是《退换货时效说明》的答案——现实中提问方式和文档标题几乎不会逐字重合,这是这类工具最常见的第一个坑。
第 2 轮 · 升级为语义检索
代码块
Plain Text
问题:AI 说明需要调用 embedding 接口做向量化,但没配置 API Key,运行直接报错——原型依赖了一个还没准备好的外部条件,新手常见卡点。
第 3 轮 · 处理报错
代码块
Plain Text
刚才运行报了这个错:[粘贴完整报错]
是不是因为没配置向量化服务的 Key?用大白话说清楚这一步具体依赖
什么,申请之前有没有更简单的临时方案能先把流程跑通?
在 AI 解释后发现,10 条数据的规模不需要真正的向量数据库,一个轻量的开源文本相似度方法就够用,不必现在申请外部服务。
第 4 轮 · 接入真实数据
代码块
Plain Text
把示例数据换成脱敏后的 200 条真实 FAQ 数据(已去掉姓名和联系方式)。
如果找不到足够相关的答案,不要硬凑,显示"没有找到相关答案,建议
转人工处理"。
问题:数据从 10 条变成 200 条后,出现几条相似度评分虚高但明显文不对题的结果——这是语义检索常见的坑,和 什么是 RAG 里"检索不准直接决定答案质量"是同一个问题。这一轮没有靠 AI 自己判断,而是让业务同事实际试用、圈出错误结果反馈调整,原型迭代到这一步已离不开真实用户参与。
第 5 轮 · 打磨到可演示状态
代码块
Plain Text
功能跑通了,现在打磨成可以给团队演示的状态:搜索要有加载提示;
空输入时提交按钮禁用;样式做得干净、正经一点;最后列一下这个
原型目前还有哪些已知问题、没做的功能。
五轮迭代后,得到一个可以现场演示、验证"语义检索能把查找时间从分钟级压到秒级"这个核心假设的原型。它还远不能上生产——这正是下一节要讲的边界。
四、什么时候该喊工程师接手
模型选型框架 讲的是生产阶段 PM 和算法工程师的分工边界;这里讲的是更早一步——demo 阶段就该判断"这件事还能不能自己捣鼓下去"。出现下面任意信号,就该喊工程师接手,而不是硬着头皮往前拱:
判断核心不是"复杂不复杂",而是"要不要为真实用户的真实数据、真实业务负责"。一旦答案是"要",原型阶段就该结束,交给工程师从头设计,而不是把 PM 写的原型代码直接"升级"成生产系统——这正是"vibe coding 出的东西直接怼上生产"事故频发的根源。交接时,把第 5 轮要求 AI 列出的"已知问题清单"连同关键提示词记录一并交给工程师,能大幅降低沟通成本。
五、常见踩坑与对策
六、可复用清单:Vibe Coding 项目自查清单
代码块
Markdown
# Vibe Coding 项目自查清单