【LLM基础】5.prompt & context engineering

一、Prompt Engineering

---

一、 基础提示范式 (Foundational Prompting)

1. 零样本提示 (Zero-Shot Prompting)

• 原理：不提供任何示例，直接向大模型下达任务指令，依赖模型预训练阶段积累的知识进行零次学习回答。

• 完整 Prompt 示例：

  将以下句子翻译成法语，并提取其中的情感倾向（积极/消极/中立）：

  句子："我今天弄丢了钱包，但好心人把它交给了警察，真是太幸运了！"

• 模型回答示例：

  翻译：J'ai perdu mon portefeuille aujourd'hui, mais une personne de bon cœur l'a remis à la police, c'est vraiment très chanceux !

  情感倾向：积极

2. 少样本提示 (Few-Shot Prompting)

• 原理：在提示中提供少量的（通常1-5个）输入-输出示例。这利用了模型的"上下文学习"能力，让模型隐式地理解任务模式、输出格式或特定的分类标准。

• 完整 Prompt 示例：

  提取文本中的机场代码：

  文本："我明天从北京首都飞往上海虹桥。" -> 提取：PEK, SHA

  文本："航班从肯尼迪国际机场起飞，降落在洛杉矶。" -> 提取：JFK, LAX

  文本："下周二我要从广州白云机场出发去成都天府机场开会。" -> 提取：

• 模型回答示例：

  CAN, TFU

---

二、 线性思维与分解范式 (Linear & Decomposition Reasoning)

3. 思维链提示 (Chain-of-Thought Prompting, CoT)

• 原理：鼓励模型在输出最终答案前，显式地按步骤生成中间推理过程。这极大地减少了模型在算术、常识和符号推理任务中的"幻觉"。

• 完整 Prompt 示例：

  农场里有一些猪和鸡。如果一共有 22 个头和 72 条腿，请问猪和鸡各有多少只？请一步一步地进行推理。

• 模型回答示例：

  1. 假设这 22 个头全部是鸡，那么腿的总数应该是 22 * 2 = 44 条。

  2. 但实际有 72 条腿，比假设多出了 72 - 44 = 28 条腿。

  3. 每只猪比每只鸡多 2 条腿（4 - 2 = 2）。

  4. 多出的 28 条腿必然属于猪，所以猪的数量是 28 / 2 = 14 只。

  5. 鸡的数量则是总头数减去猪的数量：22 - 14 = 8 只。

     结论：有 14 只猪，8 只鸡。

4. 由简到繁提示 (Least-to-Most Prompting)

• 原理 ：CoT 的进阶版。当问题过于复杂时，单一的思维链也容易出错。该方法引导模型先将复杂问题拆解成一系列子问题，然后基于前一个子问题的答案去解决下一个子问题。

• 完整 Prompt 示例：

  问题：艾米一小时能折 15 个纸鹤，鲍勃一小时能折 10 个。他们需要折 100 个纸鹤来装饰教室。如果艾米先单独折了 2 小时，剩下的两人一起折，还需要多久才能完成？

  请先将这个问题拆分为几个子问题，然后依次解答。

• 模型回答示例：

  子问题 1： 艾米在前 2 小时内折了多少个纸鹤？

  解答：15个/小时 * 2小时 = 30个纸鹤。

  子问题 2： 还剩下多少个纸鹤需要折？

  解答：100 - 30 = 70个纸鹤。

  子问题 3： 两人一起折纸鹤的速度是多少？

  解答：15 + 10 = 25个/小时。

  子问题 4： 剩下的纸鹤需要两人合作多久才能完成？

  解答：70 / 25 = 2.8 小时。

  最终答案：还需要 2.8 小时才能完成。

---

三、 树状与网状高级推理范式 (Advanced Structured Reasoning)

5. 思维树提示 (Tree of Thoughts, ToT)

• 原理 ：突破了思维链的线性单向思考。它允许模型针对一个问题生成多个不同的推理分支（节点），然后自我评估每个分支的可行性（如打分或寻找死胡同），最后像搜索算法（广度优先/深度优先）一样选择最优路径。

