企业官网建设流程全解析

“这套界面又是那个味儿。”最近几个月我和做AI应用的朋友交流，几乎每个人都被同一个问题卡住过：让大模型生成一个管理后台、一个官网落地页、一个数据分析面板，出来的东西闭着眼都知道长什么样——左侧栏、卡片式堆叠、圆角大按钮、蓝色渐变主色、白色背景。不能说不好看，但看多了真的会视觉疲劳。问题的根源不在于模型能力不够，而在于模型天然会往“训练数据里出现频率最高”的样式上靠，也就是所谓的平均化审美。而解决这个问题的思路也慢慢清晰了：不要用一句提示词去约束它，而是直接给模型装上一套“Skill包”。这东西不是普通的prompt加强版，而是一种可组装、可复用、可挂在Agent工作流里的结构化技能模块。装上之后，AI生成界面的逻辑会从“我见过很多后台，我随便选一种”变成“我遵循一套明确的设计准则，并且参考了具体案例”，输出结果完全就是两个级别。

这篇文章我会从头拆解：Skill到底是什么、为什么它能让AI跳出模板化死循环、以及我实际用下来的具体套路和踩坑记录。适合两类人看，一类是正在做AI应用开发、想让Agent产出更贴合业务气质的界面的人，另一类是单纯受够了AI模板风格、想在工作流里注入一点设计约束的普通用户。

1. 先搞清楚问题：界面为什么总是一股“AI味”

1.1 模型没有审美，只有统计学偏好

先摆一个观点：大模型生成界面时，它脑子里没有“审美”这个概念。它有的只是Token的概率分布。你给它一个需求，它输出界面的过程，本质上是在所有它见过的界面代码片段里面，挑选一条概率最高的路径往下走。

这就会引出一个很现实的问题：训练数据里占比最多的界面是什么？是各种开源后台模板、Bootstrap文档示例、WordPress主题、通用SaaS网站。这些数据量庞大，风格高度趋同，于是模型学到的“默认界面”就是那套最常见的组合：左侧固定导航栏，顶栏放用户头像和退出按钮，中间是一个卡片网格，右上角一个主色按钮，背景白色或浅灰。这不是模型刻意选的，它是数学上最“稳妥”的选择。

很多人以为换个模型就能解决这个问题，实测下来效果差距没有想象中大。无论是闭源还是开源的，只要不做额外约束，最后的界面风格都逃不开那个统计学舒适区。所以问题的关键不是“换个更懂设计的模型”，而是“改变模型的决策路径”。

1.2 一句提示词管不住风格，因为约束太薄弱

那你说，我在prompt里写“请设计一个更有创意的界面”，或者“不要用常见的后台风格”，有没有用？有一点，但非常有限。原因在于：提示词是瞬时性的，模型读到这句约束时，确实会增加一点多样性权重，但它后续还是要靠概率分布来生成具体代码。而“不要用常见风格”这种负向约束，对概率分布的影响非常微弱，因为模型不擅长在生成时不断排除自己最常用的Token路径。

而且提示词没法携带足够多的参考信息。你说“要简洁”，模型不知道你说的简洁是那种日式极简还是瑞士国际主义风格；你说“要有科技感”，模型给出的科技感往往是深蓝色加发光效果——这本身就是模板化审美的另一种表现形式。

1.3 Agent化之后，问题变得更大了

如果你只是让ChatGPT用对话方式生成一个页面，模板味重一点，你还能让它改。但如果你是在用Agent做自动化生成，比如你写了一个AI生成营销落地页的工作流，Agent会自动拆解任务、自动生成代码、自动迭代几轮后直接输出成品。这种情况下，模板味的问题会被指数级放大，因为Agent本身没有审美判断力，它的迭代标准往往只是“功能完整”“没有bug”“看起来合理”，而“看起来合理”的参照系恰恰又是训练数据里的那套模板。

这就是为什么Skill包的出现如此关键。Agent的工作流里有“工具调用”（比如调用搜索、调用浏览器截图、调用代码执行器），也有“技能调用”（比如读取一份结构化文档，把其中的规则注入到当前的上下文里）。Skill包本质上就是把“设计规则”从提示词这种软约束，变成Agent每次执行任务时都会读取并遵循的硬性上下文。

2. Skill包到底是什么，和普通提示词有什么本质区别

2.1 把Skill理解为“给Agent安装的岗位手册”

