现代大语言模型交互的系统化方法论h1

1. 执行摘要：AI交互范式的认知重构h2

在人工智能技术飞速发展的当下，大语言模型（Large Language Models, LLMs）已经从实验室的理论探索走向了产业应用的中心舞台。这一转变不仅是计算能力的胜利，更是软件工程范式的根本性变革。我们正在经历从“显式编程”（Explicit Programming）到“概率引导”（Probabilistic Guidance）的跨越。在传统的软件开发中，工程师通过编写精确的代码逻辑来控制程序的行为；而在大语言模型的时代，自然语言成为了这一控制层的核心接口。 为了驾驭这种强大的概率计算引擎，两个关键的学科应运而生：提示词工程（Prompt Engineering）与上下文工程（Context Engineering）。尽管在许多非专业讨论中这两个概念常被混淆，但它们实际上代表了与模型交互的两个不同维度。提示词工程，以吴恩达（Andrew Ng）教授与OpenAI合作的经典课程为代表，关注的是“指令层”的优化——即如何通过精准的语言表达，引导模型在即时推理中输出高质量的结果。这是一种针对模型“短期记忆”与“推理能力”的微调艺术。相比之下，上下文工程则是“架构层”的设计——它关注的是模型在做出回答之前所处的“信息环境”。它涉及如何构建模型的记忆系统、如何从海量数据中检索最相关的信息、以及如何管理模型有限的注意力窗口（Context Window），以确保模型不仅“听得懂”指令，而且“看得到”正确的事实依据 1。 本报告旨在为专业开发者、AI架构师及研究人员提供一份详尽、深入且具有实操价值的“学习笔记”与技术综述。我们将系统性地拆解吴恩达教授关于提示词工程的核心教学内容，不仅复述其方法，更深入剖析其背后的原理；同时，我们将视野拓展至前沿的“上下文工程”领域，详细阐述“迷失在中间”（Lost in the Middle）现象、检索增强生成（RAG）的优化策略以及Anthropic最新的提示词缓存（Prompt Caching）技术。本报告将通过严谨的逻辑推演、丰富的代码实例以及深度的行业洞察，帮助读者建立起一套成熟的AI交互方法论。

2. 第一部分：提示词工程的基石——吴恩达课程体系深度复盘h2

吴恩达教授与OpenAI合作推出的《ChatGPT Prompt Engineering for Developers》课程，被业界公认为大模型交互领域的“入门圣经”。这门课程的核心价值不在于罗列各种花哨的“魔法咒语”，而在于确立了与LLM交互的工程化思维。其核心论点是：大语言模型并非是一个能够自动揣测人类意图的“读心者”，而是一个需要精确逻辑引导的“概率推理机”。要用好这个工具，必须遵循两大核心原则：清晰性（Clarity）与思考时间（Time to Think） 4。

2.1 核心原则一：编写清晰明确的指令（Write Clear and Specific Instructions）h3

在提示词工程中，“清晰”并不等同于“简短”。这是一个极其常见的误区。实际上，在许多复杂任务中，过短的提示词往往会导致歧义，迫使模型基于概率去猜测用户的意图，从而产生幻觉（Hallucination）或平庸的回答。清晰性意味着通过限制模型的解空间（Solution Space），使其输出收敛到用户期望的特定格式和内容上。

2.1.1 策略A：使用分隔符（Use Delimiters）构建语义边界h4

