最近在尝试使用 Claude Opus 进行一些长文档分析和代码生成任务时发现了一个关键的限制其默认的上下文窗口Context Window被限制在了 20 万个 Token。对于需要处理超长技术文档、多轮复杂对话或大型代码库的开发者来说这个限制可能会成为工作流中的一个瓶颈。本文将深入探讨 Claude Opus 的上下文窗口限制解释其背后的技术原理并提供一套完整的实战方案帮助你理解、评估并有效应对这一限制从而最大化利用 Claude Opus 的能力。无论你是 AI 应用开发者、技术研究者还是希望将大模型集成到复杂业务中的工程师理解上下文窗口的运作机制和优化策略都至关重要。本文将涵盖从基础概念到高级技巧的完整内容包括如何计算 Token、如何设计提示词以适应有限窗口、以及如何通过工程化手段处理超长文本。读完本文你将能够清晰地规划你的 Claude Opus 使用策略避免因上下文溢出导致的对话中断或信息丢失。1. 背景与核心概念理解上下文窗口与 Token在深入探讨 Claude Opus 的限制之前我们首先需要明确几个核心概念。这些概念是理解所有大语言模型LLM工作方式的基础。1.1 什么是上下文窗口上下文窗口Context Window有时也称为上下文长度指的是一个大语言模型在一次处理中能够“看到”和“记住”的文本总量。你可以把它想象成模型的“短期工作记忆”。模型会根据这个窗口内的所有文本来生成下一个词或理解你的问题。例如如果你提供了一个 5000 字的文档并要求模型总结模型需要将这 5000 字全部纳入其上下文窗口进行处理。如果文档有 30 万字而模型的窗口只有 20 万 Token那么模型就无法一次性处理全部内容部分信息会被“遗忘”实际上是被截断。1.2 什么是 TokenToken 是模型处理文本的基本单位。它不等同于单词或汉字。在英文中一个单词可能被拆分成多个 Token例如“unfortunately” 可能被拆成 “un”, “fortunately”。在中文中一个汉字通常是一个 Token但词语也可能被拆分。为什么用 Token 而不是字数因为模型内部有一个词汇表Vocabulary它将文本映射成数字 IDToken ID。使用 Token 能更准确地衡量模型的计算负载。不同模型的 Token 化方式不同因此同样的文本在不同模型下的 Token 数量会有差异。如何估算 Token 数量一个常用的经验法则是英文1个Token ≈ 0.75个单词。1000个Token约等于750个英文单词。中文1个汉字 ≈ 1~2个Token取决于模型和分词方式。1000个Token约等于500-700个汉字。Claude Opus 采用的可能是类似于 Claude 系列自家的 Tokenizer。对于混合中英文的技术文档Token 数量会介于两者之间。1.3 Claude Opus 的 0.2M Token 限制意味着什么项目标题明确指出“Claude Opus 5 is limited to a 0.2M token context window by default”。0.2M即 200,00020万。by default这意味着是默认限制。可能存在通过特定方式如 API 参数、企业版扩展的可能性但标准访问模式下的硬性上限就是 20 万 Token。换算成实际文本纯英文大约相当于15 万单词200,000 * 0.75。这大概是一本 300 页书籍的文本量。纯中文大约相当于10-14 万汉字。这大概是一篇非常长的论文或一份中型软件项目的部分源代码。混合代码与文档一个中等规模的软件项目包含数万行代码和相应的文档很容易接近甚至超过这个限制。关键影响对话历史长度受限你与 Claude Opus 的整个对话历史包括你的所有提问和它的所有回答总 Token 数不能超过 20 万。一旦超过最早的历史信息会被丢弃。单次输入文件大小受限你无法一次性上传一个超过 20 万 Token 的文档让它分析。复杂任务链受阻需要多步推理、引用大量前文信息的复杂任务可能因上下文被截断而失败。2. 环境准备与评估量化你的需求在开始设计解决方案前你需要评估你的具体需求以确定 20 万 Token 的限制对你是否是问题。2.1 如何计算文本的 Token 数量虽然最准确的方式是使用模型对应的官方 Tokenizer 库但对于估算和规划我们可以使用一些近似方法和工具。方法一使用近似公式快速估算对于技术文档可以保守地使用以下公式总Token数 ≈ (英文字符数 / 4) (中文字符数 * 2)这是一个非常粗略的估算但适合快速判断。方法二使用 OpenAI 的 tiktoken 库推荐OpenAI 的tiktoken库速度快且易于使用。虽然它不是为 Claude 设计的但不同模型的 Token 数量级是相似的对于比较和估算极具参考价值。# 安装 tiktoken pip install tiktoken# 示例估算一段文本的 Token 数量 import tiktoken def num_tokens_from_string(string: str, encoding_name: str cl100k_base) - int: 返回使用给定编码的字符串中的Token数量。 # cl100k_base 是 GPT-4/Claude 3系列可能使用的编码适合估算。 # 注意Claude 的实际编码可能不同此处用于估算。 encoding tiktoken.get_encoding(encoding_name) num_tokens len(encoding.encode(string)) return num_tokens # 你的文本 text # 这是一个示例Python代码 def calculate_sum(numbers): \\\计算列表中所有数字的和。\\\ total 0 for num in numbers: total num return total if __name__ __main__: result calculate_sum([1, 2, 3, 4, 5]) print(fThe sum is: {result}) token_count num_tokens_from_string(text) print(f估算的Token数量: {token_count}) # 输出可能 around 110-130 个 Token方法三在线工具一些网站提供基于不同模型的 Token 计数器你可以粘贴文本进行估算。2.2 评估你的典型工作负载问自己几个问题我通常分析的文档有多大是单篇论文通常10万Token还是一整本书可能20万Token我的对话有多长是需要持续数十轮的技术讨论还是简单的问答我需要模型同时参考多少信息是需要它交叉引用多个文档还是只处理当前文件记录下这些场景并尝试用上述方法估算 Token 消耗。如果频繁超过 15 万 Token为输入和输出留出缓冲空间那么你就需要下文中的策略。3. 核心策略在有限上下文窗口内高效工作面对 20 万 Token 的限制我们不能蛮干需要采用精明的策略。核心思想是不是把所有信息都塞进去而是把最相关、最精华的信息塞进去。3.1 策略一提示词工程优化这是成本最低、效果最直接的优化方式。1. 精简输入删除无关内容在提交代码前删除所有注释、日志语句、空行和与当前任务无关的函数。只保留核心逻辑。使用摘要代替全文对于参考文档先用人脑或简单脚本提取关键章节、摘要和结论再将摘要输入模型。分段处理将长文档按章节、功能模块或页面分割分批提交给模型并指示模型进行“增量分析”或“总结上一部分后再结合下一部分”。示例糟糕的提示 vs 优化的提示// 糟糕的提示 “这是我的项目源码有50个文件。请帮我检查所有代码的安全漏洞。” 直接附上50个文件的压缩包或粘贴所有代码 // 优化的提示 “我正在进行代码安全审计。以下是我的UserService.java核心模块的代码它处理用户登录和权限验证。请重点关注 1. SQL注入风险特别是字符串拼接处。 2. 用户输入验证和过滤。 3. 敏感信息如密码的日志记录。 请先分析这个文件我会随后提供其他相关模块。 【仅粘贴 UserService.java 的核心代码省略getter/setter和大量注释】”2. 结构化指令减少冗余模型需要理解你的指令。模糊的指令会导致模型生成冗长的、试探性的回复浪费输出 Token。清晰的指令能让回复更精准、简洁。// 模糊指令 “告诉我这段代码是干嘛的有什么问题。” // 结构化指令 “请执行以下任务 1. 用一句话总结该函数的功能。 2. 列出函数中可能存在的三个性能瓶颈点。 3. 提供一个修复了瓶颈点的优化版本代码。 代码【代码片段】”3. 利用系统的“记忆”指令在对话开始时设定清晰的规则告诉模型如何保持简洁。“在本次对话中请你 - 用要点列表形式回答除非需要详细解释。 - 代码示例只展示关键改动部分省略样板代码。 - 当我提供后续信息时请关联之前的结论但不要重复它们。 我们现在开始。第一个问题是...”3.2 策略二外部记忆与检索增强当需要处理的信息远超 20 万 Token 时我们必须引入外部系统来充当模型的“长期记忆”。这是构建复杂 AI 应用的关键模式。核心架构检索增强生成Retrieval-Augmented Generation, RAG知识库存储将所有文档代码库、手册、会议记录拆分成小块Chunks进行向量化Embedding存入向量数据库如 Pinecone, Weaviate, Chroma, Milvus。用户提问当用户提出问题时将问题也向量化。检索相关块在向量数据库中搜索与问题向量最相似的文本块通常返回 top-k如 3-5 个。构建上下文将这些检索到的、最相关的文本块连同问题和系统指令一起组装成不超过 20 万 Token 的提示发送给 Claude Opus。生成回答Claude Opus 基于这个“浓缩的、相关的”上下文生成回答。# 一个简化的 RAG 流程概念示例 import requests # 假设我们有向量数据库客户端和嵌入模型 # from vector_db import search_similar_chunks # from embedding_model import get_embedding def ask_claude_with_rag(user_question, knowledge_base_id): # 1. 将用户问题转化为向量 # question_embedding get_embedding(user_question) # 2. 从向量数据库检索最相关的文本块 (伪代码) # relevant_chunks search_similar_chunks(question_embedding, knowledge_base_id, top_k5) # 模拟检索到的块 relevant_chunks [ 文档A第3节Spring Security通过Filter链实现认证。核心过滤器是UsernamePasswordAuthenticationFilter。, 代码文件UserController.java: 第45行PostMapping(\/login\) 方法调用 authenticationManager.authenticate()。, 配置说明在application.yml中security.basic.enabled需要设置为false以启用表单登录。 ] # 3. 构建给Claude的提示 prompt f 你是一个后端安全专家。请基于以下提供的相关上下文信息回答用户问题。 如果上下文信息不足以回答问题请如实说明。 【相关上下文】 {chr(10).join(relevant_chunks)} 【用户问题】 {user_question} 【你的回答】 # 4. 调用 Claude Opus API (伪代码) # 注意需要计算 prompt 的 Token 数确保不超过限制。 # response call_claude_api(prompt) # return response print(f构造的提示词前500字符:\n{prompt[:500]}...) # 返回模拟回答 return 根据上下文您的登录流程涉及UsernamePasswordAuthenticationFilter。建议检查...模拟回答 # 使用示例 answer ask_claude_with_rag(我的Spring Boot登录接口为什么返回403, project_spring_docs) print(answer)这种方法将模型的能力从“记忆”扩展到了“检索”使其能够处理理论上无限大的知识库。3.3 策略三对话管理与总结在多轮对话中上下文会不断增长。我们需要主动管理防止有用的早期信息被挤出窗口。1. 主动总结在对话进行到一定轮次或 Token 消耗达到阈值后可以主动要求模型对之前的对话历史进行总结。“我们已经讨论了关于微服务架构设计的五个要点。现在请你将我们之前讨论的核心结论浓缩成一个不超过300字的摘要。我将用这个摘要来继续我们的后续讨论。”然后你可以将这个摘要作为新对话的起点重置上下文从而释放大量 Token 空间。2. 关键信息重注入如果后续对话需要依赖前文某个非常重要的结论或数据不要指望模型还记得。你应该手动将那个关键信息复制到新的提问中。“之前我们得出结论数据库索引在‘user_id’和‘created_time’的联合索引上性能最佳。基于这个结论现在请为这个索引编写一个创建它的SQL语句并解释为什么这个顺序是好的。”4. 完整实战案例构建一个处理长代码库的问答助手让我们通过一个实战项目将上述策略整合起来。目标创建一个工具能够回答关于一个超过 20 万 Token 的本地 Python 项目代码库的问题。技术栈Pythonlangchain框架用于简化 RAG 流程chromadb轻量级向量数据库本地运行sentence-transformers生成文本向量anthropic官方 API假设用于调用 Claude Opus4.1 项目结构与环境准备创建项目目录并安装依赖。# 创建项目目录 mkdir claude_long_context_helper cd claude_long_context_helper # 创建虚拟环境可选但推荐 python -m venv venv source venv/bin/activate # Linux/Mac # venv\Scripts\activate # Windows # 安装核心依赖 pip install langchain langchain-community langchain-chroma sentence-transformers anthropic pypdf python-dotenv # pypdf 用于处理PDF按需安装。本例主要处理代码文本。创建项目文件结构claude_long_context_helper/ ├── .env # 存储API密钥 ├── main.py # 主程序入口 ├── knowledge_base/ # 存放原始文档/代码 ├── vector_store/ # ChromaDB持久化存储路径 ├── ingest.py # 知识库录入脚本 └── query.py # 问答脚本4.2 知识库录入文档加载、分割与向量化创建ingest.py负责读取你的代码库分割成块生成向量并存储。# ingest.py import os from pathlib import Path from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.document_loaders import TextLoader, PythonLoader from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_chroma import Chroma from dotenv import load_dotenv load_dotenv() # 加载 .env 文件中的环境变量 class CodeRepositoryLoader: 自定义代码仓库加载器遍历目录加载.py, .md, .txt文件 def __init__(self, repo_path): self.repo_path Path(repo_path) def load(self): documents [] allowed_extensions [.py, .md, .txt, .rst, .yml, .yaml, .json] for ext in allowed_extensions: for file_path in self.repo_path.rglob(f*{ext}): try: if ext .py: loader PythonLoader(str(file_path)) else: loader TextLoader(str(file_path), autodetect_encodingTrue) loaded_docs loader.load() # 为每个文档添加源文件路径元数据 for doc in loaded_docs: doc.metadata[source] str(file_path.relative_to(self.repo_path)) documents.extend(loaded_docs) print(f已加载: {file_path.relative_to(self.repo_path)}) except Exception as e: print(f加载文件 {file_path} 时出错: {e}) return documents def main(): # 1. 配置路径 repo_path ./knowledge_base # 把你的项目代码放在这个目录下 persist_directory ./vector_store # 2. 加载文档 print(开始加载代码库文档...) loader CodeRepositoryLoader(repo_path) raw_documents loader.load() print(f共加载 {len(raw_documents)} 个文档片段。) if not raw_documents: print(知识库目录为空请放入代码文件。) return # 3. 分割文本 # 代码文件适合用基于字符的分割并尽量保持函数/类的完整性 text_splitter RecursiveCharacterTextSplitter( chunk_size1000, # 每个块约1000字符 chunk_overlap200, # 块之间重叠200字符保持上下文连贯 separators[\n\n, \n, , ], # 分割符优先级 length_functionlen, ) print(正在分割文档...) documents text_splitter.split_documents(raw_documents) print(f分割后得到 {len(documents)} 个文本块。) # 4. 创建嵌入模型和向量库 # 使用开源模型生成向量无需调用API本地运行 embeddings HuggingFaceEmbeddings( model_nameall-MiniLM-L6-v2 # 轻量且效果不错的句子嵌入模型 ) # 5. 向量化并存储到ChromaDB print(正在生成向量并存入数据库...) vectordb Chroma.from_documents( documentsdocuments, embeddingembeddings, persist_directorypersist_directory ) vectordb.persist() # 持久化到磁盘 print(f向量数据库已创建并保存至 {persist_directory}) print(知识库录入完成) if __name__ __main__: main()运行此脚本前请将你的项目代码复制到knowledge_base/目录下。python ingest.py4.3 构建问答链检索与生成创建query.py处理用户问题检索相关上下文并调用 Claude Opus 生成答案。# query.py import os from langchain_chroma import Chroma from langchain_community.embeddings import HuggingFaceEmbeddings from langchain.prompts import PromptTemplate from langchain.schema.runnable import RunnablePassthrough from langchain.schema.output_parser import StrOutputParser from dotenv import load_dotenv import anthropic # 使用Anthropic官方SDK load_dotenv() class ClaudeOpusChat: def __init__(self, api_keyNone): self.api_key api_key or os.getenv(ANTHROPIC_API_KEY) if not self.api_key: raise ValueError(请设置 ANTHROPIC_API_KEY 环境变量或在 .env 文件中配置。) self.client anthropic.Anthropic(api_keyself.api_key) def ask(self, prompt, system_promptYou are a helpful AI assistant., max_tokens4000): 调用Claude Opus API try: message self.client.messages.create( modelclaude-3-opus-20240229, # 使用正确的模型名称 max_tokensmax_tokens, systemsystem_prompt, messages[{role: user, content: prompt}] ) return message.content[0].text except Exception as e: return f调用API时出错: {e} def format_docs(docs): 将检索到的文档格式化为字符串 return \n\n.join([f来源{doc.metadata.get(source, N/A)}\n内容{doc.page_content} for doc in docs]) def main(): # 0. 初始化Claude客户端 claude_client ClaudeOpusChat() # 1. 加载向量数据库 persist_directory ./vector_store embeddings HuggingFaceEmbeddings(model_nameall-MiniLM-L6-v2) vectordb Chroma(persist_directorypersist_directory, embedding_functionembeddings) # 2. 创建检索器 retriever vectordb.as_retriever(search_kwargs{k: 4}) # 检索最相关的4个片段 # 3. 定义提示模板 template 你是一个资深的代码专家和架构师。请严格根据以下提供的上下文信息来回答问题。 上下文信息来自项目的代码文件和文档。如果上下文信息不足以回答问题请如实说明“根据提供的上下文无法确定答案”不要编造信息。 上下文信息 {context} 问题 {question} 请给出专业、准确、简洁的回答 prompt PromptTemplate.from_template(template) # 4. 构建处理链检索 提示 生成 rag_chain ( {context: retriever | format_docs, question: RunnablePassthrough()} | prompt | claude_client.ask # 这里直接调用我们包装的Claude函数 ) # 5. 交互式问答循环 print( 代码库问答助手 ) print(已加载向量知识库。输入您关于代码库的问题输入 quit 退出。) while True: question input(\n您的问题: ).strip() if question.lower() in [quit, exit, q]: print(再见) break if not question: continue print(思考中...) try: # 检索相关文档 relevant_docs retriever.invoke(question) print(f[检索到 {len(relevant_docs)} 个相关片段]) # 构建最终提示 formatted_context format_docs(relevant_docs) final_prompt prompt.format(contextformatted_context, questionquestion) # 估算Token粗略使用tiktoken逻辑 import tiktoken enc tiktoken.get_encoding(cl100k_base) prompt_tokens len(enc.encode(final_prompt)) print(f提示词约 {prompt_tokens} Tokens (远低于20万限制)) # 调用Claude生成答案 answer claude_client.ask(final_prompt, system_promptYou are a precise and helpful coding assistant.) print(f\n助手回答:\n{answer}) except Exception as e: print(f处理过程中出错: {e}) if __name__ __main__: main()4.4 运行与验证准备环境变量在项目根目录创建.env文件填入你的 Anthropic API Key。ANTHROPIC_API_KEYyour_api_key_here放入知识库将你想要查询的代码项目复制到knowledge_base/目录下。构建向量库python ingest.py你会看到加载和分割文件的日志。启动问答助手python query.py进行提问 代码库问答助手 已加载向量知识库。输入您关于代码库的问题输入 quit 退出。 您的问题: 这个项目里处理用户认证的主要函数是哪个 思考中... [检索到 4 个相关片段] 提示词约 1200 Tokens (远低于20万限制) 助手回答: 根据提供的上下文用户认证的主要逻辑位于 auth/views.py 文件中的 login_user 函数。该函数接收用户名和密码调用 authenticate 方法并在成功后使用 django.contrib.auth.login 建立会话。此外middleware/auth_middleware.py 中的 AuthenticationMiddleware 负责在每个请求中验证并附加用户对象到 request.user。4.5 结果说明通过这个实战项目我们成功实现了一个能处理远超 20 万 Token 限制的代码库问答系统。其工作流程如下离线处理将整个代码库分割、向量化并存储这个过程不受 Token 限制。在线查询当用户提问时系统只检索最相关的几个代码片段总计可能只有几千 Token。智能生成将检索到的精华上下文远少于 20 万 Token与问题一起发送给 Claude Opus生成精准回答。这样我们既绕过了单次上下文窗口的限制又让模型能够基于整个代码库的知识进行回答。这就是 RAG 架构的核心价值。5. 常见问题与排查思路在使用 Claude Opus 或自建 RAG 系统时你可能会遇到以下问题问题现象可能原因排查思路与解决方案Claude 回复突然忘记对话开头的内容对话总长度历史当前输入输出超过了 20 万 Token 限制最早的历史被截断。1. 估算当前对话的 Token 消耗。2. 主动对前文进行总结并开启新对话。3. 在关键节点手动将重要结论重新粘贴到提问中。上传文件时提示“内容过长”单个文件或当前上下文总输入超过限制。1. 将大文件拆分成逻辑部分如按章节、按模块。2. 先本地用脚本提取关键信息如函数定义、API文档再提交。3. 使用 RAG 方案只上传索引不直接上传内容。RAG 系统返回的答案与文档无关或胡编乱造1. 检索到的文档块不相关。2. 提示词未强制要求模型基于上下文。3. 上下文仍然太长或嘈杂。1. 检查向量检索的相似度阈值调整k值检索数量。2. 强化提示词使用“严格根据以下上下文”等指令。3. 优化文本分割策略避免一个块包含过多无关信息。4. 在上下文中明确标出“如果上下文没有请说不知道”。Token 估算与实际消耗差异大使用的估算工具如 tiktoken与 Claude 的实际 Tokenizer 不同。1. 接受一定误差预留 10-20% 的缓冲空间。2. 如果通过 API 调用查看 API 返回的usage字段获取精确值。处理速度很慢1. 本地嵌入模型计算慢。2. 检索的块太多。3. Claude API 调用延迟。1. 考虑使用更快的嵌入模型如all-MiniLM-L6-v2已足够快。2. 减少k值如从 5 减到 3。3. 对回答长度设置合理的max_tokens。“sign-in could not be completed token exchange failed” 等错误这是网络热词中出现的认证错误与上下文 Token 无关。通常是 API 密钥、网络或区域问题。1. 检查ANTHROPIC_API_KEY环境变量是否正确设置且未过期。2. 确认 API 服务在你的区域可用。3. 检查网络连接和代理设置确保合法合规的网络访问。4. 查阅 Anthropic 官方状态页和文档。6. 最佳实践与工程建议为了在生产环境中稳定、高效地利用 Claude Opus 的上下文能力请遵循以下建议6.1 上下文窗口使用最佳实践预留输出空间记住20 万 Token 是输入和输出的总和。如果你输入了 19.5 万 Token模型可能只有 5000 Token 的空间来生成回答这可能导致回答被截断。一个安全的经验法则是输入不超过 18 万 Token为输出预留至少 2 万 Token 空间。优先放置重要信息模型对提示词开头和结尾的信息更敏感。将最重要的指令和背景放在提示词的开头将当前要解决的具体问题放在结尾。结构化输入使用清晰的标记如## 指令、## 背景、## 问题、## 代码来组织你的提示词帮助模型理解不同部分的意图。实施“上下文窗口预算”在开发多轮对话应用时设计一个简单的 Token 计数器当对话历史接近限制例如 18 万 Token时自动触发总结或清理旧消息的流程。6.2 RAG 系统优化建议分块策略是核心代码按函数、类或逻辑模块分块尽量保持完整性。可以使用 AST抽象语法树解析器进行更精准的分割。文档按章节、小节或段落分块保留标题信息作为元数据。重叠设置适当的块重叠如 10-20%确保上下文信息不会在边界处丢失。元数据增强检索在向量化时不仅存储文本块还存储元数据如文件名、章节标题、日期、类型。检索时可以结合关键词过滤如“只在 Python 文件中搜索”和向量相似度提高精度。重排序Re-ranking在向量检索返回 top-k 结果后可以使用一个更精细但更慢的模型或规则对结果进行重排序将最相关的结果排在最前面进一步提升上下文质量。缓存机制对于常见问题可以将问答对缓存起来直接返回缓存结果避免重复调用模型节省 Token 和成本。6.3 生产环境注意事项错误处理与降级API 调用可能失败。代码中必须有完善的异常处理如重试、回退到更小模型、返回友好错误信息。成本监控Claude Opus 是高性能模型调用成本较高。务必监控 Token 使用量特别是输入 Token因为输入通常很长。设置预算警报。数据安全与隐私如果处理的是公司内部代码或敏感文档确保 RAG 系统的向量数据库和整个处理流水线部署在安全的内网环境中。避免将敏感数据发送到不可控的外部 API。评估与迭代定期用一组标准问题测试你的 RAG 系统评估答案的准确性和相关性。根据结果调整分块大小、重叠度、检索数量k值和提示词模板。理解并有效管理上下文窗口限制是从简单使用 AI 模型到构建稳健 AI 应用的关键一步。Claude Opus 的 20 万 Token 默认限制是一个需要认真对待的边界但通过本文介绍的策略——从优化提示词到引入 RAG 架构——你可以将这个限制转化为设计高效、可扩展 AI 解决方案的契机。核心在于转变思维从“如何把更多东西塞进上下文”变为“如何让模型访问它需要的东西”。