你以为缺的是 Harness,其实可能连方向都还没有
大家都在搭 harness——测试/CI/review/guardrail。但有个更前置的问题被跳过了:你确定知道系统该往哪儿走?讲清方向(attractor)和围栏(harness)的真实关系——它们是双螺旋,不是先后。
大家都在搭 harness——测试、CI、review、guardrail。但有个问题被跳过了:你确定知道系统该往哪儿走吗?要是不知道,再密的围栏也只是在高效地把你推向一个错的终点。
这两年做 AI 辅助开发,一个词被反复念叨:harness。
测试、lint、CI、code review、自动校验、Agent 互审——它们都是在约束 AI 别越线。
但约束的前提是,你已经知道线在哪。
AI 大规模开发真正难的不是"怎么防越线",是"哪条路才是长期对的结构"。
下面要聊的就是这件事:方向(我后面叫它 attractor)和围栏(harness),哪个该在前。我会先把"方向优先"这个主张讲扎实——它对一半。然后讲它没说的另一半,那一半对独立开发者更要命。
"先搭围栏"是个隐藏的陷阱
主流工程方法论——TDD、DDD、Clean Architecture、code review 文化——评价的对象都是状态:
- 评价"这次 PR 对不对",不评价"过去 100 次 PR 累出来的方向对不对"
- 评价"当前架构清不清晰",不评价"架构在演化中是否在被推向稳定形态"
这套范式过去够用,因为人类工程师本身是个低频、带方向感的扰动源。一个人一天写几百行,每次改动小,脑子里还持续装着"我们大概要去哪"。状态层检查 + 人脑里的方向感,合起来保证系统不漂。
AI 把后半截抽走了。它不是"更快的程序员",是结构上完全不同的扰动源:
| 维度 | 人类工程师 | AI 协作 |
|---|---|---|
| 频率 | 低频 | 几分钟数百行 |
| 幅度 | 小,局部 | 一次跨模块结构变更 |
| 方向感 | 持续,跨天跨周 | 每个 session 独立,没有跨会话记忆 |
| 局部合理性 | 一般 | 接口/类型/测试/文档同时给出,单看每项都过检查 |
最后一行是命门。在 AI 协作里,所有状态层检查都能通过,系统整体可以一直在漂。
更隐蔽的是"自我验证陷阱":AI 在写代码的同时,把判断这段代码对不对的全部材料——类型、测试、文档、"已完成"总结——也一起写了。它们出自同一个上下文。如果这套理解从一开始就偏了,所有"证据"会一致地偏在同一个方向,彼此不矛盾,但整体是错的。
这时候你那套漂亮的 harness 在干嘛?它在忠实地、可审计地把系统拉向一个错误的稳定结构。
陷阱就在这:围栏只检查越没越线,不检查线画对了没有。
"方向优先"这个主张对在哪
于是有了一个反直觉的主张:
第一性的问题不是怎么约束 AI,是系统应该收敛到怎样的长期结构。
这个"系统反复被拉回的稳定结构",借用动力系统的词叫 attractor。它不是边界,也不是待办清单,更像一组高阶关系——职责怎么分、边界怎么立、哪些结构关系不能破。满足这些关系的实现,会自然落到同一个形态。
它跟"边界 / 护栏"有本质区别:
| 护栏 / 边界 | attractor / 方向 | |
|---|---|---|
| 回答的问题 | 什么不能做 | 系统该往哪长期收敛 |
| 违反的后果 | 立即报错 | 单次没事,持续偏离才让结构烂掉 |
| 作用层 | 执行层(每次动作被检查) | 方向层(多次动作累积是否靠拢) |
| 处理的核心 | 禁区 | 扰动下的稳定性 |
"扰动下的稳定性"正是 AI 协作的核心难题。AI 是高频高幅的扰动源,你要的不是它一次都不犯错,是它推开多远都能拉回正确结构附近。
这套主张点破了一个逻辑依赖:方向不定义,就没法判断轨迹漂没漂;轨迹漂没漂判断不了,围栏纠偏就没目标。
到这儿我是认同的。这确实是被大多数人跳过的第一性问题。
但它埋了一个雷,接下来掰扯的就是这个。
它埋的雷:方向真的能先验定义吗
整套"方向优先"逻辑,建立在一个没说出口的前提上:正确的 attractor 可以被先验定义——动手之前就有人知道系统该往哪收敛。
对一个已经成熟、有资深架构师坐镇、重写第二遍的框架,这个前提成立。
但对绝大多数真实场景——一个新产品、一个没人趟过的领域、一个独立开发者的 side project——根本不成立。
你不知道正确结构长什么样,这恰恰是你要动手的原因。
下面三件事是我认为这套理论真正的盲区。
方向是被发现的,不是被声明的
软件工程有条老智慧叫演化式架构,还有那句著名的 "worse is better":先做出粗糙但能跑的东西,让它在真实使用里长出形状。
为什么?因为对真正的新问题,最佳结构是涌现出来的,不是设计出来的。你脑子里想象的方向,跟系统实际想收敛到的方向,常常不是一回事。
想想你最近一次大重构。是什么时候你才意识到"哦,真实的结构应该是这样"?
大概率是你撞上了一堵墙——一组怎么改都过不去的测试,一个反复出 bug 的模块,一次牵一发动全身的改动。
暴露真实方向的,常常正是 harness 本身。
不是先验定义好的 attractor 提前告诉你"这里会漂",是你撞上了围栏才反推出系统真正想去的地方。
所以在新系统里,harness 不只是执行已知方向的工具,它是你发现方向的仪器。
更关键的是顺序:廉价的可逆性 + 快速反馈回路(这正是 harness 的本质)是你"承担得起判断错方向"的前提。你得先有便宜试错的能力,才敢去试那些你还不知道对不对的方向。
这个因果跟"先有方向"是反过来的——很多时候是先有围栏,才有资格谈方向。
过早定方向比没定更危险
第一节那句最锋利的话——没有方向的 harness 是在"高效固化错误基线"——我想原样还回去:
一个过早定义、被供奉成"架构铁律"的、自信的错误方向,固化错误基线的效率更高,也更隐蔽。
为什么更危险?因为它带权威。
一套没方向的围栏至少还在测量,还能暴露异常,团队还会嘀咕"我们是不是跑偏了"。一个被写成铁律、带最高优先级的错误方向,会让所有人停止怀疑方向本身——方向已经"定清楚了",剩下的只是执行。这时候 harness 越强,越是死心塌地把系统拉向错误终点。
前面讲的"自我验证陷阱"在这里放大了一个数量级:单个 AI session 的自我验证是局部的偏;一个错误的方向 + 一套强大的 harness,是整个工程组织一致地、勤奋地、可审计地朝错误方向收敛。
方向的杀伤力跟它的正确性成正比。定对了是北极星,定错了是黑洞。
而"先定方向"这个处方,对"你怎么知道自己定对了"几乎没给任何工具。
对独立开发者来说,这是何不食肉糜
这条最现实。
"方向优先"这套方法论最终依赖一件事:团队里得有个能定义正确方向的人。架构判断是稀缺资源。
那问题来了——如果你就是团队的全部,而你恰恰还没修炼出那种判断呢?
这是 99% 独立开发者和早期小团队的真实处境。你不是不想定方向,你是真的不知道。这领域你第一次做,这产品还没有用户告诉你它该长成什么样。
对这群人,"先定方向再搭围栏"是一句正确但无用的话——等于告诉一个迷路的人:"你应该先知道目的地。"
| 方向优先 适合 | 围栏优先 适合 | |
|---|---|---|
| 项目阶段 | 成熟、第二次重写 | 探索期、第一版 |
| 领域 | 走过、有先例 | 全新、无人趟过 |
| 团队 | 有资深架构师 | 独立开发者 / 新手 |
| 你对正确结构的把握 | 高 | 低,或为零 |
| 该先投资什么 | 把架构判断写成铁律 | 把试错成本压到最低(测试、CI、git、可回滚) |
对右边这一列人,够得着的围栏比够不着的方向值钱。先有便宜的试错回路,方向感会在一次次撞墙里自己长出来。
双螺旋,不是先后
讲到这你可能以为我在全盘否定"方向优先"。不是。我否定的只是那个"先"字。
"方向优先"派最后会用一个哲学论证保住"先":方向是目标因,围栏是动力因,目标因在逻辑上先于动力因。
哲学上也许自洽。但周一早上你打开仓库的那一刻,面对的是时间顺序,不是逻辑顺序。在时间里,方向和围栏是一条双螺旋:
模糊的方向感 → 搭最小围栏(测试 / CI / 可回滚)
↑ ↓
更新方向 ← 撞墙、反馈、发现真实结构
↓ ↑
扩张 → 围栏暴露新的漂移 → 纠偏
谁都不是绝对的"先"。成熟系统里方向牵引围栏,新系统里围栏孵化方向。
真正的元技能,不是背"先方向后围栏"这个顺序,是判断你此刻站在双螺旋的哪一段。
三个自检问题
下次开新项目、或接一个 AI 大规模开发的活,先问自己这三个:
1. 我对"正确结构"的把握有几分?
8 分以上,你在"方向优先"区。把那少数几个高阶不变量写下来、定成铁律,让错误结构没法合法存在。
5 分以下,你在"围栏优先"区。先别急着写架构铁律。把试错成本压到最低:测试能跑、CI 能拦、每步能 git 回滚、AI 每个 session 留一份 notes.md。
2. 我的方向是声明的,还是验证过的?
如果它只是脑子里"我觉得该这样",就给它降级——写成可被推翻的设计假设,而不是不可违反的硬约束。留出认错的余地。
3. 我有没有专门用来质疑方向本身的机制?
大多数围栏(测试 / 校验 / 审计)都是在既定方向内纠偏。你还缺第六层:定期开一个干净的会话,问一句"这个方向本身是不是错了?"
错误的方向,状态层检查永远抓不到。
讲到这,落到一句话:对一个独立开发者或者第一次趟新领域的团队来说,与其逼自己先定一个还不够稳的方向,不如先把围栏搭起来,把每次撞墙的成本降到最低——方向会在那些撞墙里自己长出来。
回头看你正在做的项目,问自己一句:对它的"正确结构",我现在打几分?
打不到 7 分,那今天该干的事不是写架构 RFC,是把测试和回滚机制再补一格。
本文受《Attractor Before Harness:AI 大规模开发的方法论》一文启发写成。该文主张"方向(attractor)逻辑上先于围栏(harness)",本文在认同其问题意识的基础上,补充了三个反面观点与一个"双螺旋"调和框架。