Gemini CLI提示词库：AI辅助开发提效的工程化实践

1. 项目概述：一个为开发者提效的AI提示词库

如果你和我一样，日常开发中经常需要借助AI助手来审查代码、生成文档、设计架构，那你肯定也经历过这样的时刻：面对一个复杂任务，你需要在聊天框里反复调整措辞，试图让AI理解你的意图，结果要么是输出太笼统，要么是格式一团糟，来回几次，时间就浪费掉了。我一直在寻找一种方法，能把那些经过实战检验、能稳定输出高质量结果的“黄金提示词”固化下来，就像建立一个私人的、可复用的工具箱。

最近，我在GitHub上发现了一个名为“Gemini CLI Prompt Library”的开源项目，它完美地契合了我的需求。简单来说，这是一个为Gemini CLI（一个命令行AI工具）设计的扩展，它打包了30多个针对常见开发任务精心设计的提示词模板。你不用再为“如何向AI提问”而绞尽脑汁，只需记住一个简单的斜杠命令，比如/code-review:security，就能立刻获得一份结构清晰、内容深入的安全代码审查报告。

这个项目的核心价值在于，它将“提示词工程”的最佳实践产品化了。它不仅仅是一个命令集合，更是一个学习如何与AI高效协作的范例库。通过研究这些预设的提示词，你能直观地理解什么样的指令是明确、具体且可操作的。对于任何希望将AI深度集成到工作流中的开发者、技术负责人或技术写作者来说，这都是一件能显著提升生产力和输出质量的利器。

2. 核心设计思路：从零散提问到标准化工作流

在深入使用和研究了gemini-cli-prompt-library之后，我发现它的设计思路非常清晰，其成功之处在于解决了AI协作中的几个核心痛点，并将解决方案封装成了一个轻量级、可扩展的系统。

2.1 解决的核心问题：提示词的“质量”与“一致性”困境

在没有标准化提示词库之前，我们与AI的交互存在两大不确定性：

1. 质量波动：同一个任务，不同的提问方式会导致AI输出的质量天差地别。一个模糊的“帮我看看这段代码”可能只会得到泛泛而谈的建议，而一个结构化的、包含具体检查项的提问则能引导AI进行深度分析。
2. 格式混乱：AI的回复往往是自由文本，对于需要直接集成到项目中的产出（如API文档、测试代码），我们不得不花费额外时间进行格式整理和结构调整。

这个项目通过预定义的、经过优化的提示词模板，从根本上消除了这种不确定性。每一个模板都相当于一个微型的“规格说明书”，它明确告诉AI：

• 角色：你是一个资深的安全专家/测试工程师/系统架构师。
• 任务：执行一个具体、细分的任务（如“进行安全分析，重点关注SQL注入和XSS”）。
• 输出格式：请按照“1. 问题概述 2. 风险等级 3. 代码位置 4. 修复建议 5. 安全代码示例”这样的结构来回复。

2.2 架构解析：基于目录与TOML文件的模块化设计

项目的文件结构非常直观，体现了其模块化的设计思想。虽然原README没有详细展示目录树，但根据其“Customization”部分的描述，我们可以推断出其核心架构：

prompt-library-extension/ ├── commands/ # 核心提示词目录 │ ├── code-review/ # 分类：代码审查 │ │ ├── security.toml │ │ ├── performance.toml │ │ └── ... │ ├── docs/ # 分类：文档编写 │ ├── testing/ # 分类：测试 │ └── ... # 其他分类 ├── README.md └── extension.toml # 扩展元数据文件

关键设计点解析：

• 按功能分类：将提示词按code-review、docs、testing等场景分类存放，符合开发者的心智模型，便于查找和管理。
• TOML格式存储：每个提示词都是一个独立的.toml文件。TOML是一种易于阅读和编写的配置文件格式。这种选择非常明智，因为它比JSON更友好（无需处理引号和逗号），比YAML更严格（减少缩进错误），非常适合存储多行文本的提示词内容。文件内容大致如下：

  # commands/code-review/security.toml prompt = """ 你是一个经验丰富的应用安全工程师。请对用户提供的代码进行深入的安全审查。 审查重点包括： 1. 输入验证与过滤 2. SQL注入风险 3. 跨站脚本攻击风险 4. 敏感信息泄露 5. 不安全的直接对象引用 请按以下格式输出： ## 安全审查报告 ### 1. 概述 [简要总结整体安全状况] ### 2. 详细问题 - **[问题类别]** 在文件 `[行号]`：`[有问题的代码片段]` - **风险**：[解释风险] - **修复建议**：[提供具体的代码修改方案] ### 3. 安全加固建议 [提供通用的、针对该项目类型的安全最佳实践] """

