一个人观察多个独立项目通过共同规则自动协作的抽象技术场景

我们说好了

:从 protocol、SKILL 到“约”

前几天改一个项目的代码,牵一发而动全身。

这个项目本身并不是孤立的,它跟另外几个项目有依赖关系。于是我下了一条指令:这边修改以后,把相关项目也同步调整,保持彼此一致。

接下来发生的事情其实很普通:几个项目开始联动。

这个项目修改接口,那个项目同步适配;这里调整一条规范,那里检查对应实现;谁负责什么,改到哪里,下一步交给谁,都按照既定规则往下走。

我看着它们之间的对接语言,忽然产生一种有点弔诡的感慨:

这几个项目之间的协作,真的是比人与人更顺畅!

当然,这不是因为 AI 比人更懂合作。

恰恰相反,可能正是因为它们不需要“懂”那么多。


人与人合作,常常有大量事情游离在规则之外。

“我以为你知道。”
“这个应该归你吧?”
“上次不是这么说的。”
“我理解你的意思不是这样。”
“这个规定只是参考,不必那么死。”

很多所谓沟通问题,其实并不是不会说话,而是大家对规则、边界和责任的理解根本没有对齐。

而程序世界不太允许这种暧昧:谁提供什么,谁依赖什么,输入是什么格式,输出应该是什么结果,什么东西能改,什么东西不能改,都最好提前说清楚。

说清楚以后,剩下的事情反而简单:大家照着走。

这让我重新想起一个很老的词:

protocol。

两个结构不同的系统通过统一协议桥连接并交换信息的示意图
系统不需要彼此相似,也不需要知道对方内部如何实现;只要共同遵守同一套协议,就可以通信

以前我在大学讲计算机网络课,对 protocol 这个词印象很深。

为什么两台完全不同的机器可以通信?
它们可能不是同一个品牌,不运行同一种操作系统,内部实现也完全不同。
它们甚至根本不需要知道对方“里面是怎么做的”。
它们只需要遵守同一套协议。

我这样发,你这样收。
你收到以后这样回应。
这个字段放这里。
这个状态代表这个意思。
如果发生错误,用这种方式告诉我。

说到底,所谓 protocol,就是一句很朴素的话:

我们说好了,以后照这个来。

只要这个“说好了”还算数,彼此就可以合作。


后来做软件和数据,类似的东西越来越多。

API 是约定。
数据接口是约定。
函数签名是约定。
Schema 是约定。
文件格式也是约定。

一个系统能不能跟另一个系统合作,很多时候并不取决于它们内部有多聪明,而取决于彼此有没有一套稳定、清楚、可依赖的共同规则。

真正成熟的系统,往往并不要求所有部分彼此相似。

它只要求:接口一致,约定有效。

换句话说:

协同不要求彼此相同,只要求共同守约。


这次让我再次想到这件事,是因为我刚好在折腾另一个很小的东西。

我写了一个 Bible Citation 插件,用来处理文章里的圣经引用。

有一个比较旧的项目也需要调用这个插件,于是我安排它按照插件的规范,为圣经引用自动加上链接。

一开始,我用了最简单的做法:直接在这个项目的 AGENTS.md 里写清楚规则。

但我很快意识到:如果以后别的项目也要用呢,难道每个项目都复制一遍?

这当然不是不可以。但一旦发生修改,就很容易漂移。这个项目写的是新版,另一个项目还是旧版;这里改过,那里忘了改。原本想让大家遵守同一个规则,最后却变成每个人手里各有一份自己的版本。

于是我想到:

不如把这些规范抽出来,写成一个小 SKILL,以后凡是需要处理 Bible Citation 的项目,都调用同一套规则。

这就不用每个项目重新解释,也不用每次重新谈判。大家共同依赖同一份约定就好。

我不禁哑然失笑:我做的是一个跟圣经引用有关的工具,而我为了让不同项目能够协作,最后做的事情,居然也是在建立一种“约”。

当然,我不是说一个 SKILL 就等于圣经里的约。这两个东西差得太远。

但技术经验确实让“约”这个词突然变得不那么抽象了。

多个独立项目连接到同一套公共规则并协同工作的抽象示意图
把散落在各项目中的重复规则抽成公共 SKILL,相当于把一次次临场协商变成所有项目都能依赖的共同约定

以前听到“约”,很容易觉得那是有点古老的词,总带着一种仪式感:

盟约、契约、立约。

但在程序世界里,你会发现,“约”其实非常日常。

一个复杂系统之所以能够运行,本来就依赖无数个“我们说好了”。

我们说好了这个字段是什么意思。
我们说好了这个接口不会突然改变。
我们说好了你负责这里,我负责那里。
我们说好了只要你按照这个格式请求,我就按照这个格式回应。

很多时候,所谓可靠,并不是因为对方每次都重新理解你。

恰恰相反,可靠往往意味着:

有些事情已经说好了,所以不必每次重新解释。


这也是为什么我越来越觉得,复杂协作最怕的并不是规则多,而是规则不清。

人们有时候把规则看成一种束缚。好像关系好,就不需要讲那么清楚。

但技术世界给出的经验几乎相反:

系统越复杂,越不能只靠默契。
参与者越多,越需要明确边界。
协作越频繁,越需要稳定约定。

没有约定,每次合作都必须重新确认一次。
有了约定,大家才能把精力放在真正要做的事情上。

所以“约”的意义并不是把关系变僵硬,恰恰是因为有一些东西稳定下来,关系才不必时时重新开始。


回头再看那几个自动联动的项目,我现在觉得,它们之所以显得比人与人合作更顺,不是因为机器更会合作。

只是因为很多人类协作里最容易出问题的东西——含糊、猜测、边界不清、各自理解——被我们尽量排除掉了,留下来的,是一套大家都承认的规则。

然后,各自照做。

这其实是一件很简单的事,简单到我们每天都在使用,却很少停下来想:

网络为什么能连起来?
软件为什么能彼此调用?
几个互不相同的项目为什么可以协同工作?

因为在开始之前,已经有一句话放在那里:

我们说好了。

有时候,一个系统能不能长期运行,靠的不是更聪明,只不过是有人还记得:

说好的事情,最好算数。

X

类似文章

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注