Vibe Coding - AI 编程五件套：Rules、Commands、Subagent、MCP、Skills 实战指南

文章目录

• 一、引言：AI 编程，已经远不止“问一句、回一句”
• 二、Rules：先写好“项目宪法”，别让 AI 乱来
  • 2.1 Rules 是什么？
  • 2.2 在 Claude Code 里怎么写 Rules？
  • 2.3 Rules 具体能带来什么变化？
• 三、Commands：把“日常活”缩成一个命令
  • 3.1 Commands 是什么？
  • 3.2 Claude Code 里常见的 Commands
  • 3.3 Commands 的价值在哪？
• 四、Subagent：把复杂任务拆给多个“AI 专家”
  • 4.1 Subagent 是什么？
  • 4.2 使用 Subagent 的典型方式
  • 4.3 Subagent 的特点和适合场景
• 五、MCP：给 AI 插上统一的“外设接口”
  • 5.1 MCP 是什么，解决什么问题？
  • 5.2 MCP 的配置长什么样？
  • 5.3 MCP 带来的好处
• 六、Skills：像给 AI 插一套“技能包”
  • 6.1 Skills 是什么？和 MCP 有什么区别？
  • 6.2 一个 Skill 的典型结构
  • 6.3 MCP 和 Skills 的关系一图看懂
• 七、把五件套串起来：AI 从工具变“流水线”
• 八、实战建议
  • 8.1 第一步：先写一份像样的 Rules 文件
  • 8.2 第二步：挑 2～3 个高频场景做 Commands
  • 8.3 第三步：配置一两个关键 Subagent
  • 8.4 第四步：按需接入 MCP 和 Skills
• 九、总结

一、引言：AI 编程，已经远不止“问一句、回一句”

大部分人用 AI 编程工具的方式很像在用一个更聪明的搜索引擎：
问需求、等回复、不满意就反复修改。
这种用法当然有价值，但很难真正改变开发方式。

实际情况是，像 Claude Code、Cursor 这类工具，已经内置了一整套“可配置、可扩展”的能力体系：

• Rules：把你的习惯和规范写成规则，AI 长期遵守。
• Commands：把重复流程收敛成一个命令，按一下就跑完。
• Subagent：用多个“专家型 AI”分工协作，干更复杂的活。
• MCP：给 AI 一个统一“USB 接口”，可以安全访问文件、GitHub、数据库等。
• Skills：像给 AI 插技能卡，按需扩展具体能力。

理解并用好这五个概念，本质上是在搭一条“AI 驱动的开发流水线”，而不是只多了一个会写代码的聊天窗口。

接下来就从这五个概念出发，拆开讲清楚它们各自是干什么的、怎么配置、以及在真实项目里怎么组合使用。

二、Rules：先写好“项目宪法”，别让 AI 乱来

2.1 Rules 是什么？

Rules = 一次配置，永久生效的 AI 使用说明书。

日常开发时，你可能会反复说这些话：

• 用 TypeScript，不要用 JavaScript。
• 前端统一用 React 18 + Next.js 14。
• Promise 记得做错误处理。
• 组件用函数式，状态用 hooks。

这些一句句说，其实都是“规矩”。与其每个会话再说一遍，不如干脆写进 Rules 配置文件，让 AI 从一开始就按这个标准来工作。

2.2 在 Claude Code 里怎么写 Rules？

Claude Code 支持在项目里加一个 .claude/rules.md 文件，把规则写进去，比如：

*** description: Project coding rules always_apply: true *** # Coding Rules # Language & Framework - Use TypeScript for all new code - Use React 18 + Next.js 14 # Style - Indent with 2 spaces - Use single quotes for strings - Always end statements with semicolons # Error Handling - Always handle promises with try/catch - Do not swallow errors silently 

这里有几个关键信息点：

• always_apply: true 表示这些规则会自动应用到所有对话中。
• 可以从“技术栈、代码风格、安全规则”三个维度，把团队共识写进去。
• 这文件就像“项目级 README for AI”，但 AI 会认真遵守。

2.3 Rules 具体能带来什么变化？

