ui-humanizer

UI Humanizer：消除界面上的 AI 感

为什么 AI 网站一眼就能认出来

模型会选择最可能的方案，所以每个视觉决策都会变成平均选择：适用于任何产品、任何受众、任何版块的方案。设计师则会针对某款产品和特定受众做选择，因此他们的选择各不相同，也更具体。这项技能中的每一种明显特征，都是平均选择的一种表现；暴露问题的是它们的组合：眉题 + 渐变标题 + 脉动标签 + 3 张带图标的卡片 = 模板。

这条讨论串带来了五点经验，以下内容都以此为指导：

1. 问题不在元素，而在默认设置。“人们会吐槽的一切，在某个时候都曾是好的 UI 实践”（@marp_sol）。在有明确理由的编辑类网站上使用眉题没问题。每个版块都用眉题就不行。
2. 用一种陈词滥调替换另一种，只会更糟。“和 AI 作对，试图让东西显得更人性化，几乎总会适得其反，最后做出来的东西反而更明显”（@lamarcke_）。去掉紫色，换成米色 + 衬线字体，只是换成了另一个默认方案（@Dan3pm 提到的 /frontend-design）。每次替换都必须源于内容，而不是为了“反其道而行”。
3. 技能本身救不了你，流程才行。“没有技能能救场，你得先定义设计系统［……］再提供参考”（@DavidMendonca01）。“不借助 AI 去思考设计，先画出来，认真想清楚网站应该是什么样，包括字体、布局、图片”（@greco_dev）。因此，这项技能是一套分阶段的流程，而不只是一份禁用清单。
4. **人来决策，AI 来执行。**有品位的人会把 AI 当作“车间设计师”，自己则是“监督者”（@gr33d1sg00d_）。涉及方向性决策时，要展示选项，让用户选择。
5. **功能优先。**对很多人来说，只要“效果好、适合场合”，其他都不重要（@h1ckzz、@geanjeorge）。绝不要为了降低 AI 感而损害可用性、性能、无障碍性或清晰度。

核心规则

每个视觉选择都必须有一个源自这个产品的理由：内容、受众、真实素材（照片、数据、产品、人物）或品牌。如果同一个选择同样适用于面包店网站、金融科技公司和 AI SaaS，那它就是默认方案。要么替换，要么说明理由。

3 秒测试（YC，经由 @junow0z）：访客看到首屏后，必须知道这家公司是做什么的。抽象的标题（“清晰决策更明智”“变革你的工作流”）无法做到这一点，还会暴露 AI 痕迹。

此技能的文件

按阶段阅读：

文件	阅读时机
references/tells.md	每次构建或审查时。完整目录：每种明显特征的识别方法、代码特征、AI 为什么会这样做、引用者、替换方案，以及何时可以保留。
references/referencias.md	阶段 3。如何通过 Chrome 在 Pinterest、Dribbble、Awwwards 等平台上寻找参考，如何提取每个参考中的要点，并将其转化为决策。
references/copy.md	UI 中包含文案时。会暴露 AI 痕迹的词语和文案结构（葡萄牙语和英语）。
references/casos.md	用于校准判断。讨论串中提到的 3 个真实网站，逐一拆解其中每种明显特征。
references/outros-formatos.md	文档、幻灯片、仪表板、应用、电子邮件。同样的特征也会出现在落地页以外的场景。
references/cobertura.md	映射这项技能中纳入 51 条评论的位置。
references/comentarios.md	原始评论，逐字收录。
scripts/audit.py	基于 grep 的检测器：python3 -I ~/.claude/skills/ui-humanizer/scripts/audit.py <arquivo-ou-pasta>

如果项目有自己的设计系统（令牌、品牌技能，例如 rti-ui、客户指南），应以它为准。这里只处理设计系统尚未规定部分的默认选择。

流程

