1. 当"AI味"成为前端交付的新痛点
做前端这些年，我经历过几个明显的审美阶段。最早是"能跑就行"，页面丑点无所谓，功能对了就交差。后来是"像素级还原"，设计稿给什么就切什么，多一个像素都要跟设计师掰扯半天。再往后是"组件化、设计系统"，大家开始讲究一致性、可维护性。而最近一两年，我明显感觉到一个新的评价维度冒了出来——"AI味"。
这个词你可能在团队评审、代码走查、甚至面试里都听过。它不是说你的代码是AI写的，而是说你的产出——页面、交互、文案、动效、甚至代码结构——透着一股"模板化、套路化、没有判断力"的气息。典型症状包括：满屏的渐变紫、圆角卡片堆叠、无意义的微动效、千篇一律的"欢迎使用XX系统"、按钮文案永远是"确定/取消/提交"。用户一眼看过去，说不上哪里错，但就是觉得"这东西像是批量生成的"。
而这次要聊的Taste Skill，以及它背后那套Agent Skills / SKILL.md的机制，恰恰是冲着这个痛点来的。它想解决的不是"AI能不能写前端"，而是"AI写出来的前端，怎么才能有品味、有判断、不像流水线产品"。关键词里那一串——Taste Skill、Agent Skills、SKILL.md、ai前端skill——指向的是同一件事：给AI Agent装上一套可复用、可组合、带审美判断的"技能包"，让它在做前端时不再只会套模板。
这篇文章我不打算写成产品说明书。我想从一个一线前端的视角，把这件事拆开讲清楚：Taste Skill 到底在解决什么问题、SKILL.md 这套机制为什么值得关注、它和传统组件库/设计系统的区别在哪、实际落地时会踩哪些坑、以及我实测下来觉得真正有用的几个操作细节。不管你是刚入行的前端，还是带团队的技术负责人，只要你在意"产出质量"这件事，这篇都值得看完。
2. Taste Skill 到底在解决什么：从"能生成"到"有判断"
2.1 传统AI生成前端的三个死穴
先说清楚问题，才能理解方案。我用过不少AI辅助生成前端的工具，从早期的代码补全，到后来的整页生成，再到现在的Agent式开发。它们普遍有三个死穴。
第一个死穴是"平均化审美"。AI的训练数据是海量网页的集合，它学到的是"最常见的做法"，而不是"最合适的做法"。所以它生成的页面天然趋向于平均值——大家都用蓝色主色，它就蓝色；大家都用卡片布局，它就卡片。结果就是所有AI生成的页面长得越来越像，这就是"AI味"的根源。它没有"这个场景该不该用卡片"的判断，只有"卡片出现频率高"的统计。
第二个死穴是"缺乏上下文感知"。一个后台管理系统和一个面向C端的营销页，审美逻辑完全不同。前者要信息密度高、操作路径短、视觉克制；后者要情绪张力、视觉冲击、引导转化。但很多AI工具对这两者用的是同一套生成逻辑，因为它没有把"业务场景"作为一等公民纳入决策。
第三个死穴是"不可控、不可复用"。你这次调教出一个满意的风格，下次开新项目又得重新来一遍。经验没法沉淀，判断没法传递。团队里张三的审美和李四的审美对不齐，AI生成的东西自然也对不齐。
2.2 Taste Skill 的核心思路：把"品味"变成可执行的技能
Taste Skill 的思路，我理解下来是这样一句话：把资深前端脑子里那些"说不清但就是知道"的审美判断，拆解成结构化的、可被Agent调用的技能单元。
这跟传统设计系统不一样。设计系统管的是"颜色、间距、字号这些原子怎么定"，它解决的是"一致性"问题。但 Taste Skill 管的是"什么时候该用什么、什么时候不该用什么"，它解决的是"判断力"问题。前者是词典，后者是语法。
举个具体例子。设计系统会告诉你"主色是 #1677FF，圆角是 8px"。但 Taste Skill 会告诉你："在数据密集型表格页面，圆角不要超过 4px，因为大圆角会让密集信息显得松散；在营销落地页，主按钮可以用更大的圆角和更强的阴影，因为要制造点击欲望。"这就是判断，是设计系统给不了的。
而承载这些判断的载体，就是SKILL.md。它本质上是一个结构化的技能描述文件，用自然语言加少量约定格式，把一个技能"是什么、什么时候用、怎么用、有什么禁忌"讲清楚。Agent 在执行任务时，会读取这些技能文件，把它们作为决策依据。
2.3 为什么是"Skill"而不是"Prompt"
这里有个关键区别值得说透。很多人第一反应是：这不就是写个更长的 Prompt 吗？不是。
Prompt 是一次性的、任务级的指令，用完就散了。而 Skill 是持久化的、可组合的、可版本管理的能力单元。你可以把 Skill 理解成给Agent装的"插件"或者"肌肉记忆"。它有几个特性是 Prompt 给不了的：
- 可组合：一个页面生成任务，可以同时调用"布局技能""配色技能""文案技能""动效技能"，它们各自独立又互相配合。
- 可复用：写一次，所有项目都能用，团队共享。
- 可迭代：发现某个判断不对，改 SKILL.md 就行，不用改代码。
- 可解释：Agent 为什么这么决策，你能从它调用了哪个 Skill 反推出来。
这几点加起来，才让"品味"这件事从玄学变成了工程。
3. SKILL.md 的写法：一份能落地的技能描述长什么样
3.1 一个技能文件的最小结构
我实测下来，一个能真正被 Agent 用起来的 SKILL.md，至少要包含四块信息：技能名与适用场景、核心判断规则、正反例、禁忌清单。缺了哪块，Agent 用起来都会跑偏。
先看结构，我用一个"后台表格页视觉技能"举例：
# Skill: Dense Table Visual ## When to use 数据行数超过 20 行、需要批量操作、用户以效率为第一诉求的后台页面。 ## Core rules - 行高控制在 40-44px，超过 48px 会显著降低一屏信息量 - 斑马纹与分割线二选一，不要同时用 - 操作列固定在右侧，超过 3 个操作收进"更多" - 状态标签用色要克制，同一屏不超过 3 种语义色 ## Good example （附一张符合规则的截图或代码片段） ## Bad example （附一张违反规则的截图或代码片段） ## Never - 不要在表格里用大面积渐变背景 - 不要给每一行加独立阴影 - 不要用超过 2 种字体这个结构看起来简单，但每一块都有讲究。When to use决定了 Agent 什么时候该调用它，写得太宽会滥用，写得太窄会漏用。Core rules是核心，必须是可判断的，不能是"要好看"这种废话。Good/Bad example是给 Agent 的锚点，比纯文字描述有效得多。Never是兜底，防止 Agent 在边界情况下乱来。
3.2 判断规则怎么写才"可执行"
这是最容易翻车的地方。我见过太多 SKILL.md 写成了设计原则宣言，比如"保持视觉层次清晰""注重用户体验"。这种话对 Agent 来说等于没说，因为它没法判断"清晰"的标准是什么。
可执行的规则，必须满足两个条件：有明确的触发条件，有明确的动作或阈值。
对比一下：
| 不可执行的写法 | 可执行的写法 |
|---|---|
| 间距要合理 | 卡片内边距用 16px 或 24px，不要用 20px 这种中间值 |
| 颜色要协调 | 主色饱和度不超过 80%，辅助色与主色色相差不超过 60 度 |
| 动效要流畅 | 入场动效时长 200-300ms，缓动函数用 ease-out，不要用 linear |
| 文案要简洁 | 按钮文案不超过 4 个字，标题不超过 12 个字 |
右边这列，Agent 拿到之后是能直接执行和校验的。左边那列，它只能靠猜。这就是"品味工程化"的关键——把模糊的审美直觉，翻译成带阈值的规则。
3.3 正反例为什么比规则本身还重要
我一开始也觉得，规则写清楚就够了，例子是锦上添花。实测下来完全不是。例子对 Agent 的约束力，往往比规则更强。
原因是，规则是抽象的，Agent 在具体场景下需要做映射，映射过程容易失真。而例子是具体的，Agent 可以直接做模式匹配。你给它一个"好的表格长什么样"的截图或代码，它在生成时就有了一个明确的参照物，跑偏的概率大幅降低。
我的做法是，每个核心技能至少配一组正反例，而且反例要选那种"看起来很合理但其实是错的"——这种反例最有价值，因为它能纠正 Agent 的"平均化审美"倾向。比如"给表格每行加轻微阴影"这件事，看起来挺精致，但在密集数据场景下就是灾难，这种反例写进去，Agent 下次就不会犯。
提示：正反例尽量用真实项目里的截图或代码片段，不要用网上随便找的。因为真实案例里包含了你的业务上下文，Agent 学到的判断更贴合你的实际需求。
4. 把 Taste Skill 接进工作流：我的实际落地路径
4.1 从"单点试用"到"团队共享"的三步走
很多人一上来就想搞一套完整的技能体系，结果写了几十个 SKILL.md，Agent 反而不知道该用哪个，效果还不如不接。我的建议是分三步走，别贪快。
第一步，单点突破。先挑一个你团队最常做、最痛、最容易出"AI味"的场景，比如后台列表页，只写一个技能文件，把它打磨到 Agent 用起来确实有效。这一步的目标是验证机制，不是铺量。
第二步，横向扩展。单点跑通后，围绕同一个业务域扩展。比如列表页跑通了，再加表单页、详情页、弹窗。这几个技能之间会有共享的判断（比如间距体系、色彩克制原则），可以抽出来做成"基础技能"，被其他技能引用。
第三步，团队共享与版本管理。把技能文件放进 Git 仓库，像管理代码一样管理它。谁发现某个判断不对，提 PR 改。定期 review，把过时的规则删掉。这一步做完，团队的审美判断才真正沉淀下来了。
4.2 技能之间的组合与优先级
实际生成一个页面时，往往要同时调用多个技能。这时候就有一个优先级问题：布局技能说"要留白"，密度技能说"要紧凑"，听谁的？
我的处理方式是给技能分层：
- 基础层：色彩、字体、间距这些全局规则，优先级最高，所有场景都生效。
- 场景层：表格、表单、营销页这些特定场景规则，优先级次之。
- 任务层：本次任务的具体要求，优先级最低，但可以覆盖上面两层。
Agent 在决策时，从基础层往下逐层应用，遇到冲突时下层覆盖上层。这样既保证了全局一致性，又保留了场景灵活性。这个分层逻辑本身也可以写进一个"元技能"里，告诉 Agent 怎么处理技能冲突。
4.3 怎么判断技能"生效了"
接了技能之后，怎么知道它有没有用？不能靠感觉。我一般看三个指标：
- 返工率：生成出来的页面，需要人工大改的比例。这个降下来，说明技能在起作用。
- 一致性：不同人、不同时间生成的同类页面，风格是否统一。这个可以用截图对比来抽查。
- 决策可解释性：问 Agent"为什么这里用这个间距"，它能不能说出依据。能说出来，说明技能被真正调用了。
这三个指标里，我最看重第三个。因为前两个可能是偶然，但"能解释决策"说明技能机制是真的在运转。
5. 实测踩过的坑：那些文档里不会写的细节
5.1 技能写太细，Agent 反而变笨
这是我踩的第一个大坑。一开始我觉得规则越细越好，把间距精确到每个场景、每个组件，写了上百条。结果 Agent 生成时变得极其僵硬，稍微超出规则范围的场景就卡壳，或者生搬硬套。
后来我明白了：技能是给判断力兜底的，不是替代判断力的。规则太细，等于把 Agent 的决策空间压没了，它就从"有品味的助手"退化成了"查表机器"。正确的做法是，只把那些"最容易出错、最需要统一"的点写成硬规则，其余留给 Agent 自己判断。
5.2 反例选得不好，会教坏 Agent
反例是把双刃剑。我早期选反例，喜欢选那种"明显很丑"的，觉得对比强烈效果好。结果发现 Agent 学到了一个错误的边界——它以为"只要不丑成这样就行"，中间地带反而更模糊了。
正确的反例，应该是**"看起来不错但在这个场景下不合适"**的。这种反例才能教会 Agent 场景判断，而不是简单的美丑判断。比如一个在营销页很出彩的大圆角卡片，放到数据表格里就是灾难，这种反例才有教学价值。
5.3 技能更新后，旧项目会"精神分裂"
技能是活的，会不断迭代。但已经生成的项目不会自动更新。这就导致一个问题：同一个系统里，早期页面用的是旧技能，新页面用的是新技能，风格对不齐。
我的处理方式是，技能文件做版本号，项目里记录用的是哪个版本。大版本升级时，安排一次专项的"风格对齐"迭代，把旧页面按新技能刷一遍。小版本升级就随缘，不强求。这个策略听起来不完美，但比"每次改技能就全量返工"务实得多。
5.4 别指望技能能解决"业务理解"问题
这是最容易被误解的一点。Taste Skill 能解决"审美判断"问题，但解决不了"业务理解"问题。它不知道你这个页面是给谁看的、核心转化目标是什么、用户此刻的情绪状态是什么。这些还是得靠人来定义。
所以我的用法是：人负责定义"这个页面要达成什么"，技能负责"用什么样的视觉语言去达成"。两者分工明确，谁也别越界。指望技能包办一切，最后出来的东西还是会有"AI味"，只不过是一种更精致的"AI味"。
6. 这套机制对前端意味着什么
6.1 前端的能力重心在往"判断"迁移
这几年前端圈有个明显的趋势：实现能力在贬值，判断能力在升值。切图、写组件、调样式这些事，AI 越来越能干。但"这个交互该不该做""这个视觉方向对不对""这个技术选型合不合适"，这些判断 AI 还替代不了。
Taste Skill 这类机制的出现，其实是在把"判断"这件事也部分工程化。它不是说前端不重要了，而是说前端的价值锚点在移动——从"我能实现"移动到"我能判断什么值得实现、怎么实现才对"。
6.2 技能资产会成为团队的新护城河
以前团队的核心资产是组件库、脚手架、工具链。未来，技能库可能会成为同等重要的资产。因为它沉淀的是团队的审美判断和工程经验，是别人抄不走的东西。
我甚至觉得，未来前端面试可能会问："你们团队的 SKILL.md 是怎么组织的？"这个问题能问出很多东西——你有没有体系化思考、有没有沉淀意识、有没有把经验变成可复用资产的能力。
6.3 对个人成长的一点提醒
如果你是个前端，我建议你现在就开始有意识地积累自己的"技能文件"。不一定要用 SKILL.md 这个格式，但要有这个意识：把你做过的判断、踩过的坑、总结的规则，结构化地记下来。这些东西攒多了，就是你区别于"只会调 API"的人的核心竞争力。
我自己有个习惯，每做完一个项目，会花半小时写一份"这个项目里我做了哪些判断、为什么这么判断"。攒了两年，回头一看，这就是我自己的 Taste Skill 库。它比任何简历都更能说明我的能力。
7. 几个可以直接抄的操作建议
最后分享几个我实测下来觉得最实用的操作细节，你可以直接拿去用。
第一，技能文件从"最小可用"开始。别一上来就写全，先写三条最核心的规则加一组正反例，跑通了再加。我见过太多人卡在"想写完美"这一步，结果一个字没落地。
第二，给每个技能配一个"反例库"。单独建一个文件夹，专门放那些"看起来对但其实错"的案例。这个库比规则库更有价值，因为它记录的是边界。
第三，定期做"技能体检"。每季度 review 一次技能文件，把那些 Agent 从来不调用、或者调用了反而出错的规则删掉。技能库不是越大越好，是越准越好。
第四，把技能和代码一起做 Code Review。技能文件的改动，也应该走评审流程。因为一个错误的规则，影响的是所有后续生成，比一个 bug 影响面还大。
第五，别把技能当成"设置完就不管"的东西。它是活的，需要跟着业务和审美一起进化。我现在的习惯是，每次发现一个"AI味"案例，就顺手更新一下对应的技能文件。日积月累，这套东西才真正长成了团队的肌肉记忆。
说到底，Taste Skill 和 SKILL.md 这套机制，解决的不是技术问题，是判断力如何沉淀和传递的问题。技术会过时，工具会换代，但"知道什么是对的、为什么对"这件事，永远是稀缺的。把这件事工程化，是我这两年看到的最有意思的方向之一。
