很多人问我，平时用 AI 写代码怎么才能不出错？我的答案是：别让 AI 猜，把你的要求说清楚。
今天分享 5 个我日常开发中一直在用的提示词模板 ------ 不是那种空泛的 "帮我写个管理系统"，而是把所有约束条件、技术栈、代码规范都写死，复制粘贴就能生成能用的项目骨架。
提示词 1：生成完整项目骨架
直接复制使用：
plaintext
帮我搭建一个【项目名称，如：电商后台管理系统】的完整技术方案，要求：
【技术栈】
-
前端：Vue3 + TypeScript + Vite + Element Plus + Pinia + Axios
-
后端：Node.js + Express + TypeScript + TypeORM + MySQL
-
统一使用ESLint + Prettier规范
【目录结构要求】
-
前端按模块划分：views/components/router/store/api/utils
-
后端分层清晰：controller/service/model/middleware/utils
-
每个文件职责单一，不超过300行
【必须包含】
-
完整的用户认证体系（JWT+刷新令牌）
-
统一的响应格式和错误处理
-
接口请求/响应日志
-
跨域配置和环境变量
-
README说明启动步骤
输出格式：先给整体架构说明，再分文件输出代码，每个文件开头写清楚文件路径。不要解释，直接给可运行的代码。
为什么这么写：
很多人生成项目踩的最大坑就是技术栈不统一 ------ 一会儿用 React 一会儿用 Vue，目录结构乱七八糟。把所有约束条件写死，AI 就不会瞎发挥。重点要求 "可运行"，而不是 "示例代码"。
提示词 2：生成单个业务模块
直接复制使用：
plaintext
基于已有的Vue3+Express项目，帮我实现【功能模块，如：商品CRUD】功能：
【前端】
-
列表页：表格展示+分页+搜索+筛选
-
新增/编辑弹窗：表单验证+提交
-
删除确认提示
-
状态开关切换
【后端】
-
RESTful风格接口：GET/POST/PUT/DELETE
-
参数校验（必填项/数据类型/长度限制）
-
软删除实现
-
操作日志记录
【代码规范】
-
前端用Composition API + <script setup>语法
-
后端用async/await，不要回调嵌套
-
所有SQL用参数化查询，防止注入
-
错误信息要友好，不要暴露堆栈
注意复用项目中已有的request工具、响应封装、通用组件。输出完整的前后端代码，按文件路径分开。
为什么这么写：
做业务模块最忌讳风格不统一。明确要求复用已有工具，就不会出现每个页面的请求方式都不一样的情况。特别强调不要写 "示例代码"，要写能直接放进项目里的。
提示词 3：数据库设计 + 代码生成
直接复制使用：
plaintext
帮我设计【业务场景，如：在线考试系统】的数据库表结构，并生成完整代码：
【表设计要求】
-
所有表必须包含：id、create_time、update_time、is_deleted
-
字段命名用下划线风格，类型合理，加必要的索引
-
外键关联清晰，说明表关系
-
加必要的注释说明每个字段用途
【需要生成】
-
MySQL建表SQL语句
-
TypeORM实体类
-
对应的CRUD接口（后端）
-
对应的前端页面（列表+新增编辑）
【约束】
-
主键用自增BIGINT
-
时间字段用DATETIME
-
所有删除都是软删除
-
金额用DECIMAL(10,2)，不要用浮点数
先输出表结构设计说明，再给代码。
为什么这么写：
数据库设计是最容易出问题的地方。把字段规范、软删除、索引这些要求明确写出来，就不会后面改表改到崩溃。特别强调金额不要用浮点数 ------ 踩过这个坑的人都懂。
提示词 4：Bug 修复与代码重构
直接复制使用：
plaintext
帮我修复这段代码的问题，并优化重构：
【问题描述】
-
【具体Bug1，如：分页查询时搜索条件不生效】
-
【具体Bug2，如：并发请求时Token过期处理有问题】
【代码片段】
// 把有问题的代码贴在这里
【重构要求】
-
保持原有功能不变，只修复问题和优化
-
拆分过长的函数，每个函数不超过50行
-
消除重复代码，提取公共逻辑
-
加上必要的错误处理
-
变量名和函数名要见名知意
输出：先说明问题原因，再给修复后的完整代码，最后说清楚改了哪些地方。不要改变原有的对外接口。
为什么这么写：
让 AI 改代码最怕的就是它把整个文件重写，把原来能用的功能改坏。明确要求 "保持原有功能不变"、"不改变对外接口"，就不会越改越乱。
提示词 5：代码审查与最佳实践
直接复制使用：
plaintext
帮我审查这段代码，找出问题并给出改进方案：
【代码片段】
// 把要审查的代码贴在这里
【审查维度】
-
有没有安全漏洞（SQL注入/XSS/越权）
-
有没有性能问题（N+1查询/循环内操作数据库）
-
有没有边界情况没处理（空值/异常/并发）
-
代码可读性怎么样（命名/注释/复杂度）
-
有没有不符合最佳实践的地方
输出格式：
-
问题清单（按严重程度排序）
-
每一项问题说明：是什么、为什么不好、怎么改
-
优化后的完整代码
只说实际存在的问题，不要空泛的建议。如果没有问题就直接说"这段代码没问题"。
为什么这么写：
很多人让 AI 审代码，结果得到一堆 "可以加注释"、"变量名可以更清晰" 这种没用的废话。明确审查维度，要求只说实际问题，就能过滤掉那些没用的套话。
最后说句真心话
其实用好 AI 写代码的核心就一句话：你得先知道什么是好代码，才能让 AI 写出好代码。
这些提示词本质上就是把一个资深开发者的经验固化成了模板 ------ 你把规范、约束、踩过的坑都提前告诉 AI，它就不会给你生成那些看起来能用、实际上一跑就崩的垃圾代码。
建议大家保存下来，下次写代码前先套一遍，效率至少提升一倍。