What are certain strategies to write good prompt
1️⃣ 考察意图
这道题看似基础，实则考察候选人对提示工程（Prompt Engineering）的系统性理解，而非背诵几个“技巧”。面试官想看你能否从“工程化”角度，将提示设计从玄学变为可复用的方法论。刁钻点在于：很多人只会说“角色设定”和“few-shot”，但无法解释为什么有效（如In-Context Learning的机制），也无法应对复杂任务（如多步推理、输出控制）。答好了能展示你对LLM能力的边界认知、工程取舍（如成本 vs 效果）和迭代优化能力，这是大厂做Agent/RAG落地的硬实力。
2️⃣ 标准答
好的提示策略不是“魔法咒语”，而是一套可复用的工程框架。我从四个层面展开：结构设计、推理引导、输出控制、迭代优化。
结构设计：明确角色、任务与格式
- 角色设定（Role Prompting）：给模型一个身份锚点，如“你是资深数据分析师”，能激活特定知识分布。为什么有效：LLM在训练时见过大量“角色+任务”的配对，角色能缩小语义搜索空间，提升输出一致性。
- 任务分解（Task Decomposition）：将复杂任务拆成子步骤。例如，做“从财报中提取风险点并生成摘要”，先写“Step1: 提取所有风险相关句子；Step2: 按风险类型分类；Step3: 生成100字摘要”。坑：步骤太多（>5步）会导致模型遗忘或跳步，建议用Markdown列表或XML标签（如
<step1>）显式分隔。 - 格式约束：明确输出格式，如“输出JSON，key为‘risk_type’和‘description’”。工程取舍：强制JSON可能降低生成质量（模型需额外解码），但能直接接入下游系统，节省解析成本。
推理引导：让模型“想清楚”
- Few-shot示例：提供2-3个输入-输出对。关键：示例要覆盖边界情况（如“正常”和“异常”），且顺序影响结果——最新示例权重最高（Recency Bias）。实战坑：示例太多（>5个）会超过模型上下文窗口，且成本线性增长。建议用DPR（Dense Passage Retrieval）动态选择最相关的示例，而非硬编码。
- Chain-of-Thought (CoT)：用“Let’s think step by step”触发推理链。为什么有效：CoT将隐式推理显式化，让模型在每一步生成中间变量，减少“跳跃错误”。取舍：CoT增加输出长度（token成本翻倍），但能明显提升数学/逻辑任务准确率（论文显示在GSM8K上从18%提升到58%）。
- Zero-shot CoT：直接加“Let’s think step by step”即可，无需示例。适合简单推理，但复杂任务仍需Few-shot CoT。
输出控制：长度、风格与安全
- 长度控制：用“max_tokens=200”或“输出不超过3个要点”。坑：模型可能截断句子，导致语义不完整。解法：用“输出一个包含3个要点的列表，每个要点不超过20字”这种双重约束。
- 否定指令：避免“不要输出XX”，模型对否定词敏感度低。正确做法：用正面指令替代，如“只输出事实，不包含观点”而非“不要输出观点”。
- 安全护栏：加“如果问题涉及敏感内容，回复‘无法回答’”。实战：结合系统提示（System Prompt）和用户提示，系统提示优先级更高，但用户提示可覆盖。
迭代优化：基于错误分析调整
- A/B测试：对同一任务写2个提示版本（如一个用角色，一个用示例），在50个样本上对比准确率或ROUGE-L。取舍：人工评估成本高，可用LLM-as-Judge（如GPT-4打分）自动化，但需校准偏差。
- 错误分类：将失败案例分为“格式错误”“推理错误”“遗漏信息”三类，针对性调整。例如，若模型总漏掉关键实体，在提示中加“必须包含以下实体：日期、金额、人名”。
- 动态提示：在RAG场景中，根据检索结果动态调整提示。例如，若检索到高置信度文档，提示中加“优先参考文档A”；若低置信度，加“请交叉验证”。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从结构设计、推理引导、输出控制、迭代优化四个层面回答。结构设计上，用角色设定和任务分解明确边界；推理引导上，用Few-shot和Chain-of-Thought让模型‘想清楚’；输出控制上，用格式约束和长度限制确保可用性；迭代优化上，基于错误分析做A/B测试。总结一句：好的提示是工程化的，不是玄学，核心是理解LLM的In-Context Learning机制和边界。”
4️⃣ 高频追问 & 应对
追问 1：Few-shot示例数量怎么选？多了会怎样？
示例数量取决于任务复杂度和模型上下文窗口。通用经验：分类任务2-3个足够，生成任务3-5个。多了的坑：① 成本线性增长（每个示例约100-500 tokens）；② 模型可能过拟合示例模式（如只输出示例中的实体）；③ 超过上下文窗口后，早期示例被遗忘（Lost in the Middle现象）。解法：用DPR动态选择最相关示例，或对示例做“重要性排序”，把关键示例放最后。
追问 2：Chain-of-Thought在什么场景下失效？
CoT在需要精确计算或事实性回答时可能失效。例如，数学题中模型可能“编造”推理步骤（幻觉），或长链推理中中间步骤错误累积。应对：① 对数学任务，用“代码解释器”替代CoT（让模型写Python代码执行）；② 对事实性任务，结合RAG（检索+CoT），让推理基于检索结果；③ 限制推理步数（如“最多3步”），减少累积误差。
追问 3：如何评估提示的好坏？有没有量化指标？
有。自动化指标：① 格式正确率（如JSON解析成功率）；② 任务准确率（如分类F1、生成ROUGE-L）；③ 输出长度偏差（是否在约束范围内）。人工指标：① 相关性（1-5分）；② 完整性（是否遗漏关键信息）；③ 安全性（是否包含有害内容）。实战：用LLM-as-Judge（如GPT-4对输出打分）做自动化评估，但需校准——GPT-4偏好长文本，所以要对齐评分标准（如“长度不超过50字得高分”）。
5️⃣ 避坑 · 常见错误答法
- ❌ 只背技巧：“用角色设定、few-shot、CoT就行。” → ✅ 解释机制：“角色设定利用LLM的In-Context Learning，缩小语义空间；CoT通过显式推理链减少跳跃错误。”
- ❌ 忽略工程取舍：“示例越多越好。” → ✅ 指出成本与效果平衡：“示例超过5个后收益递减，且增加token成本，建议用动态选择。”
- ❌ 不区分场景：“所有任务都用CoT。” → ✅ 按任务类型选择：“简单分类用Zero-shot，复杂推理用Few-shot CoT，数学任务用代码解释器。”
6️⃣ 简历呼应
- 如果你有RAG项目：从“动态提示”切入，讲如何根据检索结果调整提示（如置信度阈值），并展示A/B测试结果（如ROUGE-L提升5%）。
- 如果你只做过传统NLP：用“特征工程”类比提示设计，讲如何将任务分解为子步骤（类似pipeline），并对比CoT与规则系统的优劣。
- 如果你是校招无项目：聚焦论文复现，如用OpenAI API复现CoT在GSM8K上的效果，并分析失败案例（如模型在长链推理中出错），展示迭代优化能力。
- “Chain-of-Thought Prompting Elicits Reasoning in Large Language Models” (Wei et al., 2022)
- “Lost in the Middle: How Language Models Use Long Contexts” (Liu et al., 2023)
- “Rethinking the Role of Demonstrations: What Makes In-Context Learning Work?” (Min et al., 2022)
- OpenAI Prompt Engineering Guide (官方文档)
- DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines (Khattab et al., 2023)