02d - Prompt 模板库

你是一位有 [N] 年经验的 [语言/框架] 高级工程师。

请审查以下代码，关注：
1. 正确性：是否有逻辑错误或边界条件未处理？
2. 安全性：是否有注入、泄露、认证绕过等风险？
3. 性能：是否有 N+1 查询、不必要的循环、内存泄漏？
4. 可维护性：命名是否清晰？是否符合 [编码规范]？

输出格式：
| # | 严重程度 | 文件:行号 | 问题描述 | 修复建议 |
|---|---------|----------|---------|---------|

严重程度：🔴 必须修复 | 🟡 建议改进 | 🔵 可选优化

如果代码质量良好，回复"✅ LGTM"并说明亮点。

代码：
[粘贴代码]

<role>应用安全工程师，熟悉 OWASP Top 10 和 [语言] 安全最佳实践</role>
 
<task>
对以下代码进行安全审查，重点检查：
- SQL 注入 / NoSQL 注入
- XSS（存储型、反射型、DOM 型）
- 认证和授权缺陷
- 敏感数据暴露
- 不安全的反序列化
- 依赖项已知漏洞
</task>
 
<output_format>
每个发现包含：
- CWE 编号
- 风险等级（Critical / High / Medium / Low）
- 受影响代码位置
- 攻击场景描述
- 修复代码
</output_format>
 
<code>
[代码]
</code>

你是代码审查者。以下是一个 Pull Request 的 diff。

PR 标题：[PR 标题]
PR 描述：[PR 描述]

请审查这个 PR：
1. 变更是否与 PR 描述一致？
2. 是否有遗漏的边界条件？
3. 是否需要添加或更新测试？
4. 是否有破坏性变更？
5. 代码风格是否一致？

输出格式：
## 总体评价
[一句话总结]

## 具体反馈
- [文件名:行号] [反馈内容]

## 建议
- [改进建议]

## 结论
✅ Approve / 🔄 Request Changes / 💬 Comment

Diff：
[粘贴 diff]

我遇到了一个 bug，请帮我诊断。

环境：
- 语言/框架：[如 Python 3.12 / FastAPI 0.115]
- 运行环境：[如 Docker / AWS Lambda]
- 数据库：[如 PostgreSQL 16]

Bug 描述：
- 预期行为：[应该发生什么]
- 实际行为：[实际发生了什么]
- 复现步骤：[1. 2. 3.]
- 频率：[每次 / 偶发 / 特定条件下]

错误日志：
[粘贴错误日志]

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

请：
1. 分析可能的根因（列出 Top 3 可能性，按概率排序）
2. 对最可能的原因给出修复方案
3. 建议添加什么测试来防止回归

请解释以下错误信息，并给出修复方案：

错误信息：
[粘贴完整错误信息/堆栈跟踪]

上下文：
- 项目类型：[如 Next.js 15 应用]
- 触发操作：[如 运行 npm run build]
- 最近的代码变更：[如 升级了 React 版本]

请输出：
1. 错误原因（一句话）
2. 详细解释（为什么会发生）
3. 修复步骤（按优先级排序）
4. 预防措施（如何避免再次发生）

<context>
项目：[项目名称和简述]
团队：[人数和技术栈经验]
时间线：[交付时间]
用户规模：[当前和预期]
技术栈：[当前技术栈]
</context>
 
<task>
设计 [功能/系统] 的技术方案。
</task>
 
<requirements>
1. 提供 2-3 个候选方案
2. 每个方案包含：
   - 架构图（Mermaid 格式）
   - 技术选型和理由
   - 优势和风险
   - 预估工作量
3. 给出推荐方案和理由
4. 列出你的假设
5. 列出需要进一步调研的问题
</requirements>
 
<constraints>
- 总输出不超过 1500 字
- 架构图使用 Mermaid 语法
</constraints>

请为以下架构决策生成 ADR（Architecture Decision Record）。

决策主题：[如 选择消息队列方案]
背景：[为什么需要做这个决策]
候选方案：[如 RabbitMQ vs Kafka vs Redis Streams]
约束条件：[如 预算、团队经验、性能要求]

ADR 格式：
## ADR-[编号]: [标题]
**状态：** Proposed / Accepted / Deprecated
**日期：** [日期]
**决策者：** [角色]

### 背景
[问题描述和驱动因素]

### 决策
[选择了什么方案]

### 候选方案
| 方案 | 优势 | 劣势 | 成本 |
|------|------|------|------|

### 理由
[为什么选择这个方案]

### 后果
[这个决策带来的影响]

### 相关决策
[关联的其他 ADR]

