从 Prompt 到 AI 工程化：理解 Rules、Skills 与 Agent

什么是 Skills，什么是 Rules？

很多人在刚开始使用 AI 写代码时，主要依赖 Prompt：

text 复制代码

帮我了解这个项目架构，然后把这篇文章内容写进去。

这种方式可以完成一次任务，但很难稳定复用。因为每次对话都是新的上下文推理，AI 不会天然记住团队规范、项目结构、输出风格和交付流程。

所以从个人试用走向团队工程化时，我们需要把"临时提示"沉淀成两类能力：

text 复制代码

Rules：让 AI 不跑偏
Skills：让 AI 会做事

一、先建立整体认知

在 Cursor 里，可以先用一张图理解它们的位置：

flowchart TD P[Prompt
当前这次需求] --> A[AI Agent] R[Rules
长期约束] --> A S[Skills
任务流程] --> A A --> M[MCP
工具连接] A --> SA[SubAgent
并行分工] M --> O[代码 / 文档 / PR / 外部系统] SA --> O style R fill:#e3f2fd style S fill:#fff8e1 style M fill:#f3e5f5 style SA fill:#e8f5e9

一句话区分：

概念	解决的问题	类比
Prompt	这一次要做什么	临时需求
Rules	AI 应该遵守什么边界	项目规范 / ESLint
Skills	AI 应该按什么流程做事	SOP / npm scripts
MCP	AI 能调用哪些工具	GitHub / Figma / 终端接口
SubAgent	大任务如何并行拆解	多个协作同学

推荐理解顺序是：

text 复制代码

先理解 Rules：AI 的边界是什么
再理解 Skills：AI 的流程是什么
最后理解 Agent / MCP / SubAgent：AI 如何执行复杂任务

二、为什么 Prompt 不够用了？

只靠 Prompt，常见问题会很明显：

同一个需求，不同时间生成的代码风格不一致
AI 容易忘记项目技术栈和目录结构
每次都要重复说明团队规范
复杂任务没有稳定步骤，结果依赖临场发挥

本质原因是：

text 复制代码

Prompt 是一次性的
工程规范需要长期稳定

例如你希望 AI 永远记住：

项目使用 React + TypeScript + Tailwind CSS
API 请求必须放在 services
组件里不要直接写复杂业务逻辑
输出回答要简洁，优先给可执行结果

这些内容如果每次都写进 Prompt，会很低效；如果沉淀成 Rules，就会成为 AI 的默认上下文。

三、什么是 Rules？

一句话定义

Rules = 持续生效的系统级约束。

Rules 的作用不是告诉 AI "现在做哪件事"，而是告诉 AI：

text 复制代码

应该如何思考
应该遵守什么规范
应该使用什么技术栈
应该输出什么风格

如果把 AI 当成一个团队成员，Rules 就是入职手册、代码规范和架构边界。

Rules 解决什么问题？

Rules 主要解决四类问题。

1. 技术栈约束

md 复制代码

- 使用 React + TypeScript
- 使用 Vite
- 使用 Tailwind CSS

这样 AI 不会突然写 Vue、class component 或传统 CSS。

2. 代码规范

md 复制代码

- 禁止使用 any
- 一个组件一个文件
- 使用 hooks 管理组件逻辑

这样多人协作时，AI 生成的代码会更接近团队风格。

3. 架构约束

md 复制代码

- API 请求必须放在 services
- 组件中禁止直接写请求逻辑
- hooks 负责状态与副作用管理

Rules 不只是代码风格，更重要的是工程结构。

4. 输出风格

md 复制代码

- 回答保持简洁
- 优先给结论和代码
- 不要输出无关解释

这会直接影响 AI 的沟通方式和交付质量。

Rules 什么时候生效？

很多人误以为 Rules 是"调用"的，其实不是。

text 复制代码

Rules 不是一次命令
Rules 是默认上下文

Cursor 的典型执行顺序是：

