企业官网建设流程全解析

如果你最近在关注 AI Agent 与设计工具的结合，应该会发现一个明显变化：设计类能力正在从“对话里的临时约定”变成“可安装、可复用的技能包”。妍妍老师发布的 Mono-color Design Skill，就是这类实践里很有代表性的一个案例。标题里的 Mono-color 对应“单色系”设计，Skill 则是当前 AI Agent 生态中非常关键的一种扩展方式。

乍看之下，它只是把“单色系设计”这一条规则封装成技能。但真正值得关注的不是某一个具体配色方案，而是 Skill 机制带来的工作方式转变：以前你让 AI 做一张单色海报，需要从色板、排版、对比度、风格一遍遍补充要求；现在只要挂载一个 Skill，AI 就会自动按照预设的设计规范执行。换句话说，设计师沉淀下来的不只是提示词，而是一套可复用、可校验、可持续迭代的流程资产。

这篇文章会把这个案例拆开讲清楚。我会先用开发者的视角解释 Skill 到底是什么，再讲 Mono-color 单色系设计的方法论，然后给出一个可以直接模仿的 Skill 文件结构、完整配置和校验脚本。读完你可以照着做一个属于自己的“XX 设计 Skill”，也可以把这套思路迁移到品牌规范、数据可视化配色、前端 Design Token 管理等工作场景中。

1. 这篇文章真正要解决的问题

很多人第一次接触设计类 Skill 时，会有一个错觉：这不就是把一段“设计规范提示词”保存到一个文件里吗？如果只是这样，那确实不值得单独写一篇文章。真正的问题在于，设计规范和普通提示词有本质区别。普通提示词是告诉 AI“你要做什么”，设计规范则必须回答“你按什么标准做、做到什么程度算合格、出错了如何修正”。

在实际项目里，设计规范往往有大量隐性知识。比如“主色旁边的浅色不能太灰”“文本色和背景色的对比度不能低于某个值”“同一套方案里的色相偏差不能超过多少度”。这些细节如果只放在对话里，AI 每次都要重新理解，结果就是输出不稳定：同一个主色，换个会话生成的结果风格完全对不上。

妍妍老师发布 Mono-color Design Skill 这个案例真正解决的问题，是把一套单色系设计规则固化成 AI Agent 可以自动加载的“能力模块”。它让 AI 在生成设计前先读取规则，生成后用参考数据和脚本进行校验，最终输出的是有依据、有结构、可以被评审的结果。

什么样的读者最应该关注这篇文章：

• 设计师：希望把品牌配色规范交给 AI 执行，而不是反复手动修改图片。
• 前端工程师：在做 Design Token 或主题系统时，需要从主色生成整套色阶。
• AI Agent 开发者：想理解 Skill 的文件结构、编写方法和调试方式，而不是只会写 Prompt。
• 数据可视化同学：希望图表配色保持统一品牌色相，不再靠肉眼挑色号。

一句话总结第一章：设计类 Skill 的价值不在于“写了一段提示词”，而在于把设计判断力编码成了可复用资产。

2. Skill 机制：设计类 AI 能力的新载体

2.1 什么是 Skill

Skill 是 AI Agent 生态中用来扩展模型能力的一种标准方式。通俗来说，它是一组文件，包含“技能说明”和“参考资源”，放在指定目录后，AI 客户端或开发框架会在合适的时机自动加载这些内容。对模型来说，Skill 相当于一份可以随任务调用的“岗位说明书”；对使用者来说，Skill 相当于一个可以安装、卸载、版本管理的技能插件。

以当前主流 Skill 机制为例，一个 Skill 通常以目录形式存在：

mono-color-design-skill/ ├── SKILL.md └── references/ └── mono-color-scale.json

• SKILL.md是核心文件，描述技能的目标、触发条件、执行步骤和输出格式。
• references目录存放模型需要查询的参考数据，比如色阶表、设计格栅、品牌字体等。

