说明
底本为 Language Models Interview Handbook（© 2026 Lamhot Siagian, AI Engineering Insider）；个人学习整理，转载请注明出处，勿用于商业再发行。
第 10 章 提示、上下文学习与 LLM 编排
本章概述
提示常被介绍成一种写作练习；实务上它是概率系统的控制接口。好的提示结构化任务、降低歧义、约束输出，并帮助模型有效使用上下文。随着模型在上下文学习与指令遵循上变强，提示设计成了重要工程杠杆（Brown et al., 2020; Ouyang et al., 2022）。
本章把提示当作系统设计：好的提示不是孤立存在——它们与模式约束、工具调用、检索质量、记忆策略与评估相互作用。
Interview Anchor interview锚点
| 维度 | 内容 |
|---|---|
| interviewer真正想测的 | 是否把提示视为整个系统的界面设计，而不是孤立的「妙词」。 |
| 高质量回答套路 | 说明指令、示例、策略、工具与输出模式的角色，再连到可靠性与可维护性。 |
| 常见低分答法 | 把提示说成咒语。资深回答会谈提示版本管理、评估与失效模式控制。 |
INTERVIEW CHEATSHEET interview速记条
| 项 | 要点 |
|---|---|
| 要表达的亮点 | 提示是用约束、示例与工具上下文来塑造行为。 |
| 最佳举例 | 结构化输出任务通常在提示同时定义模式、边界与回退行为时明显变好。 |
| 可追问方向 | 提到上下文学习、工具使用与提示回归测试。 |
| 资深补充 | 把提示当作带版本与评估的生产配置。 |
| 切忌这样说 | 凭几次特殊case试跑就判断提示质量。 |
What Strong Candidates Sound Like
：「提示在被视为系统配置时最有效：显式策略、显式模式、可度量的示例与可重复的评估闭环。」
下面的示意图表明：好的提示其实是微型系统设计——指令、证据、工具与输出模式协同工作，而不是互不相关的碎片拼贴。
图 10.1：提示最好在系统策略、用户任务、检索上下文、工具与结构化输出之间做编排。
问答（Q81–Q90）
Q81. 在对话式 LLM 系统中，system、user 与 tool 消息各扮演什么角色？
答。System 消息设定治理行为、约束与输出期望。User 消息承载任务请求与新信息。Tool（或函数）结果提供外部证据或计算输出，供模型在下一步使用。
好的interview回答是：对话格式是一种接口protocol——这些角色帮助区分策略、意图与证据；清晰划分使应用更易推理、调试与安全。
Q82. 什么使提示「可靠地好」而不只是「冗长」？
答。好提示对任务、期望输出格式、决策边界与可用证据说得具体。它在消除歧义的同时，不会用无关文字淹没模型。更长≠更好；无关细节会稀释最重要的指令。
interview中要从控制而非文采解释提示质量：在真实变化下仍能稳定产出有用输出的提示，才是最强的。
Q83. 少样本（few-shot）提示在何时能实质性地帮助？
答。当模型需要从指令单独无法体现的局部约定中学习时，少样本有用：包括格式规则、细微标签边界、领域语气与边界案例决策。示例把任务锚在具体行为上。
关键是相关性而非数量。少数精选示例常胜过一大批同质化重复的示例。强候选人会说示例应覆盖边界情况，而不只简单正例。
Q84. 在产品情境中应如何看待思维链（chain-of-thought）提示？
答。有用原则是分解，而不必暴露冗长自由形式的「推理」。若任务受益于中间结构，可要求模型产出显式子结果、检查表或中间字段，而非单一未分化的最终答案。
生产中目标是可检查性与任务成功，而非最大冗长度。稳妥的interview回答是：分解可提升表现，但产品系统往往偏好简洁的结构化中间态，而非无限制的推理文本。
Q85. 如何为结构化输出做提示？
答。结构化输出提示在指明模式、清晰定义字段含义并在生成后校验时最有效。只要求「JSON」不够——模型需要知道允许字段、值类型、枚举选项，以及信息缺失时该怎么做。
interview中应提到两层控制：提示层约束与生成后校验。最佳系统假定格式仍可能失败，因而会解析、重试或修复，而不是盲目信任第一次响应。
Q86. 什么是工具或函数调用？为何重要？
答。工具调用让模型选择外部操作（如数据库查询、API 请求、计算器或工作流触发），而不是完全凭权重生成答案。这使 LLM 成为编排器-scheduler，能决定何时需要外部计算。
interview向强回答是：工具调用通过把确定性工作移出纯语言生成来提高可靠性。模型选择动作，专用系统执行动作。
Q87. 为何提示模板与版本管理在工程团队中重要？
答。一旦提示成为生产逻辑的一部分，就应作为带版本的资产管理，而不是藏在代码里的临时字符串。团队需要知道哪个提示产生了哪种行为、变更如何影响指标、以及性能回退时如何安全回滚。
强回答把提示管理与软件纪律联系起来：版本控制、评估门禁、实验追踪与可复现性。
Q88. 什么是提示注入？为何危险？
答。提示注入发生在不可信内容指示模型忽略或覆盖预期策略时。在 RAG 与使用工具的系统中这尤其危险——检索文档、网页或用户输入可能含有为操纵模型行为而构造的文本。
重要论点是架构层面的：单靠措辞无法解决提示注入。需要工具限制、信任边界、清理策略，以及把外部文本视为不可信数据而非特权指令的防护。
Q89. 如何评估提示变更是否真的更好？
答。在固定、有代表性的测试集上，用任务相关指标（如准确率、有据性、格式有效性、拒绝正确性或评审偏好）评估提示变更。临时抽查适合探索，但不足以做发布决策。
interview中强调对照比较：提示质量应像其它系统行为一样测试——基线、数据集、验收标准与回滚计划。
Q90. 何时提示不再够用，需要更强干预？
答。当任务需要领域适配、低延迟、严格一致性，或基座模型单靠指令反复无法内化的行为时，提示可能不够。此时可能需要更好的检索、更强约束、微调、专用工具，或更小的专用模型。
资深回答是：提示工程很强但不是无限的；它是若干控制面之一。成熟团队知道何时把问题上移到架构、数据或模型适配。