企业官网建设流程全解析

做功能开发的时候，我见过太多人把 Cursor 当成一个“高级命令行”：扔一句“帮我写个待办事项应用”，然后对着生成的半成品叹气，觉得 AI 不行。这其实不是 AI 的问题，问题几乎都出在提示词上。你给到的信息密度太低，AI 的想象空间就大，而 AI 替你做的“产品决策”，十个里有八个都不是你想要的。

这一篇不聊虚的，直接拿Cursor 提示词里最常用的“功能使用提示词”开刀，用开发一个待办事项应用的真实场景，把提示词从一句话怎么一步步写到能直接用，以及这些方法怎么迁移到表单、列表、搜索页等其他功能场景，一次讲透。

1. 功能提示词为什么总是“差点意思”：先搞懂你在跟谁说话

你面对的不是一个会读心术的结对程序员，而是一个知识渊博但完全不了解你项目上下文的高效实习生。你嘴里说的“做个待办应用”，在他脑袋里会拆解成“随便一个带增删改查的 CRUD 页面”，然后给你铺开一千种实现可能。

1.1 提示词不是命令，是一份“低完整度需求说明书”

大多数人写功能提示词，习惯是写祈使句：“做一个待办事项应用”“给购物车加个结算功能”“写个登录页”。这本质上是在给人下命令——人能靠默契和常识脑补大量背景，但 AI 没有你的项目背景。它唯一的依据就是你屏幕上的字。

我用一个更生活化的类比：这跟你去饭店说“来一桌菜”是一个道理。厨师确实给你上菜了，但上的大概率不是你心里的菜。你只有说清楚“红烧、少辣、要鱼、四个人吃、不要香菜”，后厨才可能做出接近预期的东西。功能提示词就是你给 AI 后厨写的食材清单和烹饪要求。

所以写功能提示词的第一性原理是：把自己从“安排任务的老板”切换成“产出需求的产品经理”。你的工作不是告诉 AI “写代码”，而是告诉 AI “你要什么，不要什么，用户怎么操作，系统怎么反应”。

1.2 一次完整的功能描述，必须覆盖五个维度

我在实际使用中总结过，任何功能场景的提示词，只要你想一次性拿到可用的代码，至少要覆盖下面五个维度。漏掉任何一个，后面都等着返工。

一句话提示词之所以总是产出半成品，就是因为它只沾了“功能范围”的边，剩下的四个维度全靠 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?days=30 返回每日 { 日期, 订单数, 销售额 } 数组。 - 边界情况：数据加载中显示骨架屏；接口失败时显示可点击重试的错误状态，不允许出现白屏。 - 技术约束：图表用 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 的使用体验就越接近“带了一个真正懂你项目的资深开发”。后者会把你的偏好、你项目的边界、你讨厌的写法都记在心里，而提示词就是你给它建立的“长期记忆”。