考察点
这道题是提示工程的开胃菜，面试官想看你是不是把 Prompt 当成「一句咒语」来写，还是当成一个结构化输入来设计。能不能讲清每个模块的作用、缺失时的影响，以及 token 预算有限时怎么取舍，是分水岭。追问通常会往「system 和 user 角色有什么区别」「上下文太长砍哪部分」方向走。
参考答案
Prompt 的典型组成
一个完整的 Prompt 可以拆成六个模块，不是每次都要全有：
- 角色与系统设定（System Prompt）：定义模型的身份、行为边界、输出风格。比如「你是一个资深后端工程师，回答只用中文」。它影响整个会话的基调。
- 任务指令（Instruction）：告诉模型要做什么，是最核心的部分。「把下面这段评论分类为正面/负面/中性」。
- 上下文（Context）：模型完成任务所需的背景信息，可能来自 RAG 检索结果、历史对话、业务数据。
- 输入数据（Input）：当前这条请求真正要处理的内容，比如待分类的评论原文。
- 输出要求（Output Format）：格式约束，比如「用 JSON 返回，字段为 label 和 reason」。
- 示例（Few-shot Examples）：若干输入输出对，用来校准模型对任务的理解。
哪些必须注入
严格意义上只有两样不能少：任务指令和当前输入。缺了指令模型不知道干什么，缺了输入模型无事可做。System Prompt 严格说也不是必须的，很多场景直接写在 user 消息里也能跑，只是稳定性和优先级有差别。
其余三个都是按需注入：
- 上下文：任务依赖外部信息时才需要，比如问答类 RAG；纯创作、翻译类任务可以没有。
- 输出要求：下游有程序解析时强烈建议加，纯给人看的对话可以省略。
- 示例：任务表述有歧义、格式特殊、或者 zero-shot 效果差时才加，能省则省，因为示例最吃 token。
工程实践中的取舍
实际项目里我会先算 token 账。比如用 128K 上下文的模型做 RAG 问答，预算大致这样分：System + 指令控制在 500 token 以内，检索上下文给到 4K-8K，历史对话 2K，其余留给输出和余量。检索内容塞得越多，噪声越多，答案质量反而下降，所以「上下文不是必须注满」这一点要在面试里讲出来。
模块顺序也有讲究。指令尽量靠近输入数据，长上下文场景下模型对开头和结尾的内容最敏感（lost in the middle 现象），关键约束放最后比埋在中间效果好。另一个细节是用分隔符把输入数据包起来，比如 """ 或 XML 标签，既能帮模型区分指令和数据，也能缓解一部分注入问题。
最后提醒一点：写代码时别把 Prompt 拼成一个大字符串了事，应该用模板化管理（比如 LangChain 的 ChatPromptTemplate 或者自己维护的 Jinja 模板），每个模块可插拔、可单测，这样后面做效果迭代才有抓手。
可能的追问
- System Prompt 和把同样的话写进 user 消息有什么区别？ 模型训练时对 system 角色赋予了更高的指令优先级，多轮对话中 system 的约束力衰减更慢；部分模型的越狱防护也主要挂在 system 层。另外 system 只需注入一次，放 user 里每轮重复会浪费 token。
- token 不够用时先砍哪部分？ 先砍 few-shot 示例，再压缩历史对话（做摘要），检索上下文做精排截断，指令和输出格式约束尽量不动——砍指令等于改需求。
- 指令放开头还是结尾？ 长上下文场景放结尾（贴近输入）效果更稳；短 Prompt 差别不大。系统级规则放开头的 system 里，任务级指令跟随输入走。