上下文工程：更好持续 AI 的瓶颈
早在 2019 年，我就曾在 O'Reilly AI 大会上做过关于构建上下文 AI 助手的演讲。尽管人工智能自那时起已取得长足进步，但一个挑战始终存在：在正确的时间提供正确上下文的艺术与科学。
如今，当大型组织的平台团队开始探索持续 AI (Continuous AI) 时，上下文工程已成为阻碍他们实现更多软件开发工作流自动化的主要瓶颈。
上下文工程不仅仅是编写更好的提示词 (Prompts) —— 它是关于系统性地解决在 AI 需要时向其提供相关信息的问题。对于负责赋能数千名开发者的平台团队而言，这一挑战尤为严峻。
比起“提示词工程”，我更喜欢“上下文工程”这个术语。
它能更好地描述核心技能：即通过提供完成任务所需的一切上下文，使任务能够被大模型合理地解决。
— tobi lutke (@tobi) 2025年6月19日
大型组织中的上下文危机
大多数组织都坐拥海量有价值的上下文，这些信息本可以让他们的 AI 效率大幅提升，但这些信息目前的存在形式对于人类和 AI 来说都难以获取。
你所需要的上下文从未被记录下来。 关键决策往往是在 Zoom 会议和走廊闲谈中做出的。架构选择背后的考量、过往事故的经验教训，以及指导日常决策的制度性知识，大部分只存在于人们的脑海中。当这些人离职时，这些上下文往往也随之流失。
即便有了文档记录，它们也散落各处。 组织知识分散在 Confluence 页面、SharePoint 站点、Jira 工单、Slack 讨论串、电子邮件链以及无数其他系统中。即使开发者知道这些信息存在，他们往往也不知道去哪里查找或如何有效地检索。
已记录的上下文并未针对 AI 消费进行优化。 传统的文档是为人类按顺序阅读而编写的。AI 系统需要结构化、具体且可搜索的信息，这些信息必须能够被快速提取并独立理解。而且它们还需要正确的访问权限。
对于平台团队来说，这意味着你的 AI 工具只能在极小一部分必要的上下文中运行。你的开发者得到的只是泛泛的建议，而非理解组织特定模式、约束和最佳实践的专业推荐。
规模化场景下的相关性挑战
即使你有全面的文档，在企业规模下，确定哪些上下文对特定任务有相关性也会变得极其困难。
上下文窗口设定了硬约束。 你不能把所有东西都丢给 AI 并期望它找出重点。你需要对包含哪些上下文或指向何处做出明智的决策，而这些决策需要同时理解即时任务和更广泛的组织背景。
人类的直觉难以文档化： 一位资深开发者可能凭直觉知道两年前的某个架构决策与今天的特性需求相关，但要将这种语境感知能力编码进服务于数百名开发者的系统中是非常困难的。
错误的上下文比没有上下文更糟： 当无关或过时的信息进入你的上下文时，就会出现“上下文投毒”现象——即 AI 对错误信息过于自信，并将错误传播到整个代码库中。
要求个别开发者手动收集上下文（复制/粘贴文档片段、@文件引用等），对于试图在大型开发组织中实现一致且可靠的 AI 协助的平台团队来说，往往是行不通的。
维护难题
上下文工程不是一次性的设置问题；它是一个持续的维护挑战，并会随着组织的扩张而愈发困难。
信息很快就会过时。 你上季度的 API 文档在最近重构后可能完全错误。你的架构决策记录可能无法反映上周事故中汲取的教训。与代码不同（代码过期时通常会发生明显的报错），上下文的衰退往往是悄无声息的。
缺乏明确的权责模型。 谁负责保持输入给 AI 的上下文处于最新状态？在大多数组织中，这落在了开发团队（专注于交付功能）和平台团队（可能不具备每个服务的深入领域知识）之间的灰色地带。
上下文的相关性随时间而变。 六个月前至关重要的信息今天可能完全不相关，但你的 AI 系统不会自动知晓这一点。你需要建立系统，不仅要更新上下文，还要确定何时应弃用或彻底删除上下文。
对于平台团队而言，这带来了可持续性挑战。构建起初运行良好的 AI 系统已属不易，但要构建随着组织演进而保持良好运行的系统，需要一种根本不同的上下文管理方法。
当上下文工程不再够用时
随着上下文窗口变大和检索系统变得更加复杂，在某些情况下，向提示词中填充更多上下文依然不是最佳解决方案。
某些知识最好编码在模型权重中。 如果你的组织有成千上万个文件中都会出现的特定编码模式，或随处可见的特定领域术语，那么微调模型来理解这些模式，可能比每次都尝试在上下文中提供示例更有效。
成本和延迟在规模化场景下至关重要。 当你为数千名开发者提供 AI 辅助，每天处理数百万次请求时，大上下文窗口的成本会迅速累积。投资模型定制化可能比支付昂贵的上下文窗口和长期运行的智能体探索费用更经济。
质量与数量的取舍变得至关重要。 在大型组织中，往往存在太多潜在的相关上下文，因此你需要复杂的系统来对信息进行排序、总结和压缩。在某个阶段，使用经过特定上下文训练的小模型，可能比使用试图实时处理相同上下文的大模型效果更好。
平台团队的关键见解在于：了解何时通过更好的检索解决上下文问题，何时通过更好的模型来解决。这一决策取决于你在成本、延迟、隐私以及组织上下文性质方面的具体约束。
衡量关键指标
当今上下文工程中最大的缺口是评估。大多数部署 AI 工具的组织对于什么有效、什么无效的可见性非常有限。
你需要开发数据来改进上下文系统。 开发者与 AI 工具之间的交互产生了关于上下文质量的宝贵信号。当开发者拒绝建议、编辑生成的代码或重复询问同一类信息时，这些数据可以指导你的上下文工程系统进行改进。
传统指标抓不住重点。 衡量响应时间或合成基准测试的准确性，并不能告诉你你的 AI 工具是否在帮助开发者更快地交付更好的代码。你需要将 AI 协助与真实的业务成果挂钩的指标：如缩短事故处理时间、加快新成员入职速度、减少生产环境中的 Bug。
上下文问题表现为其他地方的症状。 当你的 AI 工具生成的代码不符合组织模式、建议已弃用的 API，或给出的建议与架构原则冲突时，根本原因通常是上下文工程不足。你需要一个监测系统将这些问题追溯到源头。
平台团队需要系统化的方法来收集这些反馈，并利用它持续改进上下文系统。这不仅仅是为了更好的 AI，更是为了构建组织层面的知识管理和共享能力。
构建更好的上下文系统
对于准备系统性解决上下文工程的平台团队，今天就可以采取以下实践步骤：
从规则开始。 不要寄希望于 AI 会自动学习你的标准，应将它们编码为明确的规则，并与代码存储在一起。像 Continue 规则 这样的工具允许你定义上下文，使其在相关时自动被包含进去。
让更多上下文可访问。 采用 MCP 工具，使你的 AI 系统能够查询 Linear、Jira、Confluence、服务目录、事故管理系统等现有数据源。让上下文变得可访问，通常比追求其完美更具价值。
投资于上下文发现。 你的开发者往往知道哪些上下文会有帮助，但不知道去哪里寻找。采用像 Continue Hub 这样能够轻松发现和共享相关上下文的系统和工具。
衡量正确的指标。 存储你的开发数据。基于此构建仪表盘，并将其与重要的业务成果挂钩：开发者生产力、代码质量、上市时间。利用这些数据来指导你的上下文工程投资。
为维护做计划。 上下文工程不是一个项目，而是一种持续的能力。构建能够随着组织发展和变化而演进的系统和流程。
那些能够搞定上下文工程的组织，将在软件开发的 AI 原生未来中拥有显著优势。他们的 AI 工具将不仅仅提供通用协助，更将提供理解并反映其独特软件构建方式的深度协助。
上下文工程是一项艰苦的工作，但它恰恰是平台团队独具优势去解决的任务。对于那些认真对待 AI 原生开发的组织来说，这项工作已不能再拖延了。
如果你正在大型组织中为持续 AI (Continuous AI) 进行上下文工程方面的研究，我很乐意交流！你可以在 Continue Discord 上找到我 (@tydunn)，或者通过 此表格与我联系。