高转化落地页：AI 设计实战

AI 很容易生成一张结构完整的落地页：顶部有导航，中间有一个醒目的 Hero 首屏，下面排列几个页面区块（Section），再用价格、常见问题（FAQ）和行动号召（Call to Action，CTA）收尾。问题是，这类页面往往只有「落地页的外形」，没有清楚的产品信息，也没有明确的转化目标。配色、圆角和渐变即使做得精致，仍然很难让访问者采取下一步行动。

落地页需要先回答三件事：产品给谁用，解决什么问题，使用后能得到什么结果。设计负责让这些信息更容易被理解和信任，AI 与 Skills 则用来缩短从内容结构到可运行页面的距离。

先确定唯一的主要转化目标

同一个页面可以同时放注册、试用、下载、预约演示和付费入口，但首屏最好只突出一个主要动作。按钮越多，访问者越难判断下一步该做什么。

主要转化目标取决于产品当前阶段：

Hero 中的主 CTA 与页面尾部的 CTA 通常指向同一个动作。导航、功能卡片和 FAQ 可以帮助访问者补充判断，但不应与主 CTA 争抢注意力。需要同时服务自助购买与企业销售时，可以保留一个低强调度的次要动作，例如「预约演示」。

转化目标还要能够被测量。至少记录 Hero CTA、尾部 CTA、注册完成和支付完成等事件，否则页面改版后只能比较视觉感受，无法判断转化是否改善。事件中只保留来源、动作和完成状态，不应把邮箱、支付信息等敏感数据发送给分析工具。

有目的地积累设计参考

审美很难通过一句「做得高级一点」交给 AI。更稳定的做法是先收集同一产品类型的成熟页面，再明确希望借鉴哪些部分。

Pinterest 适合按行业、配色或版式建立情绪板。打开一张能源、旅行或 SaaS 落地页后，推荐流会继续给出相近方向，适合快速扩大参考范围。

Mobbin 收录了大量 Web 与 App 页面，还能按产品和 Flow 查看登录、Onboarding、创建内容等完整流程。它适合研究成熟产品如何保持多个页面的设计一致性，比单看首页截图更完整。

Landingfolio 集中收录 Landing Page、Pricing、About 等页面，可以按 Section 类型寻找 Hero、Testimonials、Pricing 和 FAQ 的参考。准备开发某个 Section 时，直接比较同类区块比漫无目的地浏览整站更有效。

收集参考时，应记录可执行的设计决定，而不是只保存截图：

• 字体层级，包括标题、正文、标签和按钮的字号与字重；

• 配色角色，包括背景、正文、强调色、边框和状态色；

• 布局节奏，包括内容最大宽度、Section 间距和网格列数；

• 图像方向，包括产品截图、真实照片、3D 资产或插画；

• 交互风格，包括悬停、进入、滚动和状态切换的动效强度。

这些决定可以写进 DESIGN.md。后续增加 Pricing、Dashboard 或登录页时，AI 读取同一份设计规范，比每次重新贴一张参考图更容易保持一致。

一套常用的落地页结构

页面顺序并非固定模板，下面这些 Section 可以作为常用的起点：

Hero 应该留在首屏，Pricing、FAQ 与 Final CTA 通常靠近页面尾部。Benefits、Use Cases、Features、Social Proof 和 Integrations 可以按产品的说服逻辑调整顺序，也不必全部出现。没有集成能力就不要放 Integrations，没有自助定价就不必伪造 Pricing。

Testimonials 必须来自真实用户。产品早期还没有公开评价时，可以改用测试用户的授权反馈、创始人的产品说明、可验证的 Demo、候补名单数据或试点结果。虚构姓名、头像和评价会直接破坏信任，也可能涉及广告合规风险。

从文案和 Section Map 开始生成

直接要求 AI「做一个好看的落地页」，等于把产品定位、页面结构、视觉方向和技术实现同时交给模型猜。更有效的提示词会先给内容，再让 AI 整理 Section Map，也就是页面区块清单。

下面这份模板适合从 0 到 1 创建页面：

请先阅读当前项目、现有组件和技术约束，不要更换框架或重复安装已有依赖。

产品名称：[名称]

目标用户：[具体角色]

用户当前的问题：[问题]

产品提供的结果：[可理解、可验证的结果]

主要转化目标：[注册、试用、下载、预约演示或购买，只选一个]

