1. 项目概述：一个面向开发者的提示词仓库
如果你是一名开发者，尤其是最近在尝试使用像 Cursor、Windsurf、DeepSeek Coder 这类 AI 编程助手，那你肯定对“提示词”这个词不陌生。简单来说，提示词就是你与 AI 对话的“指令”，指令的质量直接决定了 AI 输出的质量。好的提示词能让 AI 成为你的得力副驾，精准理解需求，生成高质量的代码、文档或解决方案；而模糊的提示词，则可能让你陷入“鸡同鸭讲”的循环，浪费大量时间。
今天要聊的这个项目，KingLeoJr/prompts，就是一个专门为开发者收集、整理和分享高质量提示词的 GitHub 仓库。它不是一个工具，而是一个“弹药库”。当你面对一个棘手的编程任务，比如重构一段遗留代码、为一个新项目搭建脚手架、或者调试一个诡异的 Bug 时，与其自己绞尽脑汁构思如何向 AI 提问，不如直接来这里寻找经过验证的“战术指令”。这个仓库汇集了针对不同场景、不同 AI 工具（如 aider, Cursor, DeepSeek 等）的提示词模板，旨在将提示词工程的经验沉淀下来，让每个开发者都能快速复用最佳实践，提升与 AI 协作的效率和产出质量。
无论你是刚接触 AI 编程的新手，还是已经深度使用并希望优化工作流的老手，这个仓库都能提供实实在在的价值。对于新手，它提供了“开箱即用”的模板，降低了学习成本；对于老手，它则是一个灵感和方案的集散地，你可以从中借鉴思路，甚至贡献自己的“独门秘籍”。
2. 核心思路与设计哲学
2.1 为什么需要专门的提示词仓库？
在 AI 编程的早期，大家往往是即兴发挥。需要写个函数，就对 AI 说“写一个 Python 函数，计算两个数的最大公约数”。但随着任务复杂度的提升，比如“为我的 Next.js 项目设计一个用户认证系统，包含邮箱注册、JWT、权限管理，并给出完整的后端 API 和前端组件”，这种简单的指令就力不从心了。AI 可能会生成一个不完整的、有安全漏洞的或者不符合你项目架构的代码。
这时，提示词工程的价值就凸显出来了。一个优秀的提示词应该包含：
- 清晰的上下文：告诉 AI 项目的技术栈、架构、已有的代码结构。
- 明确的任务目标：将大任务拆解成具体的、可执行的子任务。
- 约束与规范：指定代码风格（如 Airbnb JavaScript Style Guide）、命名约定、必须使用的库或必须避免的反模式。
- 输出格式要求：期望 AI 以何种形式回复，是只给代码，还是附带解释？是否需要给出测试用例？
手动为每个复杂场景编写这样的提示词极其耗时。KingLeoJr/prompts的设计哲学就是“避免重复造轮子”。它将社区中经过实战检验的、高效的提示词结构化地组织起来，形成一个可检索、可复用的知识库。这本质上是一种经验的“杠杆”，用一份精心打磨的提示词，撬动整个开发者社区的效率提升。
2.2 仓库结构与组织逻辑
一个优秀的仓库，其结构本身就在传递信息。虽然项目正文描述为“None”，但根据其名称和关键词，我们可以推断并构建一个合理且实用的结构。这通常不是随意的文件堆积，而是有逻辑的分类。
一个典型的提示词仓库可能会按以下维度进行组织：
按 AI 工具/平台分类：这是最直观的分类方式。不同工具对提示词的响应特性、支持的功能（如编辑特定文件、运行命令）略有不同。
cursor/: 存放专门为 Cursor 编辑器优化的提示词，可能利用其“@”引用文件、自动生成提交信息等特性。aider/: 针对 aider（一个终端 AI 编程工具）的提示词，注重通过聊天来编辑代码库。windsurf/: 为 Windsurf（另一款 AI 原生 IDE）定制的提示词。cli/: 适用于命令行交互场景的通用提示词。
按任务类型/开发阶段分类：这是从开发者工作流出发的分类。
project-setup/: 项目初始化、脚手架生成。例如：“用 TypeScript + React + Vite 创建一个新项目，并配置好 ESLint, Prettier, Tailwind CSS”。refactoring/: 代码重构。例如：“将这段类组件重构为 React 函数组件，并使用 Hooks”。debugging/: 调试与问题排查。例如：“分析这段代码的报错信息，给出可能的原因和修复方案”。documentation/: 生成文档、注释。例如：“为这个函数生成详细的 JSDoc 注释”。testing/: 编写单元测试、集成测试。例如：“为这个UserService类编写 Jest 单元测试，覆盖所有公有方法”。code-review/: 模拟代码审查。例如：“以资深工程师的身份，审查这段代码，指出潜在的性能问题、安全漏洞和代码风格问题”。
按技术栈/领域分类：
web/: 前端开发（React, Vue, Svelte）。backend/: 后端开发（Node.js, Python Django/FastAPI, Go）。mobile/: 移动端开发（React Native, Flutter）。devops/: 基础设施与部署（Docker, Kubernetes, CI/CD）。
按提示词复杂度分类：
templates/: 完整的、多轮对话的模板，可能包含角色设定、分步指导。snippets/或one-liners/: 简短的、针对特定小任务的提示词，如“优化这个 SQL 查询”。
此外，仓库根目录通常会有README.md介绍使用方法和贡献指南，以及一个CONTRIBUTING.md说明如何提交新的提示词。每个提示词文件（如.md或.txt）内部，除了提示词正文，还应包含元数据，比如：
- 目标工具：适用于 Cursor、DeepSeek Chat 等。
- 预期任务：简要描述这个提示词用来做什么。
- 使用前置条件：需要提前打开什么文件？需要什么上下文？
- 示例输出：展示一个成功的交互案例，让用户有直观预期。
注意：在实际使用或贡献时，务必仔细阅读仓库自带的说明文档。不同的仓库维护者可能有不同的组织习惯和格式要求。盲目套用可能导致提示词效果不佳。
3. 核心提示词解析与编写心法
3.1 剖析一个优秀的开发提示词
让我们以一个具体的例子来拆解。假设在cursor/refactoring/目录下有一个名为react-class-to-fc.md的提示词文件。
文件内容可能如下：
# 提示词：将 React 类组件重构为函数组件 **目标工具**: Cursor (建议使用 Chat 模式) **适用场景**: 将旧的 React 类组件转换为使用 Hooks 的函数组件。 **前置条件**: 在 Cursor 中打开包含目标类组件的文件。 ## 提示词正文 你是一个经验丰富的 React 前端架构师。我将给你一段 React 类组件的代码。你的任务是将它重构为等效的 React 函数组件，使用现代 Hooks（如 useState, useEffect, useContext 等）。 请遵循以下规则： 1. **功能等价**：重构后的组件行为必须与原始组件完全一致。 2. **使用 Hooks**： * 将 `this.state` 转换为 `useState`。 * 将生命周期方法（`componentDidMount`, `componentDidUpdate`, `componentWillUnmount`）转换为 `useEffect`，并正确处理依赖项数组。 * 将类方法（`handleClick`, `fetchData` 等）转换为函数组件内的普通函数或使用 `useCallback` 进行优化（如果该函数被传递给子组件）。 * 如果使用了 `this.context`，请转换为 `useContext`。 3. **代码风格**： * 使用 ES6+ 语法。 * 使用函数表达式（`const MyComponent = () => {}`）或函数声明。 * 移除所有 `this` 关键字。 * 妥善处理 `props`，在函数参数中解构或直接使用 `props.xxx`。 4. **输出要求**： * 只输出重构后的完整函数组件代码。 * 在代码块中输出，并标明语言为 `jsx`。 * 如果某些转换存在多种合理选择（例如，是否使用 `useCallback`），请在代码后以注释形式简要说明你的考量。 这是我的组件代码：// [用户在此处粘贴类组件代码]
## 示例（供参考） **输入（类组件）**: ```jsx class Counter extends React.Component { constructor(props) { super(props); this.state = { count: 0 }; this.handleIncrement = this.handleIncrement.bind(this); } componentDidMount() { document.title = `You clicked ${this.state.count} times`; } componentDidUpdate() { document.title = `You clicked ${this.state.count} times`; } handleIncrement() { this.setState({ count: this.state.count + 1 }); } render() { return ( <div> <p>You clicked {this.state.count} times</p> <button onClick={this.handleIncrement}>Click me</button> </div> ); } }预期输出（函数组件）:
import React, { useState, useEffect } from 'react'; const Counter = (props) => { const [count, setCount] = useState(0); useEffect(() => { document.title = `You clicked ${count} times`; }, [count]); // 依赖项为 count，这样 count 更新时 effect 会运行 const handleIncrement = () => { setCount(prevCount => prevCount + 1); }; return ( <div> <p>You clicked {count} times</p> <button onClick={handleIncrement}>Click me</button> </div> ); }; export default Counter; // 说明：原 componentDidMount 和 componentDidUpdate 合并为一个 useEffect。handleIncrement 未传递给子组件，因此未使用 useCallback。**这个提示词的优秀之处在于：** 1. **角色设定明确**：“经验丰富的 React 前端架构师”。这为 AI 设定了专业背景，使其倾向于做出符合最佳实践的决定。 2. **任务边界清晰**：明确指出是“重构”，并且目标是“功能等价”的“函数组件”。 3. **规则具体可操作**：列出了 4 条具体规则，告诉 AI 每一步该怎么转换，甚至给出了 `useState`、`useEffect`、`useContext`、`useCallback` 等具体 Hook 的映射关系。这极大减少了 AI 的自由发挥空间，保证了输出的一致性。 4. **输出格式严格**：要求“只输出代码”并在“代码块中输出”，避免了 AI 生成冗长的解释，直接给出可用的结果。 5. **提供示例**：示例部分至关重要。它展示了“标准输入”和“期望输出”，让 AI 更准确地理解任务模式。这相当于给 AI 做了 few-shot learning（小样本学习）。 ### 3.2 编写高质量提示词的通用心法 基于对众多优秀提示词的分析，我们可以总结出编写高效开发提示词的几个核心心法： **心法一：扮演角色，而非下达指令** 不要只说“写代码”。告诉 AI “你是一个资深 Python 后端工程师，擅长设计高并发的 RESTful API”或“你是一个严格的代码审查机器人”。角色设定能激活 AI 内部相应的知识模式和语言风格。 **心法二：提供充足且结构化的上下文** AI 没有记忆你的项目。你需要主动提供： * **技术栈**：项目用的语言、框架、库及其版本。 * **项目结构**：简要说明相关文件的位置和关系。在 Cursor 等工具中，可以用“@”引用文件来提供上下文。 * **业务逻辑**：如果涉及复杂业务，用一两句话说明这个模块是做什么的。 **心法三：分解任务，逐步引导** 对于复杂任务，不要指望一个提示词解决所有问题。将其分解为多个步骤，甚至使用多轮对话。 1. 第一轮：分析需求，给出架构建议。 2. 第二轮：根据确定的架构，生成核心模块的接口定义。 3. 第三轮：实现具体函数。 4. 第四轮：编写单元测试。 这种“对话式开发”更能发挥 AI 的协作价值。 **心法四：明确约束，避免歧义** 模糊的要求会导致随机的输出。必须明确： * **代码规范**：遵循哪个风格指南？缩进是 2 空格还是 4 空格？ * **禁止项**：不允许使用 `var`，不允许使用 `any` 类型（TypeScript），不允许使用已弃用的 API。 * **性能要求**：时间复杂度有要求吗？需要考虑内存使用吗？ * **安全要求**：需要对用户输入进行验证或转义吗？ **心法五：指定输出格式，方便后续处理** 你是要完整的代码文件？还是代码片段？是否需要包含导入语句？是否需要生成配套的文档或测试？明确格式能让你拿到结果后直接使用，无需二次加工。 ## 4. 主流 AI 开发工具提示词适配实战 不同的 AI 编程工具有不同的交互模式和能力侧重点。**KingLeoJr/prompts** 仓库的价值之一就在于它可能包含了针对这些工具的优化提示词。我们来看看如何为几个主流工具定制提示词。 ### 4.1 Cursor：上下文感知与精准编辑 Cursor 的核心优势在于深度集成在编辑器中，能直接“看到”你打开的文件和项目结构。因此，为 Cursor 设计提示词的关键是**充分利用其上下文引用能力**。 **实战技巧：** * **使用 `@` 引用文件**：在提示词中，通过 `@文件名` 的方式将相关文件的内容直接提供给 AI 作为上下文。这是最强大的功能之一。 * *示例提示词*：“参考 `@/src/types/user.ts` 中的 `User` 接口，在 `@/src/api/user.ts` 文件中实现一个 `getUserById` 函数，使用 axios 发起 GET 请求到 `/api/users/{id}`。” * **利用“编辑”指令**：Cursor 可以接受直接编辑文件的指令。 * *示例提示词*：“在 `@/src/components/Button.tsx` 文件中，将 `variant` 属性的类型从 `'primary' | 'secondary'` 扩展为 `'primary' | 'secondary' | 'ghost'`，并在组件内部为 `ghost` 变体添加对应的 CSS 类。” * **结合聊天与自动模式**：复杂任务可以先在 Chat 模式中讨论方案，然后使用“生成代码”或“编辑代码”指令来执行。 **一个针对 Cursor 的复杂任务提示词模板：**角色：全栈开发助手 任务：基于现有项目上下文，实现一个新功能。 上下文：
- 项目是一个 Next.js 14 + TypeScript + Tailwind CSS 应用。
- 应用路由结构在
@/app目录下。 - 全局状态管理使用 Zustand，store 定义在
@/src/store。 - 组件库位于
@/src/components/ui，使用 shadcn/ui。
具体任务：
- 在
@/app/dashboard/settings/page.tsx旁边，新建一个profile页面路由 (/dashboard/profile)。 - 这个页面需要显示当前登录用户的个人信息（姓名、邮箱、头像），并允许编辑姓名。
- 用户信息通过
@/src/store/useUserStore获取和更新。 - 页面样式参考
@/app/dashboard/settings/page.tsx的布局。 - 使用
@/src/components/ui下的Card,Input,Button组件构建 UI。 - 编辑功能需要调用
@/src/api/user.ts中的updateUserProfile函数。
请先给出实现方案概述，然后根据我的确认，生成或修改相关文件。
### 4.2 Aider：终端驱动的代码库操作 Aider 是一个命令行工具，允许你通过自然语言对话来编辑整个代码库。它的特点是**面向整个项目**，擅长跨文件重构、大规模修改和代码库维护。 **实战技巧：** * **从全局视角提问**：Aider 会自动索引你 Git 仓库中的文件。你的提示词可以更宏观。 * *示例提示词*：“浏览我们的代码库，找出所有使用 `moment.js` 库的地方，并给出一个迁移到 `day.js` 的详细计划。” * **执行多文件变更**：Aider 可以同时编辑多个文件来实现一个功能。 * *示例提示词*：“我们需要添加用户角色权限。请：1. 在 `models/` 目录下创建 `Role.js` 模型。2. 修改 `models/User.js`，添加与 Role 的关联。3. 在 `middlewares/` 下创建 `authMiddleware.js`，实现基于角色的访问控制。4. 更新 `routes/userRoutes.js` 中的相关端点，应用这个中间件。” * **运行命令**：Aider 可以执行终端命令，如运行测试、安装包等。 * *示例提示词*：“实现上述修改后，请运行 `npm test` 以确保现有测试通过，然后运行 `git diff` 让我查看更改。” **Aider 提示词风格更偏向项目管理和重构：**我现在要重构我们的身份验证系统，从当前的 session-cookie 模式改为 JWT 模式。请分析authController.js、userModel.js和相关的路由文件。首先，列出需要修改的所有文件和每个文件的修改要点。然后，我们分步实施。第一步，请创建utils/jwt.js工具文件，包含生成 token 和验证 token 的函数。
### 4.3 DeepSeek Coder 与通用聊天模型：聚焦对话与推理 对于 DeepSeek Coder、Claude、ChatGPT 等通过 Web 界面或 API 访问的模型，提示词需要更加自包含，因为你无法直接“@”引用文件。 **实战技巧：** * **手动提供关键代码片段**：将最重要的几段代码直接粘贴到提示词中。 * **描述项目结构**：用文字清晰地描述文件之间的关系。 * **要求分步思考**：对于复杂问题，使用“链式思考”（Chain-of-Thought）提示技巧，要求 AI 先推理，再给出答案。 * *示例提示词*：“我有一个 Node.js Express 服务，在高并发下出现内存泄漏，`/api/data` 端点响应缓慢。请扮演一个性能诊断专家，按以下步骤帮我分析：1. 根据描述，推测最可能的内存泄漏原因（例如，未关闭数据库连接、全局变量累积、未清理的定时器等）。2. 针对每个可能的原因，给出在代码中定位和验证的方法（例如，使用什么工具、查看哪些代码段）。3. 最后，给出修复建议和代码示例。” **通用模型提示词模板（用于算法解释）：**你是一个计算机科学导师。请用通俗易懂的语言，结合具体的生活类比和可视化例子，向一个编程初学者解释“快速排序”算法。
请按以下结构回答：
- 核心思想：用一两句话概括。
- 生活类比：用一个整理书架或给扑克牌排序的例子来比喻。
- 分步可视化：用一个简单数组
[5, 3, 8, 4, 2]为例，一步步画出分区（partition）的过程，就像在白板上画图一样描述。 - 代码骨架：给出 Python 或 JavaScript 的递归实现伪代码，并逐行注释关键步骤。
- 时间/空间复杂度：解释为什么是 O(n log n) 和 O(log n)。
## 5. 构建个人提示词库与高效工作流 依赖公共仓库如 **KingLeoJr/prompts** 是很好的起点，但最高效的方式是建立属于自己的、与个人工作流深度集成的提示词库。 ### 5.1 如何收集与整理个人提示词 1. **记录成功对话**：每当你在与 AI 编程助手的对话中，通过一组精心设计的提示词成功解决了一个复杂问题（例如，搭建了一个完整的 CRUD 模块，修复了一个棘手的 Bug），不要关闭对话就了事。将这个对话的“精华部分”——即你发出的关键指令和 AI 的有效回复——保存下来。 2. **抽象成模板**：分析这个成功案例。你的哪些描述是通用的？哪些是针对特定项目的？将通用的部分提取出来，形成一个模板。例如，将“为我的电商项目添加购物车功能”抽象为“为 [项目类型] 添加 [功能模块]，包含 [列表， 增删改查， 状态管理]”。 3. **分类归档**：在你的笔记软件（如 Obsidian, Notion）或代码仓库中建立一个私人目录。分类方式可以参考公共仓库，但更贴合你的个人习惯。比如，你可以按“日常工作”、“学习探索”、“面试准备”、“代码优化”来分。 4. **添加元信息**：为每个提示词模板添加标签，如 `#react`、`#debug`、`#sql`、`#cursor`，方便日后搜索。 ### 5.2 将提示词集成到开发环境中 仅仅收集还不够，关键是要能快速调用。 * **IDE 代码片段**：将一些简短的、高频使用的提示词（如“添加 JSDoc 注释”、“生成单元测试骨架”）配置成 IDE 的代码片段（Snippet）。例如，在 VS Code 中，输入 `///doc` 然后按 Tab，就能自动展开为一个函数注释模板。 * **文本扩展工具**：使用 Alfred、TextExpander、Espanso 等工具。你可以设置缩写，比如 `;refactor`，输入后自动扩展为一整套重构提示词，然后你只需要粘贴目标代码即可。 * **自定义 AI 助手指令**：一些 AI 工具允许保存自定义指令（Custom Instructions）。你可以将你最常用的角色设定、代码风格要求等固定下来，作为所有对话的“系统级”提示词，这样每次开始新对话时，AI 就已经具备了你的偏好背景。 ### 5.3 迭代与优化：让提示词越用越聪明 提示词不是一成不变的。你需要像优化代码一样优化你的提示词。 1. **A/B 测试**：对于同一个任务，尝试用两种略有不同的提示词（比如一个更详细，一个更简洁），对比 AI 的产出质量和效率。记录下哪种效果更好。 2. **分析失败案例**：当 AI 输出不符合预期时，不要简单归结为“AI 太笨”。仔细分析：是我的指令有歧义吗？是上下文给的不够吗？是约束条件没写清楚吗？根据分析结果修正你的提示词。 3. **加入“持续改进”指令**：在一些复杂的、需要多轮对话的任务结束时，可以追加一个提示：“回顾我们刚才的整个对话。为了未来能更高效地完成类似任务，请你为我设计一个更优的初始提示词模板，这个模板应该包含哪些关键信息和要求？”让 AI 自己帮你优化提示词。 ## 6. 常见问题与避坑指南 在实际使用 AI 编程和提示词的过程中，你会遇到各种问题。以下是一些典型问题及其解决方案，这往往是公共仓库里不会写的“实战经验”。 ### 6.1 AI 生成代码不工作或不符合预期 这是最常见的问题。不要急于责怪 AI，按以下步骤排查： 1. **检查上下文完整性**：AI 是否“看到”了所有必要的文件？在 Cursor 中，你是否 `@` 引用了所有相关的模块、类型定义？在通用聊天界面，你是否把关键代码和错误信息都贴全了？**上下文缺失是导致“幻觉”（胡编乱造）的首要原因。** 2. **审查约束条件**：你的提示词中关于技术栈、版本、代码风格的描述是否准确？如果你说“用 React 18”，AI 就不会用类组件。如果你说“避免使用 `any`”，但你的接口文件里全是 `any`，AI 也会困惑。 3. **任务是否过于复杂**：你是否试图让 AI 一步完成一个需要 1000 行代码的功能？尝试将任务分解。先让 AI 设计接口和数据结构，你确认后，再让它实现具体函数。 4. **提供错误反馈**：如果 AI 生成的代码报错，直接把完整的错误信息粘贴给它，并问“为什么这段代码会报这个错？如何修复？”AI 通常很擅长调试。 > **避坑技巧**：对于关键业务代码，永远不要完全信任 AI 的第一次输出。将其视为一个强大的“初级工程师”的初稿，你必须进行严格的代码审查和测试。特别是安全、性能和边界条件相关的逻辑。 ### 6.2 如何应对 AI 的“幻觉”或知识过时 AI 可能会使用不存在的库版本、编造 API 用法，或者提供过时的方法。 1. **要求 AI 提供来源或解释**：在提示词中加入“请确保你提供的方案是基于 [技术] 官方最新稳定版文档的。如果你引用特定 API，请说明其出处。”这能在一定程度上抑制幻觉。 2. **交叉验证**：对于 AI 推荐的库、API 或解决方案，快速去官方文档或搜索引擎核实一下。这是一个必须养成的好习惯。 3. **利用 AI 的搜索能力**：许多现代 AI 工具（如 Cursor 的搜索模式、ChatGPT 的联网搜索）可以实时获取网络信息。在提示词中明确要求“请联网搜索 [具体问题] 的最佳实践并给出答案”。 4. **限定时间范围**：对于快速发展领域（如前端框架），可以指定“请根据 2023 年以后的 React 最佳实践来回答”。 ### 6.3 多轮对话中上下文丢失或混乱 进行长时间、多轮对话后，AI 可能会忘记早期的约定或出现逻辑不一致。 1. **定期总结与确认**：在完成一个阶段后，主动说“让我们总结一下目前达成共识的设计：1. ... 2. ... 3. ... 你确认吗？”这既能巩固上下文，也能及时发现偏差。 2. **使用“系统指令”锚定核心信息**：在对话开始时，用一条强指令设定不可更改的规则，如“在整个对话中，请始终记住：本项目使用 TypeScript 且严格模式开启，禁止使用 `any` 类型。” 3. **开启新对话**：如果对话已经非常冗长和混乱，最好的办法往往是复制当前达成的一致结论，开启一个新对话，并将结论作为新对话的初始上下文。这比在混乱中挣扎更高效。 ### 6.4 提示词效率低下，需要反复调整 如果你的提示词总是需要来回修改才能得到想要的结果，说明提示词本身设计有问题。 1. **采用结构化提示词框架**：可以借鉴一些成熟的框架，如： * **CRISPE 框架**： * **Capacity and Role** (能力与角色)：你希望 AI 扮演什么角色？ * **Result** (结果)：你期望的最终输出是什么？（格式、内容） * **Insights** (洞察)：需要给 AI 哪些背景信息、数据？ * **Steps** (步骤)：任务需要分几步完成？ * **Personality** (个性)：希望 AI 以什么风格回应？（简洁、详细、严谨、富有创意） * **Experiments** (实验)：你希望 AI 尝试几种不同的方案吗？ 使用框架能确保你覆盖所有关键要素。 2. **从“示例驱动”开始**：对于格式固定的输出（如生成特定格式的 JSON、编写符合公司规范的 API 文档），最有效的方法是在提示词中直接给出 1-2 个完美的示例（Few-shot Learning）。AI 会非常准确地模仿示例的格式和风格。 3. **量化你的要求**：避免使用“高效”、“健壮”等模糊词汇。使用可衡量的要求，如“函数的时间复杂度应低于 O(n^2)”、“需要处理 `input` 为 `null`、`undefined`、空字符串的边界情况”、“单元测试覆盖率需达到 90% 以上”。 ## 7. 进阶：从使用提示词到设计提示词系统 当你熟练使用单个提示词后，可以更进一步，设计一套相互关联的提示词系统，来实现更复杂的自动化工作流。 ### 7.1 链式提示词 (Prompt Chaining) 将一个大任务分解为多个子任务，每个子任务由一个专门的提示词负责，上一个提示词的输出作为下一个提示词的输入。 **案例：自动化代码审查与修复** 1. **提示词 A (分析器)**：输入源代码。输出：发现的问题列表，按严重性（错误、警告、建议）分类，并指出具体行号和问题描述。 2. **提示词 B (修复器)**：输入源代码和问题列表。输出：修复后的代码，并附上修改说明。 3. **提示词 C (总结器)**：输入原始代码和修复后的代码 diff。输出：一份给人看的代码审查报告摘要。 你可以用脚本（Python, Node.js）将这三个提示词串联起来，形成一个自动化的代码审查流水线。 ### 7.2 提示词变量与模板引擎 像编写代码一样编写提示词，使用变量占位符。在运行时，用实际值替换这些变量。 **基础模板：**你是一个 {language} 开发专家。请为以下 {framework} 函数编写单元测试。 函数代码： {function_code} 测试要求：使用 {testing_library} 框架，覆盖所有分支，并包含至少一个边界用例。
在实际使用时，用一个简单的脚本读取模板文件，将 `{language}` 替换为 “Python”，`{framework}` 替换为 “FastAPI”，`{function_code}` 替换为具体的函数字符串，`{testing_library}` 替换为 “pytest”，然后发送给 AI。 ### 7.3 与现有开发工具集成 真正的威力在于将提示词系统嵌入到你已有的工具链中。 * **Git Hook**：在 `pre-commit` 钩子中，运行一个脚本，使用提示词 AI 自动检查提交信息是否规范、代码是否包含明显的调试语句或 TODO。 * **CI/CD 流水线**：在 CI 阶段，除了运行测试，还可以调用 AI 分析测试覆盖率报告，并生成可读性强的总结，评论在 Pull Request 里。 * **IDE 插件开发**：你可以为自己常用的 IDE 开发插件，将你精心设计的提示词模板以图形化按钮或命令面板的形式呈现，一键调用。 **一个简单的集成示例（使用 Shell 脚本和 Cursor CLI）：** 假设你有一个用于生成 Git 提交信息的提示词模板 `prompts/git_commit.md`。你可以创建一个别名或脚本： ```bash #!/bin/bash # 脚本: smart-commit # 获取暂存区的改动 diff DIFF=$(git diff --cached --no-color) # 读取提示词模板 PROMPT_TEMPLATE=$(cat ~/my-prompts/git_commit.md) # 将 diff 填入模板的 {diff} 占位符 FINAL_PROMPT="${PROMPT_TEMPLATE/\{diff\}/$DIFF}" # 调用 Cursor CLI (假设有) 或 AI API 生成提交信息 # 这里简化表示，实际需调用 API GENERATED_MSG=$(call_ai_api "$FINAL_PROMPT") # 使用生成的提交信息进行提交 git commit -m "$GENERATED_MSG"这个脚本实现了每次提交前，自动分析代码变动，并用 AI 生成规范的提交信息。这只是一个概念演示，真正的实现需要处理 AI API 的调用和错误处理。
走到这一步，你就不再仅仅是“提示词使用者”，而是成为了“提示词工程师”和“AI 增强工作流的设计师”。KingLeoJr/prompts这类仓库是你的灵感来源和素材库，但最终，如何将这些素材编织成提升你个人和团队生产力的自动化网络，则取决于你的想象力和实践。记住，最好的提示词系统，是那个能让你几乎忘记它的存在、却能让开发工作流畅如水的系统。
