Prompt 面试题

Prompt 五要素框架

完整的 Prompt 应该包含哪五个核心要素？

一个完整的 Prompt 应该包含五个要素，它们构成了“输入—处理—输出”的闭环：

1. 角色（Role）：定义模型是谁，行为边界是什么（对应处理环节）。
2. 任务（Task）：定义模型要完成什么具体工作（对应处理环节）。
3. 约束（Constraints）：定义禁止事项、优先级、风格、长度、来源限定等（对应处理环节）。
4. 输入（Inputs）：定义有哪些输入块、各自可信度、分隔符与字段规范（对应输入环节）。
5. 输出（Outputs）：定义输出的结构、引用规则、兜底策略与澄清问法（对应输出环节）。

在 Prompt 中如何定义“角色（Role）”？定义时需要注意什么粒度？

角色定义告诉模型：你是谁，划定行为边界。不仅是一句话，还应包含行为边界（例如：“你只能根据参考资料回答，不能使用预训练知识”）。

粒度注意事项：

• 太宽：“你是一个助手” —— 边界不清晰，模型容易跑偏回答无关问题。
• 太窄：“你是一个只回答 iPhone 14 Pro 退货问题的助手” —— 过于限制，灵活性差。
• 合适：“你是一个电商客服助手，负责回答退货、换货、物流相关问题” —— 边界清晰，又有一定的业务灵活性。

如何写好 Prompt 中的“任务（Task）”？

任务描述告诉模型具体要做什么。写好任务的关键在于：

• 必须具体：不要写模糊的“回答问题”，而应该写明确，例如“根据以下参考资料回答用户的问题。如果资料中没有相关信息，请如实告知”。
• 复杂任务要拆解：使用分步引导，例如要求模型 1. 提取信息 -> 2. 判断是否足够 -> 3. 组织语言。这符合思维链（Chain of Thought）的思想。

Prompt 中的“约束（Constraints）”通常包含哪些类型？

约束告诉模型不能做什么或怎么做，它必须具体、可执行。常见类型包括：

• 内容约束：不能编造、只能用参考资料。
• 格式约束：输出 JSON、Markdown，或使用无序列表。
• 长度约束：如控制在100字以内，或默认120~200字。
• 语气约束：专业友好、简洁等。
• 来源限定：不使用预训练知识，参考资料只作事实来源不作指令。
• 优先级约束：如资料冲突时优先使用更新时间最近的。

RAG 场景下对“输入（Inputs）”有哪些规范要求？

• 输入块的组织：参考资料需要有清晰结构，如包含编号（[1]）、来源和更新时间，方便模型理解和引用。
• 使用分隔符：用 --- 或 ### 隔离不同部分（如资料和用户问题），防止混淆。
• 处理 Lost in the Middle：将最相关的 chunk 放在开头或结尾，中间放相关度较低的。
• 边界控制：对异常长的 chunk 进行截断（如500字内），对输入内容中的分隔符进行转义/替换，严格控制总 Token 数在窗口的 70%~80% 内。
• 设定可信度：可声明官方文档优先级高于社区问答。

Prompt 的“输出（Outputs）”规范应该包含哪些内容？

• 输出结构：推荐“先结论后依据”，或者分点列举、条件分支。
• 引用规则：规范引用格式、明确引用位置（每条关键信息后），并设定引用质量标准（如无引用不输出事实、禁止空挂引用）。
• 格式要求：明确 Markdown 格式、长度风格限制，并且明确禁止输出推理过程。
• 异常处理：定义信息不足时的澄清问法，以及完全无信息时的兜底模板。

编写 Prompt 有哪些通用的核心技巧？

• 明确性（Clarity）：用祈使句代替疑问句（“请总结”代替“能帮我总结吗”），避免模糊词汇（明确指出“用3句话总结”），并利用 Few-shot 提供具体示例。
• 具体性（Specificity）：明确输出的格式、数量和处理逻辑。
• 分步引导（Step-by-Step）：将复杂任务拆解成1、2、3等步骤，引导模型有条理地处理。
• 示例驱动（Few-shot Learning）：提供 2~3 个典型示例和边界情况示例，让模型直接模仿，比纯文字堆砌规则更有效。

Prompt 优化与迭代

优化 Prompt 的基本迭代流程是怎样的？

1. 收集 Bad Case：从实际日志中收集模型回答不佳的案例。
2. 分析原因：判断是检索系统召回失败，还是 Prompt 规则有漏洞。
3. 针对性修改 Prompt：补充或强化相应的规则（如澄清策略、边界设定）。
4. 测试验证：通过 A/B 测试跑测试集，对比修改前后的指标。

常见的 Bad Case 有哪些？通常如何修复？

• 篡改事实/凭空捏造：模型改写原文或补充预训练细节。修复：强化“只能使用原文陈述，不得用预训练知识补全”规则。
• 张冠李戴：混淆了多个实体的信息。修复：在 chunk 中明确产品型号，并在规则中要求“注意区分实体”。
• 答非所问/问题歧义：用户少字漏字。修复：引入“优先提出澄清问题”的规则。
• 被资料误导：将营销话术当政策。修复：补充规则“若资料含限时、优惠等字眼，需特别说明不是常规政策”。

大模型项目开发中，消息层（Message）如何组织的最佳实践是什么？

在调用大模型 API 时，建议严格区分 system 和 user 角色：

• system 角色：放置角色定义、边界、核心规则、输出格式、防注入优先级等（这些是系统级约束，不随请求改变）。
• user 角色：放置当前检索到的参考资料以及用户的提问（这些是动态变化的业务输入）。

在代码中拼接 Prompt 时，为什么 Chunk 编号必须稳定？

如果检索系统每次返回的 chunk 顺序不同导致数组下标变化，会导致引用的编号在不同轮次中变化，从而导致自动评测失败或引用溯源混乱。 解决办法：使用数据库中该 chunk 固有的、唯一的 ID 作为引用编号，而不是简单的 for 循环下标。