可用证据：[产品截图、Demo、真实评价、案例数据、集成或安全说明]

页面需要包含：Navbar、Hero、Benefits、Use Cases、Features、Social Proof、Pricing、FAQ、Final CTA 和 Footer。与产品无关的 Section 可以删除，但需要说明原因。

视觉方向：[粘贴参考页面并说明只借鉴哪些设计决定]

请先输出 Section Map、每个 Section 的目标与文案草稿，确认后再实现页面。完成实现后生成 DESIGN.md，记录字体、颜色、间距、圆角、阴影、图像和动效规则，并运行项目已有的 typecheck、lint、test 和 build。

这份提示词把内容结构与实现分成两步。先审阅 Section Map，可以在写代码之前发现定位不清、证据不足和 CTA 冲突。页面已经存在时，也可以只让 AI 补齐缺失的 Section，不必重建整个项目。

用「周末去哪儿」走一遍 Section Map

下面用一个假设产品说明这套方法。示例功能、文案和数据只用于演示 Section Map，不代表真实上线产品。

• 产品名称：周末去哪儿；

• 目标用户：想在城市周边安排周末活动，但不愿在多个平台反复搜索的人；

• 当前问题：活动信息分散，时间、位置、预算和购票方式难以快速比较；

• 产品结果：根据位置、日期和预算整理一份可比较的活动清单；

• 主要 CTA：查看本周推荐；

• 可用证据：真实活动样本、更新时间、来源链接和产品 Demo。

这些信息已经足以决定页面内容：

这个版本不需要 Pricing 和 Integrations，因为假设产品还没有明确收费方案，也没有可展示的集成能力。先删除无关 Section，比用占位文案把结构填满更准确。AI 完成页面后，验收也有了明确对象：两个 CTA 是否指向同一流程，活动来源是否可核对，移动端能否完成筛选和查看详情。

截图适合还原方向，不适合承诺一比一

截图可以提供构图、比例、配色和信息密度，却无法告诉 AI 字体文件、响应式断点、交互状态、组件语义和真实资产。仅凭一张桌面截图生成页面，常见结果是首屏接近参考图，移动端、后续 Section 和交互细节明显偏离。

截图复刻更适合采用「提取规则，再实现页面」的顺序：

这张图片只作为设计参考。请先分析字体层级、配色角色、内容宽度、网格、间距、圆角、阴影、纹理、图像比例和动效线索，输出一份设计规则。

在当前项目中按这些规则实现页面，不要更换技术栈。优先使用真实 HTML、项目已有组件和可访问的交互元素，不要把整张截图当作背景图。

对截图无法确认的字体、资产、交互和响应式行为，请明确列出假设。实现后同步已有设计规范，并检查移动端、平板和桌面端布局。

如果参考站点属于自己，或者源码与模板许可明确允许复用，可以把 HTML 和 Tailwind CSS class 作为更精确的实现线索。一次只处理一个 Section，模型更容易识别局部结构和依赖，也更方便在浏览器中逐段比较。

复制整个页面源码通常效果更差。大量导航、脚本、隐藏节点和运行时属性会挤占上下文，组件依赖也可能脱离原项目后失效。页面里出现 Tailwind CSS class 只说明样式写在标记附近，不代表代码可以自由复制。第三方网站没有明确授权时，应只借鉴通用设计原则，不要复制文案、品牌资产、插画和源码。

Taste Skill 先处理整体设计

Taste Skill 是一组面向 AI Coding Agent 的前端设计 Skills，主要处理布局、字体、间距、视觉密度和常见的模板化问题。其中 design-taste-frontend 是通用实现 Skill。截至 2026 年 7 月，官方给出的单 Skill 安装命令是：

npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend"

安装 Skill 不会自动补齐产品定位和素材。它更像一组设计约束，需要与产品 brief、Section Map 和参考方向一起使用：

使用 design-taste-frontend 改进当前落地页。

保留已有信息架构、品牌内容和技术栈，重点检查 Hero 构图、字体层级、Section 节奏、网格变化、视觉密度和移动端布局。

不要用无关的渐变、悬浮卡片和装饰元素填充空白。需要新增图片时先列出图片用途和规格，缺少真实资产时保留清楚的占位说明。

修改后更新设计规范，并说明哪些设计决定可以复用于后续页面。

Taste Skill 适合决定页面整体应该长什么样。文案不清、图片质量差或证据不足时，Skill 无法用视觉效果弥补内容问题。

