name	prompt-engineering
description	中文Prompt模板库——20+即用模板涵盖代码审查、架构设计、Bug修复、重构、测试、文档、API设计，附最佳实践
version	2.0.0
author	awesome-dev-skill-pack
license	MIT
metadata	{"hermes":{"tags":["prompt","chinese","template","code-review","api-design","refactoring","testing","debugging","documentation"],"related_skills":["cn-coder","cn-dev-setup"]}}

📝 中文 Prompt 模板库

面向中文开发者的高质量 Prompt 模板集合。每个模板可直接复制使用，通过 {变量名} 替换实际内容。

一、代码审查类

模板 1.1：基础代码审查

你是一位资深的 {编程语言} 代码审查专家。请对我提交的以下代码进行全面的代码审查。

审查重点：
1. 安全性漏洞（SQL注入、XSS、认证绕过等）
2. 性能瓶颈（循环效率、内存泄漏、不必要的计算）
3. 代码规范与风格（是否符合 {团队规范名称} ）
4. 可维护性（命名是否清晰、函数是否过长、是否缺少注释）
5. 边界条件与错误处理（空指针、异常处理是否完备）

请按「严重程度从高到低」输出审查结果。每个问题标注：严重性（Critical/Major/Minor）、所在行号、问题描述、修复建议。

```{编程语言}
{粘贴你的代码}


**变量说明：**
| 变量 | 说明 | 示例 |
|------|------|------|
| `{编程语言}` | 代码语言 | Python、Java、Go |
| `{团队规范名称}` | 团队遵循的风格规范 | Google Style、PEP 8 |
| `{粘贴你的代码}` | 待审查的代码块 | — |

---

### 模板 1.2：安全专项审查

请以安全审计专家的身份审查以下代码。专注于 OWASP Top 10 安全风险。

要求：

标记每一处可能的注入风险（SQL、命令、LDAP等）
检查敏感数据泄露（硬编码密钥、Token、密码）
检查认证与会话管理缺陷
检查文件上传/下载的安全性
指出不安全的反序列化风险

对于每个安全问题，请给出： [风险等级] [风险类型] → [问题描述] → [修复代码示例]

{代码内容}


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{编程语言}` | 代码语言 |
| `{代码内容}` | 待审查的代码 |

---

### 模板 1.3：数据库与SQL审查

请作为数据库管理员审查以下 SQL / ORM 代码。审查维度：

一、性能分析

是否缺少必要的索引（通过 EXPLAIN 分析）
是否存在 N+1 Query 问题
是否使用了 SELECT * 等不必要的字段读取
大表查询是否考虑了分页与批量处理

二、安全性

是否存在 SQL 注入风险（拼接字符串 vs 参数化查询）
是否存在权限越级查询

三、正确性

JOIN 条件是否正确
事务隔离级别是否合理
死锁风险

四、改写建议

对每个有问题的查询给出优化后的版本

{你的SQL语句或ORM代码}


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{你的SQL语句或ORM代码}` | SQL 或 ORM 代码 |

---

### 模板 1.4：Code Review 摘要生成

你是一位资深技术主管。以下是一个 Pull Request 的变更内容。请帮我生成一份 Code Review 总结。

请输出：

变更概述

（用一句话概括本次 PR 做了什么）

关键变更点

（列出 3-5 个最重要的文件和改动点）

需要关注的风险

兼容性风险：
性能风险：
安全风险：

审查结论

Approved（批准合并）
Changes Requested（需修改）
Needs Discussion（需讨论）

修改建议摘要

（如果请求修改，简要列出必须修复项）

PR Diff 内容： {diff内容}


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{diff内容}` | PR 的 diff 或变更文件列表 |

---

## 二、架构设计类

### 模板 2.1：系统架构方案设计

你是一位资深的系统架构师。请根据以下需求输出一份完整的系统架构设计方案。

背景

{业务背景描述}

功能需求

{核心功能列表}

非功能需求

每日预估请求量：{QPS估算}
数据规模：{数据量估算}
可用性要求：{SLA要求}
延迟要求：{延迟要求}

请输出架构方案

请包含以下部分：

整体架构图（用 Mermaid 绘制）
核心组件说明（每个组件的职责、选型理由）
数据流设计（关键业务请求的完整链路）
存储设计（数据库选型、表结构核心设计、缓存策略）
API 设计概览（核心接口列表）
部署方案（服务拓扑、扩缩容策略）
风险与权衡（这个方案做了哪些 trade-off）


**变量说明：**
| 变量 | 说明 | 示例 |
|------|------|------|
| `{业务背景描述}` | 业务场景和问题描述 | "一个面向中小企业的在线文档协作平台" |
| `{核心功能列表}` | 关键功能 | 实时编辑、权限管理、版本历史 |
| `{QPS估算}` | 每秒查询量 | 5000 QPS |
| `{数据量估算}` | 数据规模 | 日均新增 1TB |
| `{SLA要求}` | 可用性 | 99.99% |
| `{延迟要求}` | 延迟 | P99 < 200ms |

---

### 模板 2.2：技术选型评估

请作为技术顾问，帮我评估以下技术方案的选型。需要客观中立的分析。

选型背景

{项目背景和约束条件}

候选方案

{方案A}
{方案B}
{方案C}

评估维度

请从以下维度给出评分（1-5分）和分析：

社区活跃度与生态成熟度
学习曲线与团队上手成本
性能表现（与需求匹配度）
可扩展性与灵活性
运维成本与可观测性
商业许可与成本

输出格式

每个方案给出一个总评表格，然后给出推荐优先级排序。

最后请给出一个「实施建议」段落，说明如果采用推荐方案，需要注意哪些坑。


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{项目背景和约束条件}` | 项目概述和约束 |
| `{方案A/B/C}` | 候选技术方案 |

---

### 模板 2.3：微服务拆分设计

你是一位微服务架构专家。请帮我设计一个微服务拆分方案。

现有系统

{现有单体应用描述}

拆分的业务驱动力

{拆分的原因和目标}

要求

给出推荐的微服务划分，每个服务描述其业务边界与职责
画出服务间依赖关系图（Mermaid）
定义服务间通信方式（同步/异步），说明理由
设计领域事件列表
分析拆分后的数据一致性挑战及对策（Saga / Eventual Consistency）
给出分阶段迁移路线图（Phase 1 → Phase N）

约束

团队规模：{团队人数}人
技术栈：{技术栈}
时间线：{时间要求}


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{现有单体应用描述}` | 当前系统描述 |
| `{拆分的原因和目标}` | 商业/技术驱动力 |
| `{团队人数}` | 团队规模 |
| `{技术栈}` | 技术栈 |
| `{时间要求}` | 时间线 |

