Busy 的第 9 版实现,一头撞上复杂度墙。所以我做了点调研。认知负担轻的编程语言,主要两个候选。Lua 分数最好。项目级和模块级都轻。我懂 Lua,跟它干活不介意……我当时天真地想。
Lua 真正的问题在于,它是个过时的、被弃养的项目。没有现行的菌株,而且它是为嵌入设计的,不是为直接跑在一个应用里。这对我想干的事是个麻烦。
Dart 拿了次低的认知复杂度分。比 go 小,模块级略轻,文件级显著更简单,和 Lua 打平。所以我选了它。
这版构建另一处大变化是分寸感(tact)。好,回到第一性原理……我们真的需要一个实时聊天机器人吗?多半不需要。我们需要的是一种围绕代码自我定向的东西。
于是我花了个周末,写出这套绝对漂亮的系统。两层。客户端应用用 Dart 写,PHP 跑在虚拟主机上。但是……回调得打隧道,打隧道又得发起一次 ftp 事务,好让 PHP 应用知道该叫谁。
在订阅的仓库里,你在 GitHub 上干任何事,系统都能抓到!实现 10 就要这么干活。至少在底层是这样。这种事,得先想管道,再想带 AI 的智能体功能。
管道美极了……但隧道不是为这个设计的。超时快,重连也接不利索。系统一半的时间花在:连上、发起事务、超时、重复,直到触顶最大指数退避,然后自我关机。
所以我调研了付费的隧道方案,想全在本地解决,认真评估了候选。想明白的是:在我现用的那家主机上买一台 vps 服务器就行,给应用分配一个专属 IP,隧道问题应刃而解。而且一个月 5 美元,女孩子想要的服务器糖果全都有。靠安全的 git 仓库发布,需要时还有 sudo 权限,还有……
好吧,现在,我设计它时做的那些关键假设,在逻辑上全站不住了,我得把整个东西重新设计。呃,也不是全部。这就是模块化架构的妙处。所以今天,我在重新调度它,搬组件。
我打算把 webhook 功能并进 Dart 应用,连同我全部的安全端点和数据库功能,但愿能甩掉那坨认知密度极高(但能跑)的 PHP 代码。数据库待在原地,vps 加白名单,这样关注点仍然分开。等弄完,我只需要在 GitHub 应用配置里改几笔,就齐活了。
下一步,上 AI 本体!