谁能把 commands、subagents、mcp、skills 和 plugin marketplace 解释清楚？

无论是小白、AI 爱好者，还是久经码场程序员，一定会有新的收获。

请一定要读到最后！！！收下 AI 时代还能保持初心的手绘图，以及实战经验 🥹

是不是有这种感觉：当别人在写 agent 的时候，你会说我要学 agent；现在大家又都在写 skill 了，你会说我要学 skill。

别再跟风了，只有适当的场景用适当的能力，才是最好的。

接下来，我会以代码评审的实际案例来教你怎么区分、怎么使用。

👉 为什么是代码评审？

众所周知，Claude 模型一直引以为傲的就是编码，编码后的代码评审是我们最常遇到、也是不可避免的工作。

同时，Claude Code 还内置了 security-reviewer（安全评审） 示例，可见代码评审是 AI 工作流很好的切入点，也是你最易理解的。

话不多说，进入正题：

1. Chat 时代

还记得 ChatGPT 刚出来的时候有多火吗？

那个时候，我们还是打开网页和 AI 对话聊天，如果拿来评审代码可以吗？

可以的，你会和 AI 一来一回地对话：把你的代码 + 精心准备的提示词给到它，让它给你评审结果。

案例：Rain 也是这么做的，把代码和提示词写好，放在文档里，需要的时候编辑下发给 ChatGPT。

图解一：AI Chat 时代评审代码

2. Commands 出现

当写的代码越来越多，有更多的代码要评审，你会发现每次都在做重复的内容：替换 XXX 代码块，偶尔更新 YYY 规范。

是不是很苦恼？

所以 Commands 来了，刚出现的时候也叫“提示词仓库”🏠，本质上是将相同的提示词放在一个 markdown 文档里，省去每次复制粘贴的工作，核心：解决提示词复用的问题。

Claude Code 中，它叫 Slash Commands（斜杠命令），语法：

/<命令名称> [参数]

案例：Rain 学会了 Commands，把固定的提示词放到 cr-java markdown 中，需要的时候就直接用，命令参数就是被评审的代码位置。

图解二：使用 Commands 评审代码

3. Sub-Agents 出现

第二阶段时，Commands 使得能“快捷唤醒 AI”，但当一次评审的代码量很多，以及除了规范评审，我们还要融入安全审查、性能评估等更全面的代码质量考核时，单个会话就显得捉襟见肘了：单次评审耗时需要 10min 以上。

有办法解决吗？

有的，Claude Code 引入了 sub-agents。

当我们进入 claude 后，你看到的就是主会话，一个主会话可以调用多个子代理，每个子代理都负责一个评审任务，互不干扰。

当所有的子代理完成任务后，它们会把评审结果都汇总给主会话。

案例：某天，Rain 被安全同事吐槽了代码安全隐患，为了评审效率，他拆分了两个子代理，协作评审。

图解三：sub-agents 并行评审

4. MCP

前面其实我们一直忽略了代码规范的问题，难道部门的代码规范一直写死在提示词中，不用迭代更新吗？

显然并不是❌，代码规范会随着新代码问题的发现，不断迭代更新。

一般规范也都是放在 Wiki 系统中，由部门架构师制定调整。

这么说，规范变更，我们就跟着改工程里的提示词。

如果代码工程数量多，维护提示词也是挺麻烦的工作量。

你肯定会想，AI 能从 Wiki 系统中获取到最新的规范不就好了？

是的，MCP 的设计，使得这一想法能够落地。

MCP（Model Context Protocol） 是一种基于 HTTP 的 JSON-RPC 协议，简单来说：就是我们常定义的 JSON 结构的后端接口。

设计好 MCP Server 后，AI 就能通过 Server 接口获取到最新的数据。

案例：为了 Claude Code 实时拉取最新的代码规范，Rain 部署了一个 MCP Server。

这个 MCP Server 提供了一个 tool，tool 后面实现了从 Wiki 系统读取当前规范并返回给 AI。

图解四：MCP 获取评审规范

5. Agent Skills 出现

还是顺着规范说，首先，你必须知道：MCP 返回的内容会一次性加载到当前的上下文中。

一次返回过量的上下文，会直接导致 Claude Code 拒绝加载（Claude Code 客户端可以配置 MCP 返回的最大的 token 数）；

严重时，会直接触发 Claude Code 的 compact，相当于 JVM 中的 STW（Stop The World），并且压缩后的内容会丢失，这肯定不是我们想看到的。

那我们是不是可以：先把内容下载下来，分次读取规范内容呢？

很聪明，你设计出了 skill。

skill 中可以包含 scripts，安全的朋友一听，肯定乐坏了，那不是什么 shell 都能执行。

确实，正是这个 scripts，我们可以通过 curl 命令下载规范，然后提示词中让 Claude Code 分段读取规范。

这也是 skill 的核心特性：渐进式披露，专为无限的上下文设计。

案例：随着规范数量多到上下文不够用了，Rain 立马引入了 skill，先把规范下载到 tmp 目录，然后分段读取。

图解五：Agent Skill 解决上下文膨胀

6. Plugin Marketplace 出现

经过前面的努力，我们已经把代码评审的提示词打磨得很好了。

作为领导的你，有想过怎么共享这些提示词吗？

传统方式：把提示词上传到 git 仓库，需要的用户下载下来，然后拷贝到工程里。

这种方式不是不行，但一个研发部门，多则上百的研发，拷贝的效率太低了。

当然，你会说我可以把提示词直接提交到每个工程中，可是新的问题又来了：多需求并行开发时，我们会有多个开发分支，提示词提交到 main 分支后，直至所有分支完成迭代，也需要很长的过渡期。

最终，一个独立于工程的 Plugin 市场出现了，你可以把 commands/sub-agents/mcp/skills 等，这一整套的提示词都打包到一个 plugin 中，并发布到市场中，便于提示词的共享。

配合 Claude Code 客户端的自动更新能力，那么用户就能在 Claude Code 客户端启动的时候拿到最新的提示词。

案例：Rain 有个同事叫小美，他迫不及待地把代码评审提示词上传到了 Plugin 市场中。

此后，小美更崇拜 Rain 哥哥了。

图解六：Plugin 市场的提示词共享

7. 总结

我深度使用了 Claude Code 至少 4 个月，对它的功能探索很多，以至于 Claude Code 新版本的 BUG 我都能很快踩到。

这里是对文章开头问题的总结：

• 适合 Commands 的场景：经常使用的提示语模版，内容少、不复杂，或者用于命令入口。
• 适合 sub-agents 的场景：多任务并行、上下文隔离。
• 适合 MCP 的场景：需要接口鉴权的通知推送、少量数据拉取。
• 适合 skill 的场景：超长上下文处理、复杂的任务处理（例如 xlsx 解析）。

其他的经验：

• 用 claude --dangerously-skip-permissions 命令启动 claude，可以跳过 accept 确认（🚨要注意“危险”操作，例如读取 env 内容、执行 rm -rf *）。
• sub-agents 不能调用 sub-agents，也不能调用 Commands。
• sub-agents 中可以调用 skill。
• skill 的唤醒方式：使用 skill:xxx 帮我 yyy。
• skill 中可以调用 MCP、sub-agents 以及其他 skill。
• skill 的加载会受限于上下文大小哦，这个肯定没人知道！！！也就是说，你并不能拥有无限的 skill。

还有很多，只能先讲一部分了。

下面重点来咯～～～

🔥 奉上完整的术语趣解：