企业官网建设流程全解析

很多人问我，前端到底应该怎么用 AI 才不算“浪费”——这里说的浪费，不是指没省时间，而是指明明一个高质量 Prompt 就能拿到 80 分答案，结果随口一句话只拿回一个 30 分的残次品，还得自己花半小时改。这一弹，我干脆把压箱底的东西翻出来，系统讲讲前端场景下的高质量 Prompt 怎么设计、怎么写，模板无偿分享，你复制过去改一改就能直接用。

这一弹适合这几类人：平时用 AI 写代码但总觉得“差点意思”的前端开发者；想给团队沉淀一套 AI 协作规范的组长；以及刚开始接触 AI 编程、想知道从哪里下手的新人。核心就一件事：把提示词从“碰运气”变成“有章法”。

先说明一点，这套方法论和具体模型无关。GPT、Claude、还有国内那几个大模型我都试过，同样的 Prompt 在不同模型上表现有差异，但“结构完整、约束清楚、上下文给够”这三个原则是通用的。你理解了底层逻辑，换什么模型都能写出可用的 Prompt。

1. 为什么前端人的 Prompt 总是不够用：四个真实痛点

先说个常见场景。很多人打开对话框就是一句：“帮我写一个弹窗组件。”模型确实会给你一个弹窗，但大概率是那种没有动画、不考虑无障碍、不处理键盘事件、样式和你的设计稿八竿子打不着的“通用弹窗”。你用不了，于是继续对话：“不对，要加关闭动画”“样式太丑了，改成圆角”……一来一回十几轮，最后拿到的还是一坨缝缝补补的代码。

这背后的第一个痛点，就是指令太模糊。你脑子里的弹窗可能有具体的长宽、圆角、阴影、动画曲线、关闭逻辑、遮罩层交互，但你没说，模型只能猜。它猜的方向是“平均意义上的弹窗”，而不是你项目里的弹窗。

第二个痛点是缺少技术边界。你的项目是 React 18 + TypeScript 严格模式 + Ant Design，组件库用 Element Plus 改的，CSS 方案是 Tailwind，这些信息不喂给它，它就按自己的偏好去写——可能给你写个 class 命名字符串，可能给你塞一个你没装过的依赖，甚至给你返回 Vue 2 的语法。不是模型不行，是它压根不知道你的语境。

第三个痛点是上下文投喂不足。这是个双刃剑。投喂太少，模型没有依据；把整个项目全塞进去，又超出上下文窗口，或者塞进去的全是无关文件，反而稀释了关键信息。我见过有人真的把 src 目录下几百个文件一股脑丢进去，然后问“帮我重构这个项目”，结果模型回复说“项目内容过多，我无法逐一分析”。这不是模型偷懒，是上下文管理策略本身就是错的。

第四个痛点是不知道 Prompt 还能写成长文本。多数人默认提示词是一两句话，实际上高质量的提示词完全可以写成一份几十行的结构化“需求文档”。把角色、任务、技术栈、验收标准、输入输出格式全部写清楚，模型输出的质量会有一个肉眼可见的跃升。

这四个痛点，本质上是同一个问题：你没有把脑子里隐性的需求，显性化为模型能理解的指令。而高质量 Prompt 要解决的，就是这件事。

2. 高质量前端 Prompt 的底层结构：五段式框架

我自己摸索了很久，最后固定下来一套五段式框架，不管写什么前端任务，我都往这五个维度上靠。

第一段是角色设定。让模型先“进入状态”。前端领域很宽，写业务组件、写基建工具、写性能优化方案，需要的专家路径完全不同。你直接让它“你是一个资深前端工程师”太泛，要更具体：“你是某大型中后台产品的前端负责人，做过复杂的表单系统、权限模型和数据可视化项目，熟悉 React 18、TypeScript、设计系统落地。”这段设定会显著影响模型后续的输出语气和方案倾向。

第二段是任务描述。写清楚要做什么，而且尽量带上验收标准。不要只说“给表格加筛选”，而是说“为订单列表增加一个筛选栏，支持按订单状态、时间范围和支付方式三个维度筛选，筛选后 URL 参数同步更新，刷新页面后筛选条件保持”。验收标准越明确，输出越能对齐你的预期。

第三段是技术约束。这是前端场景里最容易踩坑的地方，也是模板价值最大的一环。把框架、语言、UI 库、样式方案、构建工具、Node 版本、包管理器统统写出来。比如“React 18.2，TypeScript strict 模式，Ant Design 5，Tailwind CSS 3.4，Vite 5，pnpm，不要再引入额外的依赖”。最后那句“不再引入额外依赖”特别关键，能阻止模型给你塞一堆来路不明的包。

