Appearance
Q143 · 大模型的 Prompt 设计有哪些技巧？
把“帮用户判断能否退货”交给模型，若只写一句“你是专业客服，请认真回答”，它可能不知道采用哪版政策、不知道用户是否已签收，也不知道缺信息时该怎么办。Prompt 设计的核心，是把任务目标、可用资料、约束与输出要求交代清楚，让模型在可判断时给出有依据的结果，在不可判断时明确说缺什么；然后用真实测试题检验，继续修改。OpenAI Prompt Engineering 指南 · Google Cloud Prompt 设计指南
图中的任务卡不是要求每次都写四大段长提示，而是提醒四个常漏的要素。写得越长不必然越好；信息具体、层级清晰、可验证比堆“请认真思考”“你是世界第一专家”更重要。
术语：先认识提示里每样东西
| 名词 | 面向初学者的解释 |
|---|---|
| Prompt / 提示 | 送给模型的输入内容，可包含指令、用户问题、参考资料、示例和格式要求。 |
| 系统/开发者指令 | 应用开发者设定的稳定规则，如“只能依据当期政策回答”；具体 API 的消息层级可能不同。 |
| 用户输入 | 用户本次真正提出的问题和提供的事实。它随每次请求变化。 |
| 上下文 | 为当前问题补充的事实材料，如检索到的政策、订单数据。它可能不完整或过期，需标明来源。 |
| Few-shot / 少样本示例 | 在提示中放少量“输入 → 期望输出”的样例，帮助模型理解边界和格式；不是重新训练模型。 |
| 输出格式 | 规定答案用自然语言、表格，还是固定字段的 JSON。格式应服务于后续使用方式。 |
| JSON Schema | 对 JSON 字段名称、类型和允许取值的约定；例如 status 只能是 eligible、ineligible 或 need_info。 |
| Token / 词元 | 模型处理文本的计量单位；长资料和示例会占用上下文窗口与成本。 |
| 上下文窗口 | 一次请求模型能处理的输入与生成内容的总容量上限，具体大小依模型而异。 |
| 提示注入 | 不可信网页或文档夹带指令，企图覆盖应用原有规则。把文档明确当“资料”仍需系统层权限控制。 |
| 评测集 | 一批有期望行为的固定案例，用于比较提示修改前后是否真的变好。 |
下面使用一个教学假设：公司政策 V3 规定“普通商品自签收之日起 7 个自然日内可申请退货”，且订单必须能查到签收时间。这里先只判断时间条件，不讨论商品类型、运费等真实政策细节。今天假设是 2026-09-26，订单 A17 的签收日期是 2026-09-23；订单 B28 的签收日期未知。所有日期与政策都是虚构数据，目的是检验提示的行为。
技巧一：把任务写成可检查的动作
含糊的说法：
你是优秀客服。请判断用户能不能退货，回答得专业些。
它没有说“依据什么判断”“缺签收日期怎么办”“是否能替用户操作”。模型可能自信地给 B28 一个结论，也可能误把“判断”扩展为“提交退货申请”。改成可检查的目标：
依据本次提供的政策版本和订单签收日期，只判断是否满足时间条件。若日期缺失，返回“需要补充签收日期”，不要猜测。给出使用的政策版本和日期依据。不要提交申请，也不要承诺最终退款结果。
这样每句话都有测试方法：是否用了 V3、是否在 B28 上停止判断、是否错误提交或越权承诺。OpenAI 的提示指南建议给明确任务与相关上下文；Google Cloud 也强调清晰、具体的指令及迭代评估。OpenAI Prompt Engineering · Google Cloud Prompt Design Strategies
所谓“设定角色”，如“你是客服助手”，可以帮助约定语气和领域，但角色本身不会提供最新政策或订单事实。如果关键资料缺失，写再强烈的身份设定也不能补上证据。
技巧二：把资料、指令和用户问题分开
模型要判断 A17，需要两类事实：政策 V3 的时间规则、订单 A17 的真实签收日期。建议在应用里把稳定规则放在高优先级指令中，把检索/数据库返回明确标成“待参考资料”，把用户问题单独放置。可读性好，也更方便追踪错误来源。不能把从网页抓到的整段文字直接拼成新的系统规则；网页内容可能是错误信息或提示注入。OpenAI Agent 安全指南
给人看的一个简化模板如下。它只是教学上的内容结构，实际消息角色、工具结果格式由所用 API 决定：
text
【任务】只判断普通商品的退货时间条件；不执行退货。
【规则】只能依据下面的政策和订单事实；缺关键事实就回答“需要补充”。
【政策资料】版本 V3：签收之日起 7 个自然日内可申请。
【订单事实】订单 A17：签收日 2026-09-23。
【当前日期】2026-09-26。
【用户问题】订单 A17 现在还在申请时间内吗？
【输出】结论、依据的日期计算、政策版本；不要推断未给出的商品条件。这里 A17 是教学订单号；V3 是政策版本标记；“当前日期”必须来自可信时间源，不应让模型自己猜；“订单事实”应来自受控查询结果。按照假设，9 月 23 日到 9 月 26 日相隔 3 个自然日，满足“7 个自然日内”的时间条件。回答应说“时间条件满足；完整退货资格还要核对其他政策条件”，不能把局部判断扩大为“肯定可以退款”。
长文档任务也要管住资料量。可以先检索与问题相关、带版本和来源的片段，避免整库内容塞进提示；同时检查被检索片段是否真含答案。模型上下文窗口有限，长资料会增加费用，也可能使关键条件被淹没。OpenAI 的提示指南对上下文窗口和检索补充资料有单独说明。OpenAI Prompt Engineering
技巧三：把“缺信息”和“越界”写进提示
对订单 B28，系统查不到签收日期。即使今天是 9 月 26 日，也无法算出“签收后几天”。提示应明确：缺日期就返回待补充，不得用下单日、付款日或聊天里出现的模糊时间替代签收日。这是一个比“请不要胡编”更可执行的边界，因为它说明了哪个字段缺失、不能用什么代替、下一步应是什么。
还要规定哪些动作不在任务内：本例只判断时间，不能调用提交退货工具。若模型输出“已帮您提交”，无论语气多自然，都属于严重失败。真正的授权还应由系统工具层检查；提示文字不能单独提供安全保证。
失败路径也要能处理资料冲突。假设检索到政策 V2 和 V3，两份生效日期不清楚，不能挑对自己有利的一份。返回“政策版本无法确认，需要核实适用规则”，或让系统按明确的生效规则选择。否则会出现“引用了政策，但引用错版本”的假可靠。
技巧四：用少量示例教边界，别堆同一种正例
少样本示例适合教模型一种团队特有的判定格式，尤其要放容易混淆的边界样例。例如只给一个“已签收 3 天，时间条件满足”的正例，模型可能学到“一律回答可退”。可用两到三个覆盖不同情况的例子：
| 输入事实 | 期望输出的关键点 |
|---|---|
| 已签收 3 天，政策上限 7 天 | 时间条件满足，仍需核其他条件。 |
| 签收日期缺失 | 需要补充签收日期，不给肯定或否定结论。 |
| 资料同时出现 V2、V3，生效关系未知 | 政策版本待核实，不擅自选规则。 |
这些示例要和实际规则一致；示例若写错，模型也可能复制错误。还要考虑输入分布：只有简短中文正例，却要处理很长的多语言投诉邮件，迁移未必可靠。OpenAI 指南将 few-shot 描述为在提示中给输入/输出样例，并建议覆盖不同输入；Google Cloud 也把示例与测试迭代列为常用策略。OpenAI Prompt Engineering · Google Cloud Prompt Design Strategies
示例不是越多越好。每个例子占 token，可能造成成本与上下文压力；若复杂规则经常更新，应维护权威政策数据，而不是把一堆旧例永久贴在提示里。
技巧五：让输出方便人和程序核对
如果答案只给人看，一段简洁自然语言加政策引用可能够用。若后面有程序要按结论分流，可约定结构化字段。先用中文把字段意义讲清：status 表示时间条件的判定，reason 是可读理由，policy_version 是使用的政策版本；它们只是本例人为起的字段名，不是模型内置变量。
json
{
"status": "eligible",
"reason": "2026-09-23 签收，至 2026-09-26 相隔 3 个自然日；满足 V3 的 7 日时间条件",
"policy_version": "V3"
}这里 eligible 只表示满足时间条件，不代表最终退款已获批。B28 的 status 应为 need_info，reason 明确指出“缺签收日期”。若用了 JSON Schema 等结构化输出机制，能更稳定地约束字段类型和允许值；符合格式仍不保证事实正确，还要检查日期、政策版本和证据。OpenAI 的结构化输出文档也提醒：当输入与任务不相容时，应设计明确的空值或失败状态，模型即使符合 Schema 仍可能给错误内容。OpenAI Structured Outputs
如果是需要调用工具的 Agent，进一步把“查询订单”“读取政策”和“提交退货”做成不同的受控接口。只读判断时不给提交权限；即使模型在 Prompt 里被诱导说“现在提交”，宿主程序也会拒绝。这比在文字里重复十遍“不要提交”更可靠。
技巧六：用固定案例迭代，而非凭感觉调词
改提示前先准备一批题，至少覆盖：正常签收、恰好第 7 天、超过 7 天、缺签收日期、政策版本冲突、用户要求直接提交、外部文档夹带恶意指令、长上下文中有干扰日期。每题写明期望行为与严重程度。然后固定模型版本、检索资料和评分口径，比较提示 A/B 的整单正确率、缺信息处理率、越权次数、回答长度和成本。OpenAI Evaluation Best Practices · OpenAI Prompting 指南
一次常见误判是：修改提示后，10 道手工挑选的简单题从 8 道对升到 10 道对，就宣布“提示优化成功”。如果新提示在缺签收日期的 20 道边界题里更爱猜，整体产品反而更危险。应按任务类别分别报告，留未参与修改的测试集；提示改动连同例子、政策版本一起记录，方便复现与回滚。
也不要迷信固定口诀。不同模型和任务可能需要不同力度的步骤说明。OpenAI 对推理模型的官方指导指出，“请一步一步思考”等技巧不一定提升表现，甚至可能妨碍；更稳妥的是给清晰目标、必要资料、输出标准，再依据评测结果调整。OpenAI Reasoning Best Practices
面试时怎么回答
Prompt 设计先明确任务成功标准，再把稳定指令、用户输入、可信数据与外部资料区分开；写清目标、使用哪些事实、不能做什么、缺信息或资料冲突时如何处理，以及输出给人还是给程序。若模型容易误解格式或边界，可以给少量覆盖正例和反例的示例；需要程序消费时用结构化输出和字段校验。但角色设定、格式约束都不能代替真实数据、权限检查和事实验证。最后用固定的正常与失败案例比较版本，记录准确率、越权、延迟和成本；不同模型要依实际测试调整，不靠“万能提示词”。
追问“怎样降低幻觉”，回答：提供可追溯资料、允许明确说不知道、要求引用并核验依据；资料缺失时停在“需要补充”，不能靠更强的语气要求模型凭空知道。追问“是否一定写 Chain-of-Thought”，回答：不一定，应按模型官方指导和任务评测决定；重要的是可验证的最终结果与工具执行轨迹，而非强迫输出冗长的内部推理。
资料依据
- OpenAI：Prompt Engineering：清晰指令、示例、检索上下文与窗口约束。
- Google Cloud：Prompt Design Strategies：任务、上下文、示例与迭代。
- OpenAI：Structured Outputs：Schema 的作用与内容正确性边界。
- OpenAI：Reasoning Best Practices：推理模型的提示差异。
- OpenAI：Evaluation Best Practices：用测试集而非印象验证提示改动。
- OpenAI：Safety in Building Agents：不可信输入与提示注入的系统边界。