之前做 AI 落地页和作品集站点时我最大的感受不是“生成不出来”而是“生成出来的东西一眼假”。同样是一张 Hero 图、一套栅格、一段主标题不管是 ChatGPT 还是其他大模型产出的页面拿掉 logo 之后几乎长得一模一样。后来社区里开始流行 “Skill” 这个说法也就是把某类重复性的能力封装成可复用、可配置的“技能包”。当看到 taste-skill 这个项目被反复讨论时我意识到大家真正想解决的不只是“AI 能不能写代码”而是“AI 能不能按人的审美偏好稳定地产出有风格的页面”。本文会围绕 taste-skill 展开聊清楚这几件事AI 网页为什么会有“模板味”根因在哪里。Skill 机制和普通 prompt 有什么区别。taste-skill 是怎么把“品味”变成可复用配置的。从零跑通一个带 taste 风格的 AI 网页生成流程。如何写自己的第一个 Skill以及实际落地时的排错思路。文章适合被 AI 生成内容折磨过的前端开发者、AI Agent 方向的技术同学以及想把自己设计规范沉淀成“技能包”的产品团队。1. 模板味是什么taste-skill 在解决什么问题1.1 先给“模板味”下一个定义“模板味”不是骂人的话它是 AI 生成内容时表现出来的一种统计倾向。大模型在预测下一个 token 时会优先选择训练数据中出现频率最高的组合。网页设计相关的训练语料里大量出现了“居中的 hero 标题 三栏特性卡片 圆角按钮 白色背景 浅灰页脚”这类结构模型生成的页面自然就往这个方向收敛。模板味的典型表现包括页面结构千篇一律永远是一屏 Hero、三段特性、一张产品截图、一个 FAQ。视觉风格趋同按钮全是圆角渐变卡片全是阴影字体全是系统默认。文案空泛“让世界更美好”“赋能每一个人”“开启全新体验”。缺少决策痕迹看不出这个页面为什么用绿色而不是橙色为什么用大字号标题而不是小字号搭配图片。一句话总结模板味是“多数人平均值”带来的平庸感而不是能力不够。1.2 taste-skill 项目的基本定位taste-skill 可以理解为一套“把审美偏好打包成 AI 可调用 Skill”的开源方案。它之所以能拿到很高的 Star 数并不是因为它是一个多复杂的框架而是因为它踩中了一个普遍痛点很多开发者发现单纯在 prompt 里写“请设计得有品味一点”没用模型对“品味”这个词的理解太模糊。你需要的不是一句口号而是一套可执行的规则比如正文用什么字号、什么行高。哪些地方必须留白而不是一味填充。主色调的明度和饱和度控制在什么范围。什么时候允许用卡片什么时候应该打破卡片。标题层级之间用什么对比度来拉开差距。taste-skill 做的事情就是把这类规则写进 Skill 文件然后在每次生成网页时自动加载让模型在固定的审美框架下做输出。需要注意的是不同 AI Agent 平台对 Skill 的封装格式不完全一致。taste-skill 这类项目的价值更多在于提供了一种“组织品味规范”的思路而不是绑定某一家厂商的 API。新手拿到手之后大概率还是要根据自己的模型和工具链做少量适配。1.3 它的适用场景从实际使用来看taste-skill 适合以下场景个人网站、作品集、落地页的批量生成。团队内部沉淀设计规范避免每个成员问 AI 时都从零描述风格。用 AI 批量产出多版本设计方案再人工挑选微调。培养 AI Agent 的前端审美让它生成的页面能直接被设计师采纳。反过来说如果你的目标只是快速堆一个能跑的页面不关心视觉风格那直接使用现成低代码平台会更高效没有必要引入 Skill 体系。2. 准备工作和基础概念2.1 Skill 在 AI Agent 中的定位在继续说 taste-skill 之前需要先理清 Skill 的概念。Skill 是一种结构化的能力模块。它通常包含元信息名称、描述、适用场景。使用说明告诉模型在什么情况下加载这个技能。规则与约束风格、格式、输出要求。可选示例给模型一个“做对了是什么样子”的参照。和普通 prompt 相比Skill 有三个明显优势复用性定义一次之后可以在多个项目里反复引用。可维护性审美规则变了只需要改 Skill 文件不用改每一个对话。组合性可以把文案风格、视觉风格、代码风格拆成多个 Skill按需组合。taste-skill 正是利用这种机制把“审美”做成了可维护、可组合的配置项。2.2 运行环境说明由于 taste-skill 最终的输出面向网页我建议先准备以下环境Node.js 18 或更高版本用于跑脚本和本地静态服务。Python 3.9 或更高很多 Skill 管理脚本是用 Python 写的顺手一点。一个支持 Function Calling 或系统提示词的大模型 API例如 OpenAI、Anthropic、国内大模型平台都可以。本地目录工具用于管理 Skill 文件。版本不需要完全照抄重点是把 Node 和 Python 装好能运行脚本和请求 API 就行。下面的实战示例会以文件配置为主不绑定特定框架。2.3 项目目录结构一个典型的 taste-skill 项目目录可以这样组织taste-skill-demo/ ├── skills/ │ ├── web-taste/ │ │ ├── SKILL.md │ │ ├── taste-profile.yaml │ │ └── examples/ │ │ ├── landing-page.md │ │ └── portfolio.md ├── output/ ├── scripts/ │ └── generate.py └── prompts/ └── user-request.mdskills存放所有可复用技能。output存放 AI 生成的 HTML 页面。scripts存放调用模型的脚本。prompts存放临时需求描述。这个结构并不是强制标准但它能让你在技能变多之后依然清楚每个文件的作用。3. 核心机制拆解taste-skill 是怎么起作用的3.1 从“一句话描述”到“结构化 taste profile”先看两种写法的区别。普通方式请帮我设计一个高端的落地页要有品味。模型收到之后只能根据“高端”“品味”这些模糊词去猜结果就是你我都知道的模板味。taste-skill 的方式请根据 taste-profile.yaml 中的风格定义生成一个落地页。注意 - 字体比例使用 1.25 的 Major Third。 - 主色使用低饱和度的鼠尾草绿不建议使用纯黑。 - 卡片之间保留充足的呼吸感。 - 标题采用 editorial 风格突出对比而不是居中。虽然最终还是要经过大模型输出但这一步把“品味”拆解成了可检查的规则。taste-skill 的核心就是先把模糊的审美描述翻译成结构化配置再让模型执行配置。3.2 taste-profile 的常见组成下面是一个简化版的 taste-profile 示例它可以作为你自定义 Skill 的起点taste-profile: palette: primary: #6B8E6B secondary: #F2EFE9 accent: #B5651D text: #2B2B2B typography: heading_font: Georgia, serif body_font: system-ui, sans-serif scale_ratio: 1.25 base_size: 16px layout: style: editorial-grid max_width: 1200px white_space: airy components: card: border_radius: 4px shadow: none button: border_radius: 2px style: outline hero: alignment: left-aligned background: texture-paper这些内容看起来简单但它是后面所有生成行为的总纲。模型读取到border_radius: 2px就不会把按钮做成常见的 100px 圆角胶囊读取到shadow: none就不会给卡片随意加阴影。3.3 完整生成链路一次使用 taste-skill 的生成流程可以拆成五步加载 Skill把SKILL.md和taste-profile.yaml注入到系统提示词中。读取用户需求明确要生成的是落地页、作品集还是博客页。Agent 规划结构根据页面类型确定内容模块。生成 HTML/CSS算法层结合 taste-profile 生成页面。自检并迭代把生成结果和规则对比不满足时做修正。这个流程本身不复杂复杂的地方在于第 4 步和第 5 步。taste-skill 提供的规则越具体模型输出的方差就越小。3.4 为什么不能只靠“更长的 prompt”有人可能会问我把上面这些规则直接写进系统提示词不也一样能解决模板味吗理论上是可行的但工程上不推荐。原因有三点提示词膨胀多个项目、多种风格的规则全部堆在一个 prompt 里很快就会超出上下文窗口还会互相干扰。不可复用换一个项目所有规则都要重新组织。不可测试规则混在对话历史里很难追踪是哪一条规则导致输出发生变化。Skill 的本质是把提示词工程从“一次性对话”升级为“版本化配置”。这是 taste-skill 这类项目最有价值的地方。4. 实战案例分析用 taste-skill 生成一个非模板化落地页下面我们完整走一遍流程从创建目录到最终生成一个简单但风格明确的落地页。4.1 创建项目目录执行下面的命令mkdir -p taste-skill-demo/skills/web-taste/examples mkdir -p taste-skill-demo/output mkdir -p taste-skill-demo/scripts cd taste-skill-demo4.2 创建 Skill 定义文件在skills/web-taste/SKILL.md中写入--- name: web-taste description: 为 AI 网页生成过程注入编辑设计风格避免模板化视觉输出。 --- # Web Taste Skill ## 适用场景 生成落地页、作品集、个人主页、营销单页时本 Skill 提供统一的视觉品味约束。 ## 使用方式 读取同一目录下的 taste-profile.yaml严格按照其中的 palette、typography、layout 和 components 配置输出 HTML/CSS。 ## 硬性约束 1. 不使用默认系统渐变按钮除非 taste-profile 明确允许。 2. 卡片阴影默认关闭使用留白和细边框区分层级。 3. 主标题不强制居中优先使用左对齐加大字号对比。 4. 正文行高保持在 1.7 到 1.9避免拥挤。 5. 全文只使用 taste-profile 中定义的色板。 6. 视觉层级通过字号、字重、留白实现而不是通过堆阴影和渐变。再在skills/web-taste/taste-profile.yaml中写入前面给出的 taste-profile 配置。4.3 编写调用脚本这里给一个 Python 示例作用是把 Skill 文件和用户需求组合起来发给大模型 API。不同平台的请求格式有差异下面代码以 OpenAI 风格为参考。import os import requests API_KEY os.environ.get(LLM_API_KEY, your-api-key) API_URL os.environ.get(LLM_API_URL, https://api.openai.com/v1/chat/completions) MODEL os.environ.get(LLM_MODEL, gpt-4o-mini) def read_file(path): with open(path, r, encodingutf-8) as f: return f.read() def build_system_prompt(skill_dir): sk read_file(os.path.join(skill_dir, SKILL.md)) profile read_file(os.path.join(skill_dir, taste-profile.yaml)) return f{sk}\n\n以下是 taste-profile.yaml 的内容\n\n{profile} def generate_page(user_request): system_prompt build_system_prompt(skills/web-taste) payload { model: MODEL, messages: [ {role: system, content: system_prompt}, {role: user, content: 需求 user_request \n请直接输出完整 HTML使用内联 CSS 或独立 style 标签不要输出多余解释。} ], temperature: 0.8 } headers {Authorization: fBearer {API_KEY}} resp requests.post(API_URL, jsonpayload, headersheaders) resp.raise_for_status() return resp.json()[choices][0][message][content] if __name__ __main__: req 一个给独立开发者用的轻量笔记工具落地页强调安静、克制、长时间使用不疲劳。 html generate_page(req) with open(output/landing.html, w, encodingutf-8) as f: f.write(html) print(生成完成输出文件output/landing.html)运行前先把 API Key 配置到环境变量export LLM_API_KEYyour-key python scripts/generate.py如果你的模型平台请求方式不同只需要改build_system_prompt和请求 payload 两个地方Skill 文件本身可以不动。4.4 运行与预期结果运行脚本之后output/landing.html应该是一个完整的 HTML 页面。由于 taste-profile 里限制了字体为 Georgia system-ui按钮为 outline 风格主色为鼠尾草绿生成结果大概率不会出现典型的紫色渐变按钮和全屏居中 hero。如果结果仍然有模板味第一个要检查的是模型有没有真的读完 taste-profile。可以打印 system prompt 的内容确认文件加载成功也可以在请求里直接附加一句“请先用 50 字说明你打算如何应用 taste-profile”。这一步虽然多花一次调用但对调试非常有帮助。4.5 验证是否摆脱模板味判断页面是否脱离模板味可以按下面的清单自查页面主色是否完全来自 palette有没有出现 palette 之外的亮紫、荧光蓝。按钮风格是 outline 还是渐变胶囊。卡片是否依赖边框和留白划分而不是统一灰色阴影。主标题是左对齐还是居中字号层级是否拉开。页面里有没有“赋能”“开启新时代”这类空泛文案。如果以上五项都通过了说明 taste-skill 真正起了作用如果只有一两项通过建议从第 5 章的“自定义 Skill”入手把规则写得更细。5. 怎么编写一个属于自己的 Skill很多项目用 taste-skill 一段时间后会希望调整成自己的品牌风格。这时候就需要写自定义 Skill。5.1 Skill 文件的基本结构一个最小 Skill 至少包含两部分元信息 规则正文。--- name: brutalist-portfolio description: 适用于设计师个人作品集特征是大字号、高对比、不圆角、粗边框。 --- # Brutalist Portfolio Skill ## 规则 1. 页面使用无衬线字体标题字号至少 64px。 2. 所有元素圆角设置为 0。 3. 使用粗黑边框区分内容区域。 4. 背景以米白色为主强调色只用高饱和红色。 5. 不允许渐变、阴影、玻璃拟态效果。 6. 图片使用黑白滤镜除非是作品实际截图。5.2 增加示例比增加规则更有效大模型对抽象规则的理解是有上限的。与其写很多条“不要太圆润”不如给一个符合审美的具体示例。比如在examples/下放一个简短的 Markdown 描述页面风格参考 - 类似 1990 年代音乐厂牌网站。 - 大标题像海报印刷文字边缘锐利。 - 导航使用下划线链接不包裹在卡片中。这些示例不是给用户看的而是给模型做 few-shot 参照。规则描述的是“不能做什么”示例描述的是“应该长什么样”两者配合效果最好。5.3 让 Skill 真正生效的四个细节第一个细节description 要写清楚触发条件。模型判断“什么时候该用这个 Skill”靠的就是这段描述。描述写成“适用于所有页面”没有意义要写成“适用于设计师个人作品集”这种有边界的表述。第二个细节规则尽量写成否定句 肯定句的组合。“不要使用阴影”和“改用细边框区分卡片”一起出现模型执行起来更明确。第三个细节taste-profile 中的数值要给出具体值比如border_radius: 4px而不是border_radius: 小一点。大模型对模糊描述的输出方差非常大。第四个细节Skill 文件不要超过 300 行。规则太多时模型容易顾此失彼。建议把最重要的 5 到 10 条规则放在最前面次要规则放到后面。6. 常见问题与排查思路6.1 问题汇总表问题现象常见原因解决思路生成的页面还是模板味模型没有加载 SKILL.md打印 system prompt确认 skill 内容进入上下文风格不稳定两次结果差异大temperature 设置过高降低到 0.5 到 0.7 区间颜色总是超出 palette规则没有硬性禁止增加“只允许使用 palette 中的颜色”这类绝对化语句按钮还是圆角渐变taste-profile 与 SKILL.md 约束冲突在 SKILL.md 中增加“组件优先级高于模型默认习惯”Skill 文件容易被忽略模型上下文过长注意力被稀释把关键规则放在 system prompt 最前面生成 HTML 代码有不完整标签输出长度受限要求“可以省略图片素材用占位元素”减小单次生成压力中文文案风格还是空泛缺少文案规则单独写一份 copywriting-skill与视觉 skill 组合使用6.2 高频问题的深层排查模板味依旧是最常见的问题但它其实有两种情况。第一种是 Skill 根本没被模型读到。这种情况通常发生在直接把 Skill 放在用户消息里位置太靠后模型在生成到一半时已经遗忘了。解决办法是把 Skill 内容放到 system 角色消息中并放在最前面。第二种是模型读到了规则但执行能力不足。比如规则写着“主色调为鼠尾草绿”模型真的生成了一个绿色但它不知道鼠尾草绿应该偏灰、饱和度不能高。这时候需要把色值写出来把饱和度指标写出来而不是依赖模型对颜色名词的理解。如果你用了很多规则仍然无效建议先做一个最小验证只保留一条规则比如“所有按钮圆角必须为 0不允许出现其他设计”看模型是否严格遵守。如果这一条都不能执行问题可能出在模型本身对前端代码的遵循能力上而不是 Skill 文件写得不对。7. 最佳实践与工程建议7.1 把审美规则当成代码来维护taste-skill 的核心思想是“审美即配置”。既然审美变成了配置就应该用代码管理的标准来对待它Skill 文件纳入 Git 仓库每次修改都留下记录。给不同项目建立独立的 taste-profile而不是所有项目共用一份。设置版本号例如web-taste-v1、web-taste-v2方便回退。每次改动规则后用同一段用户需求重新生成一版页面直观对比变化。7.2 设计可评估的验收指标审美这个东西听起来主观但在工程上仍然可以量化。我建议团队这样验收颜色外溢次数生成的 CSS 中有多少处颜色值不属于 palette。组件违规次数有多少按钮或卡片违反了圆角或阴影约束。结构同质率和上一版生成页面的结构相似度有多高。人工审美评分让设计师按 1 到 5 分快速打分。前三个指标可以用脚本自动跑最后一个指标人工负责。没有评估就没有优化方向。7.3 关注上下文和成本控制每增加一个 Skill都会增加 token 消耗这是躲不开的工程成本。优化方向有两种。第一种是精简规则把可有可无的描述删掉只保留影响视觉本质的规则。第二种是按场景按需加载比如用户明确要“作品集页面”时才加载 portfolio-skill而不是把全部 Skill 一次塞进上下文。在成本敏感的场景里可以先让模型输出一个精简版 HTML确认风格没问题后再让模型丰富内容分步生成比一次生成更省钱也更可控。7.4 安全与授权提醒如果你打算在大模型 API 调用中使用模型生成代码甚至是后端自动生成页面需要注意以下几点不要把 API Key 硬编码到仓库里使用环境变量或密钥管理平台。生成结果要经过安全过滤防止模型输出包含恶意脚本或异常外链。涉及内网资源、用户数据、数据库操作的场景必须走正规鉴权流程不要从生成的页面里偷偷读接口。批量生成或自动化发布时要设置人工审批环节避免脏数据直接上线。大模型生成的代码只是半成品工程化落地需要人把手放在发布按钮上。7.5 组合 Skill 而不是编写零散 prompt当项目的规则越来越复杂以后比较好的做法是维护一组互相独立的 Skillvisual-taste控制视觉风格。copywriting-taste控制文案语气。layout-taste控制结构节奏。accessibility-rules控制可访问性。需要生成落地页时组合 visual-taste 和 copywriting-taste需要生成文档站时组合 layout-taste 和 accessibility-rules。这种组合方式比每需求写一套 prompt 更干净。8. 下一步可以做什么taste-skill 真正想解决的问题并不是“让所有 AI 网页都好看”而是让“好看”变成一个可以被定义、被复用、被迭代的对象。这类项目能拿到高 Star说明开发者对模板化 AI 输出的容忍度已经降到了最低。如果你打算在自己的项目里落地这个思路我建议从这三个方向入手先给一个已有一致风格偏好的页面类型比如个人主页把 taste-profile 写出来。再用脚本跑一次完整生成确认 Skill 真的生效。最后把规则按视觉、文案、结构拆成多个 Skill逐步扩展。这样一套流程走完你大概就能感受到所谓“品味”不是一个玄学词而是一组可以被测试和迭代的工程约束。AI 网页的模板味不会因为装一个 Skill 就彻底消失但至少它不像以前那样无解了。