第四段是输入上下文。把和任务相关的代码贴进来。不是贴整个文件，而是贴关键片段。比如写一个表格组件，你要贴的是 Table 的 props 定义、接口返回的数据结构、UI 库当前版本提供的列配置方式。上下文给到“刚好够用”，效率最高。

第五段是输出格式。告诉模型你希望它以什么形式返回。前端场景下我常用这么几种：直接输出完整可运行的组件代码；只输出关键函数并附带使用说明；给出多个方案并用表格对比优劣；以 diff 形式给出修改建议。格式化要求越具体，越省去你二次处理的精力。

除了这五段，还有一个我觉得非常有用的加分项——负面约束清单，也就是“不要做什么”。举例：“不要使用原生 DOM API，不要用 any 类型，不要忽略边界情况，不要给非受控组件做受控改造，不要改动与本次需求无关的代码。”这个清单能过滤掉大量模型自以为“贴心”但实际是画蛇添足的行为。

2.1 一个对比实验：五段式 Prompt 到底强在哪里

口说无凭，我拿同一个需求——一个带搜索、选择、清空功能的下拉选择器——做了两轮对比。

第一轮的 Prompt 是普通人最常写的：“写一个可搜索的下拉选择器。”输出结果：能搜、能选，但是用了一堆原生方法，样式也是裸的，类型全是 any，还忽略了键盘导航。

第二轮的 Prompt 按五段式写：

角色：你是某中后台产品的前端负责人，熟悉 React 和 Ant Design，注重代码可维护性和无障碍体验。 任务：在现有项目中新增一个远程搜索的 Select 组件，支持输入关键字从接口获取选项、选择后回显 label、支持清空。验收标准：搜索有 300ms 防抖；选项为空时展示空状态；键盘上下键可导航，回车选中。 技术约束：React 18 + TypeScript strict 模式 + Ant Design 5 + Vite，组件库已有的 RemoteSelect 基础封装可直接扩展，不要新增额外依赖。不要使用 any 类型。不要修改其他文件。 输入上下文： 接口返回结构：{ code: number, data: { list: { id: string, name: string }[] } } 现有封装位于 src/components/RemoteSelect.tsx，内部已有 useDebounce 和 request 方法，可直接调用。 输出格式：返回完整的 RemoteSelect.tsx 代码，并用 3-5 行说明如何使用。如果涉及 Ant Design API，请指出你引用的版本对应关系。

第二轮输出的代码几乎可以直接落地：类型写全了，防抖已经有了，键盘导航通过内置组件实现，注释也只加在关键判断处。差别就是这么明显。不需要什么技巧，信息给到位了，模型自然不糊弄。

3. 无偿分享：7 套前端场景 Prompt 模板，拿去就能改

下面这 7 套模板，是我自己在日常开发里反复用过、调过、确认有效的。每一套的结构都不一样，因为场景不同，侧重点不同。你复制后，把方括号里的内容替换成你的真实信息就能用。

3.1 组件开发模板：严格按设计风格出码

你是一名资深前端工程师，擅长开发高质量、可维护的 React 组件。 任务：开发一个 [组件名] 组件，功能要求如下： - [功能点1，比如：支持受控与非受控两种模式] - [功能点2，比如：支持自定义渲染插槽 slot] - [边界情况：空数据、加载中、错误态如何处理] 技术栈：React [版本] + TypeScript [严格/babel] + UI库 [名称版本] + 样式方案 [CSS Modules/Tailwind/styled-components]。 不要新增任何第三方依赖。不要使用 any。所有对外 prop 必须定义清晰类型。事件回调必须有完整的参数类型。 组件风格要求：样式与现有项目一致，圆角使用 [具体值]，主色参考 [品牌色]，间距遵循 8px 栅格。 请优先复用项目内已有的 [基础组件名]，不要重复造轮子。 输出要求： 1. 完整的组件代码，内部逻辑与样式分离 2. 组件使用示例 3. 针对周期 useEffect、useMemo 依赖的简单说明 4. 列出你引用的 UI 库 API 及版本，避免使用已废弃的 API

这个模板最适合做业务组件。我实际用下来，它最值钱的是“复用已有基础组件”那一条——你不说，模型就会自己造一个风格完全不同的轮子；你说了，它至少会先搜一遍你的代码结构。

3.2 设计稿还原模板：从描述到像素级代码

