【AI风向】Wix 250次评测打脸"Skill万能论"：文档写好比写Skill更重要，Claude Code上线电台+插件市场

Wix工程团队用250次对照实验证明：AI Agent用优化好的文档干活，完成率87%；用专门写的Skill反而降到78%。同一天，Claude Code 5月更新上线了/radio电台命令、Plugin Marketplace和Opus 4.7百万上下文。

一、250次评测推翻行业共识

AI Agent圈子里有一个近乎信仰的假设：给Agent写"Skill"（技能包），一定比让它自己翻文档强。

逻辑看起来无懈可击——文档是给人看的，Skill是专门为AI优化的，后者当然更高效。Wix工程团队决定用实验说话，而不是凭直觉。

他们在自己的Wix MCP平台上，用三种条件跑了250次对照评测：

条件	说明	CLI任务完成率
基准文档	标准llms.txt供Agent抓取	67%
优化文档	修复缺失方法名、字段名、依赖步骤	87%
专门Skill	用Wix MCP打包的Skill包	78%

写Skill反而不如把文档修好。 这个结果让Skill的信徒们沉默了。

二、Skill为什么会"负优化"

不是Skill本身有问题，而是Skill太容易"过时"。Wix团队观察到三种典型翻车模式：

翻车1：脚手架错位 → Token暴涨94%

一个Skill写的是"用React库做这个组件"，但Wix CLI有自己的专属方案。Agent按Skill指令走了30步后发现行不通，回头重来——多烧了94%的Token。

翻车2：代码片段漏导出 → 多试了39%的Token

Skill里的示例代码少了一行export声明。Agent不相信这么简单的代码会出错，反复尝试不同模式来"修复"，额外消耗39%的Token。

翻车3：最佳实践过载 → Token多烧52%

Skill里塞了太多"应该这样做""推荐那样做"的建议，Agent每个建议都认真检查一遍，结果比直接用文档慢了52%。

但当Skill写对了，效果惊人：Token减少30-50%，时间缩短30%。

结论很微妙：Skill是一把双刃剑。写得好是加速器，写得烂是减速带。而"写得烂"的概率，远比大多数人想象得高。

三、一个反直觉的发现：Token少了≠更快

在REST API任务中，出现了一个让人意外的数据：

优化文档：完成率80%，耗时31%更少，交互轮次减少33%
专门Skill：完成率80%，Token减少29%，但耗时并不少

原因很讽刺：Skill通过MCP协议传递信息时，同一个API的完整信息（方法名、参数、Schema、示例）被拆成多次MCP调用；而文档是Agent一次性抓取，一次LLM推理就够。

少烧Token ≠ 省时间。多轮LLM推理的延迟，比多传几KB文字更贵。

四、更隐蔽的代价：Skill让Agent变"笨"

Wix团队还发现了一个更值得警惕的现象：

Agent拿到官方Skill后，会严格按Skill的路径走，不再尝试其他解法。 遇到Skill没覆盖的边界情况时，直接报错而不是自己想办法。而用文档的Agent因为没有"官方路线图"，反而经常发现更简洁的实现路径。

Skill优化了"特定场景"的效率，但牺牲了"未知场景"的灵活性。

五、正确的做法：文档是地基，Skill是缓存层

Wix团队给出了一个两层框架：

┌─────────────────────────────────┐
│  第一层：Agent优化文档（地基）     │
│  · 结构化，面向机器消费           │
│  · llms.txt清晰入口              │
│  · 命名一致、依赖明确             │
│  · 覆盖所有可能任务               │
└────────────┬────────────────────┘
             ▼
┌─────────────────────────────────┐
│  第二层：Skill（缓存加速层）       │
│  · 从文档派生，不独立编写         │
│  · 仅覆盖高频任务                 │
│  · 目标是让熟路更快更省           │
└────────────┬────────────────────┘
             ▼
┌─────────────────────────────────┐
│  持续评测（维护机制）             │
│  · 定期对比 Skill vs 文档        │
│  · 性能劣化 = 漂移信号            │
│  · 自动化监控≠一次性工程          │
└─────────────────────────────────┘

一句话总结：先修文档，再写Skill。文档是地基，Skill是装修。地基没打好就急着装修，迟早塌。

六、Claude Code 5月更新：电台+插件市场+百万上下文

同一天，Claude Code也放出了5月更新：

/radio 命令：内置Claude FM电台，写代码时听背景音乐。已成Twitter病毒传播事件——开发者喜欢这种"人味儿"功能。
Plugin Marketplace：插件市场正式上线，第三方可以直接发布Claude Code插件，生态开始成形。
Opus 4.7模型：支持100万Token上下文窗口，Agent可以一口气吃下整个大型代码仓库。
新增命令：/loop（循环执行任务）、/ultrareview（深度代码审查）。

从"工具"到"平台"的跃迁正在加速——Plugin Marketplace意味着Claude Code正在建立类似VSCode扩展生态的飞轮。

行动建议

今天就检查你的llms.txt：假设一个AI Agent要用你的产品，它能通过llms.txt顺利完成一个基本任务吗？如果不行，先别写Skill。
Skill要小、要少：只覆盖高频任务，每个Skill不超过一个明确场景。大而全的Skill=定时炸弹。
建立评测流水线：写完Skill不等于完事。定期跑一组测试任务，对比Skill模式vs纯文档模式的完成率和Token消耗。
试试Claude Code /radio：不是核心功能，但这种"关怀开发者体验"的设计思路，值得每个做AI产品的人学习。

本文由AI辅助创作，经人工审核编辑发布