Prompt Engineering to Context Engineering

落樱弥城2025-09-09 14:22

Prompt Engineering to Context Engineering

摘要 :

本文详细探讨了从 Prompt Engineering（提示工程） 到 Context Engineering（上下文工程） 的演进过程及其技术背景。Prompt Engineering 是早期大语言模型（LLM）应用的核心技能，通过精心设计输入指令引导模型生成特定输出。然而，随着应用场景的复杂化和模型能力的提升，Prompt Engineering 的局限性逐渐显现，包括对提示敏感、泛化能力不足、可维护性差等问题。这促使行业转向 Context Engineering，强调通过系统化的上下文管理、外部知识检索、多模态信息融合和长期记忆机制，构建更加稳健和可扩展的 LLM 应用。

文档分析了 Prompt 和 Context 的定义、区别及互补关系，并深入探讨了 Context Engineering 的核心技术框架，包括动态上下文拼接、检索增强（RAG）、上下文压缩与优化等策略。此外，文档还结合实际案例（如企业客服助手、GitHub Copilot、学术研究助手）展示了 Context Engineering 的价值。最后，文档展望了未来趋势，包括自动 Prompt 与 Context 的混合、多模态上下文整合、Agent 驱动的上下文自治以及可控性和可解释性的提升。
关键字: Prompt Engineering, Context Engineering, 大语言模型, 提示词工程, 上下文工程, 技术背景, 演进过程, 技术框架, 案例分析, 未来趋势

1. Prompt Engineering 的起源与演进

1.1 Prompt 的基本概念

在大语言模型（LLM, Large Language Models）中，Prompt（提示词）指的是开发人员或用户输入的一段自然语言文本，用来引导模型产生特定的输出。通俗来讲，Prompt 就像"提问的方式"，不同的问法会得到不同的回答。

在早期的 LLM 应用中，Prompt 的作用主要有以下几个方面：

  • 任务定义：告诉模型需要完成什么样的任务（例如：翻译、总结、代码生成）。
  • 格式约束：通过自然语言或示例，要求模型输出特定格式的内容。
  • 上下文注入：在 Prompt 中直接加入背景信息，帮助模型理解问题。

从实践角度来看，Prompt 是开发者与模型交互的最初入口，因此 Prompt Engineering（提示词工程）应运而生，成为早期 LLM 应用的核心技能。

参考文档：

1.2 Prompt Engineering 的典型方法

随着实践的深入，开发人员发现简单的指令往往不足以得到稳定可靠的输出，因此出现了多种 Prompt 工程化方法。

  • 模板化 Prompt ：通过固定的格式来组织输入，使模型输出更可预测。这种方法被广泛应用于商业系统中，因为它能减少模型对模糊输入的误解。
    示例：

    任务：将以下句子翻译为英文
    输入：{{中文句子}}
    输出：

  • 少样本提示（Few-shot Prompting） ：在 Prompt 中加入几个示例，让模型学习模式后再完成新任务。
    示例：

    翻译示例：
    中文：你好 → 英文：Hello
    中文：谢谢 → 英文：Thank you
    中文：再见 → 英文：

这种方法正是 GPT-3 论文中提出的 Few-shot 学习的核心。参考论文：Brown et al. (2020), https://arxiv.org/abs/2005.14165

  • 思维链提示（Chain-of-Thought） ：在 Prompt 中显式要求模型展示推理过程，而不是直接给出答案。
    例如在数学问题中，可以提示模型"请逐步推理并给出答案"。
    研究表明，这种方法能显著提升复杂推理任务的表现。

参考文档：Wei et al. (2022), Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, https://arxiv.org/abs/2201.11903

  • 自洽性采样（Self-Consistency）：结合 CoT，生成多个推理路径，最后通过投票选出最可能的答案，从而提升稳定性。

参考文档：Wang et al. (2022), Self-Consistency Improves Chain of Thought Reasoning in Language Models, https://arxiv.org/abs/2203.11171

1.3 Prompt Engineering 的瓶颈

