在一篇早前的文章中，我们提出了一个观点，并承认当时尚未验证：我们的前端 Agent 技能应当对更弱、更廉价的模型帮助更大，而非帮助前沿模型。这个逻辑是站得住脚的——把知识直接递给一个已经掌握它的模型，价值就更低——但逻辑并不等于证据。于是我们做了这个实验。以下是数据给出的答案。
实验设置
我们用两个较弱的执行者——Haiku 4.5 和 Sonnet 4.6——在使用技能和不使用技能两种情况下，重新运行了同样的构建任务，并用与前沿模型（Opus 4.8）完全相同的评测工具进行打分。真正关键的数字是提升幅度：技能在每个模型层级上对输出的改进程度。
两项测试：七项知识技能（按客观正确性打分），以及那项流程类的“视觉打磨”技能（就质量进行盲评）。
结果一：模型越弱，提升越大
在正确性上，规律清晰且单调：
| 模型 | 不使用技能 | 使用技能 | 提升 |
|---|---|---|---|
| Opus 4.8（前沿） | 95.8% | 100% | +4.2 分 |
| Sonnet 4.6 | 91.7% | 100% | +8.3 分 |
| Haiku 4.5（最小） | 87.5% | 100% | +12.5 分 |
技能把每一个层级都拉升到了 100%——但模型越弱，它弥补的差距就越大。从前沿模型到最小的模型，提升幅度大致翻了三倍。没有辅助的弱模型总是会丢掉技能所编码的那些确切约定（一致的尺寸策略、尊重可访问性的断点、移动导航状态、性能信号）；而技能每次都把它们补齐了。假设得到验证。
结果二：审美会向下传递——验证却不会
质量技能则更有意思。经过盲评，在较弱的模型上，带技能的输出在 4 对捉对比较中赢下了 3 对（前沿模型在跑完整渲染循环时，赢下了它的两对）。评审员再次将无辅助的版本标记为通用 AI 的默认产物，而将带技能的版本标记为“定制设计”。
“胜出的设计偏好自信的配色和编辑风格的排版；落败的则依赖通用默认值——紫色/靛蓝渐变、渐变标题文字、千篇一律的居中卡片。”
但那唯一的一次落败，才是整项研究中最有价值的结果。最小的模型即便带上技能，仍输掉了一对——不是因为看起来通用，而是因为交付了一个对比度失效的行动号召按钮（白底白字）。这恰恰是技能的“渲染并优化”循环通过查看渲染后的页面本应捕捉到的那类执行缺陷——而一个较弱、无浏览器的模型无法可靠地运行那个循环。
因此，随着模型变弱，技能的两个组成部分表现各异：所交付的审美（一套经过审核的设计系统、反模式护栏）会向下层级传递，让输出不至于显得通用。而验证（渲染、评判、修正）则不会——它既需要浏览器，也需要足够的能力去判断一张截图。
我们做了哪些改动
这些发现指向一个明确的修复方向：如果弱模型无法运行“查看并优化”的循环，就给它一个不依赖模型自身判断的验证底线。于是我们在打磨技能中新增了：
- 一个零依赖的自动化质量关卡——一个脚本，用于标记确定性缺陷（缺失的焦点状态、没有 reduced-motion 保护、缺失 viewport 标签、在 JS 加载前内容被隐藏、通用 AI 配色、扁平阴影、明显的对比度失效），并且必须在交付前通过。在测试中，它正确地否决了通用基线，并放行了参考页面。
- 一个场景矩阵——针对模型能力与浏览器可用性的每一种组合，规定应运行哪种验证，其中自动化关卡是每种情况下都成立的恒定项。
这个关卡是一种启发式判断，而非渲染器——它看不到真实的像素对比度——所以当有浏览器可用时，完整的渲染检查仍会运行。但无论模型能力如何，它都能把“我觉得应该没问题”变成一个经过核验的结果。
这对团队意味着什么
- 知识技能在更廉价的模型上收益更大——可以说这才是它们的最佳用例。如果你在生产环境中运行小型或预算型模型，那么构建良好的技能正是你大量质量的来源。
- 不要指望在前沿模型上有同样的效果——它已经掌握了那些约定，因此一项正确性技能几乎撼动不了它。
- 交付的审美会传递；自我验证不会。一套设计系统能提升任何模型的输出；而“查看并修正”的循环则需要能力和浏览器。
- 给每个层级都配一个自动化关卡。这正是你阻止廉价模型交付它自己看不到的那个 Bug 的方法。
SplatDev 如何运用这一点
我们构建的 AI 增强型开发系统，会针对你实际运行的模型进行调优——无论是前沿还是预算型——配以让输出在该层级上可靠的技能、护栏和自动化关卡。而且我们会去度量它：收益在哪里、不在哪里，以及要补充什么来弥合差距。
正在运行一个成本敏感的模型，并希望从中获得更高的质量？
或者发邮件给我们：[email protected]