从MCP到Subagent再到Skills，Anthropic确实为AI编程领域创建了很多规则。

这家公司自2024年11月推出Model Context Protocol（MCP）以来，就一直在引领AI编程工具的标准化进程。MCP作为一个开源协议，旨在统一AI系统与外部工具、数据源之间的交互方式，如今已经被OpenAI、Google DeepMind等主流AI厂商采纳，俨然成为了行业标准。

尤其是Skills，现在GitHub有非常多的关于Skills的仓库，我看了很多关于这些技术方面的视频和文章，但却不知道应该如何融入自己的工作流。这种困惑其实很正常，因为这些工具本身就是为了解决特定场景下的问题而设计的，而不是所有场景都需要它们。

由于我是前端开发，所以MCP仅仅是用了context7，然而随着各个AI联网能力的提升，有时候直接让AI从网络上搜索得到的结果反而更准确。

说到context7，这是由Upstash开发的一个MCP服务器，主要解决的是AI生成过时代码的问题。我们都知道，大语言模型的训练数据存在时间截止点，这导致它们经常会生成已经废弃的API或者不存在的方法。context7的工作原理是实时从官方文档抓取最新的、版本特定的代码示例，然后注入到LLM的Prompt中，从而避免”幻觉”问题。它还引入了llms.txt文件的概念，类似于robots.txt，用来指导语言模型应该使用哪些文档片段。在Cursor、Windsurf、Claude Desktop等主流AI编辑器中，只需要在Prompt中加上”use context7”就能触发这个功能。不过我现在用的越来越少了，因为各大AI的联网搜索能力已经足够强大，有时候直接让AI去搜索官方文档反而更加直接有效。

至于Subagent，最开始推出的时候我就体验过，在子Agent中无论是执行还是修改，都没有对应的输出，而且我发现几乎所有情况下，主Agent都已经足够了，不需要子Agent。Subagent的设计初衷是让AI能够并行处理多个任务，或者将复杂任务拆分给不同的专业Agent处理。但在实际使用中，这种协作机制的调试成本太高，输出不透明也让人很难信任它的执行结果。而对于日常的前端开发工作来说，一个足够聪明的主Agent已经绰绰有余。

至于Skills，在企业开发中非常有用，这也就是为什么在GitHub上面那么多Skills仓库能够得到上千次Star的原因，本文也主要介绍Skills能够在企业开发中做什么。

Skills相当于一个渐进加载的Prompt，可以让AI根据情况加载不同的上下文，不会因为一次将上下文扔给AI而导致上下文爆炸，消耗大量的Token。这种设计思路其实非常巧妙：与其一股脑地把所有项目信息都塞给AI，不如让它在需要的时候按需加载相关的上下文。这不仅节省了Token消耗，也让AI的注意力更加集中在当前任务上。Anthropic最初将Agent Skills定义为一种打包好的指令和脚本集合，用来扩展AI Agent的能力边界。

我个人在企业开发中使用Skills的场景是，为当前项目生成一个独立的Skills，里面包含组件、路由、支付、API、特殊流程等说明，这样可以让AI在开发的时候充分地了解项目。比如项目中有一个复杂的权限控制逻辑，或者支付流程涉及多个第三方服务的对接，这些内容如果每次都要手动解释给AI听，效率会非常低。把它们封装成Skills之后，AI就能像一个新入职但看过所有文档的同事一样，快速上手项目开发。

还有就是框架的Skills，比如Vue的Skills、React的Skills等等，这些技能可以大大地约束AI的行为。框架Skills可以指定代码风格、最佳实践、性能优化策略，甚至是团队内部的约定俗成。这样AI生成的代码就不会是那种”能跑但不规范”的代码，而是真正符合项目标准的代码。

最近Vercel还发布了一个新的Skills网站

https://skills.sh/

这个平台被设计成”AI技能的NPM”，提供了一个开放的、与Agent无关的生态系统。Vercel还推出了skills命令行工具，用于安装和管理AI技能包。这个平台支持Claude Code、OpenAI Codex CLI、Cursor、GitHub Copilot等主流AI编程工具，里面已经有React和Next.js性能优化、Web设计指南、Vercel部署等各种实用的Skills。这意味着以后找Skills就像找NPM包一样方便，不用再到处翻GitHub了。

独立开发

我发现无论是MCP还是Subagent还是Skills，对于独立开发者来说作用远远大于企业开发者。

这个结论乍一看可能有些反直觉，毕竟这些工具听起来都很”企业级”。但仔细想想就明白了：企业开发有完善的团队协作、代码规范、基础设施，而独立开发者往往是一个人打天下，AI工具对他们的加成效果是成倍放大的。

通过MCP可以打通前后端的障碍，使用MCP如Supabase这种，可以直接自动化创建数据库，自动化声明接口，前端直接通过AI来对接各种接口。Supabase的MCP服务器现在已经支持Remote模式，不需要复杂的本地配置，就能让Cursor、Claude Code等工具直接与Supabase项目交互。它内置的AI Assistant可以生成SQL查询、设计数据库schema、调试错误、管理Row Level Security策略，甚至创建和更新Postgres函数。对于独立开发者来说，这意味着你不需要精通后端开发，也能快速搭建一个完整的数据库架构。再配合Supabase对pgvector的支持，你甚至可以轻松构建RAG应用或者需要向量检索的AI产品。

而Subagent则可以开启多个子Agent，同时进行不同的任务，比如设计、实现、代码审查，甚至可以多个Agent互搏，讨论出一个更加完善的方案。在独立开发场景下，这相当于你有了一个完整的开发团队：一个Agent负责写代码，另一个负责Review，第三个负责思考架构设计。虽然我前面说在日常开发中用不太到Subagent，但如果你要做一个需要深思熟虑的技术决策，让多个Agent从不同角度分析利弊，可能比自己一个人冥思苦想要靠谱得多。

而Skills就更有用了，Skills甚至可以实现开发、打包、部署、更新文档，甚至在社交媒体上面发布相关内容。想象一下这样的工作流：你用AI完成了一个功能开发，然后一个Skill自动运行打包脚本，另一个Skill将构建产物部署到Vercel或者其他平台，第三个Skill更新项目的README和Changelog，最后一个Skill帮你生成一条推文或者开发日志发布到社交媒体。这套流程对于独立开发者来说简直是降维打击——以前需要一整天才能完成的发布流程，现在可能几分钟就能搞定。

说到底，MCP、Subagent、Skills这些工具的本质都是在扩展AI的能力边界。对于有完整团队支撑的企业开发者来说，这些能力可能只是锦上添花；但对于独立开发者来说，它们填补的是真正的能力空白。当AI能够帮你处理后端、运维、文档、运营这些你本来不擅长或者没时间做的事情时，你就能把更多精力放在产品本身上。这大概就是为什么独立开发者社区对这些工具的热情远超企业开发者的原因吧。

最重要的是，在企业中活是干不完的，你干的越快，活来的也越快。