高频面试题

有哪些设计和优化 Prompt 的技巧？请举例说明

这题看似开放，实际考的是你能不能把技巧归类，并知道每个技巧解决什么问题、有什么副作用。

适合阶段：Prompt 入门到进阶核心能力：结构化表达 · 示例设计 · 评估迭代

面试官角度分析，想考什么

• 你是否只会背“角色扮演、一步步思考”？
  考察能否按问题类型选择技巧。
• 能不能给出可落地例子？
  考察 Prompt 是否具体、可执行、可验证。
• 知道技巧的副作用吗？
  考察成本、幻觉、格式稳定性和安全边界。
• 如何持续优化？
  考察评估集和失败样本回流。

可直接抄走的 30 秒参考答案

我一般把 Prompt 技巧分成几类：先清晰化目标和边界，再用 Markdown、XML 或 JSON 结构化输入输出；标准抽象时加 Few-shot 示例；任务复杂时做分解；格式强约束时用 schema 或 function calling；容易幻觉时要求基于资料回答和缺失时拒答。优化时一定结合评估集，看正确性、格式、稳定性、成本和安全，而不是凭感觉改。

面试回答详解，知其所以然

Prompt 优化不是“咒语大全”。成熟做法是先看任务失败在哪里，再选择对应技巧。

1. 清晰化任务目标

差的 Prompt：

帮我分析一下这段数据。

更好的 Prompt：

请分析下面的销售数据，输出 3 部分：
1. 发现 3 个最重要的变化趋势
2. 解释可能原因
3. 给出下一步需要验证的问题
不要编造数据中没有的指标。

技巧重点：说明目标、读者、输出数量、不要做什么。

2. 结构化输入和输出

把 Prompt 分成任务、输入、约束、输出格式：

## 任务
从用户反馈中抽取问题类型和紧急程度。

## 输入
"""
{feedback}
"""

## 输出
严格 JSON：
{"category": "...", "priority": "low|medium|high", "reason": "..."}

结构化能降低歧义，也方便后端解析和评估。

3. 使用 Few-shot 示例

当任务标准抽象、边界难说清时，用示例更有效：

• 给 2-5 个覆盖不同类型的样例。
• 示例要短而典型。
• 包含一个边界或反例。
• 示例输出格式要和目标格式完全一致。

Few-shot 的风险是占 token、可能过拟合示例风格，所以要定期评估。

4. 任务分解

复杂任务不要一次让模型完成所有事：

先判断用户意图
-> 再检索资料
-> 再生成回答
-> 最后检查格式和事实

任务分解适合多约束、多步骤和高风险场景。缺点是调用次数和延迟增加。

5. 使用约束和反例

约束要可检查：

• “不超过 200 字”比“简洁”更可执行。
• “只输出 JSON，不要 Markdown 代码块”比“格式规范”更明确。
• “资料没有提到时输出无法判断”比“不要幻觉”更可操作。

反例适合纠正常见错误：

不要输出：
{"priority": "紧急"}
因为 priority 只能是 low、medium、high。

6. 用评估闭环优化

每次优化都应该回答三个问题：

• 修复了哪类失败？
• 有没有伤害原本通过的样本？
• 成本、延迟、安全是否变化？

没有评估闭环的技巧只是经验，不能稳定复用。

面试官追问3个问题

追问一：Role Playing 还有用吗？

• 考察点：是否迷信角色提示。
• 回答方向：有用但不是核心。它更适合语气、职责边界和多 Agent 分工；对现代指令模型，清晰任务通常比“你是专家”更重要。

追问二：什么时候用 Few-shot？

• 考察点：示例设计能力。
• 回答方向：当规则难以完整描述、输出风格需要对齐或分类边界模糊时使用；示例要覆盖典型和边界场景。

追问三：Prompt 越详细越好吗？

• 考察点：成本和注意力边界。
• 回答方向：不是。详细要服务于减少歧义，冗余规则会增加 token、引发冲突，还可能让模型忽略关键信息。

扩展知识

技巧和问题的对应关系

• 输出跑偏：补任务目标、角色边界和拒答条件。
• 格式错误：用结构化输出、schema、示例和解析重试。
• 事实错误：补 RAG、引用要求和缺信息处理。
• 推理错误：用 CoT、候选方案比较或工具验证。
• 结果不稳定：降低随机性，固定版本，收紧约束。