前言在日常使用生成式 AI 的过程中很多人会发现一个现象同样的问题不同人问出来得到的答案质量差很多。有人得到的是泛泛而谈的套话有人却能拿到可以直接使用的代码、文档、方案或分析结果。这说明AI 输出质量不只取决于模型能力也和提示词设计有很大关系。提示词工程并不是玄学而是一套可以学习、复用和迭代的方法。它的核心是把模糊需求变成清晰任务把主观描述变成具体约束把一次性提问变成可控流程。一、高质量 Prompt 的五个核心要素很多低质量输出的根源是指令信息不完整。一条比较完整的 Prompt通常要包含五个部分维度作用示例角色定位告诉 AI 以什么身份回答你是一位资深 Python 后端工程师任务目标明确要完成什么工作重构以下代码并补充异常处理场景上下文说明使用场景和受众该函数用于高并发 API 服务约束规则明确必须做和不能做的事禁止使用全局变量必须包含类型注解输出格式控制返回结构按问题定位、解决方案、代码对比输出很多人只写一句“帮我优化代码”这类指令太宽泛模型只能猜。更好的写法是你是一位资深 Python 后端工程师。 请重构下面这段代码用于高并发 API 服务。 要求 1. 优化时间复杂度 2. 补充异常处理 3. 禁止使用全局变量 4. 保留原有输入和返回结构 5. 按“问题定位 → 优化方案 → 修改后代码 → 验证方式”输出。这样 AI 的发挥空间会被有效收敛结果也更容易复用。二、把主观描述改成可量化要求提示词中最常见的问题是使用了太多模糊词。比如写得详细一点风格专业一点逻辑通顺一些内容丰富一点帮我优化一下。这些词对人类来说能理解但对模型来说很容易变成泛化输出。更好的方式是把主观要求改成客观约束。模糊说法更好的表达写详细一点每条建议不少于 100 字并包含原因和示例风格专业一点使用正式技术文档风格避免口语化表达优化代码降低圈复杂度补充边界条件和异常处理内容丰富些增加 2 个实际场景和 1 个错误示例总结一下输出 5 个要点每条不超过 30 字提示词越具体模型越不容易跑偏。尤其是技术场景最好提前说明语言版本、运行环境、输入输出、限制条件和期望格式。三、使用结构化模板提高输出稳定性相比临时拼一句话结构化模板更适合长期使用。可以使用下面这个通用模板【角色设定】 你是一位精通 [技术栈/领域] 的资深 [岗位]。 【任务背景】 本次内容用于 [具体场景]面向 [目标受众]需要达到 [核心目标]。 【核心任务】 请完成[具体任务] 【输出要求】 1. 篇幅[字数/行数/条数] 2. 风格[技术严谨/通俗易懂/正式文档] 3. 结构[指定章节顺序] 4. 语言[中文/英文/中英对照] 【约束条件】 1. 禁止[不能出现的内容] 2. 必须[必须满足的要求] 【参考素材】 [粘贴代码、日志、文档或背景资料]这个模板可以用于代码生成代码审查技术方案API 文档学习计划文章大纲项目复盘。长期使用这类模板可以慢慢沉淀出自己的提示词库。四、复杂任务要拆开不要一次问完很多人使用 AI 失败是因为一上来就丢一个很大的任务。比如“帮我写一个完整项目方案。”“帮我生成一篇完整技术白皮书。”“帮我重构整个模块并写测试。”这类任务太大模型容易遗漏重点。更好的方式是拆成三步。1. 先确认框架先让 AI 输出结构而不是直接写全文。请基于下面需求输出一份技术方案大纲。 要求包含 1. 背景 2. 方案对比 3. 详细设计 4. 风险分析 5. 实施步骤。2. 再逐块生成确认大纲没问题后再按章节生成。请基于上面大纲展开第二章“方案对比”。 要求用表格输出包含方案、优点、缺点、适用场景和风险。3. 最后整体优化所有模块完成后再统一润色。请检查以下合并后的文档统一术语优化段落衔接删除重复内容输出最终版本。这种分步方式比一次性生成更稳定也更适合长文档、代码设计和复杂方案。五、不要追求一次生成完美重点是迭代高质量输出通常不是第一次就完成的而是多轮迭代出来的。常见迭代方式包括目标指令示例补充细节在第二部分补充性能损耗和适用边界强化逻辑调整段落顺序先讲问题再讲方案精简内容删除铺垫性描述压缩到 800 字以内切换风格改成面向产品经理能看懂的说明增加示例每个观点补充一个实际开发场景不要把第一次输出当成终稿。更推荐的流程是生成初稿 → 指出问题 → 补充要求 → 二次优化 → 最终整理如果是高频任务比如写文章、生成接口文档、分析报错、写单测可以把每次好用的提示词保存下来形成自己的模板库。六、不同模型要调整提示词侧重点不同 AI 模型的输出风格不完全一样。有的模型更擅长结构化推理有的更擅长长文本整理有的在代码任务上更直接。因此同一条 Prompt 在不同模型上可能效果不同。使用时可以根据任务调整重点任务类型提示词重点代码生成明确语言版本、运行环境、输入输出和边界条件长文档整理提供清晰结构和分段要求技术方案明确受众、约束、风险和落地步骤内容写作明确风格、标题、受众和字数问题排查提供报错日志、环境信息和复现步骤如果你经常使用多个模型可以用同一个任务做对比观察不同模型在结构、细节、代码质量和表达风格上的差异。这样能更快找到适合自己工作流的组合方式。七、提示词设计常见误区常见误区更好的做法提问太笼统明确角色、目标、场景和格式只写主观要求改成可量化约束一次性塞入所有需求拆成多轮任务不提供上下文补充代码、日志、背景资料不指定输出格式提前要求 Markdown、表格、代码块第一次输出就直接用做二次校验和迭代不保存好用模板建立个人提示词库提示词的本质不是“写得很玄”而是让 AI 明确知道你是谁你要什么用在什么场景有哪些限制最后要什么格式。八、一个开发者可复用的提示词公式可以把高质量提示词总结成一个公式角色 背景 任务 约束 格式 示例 迭代要求例如你是一位资深后端工程师。 我正在使用 Spring Boot 开发一个接口服务目前接口响应较慢怀疑存在重复查询数据库的问题。 请帮我分析可能原因并给出优化方案。 要求 1. 按“问题定位 → 优化思路 → 示例代码 → 验证方式”输出 2. 语言专业简洁 3. 示例代码适配 Spring Boot 2.7 4. 不要只给理论要给可执行建议 5. 如果信息不足请先向我提出需要补充的问题。这个模板稍微替换内容就可以用于代码优化、Bug 分析、架构设计、文档生成等场景。总结提示词工程不是玄学而是一种结构化沟通方法。想让 AI 输出更稳定关键不是随便换模型而是把提问方式改得更清楚。核心方法可以总结为明确角色说清任务补充上下文增加约束指定格式拆解复杂任务多轮迭代优化沉淀可复用模板。当你从“随口提问”升级为“结构化下任务”GPT 就不再只是一个聊天工具而会更像一个可控的开发辅助组件帮助你完成代码、文档、方案、总结等高频工作。