落地页工艺是做什么的？

本文记录了 Favour 实际构建落地页时，如何避免模板化的具体方法。这些方法源自他过去构建 Allowance、didii、Revolut Founder Mode、TrashPay 和 FlutterBytes 会议网站的对话，并经过他本人针对使用本技能制作的测试构建所给出的直接反馈而不断完善。这不是一份泛泛的“落地页最佳实践”指南——它具体呈现了他始终坚持、不断修正、并拒绝在质量上妥协的原则。本文也是一份实时更新的文档：开始之前请先查阅 references/build-log.md，完成后请更新该文件。

每个项目的目标：打造一个真正有独特视角的页面，而不是一个仅仅替换了客户名称的、合格的模板。关键是：这个概念要能在第一眼就被视为明显且刻意的设计，而不是一个需要解释才能理解的点子。

开始之前：是否有足够的信息？

如果简报没有提供一个可以挂钩的实体产品——即没有名称、没有目标用户、没有调性提示、没有任何能将这个想法与其通用版本区分开来的信息——请先停下来并提问。提出一两个尖锐的问题，远好过自己虚构一个方向，然后发现它并不适用。

还有两个需要主动提问而非假设的具体场景：

如果一个部分显然需要真实照片（而不是抽象或矢量图表示），在继续之前请先索取。如果无法获得，请说明情况，并使用渐变和线条图形来即兴创作，而不是伪造一张库存照片。
如果一个部分需要典型的示例内容（例如示例名称、样本卡片、占位数据），请先提出一个版本，并明确邀请对方提出修改意见，而不是悄悄敲定你自己的猜测。

如果有足够的信息——一个真实的名称、真实的受众、真实的差异化点，即使很粗略——就可以继续。

构建技术栈

默认目标是 Next.js、TypeScript、Tailwind CSS 和 Framer Motion。这也是本技能所借鉴的每个项目实际使用的技术栈。切勿交付纯 HTML 或纯 JavaScript。

如果工作环境无法实时渲染这个技术栈，请直说，而不是悄悄替换成更弱的技术。仍然要构建真实的 React 组件，永远不要使用纯 JavaScript，并尝试使用 CSS 过渡或 Web Animations API 来模拟预期的动效以进行预览——但同时提供真实的 Next.js/TypeScript/Framer Motion 代码库作为可下载文件。并且，如果需要一个能够真正运行并截取该技术栈输出（例如 Claude Code）的环境时，尤其当对输出进行真实视觉判断比快速浏览更重要时，要说明这一点。

表单始终提交到 Google 表单

网站上的任何表单——候补名单、联系、咨询、申请发言、订单/预订等——都是一个品牌化的、使用网站自有设计的自定义构建表单，其提交内容通过 Google 表单的预填链接转发到后台的 Google 表单。访问者永远不会看到原始的 Google 表单；他们看到的是网站的风格，而数据会落入 Google 表单的回复（及其链接的回复电子表格）中。

一旦明确网站需要表单，就尽早提出这个要求——这就像照片一样，是对他人的一个依赖。要求他们创建一个字段与网站表单相匹配的 Google 表单，并发送其预填链接。然后，将每个现场表单字段映射到从预填链接中解析出的相应 Google 表单条目 ID，并在表单的提交处理程序中进行提交（标准方法是通过 POST 请求提交到表单的 /formResponse 端点，并携带 entry.<id> 参数，或等效方法）。如果对方尚未提供链接，请完整构建品牌化的表单 UI，但明确地存根并标记提交目标，而不是虚构一个端点。

始终向对方说明获取 Google 表单预填链接的步骤，因为大多数人不知道在哪里找到它：

以编辑模式打开 Google 表单。
点击右上角的三个点 ⋮ 溢出菜单。
选择 “获取预填链接”。
为每个字段填写一个可识别的占位值（例如，将字段自身的名称输入进去），然后点击底部的 “获取链接”。
在弹出的窗口中点击 “复制链接” 并发送过来。

该链接包含每个字段的 entry.<id>，正是将品牌化表单的字段映射到 Google 表单所需的信息。

字体和颜色，与对方共同选择，而非独自决定

在确定任一元素之前，先进行简短的视觉确认，而不是独自决定：