• 完整 Prompt 示例：

  任务：用 2, 4, 6, 8 四个数字，通过加减乘除得出 24（每个数字必须且只能用一次）。

  请使用思维树（Tree of Thoughts）的方法：

  1. 生成 3 种不同的第一步组合尝试。
  2. 评估每种尝试是否有可能最终得出 24（可行、部分可行、不可行）。
  3. 放弃不可行的路径，继续展开可行的路径，直到得出最终答案。

• 模型回答示例：

  分支生成 (第一步组合)：

  • 路径 A：先计算 8 * 4 = 32。剩下数字：32, 6, 2。
  • 路径 B：先计算 6 + 4 = 10。剩下数字：10, 8, 2。
  • 路径 C：先计算 8 / 2 = 4。剩下数字：4, 6, 4。

  评估：

  • 路径 A (32, 6, 2)：32 - (6+2) = 24。非常可行！
  • 路径 B (10, 8, 2)：10 * 2 + 8 = 28，或者 10 + 8 + 2 = 20。较难得出 24。
  • 路径 C (4, 6, 4)：4 * 6 = 24，但还剩下 4，(46) (4/4) = 24！也可行！

  深入路径 A：

  步骤 1：8 * 4 = 32

  步骤 2：6 + 2 = 8

  步骤 3：32 - 8 = 24

  最终答案：(8 * 4) - (6 + 2) = 24。

6. 苏格拉底式提示 / 产婆术提示 (Maieutic Prompting / Socratic Prompting)

• 原理 ：通过自我提问与反驳来检验逻辑的稳健性。模型不仅给出解释，还会像苏格拉底一样对自己提出质疑（寻找逻辑漏洞或反例），然后再回应这些质疑，从而得出更加严谨、深刻的结论。

• 完整 Prompt 示例：

  请解释"为什么天空是蓝色的？"。

  在给出初步解释后，请使用苏格拉底式提问（自我质疑）：针对你的初步解释提出一个反面问题或潜在漏洞（例如关于紫光的问题），然后回答你自己的质疑，以完善你的最终解释。

• 模型回答示例：

  初步解释： 天空是蓝色的因为"瑞利散射"。太阳光包含七色光，其中蓝光波长较短，当阳光穿过大气层时，蓝光更容易被空气分子散射到四面八方，所以我们看到的天空是蓝色的。

  自我质疑（苏格拉底式提问）： 等等，如果波长越短越容易被散射，那么紫光的波长比蓝光还要短，为什么天空不是紫色的？

  回应质疑（完善解释）： 这是一个很好的问题。天空不是紫色的主要有两个原因：一是太阳光谱本身发出的蓝光强度远大于紫光；二是人类眼睛的视网膜上对不同颜色的感光细胞（视锥细胞）对蓝光非常敏感，而对紫光很不敏感。

  最终结论： 天空呈现蓝色，是物理学上的瑞利散射（短波长蓝光被剧烈散射）与人类生理学（人眼对蓝光更敏感且太阳本身辐射蓝光更多）共同作用的结果。

---

四、 其他必知的进阶范式 (Other Essential Paradigms)

7. 自洽性提示 (Self-Consistency)

• 原理：让模型通过不同的路径生成多次回答（例如解一道数学题用3种不同方法），然后选取出现频率最高的结果（多数表决），以此消除单次生成的随机误差。

8. 角色扮演与系统提示 (Role-Playing / Persona Prompting)

• 原理：为模型赋予一个具体的身份、立场或背景。这能显著改变输出的语气、使用的词汇，并能激活特定领域的专业知识网络。
• (例如：Prompt "你是一位苛刻的文学评论家，请点评这段散文...")

9. ReAct (Reasoning and Acting)

• 原理：将大模型变成 Agent 的核心技术。强制模型按照"思考（Thought） -> 行动调用工具（Action） -> 观察结果（Observation）"的循环运行，用于解决需要外部事实核查或执行任务的情况。

10. 提示链 (Prompt Chaining)

