企业官网建设流程全解析

1. 一次“翻车”引出的前端改造思路

定价卡片这个东西，做过 SaaS 落地页或者工具类产品官网的朋友都不陌生。三列并排、中间那列高亮、顶部挂个“最受欢迎”的角标、下面列一堆功能勾选项、底部一个大按钮——这套结构几乎是行业标配。我手上正好有个小项目要重做定价区，原本打算自己手写，后来想着试试用 Cursor 配合 StageWise 的分阶段提示思路，再叠加一层主动提示词，看看能不能把这种“模板感极强”的模块做出点新意。

结果第一轮跑完，AI 给我的东西确实让我愣了一下——卡片边框变成了渐变色描边，按钮加了呼吸光晕，价格数字用了描边字体，连勾选图标都换成了带旋转动画的星星。用我同事的话说，“花里胡哨”。但冷静下来看，这轮“翻车”其实非常有价值：它暴露了主动提示词在 UI 生成场景里的一个核心矛盾——你给 AI 的自由度越大，它越倾向于堆视觉特效；而定价卡片这种承载转化任务的组件，恰恰最怕视觉噪音盖过信息层级。

所以这篇东西不是教你“怎么让 AI 帮你写定价卡片”这么简单。我想把这次实测的完整链路拆开：Cursor 负责什么、StageWise 的分阶段思路怎么落地、主动提示词到底该怎么写才不跑偏，以及最关键的——当 AI 输出“花里胡哨”的结果时，怎么把它拉回到可用的工程轨道上。适合正在用 AI 辅助前端开发、或者对提示词工程有兴趣但还没找到系统方法的朋友。哪怕你用的是别的编辑器、别的模型，这套思路也能直接迁移。

2. 三个工具各自扮演什么角色

2.1 Cursor 不只是“会补全的编辑器”

很多人对 Cursor 的理解还停留在“VS Code 加了个 AI 补全”，这其实低估它了。在这次定价卡片改造里，我主要用到它三个能力：多文件上下文感知、内联指令编辑、对话式重构。

多文件上下文这点很关键。定价卡片不是一个孤立组件，它依赖设计令牌（颜色、间距、圆角）、依赖按钮组件、依赖图标库。如果 AI 只能看到当前文件，它生成的样式大概率会和项目里其他部分打架。Cursor 的索引机制能把相关文件一起喂给模型，这样它改出来的东西至少变量名是对的、引入路径是通的。

内联指令编辑（就是选中一段代码按快捷键直接下指令）适合做局部微调。比如我觉得某个卡片的阴影太重，选中那一行box-shadow，直接说“改成更轻的层级阴影，参考项目里 card 组件的变量”，它就能在保持上下文的前提下改掉，不用我手动去翻设计令牌文件。

对话式重构则适合处理“结构级”的改动。比如我想把原来写死的三列布局改成基于 CSS Grid 的自适应结构，这种改动涉及 HTML 结构和 CSS 两处，用对话模式让它一次性处理比手动改要稳。

2.2 StageWise 的核心是“别让 AI 一口吃成胖子”

StageWise 这个名字听起来像某个具体工具，但在我这次实践里，它更多是一种分阶段推进的方法论——把一个复杂的 UI 改造任务拆成若干个有明确验收标准的阶段，每个阶段只让 AI 做一件事，做完验证再进下一阶段。

为什么需要这个？因为定价卡片涉及的东西太多了：布局结构、视觉层级、交互状态、响应式断点、无障碍属性。如果你一次性把这些需求全丢给 AI，它会在生成过程中“顾此失彼”——比如为了做出好看的渐变，把对比度拉到不达标；为了加动画，把prefers-reduced-motion的适配忘了。

我这次把整个改造拆成了四个阶段：

每个阶段单独给 AI 下指令，完成一个再进下一个。这样做的好处是，当某个阶段出问题时，你能快速定位是哪一层出了偏差，而不是面对一坨“什么都改了但又说不清哪里不对”的代码。

2.3 主动提示词：从“等 AI 猜”到“带 AI 走”

主动提示词是我这次感受最深的一环。所谓“主动”，是指你在提示词里主动预设约束条件、主动给出反面示例、主动定义验收标准，而不是只描述你想要什么。

举个例子。被动提示词是：“帮我做一个好看的定价卡片。”主动提示词是：“帮我做一个定价卡片，要求：信息层级从价格到功能列表到按钮依次递减；中间列用边框和轻微背景色区分，不要用大面积渐变；按钮 hover 时只改变背景色深浅，不要加位移或缩放；所有颜色必须从项目已有的设计令牌里取，不要自己造新颜色。”