---

## 三、Bug 修复类

### 模板 3.1：代码 Debug

我遇到了一个 Bug，请帮我分析和修复。

环境信息

编程语言/框架：{语言/框架}
运行环境：{OS和版本}
依赖版本：{关键依赖及其版本}

Bug 描述

{Bug的现象描述}

复现步骤

{步骤1}
{步骤2}
{步骤3}

期望行为

{期望输出或行为}

实际行为

{实际输出或行为}

错误日志/堆栈

{错误栈或日志}

已尝试的解决方案

{已经尝试过的排查方向}


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{语言/框架}` | 如 Python 3.11、Spring Boot 3.2 |
| `{OS和版本}` | 如 Ubuntu 22.04、macOS 14 |
| `{关键依赖及其版本}` | 如 Redis 7.0、MySQL 8.0 |
| `{Bug的现象描述}` | 详细描述 BUG |
| `{步骤1/2/3}` | 复现步骤 |
| `{期望输出或行为}` | 期望结果 |
| `{实际输出或行为}` | 实际结果 |
| `{错误栈或日志}` | 错误信息 |
| `{相关代码片段}` | 相关代码 |
| `{已尝试过的解决方案}` | 已尝试的调试方法 |

---

### 模板 3.2：异常日志分析

你是一位经验丰富的运维开发工程师。以下是一段生成环境中的异常日志。请你分析并定位根因。

服务信息

服务名称：{服务名称}
时间范围：{时间范围}
平均请求量变化：{请求量趋势}

异常日志

{paste日志内容}

请分析

根因分析：最可能的原因是什么？请说明推理过程
影响范围：影响的用户量、功能范围
临时解决方案：如何快速止血
永久修复方案：完整修复建议
监控建议：如何提前发现此类问题


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{服务名称}` | 服务名 |
| `{时间范围}` | 如 2026-04-29 13:00~13:30 |
| `{请求量趋势}` | 如 QPS 从 100 骤降至 5 |
| `{paste日志内容}` | 日志内容 |

---

### 模板 3.3：运行时性能问题排查

我有一个性能问题需要排查。请作为性能优化专家帮我分析。

问题现象

{性能问题的表现}

配置信息

硬件：{CPU/内存/网络}
配置参数：{关键配置}

性能数据

CPU 使用率：{数据}
内存使用率：{数据}
磁盘 IO：{数据}
网络 IO：{数据}
GC 日志：{如果有}
慢查询：{如果有}
APM Trace：{如果有}

分析与建议

请按以下结构输出：

根因诊断（最可能的瓶颈位置）
排查方法（如何进一步确认）
优化建议（代码层面、配置层面、架构层面）
预期效果（优化后性能提升预估）


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{性能问题的表现}` | 如 "接口 P99 延迟从 50ms 上升到 2s" |
| `{CPU/内存/网络}` | 配置详情 |
| `{关键配置}` | 如 JVM -Xms -Xmx、MySQL innodb_buffer_pool_size |

---

## 四、重构类

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

请作为代码重构专家，审视以下代码，给出重构建议。

重构目标

原始代码

{待重构的代码}

约束条件

不能改变现有公共 API 签名
保持向后兼容
{其他约束}

请输出

问题诊断：当前代码存在哪些问题（列出 3-5 点）
重构方案：给出重构后的代码
改动说明：解释每项改动的理由
风险提示：重构后可能引入的风险及回退方案


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{编程语言}` | 代码语言 |
| `{待重构的代码}` | 待重构代码 |
| `{其他约束}` | 约束条件 |

---

### 模板 4.2：大函数拆分

以下函数过于庞大（超过 {行数} 行），请帮我将其拆分为多个职责清晰的小函数。

原始函数

{超大函数代码}

输出要求

分析该函数的多个职责（说清楚它做了什么不同的事情）
给出拆分后的多个函数，每个函数遵循单一职责原则
说明每个函数的输入输出
展示重构后的调用关系
保持总逻辑不变

额外要求

拆分后的每个函数不超过 {目标行数} 行
函数命名要能清晰表达其职责
必要时使用内部类或模块化组织


**变量说明：**
| 变量 | 说明 | 示例 |
|------|------|------|
| `{行数}` | 触发拆分的阈值 | 100 |
| `{编程语言}` | 代码语言 | JavaScript |
| `{超大函数代码}` | 大函数源码 | — |
| `{目标行数}` | 拆分后每函数最大行数 | 20 |

---

### 模板 4.3：设计模式重构

以下代码存在设计不合理的问题。请使用 {设计模式名称} 设计模式进行重构。

当前代码分析

{当前代码}

当前代码的问题

{列举当前代码在设计上的问题}

重构要求

应用 {设计模式名称} 模式
保留原有功能不变
给出重构后的完整代码
画出类图（可用 Mermaid）
解释模式如何解决原有问题
指出该模式的潜在劣势（trade-off）

可选模式（如果没有指定，请推荐最合适的）

