本文核心观点：Harness Engineering（驾驭工程）不是新概念，而是把Prompt Engineering、Context Engineering、Vibe Coding整合在一起的系统化实践——核心是让AI在正确的约束下发挥最大价值，而不是放任它自由发挥。

核心要点：

Harness Engineering本质是给AI套上"缰绳"，让它从野马变成能拉车的役马

它整合了提示词工程、上下文工程、氛围编程等多种实践

核心工具包括：CLAUDE.md角色定义、hooks检查点、知识库上下文、skills权限控制

设计Harness需要大量与AI协作的实践经验，不是理论能教的

未来开发者的核心竞争力从"写代码"转向"设计AI协作系统"

Vibe Coding都还没学完，Prompt Engineering的课还在卖，Context Engineering的墨迹还没干。

现在又来一个Harness Engineering？

AI圈造新词的速度，快赶上模型迭代了。

但当我读完OpenAI和Anthropic的原文，反应变了。不是"哇好新"，是：等等，这不就是我过去半年一直在干的事吗？

一、Harness Engineering到底是啥？

Harness，英文原意是马具、缰绳。

不是马本身，是套在马身上让它能拉车、能被引导的那整套东西。

没有它，马就是一匹乱跑的野马，力气再大也白搭。

把这个概念搬到AI领域，Harness Engineering就是：给AI设计一套约束和引导系统，让它在正确的边界内发挥最大价值。

具体来说，包括这几个核心组件：

1. CLAUDE.md——给AI立规矩

告诉AI它是谁、什么规则必须遵守、什么风格必须保持。

就像你带新员工，先得让他知道公司文化、工作流程、红线在哪。

2. Hooks——在关键节点设检查点

在AI工作的关键路径上插入检查逻辑。

不是等它做完再改，而是在做的过程中就引导和纠偏。

3. 知识库——给AI准备决策上下文

AI不是全知全能的，它需要相关信息才能做出好决策。

知识库就是给AI准备的"参考资料"，让它有据可依。

4. Skills——定义AI的能力和权限

AI能用什么工具、有什么权限、能访问什么资源，都需要明确定义。

这不是限制AI，而是让它知道"什么能做、什么不能做"。

二、这不是新概念，是旧实践的整合

说实话，上面这四件事，我自己做了半年，从来没觉得需要一个统一的名字。

写CLAUDE.md，告诉AI我是谁、什么规则必须遵守。

配hooks，在agent关键节点注入检查。

建知识库，给AI准备决策需要的上下文。

调skills，定义AI能用什么工具、有什么权限。

然后OpenAI发了篇博文说这叫Harness Engineering。

Mitchell Hashimoto发了篇博文也说这叫Harness Engineering。

Anthropic发了两篇工程文章，Martin Fowler写了长文分析，大家都这么叫。

行，那就叫Harness Engineering。

名字不重要，重要的是这套方法确实有效。

三、Harness Engineering vs 写代码的经验

这里有个有意思的讨论。

Martin Fowler在文章里表达了一个担忧：Harness Engineering会不会让开发者失去写代码的能力？

他的逻辑是：如果大家都在设计Harness而不是写代码，那传统的编程经验是不是就没用了？

我得对自己诚实。

我能设计Harness，不是因为我天生懂系统设计。是因为我在和AI协作的上千小时里，观察到了它的行为模式。

它什么时候偷懒，什么时候幻觉，什么时候需要硬约束而不是温柔提醒。

这些判断力不来自写代码的经验，但来自另一种经验：和AI反复较劲的经验。

问题是，这种经验能教吗？

我自己说不清楚。

我知道CLAUDE.md该怎么写，但让我教别人为什么这么写，我会卡住。很多决定是直觉做的，直觉来自踩坑，踩坑来自大量重复，大量重复来自时间。

这和老程序员说"你写几万行代码自然就懂了"其实是一回事。

所以问题可能不是"写代码的经验"能不能被替代。而是：不管你积累的是什么经验，足够多的经验本身就是设计Harness的前提。

没有捷径，换了个赛道而已。

也许Martin Fowler担心的不是"没人写代码了"，而是"没人愿意花够多时间踩够多坑了"。

这个我也不确定。留给你想。

四、对普通开发者意味着什么？

如果你是个普通开发者，看到这里可能会问：这跟我有什么关系？

关系很大。

第一，你的工作内容会变化。

以前你的主要工作是写代码实现功能。

以后你的主要工作可能是：设计AI怎么帮你实现功能，然后在关键节点检查和修正。

代码还是要看，但写代码的时间会减少。

第二，你需要的技能会变化。

技术能力当然还是基础，但更重要的是：

系统设计能力——怎么把复杂任务拆解成AI能理解的步骤

产品思维——怎么定义"好"的标准，让AI知道什么时候算完成

调试能力——AI出问题时，能快速定位是Prompt问题、上下文问题还是权限问题

第三，竞争门槛会变化。

以前会写代码就能干活。

以后会设计Harness才能高效干活。

这个转变不会一夜发生，但已经在发生了。

五、写在最后

Harness Engineering不是什么革命性的新概念。

它是Prompt Engineering、Context Engineering、Vibe Coding这些实践的自然演进和系统整合。

就像软件开发从"写代码"进化到"工程化"一样，AI协作也在从"试Prompt"进化到"系统化设计"。

这个过程中，有人焦虑，有人兴奋，有人观望。

但不管你怎么看，变化已经在发生了。

与其纠结名字，不如开始实践。

从写一个CLAUDE.md开始，从配一个hook开始，从整理你的知识库开始。

做得多了，自然就懂了。

你怎么看Harness Engineering？你觉得它会让开发者失业，还是让开发者更强？

欢迎在评论区聊聊你的观点，觉得有用的话记得转发给还在纠结的朋友。