看出区别了吗？被动提示词把“好看”这个主观判断交给了 AI，而 AI 对“好看”的理解往往偏向视觉刺激强的方案——渐变、发光、动画。主动提示词则把“好看”翻译成了可执行、可验证的具体约束，AI 的自由度被限制在合理范围内，输出自然更可控。

3. 主动提示词的写法拆解

3.1 约束前置：把“不要什么”说在前面

大多数人写提示词的习惯是先说想要什么，最后才补一句“不要怎样”。但在 UI 生成场景里，负面约束应该前置。原因是模型在生成时是按顺序处理的，先给出的约束会作为“硬边界”影响后续所有决策。

我这次的实际写法是这样的：

你是一个前端开发助手。在生成定价卡片时，请遵守以下硬性约束： 1. 不使用任何渐变色作为大面积背景 2. 不使用发光、阴影扩散超过 8px 的效果 3. 不使用位移动画（translate）作为 hover 反馈 4. 所有颜色值必须引用项目 tokens 文件中的变量 5. 字体大小不超过 4 个层级 在此基础上，帮我实现一个三列定价卡片布局……

把“不要什么”放在最前面，相当于给 AI 画了一个圈，它后面所有的创意发挥都只能在这个圈里进行。实测下来，这样生成的代码返工率明显更低。

3.2 给参照物：用“像什么”代替“要什么”

“要什么”很难描述清楚，但“像什么”很容易。我在第二阶段调整视觉层级时，提示词里加了一句：“中间高亮列的视觉处理参考 Stripe 定价页的做法——用细边框加轻微背景色差，而不是用放大或强阴影。”

给参照物的好处是，AI 能从一个具体的、它训练数据里见过的案例中提取风格特征，比抽象描述“要高级感”有效得多。当然，参照物不一定是某个具体产品，也可以是项目里已有的其他组件：“视觉风格参考项目里已有的 pricing-table 组件，保持一致的圆角和间距节奏。”

3.3 定义验收标准：让 AI 自己检查

主动提示词的最后一步，是把你脑子里的验收标准写出来，让 AI 在生成后自己过一遍。我常用的模板是：

生成后请自查： - 在 1280px 宽度下，三列是否等宽且间距一致？ - 中间列的边框颜色与背景色对比度是否达到 3:1 以上？ - 键盘 Tab 键能否依次聚焦到三个按钮？ - 是否所有颜色都来自 tokens 变量？

这个自查清单不一定会让 AI 真的去“检查”，但它会作为生成时的隐式约束，让模型在写代码时更注意这些点。实测下来，加了自查清单的生成结果，在无障碍和响应式方面的遗漏明显更少。

4. 完整实操流程与关键代码

4.1 第一阶段：结构骨架的生成与验证

第一阶段的提示词我写得很克制，只描述结构，不涉及任何视觉：

用语义化 HTML 生成一个三列定价卡片结构。 每列包含：套餐名称、价格、计费周期、功能列表、CTA 按钮。 中间列标记为推荐套餐。 不要写任何 CSS，只出 HTML 结构。

Cursor 给出的结构大致是这样的：

<section class="pricing-grid" aria-label="定价方案"> <article class="pricing-card"> <h3 class="plan-name">基础版</h3> <p class="plan-price"><span class="currency">¥</span>29<span class="period">/月</span></p> <ul class="feature-list"> <li>核心功能 A</li> <li>核心功能 B</li> <li>基础支持</li> </ul> <button class="cta-button" type="button">开始使用</button> </article> <!-- 中间推荐列 --> <article class="pricing-card is-featured"> <span class="badge">最受欢迎</span> <h3 class="plan-name">专业版</h3> <p class="plan-price"><span class="currency">¥</span>79<span class="period">/月</span></p> <ul class="feature-list"> <li>全部核心功能</li> <li>高级功能 C</li> <li>优先支持</li> </ul> <button class="cta-button" type="button">开始使用</button> </article> <!-- 第三列 --> <article class="pricing-card"> <h3 class="plan-name">团队版</h3> <p class="plan-price"><span class="currency">¥</span>199<span class="period">/月</span></p> <ul class="feature-list"> <li>全部功能</li> <li>团队协作</li> <li>专属支持</li> </ul> <button class="cta-button" type="button">联系我们</button> </article> </section>

这个结构基本可用，但有个细节需要注意：<article>里直接放<span class="badge">在语义上稍微有点别扭，更稳妥的做法是把 badge 放在<h3>内部或者用aria-label补充说明。我在这一阶段没有让 AI 改，因为结构层面的小瑕疵可以在后续阶段顺手处理，没必要在第一轮就追求完美。

提示：第一阶段千万不要让 AI 写 CSS。一旦它开始写样式，注意力就会被视觉细节分散，结构上的问题反而容易被忽略。