尽管 Prompt Engineering 在 LLM 早期应用中发挥了重要作用，但其局限性也逐渐暴露：

  • 对提示敏感：模型输出往往依赖于 Prompt 的细节，小小的改动可能导致结果完全不同。这使得系统缺乏稳定性和可复现性。

  • 泛化能力不足：Prompt 工程化方法通常针对特定任务进行优化，但难以适应复杂的、多样化的应用场景。例如：一个在问答中表现良好的 Prompt，可能在代码生成中失效。

  • 可维护性差：随着系统规模增大，开发者需要维护大量不同任务的 Prompt，难以实现统一管理。尤其在企业级应用中，这种"提示堆叠"会变得越来越难以维护。

  • 扩展性有限：Prompt 依赖于模型的上下文长度，当任务涉及大量外部知识或长文档时，单靠 Prompt 无法满足需求。

这些问题催生了新的工程范式，即 Context Engineering ------ 通过更系统化、可扩展的上下文管理，来取代对单一 Prompt 的依赖。

2. 从 Prompt Engineering 到 Context Engineering 的转变

2.1 Context 的定义与扩展

在 LLM 领域中，Prompt 和 Context 常常被混用，但二者实际上有明显区别。

  • Prompt 更偏向"输入指令"，通常是开发者或用户直接编写的提示，用来驱动模型输出结果。
  • Context 则是一个更广义的概念，它不仅包括 Prompt，还包括与任务相关的各种辅助信息，例如历史对话记录、外部文档检索结果、数据库查询内容、API 调用信息等。

换句话说，Prompt 只是 Context 的一个子集。Context 更像是"信息场"，决定了模型能够在什么样的背景下理解问题和生成答案。随着模型能力的增强，开发人员逐渐从"如何写好一个 Prompt"转向"如何构建和优化 Context"。

参考文档：

2.2 转变的驱动因素

从 Prompt Engineering 到 Context Engineering 的转变，并非偶然，而是由多个技术发展趋势推动的。

  • 模型能力的提升：早期的 LLM（如 GPT-2）在理解复杂指令方面有限，Prompt 的精心设计至关重要。但随着 GPT-3、GPT-4 以及 LLaMA 等模型出现，模型在推理、理解和生成方面的能力大幅增强，使得单纯依赖 Prompt 已不足以发挥潜力，必须通过更全面的 Context 管理来组织知识。

参考文档：Brown et al. (2020), Language Models are Few-Shot Learners, https://arxiv.org/abs/2005.14165

  • 长上下文窗口的发展：新一代模型逐渐支持更长的输入窗口，例如 Anthropic Claude-2 支持 100K token，上下文信息量远超早期模型。这意味着开发者不仅能写 Prompt，还能把海量背景知识直接注入模型，从而推动 Context Engineering 的兴起。

参考文档：Anthropic Claude Model Card (2023), https://www.anthropic.com/index/claude

  • 多模态输入的出现：随着 OpenAI GPT-4V、Google Gemini 等多模态模型的推出，输入不再局限于文本，还可以包括图像、代码、表格甚至音频。这类输入无法通过传统 Prompt 轻易表达，而是需要构建跨模态的上下文，推动 Context Engineering 的扩展。

参考文档：OpenAI (2023), GPT-4 Technical Report, https://arxiv.org/abs/2303.08774

2.3 Context Engineering 的核心目标

Context Engineering 注重"如何写好提示"，而 Context Engineering 更关注"如何构建和管理信息场"，其核心目标包括：

  • 降低人工设计成本：Prompt 往往需要反复试错才能找到最佳方案，而 Context Engineering 倾向于通过自动化方法（如检索增强、上下文拼接）来减少人工干预。

  • 提升系统稳定性和鲁棒性：依赖单一 Prompt，容易因措辞不同而导致结果波动。Context Engineering 通过引入结构化知识和外部记忆，使系统输出更稳定。

  • 面向复杂任务的自动化：随着应用复杂度增加，单一 Prompt 无法支撑。例如在企业知识库问答中，需要动态检索文档、选择合适上下文并组合，这正是 Context Engineering 的目标。

参考文档：Lewis et al. (2020), Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, https://arxiv.org/abs/2005.11401

3. Context Engineering 的技术框架

3.1 上下文构建策略

Context Engineering 的核心任务是如何为大模型构建一个合适的"信息场"，让模型能够更准确、更高效地完成任务。常见的构建策略包括：

  • 动态上下文拼接：在对话或任务执行中，根据用户请求动态拼接上下文信息，例如用户历史对话、任务描述和外部知识。这种方式适合于多轮对话和个性化助手。

