1. 从一堆术语说起Skills、Rules、Commands、MCP、Subagents 到底谁管谁如果你最近在折腾 AI 编程工具大概率被这几个词轮番轰炸过Skills、Rules、Commands、MCP、Subagents。单独拎出来每个都像那么回事凑一起就懵了——它们到底是并列关系还是谁调用谁配置该写在哪改了一个会不会把另一个搞崩我先把结论摆出来这五个东西不是同一层级的竞品而是一套从静态约束到动态执行的分工体系。Rules 是常驻的规矩Commands 是打包好的快捷动作MCP 是伸向外部世界的接口Subagents 是戴帽子分工的执行者而 Skills 是把前面这些按需组装、按需加载的容器。你可以把它们理解成一家公司的运作方式Rules 是员工手册Commands 是常用审批流程MCP 是对外联络通道Subagents 是不同岗位的人Skills 则是接到某类任务时该翻哪本手册、叫哪个人、走哪条通道的调度清单。这篇不聊虚的进化史直接给你能落地的配置骨架。我会用settings.json和config.toml两份可复制文件把 Rules、Commands、MCP、Subagents 串起来再演示怎么通过 TaoToken 统一 Key 和 API 通道让 CC Switch 和 Cline 这类客户端都走同一个入口。最后附上验证动作确认每个组件真的生效而不是你以为它生效了。适合谁看已经在用 Claude Code、Cline、Cursor 这类工具但配置越堆越乱、搞不清哪个文件管哪件事的开发者。如果你还没开始配也能照着从零搭一套最小骨架。2. 前置准备用 TaoToken 统一 Key 与 API 通道在讲配置骨架之前得先把通道这件事解决。很多人配置乱根源是每个客户端各填一套 Key、各写一个 Base URL改一处漏一处。我的做法是所有客户端统一指向 TaoToken 的 API 通道Key 也只维护一份。TaoToken 在这里扮演的是统一入口的角色官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 这个不加 UTM。你需要在控制台创建一个 API Key后面 CC Switch 和 Cline 都复用它。具体动作分三步。第一步打开控制台页面 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 登录后进入 API Keys 管理页 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 新建一个 Key 并复制保存。第二步确认你要用的模型名可以在模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 先手动聊一句确认通道通、模型可用。第三步把 Key 和 Base URL 填进各客户端。注意Key 只创建一次、只存一处客户端里全部引用同一个值。这样后面排查问题时你只需要确认通道通不通而不用怀疑是不是这个客户端的 Key 过期了。如果你打算长期跑编码任务或 Agent 工作流可以顺带看下 Coding Plan 页面 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 把额度模式先规划好避免跑到一半断流。接入细节如果卡住文档页 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里有完整的参数说明。3. 可复制配置骨架settings.json 与 config.toml这一节是全文的核心。我把配置拆成两份文件settings.json负责客户端侧的模型通道与 Rules/Commands 挂载config.toml负责 MCP Server 与 Subagents 的声明。两份文件配合才能把五个概念真正串起来。3.1 settings.json通道、Rules、Commands 三合一先看settings.json。这份文件的核心作用是告诉客户端用哪个 API 通道、加载哪些 Rules、注册哪些 Commands。{ api: { baseUrl: https://taotoken.net/api, apiKey: sk-你的TaoToken密钥, model: claude-sonnet-4-5, timeoutMs: 120000 }, rules: { enabled: true, files: [ .ai/rules/project.md, .ai/rules/style.md ], alwaysLoad: true }, commands: { dir: .ai/commands, items: [ { name: commit, file: commit.md, description: 生成 commit message 并推送 }, { name: review, file: review.md, description: 对当前 diff 做代码审查 } ] } }这里有几个关键点。api.baseUrl填 TaoToken 的 API 地址注意不要带 UTM 参数保持干净。rules.alwaysLoad设为 true意味着每次对话开始前Rules 文件都会被读进上下文——这就是 Rules 的常驻特性。commands.items里每一条对应.ai/commands/目录下的一个 Markdown 文件文件内容就是你原本要手打的那串提示词。Rules 文件本身长这样放在.ai/rules/project.md# 项目规则 - 语言Python 3.11禁止引入 Java 风格命名 - 缩进4 空格禁止 Tab - 依赖新增库前必须先说明理由 - 提交commit message 使用中文格式为「类型: 描述」Commands 文件放在.ai/commands/commit.md请执行以下操作 1. 查看当前 git diff 2. 生成符合项目规范的中文 commit message 3. 执行 git add 与 git commit 4. 推送到当前分支配好之后你在客户端里敲/commit就等于把这一整段提示词发出去。Commands 的本质就是提示词打包 快捷触发它解决的是重复劳动。3.2 config.tomlMCP Server 与 Subagents 声明settings.json管的是规矩和快捷动作config.toml管的是对外连接和分工执行。MCP Server 在这里注册Subagents 也在这里声明。[api] base_url https://taotoken.net/api api_key sk-你的TaoToken密钥 model claude-sonnet-4-5 [mcp_servers.filesystem] command npx args [-y, modelcontextprotocol/server-filesystem, ./workspace] enabled true [mcp_servers.fetch] command npx args [-y, modelcontextprotocol/server-fetch] enabled true [subagents.architect] description 负责架构设计与模块拆分 model claude-sonnet-4-5 tools [filesystem] rules [.ai/rules/project.md] [subagents.debugger] description 专注定位与修复缺陷 model claude-sonnet-4-5 tools [filesystem, fetch] rules [.ai/rules/style.md]mcp_servers段每一条就是一个 MCP Servercommand和args决定它怎么启动enabled控制开关。MCP 的作用是让 AI 能伸手去读文件、抓网页、查数据库——它解决的是连接问题。但要注意MCP Server 不是越多越好挂太多工具会让模型注意力分散所以按需开启。subagents段是分工的关键。architect只挂filesystem工具debugger多挂一个fetch。每个 Subagent 有自己的rules和tools白名单这就是限制视野、提高可靠性的落地方式。Subagent 不是新模型而是同一模型在不同工具集和规则下的受限实例。3.3 Skills 作为调度层把上面四者折叠起来现在回到 Skills。Skills 不是第五个独立配置项而是把 Rules、Commands、MCP、Subagents 按场景组装起来的调度层。一个 Skill 可以声明当我处理数据库迁移任务时加载哪条 Rule、调用哪个 Command、启用哪个 MCP、交给哪个 Subagent。# Skill: db-migration ## 触发条件 用户提到「迁移」「migration」「改表结构」 ## 加载 - rules: .ai/rules/project.md - commands: review - mcp: filesystem - subagent: architect ## 执行步骤 1. 读取当前 schema 文件 2. 生成迁移脚本草稿 3. 调用 review 命令做自检 4. 输出变更说明这样你就不用在每次对话里手动指定用哪个规则、开哪个工具Skill 帮你按需加载。Skills 的美妙之处在于按需——你可以有几十个 Skill但同一时刻只有相关的那个被激活上下文不会被塞爆。4. 验证请求确认每个组件真的生效配置写完不代表生效。这一节给你一套验证动作逐个确认 Rules、Commands、MCP、Subagents 和通道都通了。第一步验证 API 通道。在客户端里发一句最简单的请求比如回复 OK。如果返回正常说明baseUrl和apiKey没问题。如果报 401检查 Key 是否复制完整如果报超时检查timeoutMs是否太小。第二步验证 Rules 生效。在对话里问我的项目用什么语言和缩进。如果 AI 回答出 Python 3.11 和 4 空格说明 Rules 被正确加载。如果它答不上来检查rules.files路径是否写对、alwaysLoad是否为 true。第三步验证 Commands。敲/commit看它是否触发了 git 操作流程。如果没反应检查commands.dir和items里的file是否对得上文件名大小写敏感。第四步验证 MCP。让 AI 读一个工作区里的文件比如读一下 workspace 下的 README。如果它能读到内容说明 filesystem MCP 通了。如果报工具不可用检查mcp_servers里的command是否能在终端里手动跑通。第五步验证 Subagents。触发一个架构类问题比如帮我拆分这个模块。观察它是否调用了 architect 的规则和工具集。如果它用了 debugger 的工具说明 Subagent 路由没配对。下面是一个快速自检的请求示例你可以直接贴进对话请依次回答 1. 当前加载了哪些 rules 文件 2. 可用的 commands 有哪些 3. 已启用的 MCP server 列表 4. 当前可调用的 subagents 有哪些如果这四问都能答对说明你的配置骨架已经跑通了。答不对的那一项回到对应章节检查。5. 本篇常见错排查配置过程中最容易踩的坑我按出现频率排一下。错误一Base URL 带了多余路径。有人把https://taotoken.net/api写成https://taotoken.net/api/v1/chat结果 404。正确做法是只填到/api具体路径由客户端自己拼。错误二Rules 文件路径用绝对路径。settings.json里的rules.files建议用相对项目根目录的路径绝对路径换台机器就失效。错误三MCP Server 启动命令在客户端环境里找不到。比如npx在终端能用但客户端启动时 PATH 不同。解决办法是在command里写npx的绝对路径或者确认客户端继承的环境变量。错误四Subagent 的 tools 白名单写成了不存在的名字。tools [filesystem]里的名字必须和mcp_servers段的键名一致写错就静默失效不报错但工具调不到。错误五Commands 文件名和 items 里的 file 不一致。比如文件叫commit.mditems 里写commit.txt触发时找不到文件。大小写也要一致。错误六Key 在多个客户端里各存一份改了一处忘了另一处。这就是为什么前面强调统一走 TaoToken 通道、只维护一份 Key。如果发现某个客户端突然 401先确认它的 Key 是不是旧的。错误七Skills 触发条件写得太宽泛。比如触发词只写改结果每次改代码都激活迁移 Skill上下文被无关内容占满。触发条件要具体宁可窄一点。排查顺序建议先确认通道通能收到任何回复再确认 Rules 加载问项目规范再确认 Commands敲斜杠命令最后确认 MCP 和 Subagents让它调工具。一层层往下不要跳步。6. 把配置沉淀成可复用资产走到这里你已经有了两份可复制的配置骨架、一套验证动作和一份排错清单。接下来真正拉开差距的不是再学几个新术语而是把 Rules 和 Skills 当成有生命的产品去迭代。我的习惯是每次 AI 搞砸了先别急着改代码回头看看是哪条 Rule 没写清楚或者哪个 Skill 的触发条件太模糊。改配置比改代码的收益更持久因为它会影响之后每一次对话。Rules 保持精简高质量Skills 按工作流封装Commands 把重复动作固化下来MCP 只开当前需要的Subagents 按职责切分工具集。如果你还没接入统一通道可以从 API Keys 页面 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 建一个 Key 开始接入细节看文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。想先验证模型效果去模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 聊两句。长期跑编码和 Agent 任务的话Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 能把额度规划清楚。Claude Code 相关的接入配置可以参考 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite 。最后留一个我自己的实践把.ai/目录整个提交进代码库团队里每个人拉下来就是同一套 Rules、Commands 和 Skills。新人入职不用口头交接我们项目 AI 该怎么用配置本身就是文档。这比任何术语科普都管用。
1. 从一堆术语说起Skills、Rules、Commands、MCP、Subagents 到底谁管谁如果你最近在折腾 AI 编程工具大概率被这几个词轮番轰炸过Skills、Rules、Commands、MCP、Subagents。单独拎出来每个都像那么回事凑一起就懵了——它们到底是并列关系还是谁调用谁配置该写在哪改了一个会不会把另一个搞崩我先把结论摆出来这五个东西不是同一层级的竞品而是一套从静态约束到动态执行的分工体系。Rules 是常驻的规矩Commands 是打包好的快捷动作MCP 是伸向外部世界的接口Subagents 是戴帽子分工的执行者而 Skills 是把前面这些按需组装、按需加载的容器。你可以把它们理解成一家公司的运作方式Rules 是员工手册Commands 是常用审批流程MCP 是对外联络通道Subagents 是不同岗位的人Skills 则是接到某类任务时该翻哪本手册、叫哪个人、走哪条通道的调度清单。这篇不聊虚的进化史直接给你能落地的配置骨架。我会用settings.json和config.toml两份可复制文件把 Rules、Commands、MCP、Subagents 串起来再演示怎么通过 TaoToken 统一 Key 和 API 通道让 CC Switch 和 Cline 这类客户端都走同一个入口。最后附上验证动作确认每个组件真的生效而不是你以为它生效了。适合谁看已经在用 Claude Code、Cline、Cursor 这类工具但配置越堆越乱、搞不清哪个文件管哪件事的开发者。如果你还没开始配也能照着从零搭一套最小骨架。2. 前置准备用 TaoToken 统一 Key 与 API 通道在讲配置骨架之前得先把通道这件事解决。很多人配置乱根源是每个客户端各填一套 Key、各写一个 Base URL改一处漏一处。我的做法是所有客户端统一指向 TaoToken 的 API 通道Key 也只维护一份。TaoToken 在这里扮演的是统一入口的角色官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 这个不加 UTM。你需要在控制台创建一个 API Key后面 CC Switch 和 Cline 都复用它。具体动作分三步。第一步打开控制台页面 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 登录后进入 API Keys 管理页 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 新建一个 Key 并复制保存。第二步确认你要用的模型名可以在模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 先手动聊一句确认通道通、模型可用。第三步把 Key 和 Base URL 填进各客户端。注意Key 只创建一次、只存一处客户端里全部引用同一个值。这样后面排查问题时你只需要确认通道通不通而不用怀疑是不是这个客户端的 Key 过期了。如果你打算长期跑编码任务或 Agent 工作流可以顺带看下 Coding Plan 页面 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 把额度模式先规划好避免跑到一半断流。接入细节如果卡住文档页 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里有完整的参数说明。3. 可复制配置骨架settings.json 与 config.toml这一节是全文的核心。我把配置拆成两份文件settings.json负责客户端侧的模型通道与 Rules/Commands 挂载config.toml负责 MCP Server 与 Subagents 的声明。两份文件配合才能把五个概念真正串起来。3.1 settings.json通道、Rules、Commands 三合一先看settings.json。这份文件的核心作用是告诉客户端用哪个 API 通道、加载哪些 Rules、注册哪些 Commands。{ api: { baseUrl: https://taotoken.net/api, apiKey: sk-你的TaoToken密钥, model: claude-sonnet-4-5, timeoutMs: 120000 }, rules: { enabled: true, files: [ .ai/rules/project.md, .ai/rules/style.md ], alwaysLoad: true }, commands: { dir: .ai/commands, items: [ { name: commit, file: commit.md, description: 生成 commit message 并推送 }, { name: review, file: review.md, description: 对当前 diff 做代码审查 } ] } }这里有几个关键点。api.baseUrl填 TaoToken 的 API 地址注意不要带 UTM 参数保持干净。rules.alwaysLoad设为 true意味着每次对话开始前Rules 文件都会被读进上下文——这就是 Rules 的常驻特性。commands.items里每一条对应.ai/commands/目录下的一个 Markdown 文件文件内容就是你原本要手打的那串提示词。Rules 文件本身长这样放在.ai/rules/project.md# 项目规则 - 语言Python 3.11禁止引入 Java 风格命名 - 缩进4 空格禁止 Tab - 依赖新增库前必须先说明理由 - 提交commit message 使用中文格式为「类型: 描述」Commands 文件放在.ai/commands/commit.md请执行以下操作 1. 查看当前 git diff 2. 生成符合项目规范的中文 commit message 3. 执行 git add 与 git commit 4. 推送到当前分支配好之后你在客户端里敲/commit就等于把这一整段提示词发出去。Commands 的本质就是提示词打包 快捷触发它解决的是重复劳动。3.2 config.tomlMCP Server 与 Subagents 声明settings.json管的是规矩和快捷动作config.toml管的是对外连接和分工执行。MCP Server 在这里注册Subagents 也在这里声明。[api] base_url https://taotoken.net/api api_key sk-你的TaoToken密钥 model claude-sonnet-4-5 [mcp_servers.filesystem] command npx args [-y, modelcontextprotocol/server-filesystem, ./workspace] enabled true [mcp_servers.fetch] command npx args [-y, modelcontextprotocol/server-fetch] enabled true [subagents.architect] description 负责架构设计与模块拆分 model claude-sonnet-4-5 tools [filesystem] rules [.ai/rules/project.md] [subagents.debugger] description 专注定位与修复缺陷 model claude-sonnet-4-5 tools [filesystem, fetch] rules [.ai/rules/style.md]mcp_servers段每一条就是一个 MCP Servercommand和args决定它怎么启动enabled控制开关。MCP 的作用是让 AI 能伸手去读文件、抓网页、查数据库——它解决的是连接问题。但要注意MCP Server 不是越多越好挂太多工具会让模型注意力分散所以按需开启。subagents段是分工的关键。architect只挂filesystem工具debugger多挂一个fetch。每个 Subagent 有自己的rules和tools白名单这就是限制视野、提高可靠性的落地方式。Subagent 不是新模型而是同一模型在不同工具集和规则下的受限实例。3.3 Skills 作为调度层把上面四者折叠起来现在回到 Skills。Skills 不是第五个独立配置项而是把 Rules、Commands、MCP、Subagents 按场景组装起来的调度层。一个 Skill 可以声明当我处理数据库迁移任务时加载哪条 Rule、调用哪个 Command、启用哪个 MCP、交给哪个 Subagent。# Skill: db-migration ## 触发条件 用户提到「迁移」「migration」「改表结构」 ## 加载 - rules: .ai/rules/project.md - commands: review - mcp: filesystem - subagent: architect ## 执行步骤 1. 读取当前 schema 文件 2. 生成迁移脚本草稿 3. 调用 review 命令做自检 4. 输出变更说明这样你就不用在每次对话里手动指定用哪个规则、开哪个工具Skill 帮你按需加载。Skills 的美妙之处在于按需——你可以有几十个 Skill但同一时刻只有相关的那个被激活上下文不会被塞爆。4. 验证请求确认每个组件真的生效配置写完不代表生效。这一节给你一套验证动作逐个确认 Rules、Commands、MCP、Subagents 和通道都通了。第一步验证 API 通道。在客户端里发一句最简单的请求比如回复 OK。如果返回正常说明baseUrl和apiKey没问题。如果报 401检查 Key 是否复制完整如果报超时检查timeoutMs是否太小。第二步验证 Rules 生效。在对话里问我的项目用什么语言和缩进。如果 AI 回答出 Python 3.11 和 4 空格说明 Rules 被正确加载。如果它答不上来检查rules.files路径是否写对、alwaysLoad是否为 true。第三步验证 Commands。敲/commit看它是否触发了 git 操作流程。如果没反应检查commands.dir和items里的file是否对得上文件名大小写敏感。第四步验证 MCP。让 AI 读一个工作区里的文件比如读一下 workspace 下的 README。如果它能读到内容说明 filesystem MCP 通了。如果报工具不可用检查mcp_servers里的command是否能在终端里手动跑通。第五步验证 Subagents。触发一个架构类问题比如帮我拆分这个模块。观察它是否调用了 architect 的规则和工具集。如果它用了 debugger 的工具说明 Subagent 路由没配对。下面是一个快速自检的请求示例你可以直接贴进对话请依次回答 1. 当前加载了哪些 rules 文件 2. 可用的 commands 有哪些 3. 已启用的 MCP server 列表 4. 当前可调用的 subagents 有哪些如果这四问都能答对说明你的配置骨架已经跑通了。答不对的那一项回到对应章节检查。5. 本篇常见错排查配置过程中最容易踩的坑我按出现频率排一下。错误一Base URL 带了多余路径。有人把https://taotoken.net/api写成https://taotoken.net/api/v1/chat结果 404。正确做法是只填到/api具体路径由客户端自己拼。错误二Rules 文件路径用绝对路径。settings.json里的rules.files建议用相对项目根目录的路径绝对路径换台机器就失效。错误三MCP Server 启动命令在客户端环境里找不到。比如npx在终端能用但客户端启动时 PATH 不同。解决办法是在command里写npx的绝对路径或者确认客户端继承的环境变量。错误四Subagent 的 tools 白名单写成了不存在的名字。tools [filesystem]里的名字必须和mcp_servers段的键名一致写错就静默失效不报错但工具调不到。错误五Commands 文件名和 items 里的 file 不一致。比如文件叫commit.mditems 里写commit.txt触发时找不到文件。大小写也要一致。错误六Key 在多个客户端里各存一份改了一处忘了另一处。这就是为什么前面强调统一走 TaoToken 通道、只维护一份 Key。如果发现某个客户端突然 401先确认它的 Key 是不是旧的。错误七Skills 触发条件写得太宽泛。比如触发词只写改结果每次改代码都激活迁移 Skill上下文被无关内容占满。触发条件要具体宁可窄一点。排查顺序建议先确认通道通能收到任何回复再确认 Rules 加载问项目规范再确认 Commands敲斜杠命令最后确认 MCP 和 Subagents让它调工具。一层层往下不要跳步。6. 把配置沉淀成可复用资产走到这里你已经有了两份可复制的配置骨架、一套验证动作和一份排错清单。接下来真正拉开差距的不是再学几个新术语而是把 Rules 和 Skills 当成有生命的产品去迭代。我的习惯是每次 AI 搞砸了先别急着改代码回头看看是哪条 Rule 没写清楚或者哪个 Skill 的触发条件太模糊。改配置比改代码的收益更持久因为它会影响之后每一次对话。Rules 保持精简高质量Skills 按工作流封装Commands 把重复动作固化下来MCP 只开当前需要的Subagents 按职责切分工具集。如果你还没接入统一通道可以从 API Keys 页面 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 建一个 Key 开始接入细节看文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。想先验证模型效果去模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 聊两句。长期跑编码和 Agent 任务的话Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 能把额度规划清楚。Claude Code 相关的接入配置可以参考 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite 。最后留一个我自己的实践把.ai/目录整个提交进代码库团队里每个人拉下来就是同一套 Rules、Commands 和 Skills。新人入职不用口头交接我们项目 AI 该怎么用配置本身就是文档。这比任何术语科普都管用。
