Prompt Engineering——从随意提问到工程化调用

前言在上一篇文章中我们理解了大模型为什么会产生幻觉。其中一个关键的缓解手段就是Prompt Engineering。你可能会觉得“Prompt Engineering 不就是写好提示词吗这有什么可学的” 但真正做过大模型应用开发的人都知道——同样一个模型换一种提问方式答案质量天差地别。这不是玄学而是一套可以被拆解、验证、复用的工程方法。面试官看到你简历上写了Prompt Engineering通常会追问一句“你设计的Prompt模板是怎么想的” 本文就是帮你准备好这个问题的完整答案。本文核心问题为什么同样的模型换个问法答案就不一样Prompt到底是如何影响模型输出的角色设定、Few-shot、Chain of Thought 分别解决什么问题各自的底层逻辑是什么输出格式约束怎么做JSON模式 vs 自然语言约束Prompt模板如何管理硬编码 vs 配置化的优劣如何评估一个Prompt的好坏A/B测试怎么做你在课程问答项目中实际使用的Prompt模板是什么经历了哪些迭代什么场景下应该把复杂Prompt拆成多步Prompt Engineering 有天花板吗什么时候该转向微调或其他方案读完本文你将能把写Prompt这件事从感觉变成方法面试时能讲清楚每一步设计的底层考量。一、为什么Prompt是工程而不是聊天疑问不就是跟AI说话吗为什么还要工程化回答因为大模型对输入极为敏感。同一个问题三种问法三种结果。1.1 一个真实的对比实验我在做课程问答助手时测试过三种不同的Prompt问法A随意 Java线程池怎么配置 → 模型给了一个通用回答和课程内容无关还编了两个不存在的参数名 问法B加角色 你是一个Java课程助教。Java线程池怎么配置 → 语气更像老师了但内容还是通用的没有引用课程 问法C加角色约束课程文档 你是课程答疑助手只能根据以下课程内容回答。如果内容中没有答案说课程未提及。课程内容{文档}。问题Java线程池怎么配置 → 准确从课程文档中提取了答案标注了章节出处同样的模型三种Prompt三种质量。这就是Prompt Engineering要解决的问题——不是会说话而是用最小的Token成本稳定地获得最高质量的输出。1.2 Prompt是如何影响模型输出的从上一篇我们知道大模型是逐Token预测下一个词的概率。Prompt改变了这个概率分布没有Prompt约束时 Java线程池... → 所有可能的续写竞争 → 最通用的那类回答概率最高 有Prompt约束时 你是课程助教。课程内容{文档}。Java线程池... → 基于课程的续写概率被大幅拉高 → 编造外部知识的续写概率被压制Prompt就是在引导概率流向——让模型在正确的语义空间中采样。二、Prompt三大核心技巧的底层逻辑疑问角色设定、Few-shot、Chain of Thought 是Prompt的三大法宝。它们各自解决什么问题为什么有效2.1 角色设定——缩小语义搜索空间不做角色设定 模型在整个互联网文本分布中采样 → 输出泛化、风格随机 做角色设定 你是一个10年经验的Java架构师 → 模型在技术专家文本的子空间中采样 → 输出更专业、更有结构本质角色设定是一种软约束——它没有硬性规定输出内容但大幅缩小了模型采样的语义空间。这不是让模型扮演角色而是告诉模型应该从哪种语言模式的分布中采样。2.2 Few-shot——用示例教会模型模式Zero-shot不提供例子 将以下句子翻译成JSON姓名张三年龄25 → 模型可能输出{name:张三,age:25} ← 猜对了 → 也可能输出{姓名:张三,年龄:25} ← 猜错了格式 Few-shot提供2-3个例子 示例1姓名李四年龄30 → {name:李四,age:30} 示例2姓名王五年龄22 → {name:王五,age:22} 现在姓名张三年龄25 → → 模型几乎100%输出{name:张三,age:25}本质Few-shot 是一种模式示范。大模型有很强的模式识别和复制能力。给它2-3个示例它就能准确复现你想要的格式。这比用自然语言描述格式要求可靠得多。2.3 Chain of Thought——强迫模型慢思考不用COT 一个班有30个学生男生比女生多4个男生有多少 → 模型直接输出17个 ← 可能对也可能错 用COT加一句请逐步推理 同一个问题 请逐步推理 → 设女生x人男生x4人。x(x4)302x26x13。男生13417。 → 准确率大幅提升本质COT 把一步跳到答案变成了多步推演。每一步的推演结果都成为下一步的输入——模型在每一步都在基于自己的推理结果继续推理而不是一次性猜测最终答案。这和人类的打草稿是同一个道理。三、输出格式约束——让模型说人话疑问怎么让模型稳定输出JSON用自然语言说请输出JSON格式够吗回答不够。自然语言约束有模糊性结构化约束更可靠。3.1 三种约束方式对比方式示例成功率适用场景自然语言“请以JSON格式输出”80-90%简单结构Few-shot 示例格式给出2-3个期望输出示例95%大部分场景JSON ModeAPI原生response_format{type:json_object}99%严格要求JSON3.2 我在课程问答项目中的做法StringpromptTemplate 你是一个课程答疑助手只能根据以下课程内容回答学生的问题。 如果课程内容中没有相关信息请直接说课程中未提及此内容不要编造答案。 ## 课程内容 {context} ## 学生问题 {question} ## 回答要求 - 基于课程内容回答引用原文时标注出处章节名 - 如果涉及代码使用代码块格式包裹 - 回答简洁不超过300字 - 输出格式保持纯文本不需要markdown标题 ;设计考量“标注出处”——方便用户回溯原文验证也方便我做质量审查“代码用代码块”——课程内容大量涉及代码格式要求保证可读性“不超过300字”——克制模型过度回答的倾向当答案不需要300字时这个限制防止它为了凑字数而编造“不需要markdown标题”——前端渲染时直接用样式控制层级不需要模型自作主张四、Prompt模板管理——硬编码 vs 配置化疑问Prompt直接写在代码里不行吗为什么需要模板管理回答Demo阶段写死没问题但生产环境需要考虑迭代效率和团队协作。4.1 硬编码的问题// ❌ 硬编码改一句话需要重新部署Stringprompt你是客服助手...context...question;// ✅ 配置化改Prompt不需要重新部署StringpromptpromptTemplateManager.get(course_qa).replace({context},context).replace({question},question);4.2 我的方案对于课程问答这个Demo项目我选择了轻量配置化——Prompt存放在配置文件中启动时加载到内存# prompts.ymlcourse_qa:system:你是课程答疑助手只能根据课程内容回答...user_template:|## 课程内容 {context}## 学生问题{question}选型考量项目当前只有一个Prompt模板过度设计没必要。但用配置文件意味着后续如果需要做A/B测试对比两个Prompt的效果只需要改配置重启即可不用动代码。五、如何评估一个Prompt的好坏疑问我怎么知道改了一句话Prompt是变好了还是变坏了凭感觉吗回答不能凭感觉。需要一套可量化的评估方法。5.1 评估维度维度衡量标准课程问答项目中的做法准确性回答与课程内容是否一致人工抽查50条判断引用是否正确诚实性不知道时是否说不知道用课程外的10个问题测试统计幻觉率稳定性同一问题多次询问是否一致5个问题各问3次统计不一致的比例格式合规是否遵守输出格式约束检查代码块包裹率、字数超标率5.2 A/B测试怎么做1. 准备两份PromptA版当前版本、B版优化版本 2. 准备50个测试问题覆盖正常问题、边界问题、课程外问题 3. 用同一个模型分别套用A版和B版Prompt 4. 对每个回答打分准确性、诚实性、格式合规 5. 对比两版的总分和分项表现 6. B版如果全面优于A版 → 上线B版5.3 我在项目中实际经历的迭代V1你是一个课程答疑助手。{context}。{question}。 → 问题模型偶尔还是编造内容 V2你是课程答疑助手只能根据课程内容回答。如果内容中没有答案 请说课程中未提及。{context}。{question}。 → 改善编造大幅下降但对代码格式控制不好 V3在V2基础上加代码用代码块包裹和不超过300字 → 最终版满足项目需求六、什么时候需要拆解复杂Prompt疑问一个Prompt搞定所有事情不行吗为什么要拆成多步回答复杂任务拆成多步每步只做一件事准确率比一个长Prompt高。单一复杂Prompt 分析这段代码的问题给出修改建议并输出修改后的完整代码 → 模型可能遗漏问题、建议笼统、代码和原文对不上 拆成多步 步骤1分析这段代码的问题只列问题不修改 步骤2拿到问题列表后逐个问针对问题1给出修改方案 步骤3拿到所有方案后请整合所有修改输出完整代码 → 每步输出质量有保障最后结果可用什么场景该拆如果一个问题需要模型同时完成判断检索生成格式化且你发现单一Prompt输出不稳定——就值得拆成多步。七、Prompt Engineering的天花板疑问Prompt Engineering能解决一切吗什么时候该用其他方案回答有天花板。当Prompt已经足够好但效果仍不达标时考虑以下进阶方案场景Prompt的局限进阶方案需要模型学会新的知识靠Prompt灌输效率低RAG检索增强生成需要模型遵循非常特定的格式/风格Prompt无法100%保证微调Fine-tuning需要模型执行复杂的多步操作Prompt过长导致注意力分散Agent工具调用任务规划需要模型展示可靠的计算能力概率生成不保证数值正确外挂计算工具Function CallPrompt Engineering是基础不是终点。绝大多数场景下好的Prompt设计 RAG已经足够。只有当这些方法都到天花板了才需要考虑微调等更重的方案。总结Prompt不是聊天是引导概率流向——同样的模型不同的Prompt答案质量天差地别角色设定缩小语义搜索空间让模型在相关分布中采样Few-shot比自然语言描述更可靠——模型学模式比学指令更准确Chain of Thought强迫模型打草稿把一步猜测变成多步推演准确率大幅提升输出格式约束需多层保障自然语言 Few-shot示例 API级约束Prompt模板配置化让迭代不依赖重新部署为A/B测试铺路。Demo阶段建议轻量配置即可评估Prompt靠数据不靠感觉——准确性、诚实性、稳定性三个维度量化对比Prompt Engineering有天花板——该上RAG和微调时不要死磕Prompt下一篇预告AI理论学习五——RAG检索增强生成让大模型学会开卷作答。拆解RAG为什么能同时解决幻觉和知识陈旧问题以及文档切分策略、检索精度优化、Prompt拼接的最佳实践。