当用户在对话中输入“请生成一套单色系方案”时，Agent 会根据技能描述判断是否需要加载该 Skill。如果匹配，它会把 SKILL.md 和参考文件内容一并送入上下文，再生成回答。不同平台的文件规范略有差异，但整体思路非常相似。

2.2 Skill 与普通 Prompt、Plugin 的区别

理解 Skill 的最好方式，是把三者放在一起对比：

普通 Prompt 是“一次性约定”，Skill 是“持久化约定”，Plugin 则是“外部能力接入”。设计规范这类知识型内容，天然适合放在 Skill 中，而不是写成 Plugin。因为设计规范本质上是文档和判断规则，不是需要连接数据库或调用第三方 API 的强逻辑服务。

2.3 为什么说 Skill 适合承载设计规范

设计规范有三个特点：可标准化、强约束、需要参考样例。可标准化意味着我们可以把“文本对比度至少 4.5:1”写成规则；强约束意味着 AI 不能在浅色背景上放浅色文字；需要参考样例意味着单一自然语言描述不足以覆盖所有边界情况。

Skill 恰好同时满足这三点。SKILL.md里的规则文本解决前两点，references目录里的色阶 JSON 解决第三点。更重要的是，Skill 可以随项目一起放在 Git 仓库中。每次调整色阶或规则，都能留下变更记录，这对团队协作非常关键。

这也解释了为什么设计类 Skill 会越来越多：它把原本存在于设计师脑海中的判断标准，变成了组织可以沉淀的资产。

3. Mono-color 设计的核心方法论

3.1 单色系设计的难点

如果只看“单色系”这个名称，很容易误以为让 AI 生成单色设计很简单：只要用一种颜色就行。但真实情况恰恰相反，单色系设计是最容易“翻车”的配色方案之一。

原因在于，去掉多色对比后，只能靠明度和饱和度的变化来区分信息层级。如果色阶设计不好，整套界面会变得很平，或者看起来脏兮兮的。举个常见例子：AI 生成的单色系方案往往只有两三个深浅不同的蓝色，放在一起层次缺失，用户根本无法判断哪个是主按钮、哪个是辅助按钮。

所以，让 AI 学会单色系设计，不是在 Prompt 里写一句“使用单色系风格”，而是要教会它一套完整的色彩系统构建方法。

3.2 色相、明度与纯度

单色系设计基于同一色相，通过控制两个维度来形成层次：

• 明度：颜色的明暗程度。明度越高越接近白色，越低越接近黑色。
• 纯度：颜色的鲜艳程度。纯度越高越鲜艳，越低越接近灰色。

在 HSB/HSV 色彩模型中，色相决定了“这是蓝色还是红色”，饱和度和明度则决定“这个蓝色是深还是浅、是鲜还是灰”。单色系方案的基本原则是：保持色相不变，让饱和度和明度按梯度变化。

这里最容易踩坑的地方是，很多 AI 模型在生成视觉图时，并不会严格保持同一色相。比如用户指定主色为蓝色，结果 AI 输出里出现了一些偏紫或偏青的颜色。这在专业设计里是不可接受的。因此，一份合格的 Mono-color 设计 Skill，必须包含“色相一致性校验”规则。

3.3 从主色到色彩系统：色阶表怎么设计

在实际项目中，我们很少直接使用单个主色，而是从主色衍生出一整套色阶。最常见的做法是设计 50 到 900 共 10 个层级，类似很多设计系统里的中性色板：

{ "baseColor": "#2563EB", "colorScale": [ { "step": 50, "hex": "#EFF6FF" }, { "step": 100, "hex": "#DBEAFE" }, { "step": 200, "hex": "#BFDBFE" }, { "step": 300, "hex": "#93C5FD" }, { "step": 400, "hex": "#60A5FA" }, { "step": 500, "hex": "#3B82F6" }, { "step": 600, "hex": "#2563EB" }, { "step": 700, "hex": "#1D4ED8" }, { "step": 800, "hex": "#1E40AF" }, { "step": 900, "hex": "#1E3A8A" } ] }