策略模式（Strategy Pattern）
观察者模式（Observer Pattern）
工厂模式（Factory Pattern）
装饰器模式（Decorator Pattern）
责任链模式（Chain of Responsibility Pattern）


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{设计模式名称}` | 目标设计模式（可选） |
| `{编程语言}` | 代码语言 |
| `{当前代码}` | 待重构代码 |
| `{列举当前代码在设计上的问题}` | 设计问题描述 |

---

## 五、测试编写类

### 模板 5.1：单元测试生成

请根据以下代码，生成完整的单元测试。

代码文件

{待测代码}

测试框架

{测试框架名称}

Mock 工具

{Mock工具名称}

测试要求

覆盖率目标：{覆盖率}%
包含以下测试类型：
- 正常路径测试（Happy Path）
- 边界条件测试（Edge Cases）
- 异常路径测试（Error Handling）
每个测试用例包含：
- 测试名称
- 测试输入
- 期望输出
- 测试说明（为什么这个 case 重要）

额外约束

{额外约束条件，如：不能改变被测试代码}


**变量说明：**
| 变量 | 说明 | 示例 |
|------|------|------|
| `{编程语言}` | 代码语言 | Python |
| `{待测代码}` | 被测源码 | — |
| `{测试框架名称}` | 测试框架 | pytest、JUnit 5 |
| `{Mock工具名称}` | Mock 工具 | unittest.mock、Mockito |
| `{覆盖率}` | 目标覆盖率 | 90 |
| `{额外约束条件}` | 其他约束 | — |

---

### 模板 5.2：集成测试编写

请为以下 API 编写集成测试。

API 描述

{接口说明}

请求示例

{HTTP请求示例}

响应示例

{预期响应JSON}

测试场景

正常请求-响应路径
参数验证（缺失必填字段、非法值类型、越界值）
认证鉴权（无 Token、过期 Token、无权访问）
并发场景（同一资源并发读写）
幂等性验证（重复请求结果一致）

技术栈

测试框架：{测试框架}
HTTP 客户端：{HTTP客户端}
数据准备：{数据准备方式}

输出要求

完整的测试代码，包含 setup/teardown、 fixture、断言。


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{接口说明}` | API 描述 |
| `{HTTP请求示例}` | HTTP 请求 |
| `{预期响应JSON}` | 预期响应 |
| `{测试框架}` | 如 pytest、JUnit |
| `{HTTP客户端}` | 如 requests、RestTemplate |
| `{数据准备方式}` | 如 Docker Compose、Testcontainers |

---

### 模板 5.3：测试覆盖率补全

请分析现有测试覆盖率报告，补充缺失的测试用例。

被测试代码

{待测代码}

现有测试

{现有测试代码}

覆盖率报告（缺失部分）

{覆盖率报告或缺失的分支/行号}

补充要求

找出未被覆盖的分支和路径
编写缺失的测试用例
每个新测试标注它覆盖了哪个分支/条件
如果某些分支「无法测试」（如需要特定硬件），请标注并说明原因

期望输出

覆盖率不足的分析列表
新增测试代码
补充后的预估覆盖率


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{编程语言}` | 代码语言 |
| `{待测代码}` | 被测源码 |
| `{现有测试代码}` | 现有测试代码 |
| `{覆盖率报告或缺失的分支/行号}` | 覆盖率报告 |

---

## 六、文档编写类

### 模板 6.1：API 文档生成

请根据以下代码/接口定义，生成完整的 API 文档。

接口源材料

{接口定义代码或Swagger/OpenAPI描述}

输出格式

{Markdown / OpenAPI 3.0 / 内部Wiki格式}

文档要求（遵循 OpenAPI 规范）

接口概述：接口用途描述
URL 路径和 HTTP 方法
请求参数（Path、Query、Header、Body）
请求示例（curl / HTTP）
响应格式与状态码（200、4xx、5xx）
响应示例
错误码表格
限流规则与认证方式

额外要求

对每个参数标明「必填/可选」、类型、取值范围、默认值
响应示例要包含成功和失败两种情况


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{编程语言/格式}` | 如 Java、Python、OpenAPI YAML |
| `{接口定义代码或Swagger/OpenAPI描述}` | 接口源码 |
| `{Markdown / OpenAPI 3.0 / 内部Wiki格式}` | 输出格式 |

---

### 模板 6.2：README / Wiki 编写

请帮我为以下项目编写 README 文档。

项目信息

项目名称：{项目名称}
项目简介（一句话）：{一句话介绍}
技术栈：{技术栈}
目标用户：{目标用户}

功能列表

{功能列表}

目录结构说明

{项目目录结构}

要求 README 包含以下章节

🏷️ Project Title & Badge
- 项目名称、徽章（CI、License、版本号）
📖 简介
- 项目背景、解决什么问题
✨ 功能特性
- 列出关键特性，每个带图标
🚀 快速开始
- 环境要求、安装步骤、运行命令
📚 使用指南
- 常用操作示例
🔧 配置
- 环境变量、配置项说明
🏗️ 项目架构
- 简要说明模块结构
🤝 贡献指南
📄 许可证

风格要求

{中文 / 中英双语 / 英文}


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{项目名称}` | 项目名称 |
| `{一句话介绍}` | 一句话简介 |
| `{技术栈}` | 技术栈 |
| `{目标用户}` | 用户群体 |
| `{功能列表}` | 功能点 |
| `{项目目录结构}` | 目录树 |

---

### 模板 6.3：技术方案/设计文档

请帮我把以下讨论整理成一份结构化的技术方案文档。

原始讨论/笔记

{原始的讨论或笔记}

文档结构要求

背景与目标
- 为什么要做这件事
- 成功标准是什么
方案对比
- 列出候选方案（至少 2 个）
- 每个方案的优缺点
- 推荐方案及理由
详细设计
- 核心流程（Mermaid 流程图）
- 数据模型设计
- 接口设计
- 关键实现细节
兼容性与迁移
- 对现有系统的影响
- 迁移/灰度方案
风险与应对

风格

正式、专业的中文技术文档风格
使用清晰的二级/三级标题
重要结论用「粗体」标注


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{原始的讨论或笔记}` | 零散讨论内容 |

---

## 七、API 设计类

### 模板 7.1：RESTful API 设计

请作为 API 设计师，根据以下需求设计 RESTful API。

业务背景

{业务背景}

核心资源

{资源列表，如用户、订单、商品}

功能需求

{功能需求1}
{功能需求2}
{功能需求3}

设计约束

API 版本策略：{版本策略}
认证方式：{OAuth 2.0 / JWT / API Key}
响应格式：{JSON / Protocol Buffers}
命名风格：{snake_case / camelCase}

输出要求

