工作流的核心是三个层次的配置：Rules（行为约束）、MCP（外部能力扩展）和 Skills（复杂流程封装）。它们层层递进，从"告诉 AI 怎么写代码"到"告诉 AI 怎么做事"。
Rules 是最基础的一层，本质是写进系统提示里的约束条件。没有 Rules 之前，每次都要反复叮嘱 AI "用 ProTable 不要用 Table"、"弹窗单独封装"，很烦。
Rules 分两个层级：
| 类型 | 配置位置 | 作用范围 |
|---|---|---|
| 全局 Rules | Cursor Settings > User Rules | 所有项目通用 |
| 项目 Rules | .cursor/rules/*.md | 当前项目，可随代码库共享 |
全局 Rules 最重要的是 RIPER-5 协议（Research → Innovate → Plan → Execute → Review），它定义了 AI 处理任务的标准流程：
Research（研究） — 读代码、理解现状，不做任何建议
↓
Innovate（创新） — 头脑风暴多种方案，评估利弊
↓
Plan（计划） — 生成详尽的实施清单，精确到文件和函数
↓
Execute（执行） — 严格按清单逐步实现，不允许偏离
↓
Review（审查） — 逐行对比实现与计划，标记任何偏差
RIPER-5 解决的核心问题是 AI 过于积极地修改代码。没有这个约束，AI 经常在你只是想了解一下的时候就开始改代码，导致逻辑被破坏。五个阶段强制分离了「思考」和「动手」，每一步都有明确的允许和禁止行为。
除了 RIPER-5，全局 Rules 还包括语言设置（中文交互）、代码注释用中文、多维思维框架等跨项目通用约定。
项目级 Rules 放在 .cursor/rules/ 下，用 .md 文件编写，针对当前项目的具体约定：
---
description: 列表页面开发规范
globs: src/pages/**/*.tsx
---
- 表格组件优先使用 @ant-design/pro-components 的 ProTable
- 弹窗/抽屉组件必须单独封装，放在 components/ 子文件夹
- 列表页面拆分为 index.tsx + tableData.tsx + formData.tsx + components/
- 分页参数使用 PageIndex/PageSize，成功判断 ResponseStatus.ErrorCode === '0'
- 行操作统一使用 CommonOption 组件，操作列宽 200
通过 globs 字段可以限定规则只在匹配的文件中生效，避免规则过多导致 AI 注意力稀释。
Rules 的关键是精准而不冗长。太多规则反而会稀释优先级，AI 容易忽略。实际经验是把最常被违反的约定写进去，其余靠 Skills 和 Context 补充。
MCP（Model Context Protocol）是给 AI 接外部能力的标准协议，可以理解为 AI 的插件系统。就像 AI 应用的 USB-C 接口，提供标准化的方式连接不同数据源和工具。
MCP Hosts（Cursor）
↓
MCP Clients（内置客户端）
↓
MCP Servers（各类工具服务）
├── 文件系统读写
├── Git 操作
├── 数据库查询
└── 自定义业务 API
Cursor 中配置 MCP 在 ~/.cursor/mcp.json（全局）或项目根目录的 .cursor/mcp.json（项目级）：
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/path/to/project"
]
},
"git": {
"command": "uvx",
"args": ["mcp-server-git", "--repository", "."]
}
}
}
用了 GitLens 提供的 MCP Server（user-eamodio.gitlens-extension-GitKraken），可以让 AI 直接读取 Git 历史、Blame 信息、分支状态等。实际使用下来，在做代码 Review 或者追查 Bug 引入时间点时很好用，不用自己去翻 git log。
MCP 和 Function Calling 的主要区别是连接方式——MCP 维持持久会话，更适合需要多轮交互的工具场景。
Skills 是比 Rules 更高层的抽象，用来封装有固定步骤的复杂流程。Rules 告诉 AI 写代码的规范，Skills 告诉 AI 一个任务怎么一步步做完。
Skills 文件放在 .cursor/skills/<skill-name>/SKILL.md，格式是带 frontmatter 的 Markdown：
---
name: openspec-explore
description: 进入探索模式，作为思考伙伴帮助分析问题
---
进入探索模式。深度思考，自由发散。
**重要：探索模式只思考，不实现。**
...
Skills 的优势是流程可复用。一旦把探索→提案→实现→归档这套流程封装好，任何新功能开发都走同一套路，AI 的行为变得可预期。
Skills 分两个层级存放，作用域不同：
| 类型 | 路径 | 作用范围 |
|---|---|---|
| 全局 Skills | ~/.cursor/skills/ | 所有项目通用 |
| 项目 Skills | .cursor/skills/ | 可随代码库共享 |
全局 Skills 适合放那些和具体业务无关、各项目通用的流程，比如代码 Review、Git 提交规范、创建新 Skill 等。项目 Skills 则放和业务强绑定的流程。
目前 ~/.cursor/skills/ 下装了两个：
find-skills — 帮助发现和安装社区 Skills。当你想问"有没有能做 X 的 Skill"时自动触发，会调用 npx skills find [query] 去 skills.sh 上搜索。
vercel-react-best-practices — Vercel 官方出品的 React / Next.js 性能优化指南，涵盖 57 条规则，分 8 个优先级分类（消除瀑布流、Bundle 优化、服务端性能、重渲染优化等）。写 React 代码时自动介入，不需要手动调用。
Skills 生态在 skills.sh 上持续更新，遇到重复性高的任务先去搜一下，大概率有现成的。
这套工作流的本质是结构化上下文管理。AI 不缺能力，缺的是足够清晰的输入——Rules 给约束，MCP 给工具，Skills 给流程。三层叠加，AI 的输出质量和可预期性都明显提升。