When AI is used for programming, the biggest difference between a useful answer and unusable output often comes down to prompt structure. Vague requests tend to produce generic code, while precise prompts make it far easier to get code that matches project conventions, dependencies, and business rules.
This prompt library is built around real development scenarios. It starts with a universal structured framework, then expands into backend, frontend, and scripting templates, and finally adds project-level standards plus a review checklist for checking AI-generated code before it lands in a codebase.
A universal prompt structure that works across scenarios
A reliable coding prompt usually contains four parts:
- Scenario: what kind of development task this is
- Requirement: the exact feature or goal
- Constraints: stack, conventions, limits, and dependencies
- Output format: what kind of result should be returned
This structure reduces ambiguity and makes it much easier for the model to generate code that can actually be used.
Core template
# 场景定位
{开发场景：如“Java 后端订单模块 DTO 生成”“Python 数据处理脚本”“Vue 前端表单组件”}
# 需求描述
{具体功能/目标，分点列出核心要求，避免模糊表述}
1. 核心功能：{如“生成用户查询DTO，包含3个字段”“实现Excel数据读取与过滤”}
2. 关键细节：{如“字段需非空校验”“过滤条件为日期大于2025-01-01”}
# 约束条件
1. 技术栈：{如“Java 17 + Lombok”“Python 3.10 + Pandas”“Vue 3 + Element Plus”}
2. 项目规范：{如“符合阿里巴巴Java开发规范”“组件采用PascalCase命名”}
3. 限制要求：{如“代码行数≤50行”“不添加冗余注释”“禁止使用for循环，用流式处理”}
4. 依赖限制：{如“依赖项目UserMapper类”“使用项目封装的HttpUtil工具”}
# 输出格式
{如“Service接口+实现类”“单文件组件（.vue）”“带注释的Python函数”“JSON结构+实体类”}
The key idea is simple: define the task, specify the goal, narrow the implementation space, and tell the model exactly how to deliver the result.
Example: generating a Java order DTO
This example shows what a fully specified prompt looks like in practice. It defines the business purpose, field details, validation rules, imports, naming conventions, and expected output style.
# 场景定位
Java 后端订单模块 DTO 生成（用于订单创建接口入参）
# 需求描述
1. 核心功能：生成订单创建DTO，包含6个字段；
2. 关键细节：
- id：Long（非空，订单唯一标识）；
- orderNo：String（非空，订单编号，格式为“ORD+时间戳+随机6位数字”）；
- userId：Long（非空，关联用户ID）；
- totalAmount：BigDecimal（非空，订单总金额，保留2位小数）；
- status：Integer（非空，订单状态：0-待支付，1-已支付，2-已取消）；
- createTime：LocalDateTime（非空，创建时间）。
# 约束条件
1. 技术栈：Java 17 + Lombok + JSR380（参数校验注解）；
2. 项目规范：
- 类名采用 PascalCase（OrderCreateDTO）；
- 字段名采用 camelCase；
- 每个字段添加中文注释；
- 校验注解：@NotNull、@Pattern（订单编号格式）、@DecimalMin（金额≥0）；
3. 限制要求：不生成getter/setter（依赖Lombok @Data），不添加多余方法；
4. 依赖限制：BigDecimal 导入 java.math 包，LocalDateTime 导入 java.time 包。
# 输出格式
单文件Java类，包含完整注解、注释，直接可复制到项目中使用。
This kind of prompt sharply reduces back-and-forth because it already encodes the class name, field rules, validation expectations, and implementation boundaries.
Language-specific prompt templates
Different stacks need different levels of instruction. Backend prompts usually need business logic and dependency boundaries. Frontend prompts need component contracts, validation, interaction, and UI structure. Scripting prompts often need file paths, processing rules, and error handling.
Backend templates
Java service implementation
This template is aimed at a user module query service with pagination, fuzzy search, status filtering, Redis caching, logging, and business exception handling.
# 场景定位
Java 后端用户模块 Service 实现类（查询功能）
# 需求描述
1. 核心功能：实现用户分页查询，支持按用户名模糊查询、按状态精确查询；
2. 关键细节：
- 入参：UserQueryDTO（pageNum、pageSize、username、status）；
- 出参：PageInfo<UserVO>（包含用户ID、用户名、手机号、状态、创建时间）；
- 业务逻辑：先查Redis缓存（key：user:query:{username}:{status}:{pageNum}），缓存未命中查数据库，查询结果存入缓存（过期时间5分钟）。
# 约束条件
1. 技术栈：Java 17 + Spring Boot 3.x + MyBatis-Plus + RedisTemplate；
2. 项目规范：
- 类名：UserServiceImpl，实现 IUserService 接口；
- 异常处理：用户状态不存在时抛出 BusinessException（错误码：1001）；
- 日志：使用 SLF4J，查询前后打印日志（格式：“用户查询，入参：{}，结果：{}”）；
3. 限制要求：不生成 mapper 层代码，直接调用 userMapper.selectPage(...)；
4. 依赖限制：缓存序列化使用 Jackson2JsonRedisSerializer。
# 输出格式
Service 实现类完整代码，包含方法注释、日志打印、异常抛出、缓存逻辑。
The practical value here is not just the feature list. It also pins down cache key design, cache expiration, logging style, and where implementation should stop.
Go Gin route configuration
For Go projects, prompts often need clear route grouping, middleware, binding rules, and explicit boundaries so the model does not drift into generating controller logic that was never requested.
# 场景定位
Go 后端商品模块 Gin 路由配置
# 需求描述
1. 核心功能：配置商品CRUD接口路由，包含4个接口；
2. 关键细节：
- GET /api/v1/goods/{id}：查询单个商品；
- GET /api/v1/goods：分页查询商品（入参：page、size、name）；
- POST /api/v1/goods：新增商品（入参：GoodsCreateRequest）；
- PUT /api/v1/goods/{id}：修改商品（入参：GoodsUpdateRequest）；
- DELETE /api/v1/goods/{id}：删除商品。
# 约束条件
1. 技术栈：Go 1.22 + Gin v1.9.1 + jwt 权限校验；
2. 项目规范：
- 路由分组：/api/v1/goods，统一添加 jwt 中间件（jwt.Middleware()）；
- 控制器：调用 goodsController 对应的方法（如 goodsController.GetById）；
- 入参绑定：使用 ctx.ShouldBindQuery()/ShouldBindJSON()；
3. 限制要求：不生成控制器实现，仅配置路由；
4. 依赖限制：路由前缀统一为 /api/v1，端口已在 main 函数配置。
# 输出格式
routes/goods_route.go 文件完整代码，包含路由注册、中间件配置、接口映射。
Frontend templates
Vue 3 form component
In admin systems, form generation is one of the most frequent AI-assisted tasks. A good prompt needs to define fields, validation rules, component naming, submission behavior, layout, and what existing API layer should be reused.
# 场景定位
Vue 3 + Element Plus 后台管理系统表单组件（商品新增）
# 需求描述
1. 核心功能：生成商品新增表单，包含6个字段，支持校验与提交；
2. 关键细节：
- 商品名称：input，非空，长度1-50；
- 商品分类：select，非空，选项：[{label: '电子产品', value: 1}, {label: '服装', value: 2}]；
- 价格：number，非空，≥0.01，保留2位小数；
- 库存：number，非空，≥0；
- 状态：switch，默认开启（1-启用，0-禁用）；
- 备注：textarea，可选，最大长度500。
# 约束条件
1. 技术栈：Vue 3 + TypeScript + Element Plus + Pinia；
2. 项目规范：
- 组件名：GoodsCreateForm（PascalCase）；
- 表单校验：使用 ElForm 内置校验规则，错误提示在输入框下方；
- 提交逻辑：点击“提交”按钮触发 submitForm 方法，校验通过后调用 goodsApi.create()；
- 样式：使用 Element Plus 栅格布局（el-row + el-col），一行2列；
3. 限制要求：不生成 API 封装，直接调用已有的 goodsApi；
4. 依赖限制：导入 ElForm、ElFormItem、ElInput 等组件，使用 setup 语法糖。
# 输出格式
src/views/goods/components/GoodsCreateForm.vue 完整代码，包含模板、脚本、样式。
This template keeps the model focused on the component itself rather than inventing new request layers or changing the project architecture.
React visualization component
For data visualization, prompts need to control chart type, data source, states, error handling, and interaction behavior.
# 场景定位
React 18 + ECharts 数据可视化组件（销售额趋势图）
# 需求描述
1. 核心功能：生成折线图，展示近7天销售额趋势；
2. 关键细节：
- X轴：日期（格式：MM-DD）；
- Y轴：销售额（单位：元）；
- 交互：鼠标hover显示tooltip（包含日期、销售额），支持图例切换；
- 样式：折线颜色#1890ff，标记点为圆形，网格线显示。
# 约束条件
1. 技术栈：React 18 + TypeScript + echarts-for-react + Axios；
2. 项目规范：
- 组件名：SalesTrendChart；
- 数据请求：组件挂载时调用 /api/v1/statistics/sales 接口，获取近7天数据；
- 加载状态：请求中显示 ElLoading 组件；
- 异常处理：请求失败显示“数据加载失败，请重试”；
3. 限制要求：数据格式假设为 [{date: '2025-01-01', amount: 1000}]；
4. 依赖限制：导入 EChartsReact 组件，使用函数式组件 + hooks（useState、useEffect）。
# 输出格式
src/components/Statistics/SalesTrendChart.tsx 完整代码，包含数据请求、图表渲染、状态管理。
Script templates
Python data processing script
This template is suited to routine data-cleaning work: read Excel, normalize fields, calculate grouped statistics, export multiple sheets, and keep the implementation functional and compact.
# 场景定位
Python 数据处理脚本（Excel 数据清洗与统计）
# 需求描述
1. 核心功能：读取Excel文件，清洗数据后生成统计结果并导出；
2. 关键细节：
- 读取文件：input.xlsx（sheet名：data）；
- 数据清洗：
1. 删除空行；
2. “金额”列转为数值类型，剔除非数字数据；
3. “日期”列格式统一为 yyyy-mm-dd；
- 统计逻辑：按“分类”列分组，计算每组的金额总和、平均值、数据条数；
- 导出文件：output.xlsx（包含清洗后的数据 + 统计结果，分2个sheet）。
# 约束条件
1. 技术栈：Python 3.10 + pandas + openpyxl；
2. 规范要求：
- 代码添加中文注释，关键步骤说明；
- 异常处理：文件不存在抛出 FileNotFoundError，数据格式错误打印警告并跳过；
- 输出日志：打印处理进度（如“已读取数据：100条”“清洗后数据：85条”）；
3. 限制要求：不使用复杂类，仅用函数式编程，代码行数≤100行；
4. 依赖限制：Excel 读写使用 pandas 的 read_excel/write_excel 方法。
# 输出格式
完整Python脚本（data_process.py），可直接运行，包含参数配置（文件路径可修改）。
Shell deployment script
For deployment automation, prompts should define the full path from packaging to health checks, while being strict about logs, failure handling, and available system tools.
# 场景定位
Shell 脚本（Spring Boot 项目自动化部署到 Linux 服务器）
# 需求描述
1. 核心功能：实现项目打包、停止旧服务、部署新服务、启动验证；
2. 关键细节：
- 打包：本地执行 mvn clean package -Dmaven.test.skip=true；
- 上传：将 target/*.jar 上传到服务器 /opt/project 目录；
- 停止服务：查找项目进程（根据 jar 包名），优雅停止（kill -15）；
- 启动服务：nohup java -jar /opt/project/xxx.jar --spring.profiles.active=prod &；
- 验证：启动后3秒访问 http://localhost:8080/actuator/health，判断服务是否正常。
# 约束条件
1. 环境：Linux（CentOS 7）+ Maven 3.8.x + JDK 17；
2. 规范要求：
- 变量定义：项目名、本地 jar 路径、服务器路径可配置；
- 日志输出：每个步骤打印“[INFO] 步骤描述”，失败打印“[ERROR] 错误信息”；
- 容错处理：打包失败直接退出，停止服务失败提示用户手动处理；
3. 限制要求：不依赖额外工具，仅使用 shell 内置命令 + curl；
4. 依赖限制：服务器已配置免密登录（ssh 无密码访问）。
# 输出格式
deploy.sh 完整脚本，包含注释、变量配置、步骤逻辑，支持 chmod +x 后直接执行。
Project rules you can pass as global context
One of the most effective ways to improve AI code quality is to provide project conventions up front as shared context. That avoids having to repeat the same style, exception, logging, and dependency rules in every prompt.
Java project standards
This global template covers naming, comments, exceptions, logging, formatting, and approved utility or infrastructure usage.
# Java 项目编码规范（全局约束）
1. 命名规则：
- 类名：PascalCase（如 UserService）；
- 方法名/字段名：camelCase（如 getUserById）；
- 常量：UPPER_SNAKE_CASE（如 MAX_RETRY_COUNT）；
- 包名：全小写，按“com.公司名.项目名.模块名”层级（如 com.xxx.shop.goods）。
2. 注释要求：
- 类注释：包含作者、创建日期、功能描述；
- 方法注释：使用 Javadoc 格式，说明参数、返回值、异常类型；
- 字段注释：关键字段添加中文注释（如// 订单状态：0-待支付）。
3. 异常处理：
- 统一抛出自定义异常 BusinessException，禁止直接抛出 RuntimeException；
- 异常需携带错误码（如 new BusinessException(1001, "用户不存在")）；
- 全局异常由 GlobalExceptionHandler 统一处理。
4. 日志规范：
- 使用 SLF4J（import org.slf4j.Logger; import org.slf4j.LoggerFactory）；
- 日志级别：DEBUG（开发调试）、INFO（业务流程）、WARN（警告信息）、ERROR（错误信息）；
- 日志格式：“[模块名] 描述，参数：{}”（如 log.info("[用户查询] 分页查询用户，入参：{}", queryDTO)）。
5. 代码风格：
- 缩进：4个空格，禁止使用 Tab；
- 括号：if/for/while 语句的括号必须换行，即使只有一行代码；
- 空行：方法之间空1行，逻辑块之间空1行，保持代码整洁。
6. 依赖规范：
- 工具类：使用项目封装的 com.xxx.common.util 包下工具（如 DateUtil、StringUtil）；
- 数据库：MyBatis-Plus 分页使用 PageHelper，禁止手写 LIMIT；
- 缓存：统一使用 RedisTemplate，序列化方式为 Jackson2JsonRedisSerializer。
Vue project standards
For frontend work, supplying framework conventions in advance helps AI keep file structure, naming, style isolation, state handling, and route patterns aligned with the rest of the project.
# Vue 项目编码规范（全局约束）
1. 命名规则：
- 组件名：PascalCase（如 GoodsList），单文件组件文件名与组件名一致；
- props 名：camelCase（如 userId），模板中使用 kebab-case（如 user-id）；
- 事件名：kebab-case（如 @save-click="handleSave"）；
- 目录结构：
- 公共组件：src/components/组件名；
- 页面组件：src/views/页面名/components（页面私有组件）。
2. 代码风格：
- 脚本：使用 TypeScript + setup 语法糖；
- 模板：标签属性换行（每个属性占一行），禁止超过3个属性在同一行；
- 样式：使用 scoped 样式隔离，优先使用 Element Plus 原子类，自定义样式用 BEM 命名（如 .goods-card__title）。
3. 规范要求：
- props 必须定义类型和默认值，添加校验（如 type: Number, default: 0）；
- 状态管理：核心状态用 Pinia，局部状态用 ref/reactive；
- 接口请求：统一使用 src/api 目录下封装的请求函数（如 goodsApi.getList()）；
- 路由：路由路径使用 kebab-case（如 /goods-detail），组件懒加载（import(() => import('@/views/goods/GoodsDetail.vue'))）。
4. 性能优化：
- 列表渲染：添加 key（如 :key="item.id"），避免使用 index 作为 key；
- 图片懒加载：使用 v-lazy 指令；
- 防抖节流：使用 lodash 的 debounce/throttle 工具。
A review checklist for AI-generated code
Even a strong prompt does not remove the need for review. AI output should still be checked against business requirements, project standards, security concerns, and integration constraints.
This checklist is designed as a quick verification pass before adopting generated code.
# AI 生成代码审核清单（必查10项）
## 1. 逻辑正确性
- [ ] 代码是否符合原始需求，无功能遗漏；
- [ ] 边界条件是否处理（如空值、异常输入、并发场景）；
- [ ] 业务规则是否匹配（如状态值范围、金额计算逻辑）。
## 2. 规范对齐
- [ ] 命名（类/方法/字段）是否符合项目规范；
- [ ] 注释是否完整（类/方法/关键字段）；
- [ ] 异常处理是否统一（自定义异常、错误码）；
- [ ] 日志是否按格式打印，无冗余/缺失。
## 3. 性能安全
- [ ] 是否存在重复查询/计算（需缓存优化）；
- [ ] 是否存在未关闭资源（如数据库连接、文件流）；
- [ ] 是否存在安全风险（如 SQL 注入、XSS 漏洞、敏感数据泄露）；
- [ ] 代码是否存在冗余（如重复造轮子、无用变量）。
## 4. 兼容性
- [ ] 是否与现有代码冲突（如类名重复、方法重载冲突）；
- [ ] 依赖是否正确（如导入包路径、版本兼容）；
- [ ] 接口是否与上下游兼容（如入参/出参格式）。
## 5. 可维护性
- [ ] 代码是否模块化，无过度耦合；
- [ ] 复杂逻辑是否有注释说明；
- [ ] 是否存在硬编码（如固定IP、魔法值，需抽为常量）。
What makes these prompts effective
Several patterns run through all of these templates:
- They define the development scenario clearly instead of asking for code in the abstract.
- They describe core functionality and detailed rules separately, which reduces missing edge conditions.
- They lock in stack and project conventions, helping the output fit an existing codebase.
- They include explicit limits, such as no extra methods, no controller implementation, or no custom API wrapper generation.
- They specify the output shape, making the response easier to paste directly into a real project.
If AI-generated code often feels close but not usable, the problem is usually not the model alone. More often, the prompt did not define the business boundaries, coding standards, and delivery format precisely enough.
A well-written prompt does not just ask for code. It provides the context a teammate would need before writing it.