Menü
中文Prompt模板库——20+即用模板涵盖代码审查、架构设计、Bug修复、重构、测试、文档、API设计，附最佳实践
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
国内AI平台API统一封装 —— DeepSeek / 通义千问 / 百度文心 / 讯飞星火 一键切换
中文代码生成规范：命名规范、注释规范、多语言代码规则、CRUD模板、代码审查清单
一键配置国内AI开发环境——DeepSeek/通义千问/豆包/百度文心/讯飞星火API适配，WSL/Windows/Mac三环境自动检测，代理配置，故障排查
国内云服务部署完全指南 —— 阿里云ECS / 腾讯云 / CDN / 备案 / 镜像加速 / CI/CD / 成本估算
中文爬虫工具集 —— Python requests/BS4 爬虫模板、反爬虫绕过、Selenium 自动化、数据导出
WSL/Windows双环境自动化管理——轻松在WSL和Windows之间协作，解决Interop/路径/权限/代理/性能问题
| 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 模板集合。每个模板可直接复制使用，通过 {变量名} 替换实际内容。
你是一位资深的 {编程语言} 代码审查专家。请对我提交的以下代码进行全面的代码审查。
审查重点：
1. 安全性漏洞（SQL注入、XSS、认证绕过等）
2. 性能瓶颈（循环效率、内存泄漏、不必要的计算）
3. 代码规范与风格（是否符合 {团队规范名称} ）
4. 可维护性（命名是否清晰、函数是否过长、是否缺少注释）
5. 边界条件与错误处理（空指针、异常处理是否完备）
请按「严重程度从高到低」输出审查结果。每个问题标注：严重性（Critical/Major/Minor）、所在行号、问题描述、修复建议。
```{编程语言}
{粘贴你的代码}
**变量说明：**
| 变量 | 说明 | 示例 |
|------|------|------|
| `{编程语言}` | 代码语言 | Python、Java、Go |
| `{团队规范名称}` | 团队遵循的风格规范 | Google Style、PEP 8 |
| `{粘贴你的代码}` | 待审查的代码块 | — |
---
### 模板 1.2：安全专项审查
请以安全审计专家的身份审查以下代码。专注于 OWASP Top 10 安全风险。
要求：
对于每个安全问题，请给出： [风险等级] [风险类型] → [问题描述] → [修复代码示例]
{代码内容}
**变量说明：**
| 变量 | 说明 |
|------|------|
| `{编程语言}` | 代码语言 |
| `{代码内容}` | 待审查的代码 |
---
### 模板 1.3：数据库与SQL审查
请作为数据库管理员审查以下 SQL / ORM 代码。审查维度：
一、性能分析
二、安全性
三、正确性
四、改写建议
{你的SQL语句或ORM代码}
**变量说明：**
| 变量 | 说明 |
|------|------|
| `{你的SQL语句或ORM代码}` | SQL 或 ORM 代码 |
---
### 模板 1.4：Code Review 摘要生成
你是一位资深技术主管。以下是一个 Pull Request 的变更内容。请帮我生成一份 Code Review 总结。
请输出：
（用一句话概括本次 PR 做了什么）
（列出 3-5 个最重要的文件和改动点）
（如果请求修改，简要列出必须修复项）
PR Diff 内容： {diff内容}
**变量说明：**
| 变量 | 说明 |
|------|------|
| `{diff内容}` | PR 的 diff 或变更文件列表 |
---
## 二、架构设计类
### 模板 2.1：系统架构方案设计
你是一位资深的系统架构师。请根据以下需求输出一份完整的系统架构设计方案。
{业务背景描述}
{核心功能列表}
请包含以下部分：
**变量说明：**
| 变量 | 说明 | 示例 |
|------|------|------|
| `{业务背景描述}` | 业务场景和问题描述 | "一个面向中小企业的在线文档协作平台" |
| `{核心功能列表}` | 关键功能 | 实时编辑、权限管理、版本历史 |
| `{QPS估算}` | 每秒查询量 | 5000 QPS |
| `{数据量估算}` | 数据规模 | 日均新增 1TB |
| `{SLA要求}` | 可用性 | 99.99% |
| `{延迟要求}` | 延迟 | P99 < 200ms |
---
### 模板 2.2：技术选型评估
请作为技术顾问，帮我评估以下技术方案的选型。需要客观中立的分析。
{项目背景和约束条件}
请从以下维度给出评分（1-5分）和分析：
每个方案给出一个总评表格，然后给出推荐优先级排序。
最后请给出一个「实施建议」段落，说明如果采用推荐方案，需要注意哪些坑。
**变量说明：**
| 变量 | 说明 |
|------|------|
| `{项目背景和约束条件}` | 项目概述和约束 |
| `{方案A/B/C}` | 候选技术方案 |
---
### 模板 2.3：微服务拆分设计
你是一位微服务架构专家。请帮我设计一个微服务拆分方案。
{现有单体应用描述}
{拆分的原因和目标}
**变量说明：**
| 变量 | 说明 |
|------|------|
| `{现有单体应用描述}` | 当前系统描述 |
| `{拆分的原因和目标}` | 商业/技术驱动力 |
| `{团队人数}` | 团队规模 |
| `{技术栈}` | 技术栈 |
| `{时间要求}` | 时间线 |
---
## 三、Bug 修复类
### 模板 3.1：代码 Debug
我遇到了一个 Bug，请帮我分析和修复。
{Bug的现象描述}
{期望输出或行为}
{实际输出或行为}
{错误栈或日志}
{相关代码片段}
{已经尝试过的排查方向}
**变量说明：**
| 变量 | 说明 |
|------|------|
| `{语言/框架}` | 如 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：运行时性能问题排查
我有一个性能问题需要排查。请作为性能优化专家帮我分析。
{性能问题的表现}
请按以下结构输出：
**变量说明：**
| 变量 | 说明 |
|------|------|
| `{性能问题的表现}` | 如 "接口 P99 延迟从 50ms 上升到 2s" |
| `{CPU/内存/网络}` | 配置详情 |
| `{关键配置}` | 如 JVM -Xms -Xmx、MySQL innodb_buffer_pool_size |
---
## 四、重构类
### 模板 4.1：代码重构建议
请作为代码重构专家，审视以下代码，给出重构建议。
{待重构的代码}
**变量说明：**
| 变量 | 说明 |
|------|------|
| `{编程语言}` | 代码语言 |
| `{待重构的代码}` | 待重构代码 |
| `{其他约束}` | 约束条件 |
---
### 模板 4.2：大函数拆分
以下函数过于庞大（超过 {行数} 行），请帮我将其拆分为多个职责清晰的小函数。
{超大函数代码}
**变量说明：**
| 变量 | 说明 | 示例 |
|------|------|------|
| `{行数}` | 触发拆分的阈值 | 100 |
| `{编程语言}` | 代码语言 | JavaScript |
| `{超大函数代码}` | 大函数源码 | — |
| `{目标行数}` | 拆分后每函数最大行数 | 20 |
---
### 模板 4.3：设计模式重构
以下代码存在设计不合理的问题。请使用 {设计模式名称} 设计模式进行重构。
{当前代码}
{列举当前代码在设计上的问题}
**变量说明：**
| 变量 | 说明 |
|------|------|
| `{设计模式名称}` | 目标设计模式（可选） |
| `{编程语言}` | 代码语言 |
| `{当前代码}` | 待重构代码 |
| `{列举当前代码在设计上的问题}` | 设计问题描述 |
---
## 五、测试编写类
### 模板 5.1：单元测试生成
请根据以下代码，生成完整的单元测试。
{待测代码}
{测试框架名称}
{Mock工具名称}
{额外约束条件，如：不能改变被测试代码}
**变量说明：**
| 变量 | 说明 | 示例 |
|------|------|------|
| `{编程语言}` | 代码语言 | Python |
| `{待测代码}` | 被测源码 | — |
| `{测试框架名称}` | 测试框架 | pytest、JUnit 5 |
| `{Mock工具名称}` | Mock 工具 | unittest.mock、Mockito |
| `{覆盖率}` | 目标覆盖率 | 90 |
| `{额外约束条件}` | 其他约束 | — |
---
### 模板 5.2：集成测试编写
请为以下 API 编写集成测试。
{接口说明}
{HTTP请求示例}
{预期响应JSON}
完整的测试代码，包含 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格式}
**变量说明：**
| 变量 | 说明 |
|------|------|
| `{编程语言/格式}` | 如 Java、Python、OpenAPI YAML |
| `{接口定义代码或Swagger/OpenAPI描述}` | 接口源码 |
| `{Markdown / OpenAPI 3.0 / 内部Wiki格式}` | 输出格式 |
---
### 模板 6.2：README / Wiki 编写
请帮我为以下项目编写 README 文档。
{功能列表}
{项目目录结构}
{中文 / 中英双语 / 英文}
**变量说明：**
| 变量 | 说明 |
|------|------|
| `{项目名称}` | 项目名称 |
| `{一句话介绍}` | 一句话简介 |
| `{技术栈}` | 技术栈 |
| `{目标用户}` | 用户群体 |
| `{功能列表}` | 功能点 |
| `{项目目录结构}` | 目录树 |
---
### 模板 6.3：技术方案/设计文档
请帮我把以下讨论整理成一份结构化的技术方案文档。
{原始的讨论或笔记}
**变量说明：**
| 变量 | 说明 |
|------|------|
| `{原始的讨论或笔记}` | 零散讨论内容 |
---
## 七、API 设计类
### 模板 7.1：RESTful API 设计
请作为 API 设计师，根据以下需求设计 RESTful API。
{业务背景}
{资源列表，如 用户、订单、商品}
**变量说明：**
| 变量 | 说明 |
|------|------|
| `{业务背景}` | 业务描述 |
| `{资源列表}` | 核心资源 |
| `{功能需求1/2/3}` | 具体功能 |
| `{版本策略}` | 如 URL Path Versioning |
| `{OAuth 2.0 / JWT / API Key}` | 认证方式 |
---
### 模板 7.2：GraphQL Schema 设计
请根据以下需求设计 GraphQL Schema。
{业务领域描述}
{实体列表及关系}
{常见查询场景}
{常见变更场景}
**变量说明：**
| 变量 | 说明 |
|------|------|
| `{业务领域描述}` | 业务领域 |
| `{实体列表及关系}` | 实体与关系 |
| `{常见查询场景}` | 查询场景 |
| `{常见变更场景}` | 变更场景 |
---
### 模板 7.3：API 错误码与异常设计
请为以下系统的 API 设计一套完整的错误码体系和异常处理规范。
{系统名称}
{已有的错误码列表}
错误码分类
错误响应结构
{
"code": "ERROR_CODE",
"message": "用户可读的错误描述",
"detail": "详细的调试信息（仅内部环境）",
"request_id": "用于追踪的UUID"
}
HTTP 状态码映射策略
全局异常处理方案
错误码枚举定义
**变量说明：**
| 变量 | 说明 |
|------|------|
| `{系统名称}` | 系统名 |
| `{已有的错误码列表}` | 已有的错误码 |
| `{编程语言}` | 枚举定义语言 |
---
## 八、中文 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 模板库。