• 原理：把极其复杂的任务拆分成多个独立的 Prompt 串联执行。前一个模型的输出直接作为后一个模型的输入。（例如：步骤1写大纲 -> 步骤2根据大纲写草稿 -> 步骤3润色草稿）。

---

五、 全景适用场景总结表

技术名称 (Technique)	原理简述	适用场景
零样本提示 (Zero-Shot)	不给示例，直接下指令	基础问答、文本翻译、情感分析、日常闲聊等低复杂度任务。
少样本提示 (Few-Shot)	提供少量输入输出样例	需特定格式输出的代码生成、风格模仿、非结构化数据实体提取。
思维链 (CoT)	引导模型写出逐步推理过程	基础数学题、日常逻辑判断、符号推理、简单的因果分析。
由简到繁 (Least-to-Most)	将大问题拆分为连续子问题求解	复杂业务逻辑计算、长文本阅读理解、条件繁多的谜题。
思维树 (Tree of Thoughts)	探索多条路径，自我评估并搜索最优解	创造性写作规划、复杂的数学运算（如24点）、多方案战略制定。
苏格拉底提示 (Maieutic)	通过自我提出反问和回应来验证逻辑	哲学问题探讨、法庭辩论推演、科学概念深度解析、消除逻辑谬误。
自洽性 (Self-Consistency)	多次采样，采用多数表决得出结论	容易算错的数学问题、容错率低的决策建议。
ReAct范式	交替进行思考规划与外部工具调用	智能体开发（Agent）、需联网查实时数据、需调用计算器或API的任务。
角色扮演 (Role-Playing)	设定特定的身份或专家人设	专业咨询（医疗/法律）、游戏NPC设定、模拟特定人物语气的文案。
提示链 (Prompt Chaining)	多步工作流，前一步输出为后一步输入	长篇小说创作、复杂代码项目生成、大型文档摘要与信息清洗。

二、Context Engineering

• Prompt Engineering 关注的是**"怎么问"**（语法、指令格式、推理引导范式，如 CoT、ToT）。
• Context Engineering 关注的是**"给什么"以及"如何管理这些信息"**。它是一个系统工程，解决的是如何在一个有限的、昂贵的上下文窗口（Context Window）内，高效地组装、检索、更新、压缩和流转信息，以支撑复杂的 Agent 运行。

当跳出单次对话，开始构建具有"智能分析"能力或"多节点协作"能力的复杂应用时，你面对的就不再是如何写好一句话，而是如何设计一个动态的上下文流转架构。

---

一、 记忆管理范式 (Memory Management)

处理大模型"健忘"问题的核心，关注上下文中时间维度的信息留存。

• 短期记忆 (Short-term Memory / Session Context)：

  • 原理： 单次会话内的上下文滑动窗口。通常通过保留最近的 N 轮对话，或者计算 Token 数量来截断最早的对话。
  • 挑战： 简单的截断会导致早期重要指令或设定的丢失。

• 长期记忆 (Long-term Memory)：

  • 原理： 将用户的习惯、事实或历史事件持久化到外部存储（如向量数据库 Vector DB 或关系型数据库）。当相似场景触发时，再将这些记忆"唤醒"并注入当前上下文。
  • 补充技术 (Entity Memory / Knowledge Graph)： 单纯的向量检索容易丢失实体间的关联。现在更进阶的做法是利用知识图谱（如 GraphRAG 思路）来管理记忆，或者为特定实体（如"用户A"或"项目B"）维护一个不断更新的 JSON/KV 状态表。

二、 外部知识与能力注入 (External Context & Grounding)

大模型的知识截断是静态的，Context Engineering 需要动态地将世界知识和执行能力"喂"给模型。

• RAG (Retrieval-Augmented Generation)：

  • 核心： 将外部文档切块（Chunking）、向量化（Embedding），在生成前检索最相关的片段拼接进上下文。
  • 进阶演进： 现在的 RAG 远不止相似度检索。包括：查询重写（Query Rewriting） 优化检索词；重排（Reranking） 过滤无关上下文；以及图检索（GraphRAG） 以捕获跨文档的全局语义关联。

