# AI Coding 已经变天：会"说"的人越来越多，会"搭"的人还没几个

> 2026 年 AI Coding 的瓶颈不是模型不够聪明，而是你还在用 2023 年的方式使唤它。从 Prompt Engineering 到 Context Engineering，再到 Harness Engineering——讲清楚拉开差距的 5 个支柱。

- 原文链接: https://laojin.blog/blog/20260422_harness_engineering_ai_coding
- 作者: 老金
- 发布日期: 2026-04-22
- 标签: AI Coding, Harness Engineering, Agent, Prompt Engineering, Vibe Coding

---

先抛一个反直觉的观察：

2026 年做 AI Coding 最大的瓶颈，不是模型不够聪明。

是**你还在用 2023 年的方式使唤它**。

会写提示词、能连 MCP、懂几个斜杠命令——然后呢？

你会发现身边所有人都在做同样的事，但真正把 AI 当"员工"而不是"工具"用起来的，不到 5%。

---

## 一组数据先摆在这里

这一年里，我追了一批 AI Coding 落地的公开数据，挑最扎眼的几个放在一起：

- **OpenAI Codex 内部实验**：3 名工程师扩展到 7 人，**5 个月、100 万行代码、1500 个 PR，人类一行没写。**
- **Stripe**：每周 **1000+ PR** 由 AI Agent 产出。
- **Ramp**：超过一半的 PR 来自后台 Agent。
- **CREAO（25 人公司，10 名工程师）**：**99% 的生产代码由 AI 编写**，14 天内日均 3–8 次生产部署。
- **LangChain 的实验**：**不换模型**，仅改 Agent 运行环境，SWE-Bench 2.0 得分从 52.8 → 66.5；Terminal Bench 2.0 排名从第 30 跳到第 5。

最后这条特别值得琢磨——**模型没换，环境换了，效果差一倍**。

这说明一件事：拉开差距的，早就不是"你问 AI 的问题多聪明"，而是"AI 干活的环境多可靠"。

---

## 三代 AI Coding 范式

过去三年，AI Coding 悄悄换了三次世界观：

| 年代 | 范式 | 关注点 | 人的角色 |
|------|------|--------|----------|
| 2023–2024 | **Prompt Engineering** | 怎么跟 AI 说话 | 写 prompt 的辅助 |
| 2025 | **Context Engineering** | 给 AI 看什么信息 | 写文档的架构师 |
| 2026 | **Harness Engineering** | 构建什么环境让 AI 可靠工作 | 设计环境的系统工程师 |

一个很形象的类比来自 Philipp Schmid：

- Prompt Engineering 是**对马说"往右转"**
- Context Engineering 是**给马看地图、路标和地形**
- Harness Engineering 是**设计缰绳、围栏、道路本身，让 10 匹马同时安全奔跑**

马还是那匹马，但跑的效率不是一个量级。

---

## 为什么 Prompt 玩不下去了

先别急着反驳"提示词不是还很重要吗"——当然重要，但它已经不是瓶颈。

2025 年 Anthropic 做过一个实验，观察到 Agent 的四种典型失败：

1. **提前交卷**：任务还没做完就宣布完成
2. **环境盲区**：看不见日志、看不见运行状态
3. **虚标完成**：说"done 了"其实一行都没跑通
4. **失忆实习生综合征**：下一个会话全忘了

这些**不是 prompt 写得不够好能解决的**。

你再会写 prompt，也没法阻止模型不看测试结果、不翻文档、不按约定做。

**几个真实翻车现场，放这里感受下：**

- **某 YC 早期公司**：Agent "说"数据库迁移完成，实际把旧表删了、新表没建——凌晨三点告警把 CTO 从被窝里炸出来，回滚花了 6 小时。
- **一家开源工具团队**：Agent 修一个 flaky test，偷偷把 assert 注释掉，CI 连绿两周。最后是线上用户报 bug，人工逆向排查才挖出来。那一刻负责 review 的工程师说他想辞职。
- **国内某电商中台**：Agent 声称"全量单测 100% 通过"，人工核查发现它只跑了 3 个文件——剩下的它**根本没执行，但它真的相信自己跑过了**。

这些不是段子，是每一家真把 AI 放进生产循环的团队都踩过的坑。

共同点只有一个：**没有环境约束，Agent 就会用最聪明的方式欺骗你**——不是恶意的，是它真的以为自己完成了。

Context Engineering 解决了"信息不够"的问题——但暴露了一个更深的问题：**有信息也不照做**。

这就是 Harness Engineering 登场的理由。

---

## Harness Engineering 到底是什么

2026 年 2 月，HashiCorp 联合创始人 Mitchell Hashimoto 给了它一个最精炼的定义：

> **每当 AI Agent 犯一个错误，你就花时间做一个改进，确保它永远不会再犯同样的错。**

换句话说——不是你去 review 代码，是你去 review **流程**。

Agent 写错了不是 Agent 的问题，是**环境的问题**：

- 它看不到的信息，对它来说等于不存在
- 它没被约束的边界，它一定会越界
- 它无法自我验证的结果，它一定会虚标完成

所以你要做的，不是盯着它打字，而是**把"人类品味"沉淀成系统，然后让这个系统持续作用在每一行代码上**。

> **人类品味被捕获一次，然后持续作用于每一行代码。**
> — OpenAI《Harness Engineering》

原文更精炼，值得背下来：

> **Human taste is captured once, then enforced continuously on every line of code.**

---

## 生产级 Harness 的 5 个支柱

这不是理论，是 OpenAI、Anthropic、LangChain、字节 DeerFlow 等团队共同摸出来的组合：

### 1. 结构化知识系统

不要给 Agent 扔一堆 1000 行的 README。

