---
name: prompts-library
description: 常用提示词模板库（含元提示词），通过 #prompts-library 引用
---

# 常用提示词库

> 开发过程中常用的提示词模板

---

## 需求分析

### 需求澄清

```
我想实现 [功能描述]。

请帮我：
1. 分析这个需求的核心目标是什么
2. 拆解为具体的子任务
3. 识别可能的技术难点
4. 推荐实现方案

在开始之前，请先问我任何需要澄清的问题。
```

### 方案对比

```
我需要实现 [功能]，有以下几种方案：
- 方案A：[描述]
- 方案B：[描述]

请从以下维度对比：
1. 实现复杂度
2. 性能
3. 可维护性
4. 扩展性

给出推荐方案及理由。
```

---

## 胶水开发

### 寻找轮子

```
我需要实现 [你的需求]，请帮我：
1. 分析这个需求可能涉及哪些技术领域
2. 推荐对应的 GitHub Topics 关键词
3. 搜索并推荐 3-5 个成熟的开源库
4. 对比它们的优缺点（Star数、更新频率、文档质量）
5. 给出最终推荐
```

### 理解库接口

```
我选择使用 [库名] 来实现 [功能]。

请帮我：
1. 总结这个库的核心 API
2. 列出关键函数的输入输出
3. 给出最小可运行示例
4. 说明常见的坑和注意事项
```

### 编写胶水代码

```
我需要连接以下两个库：
- 库A：[名称]，负责 [功能]
- 库B：[名称]，负责 [功能]

数据流：A 的 [输出] → 转换 → B 的 [输入]

请帮我编写最小必要的胶水代码，要求：
1. 只做组合、调用、封装、适配
2. 不重复实现库已有的功能
3. 添加必要的错误处理
4. 添加日志记录
```

---

## 代码开发

### 功能实现

```
请实现 [功能描述]。

要求：
1. 只改 [指定文件/模块]，不要动其他文件
2. 遵循现有代码风格
3. 添加必要的注释
4. 考虑边界情况和错误处理

输入：[描述]
输出：[描述]
```

### 代码重构

```
请重构以下代码：

[粘贴代码]

重构目标：
1. [目标1，如：提高可读性]
2. [目标2，如：减少重复]

约束：
- 保持功能不变
- 保持接口不变
```

### 代码审查

```
请审查以下代码：

[粘贴代码]

请从以下角度审查：
1. 代码质量（可读性、命名、结构）
2. 潜在 bug
3. 性能问题
4. 安全问题
5. 改进建议
```

---

## 调试排错

### 错误分析

```
我遇到了一个错误：

错误信息：
[粘贴完整错误]

相关代码：
[粘贴相关代码]

我的环境：
- 操作系统：[...]
- 语言版本：[...]
- 相关依赖版本：[...]

我已经尝试过：
1. [尝试1]
2. [尝试2]

请帮我分析原因并给出解决方案。
```

### 最小复现

```
我遇到一个问题：[描述问题]

预期行为：[...]
实际行为：[...]

请帮我：
1. 分析可能的原因
2. 给出最小复现步骤
3. 提供解决方案
```

---

## 文档生成

### 项目上下文

```
请基于当前对话内容，生成一份项目上下文文档，包含：
1. 项目概要
2. 范围定义
3. 关键实体与关系
4. 功能模块
5. 技术方向
6. 当前进展
7. 后续计划

若某字段信息不足，标注"暂无信息"。
```

### API 文档

```
请为以下代码生成 API 文档：

[粘贴代码]

文档格式：
- 函数名
- 功能描述
- 参数说明（类型、含义、是否必填）
- 返回值说明
- 使用示例
- 注意事项
```

---

## 流程标准化

### 流程文档

```
请将以下内容转化为标准化流程文档：

[描述流程]

文档必须包含：
1. 目的
2. 适用范围
3. 注意事项
4. 相关模板或工具
5. 流程步骤（使用数字编号）

要求：
- 步骤必须可执行、按时间顺序排列
- 每一步都要明确详细具体怎么做
- 只看这一个文档就能完全掌握
```

---

## 架构设计

### 系统架构

```
我要设计一个 [系统描述] 的架构。

需求：
1. [需求1]
2. [需求2]

约束：
- [约束1]
- [约束2]

请帮我：
1. 设计系统架构
2. 画出架构图（Mermaid）
3. 说明各模块职责
4. 描述数据流
5. 列出技术选型建议
```

### 目录结构

```
请为 [项目类型] 项目设计目录结构。

技术栈：[...]
主要功能：[...]

要求：
1. 遵循关注点分离原则
2. 便于测试
3. 便于扩展
4. 符合业界最佳实践
```


---

## 元提示词模式

> 用于生成和优化提示词的高级模式

### α-Generator 模式（生成）

当需要创建新的提示词时，使用此模式：

#### 生成规则

1. **结构化**：使用清晰的章节划分
2. **具体化**：避免模糊描述，使用具体指令
3. **可验证**：包含明确的输出格式和验收标准
4. **边界清晰**：明确说明能做什么、不能做什么

#### 提示词模板结构

```markdown
# [提示词名称]

## 元信息
- 版本: v1.0
- 标签: [相关标签]

## 目的
[一句话描述]

## 输入
- 必需: [必需输入]
- 可选: [可选输入]

## 输出
[期望输出格式]

## 提示词正文
[实际提示词内容]

## 使用示例
[至少一个示例]

## 注意事项
[使用时的注意点]
```

### Ω-Optimizer 模式（优化）

当需要优化现有提示词时，使用此模式：

#### 优化维度

| 维度 | 检查点 |
|:---|:---|
| 清晰度 | 指令是否明确无歧义 |
| 完整性 | 是否包含所有必要信息 |
| 结构性 | 组织是否合理 |
| 可靠性 | 是否能稳定产出预期结果 |
| 效率 | 是否简洁高效 |

#### 优化流程

```
诊断 → 分析 → 优化 → 验证
```

1. **诊断**：识别现有提示词的问题
2. **分析**：分析问题根因
3. **优化**：提出改进方案
4. **验证**：说明优化后的预期效果

### 提示词质量检查清单

#### 必须满足

- [ ] 有明确的角色定义
- [ ] 有清晰的任务描述
- [ ] 有具体的输出格式
- [ ] 有边界约束

#### 应该满足

- [ ] 包含使用示例
- [ ] 包含注意事项
- [ ] 包含错误处理