• 工具调用上下文 (Tool Use / Function Calling / Actions)：

  • 核心： 将 API 接口描述（如 OpenAPI schema）作为 Context 注入给模型。模型输出的不再是自然语言，而是结构化的 JSON 参数。
  • 管理难点： 当工具有几十个时，全部塞入上下文会导致"上下文污染"和 Token 浪费。需要引入工具路由（Tool Routing），即先让一个轻量级模型判断需要哪类工具，再将特定的工具描述注入上下文。

三、 动态状态与 Agent 协作管理 (Agentic State & Interaction)

在构建工作流或多 Agent 系统（如使用 LangGraph、AutoGen 等框架）时，上下文不再是线性的文本，而是**状态机（State Machine）**中的数据流。

• 多 Agent 上下文隔离与传递 (Multi-Agent Context Routing)：

  • 核心： 不同的 Agent（如"代码编写者"和"代码审查者"）不需要也不应该看到全局所有的上下文。Context Engineering 需要精准控制：共享上下文 （如目标、最终代码）和私有上下文（如各自的思考过程、草稿）。这通常通过图结构（Graph-based state）来维护每个节点的输入输出。

• 反思与自我纠错 (Reflection / Self-Correction)：

  • 核心： 运行过程中产生的"错误"或"异常反馈"也是一种极具价值的 Context。通过捕获报错信息或评估器的反馈，将其作为新的 Context 注入，强制模型基于历史教训重新生成（如 Reflexion 架构）。

四、 上下文优化与压缩 (Optimization & Compression)

解决"上下文爆炸（Context Explosion）"的核心技术。即使模型支持 1M Token 的长窗口，全量输入的计算成本（Attention 机制的二次方复杂度）和"迷失在中间（Lost in the Middle）"效应依然致命。

• 动态摘要 (Dynamic Summarization)：

  • 原理： 当对话或文档长度达到阈值时，触发一个后台模型将早期的详尽记录压缩为一段核心摘要（Summary），用摘要替换原文，从而释放窗口空间。

• 提示词压缩 (Prompt/Context Compression)：

  • 原理： 使用特定的算法或小型模型（如 LLMLingua），在不改变语义意图的前提下，剔除上下文中的停用词、冗余词或低信息量 Token，将庞大的 Context 物理压缩。

• KV Cache 优化 (系统层面的上下文工程)：

  • 原理： 偏向底层基建。为了避免多轮对话中前序 Context 的重复计算，利用 PagedAttention 或 Prompt Caching 技术，将经常复用的上下文（如系统设定、庞大的多轮历史）的键值对缓存在显存中，极大降低推理延迟。

---

Context Engineering 全景分类总结表

核心维度	关键技术/范式	解决的核心问题 / 适用场景
记忆管理 (Memory)	会话滑动窗口、向量库持久化、知识图谱记忆、实体状态更新	解决模型"失忆"，实现个性化交互和长期任务跟踪。
外部注入 (Grounding)	高级 RAG (Rerank/GraphRAG)、Function Calling、工具路由	消除知识盲区，连接物理世界，执行自动化任务。
Agent协作 (Interaction)	状态图流转 (State Graph)、上下文隔离/共享、Reflexion (反思)	构建复杂的多步骤工作流、多角色辩论与协同开发。
优化压缩 (Optimization)	动态摘要替换、Token 级别物理压缩、Prompt Caching	解决上下文爆炸、降低 Token 成本、缓解"迷失在中间"效应。
指令设计 (Prompting)	CoT、ToT、少样本学习、角色设定 (Prompt Eng 属于此层)	规范单次输出的格式、逻辑和质量。

在这个体系下：Prompt Engineering 决定了单次计算的下限 ，而 Context Engineering 决定了整个 AI 系统架构的上限。

三、面试问答模拟

面试官提问1： "在构建复杂的多 Agent 协作系统（类似基于图结构的工作流框架）时，如果所有 Agent 共享全局上下文，很快会导致 Token 爆炸和'上下文污染'。你如何设计一套优雅的 Context Engineering 方案，来管理多个 Agent 之间的状态同步与上下文隔离？"