在构建实际应用程序时，提示词往往是由“系统指令”和“用户输入”拼接而成的。例如，通过API构建一个翻译助手，系统指令是“翻译以下文本”，而用户输入可能是任何内容。如果用户输入的内容本身包含了类似“忽略前面的指令”的恶意攻击（即提示词注入 Prompt Injection），模型就可能发生混乱。 分隔符的使用不仅仅是为了防止攻击，更是为了在认知层面帮助模型区分“指令”与“数据”。 技术实现： 常见的分隔符包括三重双引号 (""")、三重反引号 (```)、尖括号 (< >) 或 XML 标签 ()。 深度洞察： 对于像Claude 3.5 Sonnet或GPT-4这样经过微调的模型，XML标签（如 …）通常具有更好的表现。这是因为这些模型在训练数据中大量接触了结构化代码，XML标签能触发模型对文本结构的深层理解，从而更严格地遵守数据边界 5。 应用实例：

• 差的提示词： 总结这段话：{user_input}
• 好的提示词： 请总结被三重反引号包裹的文本。 {user_input}

2.1.2 策略B：要求结构化输出（Structured Output）h4

在软件工程中，对接LLM的最大挑战之一是解析其输出。自然语言是多变的，而代码需要确定的数据结构。因此，明确要求模型输出JSON、HTML或XML格式，是将LLM从“聊天机器人”转化为“API后端”的关键步骤。 机制解析： 当我们在提示词中明确要求 Provide the output in JSON format with keys: ‘sentiment’, ‘keywords’ 时，我们实际上是在利用模型的“代码生成能力”来约束其“文本生成能力”。模型会调用其内部关于JSON语法的知识，确保生成的文本符合严格的语法规则（如闭合括号、转义字符等）。这大大降低了下游应用程序解析数据的正则表达式（Regex）复杂度 5。

2.1.3 策略C：条件性执行（Check Conditions）h4

为了构建鲁棒的系统，提示词必须包含逻辑判断能力。我们不能假设输入数据总是符合预期的。如果任务是“提取文本中的地址”，通过添加条件判断——“如果文本中不包含地址，请直接输出‘No address found’”——可以有效防止模型为了“讨好”用户而编造一个虚假地址。 工程意义： 这种策略通过引入“防御性编程”的思想，减少了边缘情况下的错误率。它教会模型在面对不确定性时选择“拒绝回答”而非“错误回答”，这在金融或医疗等高风险领域的应用中至关重要 5。

2.1.4 策略D：少样本提示（Few-Shot Prompting）h4

这是提示词工程中最强大的技术之一。与其用千言万语描述你想要的“风格”或“逻辑”，不如直接给模型看几个例子。 原理： LLM本质上是极其强大的模式匹配器（Pattern Matcher）。当我们在提示词中提供三个 {输入} -> {输出} 的样本时，模型会计算这些样本之间的隐含向量关系——包括语气、词汇选择、推理跳跃的幅度等——并将这种“风格向量”应用到新的输入上。 应用场景： 构建特定人格（如“苏格拉底式教学”或“爷爷讲故事的风格”）的聊天机器人时，少样本提示比纯粹的描述性指令（Zero-Shot）效果要好得多且更稳定 5。

2.2 核心原则二：给模型思考的时间（Give the Model Time to Think）h3

大语言模型的生成机制是逐词预测（Token-by-Token Prediction）。如果要求模型在生成第一个词的时候就给出一个复杂的结论（例如“判断这篇2000字的文章是否存在逻辑矛盾”），这实际上是在强迫模型在没有完整处理信息的情况下进行“直觉猜测”。给予思考时间，本质上是引导模型生成更多的“中间计算步骤”，从而利用更多的计算资源来得出最终答案。

2.2.1 策略A：指定完成任务的步骤（Specify Steps）h4

将一个复杂的任务拆解为线性的子任务序列。例如：“第一步：概括文本；第二步：将概括翻译成法语；第三步：提取法文摘要中的实体。” 深度解析： 这种链式指令（Chained Instruction）迫使模型在执行后续步骤时，可以“看到”前一步的结果。这实际上是扩展了模型的“工作记忆”。如果让模型直接输出结果，它必须在隐层状态中完成所有转换；而分步输出则将中间状态显式化（Explicit），让模型可以基于上一步的显式文本进行下一步的推理，极大地提高了准确性 5。

2.2.2 策略B：思维链（Chain of Thought）与自我验证h4

在教育场景中，如果我们问模型“学生的这个数学答案对吗？”，模型可能会因为看到学生写出的错误答案而产生“偏见”，顺着错误的思路判断其为正确。 吴恩达教授特别强调了一种修正策略：“在判断学生的答案之前，先自己解决这个问题。” 指令示例： “请先独立计算出这道题的正确答案，展示完整的计算过程。然后，将你的答案与学生的答案进行比对。在你自己算出答案之前，不要判断学生是否正确。” 成效： 这种强制模型“先做题再判卷”的逻辑，消除了模型顺从用户输入的倾向（Sycophancy Bias），确保了评估的客观性 5。

2.3 迭代式开发流程（Iterative Prompt Development）h3

吴恩达课程中一个极其重要的观点是：没有完美的提示词，只有不断迭代的提示词。 提示词工程不应被视为一次性的“写作”，而应被视为类似于软件开发的“编码-编译-调试”循环 4。

2.3.1 案例拆解：椅子说明书的营销文案生成h4

课程中使用了一个关于椅子的技术规格说明书作为案例，生动展示了迭代过程：

1. 初始尝试（Baseline）：

   • 提示词： “为这张椅子写一个营销描述。”
   • 结果： 模型输出了大段文字，包含了太多技术细节（如具体的螺丝型号），这对普通消费者来说过于枯燥。
   • 分析（Error Analysis）： 缺乏受众针对性，太长。

2. 第二次迭代（增加约束）：

   • 提示词： “为家具零售网站写一个营销描述，通过‘技术规格’来介绍椅子。描述应简短，不超过50个词。”
   • 结果： 长度得到了控制，但重点仍然有些偏差，不够吸引人。
   • 分析： 需要更聚焦于卖点。

3. 第三次迭代（聚焦特定角度）：

   • 提示词： “这款椅子是中世纪风格的。请针对注重室内设计的客户写描述。”
   • 结果： 文案风格变得更加优雅，突出了设计感。

4. 第四次迭代（结构化与多任务）：

   • 提示词： “写完描述后，请在最后提取椅子的尺寸，并以HTML表格的形式输出，表格要有边框。”
   • 结果： 模型不仅生成了完美的文案，还附带了可以直接嵌入网页的代码。

这一过程揭示了提示词工程的核心方法论：Idea（想法） -> Implementation（实现） -> Experimental Result（实验结果） -> Error Analysis（错误分析） -> Refinement（修正）。高级的提示词工程师会维护一个“测试集”（Test Set），在修改提示词后，同时在数十个样本上运行，以确保修改不会引入回归错误（Regression） 5。

2.4 LLM的四大核心能力支柱h3

吴恩达教授将LLM在应用开发中的能力归纳为四大类。理解这四类能力，有助于开发者识别哪些业务场景适合使用LLM。

• 提取 vs 摘要： “提取”保留原文片段，“摘要”重写内容。在做客户反馈分析时，“提取”往往比“摘要”更能保留真实情感色彩 4。 | | 推理 (Inferring) | 分类、情感分析、实体识别。 | - 零样本分类（Zero-shot Classification）： 无需训练模型即可判断情感（正面/负面）。
  \
• 统一提取（Unified Extraction）： 一个提示词同时完成情感判断、主题提取和品牌识别，并输出为JSON。这比多次API调用更省钱、更低延迟 4。 | | 转换 (Transforming) | 语言、格式、语气的转换。 | - 语调转换： 将“这东西坏了！”转换为“客户反馈产品存在功能异常”，用于工单系统。
  \
• 代码/格式转换： 将自然语言食谱转换为JSON格式，或将Python代码转换为Java代码。LLM不仅是翻译器，更是“转码器” 4。 | | 扩展 (Expanding) | 生成性写作、头脑风暴。 | - 温度参数（Temperature）： 在扩展任务中，调节 temperature 至关重要。低温度（0.0）适合事实性邮件回复；高温度（0.7+）适合创意写作。扩展是最容易产生幻觉的环节，需配合“Grounding”（基于事实）指令使用 4。 |

3. 第二部分：上下文工程——超越提示词的新疆界h2

如果说提示词工程解决的是“如何提问”的问题，那么**上下文工程（Context Engineering）**解决的则是“模型知道什么”的问题。随着AI应用从简单的聊天机器人向复杂的智能体（Agents）进化，开发者们发现，单纯优化提示词（指令）已经触到了天花板。限制模型表现的往往不是指令不够精妙，而是模型在进行推理时，缺乏准确、相关且即时的背景信息。

3.1 上下文工程的定义与范式转移h3

上下文工程是指对大语言模型的上下文窗口（Context Window）进行系统化设计、优化和管理的工程学科。它不关注模型本身的权重训练，而是关注如何构建一个动态的信息环境，使得模型在接收到用户指令的那一刻，能够访问到最关键的知识、记忆和工具定义 1。 范式对比： 提示词工程视角： “你是一个资深律师。请分析这份合同的风险。”（假设模型已经具备法律通用知识）。 上下文工程视角： 系统首先检索该用户过去签署的5份合同（历史记忆），检索当前最新的地方法律法规（外部知识），将这些信息清洗、排序，并构建一个包含“相关先例”的提示词前缀，然后再输入指令：“基于上述检索到的法规A和先例B，分析这份合同的风险。” 3。 上下文工程将LLM的输入函数从简单的 $f(prompt)$ 扩展为 $f(SystemInstruction + RetrievedKnowledge + ConversationHistory + Tools + UserQuery)$。如何高效地填充这个函数的参数，就是上下文工程的核心挑战 13。

3.2 关键技术挑战：“迷失在中间”（Lost in the Middle）现象h3

上下文工程并非只是简单地把所有相关文档“塞”进模型的上下文窗口。虽然现在的模型（如GPT-4-Turbo, Claude 3 Opus）支持128k甚至200k的上下文长度，但研究表明，模型对上下文的注意力分布是不均匀的。

斯坦福大学等机构的研究（Liu et al., 2023）揭示了一个被称为“迷失在中间”的现象：LLM在处理长文本时，呈现出一种U型注意力曲线（U-Shaped Performance Curve）。

• 首因效应（Primacy Bias）： 模型对位于上下文最前端的信息关注度最高。
• 近因效应（Recency Bias）： 模型对位于上下文最后端（即紧邻问题之前）的信息关注度也很高。
• 中间低谷： 被埋藏在长上下文中间位置的信息，其检索准确率和推理利用率会显著下降。

实例解析： 假设你构建了一个RAG系统，检索了10个相关文档。如果包含正确答案的文档被排在第5位（中间），模型回答正确的概率可能只有50%；而如果该文档被排在第1位或第10位，准确率可能飙升至90%以上 16。

工程解决方案：上下文重排序（Context Reordering） 为了应对这一现象，上下文工程师引入了重排序算法。在检索到相关文档后，不再简单地按照相关性分数（Relevance Score）从高到低排列（1, 2, 3, 4, 5…），而是采用一种“双向填充”策略，将高分文档放置在窗口的两端。

算法可视化： 将文档列表 （分数由高到低）重排为 。这样，最重要的文档1和2分别占据了开头和结尾的“黄金注意力位”。LangChain等框架已经内置了 LongContextReorder 转换器来实现这一逻辑 19。

3.3 检索增强生成（RAG）中的上下文架构优化h3

RAG是上下文工程最典型的应用场景。一个成熟的RAG系统绝不仅仅是“向量搜索+生成”，它包含了一系列复杂的上下文优化技术。

3.3.1 上下文检索（Contextual Retrieval）与分块策略h4

传统的RAG将文档切分为几百个词的片段（Chunks）进行向量化。这会导致上下文丢失。 问题： 一个片段可能只包含“它去年的收入是5亿美元”，但没有提到“它”是指“苹果公司”。当用户搜索“苹果公司收入”时，这个片段可能因为缺乏关键词而被漏掉。 Anthropic的解决方案： 在建立索引阶段，利用LLM对每一个片段进行预处理，为其添加上下文标题。片段被重写为：“[苹果公司2023财报] 它（苹果公司）去年的收入是5亿美元。” 这种**上下文嵌入（Contextual Embedding）**技术显著提高了检索的召回率（Recall） 22。

3.3.2 上下文压缩与过滤h4

当检索到的内容过多，超出了Token预算或可能引入噪音时，需要进行“后处理”。

• 重排序（Reranking）： 使用轻量级的Cross-Encoder模型对检索回来的文档进行二次打分，剔除虽然向量相似但语义不相关的文档。
• 摘要链： 对于长文档，先调用一个快速模型（如GPT-3.5-Turbo）生成摘要，再将摘要作为上下文输入给主力模型（如GPT-4）。这是一种“用计算换空间”的策略 23。

3.4 经济学突破：提示词缓存（Prompt Caching）h3

直到最近，上下文工程一直面临一个巨大的经济瓶颈：长上下文极其昂贵且缓慢。每次API调用都重复发送一本“员工手册”既浪费钱又增加延迟。2024年，Anthropic推出的**提示词缓存（Prompt Caching）**技术彻底改变了这一局面。 技术原理： 类似于CPU的L1/L2缓存或网页CDN。如果API识别到当前请求的“前缀部分”（Prefix）与之前的请求完全一致，它就无需重新计算这些Token的注意力矩阵，而是直接复用缓存的中间状态。 成本革命： 缓存的读取成本通常只有写入成本的10%。这意味着，如果我们把几百页的“法律法典”或“整个代码库”放在提示词的开头并缓存起来，后续针对该内容的提问（User Queries）将变得极快且便宜。 实施要点：

• 上下文工程师必须精心设计提示词的结构，以最大化缓存命中率（Cache Hit Rate）。
• 静态内容置顶： 系统指令、工具定义、大型背景文档必须放在提示词的最前面。
• 动态内容置底： 用户名、当前时间、具体问题等变化的内容必须放在最后。一旦提示词中间出现任何变化，缓存就会失效（Cache Invalidation），导致后续内容必须重新计算。

代码逻辑示例（伪代码）：

system_message = [
    {"text": "你是一个专业顾问...", "type": "text"},
    {"text": "<heavy_context>...这里是50万字的行业报告...</heavy_context>",
     "cache_control": {"type": "ephemeral"}} # 标记此处进行缓存
]

第一次调用：写入缓存（全价）h1

第二次调用（即使是不同用户）：只要前缀相同，直接读取缓存（1折价格，2倍速度）h1

25。

4. 第三部分：综合对比与未来展望h2

4.1 提示词工程 vs 上下文工程：对比分析h3

为了更清晰地界定这两个领域，我们通过以下维度进行对比：

2。

4.2 迈向智能体（Agentic）的未来h3

现代AI开发的趋势是智能体化。在一个复杂的Agent系统中，提示词往往是静态的（即“系统提示词” System Prompt），而上下文是高度动态的。 一个高级的AI工程师不再仅仅是在调试一句话的措辞，而是在构建一个自我管理的上下文系统： 元认知（Metacognition）： 模型首先观察自己的上下文，判断“我知道的信息够吗？” 工具调用（Tool Use）： 如果信息不够，模型生成一个查询指令（Prompt Engineering），调用搜索工具。 上下文更新（Context Update）： 搜索结果被回填到上下文中（Context Engineering）。 最终推理： 模型基于更新后的富上下文生成答案。 在这种架构下，吴恩达教授强调的“迭代开发”与“思维链”变成了Agent内部的自动循环，而“上下文工程”则构成了Agent的长期记忆与知识库。

5. 结论h2

本报告从吴恩达教授的基础课程出发，深入剖析了提示词工程的核心技法——清晰性、思考时间与迭代开发，这些是驾驭LLM的必修课。随后，我们将视野拓展至更宏大的上下文工程领域，揭示了在长文本时代，如何通过对抗“迷失在中间”效应、优化RAG架构以及利用缓存技术，来构建更快、更准、更经济的AI系统。

对于开发者而言，掌握提示词工程意味着你可以让模型**“听懂话”；而掌握上下文工程，则意味着你可以让模型“拥有知识”**。两者的结合，正是通往构建类人级智能应用的必经之路。

(注：本报告所有引用的技术点均基于提供的研究片段 4 及行业标准实践整理而成。)

引用的著作h2

1. Effective context engineering for AI agents \ Anthropic, 访问时间为 十二月 1, 2025， https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
2. Context Engineering: A Guide With Examples - DataCamp, 访问时间为 十二月 1, 2025， https://www.datacamp.com/blog/context-engineering
3. Beyond prompt engineering: the shift to context engineering | Nearform, 访问时间为 十二月 1, 2025， https://nearform.com/digital-community/beyond-prompt-engineering-the-shift-to-context-engineering/
4. ChatGPT Prompt Engineering for Developers - DeepLearning.AI, 访问时间为 十二月 1, 2025， https://www.deeplearning.ai/short-courses/chatgpt-prompt-engineering-for-developers/
5. ChatGPT Prompt Engineering for Developers: A Comprehensive Summary of Andrew NG’s Training Program — 1 | by Elif Canduz | Academy Team | Medium, 访问时间为 十二月 1, 2025， https://medium.com/academy-team/chatgpt-prompt-engineering-for-developers-a-comprehensive-summary-of-andrew-ngs-training-program-a4cb4ee4ea4a
6. Prompt engineering: The process, uses, techniques, applications and best practices, 访问时间为 十二月 1, 2025， https://www.leewayhertz.com/prompt-engineering/
7. OpenAI & Andrew Ng’s ChatGPT Prompt Engineering Course | Medium, 访问时间为 十二月 1, 2025， https://medium.com/@hizacharylee/openai-and-andrew-ngs-chatgpt-prompt-engineering-course-guidelines-and-summary-f2fef07b226f
8. Notes on ChatGPT Prompt Engineering Course - aaron’s notes, 访问时间为 十二月 1, 2025， https://aaronnotes.com/2023/04/notes-on-chatgpt-prompt-engineering-course/
9. ChatGPT Prompt Engineering for Developers - DeepLearning.AI, 访问时间为 十二月 1, 2025， https://learn.deeplearning.ai/courses/chatgpt-prompt-eng/lesson/so7ui/iterative
10. ksm26/chatGPT-Prompt-Engineering-for-Developers - GitHub, 访问时间为 十二月 1, 2025， https://github.com/ksm26/chatGPT-Prompt-Engineering-for-Developers
11. ChatGPT Prompt Engineering for Developers: A Comprehensive …, 访问时间为 十二月 1, 2025， https://medium.com/academy-team/chatgpt-prompt-engineering-for-developers-a-comprehensive-summary-of-andrew-ngs-training-program-74ab7e893a79
12. ChatGPT Prompt Engineering for Developers - DeepLearning.AI, 访问时间为 十二月 1, 2025， https://learn.deeplearning.ai/courses/chatgpt-prompt-eng/lesson/tyucw/inferring
13. Context Engineering vs Prompt Engineering | by Mehul Gupta | Data Science in Your Pocket, 访问时间为 十二月 1, 2025， https://medium.com/data-science-in-your-pocket/context-engineering-vs-prompt-engineering-379e9622e19d
14. CONTEXT ENGINEERING Explained With Examples, 访问时间为 十二月 1, 2025， https://www.youtube.com/watch?v=seU-C6lbuTA
15. Lost-in-the-Middle Effect | LLM Knowledge Base - Promptmetheus, 访问时间为 十二月 1, 2025， https://promptmetheus.com/resources/llm-knowledge-base/lost-in-the-middle-effect
16. [2307.03172] Lost in the Middle: How Language Models Use Long Contexts - arXiv, 访问时间为 十二月 1, 2025， https://arxiv.org/abs/2307.03172
17. Lost in the Middle: How Language Models Use Long Contexts - Stanford Computer Science, 访问时间为 十二月 1, 2025， https://cs.stanford.edu/~nfliu/papers/lost-in-the-middle.arxiv2023.pdf
18. langchain.document_transformers.long_context_reorder.LongContextReorder, 访问时间为 十二月 1, 2025， https://sj-langchain.readthedocs.io/en/latest/document_transformers/langchain.document_transformers.long_context_reorder.LongContextReorder.html
19. Lost in the Middle of long context and LangChain LongContextReorder - ClusteredBytes, 访问时间为 十二月 1, 2025， https://clusteredbytes.pages.dev/posts/2023/lost-in-the-middle-langchain/
20. Source code for langchain_community.document_transformers.long_context_reorder, 访问时间为 十二月 1, 2025， https://python.langchain.com/v0.2/api_reference/_modules/langchain_community/document_transformers/long_context_reorder.html
21. Contextual Retrieval in AI Systems - Anthropic, 访问时间为 十二月 1, 2025， https://www.anthropic.com/news/contextual-retrieval
22. How to Optimize RAG Context Windows for Smarter Retrieval | by Nishikant - Medium, 访问时间为 十二月 1, 2025， https://medium.com/@ai.nishikant/how-to-optimize-rag-context-windows-for-smarter-retrieval-b26859f03b2d
23. 6 Techniques You Should Know to Manage Context Lengths in LLM Apps - Reddit, 访问时间为 十二月 1, 2025， https://www.reddit.com/r/LLMDevs/comments/1mviv2a/6_techniques_you_should_know_to_manage_context/
24. Prompt caching - Claude Docs, 访问时间为 十二月 1, 2025， https://platform.claude.com/docs/en/build-with-claude/prompt-caching
25. Unlocking Efficiency: A Practical Guide to Claude Prompt Caching | by Mark Craddock, 访问时间为 十二月 1, 2025， https://medium.com/@mcraddock/unlocking-efficiency-a-practical-guide-to-claude-prompt-caching-3185805c0eef
26. claude-cookbooks/misc/prompt_caching.ipynb at main - GitHub, 访问时间为 十二月 1, 2025， https://github.com/anthropics/anthropic-cookbook/blob/main/misc/prompt_caching.ipynb