Prompt Engineering已死，2026年最值钱的技能叫Harness Engineering

OpenAI有个团队，7个人，5个月，用Codex写了100万行代码。人工编写比例：0%。人工review比例：0%。合并了1500个PR，平均每人每天3.5个。他们没有用什么秘密模型，用的是和你一样的Codex。区别在于——他们写了88个AGENTS.md文件。

2026年2月5日，HashiCorp联合创始人、Terraform发明者Mitchell Hashimoto发了一篇博客，标题是《My AI Adoption Journey》。在文章的第五步，他写下了一个新术语：

Harness Engineering（驾驭工程）。

6天后的2月11日，OpenAI的Ryan Lopopolo在官方博客发表了《Harness Engineering: Leveraging Codex in an Agent-First World》，给出了一个经典公式：

Agent = Model + Harness

又过了几周，Martin Fowler在他那个做了20年的博客上发了一篇长文，把Harness Engineering的理论体系彻底打通。

从命名到定义到框架，总共用了不到一个月。 这可能是AI领域"从概念到共识"最快的一次收敛。

今天这篇文章，把这个2026年最重要的工程概念讲透。

一、为什么Prompt Engineering不够用了？

先说一个扎心的事实。

你精心调试了2个小时的prompt，让Claude完美地完成了一个任务。你很开心。然后你把同样的prompt用在第二个任务上——它又犯了同样的错误。

因为Prompt Engineering解决的是"单次交互"的问题，而Agent需要解决的是"持续可靠"的问题。

用Mitchell Hashimoto的原话定义：

"Anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again." ——每当你发现Agent犯了一个错误，你就花时间设计一个方案，让它永远不会再犯同样的错误。

这不是在调prompt，这是在建系统。

二、概念辨析：Prompt vs Context vs Harness

2026年有三个"Engineering"概念满天飞，容易搞混。让我一次性说清楚。

Prompt Engineering（提示工程）——"怎么说"

2022-2024年的主角。核心问题：这句话怎么措辞，才能让模型给出最好的回答？

技巧包括：Few-shot示例、Chain-of-Thought、角色扮演、输出格式约束。

Context Engineering（上下文工程）——"给什么"

2025年6月，Shopify CEO Tobi Lutke 发了一条推特：

"I really like the term 'context engineering' over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM." ——我更喜欢"上下文工程"而非"提示工程"。它更准确地描述了核心技能：为LLM提供所有必要上下文，使任务有可能被解决的艺术。

一周后，Karpathy跟帖+1：

"+1 for 'context engineering' over 'prompt engineering'. In every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window with just the right information for the next step." ——在每一个工业级LLM应用中，上下文工程是用恰到好处的信息填满上下文窗口的精微技艺。

核心问题：给模型看什么信息，才能让它理解任务并正确执行？

技巧包括：RAG检索、工具调用结果注入、对话历史管理、记忆系统。

Harness Engineering（驾驭工程）——"怎么防"

2026年2月的主角。核心问题：怎么让Agent在长期运行中保持可靠、可维护、可改进？

技巧包括：AGENTS.md约束文件、自定义Linter、结构化测试、CI管道、生命周期Hook、自动化纠错机制。

三者的关系：Harness > Context > Prompt。

Prompt是一句话，Context是一个信息包，Harness是一整套系统——包含了Context和Prompt，但还加上了约束、检测、反馈和持续改进机制。

用Martin Fowler的话说：Harness之于Model，就像操作系统之于CPU。CPU很强大，但没有OS的调度、权限管理和错误处理，它什么有用的活都干不了。

三、Martin Fowler的Harness框架：Guides + Sensors

Martin Fowler的文章给了Harness Engineering一个优雅的分类体系：Guides（引导）和Sensors（传感器）。

Guides（前馈控制）——事前预防

在Agent行动之前，通过文档、规范、约束来引导它的行为。

Sensors（反馈控制）——事后检测

在Agent行动之后，通过检测工具发现问题并触发修正。

Fowler把Sensors分成两类：

计算型传感器（确定性、毫秒级）：

• 类型检查器（TypeScript tsc）
• Linter（ESLint、Pylint）
• 单元测试 / 集成测试
• 自定义结构化测试（"controllers/目录下的文件不能import models/"）