高分回答要点：

• 核心思路： 引入"状态图（State Graph）"和"读写权限隔离"，将 Context 从静态文本升级为结构化状态机。

• 具体方案：

  1. 全局共享状态与私有状态分离： 设计一个类似 Redux 的全局 State 对象（如 JSON 格式），只存放各 Agent 的最终输出结论或执行状态（如 current_step, final_code, error_log）。每个 Agent 拥有自己独立的、临时的 Scratchpad（草稿本/私有上下文），用于存放其内部的 CoT（思维链）或 ReAct 推理过程。
  2. 基于边（Edge）的上下文过滤： 在 Agent 节点之间流转时，通过定义图的边来执行上下文清洗。比如，代码生成 Agent 将结果传给测试 Agent 时，不传递自己思考方案的过程，只传递纯净的代码块和接口文档。
  3. 动态摘要与 KV 状态更新： 引入"记忆压缩 Agent"。当多轮对话或 Agent 交互达到 Token 阈值时，自动触发摘要更新全局 State，而不是机械地拼接对话历史。

面试官提问2： "传统的基于向量相似度的 RAG 在回答'总结整个数据集'或'跨文档的全局视角'问题时表现很差。你会引入哪些 Context Engineering 策略来解决？另外，现在模型动辄支持 1M 的长上下文（Long Context），RAG 还有存在的必要吗？"

高分回答要点：

• 解决全局推理瓶颈： 引入**图检索（GraphRAG）**的概念。在数据预处理阶段，不仅做文本切块（Chunking），还通过 LLM 提取文档中的实体和关系，构建知识图谱。检索时，基于社区发现算法（Community Detection）提取子图，将结构化的图谱关系作为上下文注入，赋予模型宏观的语义连接能力。

• 长窗口时代 RAG 的必要性（Trade-off 分析）：

  1. 成本与延迟（Latency/Cost）： 1M Token 的全量输入意味着极高的计算成本和首字响应延迟（TTFT）。RAG 通过精准检索，能以更少的 Token 解决问题。
  2. 注意力稀释与幻觉（Lost in the Middle）： 即使窗口很长，模型对中间信息的关注度依然会下降（U型注意力曲线）。RAG 提供的浓缩 Context 可以提高信息密度，降低幻觉。
  3. 动态数据更新： 业务数据是实时变动的，将数据库的变动作为 RAG 的检索源，比每次把整个新数据库塞入长窗口或重新微调模型要高效得多。

面试官提问3： "你提到长文本会有'Lost in the Middle'现象。从大模型底层的注意力机制来看，为什么会出现这种现象？在 Context Engineering 中，除了把重要信息放两端，还能结合 KV Cache 或其他机制做哪些优化？"

高分回答要点：

• 底层原理解释： 这种现象源于 Transformer 的自注意力机制（Self-Attention）在长序列下的分散。模型在预训练时，大部分语料的强相关信息通常集中在开头（如文章主旨）或结尾（如总结），导致注意力权重分布在两端形成先验偏好；同时，随着序列变长，Attention 矩阵的计算复杂度呈 O(N\^2) 增长，大量的噪音 Token 会稀释对中间关键 Token 的注意力权重。

• 深度优化策略：

  1. Prompt Caching（提示缓存）： 对于需要高频调用的庞大上下文（如几万字的系统设定或 API 文档），利用底层推理引擎（如 vLLM）的 Prompt Caching 功能，将这部分 Context 的 KV Cache 固定在显存中。这不仅加速了推理，也保证了模型对这部分前置指令的"绝对记忆"。
  2. 结构化强引导（GQA 视角）： 在使用分组查询注意力（GQA）等架构的模型时，为了防止中间信息丢失，可以在 Context 内部插入高频的"锚点（Anchors）"或使用 XML 标签 <important>...</important> 强制隔离信息块，配合明确的提取指令，提升注意力聚焦。

