考察点
这是 Prompt 工程的入门题，也是筛人题。面试官想区分「会聊天式提问」和「会工程化写 Prompt」的候选人：前者凭感觉堆字，后者有稳定可复用的模板方法论。追问一般会往「你们项目里的 Prompt 模板长什么样」「怎么让团队几十条 Prompt 保持一致风格」走。
参考答案
五要素：一个都不能少
生产环境的 Prompt 我习惯拆成五个部分，缺哪个补哪个：
- 角色（Role）：告诉模型它是谁。「你是一名有 10 年经验的电商售后客服主管」比「你是客服」有效得多，角色越具体，模型调用的知识分布越集中。注意角色不是玄学，它本质是调节先验——让模型把生成重心偏向某个专业语料子空间。
- 任务（Task）：一句话说清要干什么，用动词开头。「判断这条用户反馈属于哪类问题」而不是「处理一下这条反馈」。任务描述模糊是 Prompt 失效的第一大原因。
- 上下文（Context）：模型完成任务需要的背景信息，比如业务规则、知识库检索结果、对话历史。RAG 场景下这部分是动态注入的。
- 约束（Constraints）：负面清单和边界。「不知道就说不知道，不要编造订单号」「回复不超过 200 字」「不要使用专业术语」。约束写得好，幻觉和跑题能压掉一大半。
- 输出格式（Output Format）：明确要什么形态。要给下游程序消费就写明 JSON Schema 并给一个示例；要给人看就指定结构，比如「先结论后理由」。
工程化细节
实际项目里还有几个教科书不讲的点：
- 分隔符：上下文和用户输入用
###、XML 标签或三个引号包起来，比如<context>...</context>。一是帮模型区分指令和数据，二是防御注入的第一道墙——用户输入被包在标签里，模型更不容易把它当成新指令。 - 变量占位符：模板用
{user_query}、{retrieved_docs}这类占位符，代码里做渲染。LangChain 的ChatPromptTemplate或者自己用 Python 的str.format都行，关键是 Prompt 和代码解耦，运营也能改模板。 - 指令放哪：实验上，关键约束放在 Prompt 开头和结尾各强调一次效果最好。长上下文里模型对中间部分的注意力最弱（lost in the middle 现象），重要的规则不要埋在段落中间。
- 一份模板多处复用：我们把五要素做成 YAML 配置，不同业务场景只改任务和约束部分，角色和输出格式继承基座，几十条 Prompt 的风格和格式约定自然统一了。
反例长什么样
「帮我写个营销文案」就是典型反例：没有角色（写给谁看、什么口吻）、没有上下文（产品是什么、卖点是什么）、没有约束（多长、禁用什么词）、没有格式（标题+正文还是 slogan）。模型只能靠猜，输出自然不稳定。面试时能主动举出这种对比，比背五要素定义加分得多。
可能的追问
- 五要素有先后顺序要求吗？ 一般按角色→上下文→任务→约束→格式组织，但不是铁律。关键是关键信息别放在长上下文正中间，重要约束首尾呼应。
- 上下文部分太长怎么办？ 先做信息筛选和压缩，RAG 场景控制检索条数和 chunk 长度；必要时把长文档放前面、指令放最后，利用模型对结尾的注意力偏好。
- System Prompt 和 User Prompt 怎么分工？ 稳定的角色、规则、格式放 System；每轮变化的输入放 User。这样 System 部分还能吃到 KV Cache 前缀复用的推理加速。