你有没有被这三件事同时折磨过：
上下文越写越长、工具越装越多、模型越用越“自信地胡说”。
看上去我们在学一堆名词：rule、command、MCP、mode、subagent、hook、skill、agent……越学越乱。可真正的事实是：系统在变大，工程在变复杂，旧方法撑不住了。
自从 2022 年 ChatGPT-3 发布以来，人们对大模型的探索和打磨就从未停止。最早大家被“幻觉”和“不确定性”折磨得够呛，于是用 rule / 角色扮演把约束塞进上下文；后来觉得光靠提示词不够稳，就演化出 RAG 检索增强；再后来，不满足只对话，为了扩展大模型能力边界，OpenAI 提出 function calling，Anthropic 又提出 MCP 协议，让模型能更标准化地调用外部工具。
直到今天，skill 这一概念重磅登场：灵活的 prompt 上下文、即插即用的外部工具扩展，不再把初始上下文塞到爆炸，而是把能力做成“按需加载”的模块，推动开源生态的协作与复用。
如果你是程序员，想学习 AI 大模型与 AI Agent，并获得更高曝光，我的建议是：别背名词，抓演化主线。你把每个概念放回它诞生时要解决的痛点，就会发现它们其实很“朴素”。
我会按你最应该掌握的顺序讲清楚：rule、command、MCP、skill、agent，并尽量用 Claude Code 的使用场景来落地：怎么写、怎么用、怎么避免踩坑。你读完应该能把概念直接变成项目，再把项目变成内容。
1）先把主线讲明白：概念变多，是因为“上下文”分成了两类
很多人第一次接触 Agent，会觉得行业在“造词”。但你把它们拆开，会发现核心就两个东西：
- 静态上下文：每次对话都要加载的提示词（rules）
- 动态上下文：按需加载的代码和工具，不会撑爆初始上下文（skills）
剩下的那些概念，要么是某个阶段的工程折中产物，要么是为特定场景服务的装配件。
这条主线一旦抓住，你后面学什么都会很快：
你会本能地问一句——它是在解决“静态约束”还是“动态能力”？
2）Rules 是怎么来的：模型不是不会写代码，它是“会瞎编”
早期 AI 编程最典型的痛点，不是写不出代码，而是“瞎编”：
- 编一个根本不存在的库名
- 捏造一个你项目里没有的函数
- 给出看似合理但跑不通的调用方式
于是大家用最工程的方式解决：把项目规范、业务边界、常见错误写进 rules 文件，让每次对话都带上。
你可以把 rules 理解为：给模型一个长期不变的“团队规矩”。它通常会包含：
- 代码风格与规范（命名、目录结构、提交规范）
- 业务边界（哪些不能做、哪些必须做）
- 常见坑位（依赖版本、鉴权方式、边界条件）
- 输出格式（必须给出可运行步骤、必须附测试、必须解释变更点）
但规则写得越多，新问题就来了：上下文太大。
于是规则开始“长大”：越写越长、拆文件、嵌套引用……本质仍是一件事：把规矩全部塞进每次对话的上下文里。这就是静态上下文。
你在 Claude Code 里怎么用它更有效？我建议你从“最小可用规则”开始，而不是上来写长篇大论。
一个更不容易翻车的最小规则集，大致只做三件事：
1）限定边界
- 使用的语言/框架版本
- 项目目录结构不能乱改
- 不能凭空引入不存在的依赖
2）限定输出
- 每次改动必须列出“改了哪些文件、为什么改、如何验证”
- 需要你手动操作的命令必须逐条列出
3）限定行为
- 不确定就先提问，不允许“猜接口、猜字段”
- 需要外部信息（比如环境变量、鉴权）必须显式提醒
这样写的好处是：短、硬、可执行。模型更像一个“守规矩的新同事”，而不是一个爱发挥的写作机器人。
3）Commands 解决什么：把重复工作流变成一键动作
随着用 AI 写代码的人变多，固定工作流开始出现。
跑测试、提交代码、开 PR、生成变更总结、做一次 lint……你不会希望每次都重新描述一遍步骤，更不想让模型每次理解成不同版本。
于是出现了 commands（典型是 slash command）：把一套固定流程打包起来，需要时一键执行。
它解决的是两件事：
- 降低重复沟通成本：不用每次写一大段提示词
- 提升流程稳定性：把“怎么做”固化成流程模板，减少自由发挥
但你也会发现，command 多数时候仍偏“文本层封装”：它更像是把提示词收纳起来。它能让模型更听话，但未必能让它真正落地执行。
你在 Claude Code 里使用 command 的最佳姿势是：只封装“你每天都要做、且步骤清晰”的动作，例如：
- 代码评审前的检查清单：变更点、风险点、回滚方案
- 一键生成 PR 描述：背景、方案、影响范围、测试结果
- 一键生成发布说明：新增、修复、兼容性、注意事项
你会立刻感到一个变化：
AI 不再只是“帮我写代码”，它开始参与“工程协作的固定环节”。
4）MCP 解决什么：光会说不够，AI 还得能“干活”
当你想让 AI 真的干活时，单靠文本不够了。你需要它能够：
- 跑真实代码
- 连接真实系统
- 读写真实文件和数据
MCP server 不只是提示词，它是真的在跑代码。它可以连接现有系统，读 Slack 消息，创建 issue，做 OAuth 认证。
这一步的意义在于：把 AI 从“建议者”推向“执行者”。
但 MCP 也带来一个典型工程矛盾：工具越多，上下文越容易爆。
你想象一下：
- 你装了 10 个 MCP server
- 每个 server 有 10 个工具
- 你为了让模型知道它们存在，把所有工具说明都塞进初始上下文
结果就是：初始上下文被塞满，模型还没开始做事，就已经在“读说明书”里耗尽了预算。
所以 MCP 不是终点，它只是告诉我们：
工具调用需要标准，但能力管理需要“按需加载”。
这也直接引出了后面的 skill。
5）Modes、Subagents、Hooks：给非确定性系统加“结构”和“确定性”
当系统复杂到一定程度，光有工具还不够，你需要更强的组织方式。
Subagent：把任务拆开，把工具边界也拆开
Subagent 有点像带人设的提示词，可以限定能用哪些工具。你可以把它理解为：不同子任务配不同“工具权限”和“思考方式”。
当你让 Claude Code 做复杂任务时，最容易出错的是：它一口气想把规划、编码、测试、文档都做完，结果每一块都不够稳。
Subagent 的价值在于：让它“专心做一件事”。
Mode：切换工作状态，让输出更稳定、更容易被找到
Mode 更进一步，能修改系统提示词，开放新工具，甚至改 UI。
比如规划模式会提醒 AI：“你在做计划，专注于规划”，还提供专门工具来创建和修改计划。这样做的目的很明确：
- 输出更稳定
- 功能更容易被找到
你可以把它理解为：同一个人，切换到不同岗位职责。
Hooks：用确定性的钩子兜住不确定性
AI 本质是非确定性系统，会出错。于是有了 hooks：用完全确定性的机制，在对话开始前自动注入上下文，结束后自动记日志存数据库。
这一步非常关键，因为它解决的不是“模型能力”，而是“工程可追踪性”。
你越想把 AI 放进真实团队协作，你越需要“可追踪、可审计、可复盘”。
6）Skills 如何统一这一切：把动态能力做成模块，只有用的时候才加载
讲到这里你已经有一堆概念了。但仔细看，其实就两类：
- 静态上下文：每次对话都要加载的提示词（rules）
- 动态上下文：按需加载的代码和工具（skills）
Skills 就是用来统一动态上下文的。
最基础的 skill 就像 command：一个可复用的工作流。区别在于：
- skill 可以打包好，分享给团队
- 不占初始上下文
- 只有在用的时候才加载
最高级的 skill 可以包含脚本、可执行文件、资源文件，任何你想打包的东西。重点仍然是那句朴素但决定成败的话：
只有在需要时才加载。
它意味着什么？
意味着你终于可以把“大模型能力扩展”从“把一堆说明塞进对话”，升级成“像管理依赖一样管理能力”。
当你开始用 skill 组织能力，Claude Code 这类工具的体验会明显变化：
- 你不再害怕工具越装越多
- 你不再需要把一切写进规则里
- 你开始拥有“可复用的团队资产”
这也是为什么我说 skill 是阶段性分水岭：它把 Agent 的工程化推进了一大步。
7）Agent 到底是什么：不是更聪明的模型，是一套能持续行动的系统
很多人把 Agent 理解成“更聪明的模型”。但从这条演化史你会发现：Agent 从来不是单点能力，而是一套系统形态：
- 有静态约束（rules），保证基本行为一致
- 有可调用动作（commands / skills），能执行工作流
- 有工具连接（MCP），能接入外部世界
- 有组织结构（modes / subagents），能拆解复杂任务
- 有确定性保障（hooks），能把结果落地、可追踪
当这些拼在一起，模型才从“对话”走向“行动”。
换句话说：Agent 不是“会说”，是“会做 + 可控 + 可复用”。
8）Claude Code 的学习顺序：把它从“玩具”变成“同事”
如果你现在就想动手，我建议按下面这个顺序学，几乎不会走弯路。
第一步：先把 Rules 写短，别一上来就“写宪法”
你要的不是完美规则，而是最小约束：
- 项目语言与框架版本（避免它写不兼容代码）
- 目录结构（避免它乱放文件）
- 输出要求（必须给出变更点与验证方式）
把规则写得短、硬、可执行。你会明显感到：它开始像个“守规矩的新同事”。
第二步：把高频流程抽成 Command，减少重复对话成本
你每天都会做的事，才值得封装：
- 生成 PR 描述
- 代码评审检查清单
- 变更总结与风险提示
这一步做完，Claude Code 的价值会从“偶尔帮忙写段代码”变成“日常工程流程的加速器”。
第三步：需要它接触真实世界，再上 MCP
当你希望它读写仓库、对接协作系统、串起真实工具链，MCP 的价值会非常明显。
但要记住：工具越多越要克制，别把所有工具说明塞进初始上下文。
第四步：用 Skill 管理动态能力，把工作流变成团队可复用资产
把可复用的脚本、资源、工作流封装成 skill：
- 新同事不用背一堆提示词
- 模型不用一开始加载所有工具说明
- 需要什么能力就加载什么 skill
做到这里，你就不是在“调教模型”，而是在“设计工程系统”。
第五步：任务复杂到需要协作，再引入 Agent 的组织方式
当你要做的不再是“写一个函数”，而是“完成一个特性/修疑难 bug/写迁移方案”，你会自然需要：
- 规划与执行分离（mode）
- 子任务分工（subagent）
- 确定性记录与注入（hooks）
此时 Claude Code 对你来说，就更像一个能协作、能落地、能复盘的系统组件。
9）想写出“更高曝光”的 AI Agent 科普：用演化史当骨架，用痛点当钩子
如果你要在公众号、CSDN、掘金写“如何学习 AI 大模型 / AI Agent”，最容易被收藏转发的，不是堆术语，而是给读者一个能马上用的认知框架。
你可以直接用这条结构当文章目录：
- 为什么需要 rules：模型会瞎编 → 用静态约束兜底
- 为什么需要 command：流程重复 → 一键封装
- 为什么需要 MCP：光说不做 → 连接外部系统跑起来
- 为什么需要 modes/subagents/hooks：系统复杂且非确定 → 加结构与确定性
- 为什么 skill 是分水岭：按需加载 → 动态能力可复用、可分发
- 最终 agent 是什么：一套可行动、可控、可复用的系统形态
读者最缺的其实是三种确定感：
- 我知道每个概念解决什么痛点
- 我知道它们之间的先后关系
- 我知道我现在该学哪一个、怎么用在项目里
这三种确定感，就是技术科普最稀缺的价值，也是最容易带来收藏与关注的内容形态。
10）收束一句：AI 时代淘汰你的不是 AI，而是会用 AI 的人
这条从 Rule 到 Skill 的演化史，本质上是一条工程化路线。
大模型从来不缺能力，真正决定上限的是：
- 你能不能把不确定性关进笼子（rules、hooks）
- 你能不能把能力做成模块（commands、skills）
- 你能不能把工具接入真实世界（MCP）
- 你能不能把复杂任务组织成系统（modes、subagents、agent）
如果你觉得这篇把概念讲清楚了，建议先收藏，等你写规则/封装工作流时再回来看一遍，会更顺。
