web-ai-slop

Web AI 垃圾内容——从业者的反默认检查清单

重要

核心理念（箴言）： 避免统计平均值。生成布局、样式或逻辑时，不要默认采用典型或“标准”的方案；应根据具体情境、用户和约束，做出有针对性的审慎选择。

这是一套经过训练的过滤器，而非风格指南。这项技能之所以存在，是因为语言模型在所有 Web 领域都会收敛到同一小组“安全”默认方案——并非因为这些方案很好，而是因为它们处于训练数据的统计中心。这项技能的作用，是准确指出这个中心，让你有意识地偏离它。

应用规则： 先起草输出，然后对照下文相关章节进行检查。如果在任意一个章节中符合 2 项或更多，就说明你并没有做出选择，而是采用了默认方案。丢弃草稿，针对这个产品、团队和情境做出明确且有理有据的选择。

默默应用这套过滤器。不要向用户讲述“我正在用反垃圾清单检查这个”。

---

第 1 节——视觉设计（Web 设计师 / UI 设计师视角）

拥有 40 年专业经验的设计师会立刻认出这些机器生成的模式。

1a. 布局与构图的默认模式

• 居中式主视觉区，标题 + 副标题 + 两个胶囊式 CTA 按钮 + 首屏下方的浏览器模型截图——把它当作唯一可能的布局，不论产品实际是什么都照搬。这只是一个起步框架，不是经过审慎选择的方案。
• 对称的 3 列或 6 列功能网格——每个版块都被安排成 3 项或 6 项且布局完全相同，只因为模型在不了解实际功能的情况下觉得 3 和 6“平衡”。
• 占据整个视口、除了文字、副标题和按钮外空无一物的主视觉区——把 100vh 的空白当作精致感。
• 版块 → 分隔线 → 版块 → 分隔线，节奏毫无变化——每个页面都以相同的节奏展开。真实页面的节奏各不相同：有紧凑的细节版块、有留白开阔的版块，也有数据密集的版块。
• 每个页面都出现的粘性导航，无论页面是只需滚动一次的落地页、长篇文章，还是导航会与内容争夺注意力的应用视图。
• 包含 4–5 列链接的页脚，其中的链接对于这个特定产品的用户来说，实际使用时根本不会点开。
• 给不需要图标的功能加图标——AI 模型喜欢在每项功能旁边放一个 Lucide 或 Heroicon，即使这并不能让内容更清楚。
• 把表情符号当作图标，或在任何文案中使用表情符号——不要用表情符号代替图标，也不要在标题、按钮或正文中使用表情符号。请使用真正的图标。
• 未经审视便使用默认的 Shadcn 图标集——有意识地选择图标库，或者询问用户偏好的风格，再根据回答做选择。不要直接采用组件库自带的图标。
• 默认添加装饰性渐变——如果用户明确提出要求，渐变当然可以使用。如果使用渐变，请保持微妙，并确保它适合配色；绝不要把渐变用于页面的最后一个版块（应以纯色收尾），也不要随手套用 Shadcn 默认的按钮 / 链接渐变预设。

1b. 装饰性图案

• 发光渐变色块／极光背景 — 在主视觉区后方使用紫到蓝或紫到粉的径向模糊效果。这是最常见的 AI 默认设计，用来表现“现代科技公司”。任何资深设计师在设计需求中看到这一点，都会忍不住叹气。
• 粒子网络／带连接线的浮动圆点 — 表示“AI”或“数据”的视觉简写。只要设计需求提到 AI，首先生成的就是粒子球体或神经网络网格，因此这种设计并不合适。
• 波浪形或色块状 SVG 分区分隔线 — 在各个分区之间不加区分地套用有机曲线，只为传达“亲切的科技感”，却没有任何品牌依据。
• 卡片、按钮或图片上的品牌色发光光晕／外发光阴影 — 把霓虹边框技巧一次用在所有元素上。
• 将小型仪表板组件和图表铺成瓷砖状，作为装饰性背景壁纸 — 用繁杂的占位设计代替真正的产品决策。这就是 2025/26 年的“粒子网络”。
• 笔记本电脑、火箭或办公桌前的人物等等距 3D 插画 — 在设计需求没有提出任何指示时，仍将其用作图库主视觉。
• 抽象几何低多边形背景 — 使用淡淡的三角网格或六边形作为纹理。
• 倾斜摆放的浮动 UI 元素截图（“设备样机”图）— 将其当作唯一考虑过的产品可视化形式。

1c. 组件层面的明显特征

• 玻璃拟态卡片 — 不论卡片内容或所属品牌是什么，都默认采用磨砂玻璃半透明面板、柔和的白色边框和 backdrop-filter: blur()，作为“高级感”卡片样式。
• 由图标圆角方块卡片组成的 Bento 网格 — 每张卡片都包含一个 Lucide 或 Heroicon 图标，以及恰好三行通用的优势文案（“快速、安全、可扩展。”）。
• 所有元素的圆角都过大 — 卡片、按钮、输入框、图片的圆角一律设为 16px 或更大，把它当成表达“亲切感”的万能方案。
• 所有按钮都做成胶囊形状（border-radius: 9999px），不论品牌是否适合这种样式。
• 客户评价轮播 — 使用图库圆形头像、名字加姓氏首字母，以及一句泛泛的评价，其中没有任何具体数字、成果或具名功能。
• 定价区块始终设为 3 个档位，且始终突出显示中间档位，用彩色边框和“最受欢迎”标签标注，不管这种呈现方式是否适合该产品。
• 高对比度发光／强调阴影按钮 — 默认在主要行动号召（CTA）按钮上使用高对比度渐变、厚重投影或品牌色发光光晕，作为视觉捷径，却没有充分的视觉层级或品牌契合依据。