字体： 查阅 references/typeface-library.md，寻找最近未过度使用的候选字体。然后提出三种独特、非显而易见的展示字体候选，并用每种字体实际渲染出产品名称，以环境支持的任何方式呈现（图片、快速预览、实时组件）——切勿仅以文本形式列出字体名称。让对方从真实的字形中选择，而不是凭感觉猜测一个名称听起来如何。库外全新的字体也是受欢迎的选择——如果选择了，请随后将其添加到 references/typeface-library.md 中。切勿跳过此提议和确认步骤——即使已经有一个明显的强力推荐或准备使用库内字体，仍然要展示候选并确认，而不是独自决定。
颜色和主题： 提出一个调色板（4-6 个命名值），并阐述每个选择基于主题的理由。在此处有意决定浅色与深色主题，而不是默认选择深色（请参见 references/taste-rules.md 中的主题规则——许多品牌更适合浅色主题）。在两者最终确定之前进行确认。
风格方向： 与字体和颜色一同，从 references/section-bank.md 中命名风格家族中为整个页面选择一个主导风格家族（极光/柔和辉光，新辉光深色科技，清洁科技有机，编辑/粗野主义，极简高调，奢华/高级展示，企业 B2B/金融科技）——选择必须基于简报的具体原因，而非习惯。这是稍后从板块库中选取内容的范围；在此范围之外借用是刻意的点缀，而非默认做法。

之前的两次测试构建都跳过了这些步骤，独自决定了所有内容——两次都恰好效果不错，但那是运气，而非流程按预期工作。

首先确定网站类型

在开始其他任何事情之前，先确定这是七种类型中的哪一种——以下品味规则和框架适用于所有类型，但板块清单以及（对于企业、欧洲和迷你企业类型）视觉方法有所不同：

产品落地页 (Allowance, didii, TrashPay) —— 专注于候补名单或下载、定价、用例、功能网格。
作品集 / 案例研究页 (Revolut Founder Mode) —— 设计师自身概念的推介：个人简介块、证明相关性的真实数据、“联系我”而非候补名单。
活动 / 会议页 (FlutterBytes) —— 演讲者展示、往届历史、组织团队鸣谢、赞助商、议程。
企业页 (一个时装品牌、一家面包店、一家美发沙龙、一个工作室——一个已存在的真实世界企业，而非初创公司) —— 销售已实际存在的产品或服务，因此更注重图片密集和氛围优先，而非功能网格优先。目标是大约 75% 的部分围绕真实摄影构建（菜单/作品集/画廊/空间），在其之上叠加标志性动作和动画规则，而非取代图像。
混合型 —— 有意混合上述两种或三种类型（一个也在推活动的产品，一个附带过去作品组合的企业）。为整体结构和间距选择主导类型，然后从次要类型中借用其所需的具体板块。
欧洲风格网站 —— 风格干净、克制、高级，类似于高端欧洲工作室/Framer 模板作品。基础与其他类型相同，但英雄区域刻意简洁：在约 98% 宽度的圆角矩形框中设置一张或多张合适的真实照片（从 Unsplash、Pexels 或 Pixabay 获取并下载）作为英雄背景，其上不叠加复杂的标志性视觉。无候补名单。简洁，但不乏味。
迷你企业落地页 —— 紧凑、高级的单页，恰好四个部分（英雄、产品/服务、证明、联系），旨在推介那些尚未建立线上形象的、成熟的、通常是传统行业的企业——机械经销商、大宗出口商、制造商、工业供应商、批发商。这个页面必须足够有说服力，让一个没有网站的企业相信拥有一个网站的价值，因此它非常依赖高质量的真实摄影、真实的信任信号（数据、客户标志、认证）以及自信且多样化的英雄区——请参阅 references/site-types.md 中五种英雄迭代轮换方式和强制性的“联系我们”部分。

阅读 references/site-types.md，了解每种类型的板块清单和结构说明。如果确实不属于以上任何一种，则视其为最接近的产品落地页并进行调整。

流程

