AI 上下文工程最大的误区：以为把已有资料交给 AI 就够了
真正的问题不是如何提供上下文，而是如何确定 AI 究竟需要什么上下文
一、给了AI大量资料，为什么它还是不会做？
一家企业准备利用AI Agent帮助销售人员识别客户需求。
企业已经积累了大量资料：产品手册、销售话术、客户档案、历史订单、客户沟通记录、成功销售案例等。 技术团队把这些资料接入知识库，利用 RAG 检索增强生成技术，让 AI 在回答问题时能够调用相关资料。 从技术角度看，系统已经具备了相当丰富的上下文。
但在实际应用中，AI依然可能无法准确判断客户真正需要什么。
例如，一位客户说：“你们的产品价格太贵了。” AI 可能从产品资料中找到价格说明、优惠政策、不同产品的价格对比，然后推荐更便宜的方案。 问题是：客户真正需要的，也许根本不是降低价格。 他可能正在面临预算压力，也可能是产品使用率太低，或者无法向上级证明采购价值。甚至，他只是拿竞争对手的报价作为谈判筹码。
要准确识别需求，仅仅了解产品及其价格是不够的。 AI 还需要了解客户个人、岗位、项目、组织以及外部环境等方面的信息，更重要的是，需要理解这些因素如何影响客户需求。 这里暴露出一个经常被忽略的问题：企业提供给 AI 的上下文，未必就是 AI 完成任务真正需要的上下文。 这也是为什么，企业即使建设了规模庞大的知识库，AI 仍然可能无法完成某些业务任务。
二、上下文工程解决了一个问题，却不等于解决了全部问题
上下文工程已经是当前企业 Agent 落地的热点话题，很多团队在忙着优化检索、重排、动态信息组装。但多数讨论都聚焦在「如何交付上下文」，很少往前追问：这项业务判断，到底需要哪些上下文。
早期，人们更多关注如何编写 Prompt，让 AI 按照要求回答问题。 后来逐渐发现，复杂的 AI 应用不能只依靠一段提示词，还需要提供任务背景、历史记录、业务数据、相关文档、操作规则以及工具调用结果。 于是，上下文工程成为 AI 应用建设的重要工作。 它关注如何检索、选择、组织和管理相关上下文，如何在有限的上下文窗口中提供高价值内容，如何保持信息的准确性和时效性。 这些工作非常重要。
但从企业复杂业务任务的角度看，仅仅解决如何提供上下文的问题还不够。 因为在此之前，存在一个更加基础的问题： AI 为了高水平完成某项任务，究竟需要哪些上下文？
这两个问题存在根本区别。 一个是如何提供，另一个是需要什么。 如果企业已经明确知道 AI 需要哪些数据、信息和知识，那么技术团队可以利用知识库、RAG、数据库查询、API、工具调用等方式，让 AI 在合适的时候获取这些内容。 但如果企业本身就不知道完成任务需要哪些数据、信息和知识，那么无论上下文工程做得多么出色，也不能保证 AI 完成任务。
当然，上下文工程实践中也会开展内容选择和任务分析。这里强调的是两类工作重点不同：如何组织和传递已有内容，与如何发现尚未被识别的知识需求，并不是同一个问题。
尤其需要警惕一个隐含假设： 企业完成 AI 应用所需要的上下文，已经存在于当前的数据库和文档中。 这个假设在很多简单任务中可能成立，在复杂的业务判断任务中却未必成立。
三、为什么很多人识别不出 AI 真正缺少什么？
问题的根源，在于我们长期习惯于从已有资源出发建设知识库，而不是从任务所需的知识出发。 过去，企业知识管理通常会先盘点已经积累了哪些资料，再开展知识分类、文档整理、知识库建设和检索服务。 进入 AI 时代，许多企业仍然延续这一思路，只不过把文档检索升级为 RAG，把知识库接入大语言模型。 但这并没有回答一个问题： 企业现有的知识，是否足以支撑 AI 完成目标任务？
更麻烦的是，即使知识不足，我们也未必能够发现。 原因至少有三种。 第一，有些数据和信息并没有被采集 还是客户需求识别的例子。 企业的 CRM 中可能保存了客户名称、行业、采购金额和历史订单，却没有记录客户当前项目的目标、面临的问题、组织内部的决策关系，以及相关人员的实际诉求。 这些信息可能是判断当前需求的关键，但从未进入企业系统。 如果只是接入现有 CRM，AI 自然也无法获得这些内容。
第二，有些知识存在于专家头脑中，却没有被明确表达 有经验的销售专家往往能够快速判断客户需求。 他不仅了解产品，而且知道客户需求如何形成。 例如，客户的岗位职责、考核目标、项目状态、组织利益关系，以及外部环境的变化，可能共同影响客户的实际需求。 对于专家来说，了解这些因素可能已经成为工作常识。 但企业现有的销售手册中，未必记录了这些因素之间的关系，也未必解释了为什么要收集某些客户信息。 因此，专家会做，并不意味着企业已经拥有支持 AI 做同样事情的显性知识。
第三，有些知识不仅没有记录，甚至还没有被系统建构 这类问题更加困难。 企业可能有很多优秀销售人员，每个人都积累了丰富经验。 但他们未必能够系统解释：客户需求究竟由哪些因素形成，不同因素之间是什么关系，哪些信息具有较强的判断价值，什么情况下应该采用不同策略。 这意味着，知识建设并不总是简单地把专家说过的话记录下来。 有时还需要通过任务分析、专家比较、案例分析和实践验证，重新建构完成任务所需的知识。 缺少的知识，不一定是尚未找到的文档；也可能是从未被表达、甚至尚未被明确认识的判断依据。
四、真正的关键：把能力还原为数据、信息和知识
为什么经验丰富的专家做一件复杂的事情，旁人觉得非常厉害，他自己却觉得很自然？ 一个重要原因是，专家已经掌握了支撑判断的数据、信息和知识。
举个生活中的例子。 领导让你安排一次重要客户的商务宴请。 如果你什么都不了解，只知道要把客户招待好，这就成了一项非常模糊的任务。 应该选择什么餐厅？安排什么菜？需要多高的档次？是否需要喝酒？时间怎么安排？ 于是你可能希望学习商务宴请能力、客户接待技巧，甚至购买相关培训课程。
但换一种思路。 假设你了解到：客户来自哪里、有什么饮食偏好、是否有忌口、双方是什么关系、此次来访的目的是什么、有没有同行人员、晚上是否还有行程，以及宴请预算是多少。 随着这些信息逐渐清楚，原本复杂的问题可能就变得简单了。 如果客户不喝酒、喜欢清淡食物、晚上还要赶飞机，那么餐厅选择、菜品安排、用餐时间等问题，利用常识和基本逻辑就能作出相当合理的判断。
这里真正发生的是什么？ 我们并没有突然获得一项神奇的商务宴请能力，而是找到了支撑正确判断的关键条件。 当然，信息不是越多越好。 客户使用什么手机、毕业于哪所学校，可能与此次宴请并无关系。 真正重要的是，知道哪些因素会影响判断，以及如何理解这些因素之间的关系。
这就需要同时分析三个层次。 数据： 完成任务需要掌握哪些具体事实？ 信息： 这些事实在当前任务与情境中意味着什么？它们之间有什么联系？ 知识： 应该依据什么概念、规律、机制、原则和模型来理解这些信息，并形成判断？
三个层次缺一不可。 即使掌握丰富的商务宴请知识，如果完全不了解宴请对象，也可能作出错误安排。 反过来，虽然收集了大量数据，但如果缺少相应的知识，不理解这些数据与任务之间的关系，同样可能无法作出合理判断。 这也说明，所谓能力不足，有时是知识不足，有时是数据和信息不足，有时则是无法正确理解数据、信息与知识之间的关系。
五、分析客户需求，首先要知道需求是怎么形成的
回到最开始的销售案例。 如果我们要求销售人员 “准确识别客户需求”，通常会想到培训提问技巧、沟通技巧、倾听技巧和需求挖掘方法。 这些技巧有价值，但仍然可能遗漏一个更基础的问题： 客户需求究竟是由什么形成的？
客户不是凭空产生需求的。 一个具体需求，往往与客户个人、工作任务、项目状态、组织目标、现有问题以及外部环境等因素有关。 比如，一个客户提出要购买某套软件。 这个需求可能来自公司战略调整、业务规模扩大、当前系统无法支持新的工作流程，或者某位负责人迫切需要完成绩效目标。 这些因素共同影响需求的内容、紧迫性、预算和优先级。
因此，要准确识别客户需求，就需要分析需求形成的机制，进一步明确需要了解哪些数据和信息。 例如，客户希望降低软件采购成本，究竟是预算不足，还是认为产品价值不高？是企业整体压缩支出，还是某个项目即将结束？是现有功能无法满足需求，还是采购负责人面临考核压力？ 了解的信息不同，可能得出不同的判断，也可能采取完全不同的解决方案。
对于优秀销售人员而言，这些分析可能已经成为常识。 对于普通销售人员来说，如果只是要求他 “提高客户需求识别能力”，他可能不知道应该如何提升。 但如果进一步明确，需要了解客户的哪些情况、这些信息为什么重要、怎样收集、如何分析，就能够形成具体的学习和行动要求。
对于 AI 也是如此。 与其笼统要求 AI 具备 “客户需求识别能力”，不如分析这项能力背后需要哪些数据、信息和知识，再通过业务系统、知识库、对话获取等方式补充必要条件。 只有理解客户需求形成的机制，才可能系统识别完成需求判断所需要的上下文。
六、上下文需求分析，应该从高水平任务表现出发
那么，企业应该如何发现 AI 真正需要的上下文？ 我们认为，不能只从现有资料出发，而应该首先分析 AI 需要完成的任务。 更进一步，不能只知道任务叫什么，还需要明确高水平完成这项任务意味着什么。
例如，“识别客户需求” 只是一个任务名称。 高水平表现可能包括：识别客户真实问题、发现尚未明确表达的需求、判断需求的紧迫性与优先级，并提出有针对性的解决建议。 接下来，需要进一步分析完成任务的关键动作和判断。 例如，应该了解哪些客户情况？哪些信息需要核实？如何判断客户表达的诉求是否是真正需要解决的问题？
然后继续追问： 这些动作和判断需要哪些数据、信息和知识？ 其中哪些已经存在于企业系统中？哪些分散在各种资料里？哪些存在于专家经验中？还有哪些知识目前根本没有被建构出来？
这就是一套分析路径： 高水平表现 → 关键任务 → 动作与认知 → 关键判断 → 所需数据、信息、知识 → 现有资源与缺口 → 知识获取和建构 → AI 应用与验证。
分析过程中，可以从比较容易识别的任务和动作入手，不要求一开始就知道全部知识需求。 例如，一个刚入职的销售人员可能说不清销售专家具备哪些知识，但通常能够识别客户开发、需求分析、方案设计、异议处理等任务。 再以具体任务为入口，借助业务专家、AI 和实际案例，逐步深入到动作、判断以及背后的数据、信息和知识。
这也意味着，AI 不仅是知识需求分析的应用对象，还可以成为辅助分析的工具。 但 AI 提出的知识需求和判断规则，仍需要业务专家及实践验证，尤其不能把模型生成的可能性直接当成企业的实际业务知识。
七、上下文工程之前，需要补上知识需求分析与知识建设
基于上述认识，企业 AI 建设需要把三个相互关联的工作衔接起来。
表格
| 工作 | 核心问题 | 主要产出 |
|---|---|---|
| 上下文需求分析 | 完成任务需要知道什么？ | 数据、信息、知识需求及缺口 |
| 知识获取与建构 | 所需内容从哪里来？ | 数据采集、知识模型、判断规则、补充资料 |
| 上下文工程 | 如何让 AI 正确使用这些内容？ | 检索、工具调用、上下文组织与管理机制 |
这三块工作，我们依托自研KTAF 知识任务分析框架形成标准化路径：先做上下文需求分析，识别任务必须的数据、信息与知识缺口；再完成知识获取与建构，配套必要的知识治理；最后才进入上下文工程环节，设计检索、工具调用、动态上下文组装机制。
其中，知识建设还要考虑术语规范、元数据、知识颗粒度、知识之间的关系、版本管理、质量控制等问题，使内容能够被持续维护和可靠使用。
这并不是否定上下文工程。 恰恰相反，只有知道需要提供什么，上下文工程才能更有针对性。 而且并非所有上下文都需要提前写入提示词或者知识库。 有些数据必须在任务发生时实时获取，有些信息需要在对话过程中向客户询问，有些判断需要调用业务系统，还有些问题在信息不足时必须暂缓决策或转交人工。 这些都应该根据实际任务进行设计。
因此，一个真正有效的 AI 知识体系，不仅要包含 “已经知道的内容”，还应当说明： 面对某项任务，应该获取什么、如何理解、怎样判断，以及在什么条件下不能判断。 这也是人类专家在复杂业务中通常已经具备，却很容易在 AI 建设过程中被忽略的部分。
八、AI 时代，知识管理的机会不只是管理已有知识
回顾企业知识管理的发展，我们长期重视知识的采集、分类、存储、共享和检索。 这些工作仍然有价值，但 AI 时代提出了更高的要求。 过去，一份资料只要能被员工找到，就可能发挥价值。 因为有经验的员工可以利用已有知识和常识，补充资料中没有明确写出来的内容。
但 AI 并不一定掌握这些组织内部特有的常识。 人类专家默认知道的信息、判断依据和业务规则，如果没有通过模型能力、上下文或外部工具获得，AI 就可能无法可靠完成任务。
因此，企业不能再仅仅满足于把已有文档管理起来，而应该主动分析关键业务任务需要什么知识，并对不足的部分开展知识获取和建构。 知识管理也需要从资源导向进一步转向任务牵引。 不只是管理已有知识，更要建构完成任务所需要的知识。
这意味着知识管理工作的起点要发生变化： 不再只是问企业有哪些知识、这些知识如何分类、怎样提供给员工和 AI。 还要追问： 为了完成关键业务任务、实现高水平表现，究竟需要哪些数据、信息和知识？目前缺少什么？应该怎样补齐？ 这既是知识管理的新机会，也要求知识管理人员与业务专家、技术团队进行更深入的协作。
结语：真正的难点，是发现 AI 还不知道自己缺什么
为什么专家能够自然地完成普通人觉得复杂的任务？ 一个重要原因是，他们掌握了支撑判断的知识，也知道需要获取哪些数据和信息。 当这些条件充分具备时，许多看似复杂的判断就会变得相对简单。
AI 也有类似之处。 对于一部分专业任务，只要提供正确的数据、信息和知识，通用模型就可能完成过去需要专业人员处理的工作。当然，具体效果仍然受到模型推理能力、任务复杂程度、工具可靠性等因素的影响。
问题在于，我们不能假设这些条件已经存在于企业现有文档中。 也不能指望 AI 仅靠检索现有资料，就一定能够识别所有未知的知识缺口。 真正需要建设的，不只是让 AI 获取上下文的工程能力，还包括从任务出发，发现、分析和建构所需上下文的能力。 这是人类业务专家、知识管理人员和 AI 技术人员需要共同完成的工作。
上下文工程使 AI 能够更有效地使用知识；上下文需求分析和知识建构，则努力确保 AI 获得完成任务真正需要的知识。 只有两者结合，AI 才更有可能从能够回答问题，走向能够可靠完成复杂业务任务。