• 变量插值：提示词中可以使用{{args}}这样的占位符。当用户在CLI中输入/code-review:security “我的代码”时，Gemini CLI会自动将“我的代码”替换到提示词模板中{{args}}的位置，再发送给AI模型。这实现了提示词的动态化和可复用。

2.3 与Gemini CLI的集成机制

这个项目本身是一个“扩展”。Gemini CLI提供了扩展机制，允许开发者社区贡献功能。安装后，该扩展会向Gemini CLI注册一系列新的斜杠命令（/commands）。当用户执行这些命令时，CLI会找到对应的TOML文件，组装完整的提示词，调用配置的AI模型（如Gemini、GPT等），并将结果返回给用户。这种设计使得功能与核心工具解耦，既保持了CLI的简洁，又获得了无限的扩展能力。

实操心得：为什么是CLI扩展？选择命令行界面而非图形化插件，在我看来是一个高明的决定。首先，它极度轻量，不依赖特定的IDE（如VSCode、IntelliJ），在任何终端环境下都能工作，适配性极强。其次，它能无缝集成到Shell脚本、Makefile或CI/CD流水线中，实现开发流程的自动化。例如，你可以在每次提交代码前，自动运行/code-review:best-practices来检查代码规范。

3. 核心功能深度解析与实战应用

这个提示词库覆盖了软件开发生命周期中的关键环节。下面，我将挑选几个最具代表性的类别，结合我自己的使用体验，进行深度解析，并展示如何将其应用到真实工作场景中。

3.1 代码审查与分析：从人工巡检到AI辅助审计

传统的代码审查高度依赖评审者的经验和时间，容易遗漏深层次问题，尤其是安全漏洞。/code-review:系列提示词将审查过程标准化、结构化。

以/code-review:security为例，我们拆解其工作流程：

1. 输入：你提供一段可疑的代码。
2. 处理：提示词模板赋予AI“安全专家”的角色，并明确指令其从5-6个关键维度（如SQL注入、XSS、敏感数据）进行分析。
3. 输出：AI会生成一份包含概述、详细问题列表（含代码位置、风险解释、修复建议）和通用加固建议的报告。

实战场景：审查一个简单的用户登录函数假设我们有下面这段存在明显缺陷的Node.js代码：

// 存在漏洞的登录函数 app.post('/login', (req, res) => { const username = req.body.username; const password = req.body.password; const query = `SELECT * FROM users WHERE username = '${username}' AND password = '${password}'`; db.query(query, (err, results) => { if (results.length > 0) { req.session.userId = results[0].id; res.send('Login successful!'); } else { res.send('Invalid credentials'); } }); });

在终端执行：/code-review:security “上面那段代码”

你会得到的输出将类似以下结构（AI生成内容示例）：

## 安全审查报告 ### 1. 概述 该登录端点存在严重的安全漏洞，主要问题为SQL注入，同时缺乏基本的密码安全处理，极易导致数据库被攻击者完全控制。 ### 2. 详细问题 - **【SQL注入】** 在行 `4`：`const query = \`SELECT * FROM users WHERE username = '${username}' AND password = '${password}'\`;` - **风险**：直接拼接用户输入的`username`和`password`到SQL语句中。攻击者可以输入`admin' --`作为用户名，使密码验证部分被注释掉，从而以管理员身份登录。更严重的，可通过联合查询等操作读取、修改或删除所有数据。 - **修复建议**：使用参数化查询（预编译语句）。 ```javascript const query = `SELECT * FROM users WHERE username = ? AND password = ?`; db.query(query, [username, password], (err, results) => { ... }); ``` - **【密码明文存储与传输】** 在整个流程中。 - **风险**：代码直接比较明文密码。一旦数据库泄露，所有用户密码将暴露。此外，密码在网络上也可能以明文传输（如果未使用HTTPS）。 - **修复建议**： 1. 在数据库存储密码的哈希值（加盐），例如使用`bcrypt`库。 2. 前端到后端必须使用HTTPS。 ```javascript // 存储时 const hashedPassword = await bcrypt.hash(password, 10); // 验证时 const match = await bcrypt.compare(inputPassword, storedHash); ``` ### 3. 安全加固建议 1. 对所有用户输入进行严格的验证和清理。 2. 实施强密码策略。 3. 考虑添加登录失败次数限制和账户锁定机制。 4. 使用安全的会话管理。

