AI 原生开放教材

外观

从零构建 AI Agent（didilili）课时教程·中文原文 ↗原件 ↓仓库 ↗

2、Prompt、结构化输出与护栏 ​

Q2-1. System Message 和 User Message 应该怎么分工？ ​

System Message 负责放稳定约束，User Message 负责放动态任务。

System 里一般放角色、目标、边界、安全规则、输出格式要求、工具使用规范，这些内容应该尽量稳定、少改。User Message 放用户当次任务、输入数据、补充上下文和个性化要求。

这样拆分的好处是结构更清晰，便于版本管理，也更适合后续做模板化、灰度和评测。如果把所有内容都混在一段 prompt 里，后面排查效果波动会非常困难。

重要度：必刷（出现次数：1次） | 难度：基础

**考察点：**Prompt 分层设计能力。

对应章节：13 提示词与消息模板 §3、入参的消息类型；13 提示词与消息模板 §7、对话提示词模板（ChatPromptTemplate）

Q2-2. 结构化输出有哪些常见做法？各自的优缺点是什么？ ​

从 Model I/O 这条主线看，结构化输出大致可以分成“后处理解析”和“前约束结构化输出”两类。

  • 纯 Prompt 约束：直接要求模型按 JSON 返回。优点是最简单、起步快；缺点是模型多说一句话、少个逗号，程序就容易崩，稳定性最差。
  • Output Parser：比如 StrOutputParser、JsonOutputParser、PydanticOutputParser。它更接近“模型已经输出了，我再把结果转成程序可用的数据”，适合 prompt | model | parser 这条经典链路。
  • Structured Output：比如 with_structured_output(TypedDict / Pydantic / JSON Schema)。它更接近“在模型输出前就先把 schema 定好”，让模型按结构生成并自动解析，约束力更强。
  • Function Calling / Tool Calling：本质上也是结构化输出的一种，只不过目标更偏“生成调用意图和参数”，特别适合工具调用、外部接口编排和 Agent。

如果模型平台支持更严格的结构化输出能力，通常会优先采用只保证“返回合法 JSON”的模式，因为前者更接近“按 schema 生成”，后者很多时候只是“长得像 JSON”。

如果再往下细分：

  • TypedDict 适合字段固定、但不追求很强运行时校验的场景。
  • Pydantic 适合字段类型、范围、必填项比较严格的业务场景。
  • JSON Schema 更适合跨语言、跨系统共享结构协议。

工程上通常不会把“让模型输出 JSON”当成真正的生产方案，更稳的顺序通常是：

  1. 能用原生结构化输出就优先用。
  2. 需要强校验时优先用 Pydantic 一类 schema。
  3. 即使模型已经结构化输出，也要补业务校验、缺省值处理和失败重试。

归根结底，Prompt 只能“尽量要求它长成这样”，Parser 和 Structured Output 才是在帮你把模型输出真正接进程序系统。

重要度：高频（出现次数：1次） | 难度：中等

**考察点：**从“能输出 JSON”到“能稳定接系统”的工程意识。

对应章节：14 输出解析器 §1、输出解析器简介；14 输出解析器 §4、结构化输出

Q2-3. Prompt Injection 是什么？为什么 RAG / Agent 场景更要小心？ ​

Prompt Injection 本质上是：不可信输入试图改写系统指令、诱导模型越权，或者让 Agent 执行原本不该执行的动作。

它不只来自用户直接输入，也可能藏在网页、PDF、知识库文档、邮件甚至图片里。只要这些内容会被模型读到，就可能形成“间接注入”。所以在 RAG、浏览器 Agent、代码解释器这类会读外部内容的系统里，风险会明显更高。

通常会从五层做防护：

  • 指令分层：System 放稳定规则，User 和外部文档都视作不可信输入，不能和系统约束同权。
  • 内容隔离：检索片段、网页内容、用户上传文档只当“待分析材料”，不要默认它们能发新指令。
  • 工具权限：所有写操作、危险操作都走白名单、schema 校验和最小权限，不让模型拿裸能力。
  • 动作校验：关键输出做规则校验，关键动作做确认、审批或 HITL，不让一句恶意文本直接触发副作用。
  • 观测与兜底：记录注入样例、失败轨迹和异常调用，及时加入评测集和拦截规则。

这里有一句特别关键：RAG 不是安全层，知识库文档本身也可能带恶意指令。 只要把“检索到的内容”直接当成“可信提示词”，系统就很危险。

常见追问：

  • 如果文档里写着“忽略之前所有指令”，你会怎么处理？
  • 浏览器 Agent 怎么防网页里的隐藏提示词？
  • 为什么微调和对齐不能从根上解决 Prompt Injection？

重要度：高频（出现次数：1次） | 难度：中等

**考察点：**应用层安全意识，以及对直接注入、间接注入和工具越权风险的理解。

对应章节：13 提示词与消息模板 §1、Prompt 简介；17 Tools工具调用 §6、从课程案例走向真实项目