flowchart TD A[用户输入 Prompt] --> B[加载匹配的 Rules] B --> C[分析任务] C --> D{是否需要 Skills} D -->|是| E[加载 Skills] D -->|否| F[直接执行] E --> G[按 Workflow 执行] F --> H[生成结果] G --> H style B fill:#e3f2fd style E fill:#fff8e1 style H fill:#e8f5e9

所以可以记住：

text 复制代码

Rules 通常先于 Skills 生效。

Rules 的三种加载方式

1. `alwaysApply`

适合核心规范，例如基础技术栈、交付标准、通用代码风格。

yaml 复制代码

alwaysApply: true

特点：

每次任务都会加载
稳定性最高
适合少量、高价值、长期不变的规则

2. `globs`

适合只在特定目录生效的规则。

yaml 复制代码

globs:
  - src/components/**

特点：

按路径匹配
更节省上下文
适合组件、接口、测试等局部规范

3. `Agent Requested`

适合较大或低频的规则，例如迁移指南、安全审计流程、发布检查清单。

特点：

按需加载
不长期占用上下文
适合特殊场景

Rules 推荐结构

bash 复制代码

.cursor/
  rules/
    base.mdc
    react.mdc
    architecture.mdc
    api.mdc
    testing.mdc

不要把所有内容都塞进一个巨大文件。更推荐：

text 复制代码

按职责拆分
按场景加载
每条规则尽量短而明确

一个基础 Rules 示例：

md 复制代码

---
description: 基础工程规范
alwaysApply: true
---

# 基础规则

## 技术栈

- 所有代码必须使用 TypeScript
- React 组件使用函数组件
- 样式优先使用 Tailwind CSS

## 代码质量

- 避免使用 any
- 优先保证可读性
- 异步逻辑必须处理错误

## 架构边界

- API 请求放在 services
- 可复用状态逻辑放在 hooks
- UI 组件避免直接承载复杂业务流程

四、什么是 Skills？

一句话定义

Skills = AI 的可复用任务执行流程。

如果说：

text 复制代码

Rules 决定 AI 怎么思考

那么：

text 复制代码

Skills 决定 AI 怎么做事

Skills 适合封装高频、可复用、有明确步骤的任务，例如：

创建组件
创建 Hook
接入 API
修复测试
重构模块
生成文档
准备 PR

Skills 的特点

特点	描述
按需加载	不会一直存在，只在匹配任务时加载
面向任务	关注具体目标，而不是全局规范
可复用	一次编写，多次执行
多步骤	可以定义完整 workflow

Skills 什么时候触发？

当你输入：

text 复制代码

帮我创建一个 UserCard 组件。

Cursor 会大致经历：

text 复制代码

分析任务
→ 判断是否匹配 Skill
→ 加载对应 SKILL.md
→ 按 workflow 执行
→ 输出结果

一个简单 Skill 示例：

md 复制代码

# create-react-component

## 目标

创建符合项目规范的 React 组件。

## 步骤

1. 确认组件名称和使用场景
2. 创建组件文件
3. 定义 Props 类型
4. 使用函数组件实现结构
5. 添加 Tailwind 样式
6. 导出组件
7. 给出 usage 示例

推荐目录结构：

bash 复制代码

.cursor/
  skills/
    create-component/
      SKILL.md
    create-hook/
      SKILL.md
    write-api/
      SKILL.md
    refactor-module/
      SKILL.md

五、Rules 和 Skills 的核心区别

最容易混淆的点是：Rules 和 Skills 都能影响 AI，但影响的位置不同。

维度	Rules	Skills
本质	行为约束	执行流程
是否常驻	通常持续生效	按需加载
关注点	规范、边界、风格、架构	任务、步骤、产物
使用场景	技术栈、目录规范、输出要求	创建、重构、修复、生成
类比	ESLint / 团队规范	SOP / 自动化脚本

可以用一句话记：

text 复制代码

Rules 管"不能偏离什么"
Skills 管"应该怎么完成任务"

六、两者如何协作？

一个真实场景：

text 复制代码

用户：Create a user card component

此时 Rules 和 Skills 会分别提供不同能力。

Rules 提供约束

md 复制代码

- 使用 TypeScript
- 使用 React hooks
- 使用 Tailwind CSS
- 组件放在 components 目录

Skill 提供流程

md 复制代码

1. 创建组件文件
2. 定义 Props
3. 实现组件结构
4. 添加样式
5. 导出组件
6. 给出示例

最终效果

AI 不只是"写一个组件"，而是按照项目规范写一个符合团队预期的组件。

sequenceDiagram participant User participant Cursor participant Rules participant Skills participant AI User->>Cursor: Create a user card component Cursor->>Rules: 加载项目约束 Rules-->>Cursor: React + TS + Tailwind + 架构规范 Cursor->>Skills: 匹配 create-component Skills-->>Cursor: 返回组件创建流程 Cursor->>AI: 组合上下文并执行 AI-->>User: 输出符合规范的组件代码

示例结果：

tsx 复制代码

type UserCardProps = {
  name: string;
  avatar: string;
};

export function UserCard({ name, avatar }: UserCardProps) {
  return (
    <div className="flex items-center gap-3 rounded border p-4">
      <img src={avatar} alt={name} className="h-10 w-10 rounded-full" />
      <span className="font-medium">{name}</span>
    </div>
  );
}

其中：

能力	来源
TypeScript	Rules
Tailwind CSS	Rules
函数组件	Rules
创建步骤	Skill

七、项目级落地模板

一个完整的工程化配置可以长这样：

flowchart TD A[.cursor] --> B[rules] A --> C[skills] B --> D[base.mdc] B --> E[react.mdc] B --> F[architecture.mdc] B --> G[api.mdc] B --> H[testing.mdc] C --> I[create-component] C --> J[create-hook] C --> K[write-api] C --> L[refactor-module] style B fill:#e3f2fd style C fill:#fff8e1

推荐从小开始，不要一上来追求大而全：

text 复制代码

第 1 步：先写 base.mdc，沉淀最核心规范
第 2 步：按目录拆分 react / api / testing 等规则
第 3 步：把最高频的任务做成 Skills
第 4 步：在真实任务中持续修正规则和流程

Rules 模板

md 复制代码

---
description: React 项目规范
alwaysApply: true
---

# React 项目规范

## 技术栈

- 使用 React + TypeScript
- 使用函数组件
- 使用 Tailwind CSS

## 组件规范

- 组件 Props 必须显式定义类型
- 组件文件名使用 PascalCase
- 复杂状态逻辑抽到 hooks

## 目录边界

- UI 组件放在 components
- API 请求放在 services
- 页面级组合逻辑放在 pages 或 app 目录

Skill 模板

md 复制代码

# create-component

## 目标

创建一个符合当前项目规范的 React 组件。

## 触发场景

当用户要求创建组件、补充 UI 组件或抽离可复用组件时使用。

## 执行步骤

1. 确认组件名称、Props 和使用位置
2. 查找项目里已有组件写法
3. 创建组件文件
4. 使用 TypeScript 定义 Props
5. 按项目样式方案实现 UI
6. 导出组件
7. 必要时补充测试或使用示例

八、常见误区

误区 1：把流程写进 Rules

错误示例：

md 复制代码

1. 创建组件文件
2. 定义 Props
3. 导出组件

这是 Skill 的职责。Rules 应该写"长期约束"，不是任务步骤。

误区 2：把规范写进 Skills

错误示例：

md 复制代码

所有组件都必须使用 TypeScript。

这是 Rules 的职责。Skills 应该专注"如何完成某类任务"。

误区 3：Rules 写得太多

Rules 不是越多越好。过长的规则会带来：

上下文占用变高
重点不清晰
AI 更容易忽略真正重要的约束

更好的写法是：

text 复制代码

少而关键
职责清晰
按路径或场景拆分

误区 4：Skills 过度抽象

不是所有任务都需要 Skill。只有当某类任务高频、步骤稳定、多人都需要复用时，才值得沉淀。

九、AI Agent 进阶：Agent / MCP / SubAgent

理解 Rules 与 Skills 之后，本章把「谁在决策、怎么接外部世界、大任务怎么拆」放在一条线上读。

text 复制代码

Agent：理解需求、做决策、组织步骤
MCP：连接工具、系统与数据
SubAgent：把复杂任务拆出去并行处理

本章节次说明 ：正文只用到两级标题------大节为「## 九」、小节连续编号为「### （一）」...「### （十）」。下面代码示例里的 ### Goal 等，是 Markdown 代码围栏里的示意内容，不是本文大纲层级。

（一）Agent：会执行任务的智能体

Agent 不是单纯聊天模型，而是能持续推进任务的执行单元。它通常具备：

任务理解：把一句需求拆成可执行步骤
工具调用：读文件、改代码、跑命令、查文档
状态管理：在一次任务里持续推进
自我纠错：执行失败后尝试替代路径

一句话理解：

Agent = 会思考、会动手、会持续推进的 AI 执行单元。

（二）MCP：标准化工具接口

MCP（Model Context Protocol）可以理解为 AI 与外部系统之间的标准化连接方式。

它解决的问题是：

AI 如何安全访问本地文件？
AI 如何调用浏览器、Figma、GitHub、数据库？
不同工具如何用同一种协议接入？

text 复制代码

没有 MCP：AI 只能建议你做什么
有了 MCP：AI 可以直接帮你做什么

（三）SubAgent：什么时候值得用

SubAgent 是主 Agent 派出去的任务分身，适合：

搜索范围很大
任务可以并行推进
某个子任务需要独立上下文
主任务容易被大量探索信息污染

（四）和 Rules、Skills 放在一句话里

text 复制代码

Rules：约束 AI（边界与规范）
Skills：提供能力（可复用流程）
Agent：主执行者（本轮怎么推进）
SubAgent：子任务（并行或隔离上下文）
MCP：外部通道（事实与动作）

（五）整体执行流程

flowchart TD A[用户任务] --> B[Agent] B --> C[加载 Rules] C --> D[分析任务] D --> E{是否需要 Skills} E -->|简单任务| F[直接生成] E -->|复杂任务| G[拆分 SubAgent] G --> H[SubAgent 执行] H --> I[调用 Skills] F --> K{是否需要外部系统} I --> K K -->|是| L[MCP Tools / Resources] K -->|否| M[仅用对话上下文] L --> N[生成结果] M --> N style B fill:#e3f2fd style C fill:#e8f5e9 style G fill:#f3e5f5 style I fill:#fff8e1 style L fill:#fce4ec

（六）职责关系

flowchart LR A[Rules\n规范约束] B[Skills\n能力模块] C[Agent\n主执行者] D[SubAgent\n子执行者] E[MCP\n外部工具与资源] A --> C B --> C E --> C C --> D D --> B D --> E

（七）示例：用户列表页（端到端）

用户输入：

text 复制代码

帮我实现一个用户列表页面（包含接口 + UI + loading）

sequenceDiagram participant User participant Agent participant Rules participant Skills participant SubAgent participant MCP User->>Agent: 用户需求 Agent->>Rules: 加载规则 Rules-->>Agent: TS + React + 架构 Agent->>Agent: 分析任务 Agent->>SubAgent: 拆分 UI/API/状态 SubAgent->>Skills: create-component SubAgent->>Skills: write-api SubAgent->>Skills: create-hook Skills-->>SubAgent: 返回代码 Note over Agent,MCP: 若需对齐设计稿/接口文档/浏览器验收 Agent->>MCP: 按需调用 Tools 或读取 Resources（含读 schema） MCP-->>Agent: 结构化事实与设计参考 SubAgent-->>Agent: 汇总结果 Agent-->>User: 输出页面

（八）工程结构：`.cursor` 里通常有什么

bash 复制代码

.cursor/
  rules/
    base.mdc
    react.mdc
  skills/
    create-component/
      SKILL.md
    write-api/
      SKILL.md
    create-hook/
      SKILL.md
  agents/
    main-agent.md
    ui-subagent.md
    api-subagent.md

（九）配置片段：Rules + Skills

下面用 文件名加粗 标注，不再套一层 #### 标题。

base.mdc（Rules）

md 复制代码

---
alwaysApply: true
---

- 使用 TypeScript
- 禁止 any
- 保持代码简洁

react.mdc（Rules）

md 复制代码

---
alwaysApply: true
---

- 使用函数组件
- 使用 hooks
- 使用 Tailwind

create-component（Skill，示意）

md 复制代码

# create-component

1. 定义 Props
2. 创建组件
3. 添加样式
4. 导出

write-api（Skill，示意）

md 复制代码

# write-api

1. 定义类型
2. 创建请求
3. 处理错误

create-hook（Skill，示意）

md 复制代码

# create-hook

1. 管理状态
2. 调用 API
3. 处理 loading
4. 返回数据

（十）主 Agent 与子 Agent：怎么写、何时拆

主 Agent（main-agent） 负责分析、判断是否拆分、最后汇总：

md 复制代码

# main-agent

1. 分析任务
2. 拆分 UI / API / 状态
3. 调用 SubAgent
4. 汇总结果

子 Agent 与 Skills 的对应（最小示意）：

md 复制代码

# ui-subagent

使用 create-component

md 复制代码

# api-subagent

使用 write-api

md 复制代码

# state-subagent

使用 create-hook

子 Agent 是什么：不是产品里自带的开关，而是仓库里写清的「专职说明」。常见目录：

bash 复制代码

.cursor/agents/
  ui-subagent.md
  api-subagent.md
  state-subagent.md

三个稍完整的示例（代码块里的 ### Goal 是示例文档结构，不是本章标题）：

md 复制代码

# ui-subagent

### Goal

负责 UI 组件生成

### Input

- 页面结构描述

### Use Skills

- create-component

### Output

- React 组件代码

md 复制代码

# api-subagent

### Goal

负责 API 层

### Use Skills

- write-api

### Output

- 请求函数

md 复制代码

# state-subagent

### Goal

负责状态管理

### Use Skills

- create-hook

### Output

- 自定义 Hook

什么时候拆子 Agent：只有复杂到「多线并行、上下文容易糊在一起」才值得；改一个函数、修单个 bug、动一个组件，通常单 Agent + 对应 Skill 就够。

谁在发起拆分 ：在 主 Agent 里分支------简单任务直接走 Skills，复杂任务再点名子 Agent，例如：

md 复制代码

# main-agent

### Goal

构建用户列表模块

### Steps

1. 分析任务
2. 判断复杂度

3. 如果是简单任务：
   - 直接调用 Skills

4. 如果是复杂任务：
   - 拆分 SubAgent：
     - UI → ui-subagent
     - API → api-subagent
     - State → state-subagent

5. 汇总结果

复杂度分支（流程图）

flowchart TD A[用户任务] --> B[Agent] B --> C{任务复杂度判断} C -->|简单| D[直接调用 Skills] C -->|复杂| E[拆分 SubAgent] E --> F[ui-subagent] E --> G[api-subagent] E --> H[state-subagent] F --> I[调用 create-component] G --> J[调用 write-api] H --> K[调用 create-hook] I --> L[返回 UI] J --> L K --> L L --> M[Agent 汇总输出] style B fill:#e3f2fd style E fill:#f3e5f5 style L fill:#e8f5e9

调用链

text 复制代码

用户需求
  ↓
Agent（判断复杂度）
  ↓
SubAgent（拆分任务）
  ↓
Skills（执行能力）
  ↓
代码输出

串起来：同一需求再跑一遍步骤

用户说「实现用户列表页面」时，典型过程可以是：主 Agent 判断为复杂任务 → 拆成 ui / api / state → 分别走 create-component、write-api、create-hook → 主 Agent 合并页面、接口与 Hook。

text 复制代码

1. Agent 判断：复杂任务
2. 拆分：UI → ui-subagent，API → api-subagent，State → state-subagent
3. SubAgent 调用 Skills：create-component / write-api / create-hook
4. 汇总：页面 + 接口 + hook

一句话

text 复制代码

子 Agent = 专职说明；主 Agent = 拆解与分配，最后汇总交付。

十、最后总结

可以用这四句话收尾：

text 复制代码

Prompt 让 AI 知道这次要做什么
Rules 让 AI 知道长期不能偏离什么
Skills 让 AI 知道任务应该怎么做
MCP 和 SubAgent 让 AI 具备更强的执行与协作能力

如果只用 Prompt，你是在临时对话 AI。

如果使用 Rules，你是在约束 AI。

如果使用 Skills，你是在训练 AI 做高频任务。

当 Rules、Skills、MCP 和 SubAgent 组合起来，AI 才真正从"回答问题的工具"，变成"可协作、可复用、可交付的工程化系统"。

十一、开源参考仓库

如果想继续学习 Rules 和 Skills 的真实写法，可以参考下面这些 GitHub 开源仓库。建议重点看它们的目录组织、触发场景、规则颗粒度和 workflow 写法，不要直接整包复制到自己的项目里。

Skills 参考

addyosmani/agent-skills：比较系统的 Agent Skills 示例集合，适合理解如何把复杂任务拆成可复用的 SKILL.md。
spencerpauly/awesome-cursor-skills：Cursor Skills 资源合集，包含视觉测试、性能分析、并行探索、测试迭代等场景。
gardusig/cursor-skills：偏工作流型 Skills，适合参考 Git、PR、研究类任务如何沉淀成可复用流程。

Rules 参考

beettlle/CursorRules：较完整的 Cursor Rules 集合，覆盖语言规范、安全、反模式和审计流程。
zackiles/cursor-config：面向 Agent 模式的 Cursor 配置与 Rules 示例，适合参考全局规则和本地规则的拆分方式。
SeanLF/cursor-rules：偏工程判断和生产质量的 Rules 示例，适合理解如何把高级工程原则写成 AI 可执行的约束。

从 Prompt 到 AI 工程化：理解 Rules、Skills 与 Agent

什么是 Skills，什么是 Rules？

一、先建立整体认知

二、为什么 Prompt 不够用了？

三、什么是 Rules？

一句话定义

Rules 解决什么问题？

1. 技术栈约束

2. 代码规范

3. 架构约束

4. 输出风格

Rules 什么时候生效？

Rules 的三种加载方式

1. alwaysApply

2. globs

3. Agent Requested

Rules 推荐结构

四、什么是 Skills？

一句话定义

Skills 的特点

Skills 什么时候触发？

五、Rules 和 Skills 的核心区别

六、两者如何协作？

Rules 提供约束

Skill 提供流程

最终效果

七、项目级落地模板

Rules 模板

Skill 模板

八、常见误区

误区 1：把流程写进 Rules

误区 2：把规范写进 Skills

误区 3：Rules 写得太多

误区 4：Skills 过度抽象

九、AI Agent 进阶：Agent / MCP / SubAgent

（一）Agent：会执行任务的智能体

（二）MCP：标准化工具接口

（三）SubAgent：什么时候值得用

（四）和 Rules、Skills 放在一句话里

（五）整体执行流程

（六）职责关系

（七）示例：用户列表页（端到端）

（八）工程结构：.cursor 里通常有什么

（九）配置片段：Rules + Skills

（十）主 Agent 与子 Agent：怎么写、何时拆

十、最后总结

十一、开源参考仓库

Skills 参考

Rules 参考

1. `alwaysApply`

2. `globs`

3. `Agent Requested`

（八）工程结构：`.cursor` 里通常有什么