1d. 快速扫描信号表

打开网站，在进行任何技术操作前先观察 10 秒。以下信号无需检查代码即可看到。

信号	观察要点
紫蓝渐变	许多 AI 工具默认使用相同的蓝紫渐变——看过一次，就再也无法忽视。通常是 Hero 区域后方的径向模糊效果。
到处都是玻璃拟态	磨砂玻璃卡片带白色边框，不管品牌风格如何，都被当作默认的“高级”设计手法。
粒子网络／神经网络视觉效果	漂浮的点由线条连接起来，泛泛地代表“AI”或“数据”，却没有具体指向产品的功能。
图标卡片组成的 Bento 网格	3 或 6 张圆角方形卡片，每张都配有 Lucide/Heroicon 图标，以及 2–3 行泛泛的优势描述。
间距不一致	不同版块的外边距和内边距各不相同，页面节奏因此显得不协调——间距一致是经过认真设计的明显标志之一，缺少这一点就很容易露馅。
字体层级薄弱	默认字体、尴尬的行长、不一致的标题字号，以及过于拥挤的行距，都说明字体排版从未经过妥善设置。
对比度不足	白底上的浅灰文字，或文字与背景对比度过低——WCAG 规定普通文本的最低对比度为 4.5:1，而许多 AI 默认配色都达不到这一标准。
所有卡片的悬停效果都一模一样	每张卡片悬停时都会以相同方式浮起或发光，效果一律套用，而不是只在能提供实际操作提示的地方使用。
过多闪光／AI 表情符号	在标题和按钮中大量使用 ✨ 来表示“AI 驱动”，如今这本身就成了破绽。

快速测试： 把浏览器窗口缩窄，或在手机上打开。AI 生成的布局常常会在模型从未被明确要求处理的屏幕尺寸下出现错位、重叠或溢出——而跨断点进行真正的响应式质量检查，正是最先被跳过的步骤之一。

应该这样做： 选择一个真正的视觉元素——一幅具体的插图、展示产品实际数据流的图表，或真实界面的截图——克制地呈现，并为它留出空间。认真打造产品的公司会在每个屏幕上呈现一个精准的想法，而不是拼贴 AI 默认风格的纹理。

---

第 2 部分 — 色彩与字体排版（Web 设计师／UI 设计师视角）

2a. 默认配色

• 紫色／紫罗兰色（#7c3aed 左右），或与蓝色、粉色搭配的靛蓝色：品牌没有任何相关暗示时，自动套用的“科技感”配色。
• 纯黑色（#000000）或纯白色（#ffffff）背景：取代经过斟酌、略带暖调、冷调或个性的近黑色或近白色背景。
• 仅出于审美原因而决定“默认使用深色模式”——因为深色模式在演示中上镜，或看起来更显高级，而不是因为内容、使用场景或用户群体需要它。
• 将渐变按钮作为主要 CTA 样式，却没有任何理由说明该品牌为何要使用渐变。
• 在单一设计系统中使用五种或更多强调色，因为需求中出现了“鲜艳”一词——真正的设计系统讲究克制：一种强调色、一组功能色、一组语义色。
• 毫无出处的配色选择——回答中直接出现了十六进制色值，却没有解释产品品牌、所属类别或受众如何影响这些选择。

2b. 排版默认做法

• 仅使用 Inter 的 400、600 和 700 字重，标题不使用展示字体，正文不使用衬线字体来形成对比，也不考虑 Inter 是否适合这个品牌。
• 大型展示标题的 letter-spacing: 0 保持不变——专业的字体系统会随字号增大而收紧字距（letter-spacing: -0.02em 至 -0.05em）。72px 标题使用默认字距，会显得像模板。
• 不假思索地应用 Tailwind 的 tracking-wide/tracking-wider/tracking-tight 工具类，并默认用大写文本来强调——只有在有具体排版理由时才使用其中任何一种；除非用户提出要求，否则不要改变现有文本已确立的大小写处理方式。
• 除了字号和字重，没有其他视觉上的字体层级——正文、弱化文本和浅色文本的颜色值都相同，只用字号区分。真正的层级至少会使用三个色调层次。
• 不考虑不同上下文的行高——12px 说明文字和 56px 标题都使用相同的 line-height: 1.5。
• 所有内容都使用全大写标签，以此替代对字体层级的思考。
• 正文里只用 700 字重（“粗体”）来强调，从不使用斜体、小型大写字母或基于颜色的强调。

应该这样做： 从具体来源推导配色——产品类别、你明确想与之区分的特定竞争对手，或客户提出的一项品牌约束。使用颜色前，先说明十六进制色值及其依据。指定字体前，先说明字体及选择原因。

---

流程

按此执行。不要只把清单当作参考放在一旁，却依旧沿用默认做法——原始版本的这项技能即使“参考”了清单，仍然会产出粗制滥造的结果，原因就在于此。

1a. 起草前确定锚点

指出一个具体依据，说明本次输出必须忠于什么：实际主题或产品、目标受众，以及这个特定页面、组件、文档或配置要完成的唯一任务。如果需求已经明确了方向，就严格遵循——不要用自己的参考取代明确指示。

如果需求留有发挥空间，就选出 1–2 个具体、真实的参考对象进行对照——不要只说一种感觉（“现代”“简洁”“可信”“专业”），而要说出具体对象：某个产品的信息密度、某种印刷传统的分栏规则、你明确想与之区分的特定竞争对手，或主题领域中的某种材料或仪器。只选一个参考对象容易照搬。明确地融合两个要素则能促成新意：“这份硬件数据表的直白风格，融合农事年鉴的排版温度”，为插值提供两个锚点，而不是一个照抄对象。