参考：OpenAI Function Calling 文档 (2023), https://platform.openai.com/docs/guides/function-calling

  • 检索增强 (RAG, Retrieval-Augmented Generation) ：

    通过检索系统（如向量数据库）找到相关文档，再将这些文档作为上下文输入模型。这种方式解决了模型参数内知识不足的问题，广泛应用于企业知识库问答、文档助手。

    参考：Lewis et al. (2020), Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, https://arxiv.org/abs/2005.11401

  • 内存管理与长期记忆 ：

    LLM 本身缺乏持久记忆能力，Context Engineering 可以通过显式的"记忆模块"来保存历史交互信息，并在需要时选择性注入上下文。这种方法常用于 Agent 系统。

    参考：Xu et al. (2023), MemoryBank: Enhancing Large Language Models with Long-Term Memory, https://arxiv.org/abs/2305.10250

3.2 上下文优化方法

由于上下文窗口有限，Context Engineering 不仅需要构建信息，还需要优化输入，确保最有用的信息被保留。

  • 上下文压缩 (Context Compression) ：

    通过抽取摘要、提取关键点、知识图谱化等方式，对长文本进行压缩后再输入模型，从而减少 token 消耗。

    参考：Zhang et al. (2023), Extract, then Distill: Efficient and Effective Context Compression for LLMs, https://arxiv.org/abs/2305.10601

  • 知识蒸馏与缓存 (Cache/Distillation) ：

    对于常见任务或固定知识，可以通过缓存模型的输出，或蒸馏成轻量化模型，从而减少上下文依赖。例如：FAQ 问答系统不必每次都检索整个数据库，而是可以直接使用缓存结果。

  • 语义聚合与重排序 ：

    当检索得到的候选上下文过多时，可以基于语义相似度或任务相关性进行重排序，只选择最相关的信息作为输入。这种方法可显著提升模型输出质量。

    参考：Gao et al. (2021), Condenser: a Pre-training Architecture for Dense Retrieval, https://arxiv.org/abs/2104.08253

3.3 多源上下文整合

在实际应用中，Context 不仅仅来自单一文本源，而是往往需要整合多种信息。

  • 跨模态整合：将文本、代码、图像、表格等信息整合进同一个上下文。例如，医学诊断助手需要结合病历（文本）、影像数据（图像）和实验结果（数值）。

参考：OpenAI (2023), GPT-4 Technical Report, https://arxiv.org/abs/2303.08774

  • 结构化数据与非结构化数据结合：除了自然语言文本，还可能需要整合数据库查询结果、API 输出等结构化数据。这类数据需要格式化后注入上下文，使模型能够综合利用。

  • Agent 协调机制中的上下文共享：在多 Agent 系统中，不同 Agent 需要共享上下文信息。例如，一个"规划 Agent"负责任务拆解，另一个"执行 Agent"负责代码编写，两者之间必须交换上下文才能协作。

参考：Park et al. (2023), Generative Agents: Interactive Simulacra of Human Behavior, https://arxiv.org/abs/2304.03442

4. Context Engineering 的实现路径与案例

4.1 典型应用场景

Context Engineering 并非抽象的概念，而是在各种实际应用中发挥关键作用。以下列举几个典型场景：

  • 智能助理与多轮对话 ：在对话系统中，用户的提问往往依赖于历史上下文。例如：

    用户问"帮我订一张去东京的机票"，下一句说"顺便安排酒店"。如果没有上下文管理，模型无法理解"酒店"与东京相关。

    Context Engineering 可以通过记忆模块保存对话历史，并动态拼接上下文，从而保证语义连贯。

  • 企业知识库问答：在企业中，员工需要查询内部文档、产品手册或政策。由于文档量庞大，模型参数中不可能存储所有知识。通过检索增强 (RAG)，系统可以实时获取相关文档并作为上下文传递给模型，从而提供精准回答。

  • 自动化代码生成与调试：开发者要求模型"为某个项目生成单元测试"，模型必须理解项目的现有代码和接口定义。这需要将代码片段、函数签名等作为上下文输入模型。没有 Context Engineering，模型只能"盲写"，难以生成可用代码。

  • 复杂决策系统：在医疗诊断、法律咨询或金融分析等场景中，模型需要结合多模态信息（文本、数值、表格）并进行推理。Context Engineering 通过上下文融合和优化，使得 LLM 能够整合不同数据源，辅助人类做出复杂决策。

4.2 代表性技术实现