资源模型设计：核心资源的字段、关系
API 端点设计：每个资源的标准 CRUD + 自定义操作
请求/响应示例：每个端点给出示例
错误处理规范：统一的错误响应结构、HTTP 状态码使用规范
分页/排序/过滤：统一规范
API 变更策略：如何兼容旧版本


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{业务背景}` | 业务描述 |
| `{资源列表}` | 核心资源 | 
| `{功能需求1/2/3}` | 具体功能 |
| `{版本策略}` | 如 URL Path Versioning |
| `{OAuth 2.0 / JWT / API Key}` | 认证方式 |

---

### 模板 7.2：GraphQL Schema 设计

请根据以下需求设计 GraphQL Schema。

业务领域

{业务领域描述}

核心实体和关系

{实体列表及关系}

数据查询需求

{常见查询场景}

数据变更需求

{常见变更场景}

输出要求

Type Definitions：完整的 GraphQL Schema（SDL 格式）
Query 设计：满足所有查询需求
Mutation 设计：满足所有变更需求
Subscription 设计（如果适用）：实时推送需求
N+1 问题分析：哪些查询可能存在 N+1，如何通过 DataLoader 解决
权限设计：如何通过 GraphQL Directive 或 Middleware 实现权限控制

约束

遵循 Relay Connection 规范：{是/否}
需要支持 Federation：{是/否}


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{业务领域描述}` | 业务领域 |
| `{实体列表及关系}` | 实体与关系 |
| `{常见查询场景}` | 查询场景 |
| `{常见变更场景}` | 变更场景 |

---

### 模板 7.3：API 错误码与异常设计

请为以下系统的 API 设计一套完整的错误码体系和异常处理规范。

系统/服务名称

{系统名称}

已有错误码（如果有）

{已有的错误码列表}

请输出

错误码分类
- 客户端错误（4xx）：参数校验、鉴权、资源不存在等
- 服务端错误（5xx）：内部错误、超时、熔断等
- 业务错误（自定义码）：如余额不足、库存不足等

错误响应结构

{
  "code": "ERROR_CODE",
  "message": "用户可读的错误描述",
  "detail": "详细的调试信息（仅内部环境）",
  "request_id": "用于追踪的UUID"
}

HTTP 状态码映射策略
- 哪些情况用 400 vs 422 vs 409
- 哪些情况用 403 vs 401
全局异常处理方案
- 框架层面的全局异常拦截器配置
- 日志记录规范
错误码枚举定义
- 以 {编程语言} 枚举/常量形式给出


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{系统名称}` | 系统名 |
| `{已有的错误码列表}` | 已有的错误码 |
| `{编程语言}` | 枚举定义语言 |

---

## 八、中文 Prompt 最佳实践

### 8.1 结构化原则

好 Prompt 的结构 = 角色定义 + 上下文 + 任务描述 + 输出格式 + 约束条件

示例框架（CO-STAR 的中文适配版）： ┌─────────────────────────────────────┐ │ 【角色】你是一位资深{领域}专家 │ │ 【背景】{当前场景说明} │ │ 【任务】{具体要求} │ │ 【格式】请按以下结构输出：{格式说明} │ │ 【约束】{限制条件} │ └─────────────────────────────────────┘


### 8.2 用中文写 Prompt 的关键技巧

| 技巧 | 说明 | 错误写法 | 正确写法 |
|------|------|----------|----------|
| **提供示例** | Few-shot 样例比抽象描述更有效 | "生成一个合理的API" | "参考以下示例风格：\{示例\}" |
| **明确输出长度** | 中文 token 消耗不同于英文 | "简短说明" | "请用不超过 500 字说明" |
| **使用编号** | 结构化需求更易被理解 | "要安全也要高性能" | "1.安全性... 2.性能..." |
| **负面排除** | 明确告诉 AI 不该做什么 | "优化代码" | "优化代码。不要删减注释，不要修改公共 API 签名" |
| **指定角色** | 角色设定让 AI 调用领域知识 | "审查这段代码" | "你是一位有10年经验的 Go 语言后端工程师" |
| **步骤分解** | 复杂任务拆成多步 | "设计这个系统" | "第一步：确认需求；第二步：画出架构；第三步：详细设计" |
| **自我修正** | 让 AI 自己检查输出 | | "输出后请检查是否符合所有要求，如有遗漏请补充" |

### 8.3 常见陷阱与规避

1. **模糊的代词**
   - ❌ "检查它是否正确" — "它"指代不清
   - ✅ "检查上述代码中第 15-30 行的排序算法是否正确"

2. **过度抽象的描述**
   - ❌ "优化性能"
   - ✅ "将接口响应时间降低到 200ms 以下。当前为 800ms，主要瓶颈在数据库查询"

3. **一个 prompt 塞太多任务**
   - ❌ "帮我审查代码、写测试、重构、还要部署"
   - ✅ 分多个 prompt 逐步推进，每个聚焦一个目标

4. **不给出格式示范**
   - ❌ "输出审查结果"
   - ✅ "请按这个格式输出：\n【严重性】|【问题位置】|【问题描述】|【修复建议】"

### 8.4 迭代式 Prompt 工作流

对于复杂任务，推荐分多轮对话完成：

轮次1：【角色 + 任务定义】 → "你是一位{角色}。我要{任务}，确认你理解了需求。"

轮次2：【输出初稿】 → "好的，请开始输出。"

轮次3：【细化/修正】 → "第{章节}需要补充{细节}。第{章节}的表述改为{要求}。"

轮次4：【最终检查】 → "请检查是否符合所有要求，列出每个要求的满足状态。"


### 8.5 针对不同 AI 模型的调参建议

| 模型类型 | Prompt 风格建议 | Temperature | 说明 |
|----------|---------------|-------------|------|
| GPT-4 / Claude 3 | 详细结构化的中文 Prompt | 0.1-0.3 | 代码和结构化输出时降低温度 |
| DeepSeek / Qwen | 直接清晰的中文指令 | 0.3-0.5 | 对中文理解力强，可适当简化 |
| 代码生成场景 | 示例驱动 + 约束优先 | 0.0-0.2 | 减少随机性，保证一致性 |
| 创意/设计场景 | 开放式引导 | 0.5-0.8 | 适当温度获取多样化方案 |

---

## 附录：模板快速索引卡

┌──────────────────────────────────────────────────────────┐ │ 分类 │ 模板编号 │ 用途 │ ├──────────────────────────────────────────────────────────┤ │ 代码审查 │ 1.1-1.4 │ Code Review、安全审计、SQL审查 │ │ 架构设计 │ 2.1-2.3 │ 系统设计、技术选型、微服务拆分 │ │ Bug修复 │ 3.1-3.3 │ Debug、日志分析、性能诊断 │ │ 重构 │ 4.1-4.3 │ 代码重构、大函数拆分、设计模式 │ │ 测试 │ 5.1-5.3 │ 单元测试、集成测试、补全覆盖 │ │ 文档 │ 6.1-6.3 │ API文档、README、技术方案 │ │ API设计 │ 7.1-7.3 │ RESTful、GraphQL、错误码设计 │ └──────────────────────────────────────────────────────────┘


> **使用建议**：初次使用请从模板复制后，补充具体的 `{变量}` 值。多次使用后可根据自身团队的习惯，将常用模板固化为团队内部的标准 Prompt 模板库。

name	prompt-engineering
description	中文Prompt模板库——20+即用模板涵盖代码审查、架构设计、Bug修复、重构、测试、文档、API设计，附最佳实践
version	2.0.0
author	awesome-dev-skill-pack
license	MIT
metadata	{"hermes":{"tags":["prompt","chinese","template","code-review","api-design","refactoring","testing","debugging","documentation"],"related_skills":["cn-coder","cn-dev-setup"]}}

📝 中文 Prompt 模板库

面向中文开发者的高质量 Prompt 模板集合。每个模板可直接复制使用，通过 {变量名} 替换实际内容。

一、代码审查类

模板 1.1：基础代码审查

你是一位资深的 {编程语言} 代码审查专家。请对我提交的以下代码进行全面的代码审查。

审查重点：
1. 安全性漏洞（SQL注入、XSS、认证绕过等）
2. 性能瓶颈（循环效率、内存泄漏、不必要的计算）
3. 代码规范与风格（是否符合 {团队规范名称} ）
4. 可维护性（命名是否清晰、函数是否过长、是否缺少注释）
5. 边界条件与错误处理（空指针、异常处理是否完备）

请按「严重程度从高到低」输出审查结果。每个问题标注：严重性（Critical/Major/Minor）、所在行号、问题描述、修复建议。

```{编程语言}
{粘贴你的代码}


