什么是 Harness/

在此之前，请允许我先用一个真实的小案例，给大家讲清楚，到底什么是 Harness。

如果这个概念前面不对齐，后续则无法深入到企业场景内的 Harness 实践，越到后面大家只会更加懵逼。

假设我们现在让 AI 去做一个媒体账号。

给它的前置系统提示词是：

“你的人设是宝妈，目标是涨粉，核心指标是每篇帖子的阅读量、互动量和关注转化。”

AI 收到这个提示词以后，就开始干活。

它很快发布了一篇帖子：

💬 “我家孩子 3 个月，但是不爱吃母乳怎么办？”

然后配了两张图。

到这里，AI 已经完成了两个动作：

前置，执行。

接下来进入第三步：

反馈。

帖子发出去 1 小时后，AI 去看数据，发现阅读量很低。

按照新账号起号的逻辑，一篇正常内容至少应该有上百阅读，但这篇只有几十。

于是 AI 开始复盘。

它发现，这篇内容太平了，没有足够强的吸引点。然后它把这个经验写进自己的经验库：“内容过于平淡，容易导致阅读量偏低。”

下一次发帖时，这条经验会重新进入它的前置说明里。

于是 AI 的新提示词就变成了：

“你的人设是宝妈，你的任务是发布帖子吸引用户关注和评论。你的核心指标是涨粉量和每篇帖子的阅读量。

历史经验：上一篇帖子因为内容过于平淡，阅读量很差。下次需要提高标题和内容的吸引力。”

然后 AI 又开始执行。

这次它发了一篇更夸张的：

💬 “天塌啦！我家孩子每天能吃一头牛怎么办！快养不起了，呜呜。”

这篇发出去以后，数据确实很好。

1 小时内有 1 万阅读。

但是问题来了。

1 小时后，帖子被封了。

原因是：传播夸大事实的信息。

这时候 AI 又开始复盘。它发现，夸张标题确实能带来流量，但如果夸大事实，就很容易被平台判违规。

于是经验库里又多了一条：

夸张表达可以提升点击，但不能脱离事实，否则容易被封。

现在，AI 的经验库里已经有两条经验：

第一，内容太平淡，没有流量。

第二，夸大事实虽然有流量，但容易违规。

于是第三次发帖时，AI 开始调整策略。

它不再写平淡内容，也不再硬夸张，而是换成真诚路线：

💬 “做辣妈的第三年，我是如何一边带娃，一边保持状态的？”

这篇内容戳中了很多宝妈的真实痛点。

结果，帖子爆了。

AI 看到数据以后，发现这条路线有效，于是继续把经验写回去：

真诚表达真实痛点，更容易获得稳定流量。

到这里，一个很小的运营闭环就出现了。

前置、执行、反馈、经验沉淀，再回到前置。

这就是 Harness 的核心。

它不是让 AI 单次完成一个任务，而是让 AI 在一个系统里持续变好。

当然，刚才这个例子只是为了方便理解，真实系统要复杂得多。

比如：

AI 拉到帖子数据以后，怎么判断这篇帖子是正常、偏差，还是爆了？

AI 复盘的时候，怎么对标同类账号，而不是只看自己的感觉？

AI 发现某个策略有效以后，怎么判断它是长期有效，还是只是碰巧踩中了流量？

这些问题，才是搭建 Harness 系统真正难的地方。

也就是说，Harness 的关键不只是“让 AI 干活”。

而是要给 AI 搭一套闭环：

任务怎么定义，过程怎么执行，结果怎么评估，经验怎么沉淀，下次怎么复用？

这才是 Harness 的核心。

/企业级 Harness 实战/

能看到这里的，想必已经对什么是 Harness 已经没有异议了。

那么接下来我们开始介绍本文的重点：企业级的 Harness Coding 实战应该怎么去做？

在真实的开发任务里，这个闭环会复杂很多。

因为写代码不是发一条帖子。

真实开发里有需求理解、架构边界、代码规范、接口契约、测试验证、日志排查、评审验收、多人协作。

