为什么给代码智能体 “喂点上下文”，会搞出这么多名词？

如果你正在学习或使用氛围编程（Vibe Coding），可能会被一堆概念砸中！Rules、Commands、MCP Servers、子智能体、Modes、Hooks，还有现在越来越常被提到的 技能（Skills）。光听名字就让人头大。来自 Cursor 的技术专家 Lee Robinson 在这段视频里将为大家一一讲解这些重要的技术，厘清上下文管理的发展脉络。

把时间线拉长看，其实这些概念都在解决同一件事！怎么把合适的信息，在合适的时机，放进模型的上下文里。

在氛围编程刚开始的时候，模型最让人头疼的问题是幻觉。于是大家用了一个很直接的办法：写 Rules。把代码库背景、业务约定、常见错误一股脑写进文件里，每次对话都自动带上。这类信息被称为静态上下文。不管你问什么，它都会出现。

这个方法一开始效果不错，但很快就遇到了瓶颈。Rules 越写越长，很多内容其实只在特定任务下才有用，却不得不每次都塞进上下文。理想状态当然是 “需要时再给”，但当时模型调用工具、改文件、跑命令都还不够稳定，这个想法只能先放着。

接下来，大家开始关注效率问题。有些 Prompt 会反复用，那就不如打包起来。于是有了 Commands，也就是斜杠命令。例如一键完成 Git 提交并创建 PR。这一步本质上还是文本，只是从 “复制粘贴” 进化成了 “随叫随到”。

但光靠文本还是不够。智能体需要真正接入系统、执行代码、访问第三方服务，这就引出了 MCP Server。MCP 不只是 Prompt，而是一个完整的服务器。它可以连现有系统、做 OAuth、暴露外部工具，比如读 Slack、建 Linear Issue。然而，工具一多，上下文负担就会变重。

于是又出现了子智能体和模式。子智能体就像 “带固定人设和任务的 Prompt”，还能限制可用工具。模式则更进一步，不但告诉智能体要做什么，还能修改系统提示词、开放新工具、甚至配合 UI 变化，让智能体始终记得自己正处在某种工作状态下，比如专心做规划。这些设计的核心目标只有一个：让智能体更可靠、更容易被正确使用。

但再怎么设计，模型终究是非确定性的。于是，就引入了 Hooks。Hooks 不靠模型理解，而是靠规则触发。在对话开始或结束时，确定性地注入内容、记录结果、写入数据库。这更像传统程序里的钩子，而不是 “智能判断”。

到这里，其实已经能看出一条清晰的主线了：一类东西负责一直要知道的事，另一类则负责按需获得的能力。

这也是为什么现在很多人开始把复杂的体系压缩成两个核心概念：Rules 和 Skills。

Rules 负责静态上下文，要求尽量短、尽量准、会持续演进。模型哪里老犯错，就补哪里。

Skills 则是动态上下文的升级版。它可以是一个命令、一个脚本，甚至一整个工具包，但只有在你真正用到时才加载，不会污染初始上下文。你可以把它分享给团队，也可以让智能体从中学习和优化。

从这个角度看，Skills 并不是凭空冒出来的新概念，而是对 Commands、MCP、工作流的一次收敛。它解决的不是 “能不能做”，而是 “什么时候做、要不要带进上下文”。

所以，如果你觉得现在的名词太多，其实不必全背。理解历史之后会发现，大多数复杂度都是阶段性的产物。对普通使用者来说，关注好两件事就够了：静态规则（Rules）写清楚，动态能力（Sills）按需用。

剩下的，就是如何让工具帮你把事做得更顺一点而已。