Prompt 常见结构有哪些?
未标记
考查重点:任务、输入边界与输出契约。写清要做的动作、输入边界、背景约束和输出格式,必要时给例子;角色只是视角,不能替代明确任务
本题目录
参考答案
核心回答
Prompt 常按角色、任务、背景、输入、约束和输出要求组织,必要时补充示例:
- 角色:采用什么专业视角、语气和受众深度。
- 任务:具体完成什么动作,例如提取、分类、比较或生成。
- 背景:理解任务需要的业务规则、术语和参考资料。
- 输入:本次真正要处理的文本、数据或问题。
- 约束:允许使用哪些信息,遇到缺失、冲突或不确定情况怎样处理。
- 输出要求:结果包含哪些内容,采用什么格式、字段、长度或语言。
这些是组织维度,不是必须写齐的固定模板。简单任务可以一句话说明,复杂任务再用标题或标签分区;聊天应用还常用 system、user、assistant 等消息角色组织稳定规则、本次请求和历史对话。文本里的“角色设定”与 API 的消息角色不是同一概念。
各部分分别解决什么问题
任务决定“做什么”,输出要求决定“结果怎样交付”。只写“你是专家”没有交代具体工作;只写“输出 JSON”也没有说明字段含义和判断标准。
背景与输入也应分清。客服工单的类别规则是背景,客户刚发来的消息是本次输入;分析报告中的行业定义是背景,待分析的表格是输入。把规则、示例和待处理数据混成一长段,模型更容易把示例当成当前内容,或把资料中的指令当成任务要求。
约束要可执行并且相互一致。例如“缺少订单号时填 null”比“尽量准确”更明确;“只根据给定文档回答,资料不足时指出缺口”能说明证据边界。若同时要求“必须给确定结论”和“没有证据不能判断”,需要先解决冲突,而不是继续添加强调词。
角色主要提供视角与表达方式,不能赋予模型原本没有的事实或工具能力。“资深数据库专家”不能代替表结构、实际版本和错误信息。
常见组织方式怎样选择
一句话任务说明适合翻译、提取一个字段或小范围改写。例如“把下列段落改为面向普通用户的中文,保留金额和日期,不超过三句话”。信息已足够,就不必再写完整角色背景。
分区文本适合规则较多、输入较长的任务。可以用 Markdown 标题或 XML 等标签区分指令、资料、示例和当前输入。标签名称清楚且一致即可,不存在某种标签天然最有效的保证;分隔符帮助理解结构,也不等于程序已经建立安全隔离。
结构化消息适合聊天应用。稳定的应用规则可以放在接口支持的 system 等指令位置,user 消息承载本轮请求,assistant 消息记录历史回复。具体支持哪些角色和优先级,需按目标接口核对。在普通 user 文本里写一行“System:”,不会自动得到真正系统消息的地位。
带示例的结构适合分类边界、语气或格式不易只靠文字说明的情况。示例是补充判断方式,不是另外一种必须套用的万能结构。
用一个工单提取任务说明
下面是简化的 Prompt 示例:
角色:客服工单分类助手。
任务:从客户消息中提取工单信息,不执行订单查询或退款。
背景:类别只能是“物流、支付、售后、其他”。
规则:只使用消息中明确的信息;订单号缺失填 null,并列出待补信息。
输出:只输出 JSON,字段为 category、order_id、need_info;need_info 为字符串数组。
客户消息:
<message>包裹两天没更新了,帮我查一下。</message>
符合这里约定的结果可以是:
{ "category": "物流", "order_id": null, "need_info": ["订单号"] }
这个结构说明了任务、业务分类、本次输入和缺失值规则,模型无需猜测订单号。若后续出现支付与售后类别难以区分的真实问题,可以补充类别定义和代表性例子,而不是仅增加“认真判断”的要求。
示例与规则怎样配合
先用清晰指令测试,再针对具体失败补充信息。示例应与任务相关,格式保持一致,并覆盖容易混淆的类别、缺失字段或异常输入。只给正常样本,模型可能把正常路径的假设带到所有情况;只给同一类别,也可能形成不必要的偏向。
示例数量和顺序应根据模型、任务和上下文预算验证,不固定为某个数字。长文分析还需要清楚标明资料出处和当前问题,不能认为任何任务都应采用同一种“角色在前、结论在后”的顺序。
复杂任务可以拆步骤或多次调用,在需要的阶段检查中间结果。但没必要对每个简单请求都要求完整推理过程;通常让结果带上关键依据、引用或检查结论,就更便于核对。
追问:结构完整,就能保证效果吗?
不能。结构主要减少歧义,效果还取决于模型能力、输入质量、任务难度和上下文。可以用一组固定样本观察分类是否正确、缺失信息是否处理合理、格式是否稳定,再有针对性地修改并保留有效版本。
严格格式也不能只靠“请输出 JSON”。程序需要校验能否解析、字段类型、枚举及业务含义;需要更强格式约束时,可结合目标模型支持的结构化输出能力。即使 JSON 合法,也仍可能把类别判断错。涉及工具执行时,权限与参数验证由应用负责,不能用 Prompt 的约束代替。
对应教程
- 第 1-2 章:提示词工程基础:§2.2 的六要素、§2.3 的 Zero-shot/Few-shot 与 §2.4 的结构化组织,适合建立内容结构和示例的基本认识;各要素按任务需要取舍。
- 第 13 章:提示词与消息模板:§2 展示字符串和消息列表等输入形式,帮助把“提示词包含什么”与“怎样按消息发送”对应起来。
参考资料
- 国内:JavaGuide:Prompt Engineering:借鉴资料对任务、角色、上下文和格式的职责划分,组织正文的 Prompt 组成说明,并采用简洁指令与示例的建议解释按实际失败调整提示词的方法。
- 国内:Onefly / zero2Agent:Prompt 工程与框架原理:借鉴规则、上下文、任务和示例的分层思路,组织正文对 Prompt 内容分区与消息职责的说明。
- 国内:阿里云百炼:文本生成概述:依据系统、用户和助手消息的定义,说明正文中文本角色设定与 API 消息角色的区别;具体接口仍以其支持的角色为准。
- 国外:Anthropic:Prompting best practices:参考清晰指令、背景、示例、XML 标签与角色的组织建议,说明正文中指令、资料和本次输入的分区方式。
- 国外:Google:Prompt design strategies:借鉴明确指令与 Zero-shot/Few-shot 的说明,解释正文中示例对格式和分类边界的作用,以及按具体任务迭代示例的做法。
相关面经
12 篇公司未注明
后端开发工程师在使用 Spring AI 调用大模型时,你是如何设计 Prompt 的?如何通过 Prompt 引导大模型完成预期任务?
公司未注明
AI 应用开发工程师模型提示词结构
公司未注明
Agent 应用开发工程师系统提示词设计了哪些层面?
广电数科
Java 开发工程师你们的提示词如何设计的
上海九云数智
大模型应用开发工程师(RAG 方向)提示词工程了解吗,你会怎么写一个提示词,规范的流程是什么



