完整题目
在实际的大模型应用中，你使用过哪些有效的Prompt Engineering技巧来提升模型输出的质量、准确性和一致性？请结合具体应用场景（如RAG、Agent等）举例说明其设计思路、实施过程及实际效果。
本文目录
真实性边界
问题要求说明“使用过”的技巧和实际效果，因此只能填写真实任务、模型、Prompt 版本和评测结果。法务、客服等场景若未实际参与，只能作为明确标注的教学假设，不能写成个人业绩。
回答框架
- 任务：真实输入输出、风险、失败类型和评价指标。
- 技巧：说明实际采用角色/边界、上下文分隔、Few-shot、检索增强、工具 schema、结构化输出或结果校验中的哪些。
- 机制：解释每项技巧针对哪个可观察错误，而不是罗列名词。
- 实验：固定模型、数据与解码参数，对 Prompt 版本做消融和切片。
- 生产：版本管理、监控、提示注入防护、回滚和成本约束。
事实填空
在【真实任务】中，基线 Prompt 为【】，常见错误为【】。我负责【】，采用【真实技巧】解决【对应问题】，与【备选】比较。评测集【来源/规模】，真实结果【】，延迟或 token 变化【】，失败切片【】。
证据自检
每个效果数字应能关联 Prompt diff、测试样本、模型版本和统计口径。引用正确不等于答案正确；JSON 可解析不等于业务字段有效；LLM-as-Judge 需要人工校准。
追问入口
可继续追问上下文冲突、动态示例泄漏、结构化输出失败、工具参数安全、评测器偏差和 Prompt 与模型升级的回归关系。
换一种问法，检查是否真正理解
场景切入
假设我们做一个法务RAG系统，用户问‘合同无效的情形’，模型直接编了条法条。你平时写prompt会怎么防止这种幻觉？比如加什么约束或者格式要求？
层层追问
你一般怎么用prompt来让模型输出更稳？……如果模型老是不按格式来，比如该输出JSON却输出自然语言，你会怎么处理？……那如果要保证引用来源准确，比如RAG里强制标出处，你觉得prompt上怎么做最有效？
直球架构
聊一下Prompt Engineering技巧，重点是提升输出质量和一致性。你用过哪些？从基础的角色锚定、格式约束，到针对RAG的引用强制、Agent的ReAct框架，具体怎么设计、效果怎么样？
练习口述回答 · 约90秒
- Prompt工程本质是引导模型行为
- 基础技巧：角色锚定、格式约束、负面指令
- 场景化技巧：RAG用引用强制，Agent用ReAct框架
- 业务案例：法务问答的幻觉治理
- 工程师判断：Prompt是手感活，要结合校验和版本管理
我会从一个确实做过的应用讲，而不是把常见技巧全报一遍。场景是【真实场景】，我负责【本人职责】，基线最突出的问题是【主要错误】。我采用的【具体技巧】必须和这个问题一一对应：例如 Few-shot 用来示范边界，结构化输出配合服务端校验解决解析，RAG 提供外部证据，工具 schema 约束可执行参数。
实施时我固定模型、数据和解码参数，在同一回归集上比较 Prompt 版本。用【评测口径】同时看任务质量、格式、引用支持、危险动作、token 和延迟，并按【失败切片】检查平均分会不会掩盖高风险退化。自动 Judge 只作辅助，还要用人工样本校准。
最终只报告【真实结果】，能对应 Prompt diff、样本和线上记录的数字才说。来自用户或文档的内容都按不可信输入处理，敏感工具由服务端鉴权和确认。模型升级后重跑回归；如果失败根因是缺知识、缺权限或模型能力不足，就把问题交给 RAG、工具或微调，不继续堆提示词。