面向前端的 AI 智能体技能：收益、缺口，与一次诚实的对比

在一篇配套文章中，我们展示了 AI 智能体技能能让前端输出在盲测中可量化地更美观。本文是故事的另一半——大多数“AI 让我们的代码更好”的帖子会跳过的那一半：技能没有帮上忙的地方、它们的代价，以及我们如何得知这种差异是真实的。如果你正在决定是否投资智能体技能，那么缺口和收益同样重要。

我们构建了八个技能，并用两种不同的方式加以测试。最重要的结果是：这八个技能并非一回事——它们干净利落地分成两类，行为方式截然相反。

两类技能

人们很容易把“智能体技能”当成单一的杠杆。它们并非如此。

知识型技能（七个）

它们编码的是什么才是好的前端：CSS 架构、设计系统、响应式布局、语义化 HTML 与无障碍、动画、现代 CSS 与浏览器支持，以及性能。它们是智能体按需加载的参考资料。

一个流程型技能

第八个，“视觉打磨（Visual Polish）”，编码的是设计师如何工作：构建、在真实浏览器中渲染、截图、对照评分标准审视、修复最薄弱之处，然后重复——外加一个经过甄选的设计系统素材库和一份严格的“完成的定义”。它改变的是智能体的行为，而不仅仅是知识。

这一区分最终解释了下文的每一个结果。

我们如何衡量

两次评估，每次都比较同一任务在带技能与无辅助（不带技能）下的完成情况：

• 正确性评估——七项构建任务，由客观检查评分：是否使用相对单位、语义化 HTML、无障碍焦点状态、基于 em 的断点、原生懒加载，等等。
• 质量评估——两项全新任务（一个定价区块、一个金融落地页），以盲测方式评判：一位独立评审只对渲染后的截图打分，不知道哪个是哪个，且标签经过随机化，使其无法进行模式匹配。

数字

把这两组数据合在一起看，整个故事就浮现了：在正确性上，带技能与不带技能打平；在匠心上，技能决定性地胜出——但成本更高。

技能取胜之处（收益）

1. 匠心与美感——决定性的胜利

有了流程型技能，输出从一眼可辨的“通用 AI 默认样式”变为真正经过艺术指导——并在两项任务上都以高置信度赢得盲测对比。那位对哪个设计是哪个毫不知情的评审，独立地点出了无辅助版本的特征：深紫色渐变和渐变标题文字。

“其中一个经过艺术指导、显然是定制设计——足以放进灵感画板。另一个同时倚仗了两大最典型的通用 AI 特征。差距是明确的，而非勉强的。”

2. 它能捕捉真实缺陷

由于流程型技能迫使智能体渲染并查看，它捕捉到了代码审查遗漏的两个生产级 bug：一处在没有 JavaScript 时不可见的内容，以及一处在移动端横向溢出的布局。一次性生成两者都会放过——因为没有任何环节让它去看结果。

3. 它每一次都强制执行你的约定

技能能可靠地注入模型默认不会选择的项目专属决策：一致的尺寸策略、基于 em 的媒体查询、由真实浏览器支持数据把关的现代 CSS、reduced-motion 安全，以及有层次（而非扁平）的阴影。跨越数百次运行的这种一致性本身就是一项交付成果。

技能未能取胜之处（缺口）

诚实的部分。这些是真实存在的，值得提前规划。

知识型技能勉强胜过强大的模型

前沿模型本就懂得相对单位、语义化 HTML 和无障碍基础。因此在正确性评估中，七个知识型技能与无辅助的模型基本打平——而在一项任务上，评分者甚至给它们略低的分数。它们的价值在于一致性，以及帮助较弱或更廉价的模型，而非对顶级模型的原始提升。

它们成本更高

在知识型任务上，带技能的运行大约多用了 24% 的 token 和 33% 的时间；完整的渲染并迭代循环则更为沉重（数十个构建与检查的步骤，而非寥寥几个）。你是在用算力购买质量——当质量重要时物有所值，当任务是“正确的代码，且要快”时则是浪费。

最好的杠杆需要浏览器

流程型技能的超能力在于在真实浏览器中渲染。在没有浏览器的环境中，它退化为一个知识型技能，最大的优势也随之消失。请据此规划工具链。

质量难以低成本衡量

我们的客观正确性检查在评判质量方面表现不佳——它们大多让两个版本都通过，并在设计任务上产生了假阴性。真正的质量评估需要一位类人风格的盲测评审。而且我们的质量评估规模很小：两项任务，一位评审。有说服力，但尚未在统计上足够稳健。

贯穿始终的洞见

一句话即可概括：

“正确性已经解决，匠心尚未。称职与卓越的前端之间的差距，并不是模型所欠缺的知识——而是通过迭代所施展的品味，以及拒绝交付通用默认样式的态度。”

这正是为什么增加更多知识几乎没有推动指针，而增加一套流程——渲染、审视、打磨，对照内置的品味——却推动了很多。一条文字指令无法让一次性生成做到像素级完美，而一个迫使智能体查看并修复自己成果的技能却可以。

这对团队意味着什么

• 不要指望从强大的模型获得正确性提升。如果你的评估只检查正确性，技能会显得毫无意义——因为你衡量的正是模型本就能做的事。
• 投资于流程，而不只是提示词。持久的收益来自智能体必须运行的验证循环，而非更长的指令文件。
• 交付品味，而非原则。经过甄选、立场鲜明的默认值每次都胜过抽象建议。
• 以用户体验的方式衡量质量——渲染它、查看它、盲测对比。布尔检查看不见美。
• 为此做好预算。高质量的输出会消耗更多 token 和时间；把它花在质量本身就是目标的地方。

建议：弥合缺口

这些发现指向一份具体的待办清单——既为我们自己的技能套件，也为任何正在构建技能的团队：

• 扩大盲测评估的规模。两项任务和一位评审只能证明方向，而非量级。扩展到十项以上、覆盖多种页面类型的任务，加入第二位 AI 评审，并至少纳入一位人类评审。追踪胜率和置信度，而非单一结论。
• 调校触发方式，而不只是内容。一个不触发的技能毫无价值，而一个在错误任务上触发的技能则更糟。运行一次自动化的描述优化，让每个技能在该触发时触发、不该触发时保持沉默。
• 让流程型技能优雅降级。当没有可用浏览器时，它应当检测到这一点，并回退到其知识与清单，而不是假设自己能够渲染——这样它就绝不会悄无声息地丢掉自己最大的杠杆。
• 整合重叠的知识。八个技能承载着一些重复的表层内容——现代 CSS、响应式和性能触及同一片领域。更清晰的边界意味着随平台演进需要维护的东西更少。
• 按意图路由。当质量是目标时，使用沉重的渲染并迭代循环；当目标是“快速产出正确的代码”时则跳过它。最大的浪费是为一个用完即弃的内部工具支付匠心级别的算力。
• 在较弱的模型上重新衡量。基础模型能力越弱，知识型技能理应帮助越大；确认这一点能为对成本敏感的部署量化它们的真实价值。

SplatDev 如何应用这一切

这正是我们为客户所做的工作：不只是把 AI 指向一个代码库，而是设计使其输出可靠卓越的技能、护栏与验证循环——然后用诚实的评估来证明结果，而非想当然。我们衡量质量，而不只是速度，并且会告诉你收益在哪里、以及不在哪里。

想要能交付你愿意放进作品集的作品的 AI——以及对其局限的诚实说明吗？

联系 SplatDev——用 AI 构建得更好

或发送邮件至 [email protected]