任何一个环节没管住，AI 都可能开始偏航。

所以，如果我们想让 AI 真的参与企业级开发，不能只写一句：

“你是一个资深研发工程师，请帮我完成这个需求。”

这不叫 Harness。

这叫把一个非确定性的模型，直接扔进生产代码里裸奔。

真正的 Harness Coding 系统，至少要回答几个问题：

1. AI 开始写代码前，它从哪里理解需求？

2. 它依据什么项目规则做判断？

3. 它能不能自己查架构规范，而不是反手问人？

4. 它写完以后，谁来验证？

5. 验证失败以后，怎么回到正确轨道？

6. 这次踩过的坑，下次怎么不再踩？

这才是 Harness 架构要解决的问题。

而对于 AI Coding 的场景，这套架构则最少要有如下三层：

1. 人类需求层。

2. 工程契约层。

3. 代码执行层。

/第一层，人类需求层/

这一层解决的是：人类到底想要什么。

很多 AI Coding 失败，不是模型写不出代码，而是一开始需求就没有被说清楚。

人类在聊天窗口里随口说一句“帮我加个 X 接口”，AI 就开始实现。它看起来很勤奋，实际上很危险。

因为它不知道这个接口的业务边界是什么，不知道哪些字段必须兼容旧系统，不知道异常场景怎么处理，也不知道验收标准是什么。

所以在我们的 Harness 里，第一步不是让 AI 写代码。

第一步是让人类先把需求落成一个可以被交接的文档。

这个文档不需要写得像论文，但必须说清楚几件事：

这个需求为什么要做。

这次到底做什么，不做什么。

输入输出是什么。

业务流程是什么。

验收标准是什么。

这一步非常关键。

因为 Harness 的第一条原则就是：

人类负责想清楚方向，AI 负责把方向翻译成工程动作。

如果人类自己都没想清楚，AI 只会把不确定性放大。

/第二层，工程契约层/

当人类需求写清楚以后，也不能马上进入代码实现。

中间还需要一层翻译。

因为人类需求通常是业务语言，而代码实现需要工程语言。

比如人类说：

新增一个校验能力，失败时要给前端异常提示。

这句话对业务方来说够了，但对工程实现来说还不够。

AI 需要继续把它翻译成：

改哪个模块、新增什么接口、错误码怎么定义。

测试要覆盖哪些场景、哪些架构规则不能破坏、做到什么程度才算完成。

这一层，就是工程契约层。

在这一层里，AI 可以起草设计方案、任务拆分、接口契约和验收标准，但人类必须 Review。

注意，这里不是人类逐行写设计文档，而是人类把关：方向对不对、边界有没有漏、验收标准是否可验证。

这个阶段的核心产物，不是代码，而是一份“写代码前的工程合同”。

它告诉后面的实现 Agent：你要交付什么、不能越过什么边界、交付后用什么证据证明完成。

/第三层，代码执行层/

只有前两层都对齐以后，AI 才能进入代码实现。

这一层才是真正的 Coding Agent 干活区。

但即使到了这里，也不是让一个 Agent 从头写到尾，然后自己宣布“完成了”。

我们需要把角色拆开。

一个负责规划。

一个负责实现。

一个负责评估。

并且还要有两个不同维度的评估器。

为什么？

因为同一个 AI 自己写、自己测、自己夸自己，很容易护短。

它会觉得：差不多了、应该没问题、这个边界场景可以不测。

这在真实工程里很危险。

所以我们要让实现者和评估者隔离。

实现 Agent 负责写代码和测试。

评估 Agent 负责站在外部视角审查它。

机器检查负责跑编译、单测、静态扫描、覆盖率。

人类负责最后看方向和关键证据。

这套分工听起来复杂，但本质很简单：不要让一个非确定性模型同时当运动员和裁判。

到了这里，一个企业级 Harness Coding 系统的基本骨架就出来了。

它不是一个 Prompt。

它是一条流水线：