**变量说明：**
| 变量 | 说明 | 示例 |
|------|------|------|
| `{编程语言}` | 代码语言 | Python、Java、Go |
| `{团队规范名称}` | 团队遵循的风格规范 | Google Style、PEP 8 |
| `{粘贴你的代码}` | 待审查的代码块 | — |

---

### 模板 1.2：安全专项审查

请以安全审计专家的身份审查以下代码。专注于 OWASP Top 10 安全风险。

要求：

标记每一处可能的注入风险（SQL、命令、LDAP等）
检查敏感数据泄露（硬编码密钥、Token、密码）
检查认证与会话管理缺陷
检查文件上传/下载的安全性
指出不安全的反序列化风险

对于每个安全问题，请给出： [风险等级] [风险类型] → [问题描述] → [修复代码示例]

{代码内容}


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{编程语言}` | 代码语言 |
| `{代码内容}` | 待审查的代码 |

---

### 模板 1.3：数据库与SQL审查

请作为数据库管理员审查以下 SQL / ORM 代码。审查维度：

一、性能分析

是否缺少必要的索引（通过 EXPLAIN 分析）
是否存在 N+1 Query 问题
是否使用了 SELECT * 等不必要的字段读取
大表查询是否考虑了分页与批量处理

二、安全性

是否存在 SQL 注入风险（拼接字符串 vs 参数化查询）
是否存在权限越级查询

三、正确性

JOIN 条件是否正确
事务隔离级别是否合理
死锁风险

四、改写建议

对每个有问题的查询给出优化后的版本

{你的SQL语句或ORM代码}


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{你的SQL语句或ORM代码}` | SQL 或 ORM 代码 |

---

### 模板 1.4：Code Review 摘要生成

你是一位资深技术主管。以下是一个 Pull Request 的变更内容。请帮我生成一份 Code Review 总结。

请输出：

变更概述

（用一句话概括本次 PR 做了什么）

关键变更点

（列出 3-5 个最重要的文件和改动点）

需要关注的风险

兼容性风险：
性能风险：
安全风险：

审查结论

Approved（批准合并）
Changes Requested（需修改）
Needs Discussion（需讨论）

修改建议摘要

（如果请求修改，简要列出必须修复项）

PR Diff 内容： {diff内容}


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{diff内容}` | PR 的 diff 或变更文件列表 |

---

## 二、架构设计类

### 模板 2.1：系统架构方案设计

你是一位资深的系统架构师。请根据以下需求输出一份完整的系统架构设计方案。

背景

{业务背景描述}

功能需求

{核心功能列表}

非功能需求

每日预估请求量：{QPS估算}
数据规模：{数据量估算}
可用性要求：{SLA要求}
延迟要求：{延迟要求}

请输出架构方案

请包含以下部分：

整体架构图（用 Mermaid 绘制）
核心组件说明（每个组件的职责、选型理由）
数据流设计（关键业务请求的完整链路）
存储设计（数据库选型、表结构核心设计、缓存策略）
API 设计概览（核心接口列表）
部署方案（服务拓扑、扩缩容策略）
风险与权衡（这个方案做了哪些 trade-off）


**变量说明：**
| 变量 | 说明 | 示例 |
|------|------|------|
| `{业务背景描述}` | 业务场景和问题描述 | "一个面向中小企业的在线文档协作平台" |
| `{核心功能列表}` | 关键功能 | 实时编辑、权限管理、版本历史 |
| `{QPS估算}` | 每秒查询量 | 5000 QPS |
| `{数据量估算}` | 数据规模 | 日均新增 1TB |
| `{SLA要求}` | 可用性 | 99.99% |
| `{延迟要求}` | 延迟 | P99 < 200ms |

---

### 模板 2.2：技术选型评估

请作为技术顾问，帮我评估以下技术方案的选型。需要客观中立的分析。

选型背景

{项目背景和约束条件}

候选方案

{方案A}
{方案B}
{方案C}

评估维度

请从以下维度给出评分（1-5分）和分析：

社区活跃度与生态成熟度
学习曲线与团队上手成本
性能表现（与需求匹配度）
可扩展性与灵活性
运维成本与可观测性
商业许可与成本

输出格式

每个方案给出一个总评表格，然后给出推荐优先级排序。

最后请给出一个「实施建议」段落，说明如果采用推荐方案，需要注意哪些坑。


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{项目背景和约束条件}` | 项目概述和约束 |
| `{方案A/B/C}` | 候选技术方案 |