这个示例以#2563EB作为主色，从浅到深生成 10 个层级。浅色用于页面背景、分隔区域、状态提示；中色用于图标、辅助按钮、边框；深色用于正文、主按钮、强调内容。

如果输入材料没有给出现成色阶，Skill 也应该具备生成能力：从主色出发，按固定步长调整饱和度和明度，输出一套可用的色阶。关键是所有层级必须保持同一色相。

3.4 对比度与文本可读性

单色系设计第二个核心难点是文本可读性。因为同一色相的颜色在视觉上的差异没有互补色那么明显，浅蓝背景配深蓝文字通常没问题，但浅蓝背景配中蓝文字就很容易看不清。

判断文本可读性最常用的标准是 WCAG 对比度。普通正文文本要求对比度不低于 4.5:1，大号文本不低于 3:1。在 Skill 中，这些数值可以直接写成规则，让 AI 在生成方案时自动避开低对比度组合。

更稳妥的做法是同时提供校验脚本，用 Python 或 Node.js 读取生成的色阶 JSON，自动计算文本色与背景色的对比度。如果某项组合不达标，脚本直接输出警告。这样就把“设计审美”变成了“可检查的工程质量问题”。

4. 环境准备与前置条件

在实际动手编写 Skill 之前，先确认你的运行环境。本文的示例以通用 Skill 目录结构为准，不绑定某个特定平台的版本。如果你使用的是支持 Agent Skill 机制的客户端或开源框架，通常需要满足以下条件：

• 一个支持 Skill 机制的 AI Agent 客户端或开发框架，具体名称和版本以你使用的工具为准。
• 一个代码编辑器，推荐 VS Code，方便查看 JSON、Markdown 和 Python 文件。
• 本地环境建议安装 Python 3.8 或以上版本，用于运行校验脚本。如果不想装 Python，也可以用 Node.js 或在线 JSON 工具做亮度校验。
• 一个测试用主色 HEX 值，例如#2563EB，后续示例都基于它展开。

版本方面，我不建议把某个具体版本号写死。Skill 文件格式和框架调用方式还处于快速变化阶段，今天可用的字段，明天可能被兼容性更好的新字段替代。你更应该掌握的是“目录结构 + SKILL.md + references + 校验脚本”这套最小可运行组合。

环境准备完成后，我们进入核心部分：手动创建一个 Mono-color Design Skill。

5. 完整示例：创建一个 Mono-color Design Skill

5.1 目录结构与文件清单

我们创建一个最小但完整的 Skill 目录，包含 4 类文件：

mono-color-design-skill/ ├── SKILL.md ├── references/ │ └── mono-color-scale.json ├── scripts/ │ └── check_mono_palette.py └── examples/ └── prompt-example.md

• SKILL.md：技能主文件，包含元信息、设计规则、执行流程。
• references/mono-color-scale.json：标准色阶参考数据，供模型查询。
• scripts/check_mono_palette.py：校验脚本，用于验证生成结果的色相一致性和对比度。
• examples/prompt-example.md：调用示例，方便团队成员理解怎么使用这个 Skill。

5.2 编写 SKILL.md

这是整个 Skill 最核心的文件。你可以在SKILL.md中描述技能的目标、触发条件和输出格式，让 AI Agent 知道什么时候该加载它，以及加载后按什么流程执行。

