上周有个朋友兴冲冲给我看他用 Cursor vibe coding 做出来的一款AI产品 Demo打开产品链接第一屏是个很唬人的控制台左边菜单八个大项右上角一个很精致的引导按钮看起来像模像样。我问他你这个产品到底是给谁用的用户进来第一件事干什么他愣了一下说我还没想好但我把能想到的功能都写进提示词让AI做了。我让他把当时的提示词给我看了一下果不其然一页功能清单做登录注册、做数据看板、做消息通知、做用户管理、做设置页、做主题切换……所有需求点用顿号串成一串像超市购物清单。结果AI全都做出来了每个页面都有一堆元素但放进真实场景里哪个都不好用。这就是现在玩 vibe coding 的人最常见的通病——把提示词写成了功能清单而不是产品叙事。这篇文章我想认真聊聊这件事为什么大家用 vibe coding 做AI产品时提示词总是写成功能清单这种写法到底坑在哪里正确的提示词应该是什么样我用实际案例拆给你看尽量做到可以直接抄作业。1. 先搞清楚vibe coding 的时候你写的到底是什么1.1 vibe coding 不是随便写写是产品意图翻译vibe coding 这个词这两年很火核心玩法就是你用自然语言描述需求让AI来完成大部分代码编写你的角色从写代码的人变成了定义产品并不断校正方向的人。听起来门槛低了但有一个隐藏前提被很多人忽略了你的描述能力就是产品下限。以前做开发程序员拿到需求后还要自己补充大量实现细节需求文档写得烂一点技术好的程序员能往回找补。现在不一样了AI不是人它不会在写代码之前先开个会跟你确认这个功能到底为什么存在你喂给它什么描述它就按什么描述生成。你的描述是功能清单它就给你堆功能你的描述是一个完整场景它才可能给你一个完整产品。我用一个生活化的类比来解释这件事。如果你想请一个装修公司给你做全屋设计你说我要两个卧室、一个厨房、一个卫生间、一个客厅再装个投影仪装修公司大概率给你搞出一个四面白墙、功能区切割得很生硬的房子。但如果你说我平时一个人住周末偶尔有三五好友来聚餐希望客厅能坐得下六个人厨房要方便同时出两道大菜卧室晚上要能完全遮光装修公司就知道哪里该做岛台、哪里该用推拉门、哪里该留暗装窗帘盒。同样的道理功能清单是材料列表场景叙事才是设计图纸。而且更有意思的是AI这装修公司还不会主动问你要图纸你给它什么它就信什么。1.2 功能清单式提示词的真实长相我先放一段我朋友那种典型的功能清单式提示词你看看熟不熟悉用 React 开发一个团队协作工具需要以下功能 1. 用户注册登录 2. 项目列表 3. 任务管理增删改查 4. 成员管理 5. 消息通知 6. 数据统计图表 7. 文件上传下载 8. 评论功能 9. 主题切换亮色/暗色 10. 响应式布局 请生成完整的项目代码。这段提示词看起来信息密度很高十个功能点技术栈也指定了但你要是真把它丢给 Cursor 或 Trae产出的东西大概率是一个漫长的侧边栏、十个长得一模一样的空壳页面、一个根本没有业务逻辑的假登录框、一堆孤立的组件。每个功能单独看都有痕迹但拼在一起不像一个能用的产品。为什么因为这段提示词里没有任何一个信息能告诉AI用户是谁、场景是什么、什么东西应该最突出、什么东西应该被砍掉。AI面对十个同等权重的需求只能平均用力每个功能都给你做一点存在感但每个都做不到能解决真实问题的深度。这不是AI能力不行是你根本没给它判断优先级的依据。功能清单式的提示词本质上是把决策责任全推给了AI而AI在不知道上下文的时候只能用最平庸的方式完成你的列表。2. 为什么会写成功能清单三个藏在背后的深层原因2.1 思维惯性我们被需求文档驯化了很多写功能清单式提示词的人并不是不懂产品恰恰相反他们可能是受过正统训练的产品经理或开发。传统软件开发流程里PRD、需求清单、功能列表是标配你要做一个系统先列功能模块再拆子功能再写验收标准。这套方法论在人跟人协作的场景里非常好用因为需求文档本质上是写给人看的对方可以根据自己的经验去补全你在文档里没写出来的业务场景和边界情况。问题在于AI 不是传统意义上的人它没有你在行业里积累的那些默认认知。你写登录注册人脑里会自动补充我要手机号验证码登录、第三方登录、Token过期处理AI看到登录注册它只会按训练数据里最常见的登录页模式给你生成一个用户名密码记住我。你以为自己在复用过去的需求管理经验实际上是把一套给人的沟通格式硬套在给AI的沟通场景上沟通链路从源头就错位了。更麻烦的是这种清单式写法还有很强的交付感。我们把功能列出来心里就踏实了觉得我该交代的都交代了。但这种踏实感是虚假的——清单只描述了产品的截面没有描述产品的运动轨迹AI能看到的只是一排静态按钮而不是用户在产品里走完一段旅程的动态画面。2.2 工具误导对话框天生诱导一条条提需求第二个原因在工具本身。Cursor、Trae这些AI编程工具的交互都围绕对话框展开对话框的设计逻辑天然倾向于你来我往、一问一答的命令式交互。很多人的第一反应就是把需求拆成一百个小纸条一张张往对话框里塞先做登录再做列表再做表单再做弹窗……以为这是在可控迭代实际上是在让AI在碎片上下文里瞎猜。我见过更极端的反面案例有人连续给AI发了几十条消息前一条让AI做暗色主题后一条又让AI做一个完全不相关的导入Excel功能中间没有任何上下文衔接。AI当然可以记住同一个会话里的历史消息但你给的是两个没有因果关系、没有业务关联的功能点它只能机械地收到马上去改改完上一轮的结构也七零八落。这就是我一直强调的观点对话框是执行入口不是需求输入口。你不能指望靠一百条零零碎碎的消息拼出一栋完整的建筑AI确实可以把砖头一块块砌好但它不知道你应该建的是住宅楼还是商场更不知道该把电梯放在哪个位置。工具让你觉得随时能改很方便但这一代AI产品的质量上限恰恰取决于你能不能在开始之前把方向说清楚。2.3 认知误判以为信息越多AI越懂你还有一种心理很普遍我写背景、写目标、写用户AI能听懂吗算了太麻烦功能列得全一点AI总能生成个差不多能用的东西吧。结果一行接一行的功能堆上去你以为是在补充上下文实际上是在不断稀释产品主题。AI确实在处理信息但它处理的是意图密度而不是信息总量。什么叫意图密度就是同一段内容里有多少可以直接转化为产品决策的明确指令。比如做一个周报工具——意图密度为零AI不知道该从哪下手补充一句给一个十人敏捷团队每周末汇总进展——意图密度上来了AI知道核心场景是团队汇报再补一句需要有未提交提醒和投屏汇总——AI就知道核心流程了。相比之下你写支持PDF导出、支持日间夜间模式、支持富文本编辑器、支持自定义字段这四项加起来十四个字看着很有用AI拿到手还是不知道该把哪个放在第一位。所以信息越多越懂是一个认知陷阱。信息跟信息之间是有权重的当你的提示词里全是列表式功能点核心意图就被淹没了AI只能从所有信息里做平均注意力分配最后做出来的产品就像一盘没有主菜的自助餐什么都有一点什么都填不饱肚子。而且提示词的长度本身还受上下文窗口限制你把空间都用来陈列功能了真正重要的场景描述和约束条件的空间就被挤掉了。3. 功能清单式提示词是怎么一步步搞砸产品的3.1 功能齐全但逻辑断裂继续用前面那个团队协作工具的例子。AI拿到功能清单后会去生成一个侧边栏菜单菜单里每一项对应一个页面仪表盘、项目、任务、成员、消息、统计、文件、设置。看起来很完整吧但当你试图走一遍完整流程——我作为项目负责人登录系统后想看看这周哪些任务卡住了然后指派给某个成员并给他发条消息——你就会发现任务列表和成员列表之间没有联动指派功能只是个残缺的弹窗发消息的入口根本不存在。每个页面都能打开但页面之间是信息孤岛。这就是功能清单式提示词最典型的失败模式功能没有粘合关系。真实的产品功能是互相关联的A页面的数据要喂给B页面B页面的操作要触达C流程。你在清单里列数据统计图表AI就给你在页面里塞一个假的 ECharts 折线图但不会有任何一条真实业务数据流进这个图表因为上下文里根本没有业务数据是什么、从哪来、怎么流转的描述。功能是点产品是线没有线点永远是孤立的装饰。3.2 缺少决策上下文AI只能用平均力来补位产品设计的核心其实是取舍你决定一个功能要做得非常重就意味着另一些功能可以做得非常轻。真实产品里登录页面可能花掉了整个前期交互团队的80%时间因为登录转化率就是生命线而用户协议页只需要一个超链接。但你在功能清单里写用户注册登录和用户协议时这两个功能点的权重是一样的AI没有理由厚此薄彼于是它给这两个功能分配了差不多的注意力。你看到的结果就是登录页做得平庸用户协议页也做得平庸整款产品没有呼吸感。更麻烦的是AI在缺少决策上下文时会采取一种安全的平均主义——所有按钮都一样大所有页面都用同样的布局模板所有功能都套同样的组件风格。这样做出来的产品不能说错但完全没有性格。而产品的性格恰好来自你告诉AI的那句这是给谁用的、什么场景下用、希望用户有什么感受。决定一个产品成色的往往不是它有哪些功能而是同样功能下哪个产品更懂用户的处境。3.3 没有约束AI的自由发挥会变成技术债功能清单式提示词还有一个隐蔽问题它几乎不包含约束条件。你用 React 写还是用 Vue 写AI 问了才知道你的界面是中文还是英文AI 默认按训练数据里最常见的英文文案来你的数据要不要持久化、要不要后端AI 会自作主张用一个 localStorage 糊弄过去。不是AI不努力是你根本没有告诉它边界在哪里。约束缺失的结果就是AI 会在每次迭代时钻空子选择它自己认为最省事的实现路径而这条路径往往不是你想要的产品方向。这有点像你把一堆食材扔给一个厨子不告诉他是做中餐还是西餐、是家常菜还是宴席菜、口味偏清淡还是偏浓郁。厨子最后端出来的菜也许能吃但你入口的时候会发现它既不像中餐也不像西餐说不出来是哪个菜系。AI也是这样在无约束状态下它给每个功能都做了一层轻量实现看起来什么都沾一点实际上任何深入使用场景都会露馅。更麻烦的是这种隐性技术债会随着迭代越积越多等到你发现问题想重构时AI 已经在一个错误的底子上盖了十层楼拆都拆不动。4. 把提示词从功能清单改成产品叙事实操方法4.1 一条核心原则先讲为谁解决什么问题再讲功能正确的做法其实不复杂核心就是一句话把提示词从功能列表改写成产品叙事。所谓产品叙事就是你要先在一段话里讲清楚这个产品是给谁用的、在什么场景下用、用户进来以后经历的关键路径是什么、最终希望达成的效果是什么。功能点不是不写而是放到叙事之后作为支撑材料出现。具体来说我建议你在提示词里按这个顺序组织信息产品背景一句话→目标用户和使用场景一段话→核心体验流程一段话→关键功能三到五个点→明确不做的事→技术和视觉约束。很多人看到这里会问这也太啰嗦了吧我不能直接在对话框里让AI干活吗答案是能但你会花掉接下来几十轮对话去反复纠正AI的跑偏而这些纠正对话消耗的 token 和心力远比一开始多写100个字的成本高得多。花三分钟把上下文交代清楚换来的是AI从第一版开始就往正确方向走。4.2 套用这套结构提示词立刻变得能打我在这里给出一套完整的提示词模板你直接抄走就能用产品背景我是一个十人敏捷开发团队的负责人团队每周五需要向部门总监提交周报目前靠人工收集和二次整理耗时且容易遗漏。 目标用户团队成员是提交者我是汇总者部门总监是阅读者。 核心使用场景周五下午成员用三分钟填写本周完成/下周计划/阻塞问题三个字段并提交我用一个仪表盘看到所有成员的提交状态点击一个按钮系统按项目维度自动聚合内容生成一份可以投屏的周报视图。 关键功能 - 周报提交表单固定三个字段 - 提交状态仪表盘只显示未提交名单和提交进度 - 一键生成聚合周报视图按项目分组 明确不做不做移动端APP不做复杂权限系统不做历史数据统计分析不做话题社区。 技术约束Web端使用 Next.js Tailwind中文界面视觉风格参考 Linear 的简洁仪表盘风格。你不用每行都这么工整但核心信息必须覆盖到位。你会发现写这段提示词只比写功能清单多花了两分钟但AI生成的代码会完全不同——它会优先把三字段表单做顺手把仪表盘做清晰把一键生成周报做成主页面的核心动作设置页、用户协议这些无关紧要的东西它会按你明确不做的约束直接跳过而不是平均用力。4.3 试试让AI先反问绕开功能清单陷阱还有一个特别实用的小技巧我几乎每次都推荐给身边人在提示词最后加一句在开始之前先向我提出5个你还不够清楚的关键问题。这招的本质是把AI从执行者拽回共创者的位置。当你写的是一份功能清单AI可能默默吞掉所有含糊之处强行开始写代码但当你要求它先反问你它就必须倒逼你把场景说清楚。比如它可能会问团队成员和部门总监的权限边界是什么汇总周报时遇到同一个人负责多个项目内容该如何拆分是否有需要拦截的敏感词——这些问题恰恰就是你原来功能清单式提示词里缺失的信息。这个技巧还有一个额外好处它能帮你提前暴露自己没想清楚的地方。很多时候我们觉得自己已经懂了产品其实只是在脑海中有一个模糊的画面。AI的反问会像一面镜子让你不得不把模糊的画面抽象成清晰的文字这个过程本身就是一次极好的产品思考训练。5. 实操拆解一个周报工具从清单到叙事的完整改造5.1 改造三步法把现成清单变成产品叙事如果你手里已经有一堆功能清单式提示词没关系我教你一套三步改造法你花十分钟就能把所有旧提示词提升一个档次。第一步把所有功能点反问一遍用户在什么情况下需要它。比如消息通知→周五下午有成员没交周报我希望一键提醒他交。再比如数据统计图表→我想知道这周我们团队按时提交的比例好判断要不要优化周报流程。这一步做完你会发现很多功能其实可以被合并、被砍掉因为它们服务的场景根本没有区别。第二步找出一条最关键的用户路径然后让所有功能为这条路径服务。周报工具的路径就是成员填写→汇总→投屏其他一切功能都可以挂在这棵树上。比如权限管理其实是只有我负责人能看汇总结果PDF导出其实是投屏之外还需要一份附件给总监。挂不住树上的功能点果断摘掉。第三步补上明确的约束条件。技术栈、视觉风格、语言、明确不做的事都写进去。这一步相当于给AI划了一条施工红线它就不会再往错误方向自由发挥了。做完这三步你再把新版提示词丢给AI哪怕不在同一个会话里AI也能在更短的打磨轮数内产出接近你想要的产品形态。5.2 分阶段投喂不要在一条提示词里塞完所有东西很多人还有一个误区以为一篇好提示词写完之后就一次性地把所有东西都告诉AI。其实一个好的 vibe coding 会话应该像跟一个新手开发一样分阶段沟通第一轮只交代背景、用户、场景和核心路径让AI先搭出主干。第二轮确认代码结构和页面框架没问题后再逐步叠加细节功能。第三轮再去做视觉打磨和异常处理。举一个实际会话的例子。第一轮我只需要发上面的产品叙事模板等AI交出第一版代码我先过一遍流程能不能提交周报、仪表盘能不能正确显示进度、生成周报视图能不能按项目分组。这轮基座打牢了我才会在第二轮提给仪表盘加一个按个人维度的搜索框给周报视图加一个可折叠的阻塞问题列表这类增量需求。每一轮的增量需求我依然带一句上下文比如在现有周报聚合视图基础上增加……而不是孤零零地发一条加个搜索框。这么做的好处是AI始终能理解当前改动在整个产品里所处的位置代码的上下文一致性会好很多。你回头看看那些把100条零碎需求一股脑丢给AI的人他们花的打磨时间通常是这种分阶段投喂方式的三到五倍而且最终代码结构的混乱程度也高得多。5.3 全局文档是功能清单的最优归宿在 Cursor、Trae 这类工具里还有一个能帮你摆脱对话框碎片化上下文的神器项目全局说明文档比如 AGENTS.md。你可以把产品背景、技术栈、代码风格约束、用户场景、核心流程、明确不做的事都写在这个文档里然后让AI每次更改代码前先读一遍这个文档。全局文档和即时提示词的分工应该是前者存储长线、稳定的产品上下文后者传递当前这一轮的具体任务。这样你就再也不需要每轮对话都重复我们这是个十人团队的周报工具技术栈是 Next.js Tailwind这些信息在全局文档里已经写清楚了。我自己试过的最优做法是全局文档尽量短控制在几十行只写产品是什么、技术栈、目录约定、定义完成的验收标准其他的细节让AI去代码里自己看。太长的全局文档反而会稀释AI的注意力。Dify 这类低代码工具里编排提示词也是同一个道理把固定的系统提示词和变化的用户输入分开系统提示词管这个产品是谁、该怎么说话用户输入只管本次具体要做什么。这种全局文档分阶段投喂的组合是我目前认为最接近用 vibe coding 做正经产品的标准姿势。它没有多高深的技术含量但特别能解决实际工作中的上下文管理问题。6. 常见问题与排查技巧实录6.1 AI 总是把需求做成全家桶怎么办症状你只想做一个快速记笔记的工具AI却给你生成了一整套带日历、待办、目标管理、云同步的综合效率平台。原因其实很简单AI在训练数据里见到的笔记工具大多长这样它默认你以为的笔记工具就是市面上最流行的All-in-One产品。对策利用明确不做清单来反向框定。直接在提示词里写本项目是严格意义上的单页工具不做日历、不做待办、不做云同步不做任何主流程之外的功能。我试过这招对主流模型几乎都有效。如果AI还是手痒想加东西你就追问一句我明确说了不做这些你为什么仍然实现了——AI会自己解释并移除多余代码。逼着AI自己做减法比你去删代码高效得多。6.2 迭代几轮后代码越来越乱如何止损症状刚开始AI生成的代码还挺清爽几十轮迭代之后同一个页面上混入了三套相互矛盾的样式方案组件命名也乱了新功能怎么加都报错。这也是功能清单式沟通的慢性病——你在对话框里不断追加加一个xxx的小需求AI为了不破坏已有代码只能不断打补丁代码结构自然就腐化了。对策舍得推倒重来。一旦发现修修补补的成本已经超过了重新生成的成本就把当前项目的关键上下文全局文档最近一轮的实质改动整理好开一个新会话让AI基于这些上下文重新生成一遍整个项目不要延续旧代码里的损坏结构。这一步看着浪费实际上能省下后面几十轮的排查时间。我在实际项目里试过比较舒服的节奏每当新功能要大改数据结构或核心页面布局时就主动重构一轮AI 从干净的上下文里重写通常十分钟就能把旧代码优化成更合理的结构。6.3 提示词风格切换速查表维度功能清单式场景叙事式信息组织按功能模块横向罗列按用户旅程纵向展开决策依据我来列需求AI来执行我讲清场景AI来补充设计优先级所有功能平权主流程明确次要功能主动让位约束信息几乎不写明确写不做的事和技术边界迭代成本每轮都可能推翻重来增量改动可以稳定叠加最终效果功能堆砌边界模糊主路径顺畅产品气质统一这张表很直观地说明了问题功能清单式沟通的成本不在写提示词那两分钟而在后续无穷无尽的返工里场景叙事式沟通的成本在开始前多花两分钟但省下的是一次又一次的改了这版坏了那版。6.4 排查技巧定位跑偏到底来自提示词还是AI本身最后再说一个排查小技巧。当你发现AI产出的东西明显不对时先别急着改提示词用同样的提示词换一个模型或换一个工具再试一次。如果两个模型都跑偏到同一个方向说明问题大概率出在你的提示词里场景信息不充分或者约束条件有歧义如果只有某一个模型表现特别差说明可能只是模型本身的能力局限你可以换一个更强的模型或者用鹈鹕骑自行车这类针对性测试题先验证一下模型——能准确理解一只鹈鹕正骑着一辆自行车这种少见的、需要空间想象力的描述通常说明这个模型对自然语言的理解能力足以处理你的产品描述。我在实际项目里踩过几次坑之后越来越确信一件事vibe coding 的门槛从来不是会不会用工具而是会不会描述。同样是 Cursor有人能连续三个下午做出一个像样的产品原型有人折腾一周还在跟登录功能较劲区别往往不在编程水平而在最开始那几个字——你给AI的是功能清单还是一个完整的世界。最后分享一个我一直沿用的自查方法写完提示词之后把它从头到尾读一遍假装自己是一个完全不了解这个行业的程序员看看读完能不能在脑海里浮现出用户使用的画面浮现不出来就继续补充场景直到画面清晰为止。这条画面感标准比任何提示词技巧都朴素直接但真的管用。