• 从此不用再每次说“请用 TypeScript 写”“请用 React + Next.js”。
• ai 输出风格会更稳定，不再一个函数加分号、另一个不加。
• 对长期维护的项目很关键：哪怕换了会话、换了开发者，AI 的行为仍然一致。

一句话：
先把自己的“碎碎念”写成 Rules，AI 就会按这套“项目宪法”办事。

三、Commands：把“日常活”缩成一个命令

3.1 Commands 是什么？

核心定义是：

Commands = 把重复工作流程变成一个命令。

想想你日常有没有这些高频动作：

• 给某个文件补单元测试。
• 对一个改动做简单代码审查。
• 帮忙生成 commit message 并提交。
• 对一个模块做基础“质量体检”。

这些步骤如果每次都用自然语言重新描述，很浪费。更好的方式是：
把这些“流程”固化成一个命令，执行时只需要输入 /命令名 即可。

3.2 Claude Code 里常见的 Commands

Claude Code 内置了一批命令，通过 / 调用，例如：

/ help # 查看所有可用命令及说明 / test src/utils.ts # 为指定文件生成单元测试 / review # 对当前代码进行审查 / git commit # 辅助 Git 提交操作 

使用方式很简单：

• 直接输入 /命令名 即可触发。
• 部分命令支持参数，比如 /test src/utils.ts 指定文件路径。
• /help 能列出当前环境支持的所有命令及说明。

3.3 Commands 的价值在哪？

• 避免反复描述流程：比如“请帮我为这个文件写 Jest 单测，要求覆盖 X、Y、Z”，一条命令搞定。
• 团队口径统一：所有人写测试、做 Code Review 都走同一个命令，标准一致。
• 隐藏底层复杂度：命令背后可以是非常复杂的提示模板和多步操作，但对你来说就是一个统一入口。

一句话：
你可以把 Commands 当成“脚本 + prompt 模板”的组合，一次定义，反复使用。

四、Subagent：把复杂任务拆给多个“AI 专家”

4.1 Subagent 是什么？

Subagent = 一个任务，一个专家，分头干活。

现实中的团队协作大概是这样：

• 安全工程师做安全审计。
• 资深开发做架构和质量评审。
• 技术写作者维护文档。

同理，AI 这边也可以不是“一个大而全的助手”，而是多个各自专精的 Subagent：
每个 Subagent 提前设定好角色、能力范围和偏好，针对某一类任务深度优化。

4.2 使用 Subagent 的典型方式

几个很直观的例子：

# 安全审计 请启动 security-auditor 代理对 src/ 目录进行安全检查 # 代码分析 请使用 code-analyzer 分析这个模块的代码质量 # 多代理协作 请同时启动 security-auditor 和 code-analyzer， security-auditor 完成后，code-analyzer 再对结果进行分析 

常见模式有两种：

• 单代理专门干一类活：例如 security-auditor 只做安全相关检查。
• 多代理串行或并行：一个先查安全，另一个再在“查出的风险列表”基础上做进一步分析。

底层一般通过 Task 工具来调度：你只要描述需求，系统负责决定启动哪个 Subagent、怎么传递中间结果。

4.3 Subagent 的特点和适合场景

特点：

• 每个 Subagent 有独立上下文，互不干扰。
• 支持并行，适合把一个较大的任务拆开，提高整体速度。
• 可以培养出“对某一块业务/框架特别熟”的 AI 角色。

适合用 Subagent 的情况包括：

• 安全审计、性能优化、复杂架构 Review 等，需要不同关注点的场景。
• 对大型代码库做分模块分析，每个子模块配一个专门代理。
• 希望让不同“AI 角色”对同一个输出给出不同视角，比如一个评可维护性，一个评安全。

一句话：
Subagent 帮你把“一个 AI 做所有事”升级成“多个 AI 分工协作”。

五、MCP：给 AI 插上统一的“外设接口”

5.1 MCP 是什么，解决什么问题？

MCP（Model Context Protocol）是 Anthropic 提出的一个开放协议，原文里把它比喻为：

MCP = AI 界的 USB 接口，标准统一，插上就能用。