这是原始的清单式版本所缺少的步骤。纯粹的过滤规则只会告诉模型不要产出什么，却从不告诉它应该产出什么，所以所谓的“应该这样做”往往会悄然绕道回到相同的套路。明确点出参考对象，才能真正改变输出。

1b. 起草

基于锚点，而不是脑海中最先浮现的套路，制作实际成果——文案、布局、组件、配置或文档。

1c. 过滤

根据下面相关的参考文件检查草稿。在某个参考文件的任一部分中，若符合两项或更多，就说明你是在沿用默认做法，而不是经过判断做出的决定。 丢弃草稿，并根据第 1 步的锚点重新制作。不要通过表面调整来修补同一份草稿——换个图标、放大标题、换个紫色调都不算修改，只是给同一种默认做法换了套装扮。

只加载当前任务实际涉及的文件——纯文案任务不需要打开 DevOps 参考文件。

1d. 自检

展示输出前，回答 references/self-check-and-pushback.md 中的六个问题。只要有任何一个答案是“否”或“我不知道”，就先修改再展示。

1e. 记录——仅适用于同一会话中的多部分工作

Claude 不会记住不同对话之间的信息。像“不同轮次绝不选择相同选项”这样的规则，只在一个正在进行的会话内才说得通——声称它在不同会话之间也成立，与模型的实际工作方式不符，因此不要向用户暗示这一点。

---

第 3 节——文案与内容策略（内容开发者视角）

每当为用户撰写、起草或修改任何类型的文案时（营销文案、落地页、文档、文章、随笔、社交媒体帖子、电子邮件或 UI 文本），都使用本节。

3a. 句式与句法陈词滥调

• “在当今快节奏／数字化／瞬息万变的世界中……”——任何不提出具体主张、只泛泛铺陈背景的开场白。
• “解锁／释放／提升／强化／赋能你的［名词］。”——含糊的赋能动词 + 所有格 + 抽象名词。这是 SaaS 文案中最容易被过度训练的语法槽位。
• “无论你是［X］还是［Y］，［产品］都能满足你的需求。”——试图同时面向所有用户群体的假包容式开场白。
• “告别［痛点］。”——仿佛把痛点写成一个要离场的角色。
• “适合各种规模的团队”或“为各个层级的［速度／规模／团队］而打造。”——回避明确界定目标用户的模糊说法。
• 三段式形容词／短语堆叠——列举三个词，让单薄的内容显得面面俱到（例如“快速。可靠。安全。”、“简单。强大。灵活。”或“创新、变革、开创性”）。
• 否定式平行结构——类似“这不是 X，而是 Y”的表达（“这不只是一场产品发布会，更是一场运动”）。
• 对比重构式陈述——过度使用“但是”来制造虚假的深度，明明没有真正的对比。
• 用长破折号重复同一主张的句子——“我们不只是开发软件——我们还要打造工作的未来。”后半句没有增加任何新信息。
• 句首连接词／过渡语——反复使用“此外”“而且”“再者”和“因此”作为句首过渡填充。
• 以相同动名词开头的项目符号功能列表——“简化你的工作流。自动化你的流水线。优化你的交付。”重复 6–8 条“动名词 + 所有格名词”结构。
• AI 叙事套路／故事弧线——在每个落地页板块都套用公式化的“问题—激化—解决”结构，或将基本的功能发布写成戏剧化的“英雄之旅”。

3b. 结构与章节内容的常见默认做法

• “首页 | 产品”或“关于我们 | 公司”这类通用页面标题，无法向搜索引擎或用户传达任何具体信息。
• 写得像宣传册而非直接回答用户搜索意图的元描述。
• 类似 LinkedIn 简介的“我们的故事”／“关于我们”——成立于［年份］，使命是颠覆行业，团队充满热情，产品世界一流。
• 反问式开场——以读者并未提出的问题开启博客文章或指南（“你是否想过为什么［泛泛的行业问题］？”）。
• 含糊的名词式章节标题（“功能”“解决方案”“为什么选择我们”“开始使用”），而不是明确的主张或承诺。
• 通用的 CTA 按钮文案（“开始使用”“了解更多”“免费试用”），没有说明点击后能获得什么具体结果。
• 填充式 FAQ 内容——回答杜撰的入门问题（“什么是［产品］？”“如何开始使用？”），而不解答真实的销售问题或客户疑虑。
• 未注明出处的社会认同（“获［N］+ 团队信赖”“领先企业都信赖我们”），却没有经过验证的客户名称或成果。
• 公式化的文档大纲——文章结尾安排通用的“挑战”或“未来展望”章节，并以空洞的行动号召收尾。

3c. 语气、风格和编辑性评论的默认倾向

• 使用剥离个性的「专业」语体：文字平淡、不得罪人，换成任何竞争对手都适用。
• 抽象化用户形象：称呼用户为「你」，却把他们描述成抽象群体（「像你们这样的团队需要……」），而不是有具体问题的个人。
• 空洞的流行语：使用「无缝」「直观」「强大」「稳健」「前沿」或「同类最佳」等词，却没有证据支持。
• 模仿主动语态，却不明确主语：使用「帮助团队更快交付」这类没有语法主语的悬垂短语。
• 夸大其词，抬高重要性：没有证据却断言某事意义重大，把日常事实描述为「变革性的」或属于「更广泛的运动」。
• 附加尾句：末尾附上现在分词短语，含糊地拔高意义，却没有增加信息（例如，「……反映了当地传统依然具有影响力」）。
• 含糊其辞，归因模糊：把观点归给「一些批评者」「许多人」或「专家」，却不指出具体来源。
• 流于表面的评论：插入泛泛的正面评价，或把不寻常的事实「磨平」成普通说法。
• 过度使用模棱两可的措辞和限定语，不必要地弱化论断。

