AI 接口之争再起：当“Skills”想接管一切，为什么还有人死守 MCP？
一场看似技术细节的争论，实际上在决定 AI 将来有多好用
这几个月，AI 圈里有个很微妙的风向：越来越多人开始把“Skills”捧成给大模型扩展能力的新标准。简单理解，Skills 有点像给 AI 写的一份说明书，告诉它“该怎么做事”。这套思路很讨巧，门槛也低——往仓库里塞一个 SKILL.md，模型就可能学会某个流程、某种规范，甚至某个工具的调用方法。
但开发者 David 最近发了一篇措辞相当鲜明的文章，标题就很直白：《我还是更喜欢 MCP，而不是 Skills》。他的观点并不复杂：Skills 适合教 AI “知识”和“用法”，但如果你真的想让 AI 去连接 Notion、Google Calendar、浏览器、邮件系统、数据库这些真实世界的服务，那么 MCP，也就是 Model Context Protocol，仍然是更成熟、更工程化的路。
这件事为什么重要？因为 AI 现在正在经历一个从“会聊天”到“会做事”的拐点。过去的大模型像一个能说会道的顾问，现在大家更希望它变成一个能下场干活的助理：查日历、发邮件、订机票、调代码、改文档、跑流程。问题来了——这个助理到底该怎么接入外部世界？是让它背更多“操作说明书”，还是给它一个标准化的“连接器接口”？这不是术语之争，而是未来 AI 产品体验的底层分水岭。
Skills 很迷人，但它的问题常常在真正落地时暴露
David 对 Skills 并不是全盘否定，这一点很关键。他承认，纯知识型的 Skill 其实很好用。比如告诉 Claude 如何写符合团队规范的 commit message，怎么理解公司内部黑话，或者怎么处理 PDF 文件，这些都非常适合用文档形式沉淀。说白了，Skills 在“教模型懂规矩”这件事上，天然高效。
真正让他反感的，是越来越多团队把 Skills 当成万能胶水：你要访问一个服务？先装 CLI；你要让模型会用它？再写一份 Skill 教它怎么调用 CLI；你要认证？自己处理 token、环境变量、依赖安装。整个链条看起来像是给 AI 修了一座桥，实际上却是先让用户自己扛着水泥去工地。
这也是 Skills 当前最尴尬的地方：它默认 AI 所在环境能运行任意命令行工具。但现实并不是这样。ChatGPT 网页版跑不了 CLI，Perplexity 标准环境也不行，很多云端 AI 客户端根本没有完整的本地执行能力。于是，那些“先安装某某工具再调用”的 Skill，在大量场景里会直接失效。你以为自己在做 AI 原生集成，最后却只是把传统开发者工具又包装了一层。
更麻烦的是，CLI 生态天生零碎。安装方式可能是 npm、uv、二进制包，也可能要自己编译；更新要重装；密钥要自己管；有些环境今天能存 .env，明天就因为容器重建全忘光。一个本该让 AI 更丝滑的能力体系，最后演变成一场关于依赖管理、权限配置和 YAML 元数据兼容性的民间疾苦大会。这种体验，说实话，很像 2010 年代每个 SaaS 都逼你装浏览器插件的那种烦躁。
MCP 的价值，不是“更酷”，而是它更像真正的平台基础设施
MCP 的核心思想并不花哨：大模型不需要理解“怎么连接服务”，它只要知道“有哪些能力可以调”。比如模型想操作 DEVONthink，它调用某个工具接口，底层认证、状态管理、远程调用，都由 MCP 服务器处理。这个抽象层乍看没什么戏剧性，但它恰恰符合现代软件架构最朴素的原则：把复杂性收拢到服务端，把一致体验交给客户端。
David 强调的几个优点，其实都直击今天 AI 产品的痛点。远程 MCP 可以零安装，用户给客户端一个地址就能接；服务端一更新，所有客户端同步获得新能力；认证能通过 OAuth 等方式优雅处理，不必让用户在某个角落手动贴一串 API Key；而且它天然更适合跨设备——你今天在 Mac 上用，明天在手机上继续，并不需要重新折腾一遍本地环境。
这背后其实是一个老问题在 AI 时代的翻版：到底是“每个客户端自己适配世界”，还是“由服务方提供标准接口”？从 Web API 到 OAuth，从 RSS 到支付网关，互联网历史已经反复证明，真正能规模化的往往不是“教用户怎么操作”，而是“给开发者稳定接口”。MCP 的吸引力也正在这里。它不像一份教程，更像一根标准水管。水管不性感，但城市不能没有水管。
当然，MCP 也不是没有门槛。它需要服务提供方愿意维护接口、处理认证、思考权限边界，还要兼容越来越多 AI 客户端。对一些小团队来说，写个 CLI 再附一份 Skill 文档，短期内确实更快。但快，不等于对。很多 AI 生态今天的问题，恰恰是太多“能用就行”的临时方案正在被误当成未来标准。
真正合理的分工，也许是：MCP 负责连接，Skills 负责经验
我很认同 David 文章里一个相当务实的判断：Skills 不该取代 MCP，最好的位置是给 MCP 打辅助。这个组合拳其实比单押任何一边都更现实。
什么意思？MCP 负责“能不能做”，Skills 负责“怎样做得更好”。比如一个 Notion 的 MCP 接口已经能让模型查页面、写数据库、更新内容，但实际使用中总会冒出一堆坑：日期必须写成 YYYY-MM-DD，搜索结果默认截断，某个工具名字看起来像 A 实际功能却偏向 B。模型每次都重新试错，既浪费 token，也浪费人的耐心。这时候，用 Skill 把这些经验、惯例、禁忌整理成一份“备忘录”，就很有价值。
这也解释了为什么 Skills 在仓库级、本地工作流级特别受欢迎。你可以在 .claude/skills 里告诉模型你们团队怎么命名分支、怎么写测试、怎么接触敏感信息、怎么调用现有的 git、gh、gcloud、curl。这类知识本来就不是服务接口的一部分，而是组织经验的一部分。让 Skill 承担这个角色，恰到好处。
换句话说，如果把 AI 看成一位新入职的同事，那么 MCP 像工牌、门禁卡和公司系统账号，让它能进门、能办事；Skills 更像老员工写给它的工作手册，提醒它“这个部门脾气不太好，走流程时记得先发邮件”。前者解决接入，后者减少踩坑。把这两样混成一件东西，最后只会让系统既难维护又难推广。
这场争论最后会走向哪？标准之战，刚刚开始
眼下值得关注的一点是，越来越多 AI 平台都在争夺“能力层标准”的定义权。Anthropic 推 Skills，OpenAI 与各类工具生态继续强化 Agent 能力，浏览器、代码助手、SaaS 平台也都在摸索自己的插件或连接方式。行业表面上热闹，底层却非常碎片化：有的支持 GitHub 安装 Skill，有的支持市场分发，有的偏本地执行，有的偏云端托管。开发者今天做一个集成，往往像同时给三四个平行宇宙写适配层。
这也是为什么 David 会对“MCP 已死”的舆论反弹得这么强烈。因为一旦行业真的滑向“每个服务一个 CLI，每个 AI 一套 Skill 格式”的方向，所谓 AI 代理的未来，很可能就会变成一个新版浏览器插件地狱。能跑，但不顺；能接，但不通；看着很开放，实际处处卡壳。
从更长远的角度看，我反而觉得这篇文章提醒了一个常被忽略的问题：AI 真正的大规模应用，不取决于模型参数再涨多少，而取决于“接口层”能否像互联网当年的 URL、HTML、OAuth 那样，形成足够稳定的共识。模型本身会越来越强，但如果连接世界的方式始终是碎的，AI 的能力上限就会被产品工程拖住。
我尤其认同他最后那个略带理想主义的期待：希望未来机票、酒店、办公、浏览器、开发工具都能原生提供官方 MCP。因为这意味着 AI 不再是偷偷摸摸替人点网页、执行脚本的“外挂”，而是被正式接纳为一种新的软件使用入口。到了那一步，AI 才不只是聊天机器人，而会变成真正的通用计算界面。
而在那之前，Skills 当然还会继续增长，甚至会非常繁荣。它便宜、灵活、好上手，很适合野蛮生长阶段。但如果要问哪条路更接近未来基础设施，我的答案和 David 一样：手册永远重要，可真正撑起世界运转的，终究还是连接器。