---

### 模板 2.3：微服务拆分设计

你是一位微服务架构专家。请帮我设计一个微服务拆分方案。

现有系统

{现有单体应用描述}

拆分的业务驱动力

{拆分的原因和目标}

要求

给出推荐的微服务划分，每个服务描述其业务边界与职责
画出服务间依赖关系图（Mermaid）
定义服务间通信方式（同步/异步），说明理由
设计领域事件列表
分析拆分后的数据一致性挑战及对策（Saga / Eventual Consistency）
给出分阶段迁移路线图（Phase 1 → Phase N）

约束

团队规模：{团队人数}人
技术栈：{技术栈}
时间线：{时间要求}


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{现有单体应用描述}` | 当前系统描述 |
| `{拆分的原因和目标}` | 商业/技术驱动力 |
| `{团队人数}` | 团队规模 |
| `{技术栈}` | 技术栈 |
| `{时间要求}` | 时间线 |

---

## 三、Bug 修复类

### 模板 3.1：代码 Debug

我遇到了一个 Bug，请帮我分析和修复。

环境信息

编程语言/框架：{语言/框架}
运行环境：{OS和版本}
依赖版本：{关键依赖及其版本}

Bug 描述

{Bug的现象描述}

复现步骤

{步骤1}
{步骤2}
{步骤3}

期望行为

{期望输出或行为}

实际行为

{实际输出或行为}

错误日志/堆栈

{错误栈或日志}

已尝试的解决方案

{已经尝试过的排查方向}


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{语言/框架}` | 如 Python 3.11、Spring Boot 3.2 |
| `{OS和版本}` | 如 Ubuntu 22.04、macOS 14 |
| `{关键依赖及其版本}` | 如 Redis 7.0、MySQL 8.0 |
| `{Bug的现象描述}` | 详细描述 BUG |
| `{步骤1/2/3}` | 复现步骤 |
| `{期望输出或行为}` | 期望结果 |
| `{实际输出或行为}` | 实际结果 |
| `{错误栈或日志}` | 错误信息 |
| `{相关代码片段}` | 相关代码 |
| `{已尝试过的解决方案}` | 已尝试的调试方法 |

---

### 模板 3.2：异常日志分析

你是一位经验丰富的运维开发工程师。以下是一段生成环境中的异常日志。请你分析并定位根因。

服务信息

服务名称：{服务名称}
时间范围：{时间范围}
平均请求量变化：{请求量趋势}

异常日志

{paste日志内容}

请分析

根因分析：最可能的原因是什么？请说明推理过程
影响范围：影响的用户量、功能范围
临时解决方案：如何快速止血
永久修复方案：完整修复建议
监控建议：如何提前发现此类问题


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{服务名称}` | 服务名 |
| `{时间范围}` | 如 2026-04-29 13:00~13:30 |
| `{请求量趋势}` | 如 QPS 从 100 骤降至 5 |
| `{paste日志内容}` | 日志内容 |

---

### 模板 3.3：运行时性能问题排查

我有一个性能问题需要排查。请作为性能优化专家帮我分析。

问题现象

{性能问题的表现}

配置信息

硬件：{CPU/内存/网络}
配置参数：{关键配置}

性能数据

CPU 使用率：{数据}
内存使用率：{数据}
磁盘 IO：{数据}
网络 IO：{数据}
GC 日志：{如果有}
慢查询：{如果有}
APM Trace：{如果有}

分析与建议

请按以下结构输出：

根因诊断（最可能的瓶颈位置）
排查方法（如何进一步确认）
优化建议（代码层面、配置层面、架构层面）
预期效果（优化后性能提升预估）


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{性能问题的表现}` | 如 "接口 P99 延迟从 50ms 上升到 2s" |
| `{CPU/内存/网络}` | 配置详情 |
| `{关键配置}` | 如 JVM -Xms -Xmx、MySQL innodb_buffer_pool_size |

---

## 四、重构类

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

请作为代码重构专家，审视以下代码，给出重构建议。

重构目标

原始代码

{待重构的代码}

约束条件

不能改变现有公共 API 签名
保持向后兼容
{其他约束}

请输出

问题诊断：当前代码存在哪些问题（列出 3-5 点）
重构方案：给出重构后的代码
改动说明：解释每项改动的理由
风险提示：重构后可能引入的风险及回退方案


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{编程语言}` | 代码语言 |
| `{待重构的代码}` | 待重构代码 |
| `{其他约束}` | 约束条件 |

---

### 模板 4.2：大函数拆分

以下函数过于庞大（超过 {行数} 行），请帮我将其拆分为多个职责清晰的小函数。

原始函数

{超大函数代码}

输出要求

分析该函数的多个职责（说清楚它做了什么不同的事情）
给出拆分后的多个函数，每个函数遵循单一职责原则
说明每个函数的输入输出
展示重构后的调用关系
保持总逻辑不变

额外要求

拆分后的每个函数不超过 {目标行数} 行
函数命名要能清晰表达其职责
必要时使用内部类或模块化组织


**变量说明：**
| 变量 | 说明 | 示例 |
|------|------|------|
| `{行数}` | 触发拆分的阈值 | 100 |
| `{编程语言}` | 代码语言 | JavaScript |
| `{超大函数代码}` | 大函数源码 | — |
| `{目标行数}` | 拆分后每函数最大行数 | 20 |

---

### 模板 4.3：设计模式重构

以下代码存在设计不合理的问题。请使用 {设计模式名称} 设计模式进行重构。

当前代码分析

{当前代码}

当前代码的问题

{列举当前代码在设计上的问题}

重构要求

应用 {设计模式名称} 模式
保留原有功能不变
给出重构后的完整代码
画出类图（可用 Mermaid）
解释模式如何解决原有问题
指出该模式的潜在劣势（trade-off）

可选模式（如果没有指定，请推荐最合适的）

策略模式（Strategy Pattern）
观察者模式（Observer Pattern）
工厂模式（Factory Pattern）
装饰器模式（Decorator Pattern）
责任链模式（Chain of Responsibility Pattern）


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{设计模式名称}` | 目标设计模式（可选） |
| `{编程语言}` | 代码语言 |
| `{当前代码}` | 待重构代码 |
| `{列举当前代码在设计上的问题}` | 设计问题描述 |