请设计 [系统名称，如"类似 Twitter 的社交平台"]。

功能需求：
- [核心功能 1]
- [核心功能 2]
- [核心功能 3]

非功能需求：
- 日活用户：[数量]
- 读写比：[如 100:1]
- 延迟要求：[如 P99 < 200ms]
- 可用性：[如 99.99%]

请输出：
1. 需求分析和容量估算
2. 高层架构图（Mermaid）
3. 核心组件设计
4. 数据模型设计
5. API 设计（核心端点）
6. 扩展性考虑
7. 潜在瓶颈和解决方案

为以下函数生成单元测试。

测试框架：[如 Jest / Vitest / Pytest]
代码：
[粘贴函数代码]

要求：
1. 覆盖正常路径（至少 3 个用例）
2. 覆盖边界条件（空值、极值、类型边界）
3. 覆盖错误路径（异常输入、超时、权限不足）
4. 测试命名格式：should_[预期行为]_when_[条件]
5. 每个测试包含 Arrange-Act-Assert 注释
6. 不使用 mock，除非测试外部依赖

输出完整的测试文件，可以直接运行。

为以下用户故事生成 E2E 测试场景。

用户故事：
作为 [角色]，我想要 [功能]，以便 [价值]。

验收标准：
- [标准 1]
- [标准 2]
- [标准 3]

测试框架：[如 Playwright / Cypress]

请生成：
1. Happy path 测试（完整流程）
2. 至少 2 个异常路径测试
3. 边界条件测试
4. 每个测试包含清晰的步骤注释

输出可直接运行的测试代码。

分析以下函数/模块，发现适合 Property-Based Testing 的属性。

代码：
[粘贴代码]

请输出：
1. 至少 5 个可测试的属性，格式：
   - 属性名称
   - 属性描述（用"对于所有..."的格式）
   - 输入生成策略
   - 验证逻辑
2. 按测试价值排序（高→低）
3. 推荐的 PBT 框架：[fast-check / Hypothesis / QuickCheck]

示例属性格式：
"对于所有有效的用户输入 x，encode(decode(x)) === x"

为以下 API 端点生成文档。

端点代码：
[粘贴路由/控制器代码]

文档格式（每个端点）：
### [METHOD] [PATH]
**描述：** [一句话说明]
**认证：** [是否需要 / 认证方式]

**请求参数：**
| 参数 | 位置 | 类型 | 必填 | 说明 | 示例 |
|------|------|------|------|------|------|

**请求体：**
```json
{示例 JSON}

curl -X [METHOD] [URL] -H "..." -d '{...}'

### 模板 13：README 生成

**推荐模型：** **C** / G | **Temperature：** 0.3

### 模板 14：变更日志生成

**推荐模型：** C / **G** | **Temperature：** 0.1

---

## 六、重构与优化类

### 模板 15：代码重构建议

**推荐模型：** **C** | **Temperature：** 0.3

```xml
<context>
这段代码已经运行了 [时间]，目前存在以下问题：
- [问题 1，如：函数过长，超过 200 行]
- [问题 2，如：重复代码多]
- [问题 3，如：测试覆盖率低]
</context>

<task>
提供重构方案，要求：
1. 不改变外部行为（纯重构）
2. 分步骤执行，每步可独立验证
3. 每步包含：改动描述、改动代码、验证方法
</task>

<constraints>
- 每步改动不超过 50 行
- 优先处理最高风险的问题
- 保持向后兼容
</constraints>

<code>
[粘贴代码]
</code>

分析以下代码的性能问题。

运行环境：[如 Node.js 22, 4 核 8GB]
当前性能：[如 P50=100ms, P99=800ms, QPS=500]
目标性能：[如 P99<200ms, QPS>2000]

代码：
[粘贴代码]

请输出：
1. 性能瓶颈分析（按影响程度排序）
2. 每个瓶颈的优化方案
3. 预估优化效果
4. 优化的优先级和实施顺序
5. 需要注意的风险（如正确性、可维护性的权衡）

如果需要更多信息（如数据库查询计划、系统指标），请列出。

基于以下产品需求，生成用户故事。

产品：[产品名称和简述]
目标用户：[用户画像]
功能需求：[功能描述]

每个用户故事格式：
**US-[编号]：[标题]**
作为 [角色]，我想要 [功能]，以便 [价值]。

验收标准：
- [ ] [标准 1]
- [ ] [标准 2]
- [ ] [标准 3]

优先级：P0（必须）/ P1（重要）/ P2（可选）
估算：[S/M/L/XL]

要求：
- 生成至少 [N] 个用户故事
- 按优先级排序
- 覆盖正常流程和异常流程
- 验收标准必须可测试