你是一名像素级还原专家，擅长将设计稿描述转换为前端代码。 设计内容描述（我无法上传图片，以下面文字描述为准）： - 布局结构：[页面整体分几块，头部/侧边栏/内容区/底部，各区域大致比例] - 关键样式：[主色值、字体大小与字重、卡片圆角、阴影、间距、边框] - 交互状态：[hover 效果、focus 态、选中态、禁用态] - 响应式规则：[在 768px / 1024px / 1440px 断点如何变化] 技术栈：[如 Vue3 + Element Plus + scss]。 输出要求： 1. 完整组件或页面代码 2. 每个区块用注释标明对应的设计部分 3. 注明哪些样式用了变量，方便后续统一修改 4. 给出适配不同屏幕的具体断点实现 不要使用内联样式，不要写死宽度（除非设计稿本身要求固定宽度）。

关于设计稿这块多说一句：现在有些模型支持图片输入，但直接上传截图往往会有误差——颜色偏一点、间距差几个像素，肉眼看不出来，代码里却是明显的问题。我个人更推荐“截图 + 文字补充关键数值”的方式，给模型更确定的锚点。如果设计稿本身有标注版本，把标注图传上去，回准确率高非常多。

3.3 代码审查模板：比大多数人的 Reviewer 更严格

你是一位经验丰富的前端代码审查者，擅长发现 bug、性能隐患和可维护性问题。 请审查以下代码，文件路径：[文件路径]，所属模块：[模块描述]。 审查维度： 1. 正确性：有没有逻辑漏洞、边界情况未处理、异步竞态问题 2. 性能：不必要的渲染、重复请求、超大计算是否能优化 3. 可维护性：命名是否符合语义、函数是否过长、组件拆分是否合理 4. 规范一致性：是否符合项目内已有的 ESLint 规则和代码风格 5. 安全：有没有 dangerouslySetInnerHTML 滥用、XSS 风险点 代码： [粘贴代码] 输出格式： 按“严重问题 / 建议优化 / 可忽略”三级分类，每条给出：所在行号、问题描述、修复代码片段。不要泛泛而谈“代码质量良好”，必须给出具体的修改建议。

我每次写这个模板都会强调最后一句“不要泛泛而谈”，因为模型在拿不准的时候倾向于两边开腔，说一堆模棱两可的好话。你把“必须给具体修改建议”写死，它只能老老实实逐行看。

3.4 技术方案模板：让 AI 当你的架构参谋

角色：你是某中型前端团队的技术负责人，擅长做技术选型和架构设计。 背景：我们需要 [描述当前业务背景，如：把项目里散落的权限判断逻辑收敛到统一层]。 约束条件： - 现有技术栈：[列出现状] - 团队情况：[团队几人/平均技术水平/是否有专人维护基建] - 时间周期：[多久上线] - 兼容性要求：[支持浏览器版本/是否需要兼容老接口] 任务：请给出三套差异化方案，要求： 1. 方案 A：最稳妥、改动最小 2. 方案 B：长期收益最大、但初期成本高 3. 方案 C：折中策略 每套方案包含：核心思路、改造范围、工作量评估、风险点、回滚预案。 最后用表格对比三套方案的优劣势，并给出你的推荐和理由。

这个模板的好用之处，在于它把方案对比的逻辑固定下来了。模型不再是一个只会说“推荐方案 A”的复读机，而会沿着“风险、成本、收益”三个轴线给你完整的决策维度。作为技术评审会之前的预演材料，价值很高。

3.5 调试排错模板：把报错现场完整还原

我在 [项目名] 中遇到一个 bug，需要你帮我定位。 技术栈：[框架/版本/关键依赖]。 相关代码（关键片段）： [代码内容] 报错信息： [控制台完整错误，包括堆栈] 已经尝试过的方法： 1. [方法1，比如：已检查 props 传递，确认数据源正常] 2. [方法2，比如：已尝试去掉新加的依赖排查冲突] 请按照以下步骤帮我排查： 1. 先定位最可能导致问题的原因，按可能性排序 2. 针对每一个可能原因给出验证方法（添加什么日志、检查哪个变量） 3. 给出最终修复代码时，确保不改变现有接口和数据结构

排错类的 Prompt 有一个很容易忽略的要点：一定要写“已经尝试过的方法”。不然模型会把你引到你已经排除过的路线上反复打转。我试过很多次，只要把“已试过”写清楚，模型给出直接原因的概率明显增加。

3.6 老代码理解模板：让 AI 做文档活儿

你是一名具有极强代码阅读能力的前端工程师。 下面这段代码来自一个 [遗留老项目]，几乎没有文档和注释，需要你帮我分析清楚它的逻辑，以便接下来做重构。 代码： [粘贴完整函数或文件] 请按以下格式输出： 1. 这个文件/函数的核心职责是什么 2. 主要数据流和状态变化过程 3. 有哪些隐式约定（比如依赖组件外的全局变量、与后端的暗号字段等） 4. 如果重构，你认为关键改动点有哪些，风险最大的部分是什么 5. 用 200 字以内给一个重构建议

