★ FEATURED ARTICLE 做功能开发的时候我见过太多人把 Cursor 当成一个“高级命令行”扔一句“帮我写个待办事项应用”然后对着生成的半成品叹气觉得 AI 不行。这其实不是 AI 的问题问题几乎都出在提示词上。你给到的信息密度太低AI 的想象空间就大而 AI 替你做的“产品决策”十个里有八个都不是你想要的。这一篇不聊虚的直接拿Cursor 提示词里最常用的“功能使用提示词”开刀用开发一个待办事项应用的真实场景把提示词从一句话怎么一步步写到能直接用以及这些方法怎么迁移到表单、列表、搜索页等其他功能场景一次讲透。1. 功能提示词为什么总是“差点意思”先搞懂你在跟谁说话你面对的不是一个会读心术的结对程序员而是一个知识渊博但完全不了解你项目上下文的高效实习生。你嘴里说的“做个待办应用”在他脑袋里会拆解成“随便一个带增删改查的 CRUD 页面”然后给你铺开一千种实现可能。1.1 提示词不是命令是一份“低完整度需求说明书”大多数人写功能提示词习惯是写祈使句“做一个待办事项应用”“给购物车加个结算功能”“写个登录页”。这本质上是在给人下命令——人能靠默契和常识脑补大量背景但 AI 没有你的项目背景。它唯一的依据就是你屏幕上的字。我用一个更生活化的类比这跟你去饭店说“来一桌菜”是一个道理。厨师确实给你上菜了但上的大概率不是你心里的菜。你只有说清楚“红烧、少辣、要鱼、四个人吃、不要香菜”后厨才可能做出接近预期的东西。功能提示词就是你给 AI 后厨写的食材清单和烹饪要求。所以写功能提示词的第一性原理是把自己从“安排任务的老板”切换成“产出需求的产品经理”。你的工作不是告诉 AI “写代码”而是告诉 AI “你要什么不要什么用户怎么操作系统怎么反应”。1.2 一次完整的功能描述必须覆盖五个维度我在实际使用中总结过任何功能场景的提示词只要你想一次性拿到可用的代码至少要覆盖下面五个维度。漏掉任何一个后面都等着返工。维度要回答的问题作用功能范围这个功能具体要做哪几件事不做什么控制 AI 的想象边界防止加戏数据模型涉及哪些数据字段类型是什么有没有关联决定数据库设计和状态管理的骨架交互流程用户从上一步到这一步怎么操作操作后看到什么决定组件结构和事件逻辑边界情况空数据、重复提交、超长文本、异常状态怎么处理避免跑起来就崩的“玩具代码”技术约束用什么技术栈有没有现成 UI 库样式风格如何保证代码能直接接进现有项目而不是孤岛一句话提示词之所以总是产出半成品就是因为它只沾了“功能范围”的边剩下的四个维度全靠 AI 掷骰子。下面我拿待办事项应用把你从头到尾演示一遍从一句话到五维俱全的迭代过程。2. 从“一句话命令”到“完整需求”待办事项应用的提示词五段进化2.1 v0一句话版本能产出什么先照你标题里的场景试试这句话帮我写一个待办事项应用支持添加任务、标记完成、删除任务。这一版提示词比“做一个待办应用”好一点因为它枚举了三个功能点。我实测下来Cursor 确实会给你一个能跑的 Todo 应用页面也能出来基本的三个交互也有。但你会发现很多别扭的地方没有数据持久化刷新就丢任务表单布局随机没有空状态提示删除没有二次确认标记完成之后没有视觉反馈的过渡更别提什么编辑任务、优先级、截止日期这些你“没说要但默认应该有”的东西。问题不在于 AI 偷懒而在于**“待办事项”这四个字背后是人脑里一套非常复杂的默认预期**这套预期在你脑子里跑了十几年但 AI 只能看到你屏幕上的二十几个字。2.2 v1给功能清单这时候代码开始可用了接着往下补。第一件事是把“三个功能点”扩写成真正的功能清单同时强调默认状态。开发一个待办事项应用。功能需求如下 1. 添加任务输入框输入内容按回车或点击“添加”按钮生成新任务。 2. 任务列表展示所有任务未完成任务显示在列表上方已完成任务置灰并显示完成时间。 3. 标记完成/取消完成点击任务前的复选框切换完成状态。 4. 删除任务每条任务右侧放删除按钮点击后从列表移除不需要二次确认。 5. 任务统计列表顶部显示“X 项待办”。 6. 数据持久化使用 localStorage 保存任务刷新页面后数据不丢失。 7. 空状态当没有任何任务时显示“暂无待办任务”。这一版提示词的信息量比第一版大了一个量级。原因在于他不再让你去猜“待办应用该长什么样”而是替我给界面、交互、边界空状态、刷新持久化下了具体定义。Cursor 这时候交出来的东西已经像是一个认真做完了基础需求的版本而不是 demo。2.3 v2加数据结构和交互细节代码开始符合工程规范功能清单解决“做不做”的问题但还没解决“怎么做才顺”的问题。比如任务内容超长了怎么办任务字段里只有文本吗需不需要创建时间于是第三版提示词就要往下钉数据模型和交互细节继续完善上面的待办事项应用。补充以下要求 - 任务的数据结构为 { id: string, text: string, completed: boolean, createdAt: string, completedAt?: string | null }。 - 新任务添加后输入框自动清空并重新聚焦。 - 任务文本用文本框展示超长部分用省略号截断鼠标悬停显示完整内容。 - 标记完成时记录 completedAt 时间取消完成时清空该字段。 - 列表为空时展示空状态插画而不是纯文本。 - 所有状态变更添加、完成、删除后页面不要刷新用响应式更新。你会发现这一版提的已经不是“功能”而是行为契约。它规定字段、状态、反馈、交互时序。Cursor 拿到这种提示词之后生成的代码里数据层和视图层的结构都会规整很多因为它终于知道自己操作的数据长什么样了。2.4 v3加技术约束和 UI 倾向代码可以直接落进项目最后一步是把环境约束和样式偏好塞进来采用 Vue 3 TypeScript 实现使用 Composition API 写法样式用 Tailwind CSS不需要引入 UI 组件库。页面整体窄屏居中宽度最大 480px背景浅灰卡片白底圆角。交互风格保持克制不要动画不要装饰性元素。这里的技术约束非常关键。如果你不指定技术栈Cursor 很可能默认给你 React但你公司项目用的是 Vue于是你拿到一段完美的、没有用的 React 代码。工具最强的地方恰恰是它什么都会而提示词的目的就是把它“什么都会”收敛成“恰好会你要的那一个”。五版迭代完之后你会发现从 v0 到 v3 的差别本质上不是“字数变多了”而是决策权发生了转移。原来那些由 AI 拍脑袋做的决定——数据持久化用什么、任务结构有哪些字段、界面长什么样、要不要动效——全部被你接管。AI 的职责从“设计者”降格成了“执行者”这恰恰是它最擅长、也最不容易出错的位置。3. 把待办应用的写法抽成模板“功能提示词六槽位”可以复用到任何场景待办事项的这套方法回头就能抽出通用骨架。我自己用的“功能提示词六槽位”模板是这样的【功能名称】一句话概括功能。 【用户角色】谁在用在什么情境下用。 【数据描述】输入什么用哪些字段数据从哪来存到哪去。 【交互流程】从进入页面到完成目标每一步用户看到什么、能点什么。 【边界情况】空数据、超长内容、重复操作、失败重试怎么处理。 【技术约束】技术栈、组件库、样式方案、禁止做的事。六个槽位不是每次都要填满而是根据场景决定侧重。下面我拿三类最常碰到的功能场景做对照看看它们各自押注在哪些槽位。3.1 场景 A数据表单类功能比如“新增客户”表单类功能的核心是字段校验、提交流程和错误反馈。数据描述和边界情况这两个槽位最重要。开发一个“新增客户”表单功能 - 用户角色销售在客户详情页点击“新增客户”打开抽屉表单。 - 数据描述表单字段为客户名称必填、手机号11位校验格式、客户等级下拉A/B/C、备注最多200字。提交 POST /api/customers保存成功后关闭抽屉并刷新列表。 - 边界情况手机号格式不正确时在输入框下方显示红色提示不阻止提交提交按钮点击后防重复提交loading 期间禁用按钮接口报错时保留用户已填数据并在抽屉底部显示错误提示。 - 技术约束Vue 3 Element Plus表单校验用 Form Rules。推荐提示词的哲学是替 AI 把“哪些情况算错、错了怎么办”定义清楚。大部分表单功能翻车翻的不是主流程而是校验分支和接口失败后的用户体验。你把这些写进提示词里AI 生成的表单才会像一个能上生产环境的表单。3.2 场景 B列表筛选类功能比如“订单查询”列表页的核心是筛选条件、排序、分页和空结果。交互流程和技术约束是重头。开发一个订单查询列表功能 - 功能范围支持按订单号模糊搜索、按下单时间范围筛选、按订单状态待支付/已支付/已完成/已取消筛选。 - 交互流程筛选条件变化后自动触发列表刷新不用点击查询按钮列表展示字段为订单号、金额、下单时间、状态状态用不同颜色标签展示列表底部有分页每页10条显示总条数。 - 边界情况筛选无结果时表格区域显示“未找到匹配订单”的空状态仍保留筛选条件便于修改搜索框输入内容为空时不触发搜索重置为展示全部订单。 - 技术约束使用 Ant Design 表格组件筛选区用 Form 的 inline 布局接口调用用封装的 request 函数。这个场景你要特别强调“条件变化后自动触发列表刷新”和“空结果保留筛选条件”这是列表页交互里最容易被 AI 默认实现成“点击按钮才刷新”和“空结果直接清空条件”的地方。不写清楚十个 AI 有八个会给你做出一个反人类的查询页。3.3 场景 C信息展示类功能比如“数据看板”看板类的重点不是交互而是数据怎么聚合、图表怎么编排、加载状态怎么处理。用户角色和数据描述很重要。开发一个数据看板页面 - 用户角色运营人员登录后打开首页即看到汇总数据。 - 功能范围展示核心指标卡片今日新增用户、今日订单数、今日销售额、转化率下方展示近30天订单趋势线图。 - 数据描述调用 GET /api/dashboard/summary 返回 { 今日新增用户, 今日订单数, 今日销售额, 转化率 }调用 GET /api/dashboard/trend?days30 返回每日 { 日期, 订单数, 销售额 } 数组。 - 边界情况数据加载中显示骨架屏接口失败时显示可点击重试的错误状态不允许出现白屏。 - 技术约束图表用 ECharts四个指标卡片用 Grid 布局适配移动端两列展示。展示型页面最怕的就是“接口数据没回来页面已经渲染了一个空结构”然后闪现一堆 0 或 undefined。所以边界情况这个槽位在展示类提示词里直接决定了页面观感是 90 分还是 40 分。4. 功能提示词不必一步到位在对话里“追加约束”是更省力的姿势很多人有个误解觉得好提示词必须一上来就写得面面俱到写不完就焦虑。但你用 Cursor 的时候要想清楚一件事它天生是对话式的你可以看到代码结果之后再提要求这比写超长提示词更接近真实开发节奏。4.1 第一轮提示词的“最小有用长度”怎么判断你可以先只写功能范围和技术约束把代码跑起来然后逐轮追加数据和交互要求。比如待办应用的第一轮可以先这样用 React TypeScript 写一个待办事项应用功能包括添加任务、标记完成、删除任务。然后看到代码后逐步追加“任务数据用 localStorage 保存”“任务列表为空时显示空状态”“给删除按钮加个确认弹窗”。这种方式的好处是每一步都在真实代码上做增量变化改动可控行为可预测。对话式迭代要遵循一个原则一次对话只围绕一条主线追加需求。这条主线可以是数据持久化也可以是交互优化但不要混着来。你如果又加持久化又加拖拽排序又改样式AI 很容易在一个文件里改出互相冲突的逻辑。4.2 后续轮次的三种常用句式补充、修正、约束我在多轮对话中实际用得最频繁的句式就这么几句补充在现有基础上增加一个功能任务支持编辑双击任务文本进入编辑状态回车保存Esc 取消。修正当前删除任务后列表没有重新排序请改成删除后更新列表状态保持未完成任务在前。约束所有新增代码不要修改现有样式文件只调整当前组件的内联样式。你会发现后两种句式非常关键。修正句式的价值在于你明确指出“哪里不对”而不是让 AI 自己找 bug否则它很可能为了修一个小问题把整块逻辑重写一遍。约束句式的价值在于划定修改边界防止 AI 越界改动你本来满意的代码。4.3 多轮对话里最容易踩的交互陷阱需求漂移追加了几轮之后你会遇到一种诡异的情况AI 开始把第 2 轮的需求和第 5 轮的需求搅在一起要么实现互相矛盾要么在一个需求上出现两套并存的逻辑。这是上下文窗口被撑满后常见的“需求漂移”。我的对策很朴素一个功能闭环换一个新会话去写。待办应用就用一个会话、一个提示词主线写完不要在这个会话里顺手让它“再加个番茄钟”“再做个数据统计”。跨功能的需求宁可新开会话把已有代码结构贴给它也别在同一会话里无限追加。不然你最后一定会花大量时间在“纠正 AI 对前面需求的错误记忆”上。5. 我在功能提示词上踩过的四个坑以及对应的排查链路最后这部分是把我在真实项目里反复踩过、后来总结出规律的坑直接摆出来。每一个都对应一个可复现的排查思路希望你能绕过。5.1 坑一不写边界情况功能跑通但一用就崩做待办应用时第一版提示词里我没有写“任务内容为空时点击添加会怎样”。结果 AI 生成的任务列表允许添加空字符串任务页面渲染出一个长得像空隙的“任务”用户不知道发生了什么甚至无法定位删除按钮。排查链路是这样的先看事件处理函数里有没有对 input 值的 trim 和空值判断再看任务渲染的 key 和数据校验逻辑。但根本的解法不在代码里而在需求里——提示词里补一句“任务内容去除首尾空格为空时点击添加按钮给出轻提示且不生成任务”这段代码就不会出现。5.2 坑二只给功能不给数据模型AI 全靠猜给 Cursor 说“做一个客户管理功能能添加客户、编辑客户、查看列表”它生成的代码大概率把客户定义成一个只有 name 和 phone 的对象。等你接真实接口的时候发现要传 id、level、remark、createdAt这时候再让 AI 改数据结构等于让它在半成品废墟上打补丁改一处漏三处。排查链路很简单看它生成的类型定义里字段是不是够用不够就直接说“数据模型按这个结构来”并附上你的字段和类型。数据模型是 AI 生成代码的地基地基必须在第一轮就定死。5.3 坑三需求追加速度太快代码结构越改越乱这是对话式使用最经典的坑。第 2 轮说“删除任务时加个确认”第 3 轮又说“取消确认框时任务要闪烁一下”第 4 轮再说“闪烁效果用 CSS 动画实现”。每轮新需求AI 就往上叠代码等到第 5 轮你回头一看原来干净的删除逻辑里已经塞了状态管理、动画计时器、事件冒泡控制乱成一团。我的排查链路是一旦发现同一个函数里塞了三个以上的独立关注点立刻叫停。把这段逻辑描述清楚告诉 AI “重构 ListItem 的删除处理将确认弹窗和动画效果拆成独立函数主流程保持单一职责”。与其让 AI 在叠罗汉上继续叠不如花一轮让它把代码重新理顺。这个投入非常值。5.4 坑四没有在提示词里声明“不要做什么”功能提示词不能只写“要什么”还要明确“不要什么”。最典型的例子是我让它做一个登录页它自动引入了一个表单库但项目里已经有自己的表单封装。AI 常常会基于它熟悉的模式去选型而不是基于你项目的存量。解法是在技术约束槽位里直接写不要引入任何第三方表单库使用项目现有的 Form 组件新写代码不要改动现有 API 请求封装不使用任何未在 package.json 中声明的依赖。这类“负面约束”能省掉你大量清理依赖和删无用代码的时间。实测下来这些“不要”写进去比只写“要用什么”效果更直接。6. 最后一件事把好的功能提示词当成项目资产来沉淀功能提示词写得好不好短期看产出长期看复用。我个人现在的习惯是每完成一个成型的提示词就单独存一个 markdown 文件按“场景 功能名”命名比如表单场景-新增客户.md、列表场景-订单查询.md。下次再遇到类似功能先把旧提示词拿出来改改字段和数据模型十分钟就能出一个高质量初稿。这也是我为什么花了这么大力气去讲“六槽位模板”因为模板真正的作用不是让某一次对话变得更准而是它把个人能力沉淀成了可复用的结构。你积累的提示词越多Cursor 的使用体验就越接近“带了一个真正懂你项目的资深开发”。后者会把你的偏好、你项目的边界、你讨厌的写法都记在心里而提示词就是你给它建立的“长期记忆”。
阅读完成 · 觉得有帮助？