最近很多工具都在提Skill这个概念，常见的有Codex Skill、OpenCode Skill、Claude Code的Skill目录、Spring AI里的Skill与Agent组合。虽然不同平台叫法略有差异，核心结构是类似的：Skill不是一句话，而是一个文件夹，里面包含了一份描述文件（通常是SKILL.md），以及一些配套的资源文件，比如参考案例、代码片段、规则清单、模板文件等。

它的工作方式很简单：当Agent接到一个任务时，它会根据任务内容判断需要加载哪些Skill，然后读取这个Skill目录下的文档内容，将这些内容作为上下文的一部分参与生成。换句话说，Skill相当于给Agent装了一本“岗位手册”。不是临场叮嘱两句，而是让它每次干活前都先翻一遍手册，按手册的规范来。

2.2 Skill与Prompt、Agent的关系清单

为了帮助理解，我整理一个粗浅但直观的对照：

用好这个组合的关键在于：Agent负责“做什么”和“怎么做”的推理循环，Skill负责“按什么标准做”和“参考什么来做得不像别人”。两者是配合关系，不是替代关系。

2.3 为什么Skill能解决“模板味”问题

因为Skill可以把“风格参考”实体化。你可以在Skill包里面放上具体的设计Tokens——比如色板、字体比例、间距系统、圆角规则、阴影强度，也可以放上两三套完整的高质量界面参考代码。Agent读取这些文件后，它在生成界面时就不会再回到统计学默认值，而是会照着参考代码的结构、设计Tokens去组织新页面。

这个机制本质上是在模型的概率分布之外，注入了一个局部性的强约束。就像你让一个从没去过成都的人做一道川菜，他大概率做出来是不辣的家常菜；但如果你递给他一本非常详细的川菜菜谱，附带几张成品照片，他就不会自由发挥出番茄炒蛋了。

3. 手写“反模板”界面Skill包：完整实操过程

3.1 起手式：先想清楚这个Skill要约束什么

直接说结论：一个界面Skill包至少要约束四件事——视觉Tokens、布局模式、组件风格、禁忌清单。缺少其中任何一项，输出的界面就还是有概率滑回老路。

我管自己这套叫“Anti-Template UI Skill”，目录结构很简单：

anti-template-ui/ ├── SKILL.md ├── design-tokens.md ├── reference-examples/ │ ├── dashboard-dark-accent.html │ └── landing-editorial.html └── forbidden-patterns.md

SKILL.md是入口文件，Agent会先读它。它里面写清楚这个Skill的用途、适用场景、以及工作流程。

3.2 写SKILL.md时，最关键的是“触发条件”和“执行顺序”

很多人在写Skill的时候犯的第一个错误是：把SKILL.md当成一篇说明文，洋洋洒洒写一大堆，但没有告诉Agent“什么时候该读这个文件”以及“读完之后按什么顺序做事”。

一个有效的SKILL.md开头应该是这样：

# Anti-Template UI Skill ## 触发条件 当用户要求生成、重构或修改以下类型的界面时，必须加载本Skill： - 管理后台 / Dashboard - 数据可视化面板 - 营销落地页 - 表单密集型界面 - 任何要求“非模板化”的视觉任务 ## 执行流程 1. 先读取design-tokens.md，确定本次项目的色板、字体、间距、圆角、阴影规范。 2. 从reference-examples/目录中挑选一个与当前任务最接近的参考案例，分析其结构。 3. 严格遵循禁忌清单，逐条检查生成结果，如果触碰禁忌则重新生成。 4. 生成完成后，附上一段简短的设计说明，解释为什么这个设计避开了常见模板。

这个执行流程非常关键。它让Agent的思考路径从发散的“自由发挥”变成了一个有工序的流水线操作，每一次生成都会经过规则检查，模板味自然就被压下去了。

3.3 design-tokens.md：把视觉约束“数值化”

“设计Tokens”这个词有点唬人，其实本质就是把这些感觉词汇翻译成具体数值。AI的模板化很大程度来自于模型对“好看”的感知是模糊的，你要帮它把感知锚定在精确数值上。

我这份design-tokens.md里面有几个核心配置块：

