Java 工程师 AI 智能体学习路线 · 阶段 2：提示词工程（Prompt Engineering）详解

本阶段目标：掌握如何稳定地"指挥"模型产出期望结果，具备结构化输出能力，并理解从基础技巧到高级推理范式（ReAct、Plan-and-Solve 等）的提示词设计方法。

---

注：

博客：

https://blog.csdn.net/badao_liumang_qizhi

2.1 基础结构：三种消息角色

讲解
对话式模型把输入组织为不同"角色"的消息，模型据此理解各自的职责：

• System（系统消息）：设定模型的角色、规则、语气与全局约束，优先级最高，贯穿整个会话。
• User（用户消息）：真实用户的输入或当前任务。
• Assistant（助手消息）：模型的回复；在多轮对话中也可由开发者预填，用于引导或做 Few-shot 示例。

示例

System: 你是一名严谨的 Java 技术面试官，只回答与 Java 相关的问题，语气专业简洁。
User:   请说明 HashMap 和 ConcurrentHashMap 的区别。
Assistant:（模型生成）

常见场景

• 把"人设/规则"固定放在 System，避免每轮重复描述。
• 多轮对话中维护历史 User/Assistant 以保留上下文。

面试知识点

• Q：System 消息和 User 消息有什么优先级区别？
  A：System 用于设定全局角色与约束，通常权重更高、贯穿会话；User 是当前指令。当二者冲突时，不同模型处理策略略有差异，但一般 System 的"规则性约束"会被优先遵守。

---

2.2 基础技巧

2.2.1 角色设定（Role Prompting）

明确"你是谁"，让模型进入对应专业语境。

System: 你是一位有 10 年经验的 Spring Boot 架构师。

场景：客服、翻译、代码审查等都需要先定人设。

2.2.2 Zero-shot / Few-shot

• Zero-shot：直接给任务，不提供示例。
• Few-shot：在 Prompt 中给出若干"输入→输出"范例，引导模型按同样格式回答。

示例（Few-shot）

将用户评论分类为 正面/负面/中性：
评论：物流很快，包装也好。→ 正面
评论：客服态度差，退款慢。→ 负面
评论：东西一般，没什么特别。→ 中性
评论：手机续航不错，但发热明显。→ ？

场景：分类、抽取、格式转换等小样本任务，Few-shot 能显著提升准确率与一致性。

2.2.3 Chain-of-Thought（CoT，思维链）

要求模型"一步步思考"，把推理过程写出来，再给结论。

请逐步推理再给出答案：
问题：仓库有 120 件商品，每天卖出 15 件，几天卖完？
思考：120 ÷ 15 = 8 ...
答案：8 天

场景：数学、逻辑、多步推理任务。可加 “Let’s think step by step” 触发。

2.2.4 Self-Consistency（自一致性）

对同一个问题采样多个推理路径，取多数答案，提升复杂题准确率。
场景：关键决策、评测场景，用多次投票降低偶发错误。

面试知识点

• Q：Few-shot 比 Zero-shot 好在哪？会不会有副作用？
  A：Few-shot 通过示例显式约束输出格式与风格，小样本任务更稳；副作用是占用更多 Token、可能引入示例偏差（示例不具代表性会带偏模型）。
• Q：CoT 的代价是什么？
  A：输出更长（要把推理过程写出来），Token 成本与延迟上升；且推理模型已内化 CoT，普通模型才需显式提示。

---

2.3 结构化输出

讲解
让模型输出机器可解析的结构（如 JSON），是接入业务系统的关键。

3.1 JSON Mode

直接要求只输出 JSON，或调用支持 response_format: {type:"json_object"} 的接口。

System: 只输出 JSON，不要任何解释。
User:   提取：张三，电话 13800000000，城市 北京。
期望：{"name":"张三","phone":"13800000000","city":"北京"}

3.2 函数/ Schema 约束

通过 Function Calling 或 JSON Schema 约束字段名与类型，模型按 Schema 填值。

3.3 输出校验

拿到 JSON 后用代码校验（如 Jackson 反序列化、JSON Schema 校验），失败时重试或降级。

示例（Java 校验示意）

try {
    Result r = objectMapper.readValue(modelOutput, Result.class);
} catch (JsonProcessingException e) {
    // 重试或提示模型重新输出
}

常见场景

• 表单抽取、意图识别、工单结构化、API 参数生成。

面试知识点

• Q：模型输出 JSON 但格式偶尔非法，工程上怎么兜底？
  A：①开启 JSON Mode / 函数约束；②用代码做 Schema 校验，失败则重试（可带"上次错误"反馈）；③限制 max_tokens 防截断；④对关键字段做默认值与降级。

---

2.4 约束与防漏

讲解
通过明确指令约束模型行为边界，减少跑题、越权与幻觉。

• 拒答边界：明确"不在范围内的请求应拒绝"。

  你只处理 Java 技术问题；其他领域请回复"抱歉，我无法回答"。
  

• 格式强制：规定输出模板（如固定标题、分隔符）。

• 长度与语气控制：如"用不超过 50 字回答"“语气友好”。

常见场景

• 安全护栏：防止模型泄露 System Prompt 或被诱导越权。
• 产品化：统一回复风格，便于前端渲染。

面试知识点