使用价值：这份报告不仅指出了问题，还提供了可直接使用的修复代码。对于经验不足的开发者，这是一次生动的安全教育；对于资深开发者，这是一个高效的自动化初筛工具，能节省大量肉眼审查低级错误的时间。

3.2 文档生成：告别“写文档恐惧症”

编写和维护文档是许多开发者的痛点。/docs:系列提示词能根据项目上下文，快速生成结构清晰、内容丰富的文档初稿。

以/docs:write-readme为例：你只需要输入一段简单的项目描述，例如：“一个用Python Flask编写的RESTful API服务，用于管理个人待办事项（Todo），支持用户注册、登录、创建、更新、删除和列出任务，使用JWT进行认证，数据存储在SQLite中。”

执行命令后，AI会生成一个包含以下章节的完整README.md草案：

1. 项目名称与简介
2. 主要功能特性
3. 技术栈
4. 安装与运行指南（包含pip install命令、环境变量设置）
5. API接口文档（列出所有端点、方法、请求示例、响应示例）
6. 数据库结构说明
7. 项目结构
8. 如何贡献
9. 许可证

> 注意：AI生成的文档是优秀的起点，但绝非终点。你必须仔细核对技术细节的准确性，例如生成的安装命令是否适用于你的虚拟环境管理方式，API示例是否与你的实际代码完全一致。将其视为一个帮你完成了80%格式化工作的助手，剩下的20%关键性内容校验和个性化调整，必须由你自己完成。

3.3 测试用例生成：提升测试覆盖率的利器

编写全面的单元测试耗时耗力，特别是考虑各种边界条件和异常场景时。/testing:generate-unit-tests提示词能极大地加速这一过程。

实战场景：为一个工具函数生成测试假设我们有一个计算商品折扣的函数：

function calculateDiscountedPrice(originalPrice, discountPercentage) { if (originalPrice < 0 || discountPercentage < 0 || discountPercentage > 100) { throw new Error('Invalid input: price and discount must be non-negative, discount must be <= 100'); } return originalPrice * (1 - discountPercentage / 100); }

使用命令后，AI很可能会生成一个包含以下测试的套件（以Jest框架为例）：

describe('calculateDiscountedPrice', () => { test('should apply correct discount for valid inputs', () => { expect(calculateDiscountedPrice(100, 20)).toBe(80); expect(calculateDiscountedPrice(50, 10)).toBe(45); }); test('should return original price when discount is 0', () => { expect(calculateDiscountedPrice(100, 0)).toBe(100); }); test('should return 0 when discount is 100', () => { expect(calculateDiscountedPrice(100, 100)).toBe(0); }); test('should throw error for negative price', () => { expect(() => calculateDiscountedPrice(-10, 20)).toThrow('Invalid input'); }); test('should throw error for negative discount', () => { expect(() => calculateDiscountedPrice(100, -5)).toThrow('Invalid input'); }); test('should throw error for discount greater than 100', () => { expect(() => calculateDiscountedPrice(100, 120)).toThrow('Invalid input'); }); test('should handle floating point numbers correctly', () => { expect(calculateDiscountedPrice(99.99, 15)).toBeCloseTo(84.9915); }); });

使用价值：它几乎考虑到了所有你能想到的边界情况，甚至包括浮点数精度问题（使用了toBeCloseTo）。这不仅能确保你代码的健壮性，其测试用例本身也是学习“什么才是好的单元测试”的绝佳教材。

4. 高级使用技巧与自定义扩展

掌握了基本用法后，你可以将这个工具的能力提升到一个新的层次，使其完全适配你的个人或团队工作流。

4.1 创建属于你自己的提示词模板

这是发挥其最大威力的地方。项目鼓励你“Fork and adapt”。假设你团队主要使用Go语言开发微服务，并且有一套内部的代码规范。你可以轻松创建专属的提示词。

步骤详解：