在业界和学术界，已经出现了多种实现 Context Engineering 的框架和工具。

  • OpenAI 的 Function Calling 与 Memory

    OpenAI 提供的 Function Calling API 允许模型在生成过程中调用外部函数，并把函数返回结果作为上下文继续对话。这是一种"动态上下文注入"方式，适合工具调用和任务执行。

    另外，OpenAI 正在逐步开放 Memory 功能，能够让模型记住用户偏好和历史交互。

    参考：OpenAI Function Calling 文档 (2023), https://platform.openai.com/docs/guides/function-calling

  • LangChain 的上下文管理

    LangChain 是一个开源框架，专门用于构建基于 LLM 的应用。它提供了检索增强 (RAG)、对话记忆、Agent 框架等模块，能够帮助开发者快速实现 Context Engineering。

    参考：LangChain 文档, https://docs.langchain.com

  • 向量数据库与 LLM 的结合

    向量数据库（如 Pinecone、Weaviate、Milvus）广泛用于存储和检索高维向量表示。当用户提问时，系统会将问题转化为向量并检索相似文档，再将其拼接为上下文输入模型。这是目前知识型问答系统的主流实现路径。

    参考：Milvus 官方文档, https://milvus.io/docs

4.3 案例分析

通过几个真实案例，可以更直观地理解 Context Engineering 的价值。

  • 案例 1：企业客服助手

    某电商公司使用 LLM 构建客服系统，用户可以询问"退货流程是什么？"。系统会在知识库中检索到对应的退货政策，并作为上下文交给模型回答。相比直接依赖 Prompt，准确率提升了约 30%。

  • 案例 2：程序员助手（GitHub Copilot）

    Copilot 的底层模型在生成代码时，会将当前文件、函数签名和部分相关上下文作为输入，从而生成与项目高度匹配的代码。这正是 Context Engineering 的典型应用。

    参考：GitHub Copilot 技术博客 (2021), https://github.blog/2021-06-29-introducing-github-copilot-ai-pair-programmer/

  • 案例 3：学术研究助手

    学术搜索平台结合向量检索与 LLM，当用户提出"给我找关于长上下文窗口优化的论文"时，系统会检索到相关论文摘要，并作为上下文交给模型，生成一个带引用的答案。这种方法显著提升了科研效率。

4.4 工程化难点与解决方案

在实际落地 Context Engineering 时，仍然会遇到一些挑战：

  • 上下文长度受限：即使新一代模型支持更长窗口，也无法无限扩展。解决办法是采用上下文压缩、动态选择和分块处理等技术。

  • 信息噪声与无关上下文：如果检索或拼接了过多无关信息，模型可能被"干扰"。解决方法是使用语义过滤和相关性排序。

  • 系统复杂性增加：Context Engineering 需要整合检索、数据库、API 等多个模块，系统架构变得更复杂。解决办法是使用标准化框架（如 LangChain、LlamaIndex），降低开发和维护成本。

5. Prompt 与 Context 的对比分析

5.1 工程范式的变化

从 LLM 应用发展的角度来看，Prompt Engineering 和 Context Engineering 代表了两个不同的工程范式。Prompt Engineering 的核心是"写好提示"，即通过精心设计输入指令，引导模型生成期望的结果。它强调的是"如何问"，适合早期模型能力有限、上下文窗口较短的阶段。Context Engineering 的核心是"编排信息场"，即将相关的背景知识、历史对话、外部检索结果、结构化数据等以合适的方式组织成上下文，并交给模型处理。它强调的是"如何提供信息"，随着长上下文和多模态模型的发展，这一范式正在逐渐成为主流。

参考文档：

5.2 优势与不足

Prompt Engineering 与 Context Engineering 各有优势与局限。

  • Prompt Engineering 的优

    • 简单易用，快速试验即可得到可用结果
    • 灵活性高，适合原型开发和小规模任务
    • 不依赖复杂基础设施

  • Prompt Engineering 的不足

    • 对措辞高度敏感，难以稳定复现结果；当任务复杂或涉及大量知识时，维护多个 Prompt 成本高。

  • Context Engineering 的优势

    • 能整合大规模外部知识，突破模型参数内知识的限制
    • 提升输出稳定性与一致性，减少对"写法"的依赖
    • 更适合企业级和复杂应用，支持多模态和多 Agent 协作

  • Context Engineering 的不足

    • 工程复杂度高，需要检索系统、数据库和上下文优化机制；上下文构建本身也可能引入噪声。

参考文档：

5.3 互补关系