帮我规划下一个 Sprint。

Sprint 信息：
- 时长：[如 2 周]
- 团队容量：[如 8 人 × 8 天 × 6 点/天 = 384 SP]
- 上个 Sprint 速率：[如 完成 320 SP]

待办事项（按优先级）：
1. [任务 1] - 估算 [SP] - 依赖 [无/任务X]
2. [任务 2] - 估算 [SP] - 依赖 [无/任务X]
...

请输出：
1. 推荐纳入本 Sprint 的任务列表
2. 任务执行顺序（考虑依赖关系）
3. 风险评估（哪些任务可能延期）
4. 缓冲建议（预留多少容量应对意外）
5. 如果容量不足，建议哪些任务推迟

为以下项目生成生产级 Dockerfile。

项目信息：
- 语言/框架：[如 Node.js 22 / Next.js 15]
- 包管理器：[如 pnpm]
- 构建命令：[如 pnpm build]
- 启动命令：[如 pnpm start]
- 端口：[如 3000]
- 环境变量：[列出需要的环境变量]

要求：
1. 多阶段构建（builder + runner）
2. 使用 alpine 基础镜像
3. 非 root 用户运行
4. 健康检查
5. .dockerignore 建议
6. 镜像大小优化
7. 安全最佳实践（无敏感信息、最小权限）

输出完整的 Dockerfile 和 .dockerignore，包含注释。

为以下项目生成 [GitHub Actions / GitLab CI] 配置。

项目信息：
- 语言：[如 TypeScript]
- 框架：[如 Next.js]
- 测试框架：[如 Vitest]
- 部署目标：[如 Vercel / AWS]
- 分支策略：[如 main + develop + feature/*]

Pipeline 要求：
1. PR 触发：lint → type-check → test → build
2. main 合并触发：test → build → deploy staging
3. tag 触发：test → build → deploy production
4. 缓存策略（node_modules、构建缓存）
5. 并行执行优化
6. 失败通知（Slack/邮件）
7. 密钥管理（使用 secrets）

输出完整的配置文件，包含注释。

数据库：[如 PostgreSQL 16]

表结构：
[粘贴 CREATE TABLE 语句或 schema 描述]

需求：[用自然语言描述查询需求]

要求：
1. 生成优化的 SQL 查询
2. 添加行内注释解释关键逻辑
3. 说明查询的时间复杂度
4. 建议需要的索引
5. 如果数据量大，提供分页方案
6. 注意 SQL 注入防护（使用参数化查询）

生成数据迁移脚本。

ORM：[如 Prisma / Drizzle / TypeORM]
当前 schema：[粘贴当前 schema]
目标 schema：[粘贴目标 schema 或描述变更]

要求：
1. 生成 up 和 down 迁移
2. 处理数据转换（如果有）
3. 考虑大表迁移的性能（批量处理）
4. 添加安全检查（如非空约束前先填充默认值）
5. 包含回滚方案
6. 添加注释说明每步操作

⚠️ 标注可能导致数据丢失的操作。

请解释 [技术概念]。

目标受众：[如 有 3 年经验的前端开发者]

请按以下结构输出：
1. 一句话定义
2. 为什么重要（解决什么问题）
3. 核心原理（用类比解释）
4. 简单代码示例
5. 实际应用场景（3 个）
6. 常见误解（2 个）
7. 进一步学习资源（3 个链接）

长度：不超过 800 字。

研究问题：[如 "2026 年 React 状态管理方案选型"]

范围：
- 候选方案：[如 Zustand, Jotai, Redux Toolkit, TanStack Store]
- 评估维度：学习曲线、性能、生态、TypeScript 支持、包大小
- 项目背景：[如 中型 SaaS，10 人团队]

输出格式：
1. 对比表格（包含所有维度）
2. 每个方案的一段话评价
3. 基于项目背景的推荐
4. 推荐方案的快速上手示例
5. 标注信息来源和不确定的判断

时间范围：优先引用 2025-2026 年的信息。

你是一个 Prompt 工程师。请为以下任务生成一个高质量的 prompt。

任务描述：[用自然语言描述你想让 AI 做什么]
目标模型：[Claude / GPT / Gemini]
输出要求：[格式、长度、风格]

生成的 prompt 必须包含：
1. 明确的角色设定
2. 清晰的任务描述
3. 输出格式约束
4. 至少 2 个约束条件
5. 错误处理指令（信息不足时怎么办）

请输出：
- 完整的 prompt（可直接使用）
- prompt 设计说明（为什么这样写）
- 建议的 temperature 设置