4.2 第二阶段：视觉层级的“克制版”实现

第二阶段我给的提示词是：

为上面的定价卡片结构写 CSS。 要求： - 使用 CSS Grid 实现三列布局，列间距 24px - 中间列用 1px 边框加轻微背景色差区分，不要用放大或强阴影 - 所有颜色引用 tokens 变量（--color-bg, --color-border, --color-accent 等） - 价格数字是视觉焦点，字号最大；功能列表次之；按钮再次 - 圆角统一使用 --radius-md

这里的关键是“中间列用 1px 边框加轻微背景色差区分”这句话。如果我只说“中间列要突出”，AI 大概率会给我加个transform: scale(1.05)或者很重的box-shadow。明确指定用边框和背景色差，就把它的发挥空间限制在了“克制”的范围内。

生成的 CSS 核心部分：

.pricing-grid { display: grid; grid-template-columns: repeat(3, 1fr); gap: 24px; align-items: start; } .pricing-card { padding: 32px 24px; border: 1px solid var(--color-border); border-radius: var(--radius-md); background: var(--color-bg); } .pricing-card.is-featured { border-color: var(--color-accent); background: var(--color-bg-subtle); } .plan-price { font-size: 2.5rem; font-weight: 700; color: var(--color-text-primary); } .feature-list { font-size: 0.9375rem; color: var(--color-text-secondary); line-height: 1.8; }

这段代码没什么花哨的东西，但信息层级是清楚的：价格最大、功能列表次之、按钮再次。中间列通过边框颜色和背景色差做了区分，没有破坏整体节奏。

4.3 第三阶段：交互状态与键盘可访问性

第三阶段我重点补交互状态。提示词：

补充交互状态： - 按钮 hover 只改变背景色深浅，不加位移或缩放 - 按钮 focus-visible 要有清晰的轮廓，不能只靠颜色变化 - 卡片 hover 时边框颜色轻微加深，不要加阴影 - 所有交互状态都要考虑 prefers-reduced-motion

这里有个细节值得展开说。很多 AI 生成的 hover 效果喜欢用transform: translateY(-2px)加box-shadow组合，视觉上确实“有反馈感”，但在定价卡片这种密集排列的场景里，卡片位移会导致相邻元素视觉上的抖动，反而显得廉价。用边框颜色加深或者背景色微调，反馈感足够且更稳。

focus-visible 的处理也是 AI 容易偷懒的地方。默认的outline在很多设计系统里被去掉了，但如果没有替代方案，键盘用户就完全看不到焦点位置。我让 AI 用outline: 2px solid var(--color-accent); outline-offset: 2px;来处理，既清晰又不破坏布局。

4.4 第四阶段：动效的“最小必要”原则

第四阶段是动效。这也是最容易“花里胡哨”的地方。我的提示词写得很紧：

只加两个动效： 1. 页面加载时卡片依次淡入，间隔 80ms，总时长不超过 400ms 2. 按钮点击时有一个轻微的按下反馈（scale 0.98，持续 100ms） 其他任何动效都不要加。 必须包含 prefers-reduced-motion 媒体查询，在减弱动效模式下禁用所有动画。

“其他任何动效都不要加”这句话是必须的。如果不写，AI 很可能会给勾选图标加旋转、给价格数字加计数动画、给 badge 加脉冲效果——这些在演示视频里好看，在实际产品里只会分散注意力。

最终生成的动效代码：

@media (prefers-reduced-motion: no-preference) { .pricing-card { opacity: 0; animation: fadeIn 0.4s ease forwards; } .pricing-card:nth-child(2) { animation-delay: 80ms; } .pricing-card:nth-child(3) { animation-delay: 160ms; } .cta-button:active { transform: scale(0.98); } } @keyframes fadeIn { to { opacity: 1; } }

注意这里用prefers-reduced-motion: no-preference作为媒体查询条件，而不是在reduce模式下覆盖。这样写的好处是，默认情况下（不支持该特性的旧浏览器）不会执行动画，更稳妥。

5. 当 AI 输出“花里胡哨”时怎么拉回来

5.1 先别急着否定，拆解它为什么这么做

第一轮生成时 AI 给我的“花里胡哨”版本，其实不是乱来的。我后来复盘发现，它加渐变边框是因为我在提示词里说了“中间列要突出”，加呼吸光晕是因为我说了“按钮要有吸引力”，加旋转星星是因为我说了“勾选图标可以有点设计感”。每一个“过度设计”背后，都对应着我提示词里一个模糊的形容词。

所以当输出跑偏时，第一步不是骂 AI，而是回头检查自己的提示词：哪个词给了它过大的解释空间？“突出”可以是很重的阴影，也可以是细微的边框色差；“有吸引力”可以是发光，也可以是更好的文案。把这些形容词替换成具体的、可验证的描述，问题就解决了一大半。