从零开始创建时，使用所有阶段。审查现有内容时，直接进入阶段 6；如果审计发现问题属于结构性问题（SaaS 感、默认布局、没有图片），则返回阶段 1–4，因为这些问题无法靠替换 CSS 来解决。

阶段 0 · 分诊

• 是什么：落地页、机构网站、电商、登录后应用、仪表盘、文档、演示文稿？每种都有自己的惯例，而这些不是套路（登录后应用可以有侧边栏和卡片；仪表盘可以有 KPI 网格）。
• 有多重要：内部原型不需要完整经历第 3 阶段。品牌的公开网站则需要。
• 已经有什么：设计系统、品牌、照片、内容、旧网站。提出方案前先阅读。

阶段 1 · 简报（在动任何像素之前先写）

用几句话作答并展示给用户：

1. 这是什么、面向谁，以及用户会在页面上做什么。 面包店不是 SaaS（@eucaioba）。如果答案不是“订阅软件”，就禁止使用 SaaS 结构。
2. 用户需要在 3 秒内理解什么。 写下这句话。它将成为标题或主图。
3. 现有的真实素材。 照片、产品截图、数据、人像、地址、菜单、价格、真实评价。“缺少图片”是最常被提及的套路之一（@joaquimcassano、@vborotoo）。如果没有素材，就向用户索取。如果仍然没有，就使用明确的占位符（[门面照片]、[面板截图]）并说明情况。绝不要用图标卡片、渐变或通用插图来填补空白。
4. 必不可少的内容和可选内容。 删掉多余文字和凑数的版块（@vborotoo）。
5. 限制条件。 品牌、必需的颜色、无障碍、技术栈、期限。

阶段 2 · 编码前先起草（“不借助 AI 来画”）

编写组件之前，先用文字或 ASCII 线框图搭好骨架：有哪些版块、顺序如何、每个版块包含什么、只有这个网站才有的元素是什么（地图、巨幅产品照片、真实价格表、数据图表、菜单）。围绕它构建布局。

起草规则：

• 版块的顺序和大小取决于内容的重要性，而不是套用 hero → logos → features → 工作原理 → 评价 → 定价 → 常见问题 → CTA 的模板。
• 版块可以有不同的尺寸、宽度和对齐方式。不是所有内容都要居中。
• 不一定要有“工作原理”“为何选择”、功能网格、常见问题或最终 CTA。每个版块都必须有存在的理由。

把草稿展示给用户，并在继续前进行调整。这是修改成本最低的阶段。

阶段 3 · 参考案例

阅读 references/referencias.md 并遵循其中的要求。摘要：

• 先向用户征求参考案例（他们欣赏的网站、截图、Pinterest 画板）。这是最佳来源。
• 如果用户没有，就在浏览器中查找：Pinterest（筛选“少 AI”）、Dribbble、Siteinspire、Awwwards、Godly、Land-book、Lapa Ninja、One Page Love、Fonts In Use，以及同一行业的真实网站。
• 收集 6–12 个案例，剔除带有目录套路的案例（如今很多参考案例已经由 AI 生成），并为每个案例填写一份记录：布局、字体、颜色、图片、信息密度、令人难忘的细节。
• 向用户展示 2–3 个方向，每个方向包含 2–3 个参考案例并说明原因。由用户选择。
• 参考的是逻辑（如何组织内容、如何使用图片、采用何种对比），并融合 2–3 个案例。不要照搬任何人的布局或品牌。

第 4 阶段 · 最小化设计系统

根据选定的方向推导，而不是使用默认值：

• 字体排印： 选择 1–2 个有依据的字体家族（来自品牌、行业或参考）。字号层级要有真正的对比。不要用“默认字体 + 极简标题”（@Lukekw_），也不要用 10 种字体（@El_Sinisttro）。
• 颜色： 说明颜色的来源（建筑外观、包装、产品、行业、主图）。少量使用一种强调色。不要默认用 Tailwind 紫色（@Cirilorde），不要默认用渐变，也不要让每个元素都各用一种颜色。
• 形状： 采用小而一致的圆角层级。仅在有依据时使用胶囊形。统一边框和阴影规则，不要五花八门。
• 图标： 只用一套图标，或者不用。绝不要把 emoji 当作图标。
• 动效： 列出实际使用的少量动画，以及每个动画所表达的内容。其余保持静态。