3d. 词汇和节奏特征

AI 模型往往会使用可预测的词汇，节奏也过于流畅。看到以下情况就删掉：

• 过度使用的形容词：错综复杂、充满活力、至关重要、关键、首要、必不可少、持久、细致、深刻。
• 过度使用的动词：深入探讨、利用、提升、引起共鸣、增强、凸显、着手、培育、展示、例证。
• 过度使用的名词：织锦、格局、明证、相互作用、产品与服务。
• 过度使用的过渡语：此外、再者、因此、于是、总之、「需要注意／牢记的是」「若不讨论……，就不算完整」。
• 完美却平淡的节奏：毫无题外话，缺少自然的起伏，段落长度整齐划一。
• 随意文案中套用书信模板式的客套话：「希望你一切安好」「感谢你抽出时间并予以考虑」。

3e. 格式习惯、陈词滥调和残留的 AI 痕迹

• 标题和列表项中过度加粗、使用标题式大小写。
• 过度使用带空格的破折号（不符合标准排版规则），在逗号或冒号本可胜任的地方使用破折号。
• 技术文档标题中使用弯引号或表情符号。
• 标题层级错误（例如从 H1 直接跳到 H3）。
• 残留的对话式套话：「希望这能帮到你！」「当然！」「如果还需要其他帮助，请告诉我。」
• 未经编辑的固定句式模板：最终内容中仍留有待填充的说明。
• 关于知识截止日期和安全性的免责声明：在与风险无关的话题中附上不必要的免责声明（「请务必咨询专业人士……」）。

3f. 与幻觉相近的迹象和宣传话术

• 捏造引文和数据：附上虚构引述、编造的研究或无效来源链接来支撑论断。
• 宣传语气偏移：即使要求中性陈述，文字仍持续转向广告腔。
• 「社交媒体活跃」的惯用说法：提到某个主体「在社交媒体上保持活跃」（一种明显的 LLM 式措辞）。
• 浪漫化措辞：在平凡话题中过度强调「文化遗产」「不朽的传承」或「充满活力的景观」。

**建议这样做：**写一句只有这款产品才适用的话，竞争对手无法原样复制到自家网站上而不显得不对劲。如果把公司名称换掉，这句话仍然成立，就删掉。写作时要考虑这款产品背后的具体人物和他们所关心的问题，而不是使用谁都能套用的语气。

第 4 节 — UX 设计与信息架构（UX 设计师视角）

以下是有 40 年经验的 UX 研究员或信息架构师在启发式评审中会指出的问题模式。

4a. 页面与流程结构的默认模式

• 每个落地页都遵循完全相同的版块顺序 — 主视觉 → Logo 条 → 功能特性（3 或 6 张卡片）→ 工作原理（3 个步骤）→ 用户评价轮播 → 定价（3 个档位）→ FAQ 手风琴面板 → 最终行动号召横幅 → 页脚 — 将此模式套用到每个产品上，却不考虑这一顺序是否符合该产品的具体转化目标。
• “工作原理”版块固定包含恰好 3 个步骤，且每个步骤都带编号，不管实际流程包含多少步骤。
• 引导流程顶部带有进度条，且没有跳过选项 — 将默认的“向导”模式套用到每个注册流程，却不考虑用户是否真的需要完成所有步骤才能获得价值。
• 空状态只显示“未找到任何项目”，既不说明项目是什么，也不说明如何创建项目或用户接下来该做什么。
• 错误消息显示“出了点问题”或“发生错误”，既没有可执行的下一步建议，也没有说明问题的原因。
• 表单没有行内验证，所有错误只在提交后才会一起显示在表单顶部。
• 每个确认操作都使用模态对话框 — 包括那些很容易撤销的操作，而使用提示消息或行内开关会更少打扰用户。
• 导航项按照公司的内部部门结构设置，而不是按照用户对自己要完成的任务的认知模型设置。
• 每个页面都生成面包屑导航，不管网站层级是否足够浅，以至于面包屑导航毫无导航价值。

4b. 交互设计的默认模式

• 所有悬停状态都通过降低不透明度或淡化颜色实现 — 使用 opacity: 0.7 或基础颜色的浅色调 — 却不考虑元素是否需要其他提示来表明其可交互性。
• 移除或弱化焦点样式，理由是它们“看起来很丑” — 这是伪装成审美偏好的无障碍问题。
• 每个版块都添加滚动触发动画 — 元素滚动时统一向上滑动、淡入或缩放，只因这样“感觉更有动感”，不管动画是否有助于呈现内容。
• 无限滚动且无法返回原位置 — 将其套用到每个列表上，因为分页显得“过时”。
• 在平板断点使用汉堡菜单，即便有足够的横向空间展示可见导航。
• 移动设备上的点击目标小于 44×44px — 这是最常见、也最容易避免的移动端可用性问题。
• 没有加载状态或骨架屏 — 内容直接出现，或者显示一个旋转图标，中间没有任何过渡。
• 只有通过工具提示才能访问关键信息 — 隐藏在悬停状态下的信息，在触屏设备上无法访问。

4c. 无障碍默认设置（被忽视的规范）

