What is prompt engineering, and why is it important for LLMs
1️⃣ 考察意图
面试官想看的不是“背定义”，而是你能否区分 prompt engineering 是工程实践而非玄学。考察类型：概念 + 工程取舍。刁钻点在于：很多人把 prompt 等同于“写指令”，但面试官真正想听的是你理解 prompt 如何与模型预训练分布交互，以及如何用结构化方法（如 Chain-of-Thought、Few-shot 模板）系统性地提升输出质量。答好了能展示：对 LLM 底层机制（如注意力模式、token 概率分布）有认知，能设计可复用的 prompt 策略，而非靠运气调词。
2️⃣ 标准答
定义：Prompt engineering 是设计输入文本（包括指令、上下文、示例、格式约束）以引导 LLM 生成期望输出的过程。它不是“写作文”，而是对模型条件概率分布的有意操控——通过调整输入 token 序列，影响模型在每一步的 next-token 预测。
为什么重要？ 核心原因有三：
- 弥补预训练与下游任务的 gap：LLM 预训练时见过海量文本，但没专门优化过你的业务场景（如客服分类、代码生成）。好的 prompt 相当于“任务适配器”，把通用模型拉向特定分布。例如，用
"Classify the sentiment: Positive, Negative, Neutral"比直接问"What do you think?"的准确率高 15-20%（通用经验）。 - 控制输出质量与风格：通过角色设定（
"You are a senior Python engineer"）和格式约束（"Output as JSON: { 'answer': ... }"），可以大幅降低幻觉率。实际落地坑：不加格式约束时，模型常输出多余解释，导致下游解析失败。解法是在 prompt 末尾加一个“输出示例”，比如"Example: { 'answer': '42' }"，让模型模仿 token 序列模式。 - 实现复杂推理：单次 prompt 无法完成多步逻辑（如数学题、代码 debug）。Chain-of-Thought（CoT）通过插入
"Let's think step by step"或提供中间推理示例，把隐式推理显式化。论文《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》显示，CoT 在 GSM8K 上把准确率从 17.9% 提升到 58.1%（PaLM 540B）。工程取舍：CoT 增加 token 消耗（推理成本高 2-3 倍），但换来可解释性和准确率；在延迟敏感场景（如实时聊天）需权衡。
关键要素（按重要性排序）：
- 指令清晰性：避免歧义。用
"Summarize the following text in 3 bullet points"而非"Tell me about this"。 - Few-shot 示例：提供 2-3 个输入-输出对，让模型学习模式。注意：示例的多样性比数量重要——覆盖边界情况（如分类任务中加一个“中性”样本）能减少过拟合。
- 格式约束：用 markdown 或 JSON 模板锁定输出结构。坑：模型可能忽略格式，需在后处理加正则 fallback。
- 角色与语气：
"You are a helpful assistant"是基线，但业务场景需更具体（如"You are a strict code reviewer"）。
实际落地坑 + 解法：在电商客服场景，用 "Answer in Chinese" 仍会偶尔输出英文。根因是模型预训练数据中英文占比高，prompt 的“语言锚定”不够强。解法：在 prompt 开头和结尾各加一次语言约束，并给一个中文示例。例如：
请用中文回答。示例：用户问“退款流程”，回答“请登录APP点击退款”。 用户：{query} 回答（中文）： 这样把语言约束嵌入到 token 序列的起始和结束位置，利用注意力机制的双向强化。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从定义、重要性、关键要素三个层面回答。定义上，prompt engineering 是设计输入文本以引导 LLM 输出的过程，本质是操控条件概率分布。重要性体现在三点：弥补预训练与任务 gap、控制输出质量、实现复杂推理（如 Chain-of-Thought）。关键要素包括指令清晰性、Few-shot 示例和格式约束。总结一句：好的 prompt 不是玄学，而是基于模型机制的工程优化。”
4️⃣ 高频追问 & 应对
追问 1：你提到 Chain-of-Thought，那 Zero-shot CoT 和 Few-shot CoT 有什么区别？什么时候用哪个？
Zero-shot CoT 只需加
"Let's think step by step"，成本低但推理质量不稳定（尤其对数学题）。Few-shot CoT 需要 2-3 个带推理步骤的示例，准确率更高但 prompt 长度翻倍。工程取舍：在延迟敏感场景（如 API 调用）用 Zero-shot；在离线批处理或高精度需求（如代码生成）用 Few-shot。一个实际经验：如果任务需要多步逻辑（如“计算折扣后价格”），Few-shot CoT 的准确率比 Zero-shot 高 20-30%，但 token 消耗增加 50%。
追问 2：如果模型输出总是忽略格式约束，你怎么 debug？
三步排查：1）检查 prompt 中格式示例是否与输出格式完全一致（包括空格、换行），模型对 token 模式敏感；2）在 prompt 末尾加
"Output ONLY the JSON, no other text"并配合后处理正则提取；3）如果仍失败，改用系统消息 + 用户消息分离（如 OpenAI 的 system role），系统消息中写格式约束，用户消息中只给内容。实际案例：在分类任务中，用 system 消息"You must output 'positive' or 'negative'"后，格式错误率从 12% 降到 1%。
追问 3：Prompt engineering 和 fine-tuning 是什么关系？什么时候该用哪个？
Prompt engineering 是零成本快速迭代，适合原型验证或任务频繁变化（如客服话术每周更新）。Fine-tuning 是永久性调整模型权重，适合固定任务（如命名实体识别）且需要高精度。工程取舍：prompt 的边际收益递减——当优化 10 轮后准确率仍低于 85%，就该考虑 fine-tuning。一个经验法则：如果 prompt 长度超过 2000 token 且效果仍差，说明任务与预训练分布偏差太大，fine-tuning 更划算。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“prompt engineering 就是写更长的 prompt” → ✅ 正确切入：长度不是关键，结构化和示例质量才是。长 prompt 可能引入噪声，导致模型注意力分散。应该用 Few-shot 示例和格式约束替代冗余描述。
- ❌ 说“prompt 能解决所有问题，不需要 fine-tuning” → ✅ 正确切入：prompt 有天花板，当任务需要领域知识（如医疗诊断）或输出格式极其严格（如 SQL 生成），fine-tuning 是必要补充。prompt 适合快速验证，fine-tuning 适合生产固化。
- ❌ 说“Chain-of-Thought 总是更好” → ✅ 正确切入：CoT 增加推理成本，且对简单任务（如情感分类）可能过度推理导致错误。应该根据任务复杂度选择：简单任务用直接 prompt，复杂任务用 CoT。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“prompt 在检索增强中的角色”切入，强调如何设计 prompt 让模型只基于检索结果回答（如
"Answer based ONLY on the following context"），并对比不加约束时的幻觉率。 - 如果你只做过传统 NLP：用“分类任务”类比——prompt 相当于传统 NLP 中的特征工程，都是通过输入设计影响模型输出。可以举例：在 BERT 时代用
[CLS]做分类，现在用 prompt 做 zero-shot 分类。 - 如果你是校招无项目：聚焦“论文复现 demo”——用 GPT-3.5 复现 Chain-of-Thought 论文中的 GSM8K 实验，对比 Zero-shot 和 Few-shot 的准确率差异，并分析 token 消耗。这能展示动手能力和对论文的理解。
- 《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》（Wei et al., 2022）
- 《Pre-train, Prompt, and Predict: A Systematic Survey of Prompting Methods in Natural Language Processing》（Liu et al., 2021）
- 《Language Models are Few-Shot Learners》（GPT-3 论文，Brown et al., 2020）
- OpenAI Prompt Engineering Guide（官方文档，含最佳实践和示例）
- 《The Power of Scale for Parameter-Efficient Prompt Tuning》（Lester et al., 2021）