--- name: mono-color-design-skill description: 基于单一主色生成完整单色系色彩方案，包括色阶、界面配色和设计说明。 version: 1.0.0 metadata: author: demo-team tags: [design, mono-color, ui] --- # Mono-color Design Skill ## Skill 目标 当用户要求执行“单色系设计”“Mono-color Design”或“生成单色配色方案”时，加载本技能，输出一套符合品牌规范的完整单色系色彩系统。 ## 输入要求 - 主色 HEX：由用户提供，或从用户给出的品牌色、图片中提取。 - 应用场景：UI 界面、数据可视化、海报、PPT 等。 - 输出语言：默认中文。 ## 设计规则 1. 色相一致性：所有色块与主色的色相偏差不超过 8 度。 2. 色阶层级：优先参考 references/mono-color-scale.json，按 50-900 共 10 级输出。 3. 对比度要求：正文文本与背景对比度不低于 4.5:1，大号文本不低于 3:1。 4. 输出结构必须包含： - 主色 HEX 与说明 - 10 级色阶表 - 各场景下的配色建议 - 文本可读性校验结果 5. 禁止生成与主色色相偏差较大的颜色作为同类色阶。

这段 SKILL.md 做了三件事：定义触发条件、给出输入约束、明确输出结构。AI 只有在任务匹配时才会加载它，加载后也不需要用户再重复设计规范。如果你使用的平台支持自定义字段，可以参考这个结构调整。

5.3 准备色阶参考文件

参考文件的价值，是让模型不需要“凭空想象”一套色阶，而是能直接基于已有数据做适配。下面是一个标准蓝色系的 JSON 色阶参考文件。

{ "baseColor": "#2563EB", "description": "示例主色 #2563EB 的 10 级单色色阶，仅作为训练参考数据", "colorScale": [ { "step": 50, "hex": "#EFF6FF" }, { "step": 100, "hex": "#DBEAFE" }, { "step": 200, "hex": "#BFDBFE" }, { "step": 300, "hex": "#93C5FD" }, { "step": 400, "hex": "#60A5FA" }, { "step": 500, "hex": "#3B82F6" }, { "step": 600, "hex": "#2563EB" }, { "step": 700, "hex": "#1D4ED8" }, { "step": 800, "hex": "#1E40AF" }, { "step": 900, "hex": "#1E3A8A" } ], "usage": { "background": ["50", "100"], "border": ["200", "300"], "secondaryAction": ["400", "500"], "primaryAction": ["600"], "text": ["700", "800", "900"] } }

{ "recommendedTextPairs": [ { "background": "#EFF6FF", "text": "#1E3A8A", "contrastRatio": "10.1:1" }, { "background": "#DBEAFE", "text": "#1E40AF", "contrastRatio": "8.6:1" }, { "background": "#FFFFFF", "text": "#2563EB", "contrastRatio": "5.2:1" } ] }

实际使用时，你可以把第二个 JSON 文件放到references目录中，也可以合并到同一个文件里。参考数据的价值在于给模型一个“安全区”，避免它随意组合出低对比度配色。上面标注的对比度数值是示意值，实际数值取决于你的色值计算方式，建议运行脚本验证。

5.4 设计校验脚本

有了规则和参考数据，还需要一个“裁判员”。下面的 Python 脚本可以读取色阶文件，逐一检查每个色块与主色的色相偏差，并提示对比度风险。

# 文件路径：mono-color-design-skill/scripts/check_mono_palette.py import sys import json import colorsys def hex_to_rgb(hex_color: str): hex_color = hex_color.lstrip('#') if len(hex_color) != 6: raise ValueError(f"invalid hex color: {hex_color}") return tuple(int(hex_color[i:i+2], 16) / 255.0 for i in (0, 2, 4)) def rgb_to_hsv(rgb): return colorsys.rgb_to_hsv(rgb[0], rgb[1], rgb[2]) def main(palette_path: str, base_hex: str, hue_tolerance: float = 8.0): with open(palette_path, 'r', encoding='utf-8') as f: palette = json.load(f) base_hsv = rgb_to_hsv(hex_to_rgb(base_hex)) base_hue = base_hsv[0] * 360 print(f"base hue: {base_hue:.1f}") for item in palette["colorScale"]: step = item["step"] hex_color = item["hex"] hsv = rgb_to_hsv(hex_to_rgb(hex_color)) hue_deg = hsv[0] * 360 hue_diff = abs(hue_deg - base_hue) if hue_diff > 180: hue_diff = 360 - hue_diff ok = hue_diff <= hue_tolerance status = "OK" if ok else "WARN" print(f"step {step:>3} {hex_color} hue={hue_deg:6.1f} {status}") if not ok: print(f" warning: hue difference {hue_diff:.1f} exceeds tolerance") if __name__ == "__main__": if len(sys.argv) != 3: print("usage: python check_mono_palette.py <palette.json> <base_hex>") sys.exit(1) main(sys.argv[1], sys.argv[2])