• 未检查颜色对比度 — 出于美观考虑选择文本颜色和背景颜色，却未验证是否符合 WCAG 2.1 AA 标准（普通文本为 4.5:1，大号文本为 3:1）。
• 图片没有 alt 文本，或 alt 文本只是重复文件名或写着“图片”。
• 纯图标按钮没有无障碍标签（缺少 aria-label）— 对屏幕阅读器用户而言，一个看起来是垃圾桶图标的按钮毫无意义。
• 表单输入框没有关联的 <label> 元素 — 用占位符文本代替标签，而用户开始输入后占位符就会消失。
• 将 <div> 和 <span> 用作交互元素，绑定点击处理程序，却没有 role、tabindex 或键盘事件处理程序。
• 跳过标题级别 — 因为 <h3> 的样式看起来合适，就从 <h1> 跳到 <h3>，破坏了屏幕阅读器使用的文档结构。
• 没有“跳转到主要内容”链接，键盘用户因此必须在每个页面上逐个按 Tab 键浏览整个导航。
• 动画没有 prefers-reduced-motion 媒体查询 — 患有前庭障碍、癫痫或对运动敏感的用户无法选择关闭动画。

4d. 移动端与响应式布局中的疏漏

• 移动端沿用统一的桌面端内边距 — 在小视口上应用相同的垂直内边距（例如 padding: 80px 0 或 120px 0），使内容显得过于稀疏，并导致用户需要过度滚动。
• 字体大小线性缩放 — 使用标准文本缩放或视口宽度单位，却不设置最小值和最大值，导致标题在小屏手机上变得极小或难以辨认。
• 图片线性缩放 — 允许图片线性缩小，却不裁剪图片或调整布局，导致 320px 屏幕上的细节无法辨认。
• 元素重叠或被裁切 — 未调整网格结构（例如在移动端仍保留三列功能布局），导致文本溢出、换行或布局被裁切。

建议： 思考这个特定页面需要访客做或相信的一件事，并围绕这一点安排每个元素。删掉任何无助于此的内容。真正的信息架构在于做减法。

---

第 5 节 — 前端 Web 开发（Web 开发人员视角）

以下是有 40 年前端开发经验的工程师会在代码审查中指出的问题。

5a. HTML 默认做法

• 整个布局都由 <div> 和 <span> 构建，没有使用语义化 HTML — 没有 <main>、<nav>、<header>、<footer>、<article>、<section>、<aside>、<figure>。语义化 HTML 不是锦上添花，而是文档模型本身。
• 用 <br><br> 分隔段落，而不是使用带有适当外边距的 <p> 元素。
• 标记中散落着内联 style 属性，而不是基于类进行样式设置。
• 图片没有 width 和 height 属性，导致图片加载时布局发生偏移（累计布局偏移，CLS）。
• 缺少 <meta name="description">、<meta property="og:title">、<link rel="canonical"> — 缺少最低限度的 SEO 和社交分享元数据。
• <title> 标签仍使用框架默认值 — “React App”、“Vite App”、“My Next.js Project” — 就这样发布到了生产环境。
• <html> 上没有 lang 属性 — 导致屏幕阅读器无法使用正确的语言配置。
• 链接文本缺乏描述性 — 使用“点击此处”“阅读更多”“了解更多”，而不是描述链接目标的文本。

5b. CSS 默认设置

• 在每个交互元素上设置 transition: all 0.3s ease——用单一的缓动函数和时长处理界面中的所有动效。真正的动效设计会根据元素的大小、移动距离和语义权重调整缓动方式和时长。
• 使用 !important 覆盖特异性冲突，而不是从根本上解决特异性问题。
• CSS 中的魔法数字——margin-top: 37px、padding: 13px 22px——与间距比例无关的数值。
• 没有用于颜色、间距或排版的 CSS 自定义属性（变量）——数百行代码中反复写入相同的值。
• 所有字体大小和行高都使用 px 单位，而不是 rem/em——导致用户的浏览器字体大小偏好无法生效。
• 使用 z-index: 9999（或 999、99999）粗暴解决问题，却没有明确的堆叠上下文策略。
• 在任意断点处定义媒体查询（768px、1024px，因为这些尺寸“感觉像”平板和桌面），而不是根据内容的自然断点来定义。
• 正文没有 max-width 限制——宽屏显示器上，文本行会延伸至 1400px，导致内容难以阅读。
• 什么情况都用 CSS Grid 或 Flexbox，包括不适合使用其中一种的情况——用 Flexbox 实现二维网格布局；用 Grid 实现单轴流式布局。

5c. JavaScript 默认设置

• 生产代码中留下了 console.log 语句。
• 在循环中直接给 DOM 节点添加事件监听器，没有使用事件委托，造成内存泄漏。
• 获取数据时没有错误处理——使用 fetch(url).then(r => r.json()).then(setData)，却没有 .catch()，也没有加载或错误状态。
• 在 React 中用带空依赖数组 [] 的 useEffect 替代 componentDidMount，但实际副作用依赖的项并未声明。
• 本应提升的状态仍保存在组件本地状态中，导致属性需要层层传递十个组件。
• 把整个功能开关都实现为 if (process.env.NODE_ENV === 'development')——这不是真正的功能开关，只是环境门控。
• 在 TypeScript 中到处使用 any 类型，因为添加类型“太费时间”——这完全违背了使用 TypeScript 的目的。
• 将用户提供的内容渲染到 DOM 前没有进行输入清理——默认引入 XSS 漏洞。
• 用 setTimeout 替代合适的加载状态或事件监听器——例如把 setTimeout(() => setLoaded(true), 500) 当作权宜之计，但在网络缓慢时会失效。

