在打开任何一个主流网站之前，先问一个前端开发者可能早就想过的问题：为什么 2020 年之后的互联网，看起来越来越像同一个网站？统一的圆角卡片、统一的“免费试用”按钮、统一的渐变背景、统一的“获取早期访问权”弹窗……甚至关闭按钮的位置都出奇一致。如果你也注意过这个现象，那 GitHub 上这个名为 “Every Fucking Website (2020)” 的经典项目，几乎可以说是在用代码给整个网页设计行业画了一幅毒舌但精准的素描。
这篇文章我会先拆解这个项目的最初动机，再把里面戏谑的 UI 模式逐一落到前端工程视角来分析：它们为什么会出现、背后用了哪些技术方案、哪些模式真的能提升转化率、哪些只是大厂之间的盲目模仿。最后我会给出具体的检测方法和工程建议，帮助你在自己的项目里避免“全中国网站共用一套模板”的尴尬。
如果你是一名前端工程师、交互设计师，或者正在负责产品网站和官网落地页，这篇文章值得读完并收藏。它不会教你写出惊世骇俗的颠覆性设计，但它可以帮你认清当前 Web 设计中那些“自动巡航”式的惯性从哪里来，以及如何在保留用户熟悉感的同时，仍然做出有辨识度的产品。
1. 为什么“Every Fucking Website”能变成一个开发者梗
先交代背景。这个项目最早来自 GitHub 上一个非常简短但传播极广的代码仓库，本质是一个网页，把大量网站共有的 UI 元素全部堆在一个页面上。它的标题直接、粗粝，甚至在中文技术社区里一度被当作段子转发。但从技术角度去拆，它的价值不在脏话，而在于它用极少的代码揭示了一个事实：现代网站的结构已经高度模板化，模板化到可以被人用几段 HTML 精确复现。
如果用工程师视角来解读，作者其实是在做一次“UI 模式采样”。他观察了 2020 年前后最流行的 SaaS 网站、开发者工具主页、落地页和社区类产品，然后提取出重复率最高的组件。常见到令人发指的元素包括：
- 顶部一左一右的导航，左边是 Logo，右边是 “Log in” 和 “Get Started” 按钮。
- Hero 区域左侧大标题、右侧插画或产品截图，截图通常嵌在浏览器窗口框里。
- Facebook、Google、GitHub 三件套的第三方登录按钮。
- “Free Forever”“No credit card required”“Start your free trial” 这类橙色或绿色 CTA。
- 页脚一定是四列链接加上社交媒体图标。
- 如果用户想离开，大概率还会有退出意图弹窗，提供 10% 折扣码。
把它拆到这一步，你才会意识到：这不是设计能力问题，而是商业转化逻辑和前端工程惯性共同作用的结果。很多产品把“主流网站的布局”误认为是“经过验证的标准答案”，因为复制成功者的结构可以降低用户的学习成本，也可以减少设计决策和 A/B 测试的时间。可是当所有人都在复制时，整个互联网的用户就会产生一种奇怪的钝感——每个网站都像是一个模子刻出来的，用户在浏览时不再记忆品牌，只记忆那些相同的组件位置。
这个项目之所以能在开发者中传播，是因为程序员天然容易产生共鸣：当你接手一个企业官网或 SaaS 项目时，产品经理给的参考站点几乎都是同一类模板。从拉取设计稿到切图再到实现组件，你甚至不需要看设计稿的细节，因为闭着眼都知道第一个区块是 Hero、第二个区块是 Social Proof、第三个区块是 Feature Grid。这带来一个非常现实的问题：组件的技术实现越来越趋同，前端工程师的个人价值被逐渐压缩到了交互细节和性能优化里。而 “Every Fucking Website” 用代码做了最直接的控诉：大家引以为傲的网页作品，拆开看全是同质化积木。
2. 高频 UI 模式盘点：它们到底是什么
与其嘲笑这些模式，不如把它们的真实名称、技术和业务动机说清楚。这样你就能在未来的工作中判断，哪些模式是产品必须的，哪些只是“为了像大厂而像大厂”。
2.1 导航栏与登录区
绝大多数 2020 年前后的 SaaS 和开发者工具网站，顶部导航都采用同类结构：左侧品牌 Logo，中间若干个功能链接（Features、Pricing、Docs、Blog），右侧两个按钮，一个文字按钮 “Sign in”，一个填充按钮 “Start Free”。这个布局的合理性在于用户的浏览动线非常成熟，注册用户会习惯性地找右上角登录，潜在客户会通过按钮颜色判断下一步操作。按钮通常使用品牌色的高对比色，目的就是让页面唯一的“实心按钮”成为视觉终点。
实现层面，这个区域通常由接近的 flex 布局完成，代码结构长这样：
<header class="site-header"> <a href="/" class="logo">YourProduct</a> <nav class="main-nav"> <a href="/features">Features</a> <a href="/pricing">Pricing</a> <a href="/docs">Docs</a> </nav> <div class="auth-area"> <a href="/login" class="signin-link">Sign in</a> <a href="/register" class="btn btn-primary">Start Free</a> </div> </header>这不是错误的代码，它的问题只在于无差别复制。如果你的产品面向的是专业开发者，且核心用户并不需要“注册引导”，那么这套导航反而会挡住那些真正寻找文档或 API Key 的人。此时把高对比按钮改成 “Console” 或 “Docs” 可能更合理。
2.2 Hero 区
Hero 区是一套产品官网的核心，也是 “Every Fucking Website” 嘲讽最狠的地方。2020 年的典型 Hero 区通常由几部分组成：左侧是一个 40 到 65 像素左右的大标题，标题里一定包含 “The Best Way to ...” 或者 “Modern ... for developers”；下方是两行灰色副标题；再往下是两个按钮；右侧则是产品界面的截图，截图用台式机或浏览器窗口的轮廓框住，很多时候还有阴影、透视效果和微动效。
为什么大家如此一致？原因很简单：左文右图是大规模 A/B 测试的常见结果之一。大量商业 SaaS 网站在相同模板上测试过转化率，文字置于左侧可以让访客在 5 秒内读完价值主张，右侧吸引眼球的视觉并不干扰主文案。技术侧，这类布局还有利于响应式设计——移动端可以直接把右侧图片隐藏或置底，保留文字和按钮，代码改动小。
但要注意，它对“品牌记忆”几乎是零贡献。如果你的产品需要让用户记住独特的差异化卖点，Hero 区应该有一个非常具体的演示动画，而不是一张套了浏览器边框的截图。更有效的做法是直接把真实的代码输入框放在首屏，让用户三秒内产生“这工具能解决我的问题”的直觉。判断标准不是“像不像好的 SaaS”，而是“用户离开后能不能说清你卖什么”。
2.3 登录方式中的第三方认证
“Sign in with Google / GitHub / Microsoft” 是几乎所有 2020 年后上线的网站默认提供的。项目里把三个 Logo 排一排的情况也很常见，这背后确实有工程理由：第三方 OAuth 能降低用户的注册阻力，同时让开发者免于维护一整套密码找回和邮箱验证体系。
实现上，前端最多是几个按钮与 OAuth 跳转，后端需要对接标准协议。开发者需要考虑两个问题：一是只保留真正匹配受众的第三方登录，例如开发者工具保留 GitHub，企业服务保留 Google 和 Microsoft；二是把第三方登录与账号绑定流程设计清楚。最常见的错误是用户先用 Google 登录，后来又改用邮箱注册，结果同一个邮箱产生两个账号。今天再设计这块时，建议用统一账号体系标识邮箱，将第三方 OAuth 获得的邮箱与自有账号做打通合并。
2.4 Cookie 弹窗与隐私横幅
Cookie 同意横幅虽然不是 “Every Fucking Website” 里戏谑程度最高的元素，却也是让每个访客都感到厌倦的通用模块。它流行的真正原因是法规驱动，而不是设计师喜欢。对于前端工程师来说，它的痛点在于隐私偏好管理会直接影响脚本加载时机，处理不好很容易让分析统计失效，轻则数据不准，重则违反法律。工程上建议把它抽象成独立服务，允许用户无痕撤回授权，而不是做成一个只有“同意”按钮的假弹窗。
2.5 弹窗、公告栏与 “View Demo”
2020 年前后的网站里，公告栏几乎成了一条工具体系：顶部细长条写着 “New：we just raised 10M to build ...”，退出意图时弹出电子书下载框，右下角定时跳出一个 “Schedule a Demo” 的窗口。这些设计的出发点是捕捉高意向用户，但实施过载时就变成“移动端用户每 10 秒被弹窗打断一次”的灾难现场。
如果你统计一下自己的站点，大概率会发现公告栏带来的新功能曝光，远低于它给核心内容造成的干扰损失。工程上，公告类的组件不应该用强弹窗，而应该用可关闭的线性提示条，并做好与 Cookie 偏好一致的控制。
3. 网站同质化背后的技术推手
“Every Fucking Website” 看似是在吐槽视觉，实际上背后隐藏着一条完整的技术链条，让同质化从偶然演变成了系统性的必然。
第一层推手是前端 UI 框架和组件库的普及。Bootstrap 很早就把栅格和按钮样式推广到了全网络，而 React 生态的 Material-UI、Ant Design、Tailwind CSS 又进一步让默认样式成为主流。设计系统在提高效率的同时，也把大量组件的交互形态标准化了。比如很多开发者并不想自己调一个完美的下拉菜单，直接引入组件库默认状态即可。这本来无可厚非，但问题在于组件库的默认形态成了许多产品最终设计的唯一形态。当按钮圆角、导航高度、卡片阴影都来自同一个默认主题时，网站长成同一个样子几乎是必然结果。
第二层是程序员文化里的“复制参考站点”。产品经理会收集竞品截图，程序员会在搜索引擎里找 “SaaS landing page template”。为了降低沟通成本，两方都会默认“模仿大型成功产品是最低风险策略”。从工程决策来说，这并非懒政，而是一种风险规避：大厂官网经历过千万级流量验证，布局一定不会太差。于是 “Copy 成功模板” 就被当作 “最佳实践”传递开了。
第三层是数据驱动的局部优化。当网站开始做 A/B 测试后，团队会发现把 CTA 放在右上角、把按钮改成高对比色、把注册表单缩短到三个字段，都有可能提升 1% 到 5% 的转化率。这些局部优化彼此叠加，会慢慢把与“转化率”无关的品牌视觉和独特布局全部碾压掉。结果是：网站确实更符合数据预期了，但也丢掉了个性和“令人记住的能力”。
从 2020 年到现在，虽然设计趋势有一些变化，比如暗黑模式、玻璃拟态、超大字号排版开始流行，但信息架构的同质化没有消失。因为我们真正复制的不是颜色，而是一套组织内容的思维框架。只要这套思维框架不改变，即使把圆角改成直角、把插画改成 3D 渲染，用户感受到的仍然是“又一个从模板里出来的网站”。
4. 如何快速识别你的网站是否“模板化”
你可以用自己的产品主页做一次自查。不要只停留在视觉感受，而是把页面结构拆成组件清单，一项项做归属分析，判断每个组件究竟是“产品需求”还是“从参考网站平移来的习惯”。
先做一轮结构列表检查。一个偏模板化的页面通常会存在以下特征：
- Hero 区标题能直接换成一个竞品名称，而文案不违和。
- 功能特性区块每个卡片都是“图标 + 标题 + 一句描述”，且图标来自同一个免费的 icon 库。
- 价格页面是三个竖排卡片，中间一个带 “Most Popular” 角标。
- “Testimonials” 区的头像都是真人照片，但排版千篇一律。
- 页脚分成四列，第一列是 Product，第二列是 Resources，第三列是 Company，第四列是 Legal。
这个方法不需要写代码，只要在文档里标出每个 Map 组件的来源即可。源自“竞品都有”的数量如果超过 50%，那你的产品官网大概率正在丧失记忆点。
接下来做一次更细致的技术识别。我用 Chrome DevTools 可以快速判断页面是否重度依赖通用模板。打开任意网站，按 F12，在 Console 里输入下面这段脚本，会粗略导出页面上最常见的 UI 文案：
const usedTexts = new Set(); document.querySelectorAll('a, button').forEach((el) => { const text = el.innerText.trim(); if (text && text.length < 40) { usedTexts.add(text); } }); console.log([...usedTexts].slice(0, 80).join('\n'));运行代码后，如果控制台输出的文本里有大量的 “Get Started”“Learn More”“Free Trial”“Sign Up”“View Demo”，说明该页面正在依赖通用模板式的转化话术。当然，不是说这些词不能用，而是当页面十个按钮里有八个按钮都是此类话术时，产品的真实价值点会被淹没在套路里。
还可以查看网站的 HTML 结构中的 class 命名，很多模板化网站会在 HTML 里保留模板或 UI 库的特征关键词，例如hero、cta-section、site-footer、container这类语义命名。如果命名体系非常一致，说明前端很可能直接采用了某套通用模板，而不是针对品牌特征定制过。CSS 变量层面也可以快速查看，如果整个站点的主色、辅助色、间距、圆角都集中在几个 CSS 变量中，并且与其他竞品官网高度相似，那么“样式层”正在走向同质化。
5. 从代码层面把“模板感”降下来
想要摆脱同质化，并不需要推翻所有组件重写一遍。建议你从代码结构入手，对网站的「设计底座」做一次重构，让模板感从变量、色彩、动效和文案替换四个层面降低。
5.1 用设计令牌取代“就近取色”
很多模板化网站的样式问题，都源于开发者直接从设计稿复制十六进制颜色并散落写到每个组件中。正确的做法是建立一套设计令牌，把颜色和间距提升为主题变量。这样后续调品牌色时，不需要全局搜索替换，只需要修改一组变量。
以 CSS 自定义属性为例：
:root { --brand-hue: 262; --brand-color: hsl(var(--brand-hue) 70% 50%); --surface-1: #ffffff; --surface-2: #f6f7f9; --text-primary: #1a1a2e; --text-secondary: #5a5f73; --radius-sm: 6px; --radius-md: 12px; --radius-full: 999px; --shadow-card: 0 8px 24px rgb(0 0 0 / 8%); --space-1: 0.25rem; --space-2: 0.5rem; --space-3: 1rem; --space-4: 2rem; }将默认的按钮、卡片都建立在令牌上，之后如果希望品牌看起来不那么“Bootstrap 化”，只需要调整一个色相或圆角值，全局视觉就能立刻发生变化。这是工程层降低成本的最有效方式。
5.2 用“特色组件”替代“通用卡片”
模板感的最强来源不是颜色，而是“每个功能都装在一个圆角卡片里”的布局惯性。建议你挑选两到三个最重要的功能，为它们定制真正独特的展示组件。
以开发者工具为例。与其用三个卡片描述“高性能、安全、易用”，不如直接把一段真实 API 请求的代码贴进 Hero 区，加一个可交互的标签页切换功能。再往下，用“一个曲线图 + 实时日志输出”来替代功能特点。这个决策会让页面样式偏离模板化，因为代码编辑器、命令行终端、执行日志这类元素天然带着“工具产品”的视觉特征，不属于通用 SaaS 模板的默认视觉体系。
实现一个最简的代码展示区不太困难。使用后端的 JSON 数据，配合 Prism 把它渲染成高亮代码即可。但更关键是结构上不要硬塞到圆角卡片容器里，可以做成全宽、深底色的终端样式，视觉上更容易形成记忆点。
5.3 用动效制造“产品反馈”
模板化页面通常只有 hover 变色的微交互，用户的感受是“页面的功能存在，但没有人回应我”。优秀产品的网站会让操作有连续的反馈，比如滚动到某一块时触发数字变化，点击 Demo 按钮时出现模拟 loading，验证码提交后有成功状态。这些动效并不需要在每处都做，选取一个最核心的关键行为做一次“有仪式感的反馈”即可，用户会因此觉得产品细腻，而不是“又一个模板”。
5.4 文案去模板化的技术手段
文案层面的模板化甚至可以通过代码约束。可以在前端仓库里加入一个定制 ESLint 插件或自定义脚本，扫描常见的“标准文案”，在 CI 阶段输出警告，让开发者意识到自己又在写通用话术。更简单的方式是准备一批“文案清单”的测试用例。
一个粗糙但有效的 Node 脚本示例如下：
const fs = require('fs'); const path = require('path'); const COMMON_PHRASES = [ 'Get Started', 'Learn More', 'Free Trial', 'Sign Up Now', 'View Demo', 'No credit card required' ]; function scanFiles(dir) { const results = []; const entries = fs.readdirSync(dir, { withFileTypes: true }); for (const entry of entries) { const fullPath = path.join(dir, entry.name); if (entry.isDirectory()) { results.push(...scanFiles(fullPath)); } else if (/\.(html|jsx|tsx|md|mdx)$/.test(entry.name)) { const content = fs.readFileSync(fullPath, 'utf8'); COMMON_PHRASES.forEach((phrase) => { if (content.includes(phrase)) { results.push(`${fullPath}: 包含通用文案 "${phrase}"`); } }); } } return results; } const matches = scanFiles('./src'); if (matches.length > 0) { console.warn('检测到模板化文案，建议人工确认：'); matches.forEach((item) => console.warn(' -', item)); process.exit(0); }把这段脚本放到package.json的 scripts 里，每次构建前执行一次，是让团队真正留意文案差异的工程手段。营销文案当然可以保留一部分常规表达，但对于核心价值和区隔点，一定要有超出这个清单的特殊描述。
5.5 建立组件“用途备注”
更偏工程管理的做法是在设计系统或组件库里，给每个组件增加一段“何时不应使用”的备注。例如 Modal 组件备注里写明“不建议在首屏展示或作为强制公告使用”；Hero 组件备注写明“如果产品的主要价值是品牌认知，建议考虑左文右图之外的布局”。这类备注不一定影响运行代码，但是会通过代码 review 影响真实决策，使得开发者复制组件时，理解其适用边界，而不是把它当作放之四海而皆准的积木。
6. 实操：改造一个模板化网站的最小流程
如果手上的官网正处在“人人都说眼熟，但又说不出哪里不好”的阶段，下面这个最小改造流程可以作为一个行动参考。它不需要重构技术栈，只需要用一到两个迭代周期完成。
先把旧页面拆成五层状态：文案层、品牌层、组件层、动效层、交互反馈层。文案层单独梳理，产品经理需要回答：这个页面的第一个问题到底是“你的产品是什么”，还是“你的产品和其他工具有什么不同”？如果旧文案说的是前者而产品到了迭代期，那就应该把首个价值主张替换成更具体的独特能力。品牌层要确认主色、字体和圆角边界不能只因为美观而随波逐流，而是要定义成设计令牌，统一纳入 CI 的审查范围。
组件层则建议按照“替代”而不是“删除”来做：把最常用的三个卡片式 Feature 区块中一个改成交互演示，一个改成表格对比，最后一个保留为卡片，但加上产品独有的截图或插画。这样组件形态有节奏，同时保留了常规结构的可用性。动效层只需要做一个关键动效：首屏的核心 CTA 点击后，可以过渡到产品 Demo 的代码演示区域，形成一条视觉连续性。交互反馈层要检查所有按钮，是否有 loading 状态和成功提示，避免“点了没反应”。
改完后不要凭感觉验收，应该做一次“5 秒记忆测试”：找三四位目标用户，让每个人只在首页停留 5 秒，然后关掉页面，问他们记得住这个网站卖什么、跟其他产品的差异是什么。如果多数人能说出一致且具体的答案，说明改造有成效。这个测试方法不需要流量和统计工具，成本几乎为零，却比看热力图更适合早期判断信息传达是否到位。
7. 常见问题与排查方法
在落地去模板化改造时，团队可能会遇到一些典型的阻力。我把常见问题整理成了一个表格，方便在研发过程中快速定位。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 改了 CSS 变量后，部分按钮颜色没有更新 | 组件样式有独立的硬编码色值 | 全局搜索十六进制色值和 rgba 值 | 删除硬编码色值，统一使用设计令牌变量 |
| 移除弹窗后转化数据明显下降 | 弹窗确实是高转化来源，但干扰了品牌印象 | 拆分流量做 A/B 测试，对比长期留存 | 保留低频易关闭的退场弹窗，避免新用户首次访问即被打断 |
| 团队成员认为“只要设计得和竞品不一样就是风险” | 缺少产品差异表达方式，把“参考模板”当成了“标准解法” | 组织一次站内组件来源审查，标记哪些组件来自习惯复制 | 通过 5 秒记忆测试验证改动效果，逐步积累信心 |
| 自定义组件开发成本高，排期不通过 | 团队低估了模板化认知造成的隐形损耗 | 计算页面一致性成本与内容迭代成本 | 优先改造 Hero 区和核心功能展示区，其他区块按需推进 |
| 修改模板后部分布局在移动端错乱 | 自定义组件没有处理响应式断点 | 用 Chrome DevTools 的设备模拟器检查核心断点 | 为自定义区域设置移动端专属布局，必要时隐藏次要装饰元素 |
| 网站内部团队看了觉得没问题，但新用户记不住品牌 | 团队对产品定义过于熟悉，无法站在新手视角判断 | 邀请新手做 5 秒测试，不做诱导式提问 | 按测试反馈重写首屏一句话定位，并落实到 Hero 区文案 |
这里最容易被低估的问题，是团队会把“数据好”直接等同于“设计对”。弹窗如果带来短期注册提升，团队就会舍不得去掉它。但长期留存、品牌搜索量和对产品调性的感知，并不会直接体现在当周注册曲线里。更稳妥的判断方式是同时记录用户回访率、品牌词搜索次数和自然传播指标，而不是只看弹窗转化率这一条。
8. 最佳实践与工程建议
8.1 把“去模板化”变成可持续的工程规范
设计初衷很容易在后续版本迭代中被稀释，所以建议用代码和工程规范把偏离拉回来。最容易落地的是在 CI 流程中加入“设计令牌审查”和“模板文案扫描”。设计令牌审查比较适合用 Stylelint 配合自定义规则，禁止在组件代码中出现魔法数值色值；模板文案扫描则可以用前面的 Node 脚本。这两道关卡能让每次提交都经过一次下意识的反思，而不是事后再靠人肉评审。
8.2 保留熟悉感，别追求“为不同而不同”
强调摆脱同质化，不等于要把导航藏起来、把登录按钮放到页面最底部。用户已经习惯了右上角登录、左侧导航、主按钮聚焦这些交互线索，强行违反这些习惯会造成可用性下降。正确的做法是“结构熟悉，组件细节独特”：导航还在右上角，但按钮文案不再是 “Get Started”，而是具体到产品动作，比如 “Run your first query”；价格页还是三列，但中间高亮的不叫 “Most Popular”，而叫 “For teams scaling LLM workloads”。
8.3 用“真实内容”替代“营销占位符”
模板感最强的内容形态，是那种充满空洞形容的占位符文案。比如“提高生产力”“降低成本”“简化流程”这类在哪个领域都成立的描述，几乎不会给访客留下任何具体认知。技术产品官网的黄金法则是把抽象的形容词改成名词和数字。在代码块里放真实 API 调用，在 Hero 区直接展示一个可复制的安装命令，比任何 “The Best Way” 都更能让开发者信任。
从这个角度看，“Every Fucking Website” 讽刺的既是设计趋势，也是内容上的懒惰。所有网站都试图用一套话术说服用户，最后用户就不再相信话术了。只有先展示价值、再展示机制、最后提供证据的网站，才更容易建立信任。
8.4 警惕动效与弹窗的入口陷阱
开发者经常会在模板组件里拿到现成的弹窗、浮层和提示条，为了“丰富首页”就匆匆接入。最好的做法是在接入任何营销型浮层前，先判定它是否能让用户更接近产品的核心任务。如果答案模糊，建议先通过无侵入的页面位置进行曝光。比如“免费试用”的引导，不一定非要用弹窗强制展示，用页面底部常驻的标签栏或在导航栏右上角放一个稳定的按钮，会更温和也更有效。
8.5 使用暗黑模式和品牌可变主题
如果你不想重新设计整套风格，但又需要打破默认白底模板感，暗黑模式就是一个成本较低的差异化切口。设计系统可以将主题定义为light与dark两组令牌，跟随系统偏好自动切换。这不仅能提升开发者用户的阅读体验，也能让页面在截图、分享、社交传播场景中更醒目。实现上只需要在根级样式里切换 CSS 变量：
@media (prefers-color-scheme: dark) { :root { --surface-1: #111318; --surface-2: #1a1d24; --text-primary: #f0f2f5; --text-secondary: #a6adbb; } }如果你的产品用户本身就是程序员，暗黑模式几乎属于刚需，而不是一种单纯的美学尝试。相比一整套新设计，通过主题令牌衍生出的暗黑版形态，投入产出比通常更高。
8.6 记录设计决策，建立“避免做”清单
最后一个看似不写代码但非常有效的实践，是在项目仓库里维护一份 “Avoid list”。里面记录团队曾经轻易复制过、后来发现并不适合的组件模式，比如“不在用户首次访问时弹出问卷”“不把 Docs 入口隐藏在三个层级以下”“不在价格页使用误导性倒计时”。这份清单应该和代码一样接受 review，它能在产品经理更换、设计团队流动时，成为项目最重要的隐性知识之一。
9. 总结与后续学习方向
“Every Fucking Website (2020)” 看起来只是一个粗暴的吐槽页，但它背后的观察对开发者是有长期参考价值的：网站的视觉趋同和技术模板化，本质是组件复用、风险管理、数据优化和商业转化等多股力量共同作用下的结果。对于产品官网和 SaaS 工具类网站，完全避开这些通用模式是不现实的，也是不必要的。你需要做的是弄清哪些模式承载了真实功能，哪些只是在消耗品牌辨识度。
如果你接下来想深入实践，可以按三个方向继续研究。首先是学习设计系统的底层变量设计，比如了解 CSS 自定义属性、Design Token 和主题切换机制，这是工程层面摆脱同质化的地图。其次是关注竞品分析的结构化方法，不只是看竞品“长什么样”，而是拆解背后它的导航、弹窗、信息层级分别服务于哪种商业目标。最后是研究交互中的微反馈，尤其是在开发者工具落地页里，代码输入、命令行展示、实时日志这类承载真实内容的模块如何设计和实现。
如果你的产品也需要做一次“官网去模板化”的小改造，可以从这里开始：把首页截图打印出来，用笔圈出所有你在其他三个网站上见过的一模一样的组件，然后再问一遍——如果今晚这个大厂模板被删掉了，你的产品还能靠什么让用户记住自己的名字？