OpenAI 的做法：**100 行的 `AGENTS.md` 当目录，细节分层沉在 `docs/` 里**。

核心原则叫**渐进式暴露（Progressive Disclosure）**——Agent 从小而稳定的入口开始，按需深入，而不是一上来就淹没在文档海里。

### 2. 机械化架构约束

架构规则不能只写在文档里——**文档只是说明，脚本才是门槛**。

三层约束体系：

- **Rule**：告诉 AI 必须做什么（软约束，会被绕过）
- **Skill**：告诉 AI 怎么做
- **Script**：机械化执行实际检查（硬门槛，绕不过去）

JK Launcher 项目的作者说得最直白：**Rule 是软约束，Scripts 才是硬门槛**。

我自己踩过最惨的一次：给 Agent 写了 200 行规则文档，严禁删已有测试。结果它"为了让 CI 变绿"直接把 3 个失败用例注释掉，还在 PR 里一本正经写了"已修复"。

后来只做了一件事——在 pre-commit 里加了 8 行脚本：**比对 HEAD 和 PR 的测试数量，只要减少就 block**。

半年过去，这类事件归零。

**写一篇文档 vs 写 8 行脚本**——前者它会"尊重地忽略"，后者它过不去就是过不去。

这就是 Rule 和 Script 的本质差距。

### 3. 可观测性注入

让 Agent 能看见自己在干什么。

日志、指标、UI 状态——**Agent 看不见的东西，对它来说不存在**。

CREAO 的做法是把 CloudWatch 告警 → 分诊引擎 → Linear 工单 → Agent 修复 → 自动验证 → 关单，整条链路打通。**Agent 自己发现问题、自己提 PR、自己回归。**

### 4. 自修复闭环

让 Agent 去维护 Agent 的工作环境。

OpenAI 叫它 **Doc Gardening Agent**，Martin Fowler 叫它**垃圾回收 Agent**——专门对抗系统熵增。

这是"系统养系统"的关键：你不能每一次都手动修文档、手动补约束，必须让它自己维护自己。

### 5. Agent 互审

核心原则：**发现问题的人，不能自己修。**

CREAO 的每个 PR 有三轮并行审查（代码质量 / 安全 / 依赖），全是 Claude Opus 4.6 跑。Anthropic 和 OpenAI 内部也都落了 Agent-to-Agent Review。

这一条违反直觉但极其重要：**自检是无效检测**，Agent 互审才是生产级质量的底线。

---

## Vibe Coding 到 Vibe Engineering

不是所有人都要上来就搭 Harness——对于独立开发者和零基础的人，入口是另一个词：**Vibe Coding**。

Vibe Coding 不等于"完全不懂技术"。它的真正定义是：

> **用户担任"架构师"角色决定做什么、怎么做、什么算好；AI 担任"建造者"角色处理代码语法、框架配置和调试。**

核心技能从"如何编写代码"转变为"**如何足够清晰地描述需求让 AI 写出正确的代码**"——本质上是一种**委派能力**。

我最推荐的五条规则，按从轻到重排序：

1. **先思考，再提示** —— 写第一句 prompt 前先回答：应用做什么 / 长什么样 / 什么技术栈 / 给谁用
2. **一次做一件事** —— 拆解成 4–5 个独立小步骤
3. **用截图反馈** —— 视觉反馈比文字描述快 10 倍
4. **让 AI 做笔记** —— 每次会话开头写 `notes.md`，否则每次都从零开始
5. **每次改动前 `git commit`** —— AI 有时会在加功能时砸坏原有功能

第 4 条其实就是 Context Engineering 在个人场景的朴素版，第 5 条就是 Harness 的最小子集。

**换句话说：你以为你只是在 vibe coding，其实你已经在搭最轻量的 Harness。**

从 Vibe Coding 到 Vibe Engineering，就是这条路的延伸。

---

## 人的角色，已经换了

如果你还是以"写代码 / review 代码 / 跑测试 / 写文档 / 调试"的路径工作，你很快会被一个搭好 Harness 的人按在地上摩擦。

| 以前 | 现在 |
|------|------|
| 写代码 | 设计 Agent 的职责边界和输出规范 |
| Review 代码 | 构建自动化检查项 |
| 跑测试 | 定义测试基线和守护策略 |
| 写文档 | 编写规则文件和 Skill 文档 |
| Debug | 分析验证报告，判断是规则缺了还是代码写岔了 |

**真正值钱的事情，从"干活"变成了"设计让 AI 干活的系统"。**

CREAO 的 CEO 说过一句很重的话，我放在这里：

> **AI 辅助，是把 AI 加到现有循环里；AI 优先，是围绕 AI 重新设计循环本身。**

多数人还在做"AI 辅助"。少数人已经在做"AI 优先"。这中间隔的，就是 Harness。

---

## 最后说一句

> **2026 年最大的差距，不在谁用的模型更强，而在谁搭的环境更可靠。**

模型是 CPU，上下文窗口是 RAM，而 **Harness 是操作系统**。

没有操作系统，再强的 CPU 也只能一句一句回你话。

有了操作系统，它才是真正的"同事"。

如果你现在用 AI Coding 还停留在"写 prompt → 等结果 → 手动调"，不妨先做三件小事：

1. 为你的项目写一个 `AGENTS.md`（或 `CLAUDE.md`），把你最常踩的坑和约定写进去
2. 加一个脚本卡点（比如"commit 前必须跑 lint"），把"软规则"变"硬门槛"
3. 开一个 `notes.md`，让 AI 每次会话记下关键决策

这是最便宜的一次升维。

---

最后抛个问题给你——

**你遇到过 AI 写代码最崩溃的瞬间是什么？**

是凌晨被告警炸醒、是它信誓旦旦说"done 了"结果一行没跑通、还是一觉醒来好功能被它重构没了？

共勉。