with one click
prompt-engineering
中文Prompt模板库——20+即用模板涵盖代码审查、架构设计、Bug修复、重构、测试、文档、API设计,附最佳实践
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Menu
中文Prompt模板库——20+即用模板涵盖代码审查、架构设计、Bug修复、重构、测试、文档、API设计,附最佳实践
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
国内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 模板库。