主题
AI编程Prompt模板库
好的 Prompt 是可以复用的资产。当你第一次让 AI 帮你生成一个 REST API 端点,写了一段像样的提示词,拿到了不错的结果——这段提示词不应该随着对话窗口关闭就消失。把它沉淀下来,加上变量占位符,它就变成了一个模板,下次换个项目、换个框架,改几个关键词就能直接复用。
这篇文章汇总了 AI 编程中常见的 90+ 个 Prompt 模板,覆盖从项目初始化到文档生成的完整开发流程。每个模板都包含使用场景、模板正文和调整说明,目标是让编程新手也能直接复制、快速上手。
如何使用这些模板
在开始之前,先说清楚模板的正确打开方式。
模板的结构约定
每个模板都遵循统一格式:
【场景】:说明这个模板适用于什么情况【模板】:可以直接复制的 Prompt 正文,用{{双花括号}}标记需要替换的变量【说明】:使用注意事项和调整建议
变量替换规则
模板中的 {{变量名}} 需要你根据实际情况替换:
| 变量 | 含义 | 示例 |
|---|---|---|
{{语言}} | 编程语言 | TypeScript、Python、Go |
{{框架}} | 使用的框架 | Next.js、FastAPI、Gin |
{{项目名}} | 项目名称 | my-saas-app |
{{功能描述}} | 要实现的功能 | 用户注册登录 |
{{错误信息}} | 报错内容 | TypeError: Cannot read property |
{{数据库}} | 数据库类型 | PostgreSQL、MongoDB |
适配不同 AI 工具
这些模板在主流 AI 编程工具中都能使用,但有一些细节差异值得注意:
| 工具 | 适用方式 | 注意事项 |
|---|---|---|
| ChatGPT / Claude 网页版 | 直接粘贴到对话框 | 长模板建议分步发送 |
| Cursor | 放入 Composer 或 Chat | 可结合 @file 引用代码上下文 |
| Claude Code | 直接在终端输入 | 支持读取项目文件作为上下文 |
| GitHub Copilot | 在编辑器注释中写 Prompt | 模板需要精简,适配行内交互 |
一、项目初始化模板(12 个)
项目初始化是从「想法」到「代码」的第一步。好的 Prompt 能让 AI 帮你生成结构清晰、约定合理的项目脚手架。
1.1 全栈项目脚手架
【场景】从零开始创建一个全栈项目。
【模板】
请帮我创建一个 {{语言}} 全栈项目,要求如下:
项目名称:{{项目名}}
前端框架:{{前端框架}}
后端框架:{{后端框架}}
数据库:{{数据库}}
包管理器:{{包管理器}}
项目结构要求:
1. 前后端分离,使用 monorepo 结构
2. 包含基础的目录规划(src/components、src/pages、src/api、src/utils)
3. 配置 ESLint + Prettier 代码规范
4. 包含 .env.example 环境变量模板
5. 包含 Dockerfile 和 docker-compose.yml
6. 配置 CI/CD(GitHub Actions)
7. 包含基础的 README.md
请生成完整的目录结构和关键配置文件内容。【说明】根据团队规模和项目复杂度,可以增减配置项。小项目可以省略 CI/CD 和 Docker 部分。
1.2 前端项目初始化
【场景】创建纯前端项目。
【模板】
创建一个 {{框架}} 前端项目,需求:
- 路由方案:{{路由方案}}
- 状态管理:{{状态管理}}
- UI 组件库:{{UI组件库}}
- CSS 方案:{{CSS方案}}
- 构建工具:Vite
请生成:
1. package.json 及核心依赖版本
2. 目录结构规划
3. 路由配置文件
4. 入口文件
5. 基础布局组件
6. vite.config.ts 配置【说明】如果是 Next.js 项目,把「构建工具」换成 App Router 或 Pages Router 的说明。
1.3 后端 API 项目初始化
【场景】创建纯后端 API 服务。
【模板】
用 {{语言}} + {{框架}} 创建一个 RESTful API 项目:
项目名:{{项目名}}
数据库:{{数据库}}
ORM:{{ORM}}
认证方式:{{认证方式}}
需要包含:
1. 项目目录结构(controllers、services、repositories、models、middlewares)
2. 数据库连接配置
3. 统一错误处理中间件
4. 请求参数校验中间件
5. 日志配置
6. 健康检查接口 GET /health
7. 基础的 CORS 配置【说明】三层架构(controller → service → repository)适合中大型项目。小型项目可以简化为 controller → service 两层。
1.4 CLI 工具项目初始化
【场景】创建命令行工具项目。
【模板】
用 {{语言}} 创建一个 CLI 工具项目:
工具名称:{{工具名}}
功能描述:{{功能描述}}
参数解析库:{{参数库}}
要求:
1. 支持 --help 和 --version 参数
2. 支持子命令结构(如 tool init、tool build)
3. 包含交互式提示(用户选择、输入)
4. 彩色终端输出
5. 错误处理和友好的错误提示
6. 单元测试框架配置【说明】Node.js 项目推荐 commander + inquirer,Python 项目推荐 typer + rich。
1.5 移动端项目初始化
【场景】创建跨平台移动应用。
【模板】
用 {{框架}} 创建移动应用项目:
应用名:{{应用名}}
目标平台:iOS + Android
导航方案:{{导航方案}}
状态管理:{{状态管理}}
需要包含:
1. 项目初始化命令和目录结构
2. 导航配置(底部 Tab + Stack 导航)
3. 基础主题配置(颜色、字体、间距)
4. API 请求封装(带拦截器)
5. 本地存储方案
6. 基础页面模板(首页、列表页、详情页、设置页)【说明】React Native 项目推荐 expo-router,Flutter 项目推荐 go_router。
1.6 Monorepo 项目初始化
【场景】搭建多包共享的 Monorepo 结构。
【模板】
搭建一个 {{工具}} Monorepo 项目:
包含以下子包:
- apps/web:{{前端框架}} 前端应用
- apps/api:{{后端框架}} 后端服务
- packages/ui:共享 UI 组件库
- packages/utils:共享工具函数
- packages/config:共享配置文件
要求:
1. 工作区依赖解析配置
2. 构建任务编排(turborepo 或 nx)
3. 统一的 TypeScript 配置(tsconfig base)
4. 统一的 ESLint 配置
5. 共享的环境变量管理
6. 版本发布策略(changeset)【说明】Turborepo 适合前端为主的 Monorepo,Nx 适合需要更强大依赖图分析的场景。
1.7 浏览器扩展项目初始化
【场景】创建 Chrome/Firefox 浏览器扩展。
【模板】
创建一个浏览器扩展项目:
框架:{{框架}}(如 Plasmo / WXT)
目标浏览器:Chrome + Firefox
功能描述:{{功能描述}}
需要包含:
1. manifest 配置
2. Popup 页面
3. Background Script
4. Content Script
5. 与宿主页面通信机制
6. 存储方案
7. 开发热更新配置【说明】Plasmo 框架对 Next.js 开发者比较友好,WXT 更轻量。
1.8 Electron 桌面应用初始化
【场景】创建跨平台桌面应用。
【模板】
用 Electron + {{前端框架}} 创建桌面应用:
应用名:{{应用名}}
功能描述:{{功能描述}}
需要包含:
1. 主进程和渲染进程分离
2. 预加载脚本配置
3. 窗口管理(创建、关闭、最小化)
4. 系统托盘集成
5. 自动更新机制
6. 打包配置(electron-builder)
7. 开发环境热更新【说明】如果只需要轻量桌面壳,可以考虑 Tauri(Rust 后端,包体积更小)。
1.8 Lambda/Serverless 项目初始化
【场景】创建无服务器函数项目。
【模板】
创建 Serverless 项目:
平台:{{平台}}(AWS Lambda / Cloudflare Workers / Vercel Functions)
运行时:{{运行时}}
功能描述:{{功能描述}}
需要包含:
1. 函数目录结构
2. 路由配置
3. 环境变量管理
4. 数据库连接池
5. 请求校验中间件
6. 部署配置
7. 本地开发调试方案【说明】不同平台的本地调试方案差异较大,务必确认平台对应的 dev 工具链。
1.10 微服务初始化
【场景】创建微服务架构中的单个服务。
【模板】
创建一个微服务:
服务名:{{服务名}}
职责:{{服务描述}}
通信方式:{{HTTP/gRPC/消息队列}}
数据库:{{数据库}}
需要包含:
1. 服务脚手架和目录结构
2. 健康检查端点
3. 服务注册/发现客户端
4. 配置中心集成
5. 链路追踪中间件
6. 优雅关闭处理
7. Docker 镜像构建【说明】微服务的复杂度较高,建议先确认团队是否有成熟的基础设施再采用。
1.11 AI 应用项目初始化
【场景】创建基于 LLM 的 AI 应用项目。
【模板】
创建 AI 应用项目:
语言:{{语言}}
LLM 提供商:{{OpenAI/Anthropic/本地模型}}
应用类型:{{聊天应用/RAG/Agent}}
需要包含:
1. LLM SDK 集成和配置
2. Prompt 模板管理模块
3. 对话历史存储
4. Token 用量统计
5. 流式输出处理
6. 错误重试和降级策略
7. 安全过滤(输入/输出审核)【说明】AI 应用的关键是 Prompt 管理和 Token 控制,这两部分要独立成模块。
1.12 静态站点/博客初始化
【场景】创建技术博客或文档站点。
【模板】
创建静态站点项目:
框架:{{Astro/Next.js/Nuxt}}
内容方案:{{MDX/MD}}
部署平台:{{Vercel/Netlify/Cloudflare Pages}}
需要包含:
1. 内容目录结构(按分类组织)
2. Markdown/MDX 解析配置
3. 代码高亮
4. RSS 生成
5. Sitemap 生成
6. SEO meta 标签
7. 搜索功能(Algolia/Pagefind)【说明】纯内容站点推荐 Astro(构建速度快、SEO 友好),需要交互功能选 Next.js。
二、页面生成模板(11 个)
2.1 CRUD 列表页
【场景】创建数据列表页,包含搜索、分页和操作。
【模板】
用 {{框架}} 创建一个列表页:
数据实体:{{实体名}}
字段列表:{{字段1}}、{{字段2}}、{{字段3}}
API 地址:{{API路径}}
页面功能:
1. 数据表格展示(支持排序)
2. 关键词搜索框
3. 筛选条件({{筛选字段}})
4. 分页控件(默认每页 20 条)
5. 新建按钮(打开创建表单)
6. 编辑和删除操作
7. 批量操作(选中多条删除/导出)
8. 空状态和加载状态
请生成完整的页面组件代码。【说明】CRUD 页面是后台管理系统最常见的页面类型,适合做成可配置的通用组件。
2.2 表单页
【场景】创建数据录入表单页面。
【模板】
用 {{框架}} 创建表单页:
表单名称:{{表单名}}
提交接口:{{API路径}}
字段列表:
1. {{字段名}} - {{类型}} - {{校验规则}}
2. ...(按实际列出所有字段)
要求:
1. 表单校验(必填、格式、长度限制)
2. 实时校验反馈
3. 提交前确认
4. 提交中禁用按钮,防止重复提交
5. 成功/失败提示
6. 支持草稿自动保存(localStorage)
7. 响应式布局【说明】复杂表单建议使用 react-hook-form 或 formik,可以减少大量模板代码。
2.3 详情页
【场景】创建数据详情展示页面。
【模板】
用 {{框架}} 创建详情页:
数据实体:{{实体名}}
数据来源:{{API路径}}/{{ID参数}}
展示内容:
1. 基本信息区域(标题、状态标签、操作按钮)
2. 详细描述(支持富文本渲染)
3. 关联数据列表({{关联实体}})
4. 操作历史/时间线
5. 附件/图片预览
要求:
1. 骨架屏加载
2. 404 处理(数据不存在时)
3. 面包屑导航
4. 返回上一页功能【说明】详情页的骨架屏体验很重要,避免用户看到空白页面。
2.4 Dashboard 仪表盘
【场景】创建数据概览仪表盘。
【模板】
用 {{框架}} 创建仪表盘页面:
数据源:{{API路径}}
用户角色:{{角色}}
包含以下模块:
1. 顶部统计卡片(4 个关键指标 + 环比变化)
2. 趋势图表({{图表类型}},时间范围可选)
3. 最近活动列表(最新 10 条)
4. 待办事项/告警列表
5. 快速操作入口
要求:
1. 响应式网格布局
2. 数据加载中骨架屏
3. 图表支持切换时间范围
4. 数据自动刷新({{刷新间隔}})
5. 卡片可拖拽排列(可选)【说明】仪表盘要注意数据加载的性能,避免一次性请求过多接口。可以用 Promise.all 并行请求。
2.5 登录/注册页
【场景】创建用户认证页面。
【模板】
用 {{框架}} 创建登录和注册页面:
认证方式:{{邮箱密码/OAuth/手机验证码}}
后端接口:{{API路径}}
登录页:
1. 邮箱/密码输入框
2. 「记住我」复选框
3. 忘记密码链接
4. 第三方登录按钮(Google、GitHub)
5. 表单校验和错误提示
6. 登录成功跳转
注册页:
1. 用户名、邮箱、密码、确认密码
2. 密码强度指示器
3. 服务条款勾选
4. 邮箱验证码发送
5. 注册成功引导
通用要求:
- CSRF 防护
- 登录失败次数限制提示
- 移动端适配【说明】认证页面安全要求高,前端校验只是辅助,后端校验才是关键。
2.6 设置页
【场景】创建用户/系统设置页面。
【模板】
用 {{框架}} 创建设置页面:
设置类型:{{用户设置/系统设置}}
数据接口:{{API路径}}
设置分组:
1. 基本信息(头像、名称、简介)
2. 通知偏好(邮件通知、站内通知开关)
3. 安全设置(修改密码、两步验证)
4. 外观设置(主题、语言、时区)
5. 数据管理(导出、删除账号)
布局:
- 左侧导航分组
- 右侧设置表单
- 每组设置独立保存
- 修改后显示「未保存」提示【说明】设置页用左侧导航分组的布局方式,避免单页表单过长。
2.7 文件上传页
【场景】创建文件上传和管理页面。
【模板】
用 {{框架}} 创建文件上传页面:
上传接口:{{API路径}}
文件大小限制:{{限制}}
支持格式:{{格式列表}}
功能:
1. 拖拽上传区域
2. 点击选择文件
3. 多文件同时上传
4. 上传进度条
5. 已上传文件列表(缩略图 + 文件名 + 大小 + 操作)
6. 预览功能(图片直接预览,其他格式跳转)
7. 删除和重命名
8. 文件夹/分组管理(可选)【说明】大文件上传建议加上分片上传和断点续传。
2.8 搜索结果页
【场景】创建全站搜索或局部搜索页面。
【模板】
用 {{框架}} 创建搜索结果页:
搜索接口:{{API路径}}
搜索范围:{{全局/指定模块}}
功能:
1. 顶部搜索框(支持自动补全)
2. 搜索结果分类筛选(Tab 切换)
3. 结果列表(标题 + 摘要 + 高亮关键词)
4. 排序选项(相关度、时间)
5. 分页或无限滚动
6. 无结果时的推荐
7. 搜索历史记录(本地存储)【说明】搜索结果页的性能关键在于搜索接口响应速度,前端做好防抖和缓存。
2.9 404/错误页面
【场景】创建异常状态页面。
【模板】
用 {{框架}} 创建错误页面:
需要覆盖的状态:
1. 404 - 页面不存在
2. 500 - 服务器错误
3. 403 - 无权限访问
4. 网络错误 - 断网提示
每个页面包含:
- 友好的错误说明
- 插画或图标
- 返回首页按钮
- 返回上一页按钮
- 反馈入口(可选)【说明】错误页面容易被忽略,但对用户体验影响很大。建议统一封装 ErrorBoundary 组件。
2.10 落地页/营销页
【场景】创建产品营销落地页。
【模板】
用 {{框架}} 创建产品落地页:
产品名:{{产品名}}
目标用户:{{用户画像}}
核心卖点:{{卖点列表}}
页面结构(从上到下):
1. Hero 区域(标题 + 副标题 + CTA 按钮 + 产品截图/视频)
2. 痛点描述(3-4 个用户痛点)
3. 功能介绍(图文并茂,交替布局)
4. 社会证明(客户 Logo、评价、数据指标)
5. 价格方案(对比表格)
6. FAQ(手风琴折叠)
7. 底部 CTA(再次强调行动)
8. Footer
SEO 要求:
- Meta title 和 description
- 结构化数据(Product / FAQ schema)
- 图片 alt 文本
- 语义化 HTML 标签【说明】落地页的核心是转化,每个区块都应该引导用户向 CTA 靠近。
2.11 数据可视化页
【场景】创建以图表为主的数据展示页面。
【模板】
用 {{框架}} + {{图表库}}(ECharts/Recharts/D3)创建数据可视化页面:
数据接口:{{API路径}}
数据类型:{{时序数据/分布数据/关系数据}}
图表列表:
1. {{图表类型}} - 展示 {{数据维度}}
2. ...
交互功能:
- 时间范围选择
- 数据下钻(点击图表元素查看详情)
- 图表导出(PNG/CSV)
- 全屏模式【说明】图表库选型:简单图表用 Recharts,复杂交互用 ECharts,高度定制用 D3。
三、组件开发模板(11 个)
3.1 通用按钮组件
【场景】创建可复用的按钮组件。
【模板】
用 {{框架}} 创建 Button 组件:
变体:primary、secondary、ghost、danger
尺寸:sm、md、lg
状态:默认、hover、active、disabled、loading
要求:
1. 支持 asChild 或 as prop(渲染为不同标签)
2. 支持图标 + 文字组合
3. 支持 loading 状态(显示 spinner,禁用点击)
4. 键盘可访问(focus 样式、Enter/Space 触发)
5. 支持 ref 转发
6. TypeScript 类型完整【说明】按钮是最基础也最容易做复杂的组件,核心是变体和尺寸的组合设计。
3.2 数据表格组件
【场景】创建通用的数据表格组件。
【模板】
用 {{框架}} 创建通用 Table 组件:
功能要求:
1. 支持传入 columns 配置和数据数组
2. 列排序(升序/降序/不排序)
3. 行选择(单选/多选)
4. 列固定(左侧固定、右侧固定)
5. 虚拟滚动(支持 1000+ 行数据)
6. 可调整列宽
7. 自定义单元格渲染(render 函数)
8. 分页集成
9. 空状态和加载状态
API 设计:
- 接受泛型数据类型
- columns 和 data 分离
- 支持受控和非受控模式【说明】复杂表格建议基于 tanstack/table 封装,它能处理排序、筛选、分页等核心逻辑。
3.3 模态框组件
【场景】创建通用弹窗组件。
【模板】
用 {{框架}} 创建 Modal 组件:
功能:
1. 打开/关闭动画
2. 点击遮罩关闭(可配置)
3. ESC 键关闭
4. 焦点陷阱(focus trap)
5. 滚动锁定(打开时 body 不可滚动)
6. 支持不同尺寸(sm、md、lg、fullscreen)
7. 确认/取消按钮区域
8. 支持异步操作(提交中显示 loading)
9. 嵌套弹窗支持
10. Portal 渲染(挂载到 body 下)【说明】弹窗组件最容易被忽视的是无障碍访问,焦点陷阱和 ESC 关闭缺一不可。
3.4 搜索输入框组件
【场景】创建带自动补全的搜索组件。
【模板】
用 {{框架}} 创建 SearchInput 组件:
功能:
1. 输入防抖({{延迟时间}}ms)
2. 自动补全下拉列表
3. 搜索结果高亮匹配关键词
4. 清空按钮
5. Loading 状态
6. 无结果提示
7. 键盘导航(上下箭头选择、Enter 确认)
8. 搜索历史记录(可选)
9. 支持自定义渲染搜索结果项【说明】防抖时间建议 300ms,太短增加请求量,太长影响体验。
3.5 文件上传组件
【场景】创建可复用的文件上传组件。
【模板】
用 {{框架}} 创建 Upload 组件:
上传方式:
1. 点击选择文件
2. 拖拽上传
3. 粘贴上传(Ctrl+V)
功能:
1. 文件类型校验(accept 属性 + 二次校验)
2. 文件大小限制
3. 上传进度显示
4. 已上传文件列表(带预览、删除)
5. 上传失败重试
6. 支持单文件/多文件模式
7. 自定义上传请求(覆盖默认 fetch)【说明】文件上传组件要处理好各种异常状态:类型错误、大小超限、网络失败。
3.6 树形组件
【场景】创建树形数据展示和操作组件。
【模板】
用 {{框架}} 创建 Tree 组件:
数据格式:嵌套树形结构
功能:
1. 节点展开/折叠
2. 节点选择(单选/多选/级联选择)
3. 节点搜索(高亮匹配节点,自动展开)
4. 拖拽排序
5. 右键菜单(新增、编辑、删除节点)
6. 虚拟滚动(大量节点时)
7. 自定义节点渲染
8. 异步加载子节点【说明】文件管理器、组织架构、分类管理等场景都需要树形组件。
3.7 通知/Toast 组件
【场景】创建消息通知组件。
【模板】
用 {{框架}} 创建 Toast 组件:
类型:success、error、warning、info、loading
功能:
1. 自动消失(可配置时间)
2. 手动关闭按钮
3. 堆叠展示(多条通知同时存在)
4. 位置配置(右上角、右下角、顶部居中)
5. 进入/退出动画
6. 支持自定义内容(JSX)
7. Promise 支持(操作完成自动切换状态)
8. 全局配置(默认持续时间、位置)【说明】推荐基于 sonner 或 react-hot-toast 封装,避免重复造轮子。
3.8 图表封装组件
【场景】封装通用的图表组件。
【模板】
用 {{框架}} + {{图表库}} 封装通用图表组件:
需要封装的图表类型:
1. LineChart(折线图)
2. BarChart(柱状图)
3. PieChart(饼图)
4. AreaChart(面积图)
通用要求:
- 统一的 props 接口(data、xKey、yKey、title)
- 响应式尺寸(跟随容器宽度)
- 主题适配(亮色/暗色)
- Tooltip 自定义
- 图例配置
- 数据为空时的占位展示
- 导出为图片功能【说明】图表封装的核心价值在于统一接口和主题适配,避免每个页面各自配置。
3.9 步骤条/向导组件
【场景】创建多步骤表单或引导流程。
【模板】
用 {{框架}} 创建 Steps/Wizard 组件:
功能:
1. 步骤条展示(数字/图标/对勾状态)
2. 上一步/下一步导航
3. 步骤校验(当前步骤校验通过才能进入下一步)
4. 支持跳转(点击已完成的步骤回看)
5. 每一步的标题和描述
6. 进度百分比展示
7. 最终提交处理
8. 支持异步步骤(某一步需要请求数据)【说明】向导组件的关键是步骤状态管理,建议用 useReducer 或状态机管理。
3.10 无限滚动列表组件
【场景】创建滚动加载更多的列表。
【模板】
用 {{框架}} 创建 InfiniteScroll 组件:
功能:
1. 滚动到底部自动加载下一页
2. Loading 状态指示
3. 没有更多数据提示
4. 加载失败重试
5. 回到顶部按钮
6. 虚拟滚动优化(列表项超过 100 时)
7. 支持自定义触发距离(距底部多少像素时触发)
8. Pull to refresh(移动端下拉刷新)【说明】无限滚动要用 IntersectionObserver 而不是 scroll 事件监听,性能差异很大。
3.11 Markdown 渲染组件
【场景】创建 Markdown 内容渲染组件。
【模板】
用 {{框架}} 创建 MarkdownRenderer 组件:
功能:
1. 标准 Markdown 语法渲染
2. 代码块语法高亮(支持 20+ 语言)
3. 代码块复制按钮
4. 表格渲染
5. 数学公式(KaTeX)
6. 任务列表(checkbox)
7. 自定义链接处理(外部链接新窗口打开)
8. 图片懒加载
9. 标题锚点(点击标题复制链接)
10. 暗色主题适配【说明】推荐基于 react-markdown 或 marked 封装,注意 XSS 防护(sanitize HTML)。
四、API 开发模板(11 个)
4.1 RESTful CRUD 接口
【场景】创建标准的增删改查 API。
【模板】
用 {{语言}} + {{框架}} 创建 RESTful CRUD 接口:
资源名:{{资源名}}
数据模型:
- {{字段1}}: {{类型}} {{约束}}
- {{字段2}}: {{类型}} {{约束}}
- ...
接口列表:
1. GET /api/{{资源}} - 列表查询(分页、筛选、排序)
2. GET /api/{{资源}}/:id - 详情查询
3. POST /api/{{资源}} - 创建
4. PUT /api/{{资源}}/:id - 全量更新
5. PATCH /api/{{资源}}/:id - 部分更新
6. DELETE /api/{{资源}}/:id - 删除
每个接口要求:
- 请求参数校验(Zod/Joi/class-validator)
- 统一响应格式 { code, data, message }
- 统一错误处理
- 权限检查中间件
- 请求日志【说明】RESTful API 的核心是资源命名和 HTTP 方法的正确使用。
4.2 认证接口
【场景】创建用户认证 API(JWT 方案)。
【模板】
用 {{语言}} + {{框架}} 创建认证 API:
认证方式:JWT(Access Token + Refresh Token)
用户模型:{{字段列表}}
接口:
1. POST /auth/register - 注册
2. POST /auth/login - 登录
3. POST /auth/refresh - 刷新 Token
4. POST /auth/logout - 登出
5. POST /auth/forgot-password - 忘记密码
6. POST /auth/reset-password - 重置密码
7. GET /auth/me - 获取当前用户信息
安全要求:
- 密码 bcrypt 加密(cost factor 12)
- Access Token 有效期 15 分钟
- Refresh Token 有效期 7 天
- Refresh Token 单次使用(rotation)
- 登录失败限速(5 次/分钟)
- 敏感操作需要二次验证【说明】认证是最容易出安全问题的模块,建议用成熟库(Passport、Lucia、Better Auth)而不是自己写。
4.3 文件上传接口
【场景】创建文件上传 API。
【模板】
用 {{语言}} + {{框架}} 创建文件上传 API:
存储方案:{{本地存储/S3/OSS}}
文件大小限制:{{限制}}
允许格式:{{格式列表}}
接口:
1. POST /upload - 单文件上传
2. POST /upload/batch - 多文件上传
3. POST /upload/presigned - 获取预签名 URL(前端直传 S3)
4. DELETE /upload/:fileId - 删除文件
5. GET /upload/:fileId - 获取文件信息
功能:
- 文件类型校验(MIME type + 文件头校验)
- 文件大小限制
- 文件 Hash 计算(去重)
- 上传进度回调
- 图片自动生成缩略图
- 存储路径按日期组织【说明】大文件场景加分片上传,前端直传 S3 可以减轻服务器带宽压力。
4.4 搜索接口
【场景】创建全文搜索 API。
【模板】
用 {{语言}} + {{框架}} 创建搜索 API:
搜索引擎:{{数据库 LIKE/PostgreSQL 全文搜索/Elasticsearch/Meilisearch}}
搜索实体:{{实体列表}}
接口:
1. GET /search?q={{关键词}}&type={{类型}}&page=1&size=20
功能:
- 关键词分词处理
- 搜索结果高亮
- 按类型筛选
- 按相关度/时间排序
- 搜索建议(autocomplete)
- 热门搜索词统计
- 搜索日志记录【说明】数据量小用数据库全文搜索就够了,数据量大(10w+)才需要引入 Elasticsearch。
4.5 WebSocket 实时通信接口
【场景】创建 WebSocket 实时推送 API。
【模板】
用 {{语言}} + {{框架}} 创建 WebSocket 服务:
通信场景:{{实时聊天/通知推送/协作编辑/数据同步}}
功能:
1. 连接建立和认证(JWT 握手)
2. 心跳检测(30 秒间隔)
3. 断线自动重连(指数退避)
4. 消息广播(发送给所有连接)
5. 房间/频道(按 topic 分组推送)
6. 点对点消息
7. 离线消息队列
8. 连接数监控【说明】WebSocket 服务要单独部署,不要和应用服务混在一起,方便独立扩展。
4.6 第三方 API 集成
【场景】封装第三方服务 API。
【模板】
用 {{语言}} 封装 {{第三方服务}} API:
服务类型:{{支付/邮件/短信/OAuth/云存储}}
SDK 或 HTTP 调用:{{选择}}
要求:
1. 统一的客户端封装类
2. API Key/Secret 从环境变量读取
3. 请求重试机制(3 次,指数退避)
4. 超时配置(连接超时 5s,读取超时 30s)
5. 错误码映射(第三方错误码 → 业务错误码)
6. 请求/响应日志记录
7. Rate Limiting 处理
8. 单元测试(mock 第三方响应)【说明】第三方封装的核心原则是「隔离变化」,第三方 API 变更只影响封装层内部。
4.7 GraphQL 接口
【场景】创建 GraphQL API。
【模板】
用 {{语言}} + {{框架}} 创建 GraphQL API:
数据模型:{{模型描述}}
要求:
1. Schema 定义(Type Definitions)
2. Query 解析器
3. Mutation 解析器
4. Subscription(实时更新,可选)
5. 数据加载优化(DataLoader 解决 N+1)
6. 输入校验(Input Type + 自定义校验)
7. 权限控制(directive 级别)
8. 查询复杂度限制
9. 接口文档(GraphQL Playground)【说明】GraphQL 适合前端驱动的项目,但要注意查询复杂度控制,防止恶意深查询。
4.8 定时任务接口
【场景】创建后台定时任务。
【模板】
用 {{语言}} 创建定时任务:
任务列表:
1. {{任务名}} - {{执行频率}} - {{功能描述}}
2. ...
要求:
1. Cron 表达式配置
2. 任务互斥锁(防止重复执行)
3. 执行日志记录
4. 失败重试和告警
5. 手动触发接口(调试用)
6. 任务执行超时控制
7. 优雅关闭(应用停止时等待任务完成)【说明】分布式环境下定时任务必须加锁,否则多实例会重复执行。
4.9 Webhook 接收接口
【场景】创建接收第三方 Webhook 的 API。
【模板】
用 {{语言}} + {{框架}} 创建 Webhook 接收接口:
来源:{{第三方服务名}}
事件类型:{{事件列表}}
要求:
1. 签名验证(HMAC / RSA)
2. 幂等处理(同一事件不重复处理)
3. 异步处理(收到后立即返回 200,业务逻辑异步执行)
4. 重试支持(第三方重发时能正确处理)
5. 事件日志记录
6. 手动重放功能(调试用)
7. IP 白名单校验(可选)【说明】Webhook 最关键的是幂等性,同一个事件可能收到多次推送。
4.10 批量操作接口
【场景】创建支持批量处理的 API。
【模板】
用 {{语言}} + {{框架}} 创建批量操作接口:
操作类型:{{批量创建/批量更新/批量删除}}
资源:{{资源名}}
单次上限:{{数量限制}}
要求:
1. 请求体为数组格式
2. 单条数据独立校验
3. 部分失败处理(返回成功和失败明细)
4. 事务控制(全部成功或全部回滚,可配置)
5. 批量大小限制
6. 执行进度返回(长时间操作)
7. 并发控制(防止同时提交多个批量请求)【说明】批量接口的响应格式建议包含 { succeeded: [], failed: [{ index, reason }] }。
4.11 数据导出接口
【场景】创建数据导出 API(CSV/Excel/PDF)。
【模板】
用 {{语言}} + {{框架}} 创建数据导出接口:
导出格式:{{CSV/Excel/PDF}}
数据源:{{查询条件/SQL}}
数据量级:{{预估行数}}
要求:
1. 小数据量(<1w):直接返回文件流
2. 大数据量(>1w):异步生成 + 下载链接
3. 流式查询(避免内存溢出)
4. 自定义列映射和格式化
5. 文件名包含时间戳
6. 导出任务状态查询
7. 导出历史记录【说明】大数据量导出一定要用流式处理,不能把所有数据加载到内存。
五、数据库设计模板(11 个)
5.1 用户系统表设计
【场景】设计用户系统相关的数据库表。
【模板】
为 {{项目名}} 设计用户系统的数据库表:
数据库:{{PostgreSQL/MySQL}}
需求:
1. 用户基础信息(用户名、邮箱、头像、状态)
2. 密码存储(bcrypt hash)
3. 手机号(可选,支持国际区号)
4. 用户角色和权限
5. 第三方账号绑定(OAuth)
6. 登录日志
7. 软删除支持
请输出:
1. DDL 建表语句
2. 索引设计
3. 字段注释
4. ER 关系图(Mermaid 格式)【说明】用户表建议用 UUID 作为主键,避免自增 ID 暴露用户量信息。
5.2 电商商品表设计
【场景】设计电商商品模块的数据库表。
【模板】
设计电商商品系统的数据库表:
数据库:{{数据库}}
需求:
1. 商品分类(多级分类树)
2. 商品基础信息(名称、描述、状态)
3. SKU 管理(规格 + 价格 + 库存)
4. 商品图片(排序、主图标记)
5. 商品标签
6. 品牌管理
7. 商品属性(自定义属性键值对)
输出完整的建表语句和 ER 图。【说明】商品和 SKU 分离是电商数据库的核心设计,一个商品可以有多个 SKU(不同颜色、尺寸)。
5.3 内容管理表设计
【场景】设计 CMS 内容管理系统的数据库表。
【模板】
设计内容管理系统的数据库表:
数据库:{{数据库}}
内容类型:{{文章/视频/音频/混合}}
需求:
1. 内容基础信息(标题、摘要、正文)
2. 富文本/Markdown 存储
3. 分类和标签(多对多)
4. 版本历史(草稿、已发布、已归档)
5. 媒体资源关联
6. SEO 字段(slug、meta title、meta description)
7. 发布时间和定时发布
8. 多语言支持(国际化字段)
9. 阅读量和点赞统计【说明】内容版本历史建议用 JSON 字段存储快照,而不是每次创建新版本表记录。
5.4 多租户表设计
【场景】设计支持多租户(多组织/多公司)的数据库。
【模板】
设计多租户数据架构:
数据库:{{数据库}}
隔离方案:{{共享数据库+租户字段/独立 Schema/独立数据库}}
需求:
1. 租户(组织)表
2. 租户成员关系表
3. 租户配置/设置表
4. 业务表关联租户 ID
5. 全局唯一约束处理
6. 租户级别的索引优化
7. 数据迁移方案
输出建表语句,重点说明隔离方案的选择理由。【说明】SaaS 早期推荐共享数据库 + 租户字段的方案,简单且够用。
5.5 权限系统表设计
【场景】设计 RBAC 权限系统的数据库表。
【模板】
设计 RBAC 权限系统表:
数据库:{{数据库}}
权限粒度:{{页面级/按钮级/数据级}}
表设计:
1. 用户表
2. 角色表
3. 权限表(菜单 + 操作)
4. 用户-角色关联表
5. 角色-权限关联表
6. 数据权限规则表(可选)
要求:
- 支持一个用户多个角色
- 支持角色继承
- 权限变更实时生效
- 输出完整 DDL 和初始数据【说明】简单系统用 RBAC0(基本角色分配),复杂系统才需要 RBAC1/2(角色继承、约束)。
5.6 审计日志表设计
【场景】设计操作审计日志表。
【模板】
设计审计日志表:
数据库:{{数据库}}
记录范围:{{关键业务操作/所有操作}}
字段要求:
1. 操作人(用户 ID、IP、User-Agent)
2. 操作类型(CREATE/UPDATE/DELETE/LOGIN/EXPORT)
3. 操作对象(资源类型 + 资源 ID)
4. 变更前后数据(before/after JSON)
5. 操作时间
6. 操作结果(成功/失败 + 失败原因)
考虑:
- 日志表分区策略(按月分区)
- 自动清理策略(保留 N 个月)
- 查询性能(常用查询字段加索引)【说明】审计日志数据量大,建议按月分区,定期归档到冷存储。
5.7 消息通知表设计
【场景】设计站内消息通知系统。
【模板】
设计消息通知系统表:
数据库:{{数据库}}
通知类型:{{系统通知/评论回复/点赞关注/审批提醒}}
表设计:
1. 通知模板表
2. 通知记录表
3. 用户通知设置表(哪些通知开启/关闭)
4. 已读状态表
功能支持:
- 站内通知 + 邮件通知 + 推送通知
- 未读数统计
- 全部已读
- 通知分组【说明】未读数用 Redis 缓存,避免每次查询数据库。
5.8 订单系统表设计
【场景】设计订单相关的数据库表。
【模板】
设计订单系统表:
数据库:{{数据库}}
业务场景:{{电商/SaaS 订阅/服务预约}}
核心表:
1. 订单主表
2. 订单明细表
3. 支付记录表
4. 退款记录表
5. 订单状态变更日志
要求:
- 订单号生成规则(时间 + 序列号 + 随机数)
- 金额用 DECIMAL 存储,不用 FLOAT
- 乐观锁(防止并发更新)
- 软删除
- 完整状态流转记录【说明】订单系统对数据一致性要求极高,金额字段一定要用 DECIMAL 类型。
5.9 数据迁移 SQL 模板
【场景】编写数据库迁移脚本。
【模板】
编写数据库迁移脚本:
数据库:{{数据库}}
迁移类型:{{新增表/修改字段/添加索引/数据修复}}
迁移内容:
{{具体描述要做的变更}}
要求:
1. 生成 UP(正向)和 DOWN(回滚)两个方向的 SQL
2. 大表变更考虑锁表影响(使用 pt-online-schema-change 或 pg_repack)
3. 添加必要的注释
4. 包含数据验证查询
5. 预估执行时间
6. 标记是否需要停机【说明】生产环境数据库变更一定要准备回滚脚本,并在低峰期执行。
5.10 索引优化模板
【场景】分析和优化数据库索引。
【模板】
分析以下 SQL 查询的索引优化方案:
数据库:{{数据库}}
表结构:
{{CREATE TABLE 语句或字段说明}}
慢查询:
{{SQL 语句}}
请分析:
1. 当前索引是否覆盖查询
2. 建议新增的索引
3. 索引列顺序选择
4. 是否需要覆盖索引(避免回表)
5. 是否需要部分索引/条件索引
6. 预计优化效果
7. 索引维护成本评估【说明】不是索引越多越好,每个索引都有写入和空间成本,只给高频查询加索引。
5.11 数据库 Seeder 模板
【场景】生成测试数据。
【模板】
为 {{数据库}} 生成测试数据 Seeder:
表名:{{表名}}
表结构:{{字段列表}}
数据量:{{条数}}
要求:
1. 数据要真实合理(不要用 test1、test2)
2. 关联表数据保持一致性
3. 支持多次运行(先清空或 upsert)
4. 时间数据分布合理
5. 枚举值均匀分布
6. 可选:生成指定边界测试数据【说明】测试数据的质量直接影响开发调试效率,faker 库可以生成逼真的假数据。
六、Bug 修复模板(11 个)
6.1 通用 Bug 诊断
【场景】遇到未知 bug 需要定位原因。
【模板】
我需要修复一个 Bug,请帮我分析:
项目技术栈:{{语言}} + {{框架}}
Bug 描述:{{现象描述}}
复现步骤:
1. {{步骤1}}
2. {{步骤2}}
3. ...
期望行为:{{应该发生什么}}
实际行为:{{实际发生了什么}}
出现频率:{{必现/偶现/特定条件下}}
相关代码:{{粘贴相关代码}}
错误日志:{{粘贴错误日志}}
请按以下步骤分析:
1. 可能的原因列表(按概率排序)
2. 每个原因的验证方法
3. 推荐的修复方案
4. 修复后需要验证的测试场景【说明】Bug 修复的关键是把信息说全:复现步骤、期望行为、实际行为、错误日志。信息越完整,AI 分析越准确。
6.2 前端渲染错误
【场景】页面渲染异常。
【模板】
页面渲染异常,帮我排查:
框架:{{框架}}
页面路径:{{路由路径}}
异常现象:{{白屏/内容不更新/样式错乱/闪烁}}
浏览器控制台错误:{{错误信息}}
组件代码:{{组件代码}}
请检查:
1. 数据初始值和状态更新逻辑
2. 条件渲染的边界情况
3. Key 属性是否正确
4. 副作用依赖数组是否完整
5. 内存泄漏(未清理的订阅/定时器)
6. SSR/CSR 不匹配(如果适用)【说明】前端白屏 80% 是 JS 运行时错误导致的,先看控制台报错。
6.3 接口报错排查
【场景】API 请求返回错误。
【模板】
API 接口报错,帮我排查:
请求方式:{{GET/POST/PUT/DELETE}}
请求地址:{{URL}}
请求参数:
```json
{{请求体}}响应状态码:{{状态码}} 响应内容:
json
{{响应体}}后端代码(Controller + Service):
{{代码}}请分析:
- 状态码含义和常见原因
- 请求参数是否有问题
- 后端代码可能的异常点
- 数据库查询是否异常
- 修复建议和验证方法
【说明】常见状态码速查:400 参数错误、401 未认证、403 无权限、404 资源不存在、500 服务器错误。
### 6.4 性能问题排查
【场景】页面或接口性能异常。
【模板】性能问题排查:
问题类型:{{页面加载慢/接口响应慢/内存泄漏/CPU 占用高}} 技术栈:{{技术栈}} 量化数据:
- 当前指标:{{如 FCP 3.5s / API 响应 2s / 内存 500MB}}
- 目标指标:{{如 FCP < 1.5s / API 响应 < 200ms}}
相关代码/配置:
{{代码}}请从以下维度分析:
- 瓶颈定位方法
- 可能的根因
- 优化方案(按投入产出比排序)
- 优化后的验证方式
【说明】性能优化一定要有量化数据,否则无法判断是否改善。
### 6.5 并发/竞态 Bug
【场景】并发操作导致的数据问题。
【模板】并发问题排查:
问题描述:{{如重复提交/数据覆盖/超卖}} 技术栈:{{后端语言+框架+数据库}} 发生场景:{{什么操作触发}} 相关代码:
{{代码}}请分析:
- 竞态条件产生的原因
- 数据一致性影响范围
- 修复方案(数据库锁/分布式锁/乐观锁/队列)
- 方案对比和推荐理由
- 修复后的并发测试方案
【说明】并发问题的修复方案选择取决于场景:乐观锁适合冲突少的场景,悲观锁适合冲突频繁的场景。
### 6.6 内存泄漏排查
【场景】应用内存持续增长。
【模板】内存泄漏排查:
应用类型:{{前端应用/后端服务/移动端}} 现象:{{内存从 X MB 持续增长到 Y MB}} 触发条件:{{持续运行 N 小时后 / 操作 N 次后}} 技术栈:{{技术栈}}
相关代码:
{{代码}}请检查常见的内存泄漏模式:
- 未清理的事件监听器
- 未取消的定时器/轮询
- 闭包引用
- 全局变量累积
- 未关闭的数据库连接/文件句柄
- 缓存无上限增长
- 订阅未取消
给出排查步骤和修复方案。
【说明】前端用 Chrome DevTools Memory 面板,后端用 heapdump 分析。
### 6.7 类型错误修复
【场景】TypeScript 类型报错。
【模板】TypeScript 类型错误修复:
错误信息:
{{TS 错误信息}}相关代码:
{{代码}}请:
- 解释错误原因
- 给出修复方案
- 说明为什么这样修复(而不是用 as any 或 @ts-ignore)
- 如果有多种修复方式,列出各自的优缺点
【说明】不要图快用 `as any` 或 `@ts-ignore`,它会掩盖真正的问题。
### 6.8 构建/编译错误
【场景】项目构建失败。
【模板】构建错误修复:
项目技术栈:{{技术栈}} 构建工具:{{Webpack/Vite/TSC/esbuild}} 错误输出:
{{完整错误日志}}环境信息:
- Node.js 版本:{{版本}}
- 包管理器:{{pnpm/npm/yarn}}
- 操作系统:{{系统}}
之前是否正常:{{是/否/不确定}} 最近做了什么变更:{{依赖更新/代码修改/环境变更}}
请分析:
- 错误原因
- 修复步骤
- 如何避免类似问题再次发生
【说明】构建错误通常是环境或依赖问题,先检查 Node 版本和依赖版本是否与 CI 一致。
### 6.9 第三方库兼容性问题
【场景】第三方库升级或集成出错。
【模板】第三方库问题排查:
库名和版本:{{库名@版本}} 问题描述:{{报错/行为异常/类型不兼容}} 集成方式:{{直接引用/封装后使用}}
错误信息:
{{错误信息}}项目环境:
- 框架:{{框架}}
- 相关依赖版本:{{列表}}
请分析:
- 是否是已知的 breaking change
- 是否有 issue 或 workaround
- 降级方案 vs 适配方案
- 替代库推荐(如果问题无法解决)
【说明】升级第三方库之前先查 CHANGELOG 和 GitHub Issues,大部分问题别人都遇到过。
### 6.10 环境相关问题
【场景】开发/测试/生产环境不一致导致的问题。
【模板】环境问题排查:
问题描述:{{在 A 环境正常,B 环境异常}} 环境差异:
- 开发环境:{{Node 版本/OS/数据库版本}}
- 生产环境:{{Node 版本/OS/数据库版本}}
错误表现:{{错误信息或异常行为}} 相关配置:
{{环境变量/配置文件/Dockerfile}}请分析:
- 可能的环境差异因素
- 快速验证方法
- 修复方案
- 如何统一开发/生产环境
【说明】Docker 是解决环境一致性问题的最佳方案,但也要注意基础镜像的版本差异。
### 6.11 偶现 Bug 分析
【场景】难以稳定复现的偶现 bug。
【模板】偶现 Bug 分析:
Bug 描述:{{现象}} 出现频率:{{大约 N 次/M 次操作}} 已知规律:{{时间段/用户/操作路径/设备}} 已排除的因素:{{列表}}
相关代码:
{{代码}}请:
- 列出可能导致偶现的原因(时序问题、网络延迟、数据边界、缓存等)
- 设计复现方案(构造特定数据、模拟网络条件)
- 添加防御性代码的建议
- 监控方案(如何追踪下次出现时的上下文)
【说明】偶现 bug 的修复策略:加日志 → 复现 → 定位 → 修复 → 验证。不要猜,要靠数据。
---
## 七、代码重构模板(11 个)
### 7.1 函数拆分
【场景】将长函数拆分为多个小函数。
【模板】请帮我重构这个函数,将其拆分为多个职责单一的小函数:
当前代码:
{{函数代码}}要求:
- 每个函数只做一件事
- 函数名清晰表达其功能
- 保持原有接口不变(对外行为一致)
- 添加必要的类型定义
- 说明拆分理由
- 拆分后的单元测试建议
【说明】函数拆分的判断标准:超过 30 行的函数、有超过两层嵌套、做了两件以上的事。
### 7.2 组件拆分
【场景】将大组件拆分为小组件。
【模板】请帮我重构这个组件,拆分为更小的可复用组件:
框架:{{框架}} 当前组件代码:
{{组件代码}}要求:
- 按职责拆分(UI 展示、数据获取、状态管理)
- 提取可复用部分到独立组件
- 组件间通过 props 通信,避免隐式依赖
- 自定义 Hook 封装状态逻辑
- 保持原有功能不变
- 输出拆分后的组件树结构
【说明】组件超过 300 行就该考虑拆分了。拆分粒度:一个组件对应一个可视区域或一个独立功能。
### 7.3 设计模式应用
【场景】用设计模式改善代码结构。
【模板】请用合适的设计模式重构以下代码:
当前代码:
{{代码}}问题:{{大量 if-else / 重复代码 / 紧耦合 / 难以扩展}}
要求:
- 选择合适的设计模式
- 解释为什么选择这个模式
- 输出重构后的代码
- 说明重构前后的对比
- 评估是否过度设计
【说明】设计模式不是越多越好,只有在真正遇到「代码难以扩展」的问题时才引入。
### 7.4 错误处理优化
【场景】改善代码的错误处理逻辑。
【模板】优化以下代码的错误处理:
当前代码:
{{代码}}问题:{{错误被吞掉 / 错误信息不清晰 / 缺少边界处理}}
要求:
- 定义业务错误类型体系
- 统一错误处理流程
- 错误日志记录(包含上下文信息)
- 用户友好的错误提示
- 重试/降级策略(适用于网络请求)
- 不要使用空的 catch 块
【说明】错误处理的三个层次:捕获 → 记录 → 恢复(或优雅降级)。
### 7.5 性能优化重构
【场景】优化代码性能。
【模板】优化以下代码的性能:
当前代码:
{{代码}}性能问题:{{渲染卡顿/接口慢/内存高/包体积大}} 当前指标:{{数据}} 目标指标:{{数据}}
请按优先级给出优化方案:
- 低成本高收益的优化(缓存、懒加载、防抖)
- 中等成本的优化(算法优化、数据结构调整)
- 高成本但收益大的优化(架构调整、技术方案替换)
每个方案说明:预期收益、实现成本、风险。
【说明】性能优化遵循二八原则:20% 的优化解决 80% 的问题,先做低成本的。
### 7.6 API 接口重构
【场景】重构 API 接口的代码结构。
【模板】重构以下 API 接口代码:
当前代码:
{{Controller + Service + Repository 代码}}问题:{{Controller 太重/业务逻辑散落/缺少校验/无统一响应}}
要求:
- Controller 层只做 HTTP 相关(参数解析、响应包装)
- Service 层做业务编排
- Repository 层做数据访问
- 统一请求校验
- 统一响应格式
- 统一错误处理
- 输出重构后的代码结构
【说明】三层架构的核心价值是「每层只关心自己的事」,修改数据源不影响业务逻辑。
### 7.7 状态管理重构
【场景】优化前端状态管理方案。
【模板】重构以下状态管理代码:
框架:{{框架}} 当前状态管理代码:
{{代码}}问题:{{状态散落/重复请求/状态同步复杂/组件耦合}}
要求:
- 区分服务端状态和客户端状态
- 服务端状态用数据请求库管理(React Query / SWR)
- 客户端状态按作用域选择(组件内 / Context / 全局 Store)
- 减少不必要的状态(能用计算得到的就不要存储)
- 输出重构后的状态架构图
【说明】大多数前端应用不需要全局状态管理,React Query 能解决 80% 的数据请求问题。
### 7.8 类型系统优化
【场景】改善 TypeScript 类型设计。
【模板】优化以下 TypeScript 类型定义:
当前类型定义:
{{类型代码}}问题:{{any 过多/类型不安全/重复定义/类型推导失败}}
要求:
- 消除所有 any(用 unknown 替代并收窄)
- 提取公共类型为工具类型
- 使用泛型增加灵活性
- 使用 const assertion 和字面量类型
- 添加 JSDoc 注释
- 类型测试(确保类型行为符合预期)
【说明】TypeScript 类型的目标是「让不正确的用法在编译时报错」,不是「给每个变量标注类型」。
### 7.9 配置文件整理
【场景】整理和优化项目配置文件。
【模板】整理项目的配置文件:
项目类型:{{项目类型}} 当前配置文件:
{{粘贴配置内容}}要求:
- 添加注释说明每个配置项的作用
- 合并重复的配置
- 提取公共配置到 base 文件
- 按环境拆分的配置用继承减少重复
- 检查是否有过时/废弃的配置项
- 输出整理后的配置
【说明】配置文件加注释是容易被忽略但很有价值的事情,三个月后你自己也不记得为什么这么配。
### 7.10 依赖优化
【场景】优化项目依赖(减包体积、去冗余依赖)。
【模板】分析和优化项目依赖:
项目类型:{{项目类型}} 当前依赖(package.json):
{{dependencies 列表}}请分析:
- 包体积分析(哪些依赖最大)
- 是否有功能重叠的依赖
- 是否有可以替换为更轻量方案的依赖
- 是否有过时的依赖需要升级
- devDependencies 和 dependencies 分类是否正确
- 是否有可以用 native API 替代的依赖
- 输出优化建议和预期收益
【说明】前端项目用 `npx bundle-analyzer` 或 `source-map-explorer` 分析包体积。
### 7.11 遗留代码迁移
【场景】将旧技术栈代码迁移到新技术栈。
【模板】帮我制定遗留代码迁移方案:
旧代码:
- 技术栈:{{旧技术}}
- 代码量:{{规模}}
- 核心逻辑:{{描述}}
新代码:
- 技术栈:{{新技术}}
- 迁移策略:{{渐进式迁移/一次性重写}}
要求:
- 迁移风险评估
- 分阶段迁移计划
- 新旧系统并行运行方案
- 数据迁移方案
- 回滚策略
- 每阶段的验证标准
【说明】遗留系统迁移最忌讳「大爆炸式重写」,渐进式迁移(Strangler Fig 模式)更安全。
---
## 八、测试编写模板(11 个)
### 8.1 单元测试
【场景】为函数编写单元测试。
【模板】为以下函数编写单元测试:
语言/框架:{{语言}} + {{测试框架}} 函数代码:
{{函数代码}}测试要求:
- 正常输入的测试用例
- 边界值测试(空值、零值、最大值)
- 异常输入测试(非法参数、类型错误)
- 每个用例有清晰的描述(test description)
- 使用 arrange-act-assert 模式
- Mock 外部依赖
- 覆盖率达到 80% 以上
【说明】单元测试的重点是「行为」而非「实现」,测试函数做什么,而不是怎么做。
### 8.2 组件测试
【场景】为 UI 组件编写测试。
【模板】为以下组件编写测试:
框架:{{框架}} 测试库:{{Testing Library / Vitest}} 组件代码:
{{组件代码}}测试场景:
- 默认渲染(传入最小 props)
- 各种 props 组合
- 用户交互(点击、输入、选择)
- 异步操作(数据加载、提交)
- 错误状态展示
- 空状态展示
- 可访问性(键盘操作、ARIA 属性)
【说明】组件测试关注用户可见的行为,不测试内部实现细节(state、私有方法)。
### 8.3 API 接口测试
【场景】为 API 接口编写集成测试。
【模板】为以下 API 编写集成测试:
框架:{{框架}} 测试工具:{{Jest + Supertest / Pytest}} 接口代码:
{{Controller 代码}}测试场景:
- 正常请求(200 响应)
- 参数校验失败(400 响应)
- 未认证(401 响应)
- 无权限(403 响应)
- 资源不存在(404 响应)
- 并发请求
- 数据库操作验证(创建/更新/删除)
- 分页和排序验证
测试前自动准备测试数据,测试后自动清理。
【说明】API 测试用真实的 HTTP 请求和测试数据库,不要 mock 数据库层。
### 8.4 E2E 测试
【场景】编写端到端测试。
【模板】为以下用户流程编写 E2E 测试:
测试工具:{{Playwright / Cypress}} 用户流程:{{描述完整操作流程}}
测试步骤:
- {{步骤1}}
- {{步骤2}}
- ...
要求:
- 使用 page object 模式
- 测试数据隔离
- 等待策略(避免硬编码等待时间)
- 截图和录屏配置
- 多浏览器测试(Chromium、Firefox、WebKit)
- CI 集成配置
【说明】E2E 测试成本高但价值大,优先覆盖核心业务流程(注册、下单、支付)。
### 8.5 Mock 数据生成
【场景】生成测试用的 Mock 数据。
【模板】生成测试 Mock 数据:
数据类型:{{数据类型描述}} 数据量:{{条数}} 语言:{{TypeScript/Python/其他}}
要求:
- 数据真实合理(用 faker 库生成)
- 字段类型正确
- 关联数据一致
- 包含边界测试数据(空字符串、特殊字符、超长文本)
- 导出为 JSON / TypeScript 常量 / Factory 函数
【说明】Mock 数据工厂函数比固定 JSON 更灵活,每次调用生成不同数据。
### 8.6 测试覆盖率报告
【场景】分析和提升测试覆盖率。
【模板】分析测试覆盖率报告,给出改进建议:
当前覆盖率数据:
- Statements: {{百分比}}
- Branches: {{百分比}}
- Functions: {{百分比}}
- Lines: {{百分比}}
未覆盖的代码区域:
要求:
- 优先补充哪些测试(按业务重要性排序)
- 哪些代码不需要测试(纯展示组件、配置常量)
- 目标覆盖率建议
- 补充测试的示例代码
【说明】100% 覆盖率不是目标,核心业务逻辑 80%+ 覆盖率更有实际价值。
### 8.7 性能测试
【场景】编写性能/压力测试。
【模板】编写性能测试:
测试目标:{{API 接口/数据库查询/前端页面}} 测试工具:{{k6/Artillery/Lighthouse}} 目标指标:
- 响应时间 P95 < {{毫秒}}
- QPS > {{数值}}
- 错误率 < {{百分比}}
测试场景:
- 基准测试(单用户,验证基本性能)
- 负载测试(逐步增加并发用户)
- 压力测试(超出预期负载)
- 持久测试(持续运行 N 小时)
输出测试脚本和分析报告模板。
【说明】性能测试要在接近生产环境的条件下进行,本地测试结果参考价值有限。
### 8.8 安全测试
【场景】编写安全检查测试。
【模板】编写安全检查清单和测试:
应用类型:{{Web 应用/API/移动端}} 技术栈:{{技术栈}}
检查项目:
- SQL 注入
- XSS(存储型/反射型/DOM型)
- CSRF
- 认证绕过
- 权限越权(水平/垂直)
- 敏感信息泄露
- 文件上传漏洞
- 速率限制
- 依赖安全漏洞
输出:
- 每个检查项的测试方法
- 自动化测试脚本(适用的场景)
- 修复建议
【说明】安全测试建议集成到 CI 流程中,每次发布前自动扫描。
### 8.9 回归测试
【场景】为 bug 修复编写回归测试。
【模板】为以下 Bug 修复编写回归测试:
Bug 描述:{{原始 bug 描述}} 修复方案:{{修复概述}} 相关代码:
{{修复后的代码}}要求:
- 测试用例能复现原始 bug(修复前应该失败)
- 验证修复后的正确行为
- 覆盖相关的边界情况
- 测试命名包含 Bug ID(便于追溯)
- 添加注释说明这个测试防止什么问题再次发生
【说明】每个 bug 修复都应该有一个对应的回归测试,这是防止同一 bug 再次出现的最有效手段。
### 8.10 Snapshot 测试
【场景】为组件输出编写快照测试。
【模板】为以下组件编写快照测试:
框架:{{框架}} 组件代码:
{{组件代码}}测试场景:
- 默认渲染快照
- 不同 props 的快照
- 不同状态的快照(loading、error、empty)
- 交互后的快照
注意:
- 说明何时应该更新快照
- 避免过于脆弱的快照(避免随机值、时间戳)
- 配合行为测试使用,不要只依赖快照
【说明】快照测试适合稳定不常变的组件(Icon、Logo),频繁变化的组件用行为测试更好。
### 8.11 测试辅助工具
【场景】编写测试工具函数或自定义 Matcher。
【模板】编写测试辅助工具:
需求:{{自定义断言/数据工厂/Mock 工具/测试 Setup}} 测试框架:{{Jest/Vitest/Playwright}}
要求:
- 封装重复的测试逻辑
- 提供清晰的 API
- 类型安全
- 包含使用示例
- 本身的单元测试
【说明】当发现三个以上的测试有相同的 setup 逻辑时,就该提取为公共工具了。
---
## 九、文档生成模板(11 个)
### 9.1 README 生成
【场景】为项目生成 README 文档。
【模板】为以下项目生成 README.md:
项目名:{{项目名}} 项目类型:{{Web应用/库/CLI工具/API服务}} 技术栈:{{技术栈列表}} 项目描述:{{一句话描述}}
包含以下章节:
- 项目名称和简介(带徽章)
- 功能特性列表
- 快速开始(安装 + 运行)
- 项目结构说明
- 开发指南(环境要求、安装依赖、启动命令)
- 构建和部署
- 技术栈列表
- 贡献指南
- License
【说明】README 是项目的门面,「快速开始」部分要确保新手能照着跑起来。
### 9.2 API 文档
【场景】为 API 接口生成文档。
【模板】为以下 API 生成文档:
接口列表:
{{路由定义或 Controller 代码}}文档格式:{{Markdown/OpenAPI/Swagger}}
每个接口需要包含:
- 请求方法和路径
- 功能描述
- 请求参数(Path / Query / Body)
- 请求示例
- 响应格式(成功和失败)
- 响应示例
- 错误码说明
- 认证要求
【说明】API 文档最好从代码注释自动生成(JSDoc → OpenAPI),保持文档和代码同步。
### 9.3 组件文档
【场景】为 UI 组件生成使用文档。
【模板】为以下组件生成文档:
组件代码:
{{组件代码}}文档内容:
- 组件名称和描述
- 使用示例(基础用法 + 常见场景)
- Props 表格(属性名、类型、默认值、说明)
- 事件列表
- 插槽说明(如果适用)
- 样式变量/自定义方式
- 设计规范(何时使用/何时不使用)
- 可访问性说明
【说明】组件文档配合 Storybook 效果最好,可以在线预览和交互。
### 9.4 数据库文档
【场景】为数据库表生成文档。
【模板】为以下数据库表生成文档:
DDL 语句:
{{CREATE TABLE 语句}}文档内容:
- ER 关系图(Mermaid 格式)
- 表说明(用途、所属模块)
- 字段说明表格(字段名、类型、约束、默认值、注释)
- 索引说明(索引名、列、类型、用途)
- 关联关系说明
- 常见查询示例
- 设计决策说明(为什么这样设计)
【说明】数据库文档和代码容易脱节,建议从 DDL 注释自动生成。
### 9.5 部署文档
【场景】编写部署指南。
【模板】为以下项目编写部署文档:
项目类型:{{项目类型}} 部署目标:{{Vercel/AWS/Docker/K8s}} 环境:{{开发/预发/生产}}
文档内容:
- 前置条件(账号、工具、权限)
- 环境变量配置清单
- 构建步骤
- 部署命令
- 健康检查验证
- 回滚步骤
- 常见问题排查
- 监控和告警配置
【说明】部署文档的核心标准:新人照着能独立完成部署。
### 9.6 代码注释生成
【场景】为代码添加注释。
【模板】为以下代码添加注释:
语言:{{语言}} 代码:
{{代码}}注释要求:
- 函数级 JSDoc/docstring(参数、返回值、异常、示例)
- 复杂逻辑的行内注释(解释「为什么」而不是「做了什么」)
- TODO 标记(已知问题和待优化项)
- 不要注释显而易见的代码
- 注释用中文
【说明】好代码本身就是文档,注释的价值在于解释「为什么」,而非复述代码。
### 9.7 CHANGELOG 生成
【场景】生成版本变更日志。
【模板】根据以下 Git 提交记录生成 CHANGELOG:
版本:{{版本号}} 提交范围:{{上一个tag}}..{{当前tag}} 提交记录:
{{git log 输出}}格式要求:
- 按 Keep a Changelog 规范分类
- 分为:Added / Changed / Fixed / Removed / Deprecated / Security
- 每条变更关联 Issue 或 PR 编号
- 突出 breaking changes
- 底部列出贡献者
【说明】自动化生成 CHANGELOG 推荐用 `changesets` 或 `conventional-changelog`。
### 9.8 迁移指南
【场景】编写版本迁移指南。
【模板】编写版本迁移指南:
从版本:{{旧版本}} 到版本:{{新版本}} 主要变更:{{Breaking Changes 列表}}
文档内容:
- 变更概述
- 环境要求变更(Node.js、依赖版本)
- 配置变更(对比旧/新配置)
- API 变更(废弃的接口和新替代)
- 数据迁移步骤(如果有)
- 代码迁移步骤(before → after 代码对比)
- 已知问题
- 回退方案
【说明】迁移指南最重要的是「before → after」代码对比,用户最关心「我该怎么改」。
### 9.9 架构决策记录(ADR)
【场景】记录重要的技术决策。
【模板】编写架构决策记录(ADR):
决策标题:{{如「选择 PostgreSQL 而非 MySQL」}} 状态:{{Proposed / Accepted / Deprecated}}
内容:
- 背景:为什么需要做这个决策
- 决策:最终选了什么方案
- 备选方案:考虑过哪些其他方案
- 对比分析:各方案的优缺点
- 结论:为什么选了这个方案
- 影响:这个决策带来的约束和后续工作
【说明】ADR 的价值在于三个月后回头看,能理解当初为什么做了这个决定。
### 9.10 贡献指南
【场景】编写项目贡献指南(CONTRIBUTING.md)。
【模板】为开源项目编写贡献指南:
项目名:{{项目名}} 技术栈:{{技术栈}} 当前贡献者规模:{{个人/小团队/社区}}
内容:
- 行为准则
- 如何开始(fork → clone → install → dev)
- 项目结构说明
- 开发规范(代码风格、命名约定、提交信息格式)
- 如何提 Bug Report(模板)
- 如何提 Feature Request
- 如何提交 PR(分支命名、测试要求、Review 流程)
- Code Review 标准
- 发布流程
【说明】贡献指南是开源项目的入口,写得越清晰,收到高质量 PR 的概率越高。
### 9.11 故障复盘文档
【场景】编写线上故障复盘报告。
【模板】编写故障复盘报告:
故障时间:{{时间段}} 影响范围:{{受影响的用户/功能}} 严重程度:{{P0/P1/P2}}
文档内容:
- 故障概述(一句话描述)
- 时间线(发现 → 响应 → 定位 → 修复 → 验证)
- 根因分析(5 Whys 方法)
- 影响评估
- 修复措施
- 改进措施(短期 + 长期)
- 经验教训
- Action Items(负责人 + 截止日期)
【说明】复盘的目的不是追责,而是找到系统性改进的机会。
---
## 模板选择速查表
面对一个开发任务,怎么快速找到合适的模板?下面这张表可以帮你定位。
| 开发阶段 | 可用模板数 | 核心模板 | 补充模板 |
|----------|-----------|---------|---------|
| 项目启动 | 12 | 全栈脚手架、前端初始化、后端初始化 | Monorepo、Serverless、AI 应用 |
| 页面开发 | 11 | CRUD 列表页、表单页、详情页 | Dashboard、落地页、搜索结果页 |
| 组件开发 | 11 | 按钮、表格、模态框 | 搜索框、文件上传、无限滚动 |
| API 开发 | 11 | RESTful CRUD、认证、文件上传 | WebSocket、GraphQL、定时任务 |
| 数据库 | 11 | 用户表、权限表、订单表 | 多租户、审计日志、索引优化 |
| Bug 修复 | 11 | 通用诊断、前端渲染、接口报错 | 性能排查、内存泄漏、偶现 Bug |
| 代码重构 | 11 | 函数拆分、组件拆分、API 重构 | 状态管理、类型优化、依赖优化 |
| 测试编写 | 11 | 单元测试、组件测试、API 测试 | E2E、回归测试、性能测试 |
| 文档生成 | 11 | README、API 文档、部署文档 | ADR、CHANGELOG、故障复盘 |
## 不同工具场景选择
| 使用场景 | 推荐模板组合 | 说明 |
|----------|------------|------|
| 个人 Side Project | 前端初始化 + CRUD 列表页 + RESTful CRUD | 快速出活,先跑起来 |
| 公司后台管理系统 | 全栈脚手架 + CRUD 列表页 + 表单页 + 权限表 + 审计日志 | 标准化程度高 |
| SaaS 产品 | Monorepo + Dashboard + 多租户表 + 订单表 + 认证接口 | 完整的商业系统 |
| 开源项目 | CLI 工具 + 组件开发 + README + 贡献指南 + CHANGELOG | 注重文档和社区 |
| AI 应用 | AI 应用初始化 + 落地页 + WebSocket + 性能测试 | 注重交互和体验 |
## 模板调整要点
| 调整维度 | 考虑因素 | 具体操作 |
|----------|---------|---------|
| 技术栈适配 | 语言和框架差异 | 替换变量值,调整目录结构和配置项 |
| 项目规模 | 小型/中型/大型 | 小型项目简化配置,大型项目增加分层和监控 |
| 团队规范 | 既有代码约定 | 遵循已有的命名风格、目录结构、组件模式 |
| 部署环境 | 云平台/自建/混合 | 调整部署相关的配置和脚本 |
| 安全要求 | 内部系统/公开系统 | 公开系统增加安全校验、限速、审计 |
| 性能要求 | 低流量/高并发 | 高并发场景增加缓存、队列、分库分表 |
## 完整模板对比
| 对比维度 | 简单模板 | 完整模板 |
|----------|---------|---------|
| Prompt 长度 | 50-100 字 | 200-500 字 |
| 上下文信息 | 只说做什么 | 包含技术栈、约束、输出要求 |
| 输出格式 | 不指定 | 明确指定代码格式、目录结构 |
| 质量要求 | 能跑就行 | 包含错误处理、测试、文档 |
| 适用场景 | 快速原型 | 生产代码 |
| AI 输出质量 | 需要多轮调整 | 一次输出可用度 80%+ |
| 推荐度 | 学习和实验用 | 正式项目推荐使用 |
## 实战案例
### 案例一:用模板完成一个博客系统后端
假设你要用 Node.js + Express + PostgreSQL 搭建一个博客系统后端。以下是按顺序使用模板的过程。
**第一步:项目初始化**
使用「1.3 后端 API 项目初始化」模板,替换变量:
- 语言:TypeScript
- 框架:Express
- 数据库:PostgreSQL
- ORM:Prisma
- 认证方式:JWT
AI 会输出完整的项目结构、数据库连接配置、中间件代码。
**第二步:数据库设计**
使用「5.3 内容管理表设计」模板,加上用户表和标签表:
AI 输出 posts、users、tags、post_tags 表的 DDL,以及 ER 图。
**第三步:API 开发**
使用「4.1 RESTful CRUD 接口」模板,资源设为「文章」:
AI 输出文章的 6 个 CRUD 接口,包含参数校验和统一响应格式。
再使用「4.2 认证接口」模板完成登录注册。
**第四步:测试编写**
使用「8.3 API 接口测试」模板,对上一步的接口编写集成测试。
**第五步:文档生成**
使用「9.2 API 文档」模板,生成完整的 API 文档。
整个过程大约 5 轮对话,每轮使用一个模板,最终得到一个结构完整、有测试、有文档的博客后端。
### 案例二:用模板完成一个 SaaS 仪表盘前端
假设你要用 Next.js + Tailwind CSS + shadcn/ui 做一个 SaaS 仪表盘。
**第一步:项目初始化**
使用「1.2 前端项目初始化」模板:
- 框架:Next.js 15 App Router
- UI 组件库:shadcn/ui
- CSS 方案:Tailwind CSS
- 状态管理:Zustand + React Query
**第二步:Dashboard 页面**
使用「2.4 Dashboard 仪表盘」模板:
- 统计卡片:用户数、收入、订单数、转化率
- 趋势图:近 30 天收入折线图
- 最近订单列表
**第三步:列表页和详情页**
使用「2.1 CRUD 列表页」模板创建用户列表,使用「2.3 详情页」模板创建用户详情。
**第四步:组件封装**
使用「3.2 数据表格组件」和「3.4 搜索输入框组件」模板,封装通用组件。
**第五步:编写测试**
使用「8.2 组件测试」模板为核心组件编写测试。
---
## 如何选择和使用 Prompt 模板
下面的流程图展示了从「接到开发任务」到「使用模板完成」的完整决策路径。
```mermaid
flowchart TD
A[接到开发任务] --> B{任务类型是什么?}
B -->|创建新项目| C[项目初始化模板组]
B -->|开发页面| D[页面生成模板组]
B -->|开发组件| E[组件开发模板组]
B -->|开发接口| F[API 开发模板组]
B -->|设计数据库| G[数据库设计模板组]
B -->|修复 Bug| H[Bug 修复模板组]
B -->|优化代码| I[代码重构模板组]
B -->|编写测试| J[测试编写模板组]
B -->|写文档| K[文档生成模板组]
C --> L[选择最匹配的模板]
D --> L
E --> L
F --> L
G --> L
H --> L
I --> L
J --> L
K --> L
L --> M[替换模板变量]
M --> N[补充项目特定信息]
N --> O[发送给 AI]
O --> P{输出质量满意吗?}
P -->|满意| Q[应用到代码中]
P -->|不满意| R{哪里不满意?}
R -->|缺少上下文| S[补充更多信息重新发送]
R -->|格式不对| T[指定输出格式重新发送]
R -->|逻辑错误| U[指出错误点要求修正]
S --> O
T --> O
U --> O
Q --> V[Review 并调整]
V --> W[完成]使用检查清单
在使用模板之前,对照以下清单确认准备工作是否到位:
- [ ] 明确了任务类型(属于 9 个分类中的哪一类)
- [ ] 确定了技术栈(语言、框架、工具链版本)
- [ ] 准备好了项目上下文(现有代码结构、命名规范、已有依赖)
- [ ] 模板中的变量已经全部替换完成
- [ ] 补充了模板之外的项目特定信息(业务规则、安全要求、性能要求)
- [ ] 指定了输出格式(代码格式、目录结构、文件命名)
- [ ] 对于复杂任务,已拆分为多个模板分步执行
- [ ] AI 输出后进行了 Review,而不是直接复制粘贴
- [ ] 关键代码已经过验证(typecheck、lint、测试)
- [ ] 模板使用后记录了调整经验,方便下次优化模板
模板管理的进阶建议
当你的模板积累到一定数量后,需要系统地管理它们:
建立个人模板库:把常用的模板整理到一个 Markdown 文件或 Notion 数据库中,按分类组织,加上标签和使用频率。
版本化你的模板:模板也会迭代,用 Git 管理模板文件,记录每次修改的原因(「加上了错误处理要求,因为上次 AI 输出的代码没有异常处理」)。
团队共享:把模板放入团队的知识库或项目的 .cursor/rules 或 CLAUDE.md 中,让 AI 工具在每次对话中自动引用这些规范。
反馈循环:每次使用模板后,记录「AI 输出质量」和「需要手动调整的地方」,定期回顾和优化模板。
小结
本文汇总了 9 大分类、90+ 个 AI 编程 Prompt 模板,覆盖从项目初始化到文档生成的完整开发流程。每个模板都包含场景说明、可直接复制的模板正文和使用建议。
核心要点回顾:
- 模板是资产 — 好的 Prompt 值得沉淀和复用
- 变量替换是关键 — 模板中的
{{变量}}要根据项目实际替换 - 上下文越充分,输出越好 — 不要怕 Prompt 太长,信息完整比简短更重要
- 分步执行复杂任务 — 一个模板解决一个问题,不要把所有需求堆到一个 Prompt
- Review 不可跳过 — AI 的输出不一定正确,必须人工验证
- 持续优化模板 — 记录使用经验,迭代改进模板
把这些模板当作你的编程工具箱,遇到问题时先看看有没有对应的模板,改改变量就能用。随着使用经验的积累,你会逐渐形成自己的模板体系。
参考资料
- Prompt 编写模式:如何将思维框架赋予机器 — 黄峰达的开源书籍,系统介绍 Prompt 编写模式论
- The AI Prompt Library — 50 Templates for Common Coding Patterns — 50 个编程场景模板,按 UI、API、数据库、调试分类
- PromptKit — Premium AI Coding Prompt Library — 开源的 CLAUDE.md 和 .cursorrules 模板库
- AI Prompts for Developers: 50 Templates — 面向开发者的 50 个实用模板
- Prompts Library — Research-backed prompt templates for Cursor — Cursor 社区的研究支撑模板库
- Claude Code Templates: 1000+ Agents, Commands, Skills — Claude Code 模板市场,包含 Agent 和 Skill 模板
- 提示模板库构建:打造个人高效AI编程助手 — 如何构建个人编程提示词库
- Prompt Engineering Best Practices 2026 — 2026 年 Prompt 工程最佳实践清单