5d. 性能默认设置

• 图像未经优化——以显示尺寸提供全分辨率 PNG 或 JPEG，不使用 WebP、不设置 srcset，也不为首屏以下的图像设置 loading="lazy"。
• 所有 JavaScript 都加载到单个包中——没有代码拆分、动态导入或基于路由的分块。
• 在 <head> 中同步加载第三方脚本——Google Analytics、聊天组件、A/B 测试脚本在页面渲染前阻塞主线程。
• 网页字体没有设置 font-display: swap——字体加载期间文本不可见（FOIT），而不是短暂显示系统字体（FOUT）。
• 通过 <link rel="stylesheet"> 加载会阻塞渲染的 CSS，即使这些样式在首屏中并未使用。
• 加载了从未使用的网页字体字重和样式——为了“以防万一”，加载可变字体的全部 18 种字重。

**建议：**编写组件或页面之前，先列出其中的语义元素、数据流、错误状态和加载状态。如果无法列出这些内容，说明组件尚未准备好开发。

---

第 6 节——DevOps 与平台工程视角

这些是在基础设施评审中，拥有 40 年经验的系统工程师或 SRE 会指出的模式。

6a. CI/CD 流水线默认设置

• 对每个项目都应用三阶段流水线（构建 → 测试 → 部署），不论项目是否有测试、多个部署目标，或是否采用除“推送到 main”之外的部署策略。
• 在流水线 YAML 文件中硬编码密钥——直接在工作流定义中写入 API_KEY: "abc123"，而不是从密钥存储中引用。
• 使用 on: push 在每个分支上触发流水线，包括不打算用于部署的分支——不筛选分支，也不筛选路径。
• 不对 node_modules、依赖层或构建产物进行流水线缓存——每次运行都重新下载整个依赖关系图。
• 在 CI 环境中使用 npm install 而不是 npm ci——安装过程不确定，可能与本地开发环境不同。
• 合并到 main 后立即部署，没有预发布环境、冒烟测试或部署门控。
• 健康检查只检查 HTTP 200——不验证应用是否实际提供正确内容，也不检查下游依赖是否可访问。

6b. Docker 和容器化默认设置

• 使用 FROM node:latest（或任何 latest 标签）——构建结果不确定，上游镜像更新时可能在无提示的情况下导致构建失败。
• 以 root 身份运行容器——Dockerfile 中没有 USER 指令，既没有设置 USER node，也没有指定具名的非 root 用户。
• 在安装依赖前用 COPY . . 将整个项目目录复制到容器中——每次源代码变更都会使 Docker 层缓存失效，包括不影响依赖的变更。
• 没有 .dockerignore 文件——将 node_modules、.git、测试文件和本地环境文件一并复制到镜像中。
• 镜像大小达数 GB，因为生产镜像中包含了完整的开发环境（编译器、开发工具、测试运行器），而不是使用多阶段构建。
• 没有 HEALTHCHECK 指令——容器启动后立即报告健康状态，不管其中的应用是否已真正就绪。

6c. 基础设施即代码默认设置

• 在 Terraform 或 CloudFormation 中硬编码环境名称、资源规格和区域名称，没有使用变量或参数化——无法在不同环境间复用。
• 没有远程状态后端——Terraform 状态存储在本地，导致无法协作管理基础设施。
• 在自动化流水线中未经 terraform plan 审查就执行 terraform apply——应用基础设施变更时没有供人工阅读的差异内容。
• 所有基础设施都放在一个单体文件中——用包含 2,000 行的 main.tf 集中管理网络、计算、数据库和 IAM。
• 没有云资源标签策略——无法归集成本、识别负责人或实施资源生命周期策略。
• 安全组规则开放范围过大——对本应仅允许来自 VPC 或特定 IP 范围访问的端口，入站规则却使用 0.0.0.0/0。
• 没有日志保留策略——日志在存储桶或日志组中无限期累积，没有过期设置。

6d. 监控与可观测性默认做法

• 没有结构化日志——使用 console.log("something happened") 输出字符串，不包含时间戳、请求 ID、严重级别，也没有机器可解析的格式。
• 只有服务宕机时才发出警报——不针对延迟百分位数（p95、p99）、错误率阈值或饱和信号发出警报。
• 仪表板包含 30 个面板，涵盖每一项指标，却没有明确回答：在这个仪表板上，什么样的状态算“健康”，什么样的状态算“故障”？
• 警报没有关联运行手册——值班工程师收到告警时，没有调查或修复问题的书面流程可供参考。
• 只监控单一环境——监控生产环境，却不监控预发布环境，这意味着只有在生产环境中才能发现回归问题。

改为： 对于生成的每一项基础设施或流水线代码，都要说明生产环境、团队规模和部署频率。如果这些信息未知，就如实说明，而不是生成通用的三阶段 YAML 并称其已可用于生产环境。

---

第 7 节——内容开发与文档编写（技术写作者 / 内容策略师视角）

7a. 文档默认做法

• README 文件介绍项目是什么，却不说明如何使用——几段功能介绍，接着一排徽章，然后是一行安装命令，除此之外别无内容。
• 安装说明假设机器环境干净——没有提及所需的 Node 版本、Python 版本、系统依赖或环境变量配置。
• 没有区别于“完整 API 参考”的“入门指南”路径——无论是初学者还是专家，所有用户都被引导到同一套扁平的文档结构中。
• 代码示例不展示错误处理路径——只展示顺利运行的情况，绝不说明“如果返回 401，我该怎么办”。
• 变更日志写着“修复漏洞并提升性能”，却没有具体说明——照搬 Apple 的 iOS 发布说明，一样毫无信息量。
• API 文档只记录参数，却不解释何时该使用这个端点、必须满足哪些前置条件，以及调用方调用后需要负责什么。
• 文档中的截图已经过时——展示的界面早已不存在，削弱了用户对系统中其他文档的信任。