尽管两者有区别，但 Prompt Engineering 与 Context Engineering 并非对立，而是互补关系。

  • 混合式方法

    在检索增强 (RAG) 系统中，首先通过 Context Engineering 构建上下文（检索到相关文档），再通过精心设计的 Prompt 指导模型如何使用这些文档。两者结合可以获得更好的效果。

  • 任务适配

    对于简单任务，如文本翻译或摘要，Prompt Engineering 足够解决问题；但对于复杂任务（如跨领域问答、智能助手），Context Engineering 更具优势。

  • 工程演进

    在实际项目中，往往是先通过 Prompt Engineering 验证可行性，再逐步引入 Context Engineering 优化系统。这种演进路径能平衡快速原型开发和后期系统稳定性。

参考文档：

在实践中，两者常常协同工作。合理利用 Prompt 的灵活性和 Context 的系统性，才能构建既高效又可靠的 LLM 应用。这也为未来的 Agent 系统奠定了技术基础。

6. 从 Prompt 到 Context 的转型路径

6.1 从实验到工程的转变

Prompt Engineering（提示工程）最初被广泛应用于研究和原型设计阶段。开发者可以通过简单的文本指令快速验证模型的能力。然而，随着实际应用需求的提升，单纯依靠提示设计逐渐暴露出以下问题：

  • 稳定性不足：同样的任务可能因为提示表述不同而结果差异很大。
  • 扩展性有限：面对知识密集型任务时，模型参数内的知识往往不够用。
  • 可维护性差：不同任务需要维护多个提示模板，难以统一管理。

因此，行业逐步转向 Context Engineering（上下文工程），通过上下文编排和外部知识注入，实现更加稳健和可扩展的系统。

参考文档：

6.2 Context Engineering 的核心能力

Context Engineering 的兴起，主要基于以下几类关键能力：

  1. 检索增强 (RAG)

    通过外部检索系统动态获取相关信息，再嵌入到上下文中，弥补模型知识盲点。

    参考：Lewis et al. (2020), Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, https://arxiv.org/abs/2005.11401

  2. 结构化上下文编排

    不仅是简单拼接文本，还包括如何组织知识图谱、数据库查询结果、多模态信息等，使上下文具备逻辑性和结构性。

    参考：Hu et al. (2023), StructGPT: A General Framework for Large Language Model to Reason over Structured Data, https://arxiv.org/abs/2305.09645

  3. 长期记忆机制

    通过记忆模块或外部存储，让模型在多轮交互中保持一致性，而不是每次重新推理。

参考：Xu et al. (2023), MemoryBank: Enhancing Large Language Models with Long-Term Memory, https://arxiv.org/abs/2305.10250

6.3 技术迁移的实际路径

开发者通常会经历以下几个阶段，从 Prompt Engineering 逐步过渡到 Context Engineering：

  1. 单纯依赖 Prompt

    早期阶段，直接通过改写 Prompt 完成需求，适合小规模实验。

  2. 引入模板化 Prompt

    通过参数化提示（如"{用户问题} + {指令}"），减少手工改写成本。

  3. 集成外部知识

    使用检索系统（如向量数据库 FAISS、Weaviate、Milvus），将知识注入上下文，形成 RAG 架构。

  4. 上下文自动化编排

    利用中间层 Agent 或框架（如 LangChain、LlamaIndex），根据任务动态生成上下文，减少人工管理负担。

  5. 长期记忆与个性化上下文

    结合数据库、日志、用户画像，让 LLM 拥有"持续学习"的能力。

参考：

6.4 面向未来的演进趋势

随着模型能力和上下文窗口的提升，Prompt 与 Context 的边界将更加模糊。未来的趋势包括：

  • 自动 Prompt + 自动 Context 混合：由系统自动生成和优化提示与上下文，而非人工调优。
  • 多模态 Context：不仅是文本，还包括图像、视频、音频甚至传感器数据。
  • 可解释与可控的上下文管理：避免"黑箱式"上下文注入，提升系统可靠性。
  • 与 Agent 技术深度融合：Context 不仅是输入，而是动态决策和执行的一部分。

参考：

Prompt Engineering 与 Context Engineering 的转型，体现了从"手工技巧"到"系统工程"的演变。开发者不应仅停留在写好 Prompt，而应逐步拥抱 Context Engineering，使 LLM 应用具备更强的稳定性、扩展性和可维护性。这一过程不仅是技术演进的必然，也是未来智能 Agent 系统的核心支撑。

