从“提示词工程”到“驾驭工程”：AI应用开发范式的一次认知升级
2026 年开年以来，一个叫 Harness Engineering（驾驭工程）的概念迅速席卷整个开发者社区。本文用费曼学习法，讲清提示词工程与驾驭工程的区别、联系与各自的适用场景。
一、两条协作路径的对比
在 AI 工程实践中，人与模型的协作存在两条典型路径：
- 驾驭工程（Harness Engineering）的工作流：定义目标与验收标准 → 拆解任务 → 子代理执行 → 用标准检查结果。
- 提示词工程的工作流：提出问题 → AI 回答 → 不满意继续补充 → AI 继续回答。
两者的差异表面上看只是流程步骤不同，背后却是两种工程哲学的分野：前者是先建规则再放行，后者是先跑起来再看效果。沿后者作业时，通常要反复改措辞、加示例、调格式；一旦任务稍微复杂，就容易陷入“改了这里崩了那里”的循环。
由此引出三个需要回答的问题：提示词工程和驾驭工程的区别到底是什么？它们是一个替代另一个的关系吗？还是各自解决的是不同层面的问题？
本文结合 OpenAI、Anthropic 等团队的官方工程博客与相关工程实践整理而成。
二、提示词工程：把话说清楚的艺术
2.1 核心定位
提示词工程（Prompt Engineering）的本质，是优化人与模型之间的交互接口。其核心问题是：如何把任务表达清楚，才能让模型给出期望的结果？
主流技术手段包括角色设定、Few-shot 示例、思维链（Chain-of-Thought）引导、输出格式约束等。所有技巧都围绕同一个目标：在单次交互中，通过优化措辞与示例来提升输出质量。
2.2 能力边界
提示词工程在简单任务上非常有效——起草邮件、生成摘要、一次性格式转换、创意头脑风暴，这些场景下精心设计的提示词确实能带来质的提升。
其局限同样明显：单次交互、无状态、高度依赖个人经验。每次任务都需要人工触发；模型无法记忆历史对话之外的项目上下文；话术稍有偏差，输出就可能跑偏；出错只能修改提示词重试，无法根治同类问题。
换言之，提示词工程解决的是“听懂”的问题，解决不了“持续可靠”的问题。
三、驾驭工程：把系统管稳的能力
3.1 核心定义
驾驭工程（Harness Engineering）是 2026 年 2 月由 HashiCorp 联合创始人 Mitchell Hashimoto 正式命名的工程实践。其原始定义是：
“每当发现 Agent 犯了一个错误，你就花时间设计一个解决方案，使得 Agent 在未来不会再犯同样的错误。”
OpenAI 随后在其官方工程博客中给出了一个更具工程化色彩的公式：
Agent = Model + Harness
这里的 Harness 指的是模型之外的一切：系统提示词、工具调用接口、文件系统与沙箱环境、编排逻辑与中间件、反馈循环与约束机制、观测与评估体系。用一个形象的比喻来说，如果模型是 CPU，Harness 就是操作系统——无论 CPU 多强大，如果操作系统频繁崩溃，实际体验依然很差。
3.2 与提示词工程的根本区别
两条路径的差异可归纳如下：
| 维度 | 提示词工程 | 驾驭工程 |
|---|---|---|
| 解决的问题 | “这句话怎么说？” | “怎么让它永远不犯这个错？” |
| 作用范围 | 单次交互 | 整个系统生命周期 |
| 失败模式 | 单次输出质量差 | 长期质量退化 |
| 实现方式 | 调措辞、加示例 | 搭约束、建反馈、自动化 |
| 可维护性 | 手动、per-task | 自动、持续 |
一个关键的认知转变是：提示词工程优化的是输入话术，而驾驭工程优化的是运行系统。通俗地说，提示词工程是“对马喊话的技巧”，驾驭工程是“给马造一条高速公路，配上护栏、限速牌和加油站”。
四、为什么现在需要驾驭工程？
4.1 一组关键数据
以下几组实验数据很有说服力：
安全研究员 Can Boluk 发现，同一个模型，仅仅改变 Agent 的文件编辑接口调用方式，编码基准分数就从 6.7% 直接跳到 68.3%。模型没变，上下文没变，连 Prompt 都没变。
LangChain 在 Terminal Bench 2.0 上只改了 Agent 运行环境（文档结构、验证回路、追踪系统），排名从全球第 30 位升到第 5 位，得分从 52.8% 提升到 66.5%。
OpenAI 内部实验：3–7 人的团队，5 个月生成 100 万行生产级代码，合并 1500 个 PR，零行人工编写。
这些数据指向同一个结论：当模型能力达到一定水平后，系统设计才是效果的主要瓶颈。
4.2 人类注意力成为新瓶颈
在 OpenAI 的百万行代码实验中，工程师团队发现了一个反直觉的问题：AI 产生代码的速度远远快于人类验证代码的速度。如果 AI 实现的某项功能不符合要求，工程师就不得不陷入“对话 → 等待修复 → 再次验证”的循环中，精力被消耗殆尽。
这意味着，人类 QA 已经取代模型能力，成为开发流程中最窄的那个瓶颈。
驾驭工程要解决的核心痛点，不仅是 AI 持续工作的稳定性，更是人在 AI 时代的“注意力稀缺”。
五、驾驭工程的核心构件
综合 OpenAI、Anthropic 等一线团队的实践，驾驭工程通常包含以下几个核心组件：
第一，机器可验证的完成契约。 “完成”不再是一个模糊的概念，而是必须包含输出格式、工具使用、停止条件和验收方法的明确契约。任务开始前，先和评估者协商清楚“什么叫做完了”。
第二，版本化的知识记录系统。 知识必须离开聊天窗口，进入可发现、可维护、可验证的记录系统。OpenAI 在实践中发现，一个巨大的 AGENTS.md 文件注定失败——上下文是稀缺资源，过多的指导反而变得无效。
第三，强约束优先于提示词约束。 能用确定性约束（lint、type check、沙箱、CI 硬失败）的地方，永远不要依赖提示词。如果一条规则可以用代码强制执行，就不应该只写在提示词里。
第四，自愈循环。 Agent 必须能从环境中获得“地面真相”，能自我评估、能自我修正、能在失败后从检查点恢复。Anthropic 的实证研究表明，Agent 能否成功解决问题的关键，强相关于它能否验证自己的工作。
第五，熵管理与垃圾回收。 定期运行的 Agent 负责扫描过时文档、发起修复 PR，持续小额偿还技术债务，而非让债务累积。
六、从提示词工程到驾驭工程的过渡路径
从工程实践看，这一过渡通常经历三个阶段。
第一阶段（提示词工程） ：在 Cursor 等工具中编写小脚本或做原型开发时，用的就是提示词工程——打开对话框、描述需求、查看输出，不满意就补充说明。该阶段完全够用，效率很高。
第二阶段（引入上下文管理） ：项目变大之后，每开一个新对话都要重新解释项目结构、编码规范、依赖关系，非常低效。此时改用 .cursorrules 或 AGENTS.md 文件来沉淀这些信息，即相当于从提示词工程过渡到了上下文工程。
第三阶段（尝试驾驭工程） ：更进一步的变化是，不再让 AI“自由发挥”，而是在系统提示词中明确加入“规划 → 构建 → 验证 → 修复”的结构化工作流指导；同时在项目中设定严格的目录边界，Agent 只能在指定范围内修改文件。虽然尚未达到 OpenAI 那种“零人工编写”的水平，但 AI 输出的稳定性已有明显提升——至少不会再把代码写到错误的目录里。
一个关键结论是：驾驭工程不是要放弃提示词工程，而是要把提示词工程的成果“固化”到系统中。那些反复验证有效的指令，不应该每次都靠人手动输入，而应该成为系统的一部分。
七、总结
提示词工程的路径是线性的、反应式的——出问题就修提示词，再出问题再修。驾驭工程的路径是系统化的、前馈式的——先定义好目标和验收标准，再让 Agent 在约束下执行，最后用标准检查结果。
两者不是替代关系，而是嵌套关系：提示词工程是驾驭工程的一个组成部分；驾驭工程在提示词工程的基础上，叠加了约束、检测、反馈和持续改进机制。
用一句话概括：提示词工程教你如何跟 AI 说话，驾驭工程教你如何给 AI 设计一个能稳定干活的环境。
对于仍在用提示词工程的开发者而言，不必焦虑“过时”——在简单任务和原型阶段，提示词工程仍然是最有效率的工具。但当 AI 协作开始涉及多步骤、长周期、跨会话的复杂任务时，就到了从“改话术”转向“搭系统”的时候。