AI提示词库：结构化规则提升AI编程助手效率与代码质量

1. 项目概述一个为开发者量身打造的AI提示词库如果你和我一样每天都在和Cursor、GitHub Copilot、Windsurf这些AI编程助手打交道那你肯定也经历过这样的时刻面对一个新项目或者一个不熟悉的框架你希望AI能更懂你的意图生成更符合团队规范的代码而不是一遍遍地手动纠正它的格式或逻辑。这时候一套精心设计的“提示词”或“规则”就成了决定效率的关键。今天要聊的instructa/ai-prompts就是一个专门为解决这个问题而生的开源项目。它不是一个简单的列表而是一个结构化、可扩展的提示词库旨在帮助开发者将最佳实践和项目规范“注入”到AI助手中让它们从一开始就走在正确的轨道上。简单来说这个项目收集、整理并标准化了适用于不同AI编程工具如Cursor Rules、GitHub Copilot、Cline、Windsurf等的提示指令。你可以把它理解为一个“AI助手调教手册”的集合。它的核心价值在于“开箱即用”和“社区驱动”。你不需要从零开始摸索如何给AI下指令而是可以直接借鉴或复用社区里经过验证的、针对特定场景如项目脚手架、代码风格、安全规范、自动化流程的优质提示词。对于任何希望提升AI辅助编程效率、统一团队代码风格、或者快速为新工具建立规范流程的开发者或团队来说这个项目都是一个极具价值的起点。2. 核心设计思路为什么我们需要一个结构化的提示词库在深入使用之前我们先拆解一下这个项目的设计哲学。为什么把提示词单独做成一个仓库而不是零散地记在笔记里这背后有几个关键的考量。2.1 解决提示词的“碎片化”与“不可复用”问题大多数开发者在初期使用AI助手时提示词都是临时、随性的。你可能在某个项目的README里写了几条给Copilot的注释在另一个项目的.cursor文件夹里放了几条规则。这些提示词分散在各个角落格式不一质量参差不齐。当启动一个新项目或者换一台电脑时这些宝贵的经验很难被系统地复用。instructa/ai-prompts通过一个中心化的仓库和统一的文件结构将提示词变成了可版本控制、可搜索、可复用的资产。这就像为你的编程经验建立了一个“知识库”而不是让它们散落在记忆的尘埃里。2.2 统一规范降低团队协作成本在团队协作中统一的代码风格和开发规范至关重要。如果每个成员给AI助手的指令都不一样生成的代码风格也会千差万别增加代码审查和维护的负担。这个项目提供的标准化提示词模板如.mdc文件格式和aiprompt.json元数据为团队定义和共享一套统一的AI协作规范提供了可能。团队可以将经过评审的提示词规则库作为子模块引入项目或者直接复制到项目模板中确保所有成员使用的AI助手都遵循同一套“宪法”从而在源头保证代码质量的一致性。2.3 适应多工具生态的兼容性设计当前的AI编程工具生态是多元化的Cursor有它的RulesGitHub Copilot有Custom InstructionsWindsurf和Cline也各有各的配置方式。手动为每个工具维护一套提示词是低效的。这个项目的聪明之处在于它虽然以Cursor Rules的.mdc格式作为主要载体之一因为其功能强大且结构化好但其内容本质是自然语言描述的最佳实践。通过简单的格式转换或路径配置同一套核心思想可以适配到不同的工具上。项目文档中提供的工具对照表正是这种兼容性思维的体现。它承认了生态的碎片化并致力于提供一种“一次编写多处适配”的解决方案思路。2.4 通过社区驱动实现持续进化AI技术和最佳实践都在快速迭代。一个人或一个团队的经验总是有限的。采用开源模式允许全球开发者贡献他们在特定领域如React性能优化、Python数据科学、Rust安全编程锤炼出的高效提示词能让这个知识库以众包的方式不断进化。你遇到的难题可能早已有其他开发者总结成了精妙的提示词规则。这种社区驱动的模式是让提示词库保持活力和前沿性的关键。注意不要把这个仓库仅仅看作是一个“文件合集”。它的深层价值在于其背后蕴含的“提示工程”思维将模糊的意图转化为清晰、结构化、可重复的指令。学习这些提示词的编写方式本身就是在提升你与AI协作的元技能。3. 项目结构深度解析与使用指南了解了为什么需要它之后我们来看看怎么用它。克隆仓库后你会发现其结构非常清晰旨在同时服务“终端使用者”和“贡献者”。3.1 仓库目录结构解读典型的instructa/ai-prompts仓库结构会类似于以下布局具体可能随版本更新ai-prompts/ ├── prompts/ # 核心提示词目录 │ ├── prompt-template/ # 贡献模板包含示例文件 │ │ ├── aiprompt.json # 提示词元数据定义文件 │ │ └── example-rule.mdc # 示例规则文件 │ ├── project-scaffolding/ # 项目脚手架类提示词 │ ├── code-style-best-practices/ # 代码风格与最佳实践 │ ├── security-compliance/ # 安全与合规检查 │ └── ... (其他分类) ├── .cursor/ # 可能包含全局Cursor规则示例 │ └── rules/ ├── .github/ # 可能包含Copilot全局指令示例 │ └── copilot-instructions.md ├── CONTRIBUTING.md # 贡献指南 └── README.md # 项目主文档prompts/目录是宝库所在。每个子目录代表一个提示词类别里面包含具体的规则文件.mdc和元数据文件aiprompt.json。这种分类方式让你能快速找到所需领域的提示例如当你需要设置一个新的React项目时直接参考project-scaffolding/react下的规则即可。aiprompt.json文件是每个提示词包的“身份证”。它通常包含以下信息{ name: React TypeScript Strict Rules, description: Enforces strict TypeScript configuration and best practices for React components., author: YourName, tags: [react, typescript, strict, components], targetAITools: [cursor, github-copilot], version: 1.0.0 }这个文件使得提示词可搜索、可分类也为未来的工具自动化集成提供了可能。.mdc文件是规则的主体。它通常采用Markdown格式并包含YAML Front Matter来定义规则的属性。例如--- name: Use Functional Components with Hooks description: Prefer React functional components and hooks over class components. scope: file language: javascript, typescript, jsx, tsx --- # 规则优先使用函数组件与Hooks 在编写React代码时应始终优先使用函数组件Functional Components和Hooks而不是传统的类组件Class Components。这符合React现代开发模式能带来更简洁的代码和更好的逻辑复用。 ## 具体要求 1. **禁止**使用class MyComponent extends React.Component语法创建新组件。 2. 使用const MyComponent (props) { ... } 或 function MyComponent(props) { ... }语法。 3. 状态管理使用useState Hook。 4. 生命周期副作用使用useEffect Hook。 5. 如果遇到类组件代码应主动建议将其重构为函数组件。 ## 示例 **不要这样写** jsx class Counter extends React.Component { constructor(props) { super(props); this.state { count: 0 }; } render() { return div{this.state.count}/div; } }应该这样写import React, { useState } from react; const Counter () { const [count, setCount] useState(0); return div{count}/div; };YAML头定义了规则的名称、描述、作用范围是整个项目、当前目录还是单个文件和适用的编程语言。正文部分则用自然语言详细阐述了规则的内容、要求和正反示例。这种结构既对人类友好也便于AI解析。 ### 3.2 如何将提示词应用到你的AI工具中 这是最关键的实操步骤。项目文档给出了主流工具的配置方法这里我结合自己的经验做一些补充和细化。 **对于Cursor用户** 这是体验最深度集成的场景。你只需要将想要的.mdc规则文件复制到你项目的.cursor/rules/目录下即可。Cursor会自动加载并应用这些规则。 1. **项目级规则**在项目根目录创建.cursor/rules/文件夹将规则文件放入。这对统一该项目所有文件的AI行为非常有效。 2. **全局规则**你还可以在用户主目录如~/.cursor/rules/下放置规则这样所有Cursor项目都会默认应用这些规则。我通常会把一些通用的代码风格规则如命名约定、注释规范放在这里。 3. **优先级**Cursor会合并所有可用的规则如果出现冲突通常更具体项目级的规则会覆盖更通用全局的规则。 **实操心得**不要一次性加载太多规则。AI助手处理大量复杂规则时性能可能会受影响也容易产生指令冲突。建议按需引入先从最核心的2-3条规则开始例如“项目语言规范”和“组件编写模式”稳定后再逐步添加。 **对于GitHub Copilot用户** Copilot通过项目根目录或用户目录下的特定文件来接收指令。 1. **项目级指令**在仓库根目录创建.github/copilot-instructions.md文件。你可以将prompts/目录下相关.mdc文件中的自然语言描述部分去掉YAML头提炼出来写入这个文件。Copilot会参考这个文件的内容来生成代码和建议。 2. **用户级指令**在VS Code中你可以通过Copilot设置配置全局的Custom Instructions。你可以将一些个人偏好的通用规则如“写清晰的注释”、“使用async/await处理异步”放在这里。 3. **局限性**Copilot的指令系统不如Cursor Rules那样具有结构化的“规则”概念它更像是一个持续的上下文提示。因此在移植规则时需要将结构化的要求转化为连贯的、描述性的段落。 **对于Windsurf和Cline用户** - **Windsurf**根据文档在项目根目录创建.windsurfrules文件并将规则内容写入。其格式可能类似Cursor的.mdc但最好参考其最新官方文档。 - **Cline**作为IDE插件它通常有一个设置界面让你输入“Custom Instructions”。你可以将精选的提示词段落复制进去。由于是全局设置这里更适合放一些与你个人编码习惯高度相关的通用原则。 **通用工作流建议** 1. **浏览与筛选**首先在instructa/ai-prompts仓库的prompts/目录中浏览找到与你技术栈如python-fastapi, react-typescript和需求如testing, security相关的分类。 2. **本地化适配**直接复制选中的.mdc文件到你的项目对应目录。**务必花几分钟时间阅读并理解规则内容**根据你项目的实际情况进行微调。例如规则里可能默认用4个空格缩进而你的项目用的是2个空格。 3. **测试与迭代**引入规则后尝试让AI助手完成一些典型任务比如生成一个新的API端点、或创建一个组件。观察输出是否符合预期。如果AI行为变得奇怪或不符合预期可能是规则之间存在冲突或表述有歧义需要你调整规则或暂时禁用某些规则。 4. **贡献反馈**如果你针对某个规则进行了有效的优化或者创建了一个新的实用规则强烈建议你按照CONTRIBUTING.md的指南向原仓库提交Pull Request。这正是开源社区的魅力所在。 ## 4. 高质量提示词规则的编写心法 使用现成的提示词库固然方便但真正的高手必须掌握自己编写和调优提示词的能力。从instructa/ai-prompts的优秀案例中我们可以总结出几条核心心法。 ### 4.1 原则一明确具体避免模糊 糟糕的提示“写出好的代码。” 优秀的提示“编写一个Python函数用于验证电子邮件地址格式。函数名为validate_email输入为一个字符串返回一个布尔值。使用正则表达式进行验证需覆盖常见格式如userexample.com并拒绝明显无效的格式如缺少‘’符号。在函数开头添加docstring说明。” 后者的指令清晰界定了任务边界、输入输出、实现方法甚至代码风格AI几乎不可能跑偏。在编写规则时要像给一位非常聪明但缺乏背景知识的新手同事写任务清单一样把隐含的前提都说明白。 ### 4.2 原则二提供正反示例 这是让AI快速理解你意图的最有效方法之一。正如前面React组件的示例所示一个“不要怎么做”和一个“应该怎么做”的对比比十句抽象的描述都管用。在规则中尽可能为关键要求配上代码示例。示例应当简洁、典型直指规则的核心。 ### 4.3 原则三定义作用范围Scope和上下文 在YAML头中正确设置scope和language至关重要。 - scope: file规则仅适用于当前编辑的文件。适合代码风格、函数编写规范等。 - scope: directory规则适用于整个目录及其子目录。适合针对/components目录的React组件规范或针对/api目录的控制器编写规范。 - scope: project规则适用于整个项目。适合项目级的设置如禁止使用某些已废弃的库、强制要求测试覆盖率等。 明确的范围可以防止规则“越界”干扰也能提升AI处理规则的效率。 ### 4.4 原则四分层与组合避免规则冲突 不要试图用一条巨长无比的规则解决所有问题。应该将规则分层 1. **基础层**通用编程原则如“使用有意义的变量名”、“函数应保持单一职责”。这些可以放在全局规则中。 2. **框架/语言层**针对特定语言或框架的规范如“Python函数和方法命名使用蛇形命名法snake_case”、“React组件使用PascalCase命名”。这些可以按技术栈分类。 3. **项目/领域层**针对当前业务逻辑的特定约定如“所有API响应必须包裹在{ data: ..., message: ... }结构中”、“用户模型字段createdAt必须为ISO时间字符串”。 当规则增多时冲突难免发生。例如一条全局规则说“优先使用const”另一条项目规则说“对于导出的模块使用export default function”。这就需要你梳理规则的优先级或者通过更精确的scope和language定义来隔离它们。在Cursor中你可以通过规则文件的命名如01_global_style.mdc, 02_project_specific.mdc来隐含地控制加载顺序但更可靠的做法是确保规则语义本身是互补而非矛盾的。 ### 4.5 原则五迭代与测试 编写提示词是一个迭代过程。写下第一条规则后立即在真实编码场景中测试。观察AI生成的代码 - 是否完全遵守了规则 - 是否有意料之外的理解偏差 - 规则是否过于严格扼杀了AI的创造性例如在某些探索性编程场景下过于严格的格式要求可能不必要 根据测试结果反复调整规则的措辞、示例和范围。把提示词工程看作是一种与AI模型的“对话调试”。 ## 5. 实战场景为Next.js全栈项目配置AI规则 让我们通过一个具体的实战案例将以上所有知识串联起来。假设我们正在启动一个使用Next.js 14App Router、TypeScript、Tailwind CSS和Prisma的全栈项目我们希望为这个项目配置一套AI助手规则。 ### 5.1 第一步规划规则集 我们不需要面面俱到先从最影响开发体验和代码质量的方面入手 1. **项目结构与约定**规范App Router下的文件布局、API路由写法。 2. **TypeScript严格模式**确保类型安全。 3. **React服务器组件与客户端组件**明确使用边界和编写模式。 4. **Tailwind CSS使用规范**类名排序、避免内联样式等。 5. **Prisma与数据库操作**查询模式、错误处理。 6. **通用代码风格**导入排序、命名约定。 ### 5.2 第二步从仓库中寻找并适配现有规则 前往instructa/ai-prompts的prompts/目录我们可能会找到 - prompts/project-scaffolding/nextjs-app-router/ - prompts/code-style-best-practices/typescript-strict/ - prompts/code-style-best-practices/react-patterns/ 我们将这些规则复制到我们项目的.cursor/rules/目录下。例如创建以下文件结构my-nextjs-project/ ├── .cursor/ │ └── rules/ │ ├── 01_project_structure.mdc │ ├── 02_typescript_strict.mdc │ ├── 03_react_components.mdc │ ├── 04_tailwind_css.mdc │ └── 05_prisma_queries.mdc └── (项目其他文件)01_project_structure.mdc的内容可能基于仓库中的模板进行修改 markdown --- name: Next.js 14 App Router Project Structure description: Enforces file and directory conventions for Next.js 14 using the App Router. scope: project --- # Next.js 14 (App Router) 项目结构规范 本项目采用Next.js 14的App Router架构。所有路由均由app/目录下的文件夹定义。 ## 核心约定 1. **页面Pages**位于app/[route]/page.tsx。每个page.tsx文件默认导出export default一个React组件作为该路由的页面。 2. **布局Layouts**位于app/[route]/layout.tsx。用于定义共享的UI结构。 3. **加载状态Loading**位于app/[route]/loading.tsx。用于定义React Suspense边界内的加载UI。 4. **错误处理Error**位于app/[route]/error.tsx。用于定义错误边界。 5. **API路由**位于app/api/[endpoint]/route.ts。实现服务器端API处理程序应使用GET、POST等命名导出函数。 6. **服务器操作Server Actions**鼓励在app/actions/目录下集中定义或在相关组件同目录下的actions.ts文件中定义使用‘use server’指令。 ## 示例创建用户详情页 **正确路径**app/users/[id]/page.tsx **正确内容** tsx // app/users/[id]/page.tsx import { getUserById } from /lib/data; interface UserPageProps { params: Promise{ id: string }; } export default async function UserPage({ params }: UserPageProps) { const { id } await params; const user await getUserById(id); if (!user) { return divUser not found/div; } return ( div classNamecontainer mx-auto p-4 h1 classNametext-2xl font-bold{user.name}/h1 pEmail: {user.email}/p /div ); }### 5.3 第三步编写自定义规则以Prisma为例 仓库里可能没有完全符合我们Prisma使用习惯的规则这就需要我们自己编写05_prisma_queries.mdc。 markdown --- name: Prisma ORM Safe Query Patterns description: Enforces safe and efficient database query patterns using Prisma in a Next.js environment. scope: file language: typescript --- # Prisma安全查询模式 本规则旨在防止常见的Prisma使用错误并推广性能最佳实践。 ## 规则详情 1. **始终使用try...catch包装数据库操作**并进行适当的错误处理和日志记录。 2. **避免在循环中进行查询**N1问题。优先使用include、select或findUnique/findMany的where条件进行关联查询。 3. **对于列表查询务必使用分页**skip和take除非明确知道结果集很小。 4. **在Server Components或API Route中获取数据**不要在前端组件中直接导入Prisma客户端进行查询。 5. **使用select明确指定返回字段**避免查询不必要的数据。 6. 在where条件中使用参数时确保参数已进行验证或转义防止潜在的注入攻击尽管Prisma已提供参数化查询保护。 ## 示例 **不要这样写N1问题** typescript // 错误示例在循环中查询 const users await prisma.user.findMany(); for (const user of users) { const posts await prisma.post.findMany({ where: { authorId: user.id }, // 每次循环都发起一次查询 }); console.log(user.name, posts.length); }应该这样写使用include// 正确示例一次性关联查询 const usersWithPosts await prisma.user.findMany({ include: { posts: true, // 通过一次查询获取所有用户及其文章 }, take: 20, // 分页 skip: 0, }); for (const user of usersWithPosts) { console.log(user.name, user.posts.length); }API路由中的安全查询示例// app/api/users/route.ts import { NextRequest, NextResponse } from next/server; import prisma from /lib/prisma; // 假设已配置好单例Prisma客户端 export async function GET(request: NextRequest) { const searchParams request.nextUrl.searchParams; const page parseInt(searchParams.get(page) || 1); const limit parseInt(searchParams.get(limit) || 10); try { const users await prisma.user.findMany({ select: { id: true, name: true, email: true }, // 明确选择字段 take: limit, skip: (page - 1) * limit, orderBy: { createdAt: desc }, }); return NextResponse.json({ data: users, page, limit }); } catch (error) { console.error(Failed to fetch users:, error); return NextResponse.json( { error: Internal Server Error }, { status: 500 } ); } }### 5.4 第四步测试与调优 规则配置好后开始实际开发。当你让Cursor或Copilot生成一个API路由时观察它是否遵循了route.ts的命名和结构当你让它写一个数据获取函数时检查是否包含了try...catch和分页逻辑。如果发现AI在某些地方“不听话”回去检查对应的规则文件看描述是否足够清晰示例是否具有代表性然后进行微调。 ## 6. 常见问题与排查技巧实录 在实际使用过程中你可能会遇到一些典型问题。以下是我和社区成员遇到过的一些情况及其解决方案。 ### 6.1 问题一AI助手似乎完全忽略了规则 **症状**在Cursor中创建了.cursor/rules/目录并添加了规则文件但AI生成代码时仿佛没看到这些规则。 **排查步骤** 1. **检查规则文件路径和格式**确保规则文件直接放在.cursor/rules/下而不是子目录里除非你配置了递归读取。确保文件扩展名是.mdc或.md并且YAML Front Matter格式正确三个短横线---不能少。 2. **检查Cursor版本**确保你使用的是支持Project Rules功能的Cursor版本通常是v0.45及以上。在Cursor设置中查看“Features”或“About”确认。 3. **重启Cursor/重新加载项目**有时规则加载需要触发项目重新加载。尝试关闭当前项目窗口再重新打开或者在命令面板Cmd/Ctrl Shift P中执行“Cursor: Reload Window”。 4. **查看规则是否被激活**在Cursor编辑器中右下角或状态栏通常会有一个图标如一本书或一个徽章点击它可以查看当前激活的规则列表。确认你的规则在其中。 5. **简化测试**创建一个最简单的规则进行测试例如一条强制要求“在所有JavaScript文件开头添加// This file is governed by AI rules注释”的规则看是否生效。 ### 6.2 问题二规则之间发生冲突导致AI行为混乱 **症状**AI生成的代码逻辑矛盾或者在不同文件中表现不一致。 **排查与解决** 1. **审查规则作用域Scope**冲突常源于scope定义重叠。确保项目级scope: project的通用规则不要与文件级scope: file的特殊规则在细节上冲突。例如项目级规则要求“所有组件用.tsx扩展名”但某个文件级规则针对一个纯类型定义文件要求“使用.ts”。这时需要调整规则或使用更精确的language和文件路径globs来限定范围。 2. **检查规则优先级**虽然Cursor官方文档可能没有明确说明但根据经验同目录下按文件名排序可能影响加载顺序。你可以通过给文件添加数字前缀如01_, 02_来手动控制顺序并确保更具体的规则排在后面或具有更高的优先级逻辑。 3. **合并或拆分规则**如果两条规则总是同时出现且目标一致考虑将它们合并成一条更全面的规则。如果一条规则过于复杂包含了可能产生内部矛盾的多条指令考虑将其拆分成多条单一职责的规则。 4. **使用更精确的语言描述**冲突有时源于模糊性。将“优先使用函数式编程”改为更具体的“在操作数组时优先使用map、filter、reduce而非for循环”可以避免与其他规则比如关于循环性能的规则产生歧义。 ### 6.3 问题三规则导致AI生成了低质量或过于冗长的代码 **症状**AI为了严格遵守某条规则如“必须添加详细错误处理”在每个简单函数里都生成了大段的try...catch和日志代码显得画蛇添足。 **解决方案** 1. **为规则增加例外条件**在规则描述中明确说明例外情况。例如“对于简单的工具函数如纯计算函数无I/O操作可以省略复杂的错误处理但需在函数注释中说明其稳定性。” 2. **调整规则的严格程度**有些规则应该是“建议”而非“强制”。在YAML头或描述中可以使用“建议”、“优先考虑”等词语而不是“必须”、“禁止”。给AI留出一定的判断空间。 3. **提供更优质的示例**在正反示例中不仅要展示“应该怎么做”也要展示在简单场景下“可以接受的简化做法是什么”。这能教会AI在复杂度和实用性之间取得平衡。 ### 6.4 问题四如何管理大量规则避免性能下降 **症状**随着项目规则文件越来越多超过20个感觉AI响应速度变慢或者偶尔会“忘记”某些规则。 **最佳实践** 1. **按需加载项目化组织**不要把所有规则都塞进全局配置。将与具体项目强相关的规则如项目特定的API响应格式放在项目本地.cursor/rules/目录下。将真正通用的个人偏好如代码格式化风格放在全局规则目录。 2. **定期清理和合并**定期回顾规则库合并内容相近的规则删除那些已经不再使用或已被更好规则替代的旧规则。 3. **关注规则文件的复杂度**单个规则文件不宜过长。如果一条规则描述超过200行考虑是否可拆分为几个更专注的子规则。过长的提示词可能会占用过多的上下文窗口影响AI对其他上下文如当前编辑的代码的关注。 4. **利用.cursorignore文件**在项目根目录创建.cursorignore文件类似于.gitignore可以指定某些文件或目录不被Cursor的规则引擎分析这能在某些情况下提升性能。 ### 6.5 问题五在不同AI工具间同步规则太麻烦 **症状**在Cursor上精心调教了一套规则切换到VS CodeGitHub Copilot或Windsurf时又得重新配置。 **当前局限与应对策略** 目前还没有一个完美的、一键同步所有工具的解决方案因为各工具的配置机制不同。但可以建立一个高效的“规则源”工作流 1. **以Cursor Rules.mdc为“源格式”**由于.mdc格式结构清晰适合作为主版本。在instructa/ai-prompts这样的仓库中维护你的核心规则库。 2. **创建转换脚本或文档**为你使用的其他工具如Copilot编写一个简单的脚本或维护一个文档说明如何将.mdc文件中的核心自然语言描述提取并格式化到对应的配置文件中如.github/copilot-instructions.md。这可以是一个手动过程但至少保证了规则内容的一致性。 3. **探索工具原生导入功能**关注你所用工具的发展。未来可能会有工具支持直接导入.mdc或某种通用提示词格式。 ## 7. 进阶技巧让AI提示词发挥更大威力 掌握了基础用法和问题排查后我们可以探索一些更高级的技巧让AI助手真正成为你的“结对编程”专家。 ### 7.1 利用上下文变量和动态规则 一些高级的AI编程工具如Cursor Rules的某些版本支持在规则中使用简单的变量或上下文感知。例如你可以编写一条规则其内容根据当前文件类型动态变化。 虽然标准的.mdc格式可能不支持复杂逻辑但你可以通过创建多个规则文件并利用scope和language来实现类似效果。例如 - rules_for_typescript.mdc (language: typescript) - rules_for_python_tests.mdc (language: python, 且路径包含/tests/) 更进阶的做法是编写一些小的脚本根据项目配置文件如package.json中的dependencies自动生成或启用特定的规则集。例如如果检测到项目使用了Jest则自动启用一套Jest测试最佳实践的规则。 ### 7.2 编写“元规则”教AI如何学习你的代码库 除了具体的编码规则你可以创建一条“元规则”用来指导AI如何理解和利用你项目的独特上下文。这条规则可以放在所有规则的最前面。 markdown --- name: Project Context Primer description: Provides high-level context about this project to guide all subsequent AI assistance. scope: project --- # 项目上下文总览 你正在协助开发一个名为“TaskFlow”的在线任务管理应用。以下是关键背景信息请在所有代码生成和修改建议中充分考虑 1. **技术栈**Next.js 14 (App Router), React, TypeScript, Tailwind CSS, Prisma (PostgreSQL), NextAuth.js。 2. **核心业务概念** - Workspace: 用户所属的工作区包含多个Project。 - Project: 属于一个Workspace包含多个Task。 - Task: 属于一个Project有标题、描述、状态(TODO, IN_PROGRESS, DONE)、负责人(assignedTo)等字段。 3. **架构模式** - 数据获取在Server Components中使用async/await直接调用Prisma或在Client Components中使用TanStack Query (React Query)。 - API设计遵循RESTful风格端点位于/api/下返回标准化的{ success: boolean, data?: any, error?: string }格式。 4. **代码风格** - 函数和变量使用驼峰命名法。 - 组件使用PascalCase。 - 使用ESLint和Prettier进行代码检查和格式化配置已存在于项目中。 在生成任何代码前请先思考是否符合上述项目背景和约定。如果遇到不确定的地方可以提问澄清。这条“元规则”为AI建立了一个强大的心智模型让它生成的代码更能贴合项目的整体架构和业务逻辑而不仅仅是语法正确。7.3 将规则与自动化工作流结合AI提示词不仅可以用于生成代码还可以用于驱动自动化任务。例如你可以创建一条规则当AI检测到你在创建一个新的Next.js API路由时自动建议你运行一个脚本来生成对应的Prisma模型、OpenAPI文档片段和基础测试文件。 虽然这需要更复杂的工具链支持如自定义的Cursor命令或CLI工具但思路是将规则作为触发点连接到你已有的项目自动化脚本上从而实现“提示即命令”的高效工作流。经过这样一番从理论到实践从使用到创作的深度探索instructa/ai-prompts项目就不再只是一个简单的文件合集而是一套关于如何与AI协同编程的方法论和工具箱。它降低了高效使用AI助手的门槛但它的真正价值在于激发你去思考和实践如何将人类的最佳实践清晰、系统、可重复地“传授”给AI伙伴。