完整题目
在使用大语言模型时，prompt设计对输出质量有显著影响。请说明prompt优化的主要策略和技术手段，如思维链、少样本学习等，并举例说明其应用场景。
本文目录
主要策略
- 明确任务与边界：写清输入、目标、禁止事项和失败时的行为。
- 结构化输出：优先使用原生 structured output、tool schema 或约束解码；仅靠“请输出 JSON”不能保证合法。
- Zero-shot / Few-shot：简单任务先建立 Zero-shot 基线；Few-shot 用于示范边界与格式，但要防止示例泄漏和位置偏差。
- 推理组织：复杂问题可要求可检查的中间产物、计划或工具结果；不要把不可核验的自由思维链当作正确性证明。
- 检索与工具：外部事实通过 RAG 或工具获得，Prompt 负责规定证据使用和权限。
- 安全：分隔不可信内容，防提示注入，敏感动作必须校验和确认。
假设实验：客服质检
使用明确标注的合成任务，固定模型、解码参数和数据切分，比较基础指令、加入边界 Few-shot、加入结构化输出和加入验证器。指标包括分类质量、格式成功率、校准、对抗样本、安全错误、token 和延迟。结果必须填写真实实验，不能预设从某个准确率提升到另一个准确率。
选择原则
先使用最简单、可维护的方案；只有基线不能满足需求时才增加示例、推理步骤或多次采样。多次采样会增加成本，且多数一致不等于事实正确。
换一种问法，检查是否真正理解
场景切入
假设你在做一个客服系统，用户问“我的订单怎么还没到”，你直接让模型回答，结果它只会说“请稍等，会尽快送达”。如果改成“先分析可能的原因（物流延迟、地址错误），再给出具体建议”，效果会好很多。你平时怎么设计prompt来引导模型按你的思路走？
层层追问
你平时怎么设计prompt让模型输出更准确？……如果给几个例子算不算？……那如果任务需要多步推理呢，比如数学题，有什么技巧让模型一步步思考？……你提到的思维链，具体怎么加进prompt里？
直球架构
请系统地讲一下prompt优化的主要策略和手段，包括零样本、少样本、思维链这些，各自适用什么场景？最好能结合一个具体的业务例子，比如电商客服或代码生成，说明你怎么选策略、怎么写prompt。
练习口述回答 · 约4分钟
- Prompt优化的本质是降低任务模糊性
- 核心策略：零样本、少样本、思维链及其适用边界
- 结构化技巧与落地案例：客服质检
- 风险与取舍：不是万能，需要配合其他手段
- 可延伸点：Self-Consistency的代价
Prompt 优化要从失败模式出发，而不是把思维链、Few-shot 和角色设定一次全加上。我会先做一个最小基线，把任务、输入输出、禁止事项和失败时的行为写清楚。需要机器消费的结果，优先用模型原生 structured output、tool schema 或约束解码，再由服务端检查字段范围和业务关系；一句“请输出 JSON”只保证不了语义正确。
Zero-shot 适合建立基线。Few-shot 用来展示分类边界、格式和反例，但示例要和测试集隔离，检查顺序、长度和类别分布偏差。复杂任务可以要求模型先给可验证的计划、计算结果或工具调用，不过自由生成的思维过程不能当作正确性证据。涉及外部事实时，我会用 RAG 或工具补充来源，Prompt 负责证据边界、引用、不确定时的行为和权限，而不是要求模型凭记忆猜。
我先从工程设计角度回答，再用一个假设场景说明。假设做客服质检，可以固定模型、解码参数和数据切分，逐步比较基础指令、边界 Few-shot、结构化输出与验证器。每次只改变一个主要因素，同时看分类质量、格式成功率、校准、安全错误、token 和延迟；自动 Judge 先用人工标签校准。用户内容、检索文档和工具返回都按不可信输入分层，敏感动作必须服务端鉴权。若简单方案已达到质量和风险要求，我不会增加多次采样或更长提示，因为它们会提高成本、延迟和维护冲突。
不同技巧解决的问题也不同。角色描述主要帮助稳定任务边界，并不会给模型增加未知事实；Few-shot 能传递行为范式，但示例分布不匹配会把偏差放大；查询改写和 RAG 能补外部信息，也可能把错误或提示注入带入上下文；工具调用把计算和动作交给确定性系统，却新增了权限、幂等与副作用管理。多次采样适合探索候选，但多数输出一致不等于事实正确，而且成本会成倍增长。选择时要先说清楚失败类型，再解释这项技术为什么对症。
Prompt 还需要像代码一样治理。版本记录系统指令、用户模板、示例、上下文组装、模型和解码参数，回归集覆盖正常、边界、无答案、长上下文、格式和对抗样本。线上日志带 Prompt 哈希，灰度同时观察质量、尾延迟、token、拒答和危险动作；模型升级时回归新旧 Prompt 组合，避免把模型变化误判成提示收益。某次改动如果没有稳定改善目标切片，或者收益抵不过维护和延迟成本，就应该撤掉。优化的终点是最简单、可测、可回滚的组合，不是把所有流行技巧都塞进一个模板。