过去，各家工具要做这些事时都会各搞一套实现：

• 访问本地/远程文件系统。
• 操作 GitHub 仓库。
• 连接数据库（例如 Postgres）。

结果就是：你在不同工具里要重复配置、重复学习一遍调用方式，生态也很难统一。

MCP 想做的是：
把“怎么连外部系统”这件事标准化，你只需要按协议配置一次，任何支持 MCP 的工具都能用这套能力。

5.2 MCP 的配置长什么样？

一个 .mcp.json 的例子：

{"mcpServers":{"filesystem":{"command":"npx","args":["-y","@modelcontextprotocol/server-filesystem","/path/to/dir"]},"github":{"command":"npx","args":["-y","@modelcontextprotocol/server-github"],"env":{"GITHUB_TOKEN":"${GITHUB_TOKEN}"}},"postgres":{"command":"docker","args":["run","-i","--rm","mcp/postgres"]}}}

这段配置信息说明：

• 有三个 MCP Server：filesystem、github、postgres。
• 每个 Server 对应一个可执行命令和参数，比如通过 npx 启动文件系统 server 或 GitHub server。
• GitHub Server 需要 GITHUB_TOKEN 放在环境变量里，用来鉴权。
• Postgres 这块则是用 docker run 启动一个数据库相关的 MCP Server 镜像。

配置完成后，在支持 MCP 的工具里，AI 就可以做这些事：

• 读写指定目录下的文件（比如审查代码、重构、批量改名）。
• 查看 GitHub 仓库、PR、Issue，甚至根据 PR 内容直接生成 Review 意见。
• 查业务数据库、做统计分析、生成报表等。

5.3 MCP 带来的好处

• 配置可复用：接一次 MCP Server，多个 AI 工具都能用，不用每个插件重复搞一套。
• 安全可控：访问范围、命令执行方式、环境变量都集中在配置里管理，更容易审计和收紧权限。
• 能力上限更高：AI 不再局限在“对话框里的文本”，而是可以触达真实的工程和数据环境。

一句话：
有了 MCP，AI 从“看你发的文本”变成“能接入真实系统的可编程代理”。

六、Skills：像给 AI 插一套“技能包”

6.1 Skills 是什么？和 MCP 有什么区别？

• MCP 关注“怎么连”外部世界，是协议标准。
• Skills 关注“能做什么”具体功能，是能力实现。

可以这么理解：

MCP 是插线板和接口标准；
Skills 是插在上面的电器和功能模块。

例如，你想要的功能是“把一个 URL 里的内容抓出来，转成 Markdown 文档”，这就可以做成一个 Skill：

• Skill 本身负责解析 URL、处理内容、输出 Markdown。
• Skill 内部可能用 MCP 去拉取网页内容或读写文件。

6.2 一个 Skill 的典型结构

目录结构：

.skills/ ├── url-to-markdown/ │ ├── SKILL.yaml # 元数据 │ ├── prompts/ # 提示模板 │ ├── tools/ # 工具实现 │ └── resources/ # 配置资源 └── code-analyzer/ ├── SKILL.yaml └── ... 

其中 SKILL.yaml 是 Skill 的主配置文件，比如：

name: url-to-markdown version: 1.2.0 description: Convert URLs to markdown content capabilities:- url_extraction - content_conversion - markdown_formatting requirements:python:">=3.10"packages:- requests - beautifulsoup4 

这说明了几件事：

• 这个 Skill 叫 url-to-markdown，当前版本 1.2.0。
• 能力包括：提取 URL、转换内容、输出 Markdown。
• 运行环境需要 Python 3.10+，还要安装 requests 和 beautifulsoup4 这些包。

6.3 MCP 和 Skills 的关系一图看懂

所以在实际工程里，常见模式是：

• 先通过 MCP 配好 filesystem / github / postgres 等接口。
• 再通过 Skills 把“读文件 + 分析 + 输出报告”这整套流程封装成一个能力模块。

一句话：
MCP 让 AI 能“触达世界”，Skills 决定它“具体会做哪些事”。

七、把五件套串起来：AI 从工具变“流水线”

