夜雨聆风2026年，随着OpenAI在博客中提出“驾驭工程”（Harness Engineering），这个概念迅速在AI圈内流行开来。然而，许多讨论仍停留在表面。要真正理解它，我们必须先厘清它与“提示词工程”（Prompt Engineering）和“上下文工程”（Context Engineering）的关系，以及它们各自解决的核心问题。
这三者并非相互替代，而是层层递进、互为补充的工程化范式，共同构成了我们驾驭大模型（LLM）的完整能力体系。
提示词工程（Prompt Engineering）：让模型“听懂话”
大模型本质上是一个基于海量参数、通过输入来预测下一个字词的概率引擎。如果你给它一个宽泛的指令，它的输出往往会天马行空，难以捉摸。
提示词工程，就是通过有意识地设计和调整我们的输入，来引导模型稳定地输出符合预期的内容和格式。它解决的，是模型“无引导乱说话”的问题。
核心手段：角色设定（“你是一名资深工程师”）、背景信息注入、输出格式限制（“请用JSON格式返回”）、提供示例（Few-shot）等。 典型场景：当你要求模型修改一段代码时，你会明确指示：“请只修改这个函数，保持原有代码风格不变，并提供完整的函数代码。”
简而言之，提示词工程是人与模型认知对齐的基础，它让模型明白“具体要做什么”以及“做成什么样”。
上下文工程（Context Engineering）：给模型“配个好秘书”
提示词只是我们发给模型的全部信息——即“上下文”（Context）——的一部分。大模型存在“上下文窗口”的限制，就像人的短期记忆有限一样。在多轮对话中，信息很容易将窗口“填满”，导致我们不得不压缩或丢弃旧信息，这可能引发“上下文腐化”，即模型“记不住”关键信息，回答前后矛盾。
上下文工程，就是动态管理大模型上下文的技术。它像一个高效的秘书，确保模型在任何时候都能获得最相关、最精简的信息。其核心流程包括：
召回（Recall）：从外部新闻、历史聊天记录、当前代码库、系统环境、报错日志等海量信息中，精准找出与当前任务最相关的部分。这背后涉及RAG（检索增强生成）、Memory（记忆）等关键技术。 压缩（Compression）：将召回的信息进行总结、提炼，减小其体积，以便能放入有限的上下文窗口中。 组装（Assembly）：按照影响模型理解的顺序（例如，越靠后的信息越容易被关注）重新组织内容，将最关键的指令和信息放在最佳位置。
不同的AI工具之所以在使用同一个模型时效果迥异，很大程度上就是因为它们的上下文工程策略不同。
驾驭工程（Harness Engineering）：为模型“装上四肢和缰绳”
提示词工程解决了“怎么说”，上下文工程解决了“看什么”，但模型依然只是一个“大脑”，缺乏主动执行任务的能力。它无法自己去运行代码、测试功能或管理项目文件。
驾驭工程，正是为了解决这个问题。它通过构建一个包裹在大模型之外的“工程外壳”，赋予模型执行、记忆、反馈和规划的能力，让它从一个“思想家”变成一个“行动派”。
这个“外壳”通常由四个核心层级构成：
执行层（Execution）：为模型接入操作外部工具的能力，如Bash命令行、沙箱环境、文件读写等。这让模型能够真正地“动手”操作，比如修改代码、执行测试命令。 记忆层（Memory）：通过规则文件（如 claude.md）来定义项目目标、技术栈、需求和禁止事项等。这些文件可以动态加载，确保核心信息始终存在于模型的视野中，减少理解偏差。反馈层（Feedback）：将模型执行操作后的结果（如测试输出、报错信息）重新注入上下文，驱动模型在下一轮循环中自动发现问题并进行修复，形成一个自我修正的闭环。 编排层（Orchestration）：将一个宏大的任务拆解为多个有明确执行标准的子任务，然后按步骤驱动Agent去执行，避免其陷入无效的死循环。
一个简洁的公式可以概括其本质：
Agent = 大模型 + 驾驭工程
驾驭工程就是除大模型本身之外的所有工程化部分。模型越强，这个“外壳”或许可以越薄，但它永远不可或缺。
驾驭工程的落地实践
以Claude Code为例，它原生就支持驾驭工程的四层能力。开发者可以在一个claude.md文件中清晰地定义项目背景、目标、禁忌和测试要求。此外，还可以引入像Speck Kit这样的插件，它能按阶段自动生成约束文件、制定开发计划、拆解任务，实现“规范驱动开发”（SDD）。
在这种模式下，程序员的工作内容发生了根本性转变：从亲手“写代码”，转向了为AI“写规则”和定义“技能”（Skill）。
三者关系总结
提示词工程：让大模型明白具体需求和输出标准。 上下文工程：给大模型注入精准有效的上下文信息。 驾驭工程：让大模型能够持续按规范执行任务并最终交付。
从提示词到上下文，再到驾驭工程，我们正见证着AI开发从“与模型对话”的艺术，走向“为模型设计系统”的工程科学。
