Vibe Coding提示词：功能清单是坑，产品叙事才是王道

上周有个朋友兴冲冲给我看他用 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 提示词风格切换速查表

这张表很直观地说明了问题：功能清单式沟通的成本不在写提示词那两分钟，而在后续无穷无尽的返工里；场景叙事式沟通的成本在开始前多花两分钟，但省下的是一次又一次的"改了这版坏了那版"。

6.4 排查技巧：定位"跑偏"到底来自提示词还是AI本身

最后再说一个排查小技巧。当你发现AI产出的东西明显不对时，先别急着改提示词，用同样的提示词换一个模型或换一个工具再试一次。如果两个模型都跑偏到同一个方向，说明问题大概率出在你的提示词里，场景信息不充分，或者约束条件有歧义；如果只有某一个模型表现特别差，说明可能只是模型本身的能力局限，你可以换一个更强的模型，或者用"鹈鹕骑自行车"这类针对性测试题先验证一下模型——能准确理解"一只鹈鹕正骑着一辆自行车"这种少见的、需要空间想象力的描述，通常说明这个模型对自然语言的理解能力足以处理你的产品描述。

我在实际项目里踩过几次坑之后，越来越确信一件事：vibe coding 的门槛从来不是"会不会用工具"，而是"会不会描述"。同样是 Cursor，有人能连续三个下午做出一个像样的产品原型，有人折腾一周还在跟登录功能较劲，区别往往不在编程水平，而在最开始那几个字——你给AI的是功能清单，还是一个完整的世界。

最后分享一个我一直沿用的自查方法：写完提示词之后，把它从头到尾读一遍，假装自己是一个完全不了解这个行业的程序员，看看读完能不能在脑海里浮现出用户使用的画面，浮现不出来，就继续补充场景，直到画面清晰为止。这条"画面感"标准，比任何提示词技巧都朴素直接，但真的管用。