让 AI 从"看起来完成"到"确定完成"：我的 Harness 工程起点

📋 本篇导读

01 假性完成：AI 编码最大的坑是什么

02 Harness 是什么：把不确定性变成确定性

03 三阶段演进：从打通链路到复盘回环

PROBLEM

01 假性完成：AI 编码最大的坑

Vibecoding 已经这么流行了，Harness 工程也学了皮毛。但实际自己还是没有真实搭建一个能够实现端到端交付的 AI Native 环境。

自己使用 AI 还处于 IDE/CLI 一问一答式的帮助完成开发工作。在实践的过程中遇到最大的问题是：AI 能帮你工作，但是完成的结果都不是很理想。这应该也是很多人会遇到的问题。所以搭建一个适合自己的 AI Native 环境已经必须了，让 AI 真正助力你提效。

· · ·

UNDERSTANDING

02 对 AI 完成工作的认识

在搭建这样的 Harness 框架前，必须对 AI 完成工作有 2 点认知：

1. AI 能完成所有开发人员能做的事情。

2. AI 完成工作只是看起来完成，实际对错是不确定的。

如果老板问你：AI 现在这么厉害了，为什么还需要 Harness？我的回答会是：AI 是很厉害，可以完成任何工作，但是 AI 的完成是不确定的，它会出现“假性完成”。所以需要外层的约束或规范让 AI 更确定地完成工作。

Harness 工程 == 让 AI 确定性的工程。

· · ·

APPROACH

03 搭建 Harness 的整体思路

搭建 Harness 工程框架是个复杂的工程，不可能一步到位完成所有的工作。所以我的建设思路基本和其他人都是一样：先从最小且最简单的链路打通，再逐步演进。

Harness 工程本身包含Rule、Skill、Sub-Agent、Workflow 等多个层次，所以要避免搭建一个“过度工程”。从最小最简单开始，还能够适当调整按需搭建适合自己使用，乃至团队使用的框架。

从最简单的 Prompt，到学会用 Rule 约束 AI，再到建立自动化信任，每一步都要求团队改变与 AI 的协作方式。另一方面，这也是让你学习和适应AI 工程化思维的过程。

基本步骤

1. 确认一个正常端到端的交付链路：需求文档 → 需求评审 → 技术方案 → 技术方案评审 → 代码实现 → 功能测试 → 合并代码发布测试环境 → 验证功能 → 发布正式

2. 将每个节点都作为一个 Agent，只负责对应的功能

3. 主 Agent 中编排以上流程

4. 开始简单需求任务

三阶段演进路线

第一阶段 · 打通链路

目标：让整个流程能跑通，不管结果对不对

把整个链路先打通，不用管最终结果是否正确。Harness 工程其实是个确定性工程，所以在第二阶段开始逐个过程增加规则或约束，让 AI 输出的结果往正确的方向约束。

第二阶段 · 增加约束

目标：让每个节点的输出往正确方向靠

逐个过程增加规则或约束。但是 AI 即便在规则约束下，还是可能会因为规则不严谨导致出现差错。

第三阶段 · 复盘回环

目标：让 AI 自己检查、自己修正

接入复盘回环阶段，让 AI 自己检查、自己复盘、自己升级。就这样一步一步演进升级，到最后实现开发运维全自动闭环。

· · ·

EPILOGUE

04 写在最后

回到开头那个问题——“假性完成”是 AI 编码最大的坑。AI 能帮你写代码，但写出来的东西“看起来完成了，实际上不确定”。Harness 工程解决的就是这个问题：把不确定性变成确定性。

这篇文章是我的起点——交代了为什么搭、解决什么问题、整体思路是什么。接下来我会逐篇拆解具体怎么搭的：目录结构怎么设计、规则怎么写、Hook 怎么配、命令怎么封装。以及在这个过程中，我对 Harness 工程的理解是怎么一步步加深的。

如果你也在用 AI 编码，也遇到了“假性完成”的困扰，可以跟着这个系列一起探索。

我是高级葡萄Ya，技术写作是写你渴望理解但尚未完全理解的事情。

疯狂输出：这是2026年第 6 篇文章。

如果你觉得今天这篇有收获，欢迎 点赞、在看、转发 三连，我们下篇见