Q2-4. Prompt Engineering 中，如何系统优化提示词并把准确率做上去？ ​

通常不会把 Prompt 优化理解成“反复手改几句提示词”，而是把它当成一个小型工程闭环。真正想把准确率稳定做上去，核心不是玄学技巧，而是 任务拆解、样例驱动、评测回归和边界收敛。

比较稳的做法通常是：

  • 先定义任务边界：先说清楚什么叫答对，什么叫答错，哪些情况必须拒答或澄清。
  • 做输入分层：把稳定规则放 System，动态任务放 User，别把所有约束揉成一段长 prompt。
  • 先修大问题再修措辞：如果问题本质是缺知识、缺工具、缺流程，不要强行靠 Prompt 硬抬效果。
  • 用样例和反例：few-shot 示例、反例约束、输出格式示例，通常比抽象要求更稳定。
  • 做结构化约束：能用 schema、parser、structured output 的地方，不要只写“请返回 JSON”。
  • 建 badcase 集：把线上错例沉淀成固定评测集，每次改 Prompt 都跑回归，而不是靠体感判断“好像更准了”。
  • 做版本和灰度：Prompt、模型版本、温度、输出格式要求一起管理，避免改了一个点却查不清影响。

如果从更务实的面试表达出发，还需要补一句：所谓“准确率 > 95%”一定要绑定具体任务，比如分类、抽取、格式生成、客服问答，它不是一个通用承诺值。真正的工程目标应该是让某个具体任务在固定评测集上稳定达标，而不是追一个脱离场景的数字。

常见追问：

  • 如果 Prompt 怎么改都上不去，你怎么判断应该切到 RAG、Tool、Workflow 还是微调？
  • badcase 集应该怎么建，才能真的指导迭代？
  • 如果线上效果突然下降，你怎么判断是 Prompt 问题、模型版本问题，还是外部知识 / 工具链路问题？

重要度：高频（出现次数：1次） | 难度：中等

**考察点：**Prompt 优化方法论、评测闭环意识，以及是否知道 Prompt 不是万能修复工具。

对应章节：1-2 提示词工程基础 §2、提示词怎么写；14 输出解析器 §8、实际开发选择

Q2-5. Prompt 工程的边界是什么？为什么不能把一切问题都交给 Prompt？ ​

Prompt 更接近一种“任务表达和约束手段”，但它解决不了知识缺失、复杂状态管理和强执行需求。

比如资料太多时，仅靠 Prompt 塞上下文会出现成本高、噪声多、丢关键信息的问题，这时候应转向 RAG。多步骤复杂流程如果全靠 Prompt 硬编排，会变成不可维护的长指令，应该转 Workflow 或 LangGraph。需要稳定调用外部系统时，应该走 Tools / Function Calling，而不是让模型在文本里“假装调用了接口”。

所以工程上更合理的思路是：Prompt 负责表达规则，RAG 负责补知识，Tools 负责执行能力，Graph / Workflow 负责流程控制。

重要度：中频（出现次数：1次） | 难度：基础

**考察点：**是否理解 Prompt 不是万能药。

对应章节：1-2 提示词工程基础 §4、提示词工程的边界；13 提示词与消息模板 §1、Prompt 简介

Q2-6. 如何做 Prompt 版本管理与回归？ ​

如果 Prompt 已经进入生产环境，就不能再把它当成一段“临时改改的字符串”，而要把它当成配置资产或代码资产来管理。

通常会同时管理四样东西：

  • Prompt 模板本身：System、User 模板、few-shot 示例、输出格式要求。
  • 运行参数：模型名、模型版本、temperature、top_p、max_tokens。
  • 评测集：固定 golden questions、典型 badcase、失败样例。
  • 发布信息：模板版本号、发布时间、负责人、灰度范围、回滚版本。

更稳的做法通常是：

  1. Prompt 和代码一起版本化，或者放进配置中心统一管理。
  2. 每次改 Prompt 都跑固定回归集，不只看主观感觉。
  3. 记录模板 hash、模型版本和关键参数，避免“明明没改 Prompt，效果却变了”时查不清原因。
  4. 上线前做灰度和抽样人工复核，高风险链路保留快速回滚能力。

还有一个很容易被忽略的点：换底层模型后，旧 Prompt 不一定还能保持原效果。 所以很多时候回归的对象不是“这段 Prompt 对不对”，而是“Prompt 和当前模型组合起来还稳不稳”。

常见追问：

  • golden set 应该怎么构建？
  • 如果线上效果波动，你怎么判断是 Prompt 问题还是模型版本问题？
  • Prompt、模型、索引三者一起变更时，如何设计回滚策略？

重要度：中频（出现次数：1次） | 难度：中等

**考察点：**Prompt 工程化治理能力，而不是只会手改提示词。

对应章节：13 提示词与消息模板 §8、从文件加载提示词；1-2 提示词工程基础 §5、提示词工程的几个注意点