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 方向)
查看原面经 →
提示词工程了解吗,你会怎么写一个提示词,规范的流程是什么
展开剩余 7 篇面经

美团

软件开发工程师
秋招一面
查看原面经 →
UI跟AI交互需要写prompt吗?怎么写一个比较高效、让AI生成效果好(券/准)的prompt?

顺丰

Java 开发工程师
秋招一面
查看原面经 →
提示词优化策略

同花顺

Agent 开发工程师
社招一面
查看原面经 →
写一下你的prompt怎么用的

阿里巴巴

AI 应用算法工程师
实习
查看原面经 →
Prompt的常见结构

佰聆数据

AI 应用开发工程师
实习一面
查看原面经 →
对于提示词工程你有什么见解吗,提示词一般都要有什么内容?

快手

Java 开发实习生
一面
查看原面经 →
用ai工具时出现的问题,在ai coding时,最初的提示词对于生成的代码质量层面,是否有考虑?
自己做项目时,输入的提示词结构

阿里巴巴

Agent 开发工程师
实习一面
查看原面经 →
prompt你会怎么考量去写

收录题集

4 个来源,共5 份题集

阿里巴巴问答汇编

Rocky Ding · AIGC-Interview-Book · 1 条原题

查看题集 →

八股集锦(高频问题)

小熊饼干_ · 个人整理 · 1 条原题

查看题集 →

Prompt 工程与框架原理:模板构建、Skills 机制

Onefly · zero2Agent · 1 条原题

查看题集 →

Agent 面试题

Guide · JavaGuide · 1 条原题

查看题集 →

Agent 机制与项目追问

Guide · JavaGuide · 1 条原题

查看题集 →

相关题目

4 题