5.2 用“减法提示词”做定向修正

如果已经生成了花哨的版本，不用全部推倒重来。我常用的做法是选中出问题的代码块，用“减法提示词”做定向修正：

这段代码里的渐变边框和发光效果去掉。 中间列的区分改用 1px 实线边框加背景色差。 保持其他部分不变。

“保持其他部分不变”这句话很重要。如果不加，AI 可能会顺手把其他它觉得“不够好”的地方也改了，导致你又要重新验证一遍。

5.3 建立自己的“负面清单”

踩过几次坑之后，我整理了一份 UI 生成场景的负面清单，每次写提示词时直接复制粘贴进去：

这份清单不一定适合所有项目，但建立清单这个动作本身很有价值——它逼你把“我不想要什么”想清楚，而不是等 AI 生成后再来挑毛病。

6. 常见问题与排查技巧

6.1 生成结果和项目设计系统打架怎么办

这是最常见的问题。AI 不知道你项目里已经有一套设计令牌，它会自己造颜色值、自己定圆角大小。解决办法有两个：一是在提示词里明确要求“所有颜色和间距必须引用 tokens 文件中的变量”，二是把 tokens 文件的内容直接贴进对话上下文里。

我通常会把 tokens 文件里最常用的十几个变量列出来，附在提示词后面：

项目可用的设计令牌： --color-bg: #ffffff --color-bg-subtle: #f8f9fa --color-border: #e5e7eb --color-accent: #2563eb --color-text-primary: #111827 --color-text-secondary: #6b7280 --radius-sm: 4px --radius-md: 8px --radius-lg: 12px

这样 AI 在生成时就有明确的取值来源，不会自己发明新颜色。

6.2 响应式断点总是处理不好

AI 处理响应式时容易走两个极端：要么完全不管，要么加一堆断点把代码搞得很复杂。我的经验是，在提示词里明确指定断点策略：

响应式策略： - 桌面端（≥1024px）：三列并排 - 平板端（768px-1023px）：中间列单独一行，两侧列并排 - 移动端（<768px）：单列堆叠 只使用这三个断点，不要加更多。

指定断点数量和每档的行为，比让 AI 自己“看着办”要可靠得多。

6.3 生成的无障碍属性形同虚设

AI 会加aria-label，但经常加得不对。比如给一个已经有可见文字的按钮再加aria-label，反而会导致屏幕阅读器读两遍。我的做法是在提示词里明确：

无障碍要求： - 按钮如果有可见文字，不要加 aria-label - 功能列表用 ul/li 结构，不要用 div 堆叠 - 推荐列的 badge 用 aria-label 补充说明，不要只靠视觉区分 - 所有交互元素必须可通过键盘操作

6.4 常见问题速查表

7. 几个让我少走弯路的实操心得

第一个心得是分阶段验证比一次性生成再修要快。我一开始也嫌分阶段麻烦，觉得让 AI 一次生成完再改更省事。但实际对比下来，一次性生成后修改的时间，往往比分阶段生成加验证的时间更长——因为你要在一堆混杂的问题里逐个定位，而分阶段时每个阶段的问题边界是清晰的。

第二个心得是把“不要什么”写进提示词模板里，而不是每次临时想。我现在有一个自己的提示词模板文件，里面固定包含负面清单、tokens 列表、断点策略、无障碍要求这几块。每次做新的 UI 组件时，只需要改最上面的任务描述，下面的约束直接复用。这样既省时间，又保证了输出质量的下限。

第三个心得是AI 生成的代码一定要自己过一遍再提交。这不是不信任 AI，而是因为 AI 不知道你项目的完整上下文——它不知道某个类名已经被占用了，不知道某个 CSS 属性在你们支持的浏览器版本里有兼容问题，不知道某个交互模式和产品逻辑有冲突。把这些检查点过一遍，是对自己负责。

第四个心得是保留 AI 的“花哨版本”作为灵感库。虽然大部分花哨效果不能直接用在生产环境，但偶尔会有一些有意思的想法——比如某个渐变角度、某种图标处理方式——可以拆出来用在营销页或者演示环境里。我现在的做法是，每次 AI 生成的花哨版本都存到一个单独的文件夹里，需要做 demo 或者提案时翻一翻，比从零想要快得多。

最后再分享一个小技巧：如果你用的是 Cursor，可以在项目根目录放一个.cursorrules文件，把常用的约束条件写进去。这样每次对话时不需要重复粘贴，AI 会自动读取这些规则。我现在的.cursorrules里就包含了设计令牌引用规则、动效限制、无障碍要求这几块，实测下来能省不少重复输入的时间。