明确方向。 品牌名称、业务内容、目标用户、任何参考网站或提到的风格。如果明确网站将需要表单（候补名单、联系、咨询、订单），现在即按照上述表单部分提出 Google 表单的依赖项——请对方创建 Google 表单并发送其预填链接，以免最后手忙脚乱。
在接触任何板块之前，找到核心概念。 不是功能列表——用户从该产品实际获得或感受到的单一事项，用一个简单的句子陈述，再加上两到三个支撑性的想法。稍后将根据此概念检查每个板块的标志性动作。同时，直接询问对方是否已有他们希望包含或说明的概念、视觉或想法——特别是针对英雄区——以便他们自己的愿景能融入概念，而不是被一个虚构的想法覆盖。
与对方共同选择字体和颜色（如上所述），基于主题，而不是独自决定。
确定网站类型（如上所述）并浏览其板块清单。查阅 references/build-log.md，了解最近项目使用了什么，以避免本项目无意中与上一个雷同。
在编写任何布局或代码之前，逐节并行地运行下面的检查清单，然后诚实地评分。

逐节检查：
- 这是什么部分？它应该获得多少视觉权重？英雄区应该比信任简介获得更多权重。
- 产品大体是关于什么的？这个部分具体是关于什么的？基于其实际的标题、副标题和内容——而不是其类别的通用标签。
- 从该内容出发，什么概念是合理的？查阅 references/concept-gallery.md 中已有的概念——复用一个尚未冷却的概念，改编一个，或创造一个新的并随后添加到其中。
- 板块设计库提供了什么？从 references/section-bank.md 中提取两到三个候选行（按板块类别匹配，然后按项目的风格方向匹配），与一个从头开始创造的选项进行权衡，并按照库的“改编而非移植”规则调整胜出者——该行的调色板、字体和像素规格将重新映射到本项目，且该板块仍然必须通过针对此特定品牌的两秒测试。
- 什么动画或悬停交互能使其生动？库的动态列是一个可借鉴的词汇表（虚线偏移绘制、里程表计数、flex-grow 扩展、交错入场、遮罩揭示）——但同一页面上永远不能使用两次相同的原始动效。
- 标题和副标题有多长？短的可以承载居中/环绕处理（参见 references/taste-rules.md 中的布局原型）；长的则不能。
- 前一个板块使用了什么布局和什么标志性动作？上一个项目使用了什么？不要重复。
诚实地评分，使用可验证的检查而非舒适的数字：
- 这个概念是否落入了三种通用 AI 设计默认值之一（暖奶油色 + 衬线字体 + 赤陶色、近黑色 + 一个酸性强调色、或宽幅/发线规则的报纸风格）而没有基于简报的具体理由？如果是，那就是失败——返回检查清单。
- 如果对完全不同的产品运行相同的提示，这个确切的选择是否会出现？如果是，则说明它还不够具体。
- 一个陌生人大约在两秒钟内是否能理解它代表什么，而无需任何说明？一个只有在解释后才能起作用的概念，无论其推理多么巧妙，都是失败的。
评分是一个始终运行的纪律，而不是需要展示的东西——对方看到的是最终的概念和明确的结论，而不是一个记分牌。并且要诚实地面对真正的局限性：如果无法实际看到渲染效果，自我评分更接近于仔细的代码审查而非真实的视觉判断，因此应持怀疑态度而非慷慨。如果环境能够实际运行并截取构建的输出，请使用它——真实的查看胜过预测。
构建完整的初稿，使用评分后的概念以及 references/taste-rules.md 中的常设规则。
逐节对照已构建的页面进行质量检查。 对每个部分，问：
- 这个部分是否与第 2 步的核心概念有可见的联系，还是仅仅孤立地说明其自身的功能？
- 任何两列布局的非文本侧是否真正生动——是一个动画微界面、屏幕片段或自包含的概念——还是一个死寂的静态图片？不是问“这是两列吗”，而是问“这里是否有任何不该静态的东西是静态的”？
- 在 fading divider 或更考究的设计更合适的地方，是否使用了朴素的带边框卡片？整个页面是否总共只使用了一到两个使用卡片的板块？如果是一个卡片，它是否有真正的定制化处理（光泽渐变填充、类玻璃边框、动画图标）和真实的悬停交互？
- 所有图标是否来自选定的自定义图标库（Lucide/Phosphor/Heroicons/Tabler），页面上是否没有使用 emoji 作为替代？

落地页工艺