---

## 五、测试编写类

### 模板 5.1：单元测试生成

请根据以下代码，生成完整的单元测试。

代码文件

{待测代码}

测试框架

{测试框架名称}

Mock 工具

{Mock工具名称}

测试要求

覆盖率目标：{覆盖率}%
包含以下测试类型：
- 正常路径测试（Happy Path）
- 边界条件测试（Edge Cases）
- 异常路径测试（Error Handling）
每个测试用例包含：
- 测试名称
- 测试输入
- 期望输出
- 测试说明（为什么这个 case 重要）

额外约束

{额外约束条件，如：不能改变被测试代码}


**变量说明：**
| 变量 | 说明 | 示例 |
|------|------|------|
| `{编程语言}` | 代码语言 | Python |
| `{待测代码}` | 被测源码 | — |
| `{测试框架名称}` | 测试框架 | pytest、JUnit 5 |
| `{Mock工具名称}` | Mock 工具 | unittest.mock、Mockito |
| `{覆盖率}` | 目标覆盖率 | 90 |
| `{额外约束条件}` | 其他约束 | — |

---

### 模板 5.2：集成测试编写

请为以下 API 编写集成测试。

API 描述

{接口说明}

请求示例

{HTTP请求示例}

响应示例

{预期响应JSON}

测试场景

正常请求-响应路径
参数验证（缺失必填字段、非法值类型、越界值）
认证鉴权（无 Token、过期 Token、无权访问）
并发场景（同一资源并发读写）
幂等性验证（重复请求结果一致）

技术栈

测试框架：{测试框架}
HTTP 客户端：{HTTP客户端}
数据准备：{数据准备方式}

输出要求

完整的测试代码，包含 setup/teardown、 fixture、断言。


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{接口说明}` | API 描述 |
| `{HTTP请求示例}` | HTTP 请求 |
| `{预期响应JSON}` | 预期响应 |
| `{测试框架}` | 如 pytest、JUnit |
| `{HTTP客户端}` | 如 requests、RestTemplate |
| `{数据准备方式}` | 如 Docker Compose、Testcontainers |

---

### 模板 5.3：测试覆盖率补全

请分析现有测试覆盖率报告，补充缺失的测试用例。

被测试代码

{待测代码}

现有测试

{现有测试代码}

覆盖率报告（缺失部分）

{覆盖率报告或缺失的分支/行号}

补充要求

找出未被覆盖的分支和路径
编写缺失的测试用例
每个新测试标注它覆盖了哪个分支/条件
如果某些分支「无法测试」（如需要特定硬件），请标注并说明原因

期望输出

覆盖率不足的分析列表
新增测试代码
补充后的预估覆盖率


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{编程语言}` | 代码语言 |
| `{待测代码}` | 被测源码 |
| `{现有测试代码}` | 现有测试代码 |
| `{覆盖率报告或缺失的分支/行号}` | 覆盖率报告 |

---

## 六、文档编写类

### 模板 6.1：API 文档生成

请根据以下代码/接口定义，生成完整的 API 文档。

接口源材料

{接口定义代码或Swagger/OpenAPI描述}

输出格式

{Markdown / OpenAPI 3.0 / 内部Wiki格式}

文档要求（遵循 OpenAPI 规范）

接口概述：接口用途描述
URL 路径和 HTTP 方法
请求参数（Path、Query、Header、Body）
请求示例（curl / HTTP）
响应格式与状态码（200、4xx、5xx）
响应示例
错误码表格
限流规则与认证方式

额外要求

对每个参数标明「必填/可选」、类型、取值范围、默认值
响应示例要包含成功和失败两种情况


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{编程语言/格式}` | 如 Java、Python、OpenAPI YAML |
| `{接口定义代码或Swagger/OpenAPI描述}` | 接口源码 |
| `{Markdown / OpenAPI 3.0 / 内部Wiki格式}` | 输出格式 |

---

### 模板 6.2：README / Wiki 编写

请帮我为以下项目编写 README 文档。

项目信息

项目名称：{项目名称}
项目简介（一句话）：{一句话介绍}
技术栈：{技术栈}
目标用户：{目标用户}

功能列表

{功能列表}

目录结构说明

{项目目录结构}

要求 README 包含以下章节

🏷️ Project Title & Badge
- 项目名称、徽章（CI、License、版本号）
📖 简介
- 项目背景、解决什么问题
✨ 功能特性
- 列出关键特性，每个带图标
🚀 快速开始
- 环境要求、安装步骤、运行命令
📚 使用指南
- 常用操作示例
🔧 配置
- 环境变量、配置项说明
🏗️ 项目架构
- 简要说明模块结构
🤝 贡献指南
📄 许可证

风格要求

{中文 / 中英双语 / 英文}


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{项目名称}` | 项目名称 |
| `{一句话介绍}` | 一句话简介 |
| `{技术栈}` | 技术栈 |
| `{目标用户}` | 用户群体 |
| `{功能列表}` | 功能点 |
| `{项目目录结构}` | 目录树 |

---

### 模板 6.3：技术方案/设计文档

请帮我把以下讨论整理成一份结构化的技术方案文档。

原始讨论/笔记

{原始的讨论或笔记}

文档结构要求

背景与目标
- 为什么要做这件事
- 成功标准是什么
方案对比
- 列出候选方案（至少 2 个）
- 每个方案的优缺点
- 推荐方案及理由
详细设计
- 核心流程（Mermaid 流程图）
- 数据模型设计
- 接口设计
- 关键实现细节
兼容性与迁移
- 对现有系统的影响
- 迁移/灰度方案
风险与应对

风格