Rules（规则） ↓ “AI 要按什么方式工作” Subagent（子代理） ↓ “派哪个专业 AI 来做这件事” MCP（接口） + Skills（能力） + Commands（流程） ↓ “给 AI 什么工具和能力” 

如果我们把它翻译成一个“团队如何落地”的视角，大概是这样的：

1. 确定工作规矩：Rules
   • 统一技术栈（比如 TypeScript + React + Next.js 14）。
   • 统一代码风格（缩进、引号、分号等）。
   • 写清安全和错误处理的底线要求。
     AI 从一开始就按这套规矩工作。
2. 定义常用流程：Commands
   • 把最常用、最重复的任务（生成单测、代码审查、生成文档）固化成命令。
   • 让“流程”变成一个个可以随时调用的动作，而不是每次都讲一遍步骤。
3. 按角色拆分任务：Subagent
   • 给安全、架构、代码质量、文档等各自配一个 Subagent。
   • 需要时直接指名“用哪个代理来干这件事”，或者让 Task 系统自动分配。
4. 接入工程和数据：MCP + Skills
   • 用 MCP 接本地文件、GitHub 仓库、数据库等实际系统。
   • 用 Skills 封装具体能力，比如 URL 转 Markdown、代码分析、自动生成测试和文档。

结果就是：你不再是对着一个“万能但混乱的 AI”东一嘴西一嘴，而是站在一个更高层级上：

• 写好规则。
• 设计好流程。
• 配置好角色。
• 接上真实系统和能力模块。

让整套“AI 开发流水线”接管那些机械重复的部分。

八、实战建议

8.1 第一步：先写一份像样的 Rules 文件

• 在你的主项目里加一个 .claude/rules.md（或对应工具的规则文件）。
• 重点写三类内容：
  • 技术栈：比如“全部用 TypeScript”“前端用 React 18 + Next.js 14”。
  • 风格规约：缩进、引号、分号、命名习惯等。
  • 安全与错误处理：哪些 API 禁用、Promise 必须捕获错误、鉴权逻辑要遵守什么原则。

这一步很简单，但收益很高：AI 输出会明显更贴近团队标准。

8.2 第二步：挑 2～3 个高频场景做 Commands

• 回顾最近几周，你最常让 AI 做哪些事？
  • 写单测？审查 PR？给接口写文档？
• 从中挑出 2～3 个，把它们固化成命令：
  • 比如 /test your-file.ts、/review、/doc module-name。

先不要贪多，把“一个命令真正深入打磨好”比“十个半成品命令”更有价值。

8.3 第三步：配置一两个关键 Subagent

• 从你的项目需求出发，优先选出一两个关键角色：
  • 安全优先的项目 → security-auditor。
  • 代码质量要求高的项目 → code-analyzer。
• 在日常协作中有意识地切换：
  不要一句话啥都问一个 AI，而是明确“这个任务要哪个代理来做”。

8.4 第四步：按需接入 MCP 和 Skills

• 如果项目需要经常操作仓库、读写文件或查数据库，就值得接上 MCP：
  • filesystem 控制本地工程目录。
  • github 操作远程仓库。
  • postgres 之类访问业务数据。
• 然后再挑选合适的 Skills：
  • url-to-markdown 处理文档内容。
  • code-analyzer 做代码分析。

一开始不必全上，建议先从一两个 MCP Server + 一两个 Skills 起步，稳定运行后再逐步拓展。

九、总结

现在很多人在用 AI 编程工具时，自己成了“人肉复读机”，一遍又一遍地重复规范和流程。

而这五个概念，其实给了你一条很清晰的升级路线：

• Rules 帮你免掉重复交代。
• Commands 帮你免掉重复操作。
• Subagent 帮你拆解复杂任务，交给不同“AI 专家”。
• MCP 帮你把 AI 接入真实工程和数据世界。
• Skills 帮你按需扩展专业能力。

当你真正把这五件套用起来，你的角色会从“和 AI 对话的人”，变成“AI 开发流水线的设计者和调度者”。 这才是 AI 编程工具时代，开发者更值得投入精力的地方。