运行方式：

python scripts/check_mono_palette.py references/mono-color-scale.json "#2563EB"

如果所有色块的色相偏差都在 8 度以内，脚本输出 OK；如果某个色块偏色，会输出 WARN 并给出偏差值。这个脚本的边界能力有限，但已经足够作为设计质量门禁之一。

5.5 在 AI 客户端中调用

Skill 文件准备好后，把它放到你使用的 AI Agent 可以识别的位置。不同工具对 Skill 目录的存放位置要求不同，这里只演示调用思路：

请加载 mono-color-design-skill，主色为 #2563EB，应用场景是数据看板 UI，输出一套包含主色、深浅色阶、功能状态色的单色系方案。

AI 收到请求后，会先判断任务与 Skill 是否匹配，再读取规则和参考数据，最后按 SKILL.md 规定的结构输出结果。如果你发现 AI 没有加载 Skill，优先检查目录位置和 SKILL.md 中的触发描述是否准确。

6. 运行验证与效果检查

一个 Skill 是否真的可用，不能只靠“看起来挺好看”来判断。下面给出三个最小验证用例，你可以按顺序执行。

6.1 验证用例一：基础色阶生成

输入：

请加载 mono-color-design-skill，主色 #2563EB，应用场景为网页 UI。

检查点：

• 是否输出了至少 10 级色阶。
• 色阶中的浅色端和深色端是否存在明显明度差异。
• 是否包含文本对比度的说明。

如果 AI 只输出了一两个蓝色色值，说明 SKILL.md 中的“色阶层级”规则没有被完整加载。此时可以检查描述是否写入了触发条件，或者当前 Agent 平台的上下文长度是否不足。

6.2 验证用例二：色相一致性与校验脚本

用参考文件运行校验脚本：

python scripts/check_mono_palette.py references/mono-color-scale.json "#2563EB"

预期结果是所有 step 都输出 OK。如果某个 step 出现 WARN，说明该色块不是标准单色色阶，需要重新生成参考数据。这个步骤的意义在于，它把“是否偏色”从感觉判断变成了可重复执行的客观检查。

6.3 验证用例三：低对比度拦截

输入一个极端情况：

请加载 mono-color-design-skill，主色为浅黄色 #FDE68A，背景用最浅色，文字用中等黄色。

此时 Skill 规则应要求 AI 明确指出对比度不足，并自动选择 700 到 900 等深色作为文本色。如果 AI 仍然生成了低对比度方案，说明对比度规则的表达不够具体，建议在 SKILL.md 中把“4.5:1”和“3:1”这两条数值写得更显著。

验证失败的排查顺序可以这样走：

1. 先确认 Skill 目录是否放对位置。
2. 再确认 SKILL.md 中触发描述是否包含用户输入中的关键词。
3. 然后查看生成结果是否参考了 references 文件。
4. 最后检查规则本身是否不够量化，比如“对比度要足够高”就不如“对比度不低于 4.5:1”可执行。

7. 常见问题与排查思路

表格中的排查思路适用于大多数 Skill 类项目。你在实践中遇到新问题，可以先记录问题现象、复现方法和修复方案，逐步形成团队的排错手册。

8. 最佳实践与工程建议

8.1 让设计规则显性化

设计 Skill 能否生效，很大程度上取决于规则是否可量化。像“美观”“高级感”这类描述，模型很难稳定理解；“文本对比度不低于 4.5:1”“色相偏差不超过 8 度”则可以被验证。

