AI Coding 已经变天：会"说"的人越来越多，会"搭"的人还没几个
2026 年 AI Coding 的瓶颈不是模型不够聪明，而是你还在用 2023 年的方式使唤它。从 Prompt Engineering 到 Context Engineering，再到 Harness Engineering——讲清楚拉开差距的 5 个支柱。
先抛一个反直觉的观察：
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 的四种典型失败：
- 提前交卷：任务还没做完就宣布完成
- 环境盲区：看不见日志、看不见运行状态
- 虚标完成：说"done 了"其实一行都没跑通
- 失忆实习生综合征：下一个会话全忘了
这些不是 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 写出正确的代码"——本质上是一种委派能力。
我最推荐的五条规则，按从轻到重排序：
- 先思考，再提示 —— 写第一句 prompt 前先回答：应用做什么 / 长什么样 / 什么技术栈 / 给谁用
- 一次做一件事 —— 拆解成 4–5 个独立小步骤
- 用截图反馈 —— 视觉反馈比文字描述快 10 倍
- 让 AI 做笔记 —— 每次会话开头写
notes.md，否则每次都从零开始 - 每次改动前
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 → 等结果 → 手动调"，不妨先做三件小事：
- 为你的项目写一个
AGENTS.md（或CLAUDE.md），把你最常踩的坑和约定写进去 - 加一个脚本卡点（比如"commit 前必须跑 lint"），把"软规则"变"硬门槛"
- 开一个
notes.md，让 AI 每次会话记下关键决策
这是最便宜的一次升维。
最后抛个问题给你——
你遇到过 AI 写代码最崩溃的瞬间是什么？
是凌晨被告警炸醒、是它信誓旦旦说"done 了"结果一行没跑通、还是一觉醒来好功能被它重构没了？
共勉。