1. 定位目录：进入扩展的安装目录（通常是~/.gemini/extensions/下的某个子目录），找到commands/文件夹。
2. 创建分类和文件：为你团队的特定需求创建分类，比如go-review。

   cd commands mkdir go-review cd go-review touch concurrency.toml

3. 编写定制化提示词：编辑concurrency.toml，写入针对Go并发代码审查的专用提示。

   prompt = """ 你是一个Go语言并发专家。请审查以下Go代码，重点检查并发安全问题。 审查维度： 1. **数据竞争**：检查共享变量是否被多个goroutine在没有同步机制下访问。 2. **死锁**：分析锁的获取顺序是否可能形成循环等待。 3. **通道使用**：通道是否被正确关闭？是否存在未缓冲通道导致的goroutine阻塞？ 4. **Context传播**：并发操作中Context是否被正确传递和取消？ 5. **WaitGroup误用**：WaitGroup的Add/Done/Wait调用是否配对且在正确的位置？ 6. **并发模式**：代码使用的并发模式（如Worker Pool, Pipeline）是否合理高效？ 请结合Go内存模型和最佳实践进行分析。 输出格式： ## Go并发代码审查报告 ### 代码摘要 [简述代码功能] ### 潜在问题 - **[问题类别]** 在文件 `[文件名:行号]`：`[代码片段]` - **风险分析**：[详细解释] - **修复建议**：[提供修改后的代码片段或方案] ### 性能与优化建议 [针对并发性能的提升建议] """

4. 重启与使用：重启Gemini CLI，就可以使用你自定义的命令，例如：/go-review:concurrency “你的Go并发代码”。

4.2 将提示词集成到自动化流程中

CLI命令的特性使其极易与自动化工具结合。

• Git Hooks：在项目的.git/hooks/pre-commit脚本中加入命令，在每次提交前自动进行基础代码审查。

  #!/bin/bash # pre-commit hook 示例（简化版） changed_files=$(git diff --cached --name-only --diff-filter=ACM | grep '\.js$') for file in $changed_files; do gemini run /code-review:best-practices "$(cat "$file")" >> code_review_report.md done # 可以设置检查报告中的问题数量，决定是否阻止提交

• CI/CD Pipeline：在GitLab CI、GitHub Actions或Jenkins的构建阶段，加入一个步骤，使用/docs:write-changelog基于本次提交的git log自动生成变更日志草案，或使用/testing:edge-cases为新函数生成测试用例。

4.3 提示词工程原则的内化与应用

这个项目本身就是一个优秀的“提示词工程”教科书。反复使用和研究这些模板后，我总结出几条可以应用到任何AI对话中的核心原则，这比单纯使用工具更有价值：

1. 角色扮演 + 任务具体化：不要问“怎么写代码”，而是说“你是一个资深React开发者，请用TypeScript和函数式组件，实现一个受控的、支持搜索和分页的表格组件，要求代码包含清晰的类型定义和必要的注释。”
2. 结构化输出要求：明确指定你想要的格式。例如：“请用Markdown表格列出三种方案的优缺点，表格列包括：方案名称、优点、缺点、适用场景。”
3. 提供上下文与约束：告诉AI你的环境限制（“我使用的是Python 3.9，不能安装额外库”）和业务规则（“折扣率不能超过用户等级允许的最大值”）。
4. 迭代与精炼：将AI的第一次回答作为“初稿”。如果不够满意，不要推翻重问，而是在其基础上进行修正和补充：“很好，但在‘性能优化建议’部分，请再补充关于数据库索引设计的建议。”

5. 常见问题、局限性与应对策略

没有任何工具是完美的。在实际使用gemini-cli-prompt-library的过程中，我也遇到了一些问题和局限性。了解这些，能帮助你更理性、更高效地使用它。

5.1 安装与配置问题

问题1：gemini命令未找到或扩展安装失败。

• 排查：首先确保你已经正确安装了Gemini CLI本体。请前往其官方文档查看安装指南。通常需要先安装Node.js，然后通过npm安装：npm install -g @modelcontextprotocol/gemini-cli。
• 检查网络：安装扩展需要从GitHub或网络获取资源，请确保你的网络连接正常，且能访问相关仓库。
• 路径权限：检查CLI的扩展安装目录是否有写入权限。

问题2：执行命令后，AI回复内容空洞或跑题。

