Skip to Content
工程化实践3. 制定 Cursor Rules生成 Rules 的元提示词

生成 Rules 的元提示词

用 AI 来帮你写 AI 的规则

什么是元提示词

当你面对一个新项目或新技术栈时，从零开始编写 Cursor Rules 可能会让人无从下手。元提示词（Meta Prompt） 本质上是”用来生成提示词的提示词”——你告诉 AI 你的项目情况，AI 帮你生成适合的 Cursor Rules。

元提示词可以帮你快速生成规则框架、确保规则覆盖关键领域、保持格式一致性。但它只是起点，真正有效的规则来自实际开发中的持续迭代。

完整示例

我们已经为常见技术栈准备了完整的规则提取模板和示例：

这些示例包含了从项目中提取规范的完整提示词模板，可以直接使用或根据你的技术栈调整。

快速开始：三步生成规则

步骤 1：准备项目信息

收集项目的关键信息：

# 获取目录结构
tree src -L 2 -I 'node_modules|dist'

步骤 2：选择并填充模板

根据你的技术栈，从上述示例中选择合适的提取模板，或使用下面的通用模板：

# 任务
为我的项目生成 Cursor Rules 规则文件。
 
# 项目信息
- 技术栈：[列出你的技术栈，如 React, TypeScript, Tailwind CSS]
- 框架：[列出主要框架，如 Vite, Next.js, Spring Boot]
- 项目类型：[如 Web 应用、管理后台、REST API]
 
# 目录结构
[粘贴你的项目目录结构]
 
# 规则要求
1. 生成 global-rules.mdc：包含技术栈、目录结构、语言规范、导入约定
2. 针对主要功能模块生成专门的规则文件（如路由、UI、API、测试等）
3. 只写项目中真实存在且被反复强制使用的规范，不要写大模型常识
4. 每条规则必须具体、可执行，避免泛泛描述
5. 仅在必要时附上代码示例（3~10 行）
6. 使用合适的 globs 和 alwaysApply 配置
 
# 输出格式
为每个规则文件输出完整内容，使用 .mdc 格式，包含 frontmatter。

步骤 3：迭代优化

AI 生成的规则需要验证和改进：

  1. 审查 - 检查规则是否符合项目实际情况
  2. 补充 - 添加 AI 遗漏的项目特定规范
  3. 测试 - 让 AI 基于规则生成代码，验证效果
  4. 调整 - 根据测试结果优化规则

针对特定模块的提示词

有时你只需要为特定模块生成或更新规则：

生成 API 规则

分析我的 API 客户端代码，生成 api-rules.mdc：
 
1. 识别 HTTP 客户端的使用模式
2. 总结数据获取的标准流程（如 SWR、React Query）
3. 提取错误处理的统一方式
4. 包含完整的代码示例
 
参考代码：
[粘贴你的 API 客户端代码]

生成 UI 规则

基于我使用的 UI 组件库，生成 ui-rules.mdc：
 
1. 定义基础组件的使用规范
2. 指定图标库和用法
3. 规范通知/Toast 的使用方式
4. 列出需要避免的组件或模式
 
UI 库：[Shadcn/UI / Ant Design / Material UI]
图标库：[Lucide / Iconify]
通知库：[Sonner / React Hot Toast]

生成测试规则

为我的项目生成 testing-rules.mdc：
 
1. 测试框架：[Vitest / Jest / JUnit]
2. 测试文件位置和命名规范
3. 测试的标准结构
4. Mock 的使用规范
5. 测试覆盖率要求

规则质量检查清单

生成规则后，使用以下清单验证质量：

检查项标准
具体性每条规则是否可直接执行？
必要性是否删除了 AI 已知的常识？
示例性关键规则是否有代码示例？
路径性import 路径是否准确？
作用域globs 配置是否正确？

避免写”组件应该职责单一”、“使用 ESLint”、“函数命名要语义化”这类大模型已知的常识。只写项目独有的、AI 无法推断的规范。

参考资源

下一步

完成 Rules 的编写后，接下来我们将进入第四章：规范工作流，学习如何将这些规则融入日常开发流程。

最后更新于:
使用 Rules 管理记忆简介