理解别人写的烂代码，是每个前端最头疼的事。这个 Prompt 帮我省过很多时间。它输出的“隐式约定”那一项尤其有用——经常能挖出一些连原作者都忘了的非显性逻辑。

3.7 测试用例生成模板：覆盖面比人想得多

你是一名前端测试工程师，擅长编写覆盖全面、可读性高的单测用例。 请为以下组件/函数编写测试用例： 代码： [粘贴] 测试框架：[Jest/Vitest + Testing Library]。 要求： 1. 覆盖正常渲染、用户交互、边界输入、异常情况 2. 每个用例描述清楚“验证什么” 3. 不要写无效断言（比如只断言组件存在、不检查实际行为） 4. 异步逻辑请使用真实模拟，不要跳过执行 5. 每个用例给出对应测试代码

测试用例模板是很多人忽略的高价值场景。一个认真设计过的 Prompt 生成的用例，覆盖面通常比自己手写的还要全，因为模型不会犯“顺着实现细节走”的路径依赖，它更倾向于从行为层面去推导测试点。

4. 拿到模板之后：三个决定命中率的使用细节

模板只是开始，同样的模板，不同的人用，效果差距可以很大。下面这三个细节我踩过很多次坑才摸出来，写下来供你参考。

细节一：上下文投喂要“精准且限量”。不要一股脑全塞进去，也不要完全不塞。我现在的标准是：和任务强相关的代码片段 + 类型定义 + 接口返回结构，总行数控制在 100-200 行内。超出这个量，模型容易抓不住重点；低于这个量，信息不够它发挥。你可以在 Prompt 里用“关键代码片段”这个说法来要求自己，逼自己只挑最有信息量的部分贴进去。

细节二：第一版不满意，别发“代码不对”这种模糊反馈。模型没有读心术，你得说清楚哪里不对。比如“弹窗的关闭动画没有执行”“列表在空数据时没有显示空状态”“这个组件的样式没有走设计系统变量，全写死了”。我一般会给它三个维度：逻辑行为、视觉表现、代码规范，指出具体的偏差，再要求它在改的同时保持原有结构和风格不变。这样第二版通常就能接近可用。

细节三：关于“幻觉”的预防。前端场景里模型最常见的幻觉是编出某个 UI 库根本没提供的新版本 API，或者把某个 hook 的用法说错。应对方法：一是在 Prompt 里明确要求“如果引用第三方库的 API，请标注版本号或来源”，逼它不要含糊；二是涉及内部封装组件时，必须把封装源码贴给它，不让它自由发挥。我还会在关键代码跑起来之前，先搜一下它提到的 API 是否真实存在，这套“事中检测”流程能挡住绝大多数幻觉。

4.1 高频翻车场景对照表

这张表我建议你截下来。每次感觉模型给的代码“不太对劲”，就对照一下——大概率是某一列缺了某样东西。

5. 关于这件事我的真实体会和后续计划

写这批 Prompt，其实是一个月前临时起意的。当时我在某个技术社区看到提问：“为什么我让 AI 写的代码总是没法用？”下面回答一大串，但基本都在分析模型的毛病。我当时就觉得，问题不在模型，在提问方式。于是花了几天时间，把自己一年来用过的高质量 Prompt 全部整理了一遍，按场景分好类，测试确认可用后做了第一弹分享。反响超出预期，所以有了这一弹前端专场。

无偿分享这件事，我没什么复杂的动机。前端这个行业，学习成本和信息差一直都不小。很多好东西不是不存在，而是散落在少数人的“工作流”里，新入行的人根本不知道。我当年也是靠各路博客和开源项目摸爬滚打出来的，现在把能总结的东西总结出来，能帮到几个算几个。

最后再分享一个小技巧：与其每次都把整套 Prompt 打一遍，不如把你团队的固定约束写成一份说明文档，比如放在项目根目录的 AI_CONTEXT.md，里面写清楚技术栈版本、目录结构、组件风格、常用封装、代码规范，然后每次开场先丢给它一句“请先阅读项目说明再回答问题”。这比任何单条 Prompt 都管用，能直接把你和 AI 的协作稳定提升一个等级。

这次先分享到这。如果你手上有自己打磨过、反复实验过确实好用的前端 Prompt，欢迎在评论区贴出来，我整理进下一弹。互相抄作业，是这行进步最快的办法。