> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 营销人员上下文工程指南 - URL: https://www.hubwiz.com/blog/a-context-engineering-guide-to-marketers/ - Published: 2026-02-23T04:27:22.000Z - Updated: 2026-02-23T04:27:22.000Z - Description: 你的 AI 确实是一名员工。上下文窗口就是他们的桌面。 - Author: admin - Tags: CONTEXT ENGINEERING, #Import 2026-10-14 14:41 你的 AI 代理对你的产品了如指掌。你写了详细的提示、上传了文档、测试了无数次。然后客户问起定价，代理引用的是上一个季度的费率。又或者它向已经与你合作了三年的客户推介演示。又或者它高兴地给出一个两周前就过期的折扣码。 最让人挫败的是：正确的信息就放在你的提示词里。在第 347 行，清楚地写着。AI 偏偏把它忽略了。 [研究人员对这件事有一个名字](https://arxiv.org/abs/2307.03172?ref=hubwiz.com)："丢失在中间"。LLM 的注意力曲线呈 U 形，在输入的前后信息处理较为可靠，而对中间夹杂的任何信息的表现则可能下降超过 30%。你在客户上一次抱怨后加入的那条精心设计的规则，模型很可能根本没看到它。 [Wharton 的 Generative AI Labs](https://gail.wharton.upenn.edu/research-and-insights/tech-report-prompt-engineering-is-complicated-and-contingent/?ref=hubwiz.com) 在测试提示时也发现了类似的现象，他们把每个问题问了 100 次而不是一次，严格的准确性要求下，大部分条件"勉强优于随机猜测"。每个输出看起来都不错，但并非可靠。 你的提示可能没问题。但是 [提示工程](https://www.hubwiz.com/blog/prompt-engineering/) 已经成为一个更大栈中的一层，现在真正能在生产环境中工作的团队，花在围绕提示的内容上的时间，甚至比提示本身更多。上下文才是关键。 ## 1、什么是上下文工程？ [LangChain 团队](https://www.blog.langchain.com/context-engineering-for-agents/?ref=hubwiz.com) 对 Andrej Karpathy 的表述进行改写，他曾帮助打造特斯拉的人工智能并共同创建 OpenAI：“LLMs 就像一种新型操作系统。LLM 是 CPU，上下文窗口是 RAM。” 我找到了一个更简单的方式来向我的营销朋友解释，他们对“tokens”和“推理”感到困惑。 > 你的 AI 是一名员工。上下文窗口是他们的桌子。\[…\] 你给他们的提示词是今早递给他们的便签。 你的 AI 确实是一名员工。上下文窗口就是他们的桌面。桌面上现在摆着的客户档案、他们打印出的活动简报、抽屉里塞着的品牌指南——这些就是他们可以处理的内容。桌子会堆满，AI 的记忆也会增长。 你的提示词是今晨递给他们的便签。重要当然，但他们桌面上的文件夹堆积如山？他们打开的 CRM？正是这些决定了他们到底是在帮助客户还是在问客户已回答的问题。 Anthropic 在 2025 年撰写了他们对上下文工程的研究：将“在 LLM 推理过程中，整理并维持最佳令牌集合的策略集合”定义为上下文工程。换言之，给 AI 在正确的时间以正确的格式提供正确信息。不是更多，而是恰好所需。 ## 2、演变：从聊天机器人到具备上下文感知的代理 在深入探讨如何实现之前，我们先了解我们在 [AI 采用曲线](https://www.hubwiz.com/blog/ai-adoption/) 上处于何处。 - Phase 1：拷贝粘贴式的 ChatGPT。营销人员发现可以把客户邮件粘到聊天窗口，得到草拟回复。很振奋，但每次会话都从零开始。 - Phase 2：定制的 GPTs 和助手。你可以预加载指令和文档。更好，但上下文是冻结的，与你的业务没有实时连接。 - Phase 3：代理 AI。代理人采取行动，而不仅仅是生成文本。他们会更新你的 CRM、创建工单、发送邮件、做出决策。这种能力需要一种新的纪律：不能光给出指令就指望代理会自己执行，你必须为其架构知识。 大多数营销人员仍停留在阶段 1 或 2。领先者正在为阶段 3 做准备。 ## 3、上下文差距：为什么你的提示不起作用 当 AI 行为异常时，直觉往往是增加规则。提示会变长，200 行、400 行、甚至 500 行。更多指令似乎意味着更好的行为。 事实并非如此。 ### 3.1 中间信息被忽略 我提到过斯坦福的研究。[Chroma 的 2025 年“上下文腐蚀”研究](https://research.trychroma.com/context-rot?ref=hubwiz.com) 也有类似发现，他们测试了包括 GPT-4.1、Claude 4、Gemini 2.5、Qwen3 在内的多种模型，发现“模型并非均匀使用上下文；输入长度越长，表现越不稳定”。当研究代理学习时，涉及多轮对话、整张上下文窗口都被传递时，令牌数量暴涨，\_context\_中的指令反而被忽略。 ### 3.2 静态信息 vs 实时信息 一个超大提示是冻结的。你上个月写的。自那之后，价格变了，客户提交了支持工单，市场部今天早上推出了新活动。提示并不知道这些，只有你写下它时存在的信息。 ### 3.3 上下文窗口上限 每个模型都有一个上下文窗口。Claude 的窗口是 200K 令牌，GPT-5 是 400K，Gemini 3 Pro 可达 1M。数字虽大，但研究显示，大多数模型在达到极限前就已经开始不可靠。 在实际应用中，大型提示会占用大量空间，会有对话历史堆叠、文档加载等。到达上限时，较早的信息会被挤出，AI 会忘记十分钟前记住的事。 当我开始构建生产级代理时，给我很大震撼的是 Manus 公司的一项研究：他们发现他们的代理每产生 1 个输出令牌，就需要大约 100 个输入令牌作为上下文。对于一个需要大约 50 次工具调用的复杂任务，处理的大约是 50,000 个上下文令牌。大部分上下文是工具输出、对话历史和检索到的文档。 ## 4、上下文如何失效 上下文并非只是用完。它会以若干可预测的方式失效。Drew Breunig 研究了四种值得了解的失效模式： - 上下文污染：早期错误或幻觉进入上下文并被放大。AI 反复引用错误信息，因为它被写进记录里。一旦上下文被污染，后续的每一个决策都以这个错误为基础。 - 上下文分心：无关信息淹没了相关信息。你加载了十份文档，但这次问题只需要其中一份。 - 上下文混乱：模型无法判断哪些上下文信息适用于当前情境。你把企业和 SMB 客户的定价规则混在同一个上下文中，AI 把它们混淆。 - 上下文冲突：上下文中存在矛盾信息。上个月的定价和本月的定价同时出现，旧的活动规则和新的规则也在。AI 必须做出选择，可能会选错。 当你的代理行为异常时，这些类别有助于诊断问题：是污染（早期数据错误）？分心（信息过多且不相关）？混淆（无法判断哪个信息适用）？还是冲突（信息矛盾）？ ## 5、AI 实际需要的东西：上下文工程 vs 提示工程 大多数人把 AI 当成一个非常直观的员工，试图通过给出更多指令来解决问题。更多规则、更多示例、更多边界条件。然而我意识到问题更深层：AI 需要更好的*信息架构*，而不仅仅是更好的措辞。 提示工程问的是“我应该说什么？”上下文工程问的是“我应该知道什么？”提示是静态的、一次性写好、冻结的；上下文是实时、根据提问者和需求动态加载的数据系统。 想象一下招聘新员工。你不会给他一本 50 页的手册让他在每次通话前都背诵。你给他 CRM 访问权限，指向知识库，分享带有真实案例的风格指南。你让他知道本周正在进行的活动，以及在何种情境下应升级。 上下文工程也为 AI 做同样的事情。 ![四种上下文策略的信息图](https://www.hubwiz.com/blog/content/images/2026/02/image2.png) [LangChain 的框架](https://www.blog.langchain.com/context-engineering-for-agents/?ref=hubwiz.com) 将上下文工程拆解为四种策略。我发现这对于思考你系统实际需要什么很有用： - 写入：给 AI 提供一个在主内存之外保存信息的地方。草稿、本、笔记。这样它就不需要把所有信息都记在脑海里。 - 选择：仅提取相关信息。不是所有文档，而是对当前问题有帮助的部分。 - 压缩：当上下文变长时进行摘要。一个持续进行 20 轮对话的会话不需要把前 20 轮全部保留。 - 隔离：把复杂任务拆分给多个具有独立上下文的代理。一个代理研究，一个写作，第三个审阅。各自拥有干净、聚焦的上下文，而不是一个代理被一切信息淹没。 在实际操作中，大多数团队 heavily 依赖于“选择（Select）”。这时，像 Zapier Tables 这样的工具就非常有用：让代理可以从结构化的上下文中挑选所需信息，而不是一次性加载全部内容。 上下文是有限的。收益递减。Anthropic 的工程团队 \[很好地表达了这一点\]（https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents）："好的上下文工程意味着找到能够最大化某种期望输出可能性的最小化高信号令牌集合。" 最近的学术研究也证实这一点：对相关信息的策略性选择始终优于把你拥有的一切信息全部灌入模型。更多上下文并不总是更好的上下文。 你存储的东西与模型看到的东西之间存在差异。你的数据库可以存储 TB 级别的数据。但在任一时刻，AI 应该看到的只是与当前会话相关的内容。 不要一次性抛出全部信息。让 AI 去查找。客户在提问时的细节。功能点出现时的产品规格。不需要所有信息，随需而加载。 我花了最长时间才学会的一点：正确内容的 500 个令牌要比你拥有的一切的 50,000 个令牌更有用。 ## 6、对 AI 真正重要的三种上下文 要构建真正能工作的代理，你需要三种上下文。把它们想象成 AI 始终可以访问的数据库。 ![用于营销人员的 AI 上下文类型信息图](https://www.hubwiz.com/blog/content/images/2026/02/image1.png) ### 6.1 品牌上下文：你是谁 这是 AI 的个性。定义回答的风格、语气和边界，使其听起来像你，而不是通用的 ChatGPT。 大多数营销人员在这里会错过一件事：不能仅通过写作提示来创造品牌形象。研究显示，LLM 生成的人设存在系统性偏见：积极性偏差、理想化画像、偏见观点等。 因此，应该提取而不是凭空捏造。把你表现最好的邮件、最高评价的客户支持回复、最被广泛分享的社交帖子作为示例，输入给 AI。让品牌上下文来自于你已经做得好的，而不是你希望品牌应该听起来如何。 品牌上下文包括语音准则（“直接而自信，不做广告推销”）、反模式（“永远不要说‘协同作用’”等）、已批准的术语（尤其是人们容易错写的产品名），以及诸如竞争对手名字或尚未发布功能等禁区话题。我还会加上十到二十个真正把语气做对的回复，以及升级时机等规定：何时将对话上交给真人，AI 不该承诺的承诺等。 ### 6.2 客户上下文：他们是谁 这点随每次对话而改变。 没有客户上下文的情况下，每次互动都是从零开始。AI 会问“你们所属行业是什么？”当客户已经明确告诉你两遍后仍然这样问。拥有客户上下文后，你的 AI 可以说：“上次我们交谈时，你在评估我们的 API 集成。你有没有机会查看我发给你的文档？” 这一句话需要记忆。记忆是区分助手和会话机器人之间的分水岭。这里应该包含：公司信息与账户等级（以判断是否推介企业功能）、行业、是否有未解决的工单、购买历史和最近对话、以及在漏斗中的阶段（因此 AI 会在产品细节上走得更深或更浅） ### 6.3 战略上下文：你想实现的目标 在我的经验中，营销人员几乎总是忘记这一点。 你的 AI 不知道现在是一季度。它不知道你在推动年度计划，或本季度的目标是演示而不是提供免费试用。除非你告诉它。 这一层包含：当前活动（使代理知道要提到哪些定价优势）、可用优惠、不同漏斗阶段的规则与转化目标、以及竞争定位。 会随季度变化、影响 AI 实际应推动的内容。 ### 6.4 他们如何协同工作 客户问：”与你们相比，\[Competitor\] 有何不同？“ 品牌上下文要求绝不直接点名竞争对手；客户上下文显示他们是金融科技领域的企业试用用户；战略上下文指明当前重点是合规功能。 结果：一个突出合规能力（与金融科技相关）、强调企业级安全性（与他们的等级相关）、并在不点名对手的情况下进行定位的回答。全部保持在你的品牌语气中。 我认为没有任何提示工程技巧能达到这个效果。这需要架构。 --- 原文链接: [Context engineering: A marketer's guide](https://zapier.com/blog/context-engineering/?ref=hubwiz.com) 汇智网翻译整理，版权归意为出处