## 色板策略 - 禁止使用默认纯蓝色 (#3B82F6) 作为主色。 - 主色建议从以下色系中选择：暖棕色系、暗紫色系、橄榄绿系、或不饱和橙色系。 - 背景色禁止纯白 (#FFFFFF)，使用带轻微色相偏移的米白/灰调，如 #FAF9F7 或 #F5F4F2。 - 文字主色不要用纯黑 (#000000)，使用 #1A1A1A 或 #242424。 ## 字体与排版 - 标题字体：优先使用衬线字体或宽扁无衬线，避免默认的Inter、Roboto。 - 正文字号至少16px，行高1.6以上。 - 标题层级必须有明显的字号梯度，避免所有文字看起来一个大小。 ## 间距系统 - 基础间距单位定为8px，所有间距必须是8的倍数。 - 卡片与卡片之间的间距不得小于24px，避免页面看起来拥挤。 ## 圆角与阴影 - 圆角禁止统一使用同一数值，大小卡片必须区分，例如大卡片圆角20px，小控件圆角8px。 - 阴影层次最多3级，且禁止使用叠加的大面积柔和阴影（这是Bootstrap卡片的经典特征）。 ## 布局规则 - 禁止所有页面都使用“左侧边栏 + 顶栏 + 内容卡片”结构。 - 至少尝试以下替代布局之一：顶部大导航+全宽内容区、非对称分栏、右侧工具面板式布局、横向卡片滚动式布局。

把Tokens写细之后，你会发现AI生成的界面明显有了“设计感”，因为它不再靠猜，而是像真正的设计师一样，依据一套固定的设计决策来工作。

3.4 禁忌清单：直接堵死最典型的模板特征

这是目前被讨论得最多的板块，网上叫“去AI味”或者“去模板化”的Skill大多体现在这里。我的禁忌清单会不断更新，目前维护了这么一批：

• 不要生成“左侧深色/白色侧边栏 + 顶部导航 + 主区域卡片网格”这种组合，如果出现一种，就必须改成非对称布局。
• 不要在主视觉区域使用居中的超大标题搭配“下划线式”的装饰线条，在营销页里用错落式排版代替。
• 不要所有按钮都用圆角胶囊样式，混用直角和微圆角。
• 不要所有卡片都带投影，用边框或背景色差异来分割层次。
• 不要图标全部使用同一套默认线性图标，尝试混搭几何装饰元素、大号数字序号或粗体排版来替代。
• 不要在每个区块都用“左文右图”或“左图右文”交替排列，偶尔用全宽引文区块、数据大数字、非对称留白来打破节奏。

实际测试下来，禁忌清单带来的提升往往比正向描述还要大。因为负向约束能非常精准地限制住模型的行为，减少它逃回统计学舒适区的空间。

3.5 参考案例：给Agent“抄作业”的完整代码

参考案例是整个Skill包里最有价值的部分。你放什么样的案例，AI就能生成出什么水准的东西。注意，不是放一堆设计感极强但结构很特殊的获奖网站，那会让AI用力过猛，导致页面过于花哨而牺牲可用性。

我放了两个案例：一个是带强烈暗色风格的数据面板，结构非常规但功能清晰；另一个是杂志编辑式布局的落地页，不对称分栏、错落视觉层级、大字号排版。这两个案例覆盖了“工具型界面”和“内容型界面”两类最常见的场景。

参考案例的文件里，代码必须是完整的HTML加内联CSS，不能只给片段。如果给片段，模型补全时又会回到老路上。完整代码能让模型看到一个页面从结构到细节的“全貌”，从而理解非模板化是整体性的，不是某个角落加点小设计就能解决的。

4. 实测对比：同一个需求，装Skill前后能差多远

4.1 测试场景：生成一个“团队项目进度管理面板”

为了验证Skill的效果，我做了一个对比测试。同样的模型、同样的需求描述，唯一区别是是否加载anti-template-ui这个Skill包。

需求描述用的是非常口语化的一句话：“给我生成一个团队项目进度管理面板，能看到每个项目的状态、负责人、进度和风险。”

第一轮，不加载Skill，直接让模型生成。结果是典型的“模板全家桶”：左侧深色侧边栏（菜单项全部是整齐的图标加文字），顶部白色导航条，主区域是三列等宽卡片，每张卡片里一个进度条加一个绿色“进行中”标签。功能倒是齐全，但一眼就能看出是AI生成的界面。

第二轮，加载了anti-template-ui Skill。生成的页面结构变成了：顶部是一整条全深的棕色横贯导航区，所有项目信息放在一个不对称的分栏容器里，左边是重点项目的详细时间线与风险清单，右侧是一个紧凑的项目状态统计面板。字体用的是带有明显锐利感的衬线标题体，背景是轻微偏黄的米白色，主色是暗棕橙色。整体风格明显有了“定制感”，甚至有些像独立开发者喜欢用的那种暗调质感面板风格。

4.2 关键词覆盖率对比：模板特征如何被压制

