这段时间，AI 编码领域开始频繁出现一个词：Harness Engineering。
如果只看字面，它很容易被误解成又一个新概念，或者某种“Prompt Engineering 2.0”的包装词。但我越来越觉得，它之所以值得单独拿出来讲，不是因为名字新，而是因为它抓住了一个很现实的变化：
AI 编码的竞争，正在从“谁更会写提示词”，转向“谁能给 AI 提供更稳定的执行环境”。
也就是说，问题已经不只是“模型会不会写代码”，而是：
- 它有没有清楚的规则入口
- 它能不能读取到足够准确的上下文
- 它写完之后有没有验证机制
- 它出错之后能不能快速暴露并修回来
- 它积累下来的经验，能不能变成长期有效的工程资产
这篇文章想系统整理一下我目前对 Harness Engineering 的理解：它是什么、为什么最近越来越重要、它和 Prompt / Context / Spec 这些概念是什么关系，以及一个项目到底是怎么从“AI 写得很爽”走到“AI 能稳定交付”的。
一、Harness Engineering 到底是什么？
如果用一句话来定义：
Harness Engineering = 给 AI Agent 搭一个可执行、可验证、可修复、可长期治理的工程环境。
这里最关键的不是“让 AI 生成更多代码”，而是让 AI 在真实项目里工作时，处在一个不容易跑偏、跑完能自检、出错能定位、长期不会越用越乱的系统里。
所以它强调的不是一次 prompt 的技巧，而是围绕执行过程建立闭环：
- 有规则约束
- 有上下文入口
- 有验证反馈
- 有错误修复路径
- 有长期治理机制
换句话说，Harness Engineering 关注的不是“怎么让 AI 回答更聪明”，而是“怎么让 AI 在工程环境里表现得更稳定”。
二、为什么它最近突然变重要了？
原因其实很直接。
前一阶段，大家更关注模型能力本身。只要模型变强，很多人都会自然认为：AI 编码的问题主要会被更强的模型解决。
但实际用久了之后，很多团队和个人都会碰到同样的现实：
同一个模型，换一套更好的工作环境，效果提升往往比单纯换模型更明显。
这说明瓶颈已经在变化。
以前的问题更像是：
- AI 听不懂
- AI 写不出来
- AI 表达不够像样
现在更常见的问题则变成：
- AI 能写，但容易偏
- AI 能改，但容易把别的地方带坏
- AI 能干活，但缺少稳定反馈回路
- AI 用得越多，仓库反而越乱
- review 负担越来越重，团队经验无法沉淀
这时候你就会发现，真正限制结果的，不只是模型，而是整个系统设计。
三、它和 Prompt / Context / Spec 是什么关系？
我比较喜欢把这几个概念放在一条演进线上看。
1. Prompt Engineering：怎么说
Prompt Engineering 解决的是： 怎么跟 AI 说，才能让单次输出更准。
它很重要，但更像是单回合优化。对于复杂、长期、跨文件、跨工具的任务，单靠 prompt 很难兜住整个过程。
2. Context Engineering：给什么信息
Context Engineering 更进一步，关注的是： 给 AI 什么上下文，以及在什么时候给。
这让 AI 不再只是对一句话做反应，而是能在更完整的信息环境中工作。
但它本质上仍然偏输入侧。它改善了 AI 的理解能力，却不天然解决执行过程中的约束、验证和修复问题。
3. Spec-Driven Development：先把事情写清楚
Spec-Driven Development 解决的是： 在开始实现之前，把目标、边界和验收标准写清楚。
这对减少歧义、提高协作效率非常有效。它解决的是“做什么”更明确的问题。
但即便 spec 写得再清楚，也不代表执行过程天然稳定。
4. Harness Engineering：让执行环境稳定下来
Harness Engineering 解决的是： 怎么给 agent 搭一个真正能长期运转的执行系统。
它不是替代 prompt、context 或 spec，而是把这些能力放进一个更完整的工程框架里。
如果用最通俗的话说：
- Prompt：怎么说
- Context：给什么信息
- Spec：先把目标写清楚
- Harness：让整个执行环境稳定下来
所以我更愿意把 Harness Engineering 看成：
把 prompt、context、spec 这些局部能力，升级成一个可长期运行的工程闭环。
四、Harness 的核心组成是什么？
如果把它拆开来看，我觉得一个靠谱的 harness，至少应该包含下面五块。
1. 规则入口
首先，AI 不能靠“猜”来工作。
你得给它明确的入口，告诉它：
- 先读什么
- 项目结构怎么理解
- 什么规则不能碰
- 哪些文档是 source of truth
这类入口常见的形式包括：
AGENTS.md- 架构文档
- 产品说明
- 编码规范
- 模块边界说明
- 任务模板
这一步的价值是让 agent 不要每次都从零开始摸仓库。
2. 验证体系
如果没有验证，AI 写完就停，那整个系统几乎一定会失控。
所以第二块一定是验证闭环，比如：
- lint
- test
- build
- CI
- 类型检查
- 合约校验
验证体系的本质，不是为了形式完整，而是为了把“看起来像对的”变成“经过机制确认过的”。
3. 架构护栏
很多 AI 代码问题，并不是语法错，而是结构错。
比如：
- 跨层依赖乱引
- 同类逻辑出现多套实现
- API 返回结构被悄悄改坏
- UI 模式越写越不统一
所以你需要的不只是测试，还需要架构层的护栏，例如：
- import 边界规则
- API contract
- UI pattern 文档
- 目录职责约定
- 模块依赖约束
这决定了 AI 是在一条清晰跑道上跑，还是在一个到处都能拐弯的场地里乱窜。
4. 反馈系统
AI 要能稳定工作，反馈必须清楚，而且最好是“适合 agent 阅读”的。
比如一条失败信息，如果只是：
build failed
那几乎没什么用。
但如果它能告诉 agent：
- 哪个文件
- 哪一类错误
- 预期是什么
- 可能的修复方向
那 agent 自修的成功率会明显提高。
所以 Harness 的一部分，其实是在设计： 失败是如何被暴露和表达的。
5. 长期治理
这是最容易被忽略的一块。
很多团队前面四步都做了，但用久了之后仓库还是越来越乱。原因就在于缺少长期治理。
比如：
- 文档没同步更新
- 旧规则失效但没人清理
- 重复实现逐渐增多
- review 里反复出现同类问题
- 临时 workaround 变成永久遗留
所以 harness 不是一次性工程，而是一种持续治理机制。它通常需要：
- 周度清理
- 文档对齐
- 季度回顾
- 高频 review 意见规则化
- 针对仓库熵增的定期处理
五、一个项目是怎么从 Vibe Coding 走向 Harness 的？
要理解 Harness Engineering，最好的方式不是讲定义，而是看一个常见演进过程。
很多项目一开始都是典型的 Vibe Coding：
- 需求想到就说
- AI 写完看一眼能跑就过
- 没有统一规则入口
- 没有系统验证
- 一开始速度很快，体验甚至相当爽
问题往往不是一开始出现的，而是在项目稍微长大之后。
第一阶段：爽，但不稳
早期确实很快。
因为几乎没有额外成本：不写规范，不建验证，不补文档，直接让 AI 开始干。
但随着功能增加，典型问题会逐渐冒出来：
- 同类逻辑出现多套版本
- 页面和交互风格开始飘
- API 返回结构偶尔被改坏
- 修一个地方，另一个地方又出问题
- review 越来越像人工兜底
这时候就会发现，问题已经不是“AI 会不会写”，而是“系统撑不撑得住”。
第二阶段：补最小规则入口
通常最先补的是最基础的规则文档，例如：
AGENTS.mdarchitecture.mdproduct.mdcoding-rules.md
这一步做完后，最明显的变化是：
- agent 开始知道先看什么
- 任务边界更清楚
- 跑偏频率下降
- 输出风格开始有一致性
第三阶段：接上基础验证
接下来要做的不是继续优化 prompt，而是把验证体系接起来：
- lint
- test
- build
- CI
一旦这套东西存在，开发过程就从：
写完就停
变成：
写完先验，失败再修
这一步非常关键，因为它把“生成”变成了“闭环执行”的一部分。
第四阶段：把高频问题沉淀成规则
很多 review 意见其实高度重复。
如果每次都靠人提醒，那团队会越来越累；但如果能把高频问题沉淀成规则，整个系统就会越用越顺。
比如逐步补充：
- import 边界规范
- UI patterns
- API contracts
- 常见任务模板
- 错误说明规范
这一步之后，review 才会开始从“低级兜底”转向“方案判断”。
第五阶段：加上清理和回顾
真正成熟的阶段，不只是能做功能，而是能控制熵增。
这时通常会加入：
- 周度清理任务
- 文档对齐
- 季度回顾
- 失败案例复盘
- 仓库健康检查
到这里，项目才算真正从“AI 提效”进入“AI 工程化”。
六、怎么判断 Harness 有没有开始起作用？
我觉得可以看几个非常朴素的信号。
如果 AI 用得越来越多，但同时：
- 仓库没有越来越乱
- review 没有越来越重
- 相同问题没有反复靠人肉提醒
- 团队经验能持续沉淀进系统
- agent 的首轮成功率在逐步提高
那基本可以说明 harness 开始起作用了。
反过来，如果模型越来越强，但项目却越来越依赖“有经验的人在最后擦屁股”，那通常说明 harness 还不够成熟。
七、个人和小团队应该怎么开始？
很多人一听到 Engineering、治理、体系这些词，就会觉得这是不是只有大团队才需要。
我反而觉得不是。
因为越是小团队、越是个人项目，越需要一个轻量但清晰的 harness。否则 AI 带来的不是效率，而是额外混乱。
一个现实可行的起步方式，大概是：
1. 先补最小入口
至少把这些东西补上：
- 一个
AGENTS.md - 一个最小的项目说明
- 一份简明的编码规则
- 一份架构或目录职责说明
2. 接最基本的验证
不必一上来搞得很复杂，但至少要有：
- lint
- build
- 必要的测试
3. 把高频 review 问题写下来
不要总靠记忆，也不要每次都重复口头说。
把它们逐步沉淀成：
- 文档
- 规则
- 模板
- 脚本
- CI 检查
4. 定期做一点清理
哪怕不是很正式，也最好有节奏地做：
- 删重复实现
- 补漏掉的文档
- 清临时方案
- 回看哪些问题最近最常出现
一个最小可用 harness，不需要一开始就很重。关键是它要能形成闭环。
八、Harness Engineering 的本质，不是“更会用 AI”
说到底，Harness Engineering 真正重要的地方，并不是让工程师显得更懂 AI，也不是发明一个新的 buzzword。
它的价值在于，它把大家的关注点从：
- 模型参数
- 提示词技巧
- 一次性输出效果
转向了更本质的问题：
- 规则是否清楚
- 验证是否存在
- 反馈是否有效
- 系统是否能长期稳定运转
所以我现在越来越倾向于这样理解它：
Harness Engineering 的本质，不是更会让 AI 写代码，而是更会设计一个让 AI 稳定工作的工程系统。
这件事一旦想明白，很多判断标准都会变得清楚。
你就不会再只盯着“这次生成得像不像”，而会更关注：
- 这个系统有没有变得更稳
- 这个仓库有没有变得更可维护
- 这套经验能不能被复用
- AI 的使用是不是在放大团队能力，而不是放大混乱
九、结语：AI 编码的下一阶段，是工程化而不是玄学化
我不觉得 Harness Engineering 是一个替代一切的新词。
它更像是一个提醒： 当 AI 真正进入开发流程之后，决定效果上限的，已经越来越不是单条 prompt，而是整个执行系统。
Prompt、Context、Spec 当然还重要，但如果没有 Harness，它们更像是一些分散的局部优化。
只有当这些能力被放进一个可执行、可验证、可修复、可治理的环境里，AI 才会从“偶尔很惊艳”变成“长期可依赖”。
这也是为什么我觉得，AI 编码的下一阶段，不是玄学化，而是工程化。
从这个角度看，Harness Engineering 其实并不神秘。
它只是让我们开始认真回答一个问题：
当 AI 真正参与软件开发时，我们到底该给它一个什么样的工作环境？