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.mdAgent 反而不知道该用哪个效果还不如不接。我的建议是分三步走别贪快。第一步单点突破。先挑一个你团队最常做、最痛、最容易出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 这套机制解决的不是技术问题是判断力如何沉淀和传递的问题。技术会过时工具会换代但知道什么是对的、为什么对这件事永远是稀缺的。把这件事工程化是我这两年看到的最有意思的方向之一。