关于 Skill、CLI 与多模态的漫谈
date: 2026-04
reading_time: 约 12 分钟
从 Skill 聊到多模态的一个下午
这不是一篇结论文章，是一份思考记录。 起点是 Anthropic 推的 Skill 概念， 终点不知不觉到了多模态特征对齐。 中间的每一步，都是顺着直觉往下追问的结果。
01 — Skill 不是工具，是写给 Agent 的 SOP
最近在琢磨 Anthropic 的 Skill 这套东西，刚开始我以为它是某种新的工具调用机制，看了一阵子才反应过来——它根本不是工具，本质上是把专家经验和最佳实践沉淀成 Markdown，让模型在需要时按图索骥。
更准确的说法是：Skill 是一种可触发的、可组合的、版本化的 prompt 模块。和以前散装的 prompt engineering 相比，新意有两层。第一层是动态加载——启动时只把每个 Skill 的元数据（一两行 description）放进上下文，模型根据用户请求判断哪个相关，再去读完整的 SKILL.md。这就是所谓的 progressive disclosure。第二层更关键：它把 prompt 从"散装脚本"变成了"可被版本管理、可被复用、可被组合的资产"。这有点像从手写 shell 到 npm 的进化。
但这套东西有个常被忽略的前提：Skill 单飞没意义。如果只有 Skill 没有 tools，它能影响的只是模型的"说"，不是"做"。一个"写商业邮件的 Skill"告诉模型用什么语气、什么结构、避免什么表达——这确实有价值，但天花板就是 prompt engineering 的天花板。
真正解锁价值的是 Skill + Tools 的联动。这时候 Skill 教的不只是"怎么说话"，而是"在什么情况下调哪个工具、按什么顺序调、调完之后怎么处理结果、出错了怎么回退"。这是一套可执行的工作流，不只是输出模板。前者是建议，后者是交付。
Skill 是知识层，Tools 是执行层，模型是决策层。 三者缺一不可，谁单飞都立不起来。
02 — 警惕"一个 Skill 搞定一切"的叙事
市面上现在吹 Skill 吹得有点过。有种话术是"写个 Markdown 就能让 AI 变专家"，听起来很美，但隐藏了一个关键前提：这个领域的执行层必须已经被工具化了，而且工具化得足够好。
看看 Anthropic 官方放出来的那几个 Skill——docx、pptx、xlsx、pdf——为什么效果好？不是因为 SKILL.md 写得多神，而是因为背后 python-docx、python-pptx、openpyxl、pypdf 这些库已经被开源社区打磨了十几年。Skill 只是把"调用这些成熟库的最佳姿势"沉淀下来。真正的重活早就有人干完了，Skill 只是临门一脚。
所以判断一个 Skill 值不值得信，我会用三个问题筛一遍：
- 它依赖的工具，是不是已经在传统软件领域被验证了十年以上？
- 它的成功标准能不能被机器自动验证？代码能跑 = 能验证；"分析得好不好" = 不能验证。
- 它处理的是闭合任务还是开放任务？格式转换是闭合的，"帮我搞定这个项目"是开放的。
三个都是"是"，Skill 大概率靠谱；有一个是"否"，就要打折；两个以上是"否"，基本就是 demo 看看就好。这套筛子背后的逻辑是：Skill 不是银弹，它放大的是底层工具链的成熟度。底层成熟，Skill 就是放大器；底层不成熟，Skill 就是遮羞布。
03 — 所有人都在卷 CLI，为什么
聊完 Skill，自然就聊到了一个相关的现象：最近所有严肃做 AI coding 的公司，都不约而同地推出了自己的 CLI。Claude Code、Codex、Gemini CLI、Aider……为什么是 CLI，不是 GUI、不是网页、不是 IDE 插件？
表层原因最简单：CLI 是 agent 最自然的栖息地。Agent 要做的事——读文件、写文件、跑命令、看报错、改代码、再跑一次——这些操作在 CLI 里是一等公民。文本进，文本出，和 LLM 的输入输出格式天然同构。这是阻抗最小的接口。
中层原因是经济的：开发者是 AI 应用最早的付费用户，而开发者本来就活在 CLI 里。把 AI 做成 CLI 工具意味着零学习成本嵌入现有工作流，没有"又要装一个 app"的心理摩擦。
但真正有意思的是深层原因：CLI 是 Unix 哲学和 agent 范式的合流。Unix 哲学诞生于 1970 年代——小工具、管道、文本流、组合优于配置——安静地统治了服务器世界半个世纪。LLM agent 的工作方式，意外地和这套哲学完美契合。LLM 输入输出都是文本，和 Unix 文本流兼容；LLM 通过工具调用组合能力，和管道思想同构；LLM 需要可观察可调试，CLI 的"一切皆可 log"就是最好的可观察性。
所以 CLI 不是这一波 agent 工具的"产品形态选择"，而是它们的原生形态。因为 agent 要操作的世界，本来就是个 CLI 世界。
**顺带一个反直觉的观察：**现在很多人觉得"CLI 是开发者的小众玩具，GUI 才是大众化方向"。但在 agent 时代，这个判断可能是反的。当消费者越来越多是另一个 agent 而不是人，GUI 是负资产（agent 看不懂截图里的按钮在哪），CLI 才是资产。所以卷 CLI 不只是在卷"给开发者用的工具"，更是在抢占未来 agent-to-agent 协作的接口标准。
04 — 但 CLI 真的能脱离 GUI 吗
顺着这个思路再往前推一步，问题就来了：CLI 现在看起来赢麻了，但它的胜利有多稳？
我的判断是：CLI 的胜利可能是阶段性的。它是当前模型能力 × 当前任务结构 × 当前成本曲线这三者交汇出来的局部最优解。三个变量任何一个变了，最优解也会变。
更根本的问题是，文本本身就是一种有损压缩。当你把一个网页"文本化"成 DOM 树，已经丢掉了视觉层级、颜色暗示、空间关系、动效反馈——而这些恰恰是人类设计 GUI 时有意编码进去的信息。一个红色的警告按钮和一个灰色的次要按钮，在 DOM 里可能就是两个 <button>，但视觉上传达的紧迫性差了十万八千里。
而且世界本来就是多模态的。前端调试要看渲染结果，数据分析要看分布形状，机器人要看摄像头，客服要听语调——任何"人类要靠看或听才能判断"的任务，硬上 CLI 都是削足适履。把多模态信号压成文本的中间层，都在丢信息，而且丢的往往是最关键的那部分，因为最重要的信号往往是最难用文字描述的。
CLI 的崛起是工程妥协，不是认知最优。 一旦多模态模型做到"又便宜又快又可靠"，CLI 的优势会被重新评估。
所以更准确的说法是：CLI 不是终点，是当下能力水位下的局部最优。它会长期存在（因为 Unix 哲学的根太深），但解决不了"让 AI 真正理解世界"这个更大的问题。要做到那一步，必须把多模态作为一等公民，而不是文本的附属品。
05 — 多模态的两条路：拼装 vs 原生
那多模态怎么做？现在有两条主流路径，背后是两种不同的工程哲学。
第一条路是 modular multimodal，也就是用专家模型 + 文本胶水拼。每个模态都有一个对应的模型作为理解器：CLIP 处理图像、ASR 处理语音、OCR 处理文字、layout 模型处理版面，把每个模态都转成文本，再交给 LLM 做综合理解。这套架构现在到处都是，工程上解耦清晰，每个团队专注做好一个模态。
它的代价是每次模态转换都丢信息。一张图里"氛围有点诡异"这种感觉，OCR 提取不到，caption 模型可能写成"一个房间"，到 LLM 手里就完全没了。更隐蔽的问题是误差累积：每个模块各自 95% 准确率，串五个就只剩 77%，而且 debug 起来非常痛苦。
第二条路是 native multimodal，把图像、音频、视频都切成 token，和文本 token 混在同一个序列里，让 transformer 用同一套注意力直接处理。GPT-4o 是个标志性的转折——它能"听出语气、看出表情、用同样的情绪回应"，是因为这些信号根本没经过文本中转，是在表征层面直接流动的。
这条路的代价是训练成本极高，而且 token 化本身也是有损压缩——把图像切成 patch token，分辨率、patch size、token 数量都是 trade-off。所以两条路不是简单的"先后接替"，会长期并存：头部公司走 native 押注下一代范式，腰部和长尾继续用 modular 拼。
06 — 一个外行的猜想：在特征层融合
聊到这里我有个直觉：在到达真正强大的 native 全模态模型之前，可能还会出现一种过渡形态——不在 token 层融合，而在特征层融合。
逻辑是这样的：先用单模态网络把每个模态的特征学好（编码器各自做到极致），然后直接在 tensor 层做交互，不需要再转成 token。Token 化本来就是为了塞进 transformer 而做的妥协，本身就有量化损失。如果直接在更抽象的特征层做事，所有模态在形式上都是一致的——都是 N 维向量。要说有损失，那就是单模态编码器做得不够好，而不是融合方式的问题。
这个想法不算新鲜，对应到学界是 frozen encoder fusion 流派——BLIP-2、LLaVA、Flamingo 都是这套思路。它们的做法基本是：拿一个训好的视觉编码器冻住、拿一个训好的语言模型冻住，中间加一个轻量的连接器（projector / Q-Former / cross-attention），只训这个连接器。连接器的作用不是"翻译成文本"，而是在 tensor 层面做空间映射，把视觉特征投影到语言模型的隐藏空间里去。
这套方案训练成本比 native multimodal 低一两个数量级，效果还相当能打。LLaVA 就是用这个思路在很小的预算下做出了能和 GPT-4V 掰手腕的效果。背后还有一个更深的假设支持它——MIT 那篇 Platonic Representation Hypothesis 提出：随着模型变大变强，不同模态、不同架构的模型学到的内部表征正在收敛到同一个"柏拉图式"的表征空间。换句话说，"所有模态在足够深的特征层是同构的"——这不只是个理想，可能是大模型的一个 emergent property。
07 — 对齐才是真正硬的骨头
但这条路有个绕不开的难题：对齐。CLIP 那种对比学习只能两两对齐，要扩展到多个模态怎么办？这是整个领域最硬的开放问题之一。
有几条思路。最取巧的是 ImageBind 那种枢纽对齐——把图像作为中心模态，让所有其他模态（音频、深度、热成像、IMU）都去和图像对齐。结果发现即使没直接对齐过"音频"和"文本"，它们也会通过"图像"这个共同锚点间接对齐。聪明，但代价是非枢纽模态之间的对齐质量打折。
另一条是直接做多模态联合对比学习，把 N 个模态扔进同一个框架。技术上很难，因为对比学习的核心是"正样本 vs 负样本"，两个模态时定义清楚，三个以上就开始混乱。
我自己更倾向的方案是两两对齐再融合——用对比学习把每对模态都直接对齐好，得到一组对齐后的 encoder，再在上面接一个融合层。这个方案学界叫 hierarchical alignment，理论上比枢纽对齐质量更高，因为每对都是直接对齐。代价是工程复杂度——N 个模态需要 N(N-1)/2 对对齐，组合爆炸。所以实际中很少有人做超过 3-4 个模态的全对全对齐。
**一个我后来才知道的方向：**对齐不一定要靠对比学习。最近两年出现了一些"重建式对齐"（让 A 模态的特征去重建 B 模态的输入）、"互信息最大化"、"diffusion-based alignment"的工作。它们指向一个更深的洞察：对齐的本质不是"让向量靠近"，而是"让信息保持"。CLIP 只是实现这个目标的一种方式，未必是最优的。
08 — 后记
这条思考链从 Skill 的设计哲学一路走到了多模态对齐的研究前沿，跨度大得离谱。但回头看，每一步都不是跳跃，是顺着同一个问题往下追问的结果——那个问题就是：在 LLM 这一代技术里，"接口"到底意味着什么？
Skill 是给模型的接口（教它怎么调工具）。CLI 是给人的接口（也是给 agent 的接口）。多模态是给世界的接口（让模型不只能读文字，还能看、能听、能感知）。这三者其实是同一个问题的三个层面：智能要发挥作用，必须穿过某种"接口"和现实接触；而接口的形态，决定了智能能触达多深的现实。
文本接口最浅但最普适，多模态接口最深但最难。CLI 是当下最优的工程妥协，特征层融合可能是下一站，原生全模态是终点（如果真存在终点的话）。
我一篇论文都没发过。这套想法写出来也只是普通人对 AI 基建的胡思乱想，不是研究成果。但我越来越觉得，在 AI 这个变化太快的领域，能从第一性原理推演演化方向本身就是稀缺品——比追着 SOTA 跑要值钱。所以记录下来，权当一个非从业者在 2026 年春天对这个领域的快照。几年后回头看，要么觉得自己想对了一些，要么觉得当时还是太天真。两种都可以。
如果想顺着这条线继续读
- CLIP（OpenAI, 2021）— 理解为什么对比学习能让两个模态对齐到同一个空间
- BLIP-2（Salesforce, 2023）— frozen encoder + 轻量连接器的工程范式典范
- ImageBind（Meta, 2023）— 用图像做枢纽对齐六种模态，聪明而有局限
- The Platonic Representation Hypothesis（Huh et al., 2024）— 为什么不同模态的表征会自发收敛到同一空间
- Chameleon（Meta, 2024）— native multimodal 的另一极端，token 层早期融合
记录这条思考是因为它来得不容易。如果你看到这里，希望你也享受了这场漫游。