我用一个粗糙但直观的统计方式对比两版结果——检查页面上有多少个模板特征点。特征点包括：左侧固定导航栏、等宽卡片网格、胶囊按钮、柔和全卡阴影、蓝色主色、白色背景、默认线性图标。不含Skill的那版命中了6/7个，只差一个蓝色主色没有出现（它用的是偏绿的颜色）。加载Skill的版本只命中1个（默认线性图标），因为图标模块我还没找到很好的替代策略，目前是允许混用几何装饰元素。

这个对比说明，Skill确实能把模型的默认行为硬掰过来。而且不只是“看起来不一样”，连设计决策的底层逻辑都变了。没加载Skill时，AI考虑的是“怎么把功能安排清楚”；加载后，它考虑的是“怎么在功能清晰的基础上，建立起一种统一且有辨识度的视觉语言”。

4.3 在实际Agent工作流里，效果同样稳定

单次生成测试通过之后，我又把它接进了一个实际项目里——一个自动生成营销活动页的Agent工作流。这个流程需要AI依次完成文案、页面结构、视觉设计、响应式适配，最后输出可部署的HTML文件。以前这个流程最头疼的点就是，每次生成的几个页面模板感过于雷同，哪怕是不同主题的活动页，视觉上都能看出是同一个流水线出来的。

挂载Skill包之后，这个现象得到了明显改善。Agent在读取了design-tokens和reference-examples之后，不同主题的页面会从色板、字体、布局三个维度自动做出区分。比如一个咖啡品牌活动和一个小型科技讲座的页面，一个是暖棕调编辑风，另一个是墨绿调工业风，结构上也不再有“复制粘贴感”。这是Skill在Agent化工作流里最大的价值：把审美一致性从“碰运气”变成“默认配置”。

5. Skill包的高阶玩法：从“界面风格”扩展到“产品气质”

5.1 你已经体验了Skill包改变界面的力量，接下来怎么让它工作得更顺手

写完第一版Skill包之后，我给自己定了几个使用的“黄金规则”，按重要程度排列一下：

• 要写清触发条件。如果触发条件写得太大而全，Agent会动不动就加载Skill，场景不匹配时反而拖慢生成速度，甚至让界面为了“不模板化”而变得过于刻意。我的边界是“和视觉呈现相关的任务才加载”。

• 参考案例只需2到3个。有人觉得案例越多越好，实测下来案例超过5个会让Agent在选择时产生混乱，生成结果反而变成“多个参考的混合体”，结构不伦不类。2到3个高质量、风格差异明显的案例是最舒服的状态。

• 禁忌清单要和正向描述配合。如果只给禁忌，没有给出替代方案，模型有时候会陷入“我不知道该怎么做”的保守状态，生成的界面虽然不模板了，但变得单调谨慎，甚至结构过于简单。所以我在design-tokens里写了正向替代方案，在forbidden-patterns里写不能做什么，两者结合才是完整约束。

• Skill要定期迭代。设计趋势在变，模型的统计偏好也在变。我每隔一个月会去观察一次chatgpt、Claude这类主流模型新生成页面的风格变化，发现“新的默认模板样式”之后，就会把对应的禁忌项加进去。比如过去半年里，“玻璃拟态卡片”“超大空白留白中间一行小字”“毛玻璃导航条”都已经成了新的AI味特征。

5.2 拆解Skill子任务：把设计流程拆成“测、选、改、查”四步

如果你不想用我这种“一个大包搞定所有风格”的思路，也可以把Skill往“工作流编排”的方向做。我看到有些人会把它拆成四个子Skill：第一个负责分析需求并生成设计Tokens；第二个负责从Tokens生成HTML骨架；第三个负责视觉细节强化；第四个负责终稿检查。

这种拆分方式的优势在于，每个环节的输入输出都很明确，Agent的每一步都更可控。缺点也很明显：多个Skill之间的上下文传递可能出现信息丢失。比如生成Tokens的Skill和生成HTML的Skill如果没在同一个上下文窗口内，Agent可能会漏掉之前设定好的色板规则。

我目前用的是折中方案：一个主Skill负责“视觉规范+执行流程”，把设计Tokens、禁忌清单都写在里面；另外再单独放一个“终稿检查”的子Skill，只干一件事——在输出最终界面之前，检查是否命中了禁忌清单里的内容。这样既不会把职责切得太碎，又能在最后卡一道质量关口。

5.3 同一套Skill跨工具移植的技巧

我试用过几个主流AI编程环境来运行Skill包。不同工具对Skill目录的规范有细微差异，但核心逻辑是通用的。