面试官提问4： "在复杂的 Agent 应用或 Prompt 迭代中，很多生成任务是没有绝对标准答案的（Ground Truth）。你怎么系统性地评估你的 Context Engineering 或 Prompt 策略是否带来了真实的业务提升？"

高分回答要点：

• 核心思路： 摆脱单一的正则匹配，建立多维度的、自动化的"模型即评委（LLM-as-a-Judge）"体系。

• 具体方案：

  1. 多维度量化指标构建： 将模糊的"好坏"拆解为具体的维度，例如事实一致性（针对 RAG 幻觉）、逻辑连贯性、格式遵从度等。为每个维度编写专门的评估 Prompt。
  2. 引导式多方辩论评估（Guided Group Debate Evaluation）： 针对复杂主观题，采用多 Agent 辩论框架。引入不同的角色（如"苛刻的挑刺者"、"逻辑验证者"），让它们对待测模型的输出进行交叉验证和多轮辩论，最后由一个裁判 Agent 给出综合打分。这比单次 LLM 打分的方差更小、更稳定。
  3. AB 测试与对战模型（Elo Rating）： 在灰度环境中，将新老 Prompt/Context 策略生成的两个答案同时发给评估模型或人类标注员进行盲测比较，计算 Elo 积分来衡量迭代效果。

🧑‍💻 面试官提问5：

"看你简历里做过智能分析 Agent。假设你的系统里接了数据库查询工具，用户问了一个宏观问题，比如'分析一下去年各个大区的销售趋势'。Agent 写了段 SQL 怼到 MySQL 或者 GaussDB 里，好家伙，直接返回了 5 万行原始流水数据。你这数据全塞给 LLM，Token 直接超限报错，就算不报错，API 成本也炸了。你怎么在工程上优雅地解决这个问题？"

🏆 满分加分回答（展示系统级思维与 Agent 设计）：

"遇到这种数据量爆炸的情况，核心解决思路是**'计算下推'和'代码解释器（Code Interpreter）模式'**，绝不能把 LLM 当成数据处理引擎来用。

1. 计算下推 (Push-down Computation)： 在 Tool 的设计上，我会在 Prompt 里明确限制模型，如果是聚合类问题，必须 使用 SQL 的聚合函数（GROUP BY, SUM, AVG）在数据库层完成计算，而不是 SELECT * 拉回明细让大模型自己算。这是最高效的。

2. 多步 Agent 协同（代码沙箱兜底）： 如果查询的确实是大量明细数据（比如要做复杂的统计检验或画图），我会引入类似 LangGraph 的状态机机制。

   • Step 1: LLM 先生成 SQL 获取数据，但工具层拦截全量返回，只给 LLM 返回数据 Schema、总行数以及前 5 行 Sample。
   • Step 2: LLM 根据 Sample 认识到数据量很大，自主编写一段 Python 数据处理代码（比如用 pandas 进行数据清洗和聚合）。
   • Step 3: 系统在一个安全的 Docker Sandbox 中执行这段 Python 代码，最后只把执行结果的 Summary、核心指标或者图表路径返回给 LLM 生成最终回答。

3. 兜底截断机制： 在基础工程层面，我也会在请求数据库的工具侧加上强硬的 LIMIT 和大小校验（比如超过 100KB 直接截断），并抛出异常给 LLM，触发苏格拉底式的引导------让大模型反问用户：'数据量过大，请问您想具体看哪个大区或哪个时间段的数据？' 从而缩小查询范围。"

---

🧑‍💻 面试官提问6：

"现在业务方扔过来一份 300 页的财务年报 PDF，或者几十万字的业务需求文档。用户问'这份报告里，第三季度和第四季度的核心增长引擎分别是什么，有什么战略转变？'。传统的文本分块（Chunking）加向量检索（RAG），搜出来的全是碎片化的段落，模型根本看不见全貌，开始胡说八道。这个超长文档理解你怎么解？"

🏆 满分加分回答（展示对高级 RAG 和长文本策略的掌握）：

"传统的 Top-K 向量检索确实解决不了跨段落的宏观推理。在实际工程中，我会采用**'层级索引与摘要'结合'图检索（GraphRAG）'**的方案：