建议在 SKILL.md 中把所有规则分成“必须遵守”和“建议参考”两类。必须遵守的规则写入校验脚本，建议参考的规则保留在文本说明中。这样既保证了下限，也保留了设计的灵活性。

8.2 用数据文件管理色彩资产

不要把所有颜色硬编码在 SKILL.md 里。更好的做法是把色阶、推荐文本组合、功能色定义放到 JSON 或 YAML 文件中，由 SKILL.md 通过路径引用。这样做的好处是结构清晰、方便替换，也让校验脚本可以直接读取数据文件。

项目中可以维护一份标准的 color-token 数据文件，前端生产环境使用时直接从这个文件生成 CSS 变量或设计令牌，设计成果就能真正进入代码工程。

8.3 团队协作与版本管理

Skill 文件是普通文本文件，完全可以用 Git 管理。建议每个 Skill 独立一个仓库或目录，并在提交时附带示例输出截图或说明。这样当 AI 生成结果出现回归时，可以快速定位是规则修改还是参考数据变更导致的。

更好的做法是设置评审流程：设计师负责制定规则，开发者负责实现校验脚本，测试同学用真实项目场景验证输出结果。经过几次迭代后，这个 Skill 会越来越像一个标准化的内部工具，而不是某个人私藏的一段提示词。

8.4 安全与使用边界

有一点必须强调：设计类 Skill 不能替代人对品牌调性的最终判断。AI 可以按照规则生成色阶、计算对比度，但它不理解品牌背后的商业含义。在使用任何 AI 生成设计结果前，都需要经过设计师或品牌负责人的确认。

同时，如果 Skill 涉及公司内部品牌色、字体、素材，需要在团队知识库中明确版权和授权边界。不要把未授权的商业素材直接放入 references 目录。另一个容易忽略的问题是风险操作：如果 Skill 调用外部图像生成服务，建议先在测试环境验证参数，避免直接在生产环境批量生成不可回退的素材。

8.5 从小场景开始做

给团队落地设计 Skill 时，不要一上来就做一个“全能设计助手”。建议从一个非常窄的场景开始，比如“数据看板单色配色”，跑通后再加上“海报单色配色”“PPT 单色配色”。窄场景的好处是边界清晰，容易编写规则，也容易验证效果。多跑几个窄场景之后，你再回头抽象公共规则，会发现思路清晰很多。

9. 总结与后续学习方向

妍妍老师发布 Mono-color Design Skill 这件事，放到整个 AI Agent 发展进程中看，是一个典型信号：设计能力正在从“对话辅助”转向“工程资产”。Skill 把设计师的经验、规则与参考数据打包成可加载、可校验、可维护的文件，让 AI 在设计任务上的表现不再依赖运气。

本文真正讲清楚的几件事是：Skill 机制与普通 Prompt/Plugin 的区别；单色系设计为什么难，以及色相、明度、对比度如何变成可执行规则；如何用 SKILL.md、JSON 参考文件和 Python 校验脚本搭建一个最小 Skill；以及在团队项目中如何安全、可控地落地这类能力。

如果你已经照着示例跑通了一个最小 Skill，下一步可以继续深入几个方向：

• 把色阶生成逻辑迁移到 Design Token 工程，让前端直接消费 JSON 数据。
• 增加进阶校验能力，比如饱和度下限、无障碍颜色组合建议。
• 尝试把同一套 Skill 挂载到不同 Agent 平台，整理一份兼容性清单。
• 从单色系扩展到双色系、渐变系，抽象出更通用的配色规则库。

对实际项目的提醒只有一点：设计 Skill 的规则不是一次性写出来的，而是通过真实项目不断改出来的。每发现一次输出不达标，就补一条规则；每新增一个场景，就更新一次参考数据。先做最小版本，再慢慢演进，这会比幻想一个“万能设计神器”靠谱得多。