正式、专业的中文技术文档风格
使用清晰的二级/三级标题
重要结论用「粗体」标注


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{原始的讨论或笔记}` | 零散讨论内容 |

---

## 七、API 设计类

### 模板 7.1：RESTful API 设计

请作为 API 设计师，根据以下需求设计 RESTful API。

业务背景

{业务背景}

核心资源

{资源列表，如用户、订单、商品}

功能需求

{功能需求1}
{功能需求2}
{功能需求3}

设计约束

API 版本策略：{版本策略}
认证方式：{OAuth 2.0 / JWT / API Key}
响应格式：{JSON / Protocol Buffers}
命名风格：{snake_case / camelCase}

输出要求

资源模型设计：核心资源的字段、关系
API 端点设计：每个资源的标准 CRUD + 自定义操作
请求/响应示例：每个端点给出示例
错误处理规范：统一的错误响应结构、HTTP 状态码使用规范
分页/排序/过滤：统一规范
API 变更策略：如何兼容旧版本


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{业务背景}` | 业务描述 |
| `{资源列表}` | 核心资源 | 
| `{功能需求1/2/3}` | 具体功能 |
| `{版本策略}` | 如 URL Path Versioning |
| `{OAuth 2.0 / JWT / API Key}` | 认证方式 |

---

### 模板 7.2：GraphQL Schema 设计

请根据以下需求设计 GraphQL Schema。

业务领域

{业务领域描述}

核心实体和关系

{实体列表及关系}

数据查询需求

{常见查询场景}

数据变更需求

{常见变更场景}

输出要求

Type Definitions：完整的 GraphQL Schema（SDL 格式）
Query 设计：满足所有查询需求
Mutation 设计：满足所有变更需求
Subscription 设计（如果适用）：实时推送需求
N+1 问题分析：哪些查询可能存在 N+1，如何通过 DataLoader 解决
权限设计：如何通过 GraphQL Directive 或 Middleware 实现权限控制

约束

遵循 Relay Connection 规范：{是/否}
需要支持 Federation：{是/否}


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{业务领域描述}` | 业务领域 |
| `{实体列表及关系}` | 实体与关系 |
| `{常见查询场景}` | 查询场景 |
| `{常见变更场景}` | 变更场景 |

---

### 模板 7.3：API 错误码与异常设计

请为以下系统的 API 设计一套完整的错误码体系和异常处理规范。

系统/服务名称

{系统名称}

已有错误码（如果有）

{已有的错误码列表}

请输出

错误码分类
- 客户端错误（4xx）：参数校验、鉴权、资源不存在等
- 服务端错误（5xx）：内部错误、超时、熔断等
- 业务错误（自定义码）：如余额不足、库存不足等

错误响应结构

{
  "code": "ERROR_CODE",
  "message": "用户可读的错误描述",
  "detail": "详细的调试信息（仅内部环境）",
  "request_id": "用于追踪的UUID"
}

HTTP 状态码映射策略
- 哪些情况用 400 vs 422 vs 409
- 哪些情况用 403 vs 401
全局异常处理方案
- 框架层面的全局异常拦截器配置
- 日志记录规范
错误码枚举定义
- 以 {编程语言} 枚举/常量形式给出


**变量说明：**
| 变量 | 说明 |
|------|------|
| `{系统名称}` | 系统名 |
| `{已有的错误码列表}` | 已有的错误码 |
| `{编程语言}` | 枚举定义语言 |

---

## 八、中文 Prompt 最佳实践

### 8.1 结构化原则

好 Prompt 的结构 = 角色定义 + 上下文 + 任务描述 + 输出格式 + 约束条件


### 8.2 用中文写 Prompt 的关键技巧

| 技巧 | 说明 | 错误写法 | 正确写法 |
|------|------|----------|----------|
| **提供示例** | Few-shot 样例比抽象描述更有效 | "生成一个合理的API" | "参考以下示例风格：\{示例\}" |
| **明确输出长度** | 中文 token 消耗不同于英文 | "简短说明" | "请用不超过 500 字说明" |
| **使用编号** | 结构化需求更易被理解 | "要安全也要高性能" | "1.安全性... 2.性能..." |
| **负面排除** | 明确告诉 AI 不该做什么 | "优化代码" | "优化代码。不要删减注释，不要修改公共 API 签名" |
| **指定角色** | 角色设定让 AI 调用领域知识 | "审查这段代码" | "你是一位有10年经验的 Go 语言后端工程师" |
| **步骤分解** | 复杂任务拆成多步 | "设计这个系统" | "第一步：确认需求；第二步：画出架构；第三步：详细设计" |
| **自我修正** | 让 AI 自己检查输出 | | "输出后请检查是否符合所有要求，如有遗漏请补充" |

### 8.3 常见陷阱与规避

1. **模糊的代词**
   - ❌ "检查它是否正确" — "它"指代不清
   - ✅ "检查上述代码中第 15-30 行的排序算法是否正确"

2. **过度抽象的描述**
   - ❌ "优化性能"
   - ✅ "将接口响应时间降低到 200ms 以下。当前为 800ms，主要瓶颈在数据库查询"

3. **一个 prompt 塞太多任务**
   - ❌ "帮我审查代码、写测试、重构、还要部署"
   - ✅ 分多个 prompt 逐步推进，每个聚焦一个目标

4. **不给出格式示范**
   - ❌ "输出审查结果"
   - ✅ "请按这个格式输出：\n【严重性】|【问题位置】|【问题描述】|【修复建议】"

### 8.4 迭代式 Prompt 工作流

对于复杂任务，推荐分多轮对话完成：

轮次1：【角色 + 任务定义】 → "你是一位{角色}。我要{任务}，确认你理解了需求。"

轮次2：【输出初稿】 → "好的，请开始输出。"

轮次3：【细化/修正】 → "第{章节}需要补充{细节}。第{章节}的表述改为{要求}。"

轮次4：【最终检查】 → "请检查是否符合所有要求，列出每个要求的满足状态。"


### 8.5 针对不同 AI 模型的调参建议

| 模型类型 | Prompt 风格建议 | Temperature | 说明 |
|----------|---------------|-------------|------|
| GPT-4 / Claude 3 | 详细结构化的中文 Prompt | 0.1-0.3 | 代码和结构化输出时降低温度 |
| DeepSeek / Qwen | 直接清晰的中文指令 | 0.3-0.5 | 对中文理解力强，可适当简化 |
| 代码生成场景 | 示例驱动 + 约束优先 | 0.0-0.2 | 减少随机性，保证一致性 |
| 创意/设计场景 | 开放式引导 | 0.5-0.8 | 适当温度获取多样化方案 |

---

## 附录：模板快速索引卡


> **使用建议**：初次使用请从模板复制后，补充具体的 `{变量}` 值。多次使用后可根据自身团队的习惯，将常用模板固化为团队内部的标准 Prompt 模板库。