• 排查：
  1. 检查输入：你是否通过{{args}}提供了足够的上下文？对于代码审查，你需要粘贴完整的、相关的代码片段，而不是一个函数名。
  2. 检查模型：Gemini CLI背后连接的AI模型（如Gemini Pro、GPT-4）的能力和版本会影响结果。尝试在CLI配置中切换到更强大的模型。
  3. 提示词本身：某些自定义提示词可能设计得不够精确。尝试回到基础提示词，或者参考项目内置的优秀提示词来修改你的自定义版本。

5.2 输出质量的局限性

局限性1：对业务逻辑的深度理解不足。AI无法理解你代码背后的复杂业务规则和领域知识。例如，它可能检查出一个数值除零的风险，但无法判断“用户积分兑换比例”这个业务计算逻辑是否正确。

• 应对策略：将AI定位为“代码语法/安全/基础规范检查员”和“文档/测试/样板代码生成器”。对于核心业务逻辑的正确性，必须由开发者本人或通过详尽的业务测试来保证。

局限性2：可能产生“幻觉”或过时信息。AI可能会引用一个不存在的库的最新API，或者针对一个已修复的安全漏洞提出警告。

• 应对策略：永远将AI的输出视为“建议”而非“真理”。对于它提供的任何代码示例、API用法或安全建议，都需要你自己进行二次验证——查阅官方文档、运行测试、在安全环境中验证。

局限性3：生成内容缺乏个性化和团队特定知识。内置的/docs:write-readme生成的可能是通用模板，不会包含你团队特有的“快速开始”、“部署到内部K8s集群”的步骤。

• 应对策略：这正是自定义提示词的用武之地。你可以创建一个/docs:write-readme-internal.toml，在模板中预先写入你们团队的固定章节结构和部署指南，只留出项目特定信息让AI填充。

5.3 与现有工作流的融合挑战

挑战：如何让团队其他成员也接受并使用？如果只有你一个人使用，其价值会大打折扣。

• 应对策略：
  1. 示范价值：在团队代码评审会上，展示你用AI快速生成的、质量极高的安全审查报告或测试用例，用事实说服大家。
  2. 创建团队共享库：Fork原项目，在内部Git服务器上建立你们团队的版本，将自定义的、符合团队规范的提示词提交进去。然后统一安装这个内部扩展。
  3. 编写简易指南：为团队写一个简单的“五分钟上手”文档，降低使用门槛。

5.4 成本与依赖考量

依赖外部AI服务：所有提示词的执行最终都需要调用云端AI API（如Google Gemini API），这可能产生费用，并且需要稳定的网络连接。

• 考量：对于企业或高频用户，需要评估API调用成本。可以将此工具用于关键任务（如上线前安全审查、生成核心文档），而非所有琐碎查询。

工具链绑定：你依赖了Gemini CLI这个特定工具。

• 考量：即使未来不再使用Gemini CLI，你在这个项目中积累的、写在TOML文件里的高质量提示词模板，其文本内容本身是具有极高价值的。你可以轻松地将它们迁移到其他支持自定义提示词的平台或工具中。

这个项目为我打开了一扇门，让我意识到与AI协作可以如此高效和标准化。它不仅仅是一个工具集，更是一种工作方法的转变——从临时的、随性的提问，转向系统的、可复用的知识交付。我最深的体会是，它的最大价值不在于那30多个开箱即用的提示词，而在于它提供的这个“框架”：一个按场景分类、易于自定义、可通过命令行无缝集成的提示词管理框架。

我花了些时间，根据我们团队的技术栈（主要是Go和Vue），创建了一套内部的提示词，比如/go:http-server-review（检查Go HTTP服务的路由、中间件、错误处理）和/vue3:component-review（检查Vue 3组件的Composition API使用、Props验证、响应式逻辑）。现在，新同事在提交代码前，都会习惯性地跑一下对应的审查命令，这成了我们代码质量的第一道自动化防线。

如果你还没有尝试过将AI提示词工程化，我强烈建议你从gemini-cli-prompt-library开始。即使你不使用Gemini CLI，仔细阅读其项目中的.toml文件，学习那些提示词的写法，也足以让你与任何AI对话的效率提升一个档次。记住，未来属于那些善于将人类智慧与机器效率相结合的人，而这个项目，正是一个绝佳的起点。