技术演进从不是凭空创造，而是为了解决一个又一个具体问题。

在AI编程的世界里，每周似乎都有新概念诞生：Rules、Commands、MCP Servers、子智能体、Modes、Hooks、Skills……这些术语让你感到困惑了吗？

今天，我们抛开碎片化的功能介绍，从历史演进的视角，完整梳理这些概念为何出现、解决了什么问题，以及它们如何共同构成了现代AI编程助手的核心架构。

01 Rules

静态规则的诞生与局限

一切都始于一个简单需求：纠正AI的“幻觉”。

早期的AI编程助手经常输出不符合代码库规范或业务逻辑的内容。开发者们发现，如果能把关键信息——比如项目命名规范、API使用禁忌——硬塞进每次对话的上下文，AI的表现会稳定得多。

于是，Rules（规则文件）应运而生。

它起初是单个文件，随着规则增多，逐渐发展为可嵌套、可拆分的模块化结构。但无论形式如何变化，所有Rules最终都会合并为一份“静态上下文”，随每个请求发送给AI。

但这里存在根本矛盾：很多规则只与特定任务相关。在每次对话中都加载全部规则，既浪费宝贵的上下文窗口，也让AI难以聚焦。Rules是必要的起点，但显然不是终极解决方案。

02 Commands

可复用工作流的封装

随着开发者使用AI编程助手完成复杂任务，一些固定模式的工作流开始形成。

例如，许多团队都需要一个“处理Git提交并创建PR”的标准化流程。如果每次都要手动输入一系列提示词，效率极低。

于是，斜杠命令（Commands）出现了。

Commands的本质是可复用的提示词序列。开发者可以将一个完整工作流打包成一个命令（如/create-pr），保存、共享，在需要时一键触发。

这标志着从“静态知识”到“动态流程”的进化。但Commands仍局限在文本交互的范畴。当开发者需要AI执行实际代码操作、与外部系统交互时，新的能力需求出现了。

03 MCP Servers

为AI连接真实世界

如果Rules是给AI“输入知识”，那么MCP Servers就是为AI“安装手臂”。

早期AI助手只能调用有限的“第一方工具”（如运行Shell命令）。MCP（Model Context Protocol）服务器则打开了一个全新维度：允许AI连接任何第三方系统。

通过MCP，AI可以：

• 读取Slack频道消息
• 在Jira中创建任务
• 查询数据库状态
• 调用内部API

这彻底改变了AI的能力边界。然而，这也带来了新问题：每个工具都需要详细的描述文档，这些文档本身就会占用大量上下文空间。如果加载太多工具，上下文窗口会再次变得臃肿不堪。

04 子智能体与Modes

专业化与状态管理

随着任务复杂化，开发者需要AI在不同的场景下扮演不同角色。这催生了两个相关概念。

子智能体：为特定任务（如代码审查、文档撰写）创建的专门化AI实例。它可以被限制只能访问相关工具集，确保更专注、更安全的执行。

Modes：比子智能体更深入的状态管理。一个Mode不仅能定义任务和工具，还能：

• 修改系统提示词
• 改变用户界面布局
• 添加专属工具权限
• 持续提醒AI“正处于该模式”

例如，“架构设计模式”下，AI会获得绘图工具、架构决策框架，并被不断提醒专注于高层次设计。这极大地提升了复杂任务的专业性和输出质量。

05 Hooks

确定性控制的锚点

无论AI变得多强，其本质仍是概率模型，存在不确定性。在关键环节，开发者需要100%的确定性保障。

Hooks（钩子）提供了这种保障。

钩子是预设的确定性执行点，例如：

• 对话前钩子：强制注入特定上下文
• 对话后钩子：自动保存结果到数据库或触发通知

钩子不参与AI的思考过程，而是在关键节点强制执行预设操作，为整个非确定性系统添加了确定性的锚点。

06 Skills

一切能力的终极封装与简化

当概念多到令人困惑时，技术演进会自然走向收敛与简化。Skills（技能）就是这一趋势的产物。

Skill是什么？

• 在最简单层面，一个Skill就是一个增强版Command
• 在高级层面，它是包含代码、资源、配置的完整能力包

Skill的革命性突破：