将它们写成 tokens（CSS variables 或 Tailwind 配置），并应用到组件上，包括库中的组件（使用工厂主题的 shadcn 很显眼，@metalheadlost）。

第 5 阶段 · 构建

参照草稿和设计系统进行构建，并查阅 references/tells.md 和 references/copy.md。快速规则：

• 没有书面说明，绝不出现 A 类 tell。
• 只要有真实图片，首屏就必须使用。
• 只对能执行操作的元素添加悬停效果（@Fagner_Souza）。
• 动画只能用于解释状态变化。
• 文案必须包含具体事实：它是什么、适合谁、价格多少、在哪里，并使用用户提供的真实数字和名称。绝不虚构客户、数字、评价、logo 或奖项。

第 6 阶段 · 审核

1. 检测器： 对文件或文件夹运行 scripts/audit.py。它会查找 tell 的代码特征（眉题、渐变文字、侧边框、脉冲、emoji、紫色、玻璃质感、悬停效果、胶囊形、背景渐变、流行字体、模板文案）。这只是起点：逐一检查每项命中，有些是合理的。
2. 视觉检查： 如果可以，在 Chrome 中打开页面，并分别截取桌面端和移动端的顶部、中部和底部。许多 tell 只有渲染后才会显现：默认布局、千篇一律的卡片、缺少图片、SaaS 既视感、节奏雷同的各个版块、悬浮样机。
3. 目录： 对照 references/tells.md 检查每个 tell，先看严重的。A 类 tell 一出现就足以要求修改；B 类在与其他问题同时出现时需要重视；C 类只有在已经存在 A 或 B 类问题时才需要考虑。
4. 文案： 对照 references/copy.md 检查。长段落可结合 humanizer skill 一起处理。
5. 最终检查清单（如下）。

第 7 阶段 · 迭代

• 通过改变背后的设计决策来修正 tell，而不只是修改 CSS 类。如果整个版块都像模板，就重做这个版块。
• 再次运行检测器，并确认没有用一种陈词滥调替代另一种（紫色 → 米色、Inter → 斜体 Playfair、渐变 → 玻璃质感、emoji → 彩色方框图标）。
• 对审美选择有疑问时，并排展示 2 个版本并征求意见。

最终检查清单

1. 只看 hero，3 秒内能否看懂这家企业是做什么的？
2. 页面上是否有真实素材（照片、截图、数据、产品），尤其是首屏？
3. 结构是否符合网站类型，还是默认做成了 SaaS 风格？
4. 是否还剩下 A 类 tell？保留下来的 B 类 tell 是否都有依据？
5. 我是否只是用一种陈词滥调替换了另一种？
6. 是否有悬停效果、cursor pointer 或动画被用于不起作用的元素？
7. 文案中是否包含 copy.md 列出的用词？
8. 我是否虚构了数字、客户、评价、logo 或奖项？如果是，请删除或标记为 placeholder。
9. 我是否为了显得不那么像 AI 而损害了易用性、对比度、性能或移动端体验？如果是，请恢复。
10. 用户是否看过并批准了方向决策（草稿、参考、设计系统）？

应返回的内容

• **构建时：**需求简报、草稿、带参考的方向、设计系统，然后是代码。草稿完成后和参考内容完成后，暂停并等待用户批准，除非用户要求直接继续。
• **审查时：**列出发现的所有 tell，按严重程度从高到低排列，并附上 文件:行号 或截图、每项建议的替换内容，以及有意保留的内容和原因。如果用户只要求审查，请勿编辑。
• **修复时：**说明所做的更改、检测器修复前后的结果，以及可能的话提供截图。