1. 构建全局与局部层级摘要 (Hierarchical Summarization)： 入库时，不能只做无脑的按长度 Chunk。我会利用大模型做离线的 Map-Reduce 预处理。先对每一页或每个小节进行总结（Map），再把小节摘要融合成章节摘要，最后生成全文摘要（Reduce）。在检索时，采用路由策略：碰到宏观问题，优先去检索和阅读'高层级摘要'，而不是去大海捞针。

2. 引入 GraphRAG 应对跨文档实体关联：

   我会利用大模型在离线阶段抽取出文档中的关键实体（比如业务线、产品、财务指标）和它们之间的关系，构建知识图谱。当用户问'战略转变'时，系统会遍历图谱中相关的社区（Community），生成包含全局视角的回答。这比纯文本检索具备更强的逻辑性。

3. 长文本模型的精准喂饭（Needle In A Haystack 优化）：

   如果非要把长文本塞进去（比如必须结合多处细节），我会使用支持长窗口的模型，并在 Prompt 结构上做优化。把最核心的用户指令和问题放在 Prompt 的最开头和最末尾，中间塞入长文档内容，以对抗模型的'中间迷失 (Lost in the Middle)'现象。"

---

🧑‍💻 面试官提问7：

"你的 Agent 跟用户聊了 20 轮了，上下文很长。系统一开始的 System Prompt 里明确写了'必须以严格的 JSON 格式输出，且不能包含任何解释性废话'。但聊到第 21 轮，模型突然放飞自我，给你输出了大段 Markdown 文本，直接导致你的下游业务代码解析 JSON 崩溃。这种长上下文里的关键指令遗忘，生产环境你怎么彻底根治？"

🏆 满分加分回答（展示防御性编程和状态管理经验）：

"这个问题极其常见，指望 LLM 在长上下文中始终记住几万 Token 前的约束是不现实的。在生产环境中，我通过动态上下文管理 和末端指令重申来解决：

1. 末端指令强注入 (Late Prompting / Appending)： 注意力机制天然对末尾的 Token 更敏感。无论历史对话有多长，我会在组装最后一次给模型的请求包时，将'输出格式要求'强行拼接在最后一条 User Message 的末尾。例如：用户输入: [当前问题]。\n\n系统约束：请务必只输出合法的JSON对象，不要输出任何其他内容。 这样能最大限度唤醒模型的格式注意力。

2. 滑动窗口与状态摘要 (Stateful Memory Management)：

   在框架层（如 Dify 或自己写的逻辑中），我不会把 20 轮对话原文原封不动地传进去。我会维护一个滑动窗口，比如只保留最近 5 轮的原声对话。对于更早的 15 轮对话，利用一个小模型在后台异步生成一份'历史摘要 (Summary)'或者提取成'用户画像标签'注入当前上下文。这样既保留了记忆，又大幅度缩减了干扰信息。

3. 防御性解析与自我纠错循环 (Self-Correction Fallback)：

   工程落地永远要做最坏的打算。即使做了上述操作，依然可能输出非 JSON。我会加一层结构化输出解析器（如 Pydantic Output Parser）。一旦 json.loads() 报错，我会立即触发一次静默的重试------把报错信息和刚才放飞自我的错误输出丢回给模型，Prompt 提示：'你的上一次输出不是合法 JSON，报错信息是 XX，请立即修正并重新输出 JSON'。通常一次重试就能完美纠正。"

---

总结一下应对大厂面试的诀窍：

遇到"超长/超大"的问题，不要一上来就说"我去微调模型"或者"我用最新的长上下文模型"。大厂看重的是你能不能通过拆解任务（把大问题化小）、优化工作流（引入代码沙箱/离线图谱预处理）、以及巧妙的 Prompt 组装策略 ，用最低的算力成本把事情搞定。头部公司的面试非常看重实战踩坑经验 和对技术选型背后的思考。回答时，一定要多用"在过去的实践中，我发现......"来拉高回答的含金量。