3.338. 一些Harness编程实践的悖论
其实我认为Harness对于Vibe Coding是个很好的形容。因为本质上，我们希望利用AI的“主动性”，但不希望它越过限制。这会对应两种意向：
圈养：我们设定一个固定的范围，范围内自由活动，范围外不能逾越。
上挽具（Harness）：我们自己的智能一直没有离开，但通过不断判断更新控制边界，让马的能力释放出来。
很明显，Vibe Coding更对应后面这种具象。
而我说的悖论，是看到现在有些所谓Harness的实践似乎一直尝试用圈养的方式设计控制方法。他们设定复杂的目录结构，工作流，Skill……他们觉得这些是Harness，但很明显，这些手段是“圈养”，不是Harness。因为你的智能没有进入，你圈好了空间，你对这些都不思考了，就等着AI自己能搞定输出，这不是在“策马”，而是在“圈养”。
（注：我这里不是说设定工作流或者写Skill本身不对，这些方法确实是Harness的“挽具”本身，我说的是你尝试“完善”这些东西去让你的脑子“退出”，认为你不是在Harness那匹马，而是把一个强调“认识”的过程，变成了一个“逻辑计算”的过程。）
这其实涉及思考和程序的区别。思考是基于隐层的推理和判断（对无限信息的个人“认识”），程序是基于token的逻辑计算。哲学一点，前者是维特根斯坦的“在沉默中传递”的信息，后者是维特根斯坦的“逻辑”。
程序员写一个程序：y = a+b+c。想到y“应该”等于a+b+c，这是基于隐层的判断，而CPU执行y=a+b+c，这是纯粹的逻辑运算，换一个（种）CPU执行，这个结果都是一样的。但换一个程序员，可能根据条件，会做出判断：y = a+b（比如可能c其实对y的作用有限），甚至认为：我们不应该计算这个y，它和我们的目的无关……这些判断是基于他对现实的“认识”，而不是基于逻辑。
我们Vibe Coding主要不是需要AI的逻辑计算能力，而是AI的认识能力。我们骑马并不想控制马蹄怎么落地，而是希望我们控制马走哪条路，而马根据路径选择马蹄怎么落地。
所以，你希望用一个不经过你思考的过程去控制马怎么跑，这个方向从一开始就是缘木求鱼。AI正确输出缺的就是两个东西：你的确切目的；面对复杂局面抓住主要矛盾的能力。你不去补上这个短板，希望用一个死板的方法去控制它具体怎么走完那条曲折的道路，就好比你骑马过一片沼泽，你不去看路，尝试写一套Checklist给马，说你遇到水就走左边，遇到草甸就走上去……这套逻辑只会越加越多，而这些逻辑其实慢慢还会变成训练语料的一部分，马早知道了，但知道了也没用，它还是在面对多个要素的时候不知道把哪个作为重点，所以，你说这种形式的所有Harness，是不是自己玩自己？
我觉得，走向这个方向，还是因为很多人其实并不理解编程是什么。编程是创造，不是生产。工人用固定的方式重复同一个逻辑，在流水线上反复产生衣服，杯子，U盘。但程序员并不在反复生成Windows，Office，MySQL……他们是在“创造”生产线，不是自己生成生产线所生产的那个目标。他们生产一次Android，实际在执行Android的输出的，是每个Android的用户和他的手机上的CPU。
所以编程的时候（无论是传统Coding还是Vibe Coding），程序员每个时刻都是在审视面对的复杂局面，然后自己开始绕过这片或者驱使马匹绕过这片……沼泽。他是要审视以后才决定怎么Harness他的马的，而那些通过一组流程和Skill尝试Harness AI的，其实不是在Harness AI，而是尝试Harness程序员，只是那些过去尝试用CMM流程Harness外包程序员的失败者们的阴魂不散罢了。