Design Engineering Skills 再处理动效与细节

Emil Kowalski 的 Design Engineering Skills 用来帮助 AI 处理界面设计与动效判断。截至 2026 年 7 月，官方仓库包含下面 6 个 Skills：

官方 README 提供的安装命令会从该仓库安装 Skills：

npx skills@latest add emilkowalski/skills

动效应该解释状态、建立空间关系或给出操作反馈。落地页可以有比业务后台更丰富的滚动与进入动画，但仍要控制频率和幅度：

• 高频按钮和导航反馈保持短促，不让动画拖慢操作；

• 进入与退出优先使用 transform 和 opacity，避免动画引发布局抖动；

• 卡片组可以使用轻微 stagger，不要让所有 Section 依次慢慢出现；

• Hover 只作为增强，触摸设备不能依赖 Hover 才显示关键信息；

• 所有位移动效都要支持 prefers-reduced-motion；

• 动态数字、切换按钮和异步内容预留稳定尺寸，避免 Layout Shift。

可以把动效任务单独交给 AI：

使用 emil-design-eng 检查当前落地页的动效与交互。

为 Hero、产品 Demo、卡片组和 Final CTA 添加克制、可中断的动效。高频导航和按钮不要添加复杂动画。

禁止 transition: all，优先动画 transform 与 opacity。处理 prefers-reduced-motion、触摸设备、键盘焦点和 Layout Shift。

修改后用慢速回放检查进入、退出和连续触发状态，并在移动端验证滚动性能。

实际顺序可以是先用 Taste Skill 完成静态层级和布局，再补真实文案与图片，最后用 Design Engineering Skills 处理动效。页面结构仍在频繁变化时就加入复杂动画，会增加后续调整成本。

Impeccable 用于定向审查与上线前检测

Impeccable 把设计工作拆成一套可以直接调用的命令。截至 2026 年 7 月，官方版本包含 1 个 Skill、23 个设计命令和 46 条确定性检测规则。它会读取项目已有的 Design Tokens、Components 和约定，也能通过 PRODUCT.md 与 DESIGN.md 保存产品受众、品牌语气、视觉规则和不希望采用的设计方向。

官方推荐在项目根目录运行下面的安装命令。它会识别 Codex、Claude Code、Cursor、Gemini CLI 等开发工具，并安装对应版本：

npx impeccable install

该命令要求 Node.js 22.12 或更高版本。通用 Skills 安装器也可以使用 npx skills add pbakaus/impeccable，但它安装的是跨工具共享版本，不包含针对当前开发工具调整的命令路径和规则。安装后需要重启开发工具。

在支持 Slash Command 的工具中，首次运行 /impeccable init，选择 Brand 或 Product 模式，并生成后续命令所需的设计上下文。Codex 通过 /skills 打开 Skill，或者输入 $impeccable 后要求它初始化当前项目，不使用 /prompts: 命令。

页面已有第一版后，可以按问题选择命令：critique 检查信息层级与表达是否清楚，audit 检查 Accessibility、Performance 和 Responsive Design，typeset 与 layout 分别处理字体和布局，harden 处理文本溢出、国际化与边界状态，polish 用于上线前的最后检查。

Impeccable 还提供不调用 LLM、也不需要 API Key 的检测命令，可以放进 PR 检查：

npx impeccable detect src/

检测发现渐变文字、卡片嵌套、模板化配色等规则中的问题时，会返回非零退出码。它适合拦截可明确判断的模式，但不能替代浏览器中的视觉检查，也不能判断产品文案和证据是否可信。

这三套 Skills 不需要全部叠加。缺少初版视觉方向时使用 Taste Skill，需要细致处理动效时使用 Design Engineering Skills，页面已经成形并需要重复审查、收尾或接入 CI 时使用 Impeccable。同一轮同时运行多个设计 Skill，可能产生相互冲突的字体、间距和动效建议。

品牌图标不要交给 AI 猜

通用操作图标可以使用项目已有的 Lucide 等图标库。品牌 Logo、模型厂商和第三方服务图标应优先从品牌官方资源获取，也可以在 LobeHub Icons 与 Iconfont 中查找 SVG。

社区图标库里的品牌图形不一定是官方版本，颜色、留白和商标使用规则也可能过期。引入前要核对来源与许可，保留 SVG 的 viewBox，并给纯图标链接补充可访问名称。不要让 AI 根据文字临摹品牌 Logo，也不要把多个来源中风格不一致的图标直接拼在同一组 Integrations 里。