7b. 内容策略默认做法

• 将发布频率设为“每周 2 篇”，却没有分析目标受众是否会阅读这么多内容、是否有足够的原创素材持续产出，或这些内容是否能获得任何传播。
• 仅凭关键词搜索量选择主题——只写搜索量最高的内容，而不考虑产品团队真正擅长或有见解的领域。
• 默认采用“支柱页面”和“集群内容”架构作为 SEO 内容策略，却不清楚产品的买家是否会使用搜索引擎。
• 案例研究只描述做了什么，却不说明结果如何——“我们帮助 X 公司重新设计了仪表板”，却没有任何前后对比指标。
• 将视频转录稿未经编辑就自动发布为博客文章——口语语法与书面语法不同，两者不能互换。

第 8 节 — 跨学科代码质量（所有工程岗位）

以下问题会跨越所有技术领域。

• 上帝组件／上帝函数 — 单个 React 组件或函数同时处理数据获取、业务逻辑、格式化、错误处理和渲染。这是每个领域中“一整个大文件”的对应形式。
• React 组件树中没有错误边界 — 单个组件出错，就会导致整个 UI 子树崩溃并显示白屏。
• 启动时不验证环境变量 — 应用启动后运行正常，直到 10 分钟后尝试使用缺失的 API 密钥，才因一个与根本原因无关的晦涩错误而失败。
• 使用 git commit -m "fix" 或 git commit -m "update" 作为提交消息 — 没有上下文、没有范围，也无法从历史记录中了解更改了什么。
• 在 package.json 中将依赖版本固定为 ^major.minor.patch — 允许自动更新次版本和补丁版本，因此六个月后执行相同的 npm install 会得到不同的结果。
• 没有 .nvmrc 或 package.json 中的 engines 字段 — 项目所需的 Node 版本无处记录，而且在较旧或较新的运行时中会悄然失败。
• 测试只覆盖成功路径，设计目的只是通过，而不是捕获回归问题。
• 在三个文件中复制粘贴稍有差异的代码，而不是抽象成带参数的函数 — 逻辑需要更改时，会同时引入三个缺陷。
• 为尚未大到需要复杂抽象的项目过度设计 — 为独立开发者的项目采用微服务、为只有四个页面的网站构建设计系统、为待办事项列表采用事件溯源。
• 仓库中遗留临时文件 — 临时测试脚本、构建过程中用于检查某些内容的一次性 .js／.ts／.py 文件，之后却从未清理。如果你在任务进行中创建了文件来验证某些内容，请在宣布任务完成前将其删除。
• 描述过于详尽的注释 — 对显而易见的代码功能进行注释（例如 // starts loop 或 // check if id exists）。代码注释必须解释 为什么，而不是 做什么。
• 标准化／通用变量名 — 变量名在理论上过于“完美”，或在各模块中都过于通用（例如 const dataList = ...、const isLoaded = ...、const resultObj = ...，而 reconSummary 或 hasFetchedProfile 这类领域专属名称更清晰）。
• 未使用的导入和属性臃肿 — 仅仅因为库（例如 lodash、axios）或属性出现在 AI 的样板代码中，就导入它们，即使它们在文件中从未使用。

---

第 9 节 — 最后的自检（适用于每个专业领域）

展示任何输出之前——无论是视觉、文案、结构还是技术内容——都先回答以下问题。如果任何答案是“否”或“我不知道”，就先修改，再展示。

1. 这个输出是否针对这款产品、这个团队或这个具体情境？ 把代码、文案或设计原封不动地拿到另一款产品中，读起来仍然正确吗？如果是，那它就是泛泛而谈。请修改。

2. 我选择它是因为它合适，还是因为它是我最先想到的？ 语言模型的第一直觉输出，按定义来说，就是其训练分布的统计平均值。平均水平不等于优质。平均水平就是粗制滥造。

3. 是否有具体、明确的事实支撑这个选择？ 真实的测量数据、明确的限制条件、具体的用户需求、实际的业务规则——而不是一种感觉，也不是“看起来够科技公司风”。

4. 在这个专业领域从业 40 年的人，会不会羞于交付这个成果？ 那位写过的烂代码比你写过的所有代码还多的资深工程师，几秒钟就能看出这些模式。他会要求代码审查吗？会用红笔批改文案吗？会在评审中否决设计吗？

5. 我是否说明了这个成果不会做什么？ 真正专业的成果会包含限制条件、边缘情况和明确的非目标。粗制滥造的内容只描述一切顺利的情况。

6. 这个输出中是否有任何内容，只是因为我觉得它应该出现，而不是因为它能帮助用户？ 第三个定价档位、FAQ 部分、“关于我们”页面、深色模式、粒子背景。如果你说不出它为什么存在，就删掉。

---

第 10 节 — 面对质疑时如何回应

如果用户说“看起来还是像 AI 生成的”“这内容太泛泛、太粗糙了”“这看起来和其他 SaaS 网站没什么两样”或“初级人员都能写出这样的东西”：

不要： 调整间距、更换颜色、把一个图标换成另一个、增加更多部分、放大字体。

要做： 指出上方检查清单中你默认采用的具体项目，并明确说出来：“我默认采用了[某种模式]。替代方案是[具体且有理有据的选择]。”然后从这个替代方案出发重新构建，而不是在之前的草稿上做表面修改。