• Q：如何防止用户通过"忽略以上指令"类提示注入（Prompt Injection）？
  A：①System 中强调优先级与安全边界；②对用户输入做隔离/标记（如明确界定"以下是用户内容"）；③输出端过滤敏感信息；④关键动作需人工确认；⑤用护栏模型/规则二次校验。

---

2.5 高级范式

2.5.1 ReAct（Reasoning + Acting）

让模型交替进行"思考（Thought）→ 行动（Action，调用工具）→ 观察（Observation）"，直到得出答案。

Thought: 我需要知道今天天气，应调用天气工具。
Action: get_weather(city="北京")
Observation: 晴，28℃
Thought: 已有信息，可回答。
Answer: 北京今天晴，28℃。

场景：需外部信息/工具才能完成的任务（智能体核心范式）。

2.5.2 Plan-and-Solve

先整体规划步骤，再逐步执行，适合复杂多步任务。
场景：写报告、数据分析流程编排。

2.5.3 Reflexion（自我反思）

任务失败后，模型反思错误原因并改进重试。
场景：代码生成调试、Agent 自我纠错。

2.5.4 Tree-of-Thought（ToT）

在多个推理分支中搜索/回溯，选最优路径。
场景：需要探索多种方案的创造性/规划问题。

面试知识点

• Q：ReAct 与普通 CoT 的区别？
  A：CoT 只在"想"，不接触外部世界；ReAct 在"想"的同时能"做"（调用工具、查数据），并基于观察继续推理，是 Agent 的基础范式。
• Q：Plan-and-Solve 相比 ReAct 适合什么场景？
  A：Plan-and-Solve 先全局规划再执行，适合步骤清晰、可预见的复杂任务；ReAct 边想边做，适合需要实时信息、路径不确定的任务。

---

2.6 评测意识

讲解
提示词并非"写一次就完"，需关注稳定性与可评测性：

• 一致性：同一 Prompt 多次调用结果是否稳定。
• 回归：Prompt 改动后，原有好用例是否仍正确。
• 数据集：维护一小批"输入→期望输出"用例做自动比对。

常见场景

• 提示词版本管理（Git），每次变更跑评测集。
• A/B 对比不同 Prompt 效果。

面试知识点

• Q：如何衡量一个 Prompt 改版是否"变好"了？
  A：建立评测集（覆盖典型/边界用例），用准确率、格式合规率、人工评分等指标在改版前后对比；避免仅凭单次主观感受判断。

---

2.7 阶段 2 自测清单

• 能写一个带角色设定与拒答边界的 System Prompt
• 能写出 Few-shot 示例提升分类准确率
• 能让模型稳定输出可解析的 JSON
• 能描述 ReAct 范式的基本流程
• 能设计最小评测集验证 Prompt 改动

---

2.8 阶段 2 面试题与参考答案

1. System、User、Assistant 三种消息角色分别起什么作用？

System 设定全局角色、规则与语气，贯穿会话、权重最高；User 是用户当前指令；Assistant 是模型回复，也可由开发者预填用于 Few-shot 示例或多轮上下文。

2. Few-shot 和 Zero-shot 的区别与适用场景？

Zero-shot 直接给任务；Few-shot 提供若干输入→输出范例引导格式与风格。小样本分类/抽取任务用 Few-shot 更稳；简单或通用任务用 Zero-shot 即可，且更省 Token。

3. 什么是 Chain-of-Thought？它有什么代价？

CoT 要求模型先逐步推理再给结论，提升多步推理准确率。代价是输出变长、Token 成本与延迟上升；推理模型已内化该过程，普通模型才需显式提示。

4. 如何让模型稳定输出结构化 JSON？

①开启 JSON Mode（response_format）；②用函数/JSON Schema 约束字段；③Prompt 明确"只输出 JSON"；④代码端做反序列化校验，失败重试；⑤限制 max_tokens 防截断。

5. 什么是 Prompt Injection？如何防范？

用户通过恶意指令（如"忽略以上系统指令"）诱导模型越权或泄露规则。防范：System 强调安全边界与优先级；隔离标记用户输入；输出端过滤敏感信息；关键动作人工确认；加护栏规则二次校验。

6. 什么是 ReAct 范式？它与普通 CoT 有何不同？

ReAct = 推理（Thought）+ 行动（Action，调工具）+ 观察（Observation）循环。CoT 只"想"不"做"；ReAct 能调用外部工具并基于观察继续推理，是 Agent 的核心范式。

7. Plan-and-Solve 与 ReAct 怎么选？

步骤可预见的复杂任务用 Plan-and-Solve（先规划再执行）；路径不确定、需实时信息的任务用 ReAct（边想边做）。

8. 如何处理模型 JSON 输出偶尔非法的情况？

开启 JSON Mode / Schema 约束；代码校验失败则带错误反馈重试；限制长度防截断；关键字段给默认值与降级策略。

9. 为什么提示词也需要"评测"？

同一 Prompt 多次结果可能不一致，改动后也可能劣化原有好用例。需维护评测集，用准确率/合规率/人工评分在版本间对比，保证稳定可回归。

10. 自一致性（Self-Consistency）是什么？适合什么场景？

对同一问题采样多条推理路径，取多数答案，降低偶发错误。适合关键决策、数学/逻辑评测等对正确性要求高的场景，但成本随采样次数线性上升。