推理型传感器（非确定性、较慢）：

• LLM作为代码审查员（"AI审AI"）
• 视觉回归截图对比
• 语义一致性检查

关键洞察：先上计算型传感器。 它们快、准、便宜。推理型传感器作为补充，不要作为主力。

三种Harness类型

Fowler进一步把Harness分成了三类：

四、OpenAI的实战案例：100万行代码，0%人工编写

OpenAI的Ryan Lopopolo团队用Codex构建了一个生产级应用，留下了迄今为止最极端的Harness Engineering案例。

关键数据

1500个PR，没有人工review，全部由自动化Harness保障质量。 这句话值得反复读。

他们怎么做到的？

第一招：6层架构约束

他们把代码库分成6层，每一层只能依赖下面的层：

 1  UI层（React组件）
 2      ↓ 只能调用
 3  Runtime层（运行时状态管理）
 4      ↓ 只能调用
 5  Service层（业务逻辑服务）
 6      ↓ 只能调用
 7  Repo层（数据访问仓储）
 8      ↓ 只能调用
 9  Config层（配置管理）
10      ↓ 只能调用
11  Types层（类型定义）

这些约束不是写在文档里让Agent"遵守"的——而是通过自定义Linter硬编码成了检测规则。Agent一旦越层调用，CI直接失败。

第二招：88个AGENTS.md文件

不是一个大而全的文件，而是88个分布式指令文件。每个子组件、每个模块都有自己的AGENTS.md，只包含该模块相关的约束。

为什么不用一个文件？因为OpenAI发现：单个全量文件"可预见地失败了"——它挤占了任务相关的上下文空间。

"Context is a scarce resource."——上下文是稀缺资源。

第三招：渐进式信息披露

顶层AGENTS.md只有~100行，充当"目录"，指向结构化的docs/目录。Agent需要什么信息，按需去读，而不是一次性全部塞进上下文。

核心哲学

"Human taste is captured once, then enforced continuously on every line of code." ——人类的品味只需捕获一次，然后在每一行代码上持续执行。

这就是Harness Engineering的终极目标：把人的判断标准固化成自动化规则，让Agent在没有人类监督的情况下也能产出高质量代码。

五、量化证据：同一个模型，换套Harness，效果差10倍

说到这里，可能有人会问：Harness真的有这么大影响吗？

数据说话：

Can.ac的实验最震撼。 同一个模型、同样的权重、同样的任务——唯一的变量是Harness。准确率从6.7%飙到68.3%。

这意味着什么？意味着在2026年，模型选择已经不是第一重要的事了。你怎么用它，比你用哪个模型重要10倍。

六、Karpathy的CLAUDE.md：16万Star的"驾驭手册"

Andrej Karpathy在2026年1月发布了一份CLAUDE.md文件，基于他从"80%手写代码"到"80%Agent生成代码"的实战经验，提炼了4条核心准则。

这份文件被开源社区整理成了GitHub仓库，截至2026年5月已有16.1万Star，成为年度增长最快的开源项目之一。

四条准则

准则1：编码前先思考（Think Before Coding）

明确陈述你的假设。不确定就问。有多种解释就列出所有选项。

准则2：极简优先（Simplicity First）

不加未要求的功能。不为一次性代码创建抽象。50行能搞定的，不要写200行。

准则3：外科手术式修改（Surgical Changes）

只改请求涉及的代码。不要顺手重构周围的代码。保持diff最小化。

准则4：目标驱动执行（Goal-Driven Execution）

不要告诉AI做什么，给它成功标准。LLM特别擅长循环直到满足目标。

Karpathy的关键洞察：

"Don't tell it what to do, give it success criteria and watch it go." ——不要告诉它做什么，给它成功标准，然后看着它自己跑。

这4条准则让AI编码准确率从65-70%提升到了91-94%。

七、实战指南：怎么搭建你的Harness？

7.1 第一步：写好你的指令文件

这是成本最低、效果最立竿见影的Harness组件。

 1  # CLAUDE.md (或 AGENTS.md / .cursorrules)
 2  
 3  ## 项目概述
 4  本项目是一个供应链管理系统，使用 Node.js + React + PostgreSQL。
 5  
 6  ## 架构规则
 7  - src/controllers/ 只能调用 src/services/，不能直接访问 src/models/
 8  - 所有数据库操作必须通过 src/repositories/ 层
 9  - 前端组件不允许直接调用 API，必须通过 src/hooks/ 层