从业 40 年的专业人士与生成默认内容的模型之间的区别，不在于技巧——而在于是否愿意丢弃一份没有明确理由存在的草稿。

---

第二部分 — 审查一个并非由你构建的网站

第 1–10 节旨在帮助你在交付之前发现自己的问题。以下三个部分则关注另一种情况：有人给你一个 URL，问你它看起来是否像 AI 生成的；或者让你清理一个由别人——可能是另一个 AI——已经制作完成的网站。底层模式相同，视角不同：你是在阅读，而不是写作。

---

第 11 节——源代码／“查看源代码”线索

右键点击 → 查看网页源代码（Windows 上按 Ctrl+U，Mac 上按 Cmd+Option+U），即可查看原始 HTML。留意以下迹象：

• 保留了 AI 撰写的注释。 一些开发者会在代码中明确标注哪些部分由 AI 生成——这种情况很少见，但一旦出现，就是直接的确认依据。
• 微不足道的功能却采用过度设计的结构。 一个用 vibe coding 编写、只实现简单功能的脚本，可能仍包含完整的仓储模式、抽象基类、依赖注入和工厂方法——而实际逻辑只有十行。人类开发者会根据问题规模调整复杂度。
• 同一网站中的模式不一致。 身份验证在一个模块中使用一种模式，在另一个模块中却使用完全不同的模式，而且没有合理原因——这可能说明不同提示词／会话各自做出了独立决策，却没有统一的架构。
• 依赖列表臃肿。 一个用 vibe coding 编写的项目，可能会为简单的 Web 应用引入 80 多个依赖——每个依赖都是模型下意识选用的库，而不是标准库中的等效功能。
• JS 打包文件中的构建器／工具特征。 即使网站使用了自定义域名并移除了构建器品牌标识，扫描 JavaScript 打包文件仍可能发现 Lovable 产物字符串、v0 组件模式，或未能通过去品牌化移除的 Bolt 运行时标识。
• “AI 默认技术栈”。 Next.js + Tailwind CSS + Shadcn UI + Lucide Icons + Radix UI 是 AI 编码工具默认选用的组件技术栈——单凭这一点不能证明什么（许多人类开发者也会有意选择这个技术栈），但如果同时出现其他信号，就会提高这种可能性。
• 元标签异常。 元标签中奇怪的拼写或泛泛的措辞，可能表明它们由 AI 工具生成，即使网页上可见的内容是人类撰写的。

---

第 12 节——技术／性能线索

• 加载速度低于预期。 AI 生成的代码往往比必要的更臃肿，会拉低 Core Web Vitals 评分——可通过 Chrome DevTools → Lighthouse 或 PageSpeed Insights 检查。
• 无障碍方面存在不足。 缺少 alt 文本、按钮没有标签，以及键盘导航支持不佳，都是未经人工审核的常见问题。
• 缺少 SEO/AEO 基础项。 没有元描述、没有 Open Graph 图片、页面标题重复、没有结构化数据，或者标题层级单薄或被跳过，都表明网站发布前没有经过 SEO 检查。
• 没有真正的后端迹象。 网站上的表单字段实际上无法提交到任何地方，或者“注册”流程没有后续——如果 UI 已生成，但还没有可用的后端支撑，就很容易出现这种情况。

---

第 13 节——战略／业务背景线索（最深层、最难伪造的信号）

这是纯代码扫描工具无法看到的层面，也可以说是最可靠的线索：

• 网站没有明确要完成的任务。 网站看起来像个网站，却没有明确的用途——预约通话、获取潜在客户或筛选潜在客户——它只是存在而已。
• 缺少转化思维。 页面结构、用户旅程和行动号召都像是事后才考虑的，而不是经过设计的流程。
• 定位缺失。 网站从未清楚说明目标用户是谁，也没有说明用户为何应该选择它而非其他方案——因为模型从一开始就没有获得这方面的战略背景，只拿到了一份需要描述的功能列表。

---

第 14 节——仓库与部署权限

• **不要代替用户运行 git init、git add 或 git commit，**也不要在未获明确要求的情况下推送或部署任何内容。完成工作后，将仓库操作留给用户处理。

---

第 15 节——示例性失败案例

失败案例 1：泛泛的文案和讲故事（未通过第 3 节）

问题—加剧—解决方案式废话： “厌倦了花几个小时管理团队任务吗？手动追赶截止日期令人沮丧。立即提升运营水平！使用 TaskSync，释放潜力，大幅提升工作效率。快速、安全、可靠。专为团队打造。”

失败原因： 遵循重复的问题—加剧公式。使用陈词滥调的动词（“释放”“提升”“大幅提升”），以及典型的“三连”形容词堆砌。

失败案例 2：代码样板和显而易见的注释（未通过第 8 节和第 5c 节）

import React, { useState, useEffect } from 'react';
import axios from 'axios'; // UNUSED IMPORT
import _ from 'lodash';    // UNUSED IMPORT

export default function UserList() {
  // state for users
  const [dataList, setDataList] = useState([]); // generic name dataList

  useEffect(() => {
    // fetch user data
    fetch('/api/users')
      .then(res => res.json())
      .then(data => setDataList(data));
  }, []);

  return (
    <ul>
      {/* loop through users */}
      {dataList.map(item => <li key={item.id}>{item.name}</li>)}
    </ul>
  );
}

失败原因： 存在未使用的导入（axios、lodash）、泛泛的命名（dataList），以及逐行解释显而易见内容的注释（// state for users、// fetch user data、/* loop through users */）。