即刻App年轻人的同好社区
下载
AI 编程工具里有个让人头疼的问题：
rules、commands、MCP servers、subagents、modes、hooks、tools 一堆概念，搞得比学一门新编程语言还复杂。
Cursor 的 Lee Robinson 出了个视频解释和介绍的非常好。
其实这些东西最后都能归纳为两个核心概念：
静态上下文和动态上下文。或者说得更直白点，就是 rules 和 skills。
======
Rules 的诞生
最早做 AI 编程的时候，模型老爱瞎编。你让它写个函数，它能给你造出一个根本不存在的库。
于是就有了 rules 文件，把代码规范、业务需求、模型经常犯的错误都写进去，每次对话都带上。这招挺管用的。
后来 rules 文件越写越长，就开始拆分成多个文件，可以嵌套引用。但本质上还是一回事：把这些规则全部塞进每次对话的上下文里。
这就是静态上下文，static context。不管你要做什么任务，这些信息都会被加载进来。
------
Commands 出现了
随着用 AI 写代码的人变多，一些固定的工作流开始出现。比如我每次都要先跑测试，再提交代码，最后开 PR。
这时候就需要 slash command，把一套固定的提示词打包起来，需要的时候 /command 一下就行。
比如我现在用的 /commit 命令，一键就能完成 Git 提交和开 PR 的整套流程。这些 command 还能分享给团队，放到 Git 里统一管理。
到这里，我们还是在处理文本，只是把提示词组织得更灵活了。
======
MCP Servers 带来新能力
光有文本不够，AI 还得能干活。这就有了 MCP（Model Context Protocol）服务器。
MCP server 不只是个提示词，它是真的在跑代码。可以连到你现有的系统，读取 Slack 消息，创建 Linear issue，做 OAuth 认证。
这相当于给 AI 添加了新技能，第三方工具的能力。就像人类编程有各种库可以调用，AI 也有了自己的"工具箱"。
但问题来了：如果你装了 10 个 MCP server，每个都有 10 个工具，那初始上下文就会被塞满。这就是为什么后面又有了新的优化。
======
Modes 和 Subagents 的登场
到这一步，我们有两种往上下文里塞东西的方式：文本（rules、commands）和代码（MCP servers）。
接下来是 modes 和 subagents。Subagent 有点像带人设的提示词，可以限定它能用哪些工具。Mode 更进一步，不光能改指令，还能修改系统提示词，给 AI 开放新工具，甚至改 UI。
比如规划模式 plan mode，会提醒 AI "你现在在做计划，专注于规划"，还提供专门的工具来创建和修改计划。
这些设计的核心目的是两个：可靠性和可发现性。让 AI 的输出更稳定，让功能更容易被用户找到。
但你得记住，AI 本质上还是个非确定性系统，还是会出错。
------
Hooks 解决确定性问题
于是又有了 hooks，给 AI 加上完全确定性的钩子。
比如每次对话开始前，自动注入一些上下文（其实就是静态上下文的另一种实现）。或者对话结束后，自动触发某个操作，比如记日志或存数据库。
这些是 100% 确定执行的，不会出错。
======
Skills 统一了一切
讲到这里，我们已经有一堆概念了。但仔细看，其实就两类：
▸ 静态上下文：每次对话都要加载的提示词（rules）
▸ 动态上下文：按需加载的代码和工具，不会撑爆初始上下文（skills）
Skills 就是用来统一动态上下文的。
最基础的 skill 就像 command，一个可复用的工作流，比如我的 Git PR 流程。打包好，分享给团队，不占初始上下文。
最高级的 skill 可以包含脚本、可执行文件、资源文件，任何你想打包的东西。重点是只有在用的时候才加载，不用就不占空间。
这就把世界简化了：作为用户，你只需要关心 rules 和 skills 两个东西。
------
编程工具的优化
有了 skills 这个概念，编程工具也能做优化。
比如 Cursor 现在就学习了 skills 的思路：你装 10 个 MCP server，每个有 10 个工具，不会一上来就全加载。只有真用到的时候才加载对应的工具。
所以你可以继续用 MCP，如果需要 OAuth 这种高级功能的话（这是目前 MCP 和 skill 的主要区别）。
另外可能还需要 hooks 来处理一些确定性的任务，或者自定义 subagent。但大部分时候，作为用户你只需要想两件事：
▸ Rules：我需要给 AI 提供什么静态上下文
▸ Skills：我需要给 AI 什么动态能力
======
最佳实践
Rules 的使用建议
把 rules 当成一个"活的"文档。只放最少但最高质量的上下文，因为它会在每次对话中都被加载。
每次看到 AI 犯错，不管是本地开发还是 PR review，我就会说"嘿，把这个加到我的 agents. md 或者 cursor rule 里"。让它自己更新和进化。
现在这个还有统一标准了，挺方便的。
------
Skills 的探索
Skills 太新了，现在还没有特别成熟的最佳实践。
但我预计接下来 6 个月，随着更多人开始用 skills，生态建起来之后，会变得越来越重要。值得关注。
来源：x.com/leerob/status/2011810357942084085
rules、commands、MCP servers、subagents、modes、hooks、tools 一堆概念，搞得比学一门新编程语言还复杂。
Cursor 的 Lee Robinson 出了个视频解释和介绍的非常好。
其实这些东西最后都能归纳为两个核心概念：
静态上下文和动态上下文。或者说得更直白点，就是 rules 和 skills。
======
Rules 的诞生
最早做 AI 编程的时候，模型老爱瞎编。你让它写个函数，它能给你造出一个根本不存在的库。
于是就有了 rules 文件，把代码规范、业务需求、模型经常犯的错误都写进去，每次对话都带上。这招挺管用的。
后来 rules 文件越写越长，就开始拆分成多个文件，可以嵌套引用。但本质上还是一回事：把这些规则全部塞进每次对话的上下文里。
这就是静态上下文，static context。不管你要做什么任务，这些信息都会被加载进来。
------
Commands 出现了
随着用 AI 写代码的人变多，一些固定的工作流开始出现。比如我每次都要先跑测试，再提交代码，最后开 PR。
这时候就需要 slash command，把一套固定的提示词打包起来，需要的时候 /command 一下就行。
比如我现在用的 /commit 命令，一键就能完成 Git 提交和开 PR 的整套流程。这些 command 还能分享给团队，放到 Git 里统一管理。
到这里，我们还是在处理文本，只是把提示词组织得更灵活了。
======
MCP Servers 带来新能力
光有文本不够，AI 还得能干活。这就有了 MCP（Model Context Protocol）服务器。
MCP server 不只是个提示词，它是真的在跑代码。可以连到你现有的系统，读取 Slack 消息，创建 Linear issue，做 OAuth 认证。
这相当于给 AI 添加了新技能，第三方工具的能力。就像人类编程有各种库可以调用，AI 也有了自己的"工具箱"。
但问题来了：如果你装了 10 个 MCP server，每个都有 10 个工具，那初始上下文就会被塞满。这就是为什么后面又有了新的优化。
======
Modes 和 Subagents 的登场
到这一步，我们有两种往上下文里塞东西的方式：文本（rules、commands）和代码（MCP servers）。
接下来是 modes 和 subagents。Subagent 有点像带人设的提示词，可以限定它能用哪些工具。Mode 更进一步，不光能改指令，还能修改系统提示词，给 AI 开放新工具，甚至改 UI。
比如规划模式 plan mode，会提醒 AI "你现在在做计划，专注于规划"，还提供专门的工具来创建和修改计划。
这些设计的核心目的是两个：可靠性和可发现性。让 AI 的输出更稳定，让功能更容易被用户找到。
但你得记住，AI 本质上还是个非确定性系统，还是会出错。
------
Hooks 解决确定性问题
于是又有了 hooks，给 AI 加上完全确定性的钩子。
比如每次对话开始前，自动注入一些上下文（其实就是静态上下文的另一种实现）。或者对话结束后，自动触发某个操作，比如记日志或存数据库。
这些是 100% 确定执行的，不会出错。
======
Skills 统一了一切
讲到这里，我们已经有一堆概念了。但仔细看，其实就两类：
▸ 静态上下文：每次对话都要加载的提示词（rules）
▸ 动态上下文：按需加载的代码和工具，不会撑爆初始上下文（skills）
Skills 就是用来统一动态上下文的。
最基础的 skill 就像 command，一个可复用的工作流，比如我的 Git PR 流程。打包好，分享给团队，不占初始上下文。
最高级的 skill 可以包含脚本、可执行文件、资源文件，任何你想打包的东西。重点是只有在用的时候才加载，不用就不占空间。
这就把世界简化了：作为用户，你只需要关心 rules 和 skills 两个东西。
------
编程工具的优化
有了 skills 这个概念，编程工具也能做优化。
比如 Cursor 现在就学习了 skills 的思路：你装 10 个 MCP server，每个有 10 个工具，不会一上来就全加载。只有真用到的时候才加载对应的工具。
所以你可以继续用 MCP，如果需要 OAuth 这种高级功能的话（这是目前 MCP 和 skill 的主要区别）。
另外可能还需要 hooks 来处理一些确定性的任务，或者自定义 subagent。但大部分时候，作为用户你只需要想两件事：
▸ Rules：我需要给 AI 提供什么静态上下文
▸ Skills：我需要给 AI 什么动态能力
======
最佳实践
Rules 的使用建议
把 rules 当成一个"活的"文档。只放最少但最高质量的上下文，因为它会在每次对话中都被加载。
每次看到 AI 犯错，不管是本地开发还是 PR review，我就会说"嘿，把这个加到我的 agents. md 或者 cursor rule 里"。让它自己更新和进化。
现在这个还有统一标准了，挺方便的。
------
Skills 的探索
Skills 太新了，现在还没有特别成熟的最佳实践。
但我预计接下来 6 个月，随着更多人开始用 skills，生态建起来之后，会变得越来越重要。值得关注。
来源：x.com/leerob/status/2011810357942084085
45 621
来自圈子
AI探索站
104009人已经加入