Prompt Engineering：写好提示词的系统方法

Prompt Engineering（提示工程）是与大模型交互时最核心的技能。同样的模型，不同的 Prompt 可以导致天差地别的输出质量。Prompt 并不是玄学，它有明确的方法论和可复用的模式。

Prompt 的基本结构

一个好的 Prompt 通常包含以下几个要素：

图表加载中...

不是每个 Prompt 都需要包含所有要素，但要素越完整，模型的输出通常越准确。

角色设定（Role Prompting）

给模型指定一个明确的角色，能显著提升回答的专业度和针对性。

没有角色设定时：

请解释什么是 Kafka 的 ISR 机制。

有角色设定时：

你是一位有 8 年经验的大数据架构师，擅长 Kafka 集群的设计和运维。
请用通俗的语言解释什么是 Kafka 的 ISR 机制，并说明它在生产环境中的实际作用。

后者的回答会更贴近实战、更有深度，因为模型会"代入"这个角色，从资深工程师的视角来组织回答。

Few-shot 示例

Few-shot 是通过在 Prompt 中提供几个输入-输出示例，让模型学习到你期望的回答模式。这对于格式要求严格、或者任务定义模糊的场景特别有效。

请根据以下格式，为大数据面试题生成答案。

示例：
问题：HDFS 默认 Block 大小是多少？
答案：Hadoop 2.x 及以后版本中，HDFS 的 Block 大小默认为 128MB。
这个值远大于传统文件系统的 4KB 块大小，主要是为了减少 NameNode 的元数据压力，
降低寻址开销占比，充分利用磁盘顺序读取的高吞吐能力。
可以通过 hdfs-site.xml 中的 dfs.blocksize 参数调整。

问题：Kafka 中 Topic 和 Partition 的关系是什么？
答案：

模型看到示例后，会模仿示例的长度、深度、结构和语气来生成后续的答案。通常 2-3 个示例就足够。

Chain of Thought（思维链）

CoT 是让模型"一步一步思考"的技术。对于需要逻辑推理的问题，直接要求答案往往会出错，但如果引导模型展示推理过程，准确率会大幅提升。

图表加载中...

最简单的使用方式就是在 Prompt 末尾加一句"请一步一步思考"（Let's think step by step）。

更进阶的做法是明确指定推理的步骤框架：

分析这个 Spark 任务的性能瓶颈。请按以下步骤思考：
1. 先看 Shuffle 阶段的数据量和耗时
2. 分析是否存在数据倾斜
3. 检查序列化方式和内存配置
4. 给出具体的优化建议

结构化输出

当你需要模型输出 JSON、表格、YAML 等结构化格式时，必须在 Prompt 中明确指定格式要求，最好给出一个完整的格式示例。

请从以下招聘信息中提取关键字段，以 JSON 格式输出。

输出格式：
{
  "company": "公司名称",
  "position": "岗位名称",
  "salary_range": "薪资范围",
  "requirements": ["要求1", "要求2"],
  "location": "工作地点"
}

招聘信息：
字节跳动招聘大数据开发工程师，base 北京，薪资 30-50K，
要求熟悉 Spark/Flink，有数仓建设经验，3年以上工作经验。

常用 Prompt 技巧汇总

技巧	适用场景	核心做法
角色设定	需要专业/特定视角的回答	在开头定义角色身份和专长
Few-shot	格式要求严格、新任务定义	提供 2-3 个输入输出示例
CoT 思维链	数学推理、逻辑分析、复杂判断	要求模型展示推理步骤
分隔符	区分指令和待处理内容	用 --- 或 XML 标签分隔
负面约束	避免模型犯特定错误	明确说"不要做什么"
输出格式	需要结构化数据	给出完整的格式模板

Prompt 的调试方法

写 Prompt 和写代码一样，需要反复调试和迭代。几个实用的调试思路：

问题拆解：如果一个复杂 Prompt 效果不好，把它拆成多个简单 Prompt，分步执行。每一步都验证输出是否符合预期。

失败案例分析：收集模型输出不好的案例，分析失败原因——是指令不够明确？还是缺少示例？还是上下文信息不够？针对性地补充。

对比测试：修改 Prompt 的某一个要素，对比修改前后的输出差异。一次只改一个变量，才能准确定位哪个调整是有效的。

温度调节：对于需要确定性回答的任务（如信息提取、分类），把 temperature 调低（0-0.3）；对于需要创造性的任务（如写作、头脑风暴），调高（0.7-1.0）。