7 结语

从 Prompt Engineering 到 Context Engineering 的演进，不仅是 LLM 应用开发的一次范式转变，更是整个智能系统向工程化、系统化发展的必然路径。

在早期，Prompt Engineering 承担了"与大模型对话"的入口作用。它强调通过巧妙的指令设计，快速释放模型潜能。但随着应用场景的复杂化与规模化，这种方式暴露了可扩展性与稳定性不足的局限。于是，Context Engineering 应运而生，它强调通过系统化的上下文管理、外部知识检索、多模态信息融合和记忆机制，构建更加稳健和可维护的 LLM 应用。

未来的发展趋势，可以从以下几个方面展望：

  1. Prompt 与 Context 的融合

    Prompt 不会消失，而是成为 Context 工程的一部分。二者协同，能实现更灵活、更稳定的系统。

    参考：Gao et al. (2023), Rethinking with Retrieval: Faithful Large Language Model Inference, https://arxiv.org/abs/2301.00303

  2. Agent 驱动的上下文自治

    未来的 Agent 系统将能够自主检索、选择、编排上下文，动态优化输入，从而实现接近人类"思考---行动---记忆"的闭环。

    参考：Park et al. (2023), Generative Agents: Interactive Simulacra of Human Behavior, https://arxiv.org/abs/2304.03442

  3. 多模态与长期记忆结合

    不仅是文本，图像、音频、视频、传感器数据都会成为上下文的一部分。同时，长期记忆机制将使系统具备持续学习与个性化的能力。

    参考：Xu et al. (2023), MemoryBank: Enhancing Large Language Models with Long-Term Memory, https://arxiv.org/abs/2305.10250

  4. 可控性与可解释性提升

    上下文的透明化与可解释化将成为企业级应用的关键要求，帮助开发者理解模型为何做出特定回答。

Prompt Engineering 是点燃 LLM 应用的火花，而 Context Engineering 则是将其转化为持续能源的引擎。对于开发者而言，理解并掌握从 Prompt 到 Context 的迁移路径，不仅有助于构建更强大的应用，还能更好地把握未来智能 Agent 生态的核心竞争力。

换句话说，Prompt 是"大模型的语言"，而 Context 才是"智能系统的语境"。二者的结合，将推动 LLM 从工具走向真正的智能体。

相关推荐
非晓为骁9 小时前
【AI】AI 评测入门（二）：Prompt 迭代实战从“能跑通”到“能落地”
人工智能·prompt·提示词工程·ai评测
leo03081 天前
7种流行Prompt设计模式详解：适用场景与最佳实践
设计模式·prompt
风雨中的小七2 天前
解密prompt系列60. Agent实战：从0搭建Jupter数据分析智能体
prompt
zzywxc7872 天前
AI在金融、医疗、教育、制造业等领域的落地案例（含代码、流程图、Prompt示例与图表）
人工智能·spring·机器学习·金融·数据挖掘·prompt·流程图
bboyzqh2 天前
任务型Agent：prompt工程实践
大模型·prompt·上下文工程
美人鱼战士爱学习3 天前
2024 arXiv Cost-Efficient Prompt Engineering for Unsupervised Entity Resolution
prompt
水的精神3 天前
写好 Prompt 的 12 条实践经验
prompt
Wilber的技术分享3 天前
【大模型实战笔记 1】Prompt-Tuning方法
人工智能·笔记·机器学习·大模型·llm·prompt
relis3 天前
解密llama.cpp：Prompt Processing如何实现高效推理？
prompt·llama
热门推荐
01UV安装并设置国内源022025 年高教社杯全国大学生数学建模竞赛C 题 NIPT 的时点选择与胎儿的异常判定 完整成品思路模型代码分享，全网首发高质量！！！032025年数学建模国赛C题超详细解题思路04A股预测还能更准？开源大模型Kronos带你跑通预测+回测全流程05不再让Windows更新！&Edge游戏助手卸载及关闭自动更新06KGG转MP3工具|非KGM文件|解密音频07UV 工具安装与国内镜像源配置指南08教你如何认证 Gemini 教育优惠的二次验证，薅个 1年的 Gemini Pro 会员092025全国大学生数学建模C题保姆级思路模型（持续更新）：NIPT 的时点选择与胎儿的异常判定102025高教社杯国赛数学建模选题建议+初步分析