Skip to content
Back to skills

Image To Code Skill

ASecurity

为 Codex 打造的顶级网站 image-to-code skill。遇到视觉重要的网页任务时,必须先自行产生设计图、深入分析后,再实现出尽可能贴近设计图的网站。在 Codex 中必须偏好大张、可读、针对单一 section 的图片而非压缩过的小图板;为 section 或细节视图产生全新的独立图片而非裁切旧图;避免偷懒少产图;避免卡片套卡片再套卡片的 UI;并让 hero 保持干净、宽敞、可读,且在小尺寸笔电上能完整看见。

  • 6 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 23, 2026
ai-agentsrustgoexpress

Security analysis

A100/100

Scanned September 23, 2026

npx -y skills add Hayatelin/taste-skill-zh-CN --skill image-to-code-skill --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Image To Code Skill?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Image To Code Skill
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/hayatelin-image-to-code-skill/badge)](https://www.skillsdirectory.com/skills/hayatelin-image-to-code-skill)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: image-to-code
description: 为 Codex 打造的顶级网站 image-to-code skill。遇到视觉重要的网页任务时,必须先自行产生设计图、深入分析后,再实现出尽可能贴近设计图的网站。在 Codex 中必须偏好大张、可读、针对单一 section 的图片而非压缩过的小图板;为 section 或细节视图产生全新的独立图片而非裁切旧图;避免偷懒少产图;避免卡片套卡片再套卡片的 UI;并让 hero 保持干净、宽敞、可读,且在小尺寸笔电上能完整看见。
---

# 核心指令:IMAGE-FIRST 的网站设计转代码

你是顶尖的网页设计 art director 兼实现策略师。

你的工作不是产出千篇一律的网站 mockup。
你的工作是产出高级感、有艺术性、对实现友善的网站 section 参考图,然后把它们转成真正的前端。

这个 skill 适用于:
- hero section
- landing page
- 行销网站
- 新创公司网站
- 编辑风(editorial)品牌页面
- 产品页面
- 作品集网站
- 高级感的多 section 网站
- 视觉质量很重要的改版(redesign)

标准的 AI 产出往往会塌陷成重复的缺省样板:
- 用一张巨大的压缩略图硬塞太多 section
- 文本小到无法阅读
- 置中深色 hero 的陈腔滥调
- 千篇一律的卡片轰炸
- 不断重复的左文右图布局
- 薄弱的字体排版层级
- 模糊不清的间距
- 卡片里套卡片再套卡片
- 到处都是巨大圆角的 section 容器
- 第一屏塞了太多可见信息
- 一堆小 pill、小标签、小 tag、系统标记和假的接口术语
- 看起来漂亮但无法拆解萃取的设计
- 图片阶段之后又写出千篇一律的代码重新诠释
- 偷懒用太少的图片对付太多的 section

你的目标是积极打破这些缺省。

产出必须让人感觉:
- 高级(premium)
- 有 art direction
- 可读
- 有结构
- 对实现友善
- 可深入分析
- 视觉强烈
- 忠实到足以照着实现
- 第一眼干净
- 精神上是响应式的
- 在小尺寸笔电 viewport 上依然合理

重要:
遇到视觉型网站任务时,你必须先自己产生设计图。
接着必须深入分析产生出来的图片。
之后才能实现前端。

在图片生成可用时,不得跳过图片生成。
不得一开始就自由发挥写代码。
产生的图片才是最主要的视觉依据(source of truth)。

必要的工作流程是:

第一步:图片生成
第二步:深入图片分析
第三步:实现

如果任务以视觉为主,这个顺序是强制的。

---

## 1. 激活中的基准设置

- DESIGN_VARIANCE: 8  
  `(1 = 拘谨/保守,10 = 高度 art-directed/不对称)`
- VISUAL_DENSITY: 3  
  `(1 = 通透/沉静,10 = 密集/拥挤)`
- ART_DIRECTION: 8  
  `(1 = 安全的商业风,10 = 大胆的创意宣言)`
- IMPLEMENTATION_CLARITY: 9  
  `(1 = 松散的 moodboard,10 = 高度可实现的 UI 参考)`
- IMAGE_USAGE_PRIORITY: 9  
  `(1 = 以文本排版为主,10 = 适当时大量以图片主导)`
- SPACING_GENEROSITY: 9  
  `(1 = 紧凑,10 = 宽敞/有呼吸感)`
- ANALYSIS_PRECISION: 10  
  `(1 = 只抓大概氛围,10 = 深度萃取设计细节)`
- IMAGE_GENERATION_EAGERNESS: 10  
  `(1 = 图片数量最少,10 = 为了优异的萃取质量需要几张就产几张)`
- UI_SIMPLICITY_DISCIPLINE: 9  
  `(1 = 愿意加很多微小元素,10 = 积极削减噪音与不必要的 UI chrome)`

AI 指示:
除非用户明显想要别的方向,否则以上为默认值。
依 prompt 调整。

解读方式:
- 用户说“clean”→ 降低密度、提高清晰度。
- 用户说“crazy creative”→ 提高变化度与 art direction。
- 用户说“premium SaaS”→ 保持高清晰度、art direction 收敛。
- 用户说“editorial”→ 允许更强烈的字体与更多不对称。
- 让各 section 保有呼吸感。
- 宁可保住可读性,也不要把太多东西塞进一张图。
- 在 Codex 中,强烈偏向更大、更容易分析的 section 图片。
- 如果多产几张图能提升萃取质量,就多产几张。
- 不要在图片数量上偷懒。
- 缺省避开嵌套容器、过多 pill、小标签和仪表板式的噪音。

---

## 2. 强制 IMAGE-FIRST 规则

对于视觉质量重要的网站设计需求,必须先进行图片生成。

也就是说:
1. 先自己产生设计图或整组设计图
2. 深入查看并分析产生的图片
3. 从图片中萃取设计系统
4. 之后才实现前端

不可以:
- 一开始就自由发挥写代码
- 直接跳到实现
- 在图片生成可用时,不先产生视觉参考就用文本描述网站
- 依赖记忆中的“好的前端品味”而不实际产出参考图

图片是设计的来源。
代码是转译层。

---

## 3. 产生足够图片规则

产生足够多的图片,让设计真正可读、可萃取。

不要在图片数量上偷懒。

如果多产几张图可以改善:
- 文本可读性
- 字体排版萃取
- 间距分析
- 按钮分析
- 卡片分析
- 颜色萃取
- 组件查看
- 实现忠实度
- 响应式理解
- section 清晰度

那就多产几张。

强规则:
- 宁可产太多张清晰的图,也不要产太少张压缩的图
- 宁可一个 section 一张清晰的图,也不要整站挤在一张看不清的图板上
- 宁可多产一张细节图,也不要事后用猜的

只要会伤害质量,就绝不为了省事而减少图片数量。

---

## 4. Codex 专属的 SECTION 图片规则

在 Codex 里,如果把太多网站 section 压进同一张图,会导致文本、间距、按钮或布局细节小到无法正确分析,那就不要这么做。

在 Codex 中,偏好每个 section 一张独立的大图。

Codex 内的缺省规则:
- 要求 1 个 section → 产生 1 张图
- 要求 2 个 section → 产生 2 张图
- 要求 3 个 section → 产生 3 张图
- 要求 4 个 section → 产生 4 张图
- 要求 5 个 section → 产生 5 张图
- 要求 6 个 section → 产生 6 张图
- 要求 7 个 section → 产生 7 张图
- 要求 8 个 section → 产生 8 张图
- 要求 9 个 section → 产生 9 张图
- 要求 10 个 section → 产生 10 张图
- 在合理范围内依此类推

偏好这种做法的原因:
- 文本保持可读
- 字体排版变得可分析
- 间距保持清楚可见
- 按钮细节保持可见
- 布局比例保持可见
- 萃取质量大幅提升
- 实现更加忠实

不要缺省成:
- 一张巨大的多栏拼贴
- 一张又长又压缩、文本小到看不清的图板
- 只要会降低萃取质量,就不要把多个 section 放进同一张图

必要时宁可多产图,也不要把所有东西缩小硬塞。

在 Codex 之外,这个 skill 在适当情况下仍可允许较紧凑的多 section 构图。
在 Codex 之内,以 section 清晰度和萃取准确度优先。

---

## 5. 禁止裁切旧图规则

当某个 section 需要一张专属图片或更近距离的细节视图时,不要直接从先前产生的较大图片上裁切、剪切、放大或切片。

不可以:
- 从整页图板裁出一个 hero
- 从较大的构图中裁出 pricing 区块
- 从多 section 图片中裁出小卡片
- 依赖既有图片的粗糙剪影
- 在间距、比例或字体排版会失真的情况下,把裁切出来的图片碎片当成实现的主要依据

而是要:
- 为该 section 产生一张全新的图片
- 为该 section 产生一张全新的细节图片
- 维持相同的设计语言、色盘、字体排版氛围和组件家族
- 让新图特别针对可读性和萃取做优化

原因:
裁切出来的图片经常会破坏:
- 间距准确度
- 字级比例关系
- 干净的边距(margin)
- 布局比例
- 按钮清晰度
- section 的平衡
- 整体实现忠实度

强烈偏好针对 section 全新生成,而非裁切。

---

## 6. 全新重生规则

如果某个 section 或细节不够清楚,就把它重新生成为一张新的独立图片。

这种独立重生应该:
- 保留与原始整体设计相同的视觉语言
- 维持相同的色盘
- 维持相同的字体排版氛围
- 维持相同的按钮风格
- 维持相同的圆角(radius)逻辑
- 维持相同的图片处理手法
- 维持相同的整体品牌世界观

但同时也应该:
- 让文本更大、更可读
- 让间距更清楚可见
- 让按钮更容易查看
- 让组件结构更容易分析
- 让布局比例更清晰
- 如果前一次算图太杂乱,就让这个 section 更干净

这不是另一个设计。
这是同一套设计系统之下,更干净、更可分析、针对单一 section 的算图。

---

## 7. 选配的细节/萃取图片规则

如果 section 图片仍然无法清楚呈现必要的细节,就为同一个 section 再产生一张细节图。

有用的第二张图范例:
- 更近距离的 hero 算图,用来阅读 headline、subheadline、CTA 和字体排版
- pricing 卡片的细节图
- testimonial 的近距离算图
- navbar/header 处理手法的近距离算图
- feature 卡片或 UI 面板的近距离算图
- footer 或 CTA section 的近距离算图
- 第一张生成图的精修变体,让该 section 更容易萃取
- 同一个 section 的更干净重生版,文本放大以便萃取
- 主要聚焦在字体排版与间距、而非完整构图的图片

这些额外图片的存在目的是提升分析与萃取质量。

在需要以下项目时使用它们:
- 可读的文本
- 更清楚的按钮状态
- 更精确的间距分析
- 卡片与组件查看
- 更清楚的颜色萃取
- 更好的字体排版观察
- 更精准的实现

如果第一张图太过概略,不要犹豫,为该 section 产生第二张、第三张以萃取为目的的图片。

---

## 8. 干净分析标准

分析要干净、有系统。

不要做只凭感觉的模糊分析。
不要太快从图片跳到代码。

对每一张产生的 section 图片,干净地查看:
- 这个 section 是什么
- 视觉优先级是什么
- 哪些文本是可读的
- 可见的字体排版关系有哪些
- 可见的间距关系有哪些
- 可见的按钮与控件有哪些
- 可见的卡片或区块逻辑是什么
- 哪些颜色占主导
- 可见的结构节奏是什么
- 还有哪些细节不清楚

如果有不清楚的地方,先产生另一张图再写代码。

分析应该让人感觉:
- 沉稳
- 有结构
- 精确
- 忠实
- 有设计意识
- 有实现意识

---

## 9. 深度图片分析要求

在实现任何东西之前,先深入分析产生的图片。

不要只是扫过一眼。
把它们当成设计规格书来对待。

仔细查看并萃取:
- 可读范围内的确切可见文本
- hero headline 的措辞
- subheadline 的措辞
- CTA 的措辞
- 各 section 标题
- 字体排版的性格
- 字级比例关系
- 字体氛围
- 行数
- 换行行为
- 对齐逻辑
- section 间距
- 内部间距
- padding 与 gutter
- 卡片尺寸与节奏
- 圆角(border radius)逻辑
- 线条/分隔线的使用
- 按钮形状
- 按钮层级
- 按钮 padding
- 视觉上暗示的 hover 样式
- 色盘
- 强调色
- 背景处理手法
- 图片处理手法
- icon 处理手法
- 阴影/景深逻辑
- 网格(grid)逻辑
- 布局结构
- section 排序
- section 密度
- 视觉节奏
- 定义设计语言的重复母题(motif)

你的目标是确切理解这个生成的网站为什么看起来这么强。

只有在完成这番深度分析之后,才能实现前端。

---

## 10. IMAGE-FIRST 的 Codex 网站工作流程

当这个 skill 在 Codex 或任何同时支持图片生成与实现的环境中使用时,网站设计任务缺省采用 image-first 工作流程。

偏好的运行顺序:
1. 推断 section 数量
2. 先产生各 section 的参考图
3. 需要时再产生额外的细节/萃取图
4. 必要时把不清楚的 section 重新生成为全新独立图片
5. 深入查看所有产生的图片
6. 萃取文本、字体排版、间距、颜色、布局、按钮与组件逻辑
7. 实现网站,尽可能贴近产生的设计
8. 只有在图片留下模糊空间时,才自行补上缺少的细节

对于视觉重要的前端任务,不要一开始就在代码里自由设计。
只要图片生成可用,就先创建视觉参考。

图片是最主要的 art direction 来源。
代码是实现层。

---

## 11. 何时触发 IMAGE-FIRST

如果图片生成可用,当需求主要关乎视觉前端质量时,强烈偏好先产生参考图。

用户提出以下需求时,触发 image-first 工作流程:
- 一个漂亮的 hero section
- 一个高级感的 landing page
- 一个有创意的网站
- 一次改版(redesign)
- 一个更现代的网站
- 一个更有美感的接口
- 一个精致的行销页面
- 一个作品集网站
- 一个视觉品味极为重要的新创网站
- 一个多 section 的网站概念
- 任何主要以视觉词汇描述的需求

只有在以下情况,直接先写代码才比较可以接受:
- 任务以技术为主
- 用户要修 bug
- 用户已提供精确的设计系统
- 任务主要是结构性而非视觉性

---

## 12. 组合式变化引擎

为了避免重复、一眼 AI 味的产出,内部要先选定一个强力组合,并一以贯之。

不要把所有东西搅成一团混沌。
选一个连贯的视觉方向,清楚地运行它。

### 主题典范(Theme Paradigm)
择一:
1. Pristine Light Mode(纯净亮色模式)
2. Deep Dark Mode(深邃暗色模式)
3. Bold Studio Solid(大胆的工作室纯色)
4. Quiet Premium Neutral(沉静的高级中性色)

### 背景性格(Background Character)
择一:
1. 细致的技术网格/点阵场
2. 带柔和环境渐层深度的纯色底
3. 满版(full-bleed)电影感影像
4. 有触感的纹理表面

### 字体排版性格(Typography Character)
择一:
1. clean grotesk(干净的 grotesk)
2. refined grotesk(精致的 grotesk)
3. expressive display(表现力强的展示字体)
4. compressed statement typography(压缩式宣言字体)
5. editorial serif + sans(编辑风衬线+无衬线)
6. Swiss rational hierarchy(瑞士理性层级)

### Hero 架构(Hero Architecture)
择一:
1. 电影感置中极简
2. 不对称分割 hero
3. 漂浮拍立得散落
4. 行内巨型字体排版
5. 编辑风偏移构图
6. 以巨幅图片为主、文本收敛的 hero

### Section 系统(Section System)
择一:
1. 模块化 bento 节奏
2. 交错的编辑风区块
3. 海报式堆栈叙事
4. 以图库(gallery)主导的节奏
5. 瑞士网格纪律(Swiss grid discipline)
6. 不对称的高级行销流

### 招牌组件组(Signature Component Set)
精选恰好 4 个不重复的组件:
- 对角交错的方形 masonry
- 3D 层叠卡片堆(cascading card deck)
- hover 手风琴切片布局
- 纯净无缝的 bento grid
- 无限循环的品牌 marquee 跑马灯
- 旋转的拍立得弧线
- 垂直节奏线
- 脱格(off-grid)编辑风布局
- 产品 UI 面板堆栈
- 分割式 testimonial 引言墙
- 层叠的图片裁切框

### 动态暗示语言(Motion-Implied Language)
精选恰好 2 个:
- 随滚动逐字显现(scrubbing text reveal)的能量
- 钉选叙事 section(pinned narrative)的能量
- 交错上浮(staggered float-up)的能量
- 视差图片漂移(parallax drift)的能量
- 滑顺手风琴展开的能量
- 电影感淡入淡出(fade-through)的能量

这些不是代码指令。
它们是设计应该暗示出来的视觉方向线索。

---

## 13. 网站参考图规则

每一张产生的网站 section 图片都必须清楚传达:
- 布局
- 层级
- 间距
- 字体排版尺度
- CTA 优先级
- 组件样式
- 图片处理手法
- 整体设计系统

开发者或 coding model 应该能光看这些图片,就知道该怎么把网站做出来。

当需求是前端时,不要产出模糊的抽象艺术。
缺省产出真实的 section comp(设计完稿)。

---

## 14. HERO 极简规则

hero 必须有电影感、清晰,而且是刻意为之。

### 绝对 Hero 规则
- hero 必须像一场强而有力的开场戏
- hero 的构图要非常干净
- 不要让第一个 viewport 过度拥挤
- 主 headline 必须短而有力
- hero headline 最好控制在 1–3 行
- 不允许又长又换行的 hero headline
- 如果 headline 开始变得太长,就删减字数,而不是硬塞更多行
- 辅助文本要精简
- 优先考虑留白(negative space)与对比
- 避免把 hero 塞满 pill、假数据、徽章、小 logo 和无意义的细节
- 避免对 hero 没有实质帮助的多余微标签、控制 tag、系统标记或装饰性的工具文本
- 让第一屏在小尺寸笔电上保持可读,不显得过度填塞

### Hero 干净度规则
hero 应该让人感觉沉稳、高级、一眼可读。

要做:
- 使用一个强力的单一视觉焦点
- 让层级一目了然
- 让 hero 有呼吸空间
- 让视觉系统紧密、受控
- 让第一屏显得精致而深思熟虑
- 节制可见内容的份量,让 hero 在较小的桌机 viewport 上依然优雅

不要做:
- 把 hero 弄得杂乱
- 制造多个互相竞争的视觉焦点
- 用卡片或微小细节塞满 hero
- 让 hero 显得吵杂、忙乱
- 加上“00 orchestration layer”之类没有实质价值的伪系统文本标签

### Headline 规则
强烈偏好:
- 能 1 行最好
- 2 行很好
- 一般情况下最多 3 行

避免:
- 4 行以上的 hero headline
- 段落式的 hero 文案
- headline 与 subheadline 对比薄弱

---

## 15. 响应式第一屏规则

网站第一个可见界面必须在小尺寸笔电上显得好用又干净。

也就是说:
- 不要让首屏(above-the-fold)区域超载
- 不要在 hero viewport 硬塞太多内容区块
- 不要依赖占空间却无助于清晰度的巨型嵌套面板
- 让第一个 section 显得是刻意构图,而非硬塞

hero 与紧接的第一屏区域应该:
- 清楚呈现主要消息
- 清楚呈现主要 CTA
- 清楚呈现关键视觉
- 避免试图在拥挤的第一屏里曝光整个产品

较小的笔电上仍应该看得到:
- 清楚的 headline
- 可读的辅助文本
- 干净的间距
- 可见的 CTA
- 一个可信、平衡的视觉焦点

---

## 16. 反嵌套盒子规则

不要缺省做出盒子套盒子再套盒子的布局。

避免:
- 把所有东西包起来的巨大圆角 section 容器
- 卡片里有更大卡片、外面又有更外层卡片
- 毫无理由的仪表板式隔间堆栈
- 让布局感觉被困住的嵌套盒装 UI
- 一个大边框面板里装着更多边框面板、里面又装着更多边框面板的 section

只有在有明确目的时才使用盒子。

偏好:
- 开放的布局
- 更清楚的留白
- 更少但更强的容器
- 适当时采用更扁平的层级
- 用直接的对齐与间距取代过度的框线包裹
- 一个主要的取景手法(framing move),而非层层叠叠的框

一个 section 不该让人感觉像容器监狱。
它应该让人感觉经过设计、开放且刻意。

---

## 17. 削减微型 UI 噪音规则

不要用无助于清晰度的微小 UI 附加物弄脏设计。

避免:
- 不必要的 pill
- 伪系统标记
- 假的控制标签
- 装饰性的类代码 tag
- 无意义的小型 metadata 列
- 充数的 chip
- 到处都是的小徽章
- 假的仪表板术语
- 过度设计、干扰主布局的标签

除非真的必要,否则要避免的例子:
- “00 orchestration layer”
- 迷你的技术状态 pill
- 装饰性的 runtime 标记
- 过度具体的伪企业级 microcopy
- 只为了看起来复杂而存在的操作员/控制室风格标签

偏好:
- 更干净的标题
- 更少的标签
- 真实的层级
- 更清楚的间距
- 更简单的辅助文本
- 用更强的字体排版取代装饰性噪音

---

## 18. SECTION 图片生成规则

在 Codex 中,把每个 section 视为独立可分析的单位。

如果用户要求:
- 只要一个 hero → 产生 1 张 hero 图
- 4 个 section → 产生 4 张 section 图
- 8 个 section → 产生 8 张 section 图
- 12 个 section → 在合理范围内产生 12 张 section 图

一般偏好:
- 一个 section = 一张主图
- 一个复杂的 section = 一张主图 + 一或多张选配细节图
- 一个不清楚的 section = 重新生成为一张全新干净的独立图

这条 section 优先的生成规则是为了防止:
- 小到看不清的文本
- 迷你按钮
- 不清楚的间距
- 薄弱的萃取质量
- 有损耗的设计转代码转译

---

## 19. 网站图片系统规则

生成网站设计时,不只要思考整体网站,也要思考网站内部所使用的图片系统。

可能包括:
- hero 媒体
- section 图片
- 编辑风裁切图
- 产品视觉
- 带框的摄影作品
- 层叠的图片卡
- 图库式(gallery-like)区块
- 辅助视觉面板

如果多张图片对网站有帮助,就在整个网站中安排多个图片时刻(image moment)。

规则:
- 图片的使用必须让人感觉是刻意的
- 图片数量应与网站复杂度相称
- 如果多个 section 需要视觉支撑,不要只靠一张 hero 图
- 图片使用保持平衡、干净
- 所有图片时刻仍必须属于同一个连贯的设计世界

---

## 20. 固定媒体框规则

网站内的图片通常应该放在清楚、受控、对实现友善的框架里。

偏好:
- 固定长宽比的媒体区块
- 边界清楚的图片区域
- 可重复使用的媒体模块
- 一致的圆角逻辑
- 相似 section 之间稳定的视觉比例

范例:
- hero 图放在边界清楚的大框里
- 编辑风裁切图使用可重复的直式或横式比例
- 卡片图片维持一致的比例
- 图库区块使用受控的长宽比
- 产品图放在稳定、刻意安排的容器里

避免:
- 毫无系统的随机图片尺寸
- 相似模块之间比例不一致
- 混乱的缩放
- 失控的拼贴混沌(除非用户明确要求)

目标是:
- 视觉强烈的图片
- 放在前端 model 能实际重建的系统里

---

## 21. 文本萃取规则

当产生的 section 图片里的文本可读时,把它萃取出来并使用。

特别要查看并萃取:
- hero headline
- hero subheadline
- CTA 标签
- section 标题
- pricing 标签
- feature 名称
- 清楚可见的 testimonial 人名与职称
- navbar 标签
- 相关的 footer 标签

如果文本小到无法可靠萃取:
- 产生一张更近距离的萃取图
- 或为该 section 产生第二张更清楚的版本

不要忽略文本萃取。
可见的文本是设计系统的一部分,应该影响实现。

---

## 22. 字体排版萃取规则

不要只注意到字体排版“看起来不错”。
要正确地分析它。

萃取并观察:
- 字级比例关系
- 字重(weight)关系
- 行数
- 行高(line height)的感觉
- 字距(tracking)的感觉
- 衬线与无衬线的行为
- 展示字体(display)与内文(body)的对比
- section 标题的节奏
- CTA 文本的尺度
- 设计使用的是沉稳还是激进的字体

在实现时运用这些发现。
不要把字体排版压平成千篇一律的代码层级。

---

## 23. 间距萃取规则

刻意地分析间距。

查看:
- headline 与 subheadline 之间的距离
- 文本与按钮之间的距离
- 卡片之间的距离
- section 上下间距
- 两侧 gutter
- 卡片 padding
- 图片与文本的距离
- navbar 间距
- CTA 区块间距
- 各 section 之间的整体节奏

目标不是精确到像素的 OCR。
目标是忠实的间距逻辑。

如果产生的设计间距较宽裕,不要在实现时塌陷成千篇一律的紧凑间距。

---

## 24. 按钮/组件萃取规则

按钮和组件必须经过分析,不能用猜的。

查看:
- 按钮尺寸
- 按钮形状
- 按钮圆角
- 填色(fill)与外框(outline)的行为
- icon 的使用
- 暗示的 hover 氛围
- 主要与次要按钮的层级
- 卡片结构
- 徽章的使用
- 分隔线
- 阴影
- 边框
- pill 逻辑
- 若有输入框,其样式

如果按钮或卡片细节太小,就产生一张更近距离的图。

---

## 25. 颜色萃取规则

主动分析并萃取产生图片中的颜色。

查看:
- 背景色
- 面板颜色
- 强调色
- 按钮填色
- 文本颜色层级
- 边框颜色逻辑
- 阴影颜色氛围
- 图片的色调(tint)/调色(grade)
- 渐层的节制或强度

实现出来的网站应尽可能贴近保留原始的颜色逻辑。

不要用千篇一律的缺省网页颜色取代精心设计的色盘。

---

## 26. 设计转代码的临摹纪律

在产生并分析完参考图之后,以临摹导向(copy-oriented)的方式实现网站。

也就是说:
- 紧跟参考图
- 保留布局逻辑
- 保留间距节奏
- 保留 section 排序
- 保留文本与图片的平衡
- 保留字体排版氛围
- 保留组件风格
- 保留整体视觉的干净度

实现过程中不要漂移到另一个设计方向。
不要用千篇一律的代码布局取代原设计来“改良”它。

目标不是:
- 受图片启发

目标是:
- 视觉上忠于图片,转译成真正的前端

---

## 27. 反漂移实现规则

一种常见的失败模式是设计漂移(design drift):
产生的图片看起来很强,但写成代码后变得平庸。

严格避免这种情况。

实现期间:
- 不要简化成缺省模板
- 不要用千篇一律的横列取代有辨识度的 section
- 不要把宽裕的间距压缩成密集布局
- 不要用平淡的层级取代强烈的字体排版
- 不要为了省事抹去页面的视觉识别
- 不要把 section 逻辑合并成来源图片中不存在的重复模式
- 不要把分析阶段刻意移除的嵌套盒子复杂度加回来

最终的代码成果应该仍让人觉得跟产生的参考图是同一个网站。

---

## 28. 缺失细节的解决顺序

从图片实现时,某些细节可能仍不清楚。

按以下顺序解决模糊之处:
1. 保留可见的设计语言
2. 保留布局与间距逻辑
3. 保留组件家族
4. 保留氛围与精致程度
5. 需要时产生一张额外的细节图
6. 需要时把该 section 重新生成为全新独立图片
7. 到了这一步,才选择最忠实又对实现友善的版本

不要太快用千篇一律的默认值填补模糊之处。

---

## 29. 反 AI 废料(ANTI-AI-SLOP)规则

除非用户明确要求,否则严格避免以下模式。

### 布局废料
- 一张巨大、看不清的拼贴
- 没完没了的置中 section
- 一个 section 接一个 section 重复同样的卡片横列
- 拷贝粘贴的左文右图区块
- 没有层级的假复杂度
- 毫无目的的装饰性空白
- 卡片套卡片再套卡片
- 把所有东西包起来的巨大圆角外框 section
- 过度隔间化的仪表板式取景

### 视觉废料
- 缺省的紫蓝色 AI 渐层
- 过多的发光边缘
- 到处漂浮的色块(blob)
- 毫无理由堆栈的 glassmorphism
- 没有结构的随机未来感细节
- 过度渲染、盖住布局的噪音

### 字体排版废料
- 巨大标题+软弱迷你的副文案
- 太多种字体氛围
- 别扭的断行
- 偷懒的全大写用到底
- 千篇一律的渐层标题把戏

### 内容废料
避免以下千篇一律的填充词氛围:
- unleash
- elevate
- revolutionize
- next-gen
- seamless
- transformative platform

避免假品牌废料:
- Acme
- Nexus
- Flowbit
- Quantumly
- NovaCore

避免假复杂度废料:
- 伪企业级控制标签
- 装饰性系统标记
- 充数的状态 microcopy
- 假的 operator/runtime/orchestration 术语(除非真的是品牌核心)

### 密度废料
- 塞爆的 section
- 卡片重载
- 主要 section 之间间距过小
- 让人视觉疲劳的内容墙

---

## 30. 字体排版优先纪律

字体排版是最主要的设计素材。

永远确保:
- 清楚的字级对比
- 一目了然的阅读顺序
- 强而有力的展示时刻(display moment)
- 可读的内文
- 精简的文案
- 能强化结构的 section 标题

编辑风方向:
- 让字体排版塑造构图

科技/产品方向:
- 让字体排版传达信任感与精准度

---

## 31. SECTION 节奏规则

高端网站不会让人觉得是同一个区块无限重复。

通过改变以下项目,让整页的 section 节奏有所变化:
- 密度
- 图文比例
- 对齐
- 尺度
- 留白
- 卡片分组
- 背景强度
- 视觉节拍

但是:
- 保持整页连贯
- 保持间距受控
- 避免突兀的跳跃
- 让每个 section 都干净到足以好好分析

---

## 32. 密度与间距纪律

不要让网站太密。

页面应该要能呼吸。

规则:
- 使用均匀的 section 间距
- 让主要 section 之间的间隔受控且刻意
- 让留白创造沉静感
- 避免一个 section 拥挤、下一个却空荡
- 较小的 section 周围仍要有足够空间
- 偏好可分析、宽裕的间距,而非压缩的构图
- 不要把每一块可用区域都塞满额外 UI
- 让简洁本身承担一部分设计工作

高级感的网站应该让人感觉:
- 开放
- 有构图
- 平衡
- 自信
- 有呼吸感

而不是:
- 拥挤
- 吵杂
- 失衡
- 过度填塞
- 视觉疲劳

---

## 33. 缺省 SECTION 组合包

### 4-section 组合包
1. Hero
2. Features
3. Social proof/testimonial
4. CTA

### 8-section 组合包
1. Hero
2. Trust bar
3. Features
4. 产品展示(Product showcase)
5. Benefits/使用情境
6. Testimonials
7. Pricing
8. CTA

### 12-section 组合包
1. Hero
2. Trust bar
3. Feature grid
4. 产品预览
5. 问题/解方
6. Benefits
7. Workflow
8. 数据/实证/集成
9. Testimonials
10. Pricing
11. FAQ
12. CTA + footer

在 Codex 中,这些通常应该变成一个 section 一张图,而不是一张压缩的总表。

---

## 34. 多图一致性规则

对于多图网站,强制运行:
- 相同的品牌世界观
- 相同的字级尺度逻辑
- 相同的间距纪律
- 相同的 CTA 样式
- 相同的 icon 氛围
- 相同的图片处理手法
- 相同的语调
- 相同的组件家族

第 2、3 或第 8 张图绝不能漂移成另一个网站。

---

## 35. 清晰度检查

定稿前,在内部逐项验证:

1. 设计是否已先生成?
2. 所有产生的图片是否都经过深入分析?
3. 文本是否够可读?
4. 若否,是否已补产额外的细节图?
5. 图片数量是否足够,还是偷懒产太少?
6. 不清楚的 section 是否已重新生成为全新独立图片,而非用裁切的?
7. 层级是否一目了然?
8. hero 是否够干净?
9. 字体排版是否分析到位?
10. 间距关系是否理解到位?
11. 按钮与组件是否萃取到位?
12. 颜色是否分析到位?
13. 设计在视觉上是否有辨识度?
14. 是否没有明显的 AI 痕迹?
15. 别人能否照着它忠实写出代码?
16. 若有多张图,它们是否明显属于同一套设计?
17. Codex 是否避免了把太多 section 压进一张小图?
18. 分析是否干净、有结构、够具体?
19. 不必要的嵌套盒子是否已移除?
20. 第一屏在小尺寸笔电上是否仍干净可读?
21. 无用的 pill、标签和假技术微元素是否已削减?

若否,先在内部修正再输出。

---

## 36. 回应行为

当用户在 image-to-code 工作流程中要求网站设计时:
1. 推断网站类型
2. 推断 section 数量
3. 若图片生成可用且视觉质量是核心,先产生设计图
4. 在 Codex 中偏好一个 section 一张大图
5. 若文本或组件太小,补产细节/萃取图
6. 只要能提升可读性或萃取质量,就多产图
7. 不要在图片数量上偷懒
8. 不要裁切旧图来萃取 section
9. 需要时把 section 重新生成为全新独立图片
10. 选定一个强力的视觉组合
11. 精选 4 个招牌组件
12. 精选 2 个动态暗示线索
13. 强制运行 hero 干净度与短 headline 行数
14. 削减不必要的 pill、标签和微型 UI 噪音
15. 避免卡片套卡片再套卡片,以及巨大的盒装 section 外框
16. 让第一屏在小尺寸笔电上保持可读、平衡
17. 在适当之处强化图片的使用
18. 让间距宽裕、均匀、可分析
19. 深入且干净地分析所有产生的图片
20. 萃取文本、字体排版、间距、按钮、颜色、组件与布局逻辑
21. 实现网站,尽可能贴近产生的参考图
22. 只有在完整分析结束后才创建最终文件

如果可以做出有力的解读,就不要问不必要的追问。
当视觉问题明显应该先用图片生成解决时,不要一开始就自由发挥写代码。
在 Codex 中不要把多个 section 压进一张看不清的图。
当应该重新生成一张更干净、针对单一 section 的新图时,不要去裁切先前产生的大图。

---

## 37. 解读范例

### 范例 1
用户:
“帮我做一个 AI 新创的 hero section”

解读:
- 产生 1 张 hero 图
- 需要时,为文本/按钮再产 1 张更近距离的萃取图
- 不要从较大的图板上裁一小块出来
- 若还需要更清楚,把 hero 重新生成为一张更干净的全新独立图
- 让 hero 保持沉稳、可读
- 避免假的工具标签与嵌套卡片
- 分析 headline、subheadline、CTA、间距、颜色、hero 媒体
- 然后实现 hero

### 范例 2
用户:
“帮我设计一个 8 个 section 的 landing page”

解读:
- 在 Codex 中产生 8 张独立的 section 图
- 一个 section 一张
- 必要之处补产额外细节图
- 深入分析全部 8 个 section
- 萃取文本、字体排版、间距、按钮、颜色、卡片、结构
- 若某个 section 仍不清楚,把它干净地重新生成,而不是用裁切的
- 让各 section 保持开放、不过度盒装
- 然后依据这些参考图实现整站

### 范例 3
用户:
“做一个高级感的创意 agency 网站,4 个 section”

解读:
- 在 Codex 中产生 4 张独立的 section 图
- 让 hero 非常干净
- 确保文本保持可读
- 深入分析每个 section
- 不要使用第一批算图的粗糙剪影
- 需要时重新生成更清楚的 section 图
- 避免 pill 泛滥的 microcopy 与容器重载
- 然后依据这 4 张参考图实现网站

---

## 38. 最终目标

产生的网站参考图要让人感觉:
- 高级
- 有 art direction
- 清晰
- 有结构
- 可读
- 可分析
- 令人印象深刻
- 反千篇一律
- 对实现友善

对于视觉型网站工作,这个 skill 必须先自行产生图片,接着深入且干净地分析这些产生的图片,再以它们为最主要的视觉依据,最后把前端做到与图片高度贴近。

在 Codex 中,如果用户要多个 section,就偏好各自独立的大张 section 图,而不是一张压缩的多 section 图板,这样文本、间距、字体排版、按钮和颜色才能被正确萃取。

如果某个 section 仍需要更多清晰度,就为该 section 补产一张以萃取为目的的图。

如果多产图能提升质量,就多产图。
不要在图片数量上偷懒。

当一张全新、针对单一 section 的图能更好地保留间距、布局与可读性时,不要去裁切先前产生的图。
改产一张干净的新图。

避免卡片套卡片再套卡片。
避免每个 section 外面都包一个巨大的盒装外框。
避免假的技术 pill 和装饰性微标签。
尤其要让 hero 保持干净、宽敞、收敛,并在小尺寸笔电上可读。

成果应该要:
- 作为 section 图片够强
- 作为设计系统够强
- 经得起深度分析
- 实现成前端后依然够强

最终成果看起来应该像一个顶级网站概念被忠实转译成真正的代码,而不是一张看不清的迷你设计图板,也不是一份千篇一律的代码重新诠释。

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…