10  
11  ## 编码规范
12  - 使用 TypeScript strict mode
13  - 函数名使用 camelCase，类名使用 PascalCase
14  - 错误处理：业务异常用自定义 AppError，系统异常直接 throw
15  - 不要添加未要求的功能、注释或类型注解
16  
17  ## 测试规则
18  - 每个新函数必须有对应的测试
19  - 测试文件放在 __tests__/ 目录，命名为 *.test.ts
20  - 使用真实数据库连接，不要 mock
21  
22  ## 常见错误（每条都是踩过的坑）
23  - ❌ 不要在 controller 中直接写 SQL
24  - ❌ 不要使用 any 类型
25  - ❌ 不要把环境变量硬编码在代码中

7.2 第二步：搭建计算型传感器

// .claude/settings.json — 生命周期Hook配置 
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "command": "npx eslint --fix $FILE && npx tsc --noEmit"
      }
    ],
    "PreCommit": [
      {
        "command": "npm test -- --bail"
      }
    ]
}

每次Agent写完代码，自动跑Lint和类型检查。每次提交前，自动跑测试。Agent犯的错在提交之前就被拦截了。

7.3 第三步：建立"错误→规则"的反馈循环

这是Harness Engineering最核心的实践：

 1  Agent犯错
 2    ↓
 3  你发现了
 4    ↓
 5  分析根因：是缺少约束？还是缺少检测？
 6    ↓
 7  如果是缺少约束 → 更新 CLAUDE.md
 8  如果是缺少检测 → 添加 Linter规则或测试
 9    ↓
10  Agent永远不会再犯同样的错误

Mitchell Hashimoto的原则：每一个Agent错误都是改进Harness的机会。 不要只是修复这次的错误，而是要确保这类错误永远不会再发生。

7.4 第四步：Eval驱动开发

搭建一套评估基准，持续衡量Harness的效果：

 1  # 从真实失败案例中收集20-50个任务
 2  # 每次修改Harness后，跑一遍eval
 3  # 跟踪通过率变化
 4  
 5  eval-results/
 6  ├── baseline.json       # 基线：无Harness，通过率62%
 7  ├── v1-agents-md.json   # 加了CLAUDE.md，通过率78%
 8  ├── v2-linter.json      # 加了Linter hook，通过率85%
 9  ├── v3-arch-tests.json  # 加了架构测试，通过率91%
10  └── v4-eval-driven.json # Eval驱动迭代，通过率94%

八、开发者角色的转变：从写代码到写规范

Gartner预测，到2026年底，75%的开发者将把更多时间花在编排和架构上，而不是写代码上。

Harness Engineering推动了一个根本性的角色转变：

OpenAI的总结最到位：

"Humans steer. Agents execute." ——人类掌舵，Agent划桨。

你的价值不再是"写得一手好代码"，而是"搭得一手好Harness"。

写在最后

2026年的AI工程圈有一句话越来越流行：

"The model is the engine. The harness is the car." ——模型是发动机，Harness是整辆车。

没有人会买一台裸发动机然后期望它自己开到目的地。但大量团队正在做的事情就是——拿着一个裸模型，扔给它一句prompt，然后期望它产出生产级代码。

Harness Engineering不是一个新技术，它是一种工程纪律。 它要求你：

1. 每发现一个Agent错误，就固化一条规则
2. 每增加一个约束，就配套一个检测
3. 每次迭代，都用Eval来衡量效果

Mitchell Hashimoto、OpenAI、Martin Fowler、Karpathy——这些人在2026年2月几乎同时指向了同一个方向。这不是巧合，而是整个行业到了这个阶段的必然收敛。

模型能力趋同后，Harness就是你的护城河。

同一个Claude Sonnet，你用得好是94%准确率，用得差是6.7%。差距不在模型，在Harness。

2026年最值钱的技能，不是会调prompt，不是会选模型，而是——会搭Harness。

我是RiemannChow，一个在架构领域摸爬滚打多年的技术人。如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。关注「老周聊架构」，每周深度解读AI和架构的最新趋势。