你正在决定用什么取代企业 AI 堆栈中的 Prompt Engineering。这里才是真正的答案。
你正在决定是否继续投资于 Prompt Engineering（提示工程）培训，或是否应该围绕供应商最近称之为「Context Engineering」（情境工程）的新学科重新组织你的 AI 能力。这个决定非常关键——预算、招聘、组织架构、供应商选择，全部围绕它而转。以下，是这个词真正的含义、为什么 Anthropic、OpenAI 及顶尖企业 AI 团队现在将它视为策略级工作单位，以及如何围绕它建立你 2026 年的 AI 能力。
本文不会要求你放弃 Prompt Engineering。它会向你展示：Prompt Engineering 只是一个更大学科下的子集——而只在提示层进行优化的企业，是在优化错误的变量。
什么是 Context Engineering（情境工程）？
Context Engineering 是一门学科，专门设计 AI 模型在推理时所见的完整信息环境——提示、检索到的文件、工具输出、对话历史、系统指令及元数据——使模型能为特定业务任务产出可靠、高质量的结果。Anthropic 将其定义为 Prompt Engineering 的自然进化：不再着眼于「找到正确的字眼」，而是「什么样的情境配置，最有可能产生我们想要的行为」。
这个转变并非语言学上的，而是结构上的。Prompt Engineering 将输入视为使用者精心撰写的单一文字串。Context Engineering 将输入视为一个经过工程化的系统——被筛选、版本控制、检索、压缩、评估——并在模型每次运行时流入模型之中。
对企业领袖而言，实际意义在于：你不再是聘请那些文字功夫了得的人。你是在建设一套基础建设，在规模化、可审计、每一次都如此的情况下，于正确时刻、为正确任务，组装出正确的情境。
为什么 Context Engineering 取代了 Prompt Engineering 成为策略性概念？
2025–2026 年间，三股力量交汇，使 Context Engineering 成为主导学科。第一，情境窗口由 8,000 个 token 扩大到 100 万个——问题已不再是「如何把我的请求塞进提示」，而是「我要用什么填满这 100 万个 token」。第二，AI 代理（AI Agent）成为正式生产系统，而代理会进行多次模型呼叫、情境持续演化——静态提示会失效。第三，检索增强生成（RAG）与工具使用成为预设——提示本身，如今只占到达模型内容的极小部分。
根据 Anthropic 工程团队，Context Engineering 引入了五个情境必须满足的质量标准：相关性（只放任务需要的信息）、充分性（足以在无需猜测下作答）、隔离性（任务之间无渗漏）、经济性（以最少 token 传递最大讯号），以及可追溯性（每一项事实都可追回来源）。
任何未明确处理这五个标准的 2026 年首席信息官 AI 策略，基础都是不稳的。只对提示质量评分的供应商评估，评估的是已过时的层级。
Context Engineering 在企业 AI 系统内部实际如何运作？
正式投产的 Context Engineering 系统，具备四个在每次 AI 请求运行时协同运作的层级。理解这四层，是领袖判断供应商究竟是真正在做 Context Engineering、还是只是为旧版提示脚本换新包装的方法。
--- 第一层：检索。系统从内部知识来源——政策文件、CRM 记录、产品目录、过往对话——通过向量嵌入上的语义搜寻抽取相关情境。这一层决定了模型是否拥有作答所需的事实。
--- 第二层：工具整合。模型被赋予以结构化方式存取业务系统的能力——查询数据库、呼叫 API、建立记录。工具输出会再回馈到下一次模型呼叫的情境中。
--- 第三层：指令设计与记忆。系统提示、角色定义、行为约束，以及对过往互动的长期记忆。这一层定义了这个 AI 是谁、在这项特定任务上应如何表现。
--- 第四层：评估与可观测性。每一次情境组装都被记录。输出会按质量标准评分。产生失败的情境模式被标记并修订。缺少这一层，其他三层会在不知不觉中随时间退化。
若供应商声称在做 Context Engineering，却无法在正式环境中展示这四层，其实只是包装得较好的提示范本。
Context Engineering 与 Prompt Engineering、RAG 有什么分别？
Prompt Engineering、RAG、Context Engineering 经常被混淆。清晰的划分是：Prompt Engineering 优化文字串。RAG 将文件检索进提示中。Context Engineering 则是把整个信息环境——包括提示、检索、记忆、工具、约束、评估——作为一个工程化系统来编排。
换句话说：Prompt Engineering 是一种技能。RAG 是一种技术。Context Engineering 是容纳两者的整体架构。当数字化转型总监评估一个企业 AI 平台时，问题不是「它是否支持 RAG」（每个平台都支持）。问题是这个平台是否提供一个连贯的框架，能在每日数千次 AI 互动中设计、版本控制、评估、治理情境。
这正是为什么 Deloitte 2026 年研究显示 75% 企业计划在两年内部署代理式 AI，但 KPMG 观察到这些部署「推进后又退缩」——将情境视为基础建设的机构成功；只将它视为提示文字的机构则不然。
Context Engineering 对你香港机构的 AI 预算意味着什么？
在实际预算层面，2026 年的企业 AI 堆栈，会把 60 至 70% 的实施支出，由模型授权转移到 Context Engineering——检索系统、评估框架、工具整合、可观测性。模型本身正变得商品化；包覆它的情境，正成为策略性资产。
对于中型香港企业（200 至 500 名员工），合理的第一年 Context Engineering 投资范围介于 80 万至 300 万港元，包含向量数据库基础建设、检索管道开发、评估工具，以及设计及维护系统的人才或伙伴。这不包含模型本身——模型逐渐成为按 token 计费的运营支出，而非资本开支。
常见的诱惑是跳过 Context Engineering，期望用更大的模型解决问题。2026 年的证据毫不含糊：即使是最强的前沿模型，在情境工程不佳时，也会产出不可靠的企业输出。每月花 5 万港元用最强模型却没有情境基础建设，正是机构对 AI 彻底失去信心的方法。
一个真正达到企业级水平的 Context Engineering 能力，是什么样子？
一个达到企业级水平的 Context Engineering 能力，会展现四个采购团队在供应商评估阶段就可验证的特征。第一，具名的检索来源：供应商能精确列出哪些内部文件、数据库、API 正在为情境供料。「我们的 LLM 会读取你的资料」是营销；有文件记录的来源清单才是工程。
第二，具可量度标准的评估准则：对来源的忠实度、完整性、安全性、任务特定准确度——每一项都有通过／失败门坎。第三，情境范本的版本控制：能像软件团队回退一次错误部署那样，回退一次情境更改。第四，可观测性：每一次 AI 互动都记录完整组装的情境，让失败可以被诊断，成功模式可以被复制。
若供应商无法在试点期间展示这四项，他们就尚未准备好进行企业级部署——不论他们挂的是哪款模型。
企业领袖采纳 Context Engineering 时最常犯的错误是什么？
第一个错误，是把 Context Engineering 当作可委派的技术细节。它不是。Context Engineering 是业务知识——定价规则、审批流程、政策诠释、客户情境——与 AI 层相遇的地方。若这一层没有业务端主人，AI 会在规模化运行下自信地犯错。
第二个错误，是过度塞满情境。更多情境，不等于更好情境。「以防万一」地把每一份文件都加进去，会降低模型效能，并大幅推高每次查询成本。Anthropic 的五个标准——相关性、充分性、隔离性、经济性、可追溯性——正是为了对抗这种本能。
第三个错误，是略过评估。团队部署了 Context Engineering 系统、看到漂亮示范、便宣告胜利。六个月后，漂移出现——文件过时、检索拖出陈旧记录、工具输出格式改变——AI 便悄然退化。持续评估是唯一防线。懂AI，更懂你 UD相伴，AI不冷——Context Engineering 残酷的现实，是工作永远不会「完成」，只会愈来愈受治理。
准备好建立你的 Context Engineering 能力？
Context Engineering 这一层，决定你 2026 年的企业 AI 投资会复利增长还是崩溃。UD 已陪伴香港企业走过 28 年，手把手带你完成每一步——由检索架构、评估框架设计，到 AI 劳动力部署、持续情境治理。没有提示范本式的表演，只有能让企业 AI 规模化下仍然可靠的基础建设。