以Codex这类支持Skill加载的工具为例，它们通常会在项目里设定一个固定目录（比如.skills或.skill），直接把你的Skill文件夹放进去就行。而OpenCode、Claude Code这类工具也大同小异，关键是SKILL.md文件的内容要写得逻辑完整，因为所有平台都是靠这个文件的描述来决定“何时触发”和“如何执行”的。

如果你的工具暂时不支持自定义Skill目录，也有一个过渡方案：把SKILL.md和design-tokens.md的内容直接粘贴到系统提示词或项目提示词里，作为所有对话的默认上下文。虽然不像真正的Skill那样按需加载，但对单项目来说，效果也能到位。我已经遇到过有人用这种“伪Skill”方式，把同一套界面设计准则用在了好几个内部工具上，结果相当不错，至少比放养式提示词稳定得多。

6. 安装和验证Skill包的时候，最常见的坑有哪些

6.1 Skill加载了但没生效，页面还是老样子

这个是遇到最多的问题。表面看是“Skill不生效”，实际排查下来，大概率是SKILL.md里的触发条件写得不够明确，或者Agent在任务拆解时没有把“界面生成”归到这个Skill的负责范围里。

我调试的方法是：在SKILL.md开头加上一行强制指令，比如“当你准备生成任何HTML页面或CSS样式定义时，必须先读取本文件并严格遵循其中所有规则”。这行话对应的效果是，哪怕模型在推理时不确定该不该加载Skill，看到这条指令后也会被拉回正轨。

6.2 生成结果倒是非模板了，但可用性变差了

这是另一个很典型的反面效果。有些界面为了打破模板结构，结果做出了一些看起来很酷但用户根本不知道怎么操作的布局。比如非对称分栏做得太极端，导致核心操作按钮被挤到视线边缘；或者过于强调视觉冲击，把表格信息处理成了难以阅读的图形化样式。

我的经验是：在Skill里增加“可用性底线”条款。明确要求“打破布局规则的前提是：核心操作路径仍然清晰可见，信息层级仍然一目了然”。说白了，反模板追求的是“有辨识度的可用设计”，而不是“为怪异而怪异的艺术展品”。

6.3 不同模型对同一份Skill的服从度不同

用同一个Skill包分别跑GPT系列和Claude系列，执行效果的差异非常明显。有些模型忠实度很高，会逐条按照Skil的规则执行；有些模型更“随性”，在细节处容易忽略禁忌。

应对方案是：在同一份SKILL.md文件里，把“执行检查”步骤重复写两遍，一遍在开头任务说明，一遍在末尾输出前检查。这套方法虽然简单但非常有效，相当于给模型加了一层自我提醒机制。

6.4 Skill包体积变大后，运行效率下降

当你给Skill加了很多参考案例和设计资料之后，它会显著占用上下文窗口，导致Agent需要更长的处理时间，甚至偶尔把不相关内容挤掉，影响其他功能执行。

以前我会加载一堆精心挑选的参考资料，每个都想让Agent借鉴一点。后来发现真正有用的就那几个，资料放多了反而让Agent抓不住重点。现在我严格控制每个Skill包的总阅读量：SKILL.md控制在60行以内，design-tokens控制在40行以内，参考案例最多3个，禁忌清单保持在15条以内。这个体量能让Agent在1分钟之内完成加载和消化，执行效果也是最好的。

7. 这个方向还能怎么玩：从界面生成到全链路技能化

我现在已经不只是把Skill用在界面生成上了。比如我最近在尝试的一个方向是“界面生成 + 产品文案”的联合Skill：生成界面时，文案由同一个Agent基于它读过的参考案例里的语气来写，这样文案风格和视觉气质能保持一致，不会出现一个极简编辑风格的页面装着一堆“赋能、抓手、闭环”这类黑话文案的情况。

还有人在做品牌规范Skill，把一套完整的VI规范写进Skill包，任何AI生成的物料都严格按照这个规范来。这样就等于把“品牌外包设计师”塞进了Agent的工具箱里，每次生成都有稳定的品牌基因。

这些东西本质上都在做同一件事：把人类在某一领域的隐性经验，结构化地注入到Agent的工作流中，让它不用靠猜、不用靠运气，就能稳定地产出中高水平的结果。

对我个人来说，写Skill包这个习惯带来的改变是，我对待AI的方式完全变了。以前我是“提需求的人”，现在我是“定义标准的人”。之前总在焦虑AI会取代什么，现在反而踏实了——因为无论模型的能力边界怎么扩张，如何把行业经验和品味翻译成Skill规则，这件事本身依然需要人的判断力。