Components、Blocks 与 Templates 的区别

前端资源网站经常同时提供 Components、Blocks 和 Templates，三者解决的问题不同：

关系可以简化为：Components 组成 Blocks，Blocks 再组成 Templates。实际资源网站不一定严格采用这些标签，选择时应看代码覆盖范围，而不是只看分类名称。

shadcn/ui 适合从基础 Components 开始，shadcn/ui Blocks 与 Shadcnblocks 提供更完整的页面区块。Magic UI、Aceternity UI 和 21st.dev 收录了大量视觉与动效组件，其中部分实现已经接近完整 Block。Tailwind Plus 提供商业 Components 与 Templates，Float UI 和 Aceternity UI Templates 则适合寻找整页参考。

同一页面优先使用同一套设计语言。混合多个组件库时，需要统一字体、颜色、圆角、阴影、间距和动效，否则每个 Section 单独看都不错，组合后仍会像拼装页面。商业资源还要确认许可证是否允许当前项目、客户数量和分发方式。

模板应该迁移设计，不要继承旧技术栈

模板经常存在技术版本和工程约定与当前项目不一致的问题。一个视觉上合适的模板，可能使用旧版框架、不同的 Router、另一套 CSS 方案，或者依赖已经停止维护的动画库。直接在模板上继续写业务，后面会同时承担模板升级和产品开发两套成本。

更稳妥的流程是先初始化符合当前要求的项目，再把已获授权的模板放进 reference-template 目录，只把它当作设计与交互参考。让 AI 阅读模板后，在当前项目中重新实现，不要把模板代码和依赖整包搬进来。

reference-template 中放置了一份已获授权的落地页模板。

请阅读它的页面结构、布局、配色、字体、图像比例和交互方式，同时检查当前项目的框架版本、路由、组件库、样式方案和工程规则。

在当前项目中重新实现相同的设计方向，不要复制模板的依赖、配置和旧版框架代码。优先复用当前项目已有 Components，并把需要新增的依赖控制在最小范围。

保留模板许可证和 attribution 要求。完成后更新已有设计规范，并运行当前项目的完整验证命令。

模板只提供一种已经完成的内容组合。产品的真实 Section、文案长度和图片比例很可能与模板不同。替换过程中如果需要大量裁切文案、伪造功能或塞入无关图片，说明这份模板并不适合当前产品。此时从 Blocks 逐段组合，通常比继续修改整套模板更省事。

上线前按真实页面验收

代码生成完成不等于落地页已经完成。至少检查下面这些结果：

1. 首屏能否在几秒内说明目标用户、问题、结果和主要动作；

2. Hero CTA、尾部 CTA、注册、下载或支付流程是否真实可用；

3. Testimonials、客户 Logo、数据和功能描述是否真实且获得授权；

4. 375px、768px 和 1440px 下是否出现横向滚动、文字遮挡或布局跳动；

5. 键盘焦点、触摸目标、颜色对比和 prefers-reduced-motion 是否可用；

6. 图片是否清楚、尺寸合适，并配置了合理的加载策略；

7. 动效是否影响滚动、输入和 Core Web Vitals；

8. typecheck、lint、test 和 build 是否通过；

9. CTA 与关键转化事件是否进入分析工具；

10. DESIGN.md 是否足以指导后续页面保持同一风格。

AI 可以快速生成第一版，Skills 可以减少模板化设计、补足动效规则，并提供可重复的审查流程，Components 与 Blocks 可以缩短实现时间。最终转化仍然取决于产品定位、文案、证据、图片和细节。每次只调整一个主要变量，再用真实访问与转化数据判断结果，页面才会从「看起来完整」逐步变成可工作的销售入口。

参考资料

设计参考：

• Pinterest

• Mobbin

• Landingfolio

Agent Skills：

• Taste Skill 官网

• Taste Skill GitHub

• Emil Kowalski：Design Engineering Skills

• Impeccable 官网

• Impeccable GitHub

图标资源：

• LobeHub Icons

• Iconfont

• Lucide

Components、Blocks 与 Templates：

• shadcn/ui Components

• shadcn/ui Blocks

• Shadcnblocks

• Magic UI

• Aceternity UI

• 21st.dev

• Tailwind Plus

• Float UI Templates