继续聊大模型编程开发相关的问题

最近的一个月时间，断断续续在 OpenCode 这个工具上尝试了一些很有意思的东西。

我开始直接用 OpenCode 加上大模型去定制一个自己的大模型开发环境，然后开始用这些开发环境去折腾，包括调试自己使用的 Linux 桌面环境以及完成一些日常的工作。

前情提要，上篇已经讲了，这些环境本质是些跑着 OC 的 Systemd 容器。当然，我很不满意它没有提供套接字服务(Unix domain sockets)，所以我决定自己用大模型写一个。效果出人意外的好。对于整个 TypeScript 生态两眼一摸黑的我，不光实现了它的套接字服务，而且还发现了不少有意思的地方。这里我把这些工作直接放到了 GH 上面，有兴趣可以对照一下。

首先是我用的 OC 版本是 1.2.27 ，然后我发现它的网页端的内嵌功能是失效的。这个问题在最新版已经解决了，于是我先指令 OC 向后移植修复了这个问题。下一步，是加入套接字的功能。这一步骤并不是很顺利，很快我就明白为什么 OC 对于引入套接字不是很积极。我发现 OC 使用的 bun 对于套接字的支持非常勉强。通过大模型的指引，我甚至发现了相关问题已读不回的情况，这个我还是真的比较介意，因为一开始我想到的部署方案是就用 Systemd 的套接字激活功能，但显然基于 bun 的话这个路线只能做罢。不过我还是生成了一个能用的分支，在自己的部署中使用了 nginx 反代套接字文件。然后在剩下的半个月，用这个 OC 的部署开始做了不少事情。当然，中间还是做了一些修改。

当然开发环境并不只是 OC ，上个月我尝试部署了一下流行的龙虾，龙虾本身倒没有什么感觉，毕竟这事情需要搞定并主要是桌面自动化操作这些乱七八糟的东西，当然非常有价值，不过暂时不是我想做的事情。不过对于它的网络，发现了一个自己很感兴趣的一个功能， tailscale ，主要是内网穿透的功能。因为这个事情，我受到了一些启发。然后用 OC 制作了一个 mTLS 双向认证隧道应用，通过公网的云实例将内网的 TLS 服务暴露到公网上。在这个过程中，我还发现大部分浏览器对于 mTLS over =http3/quic 的支持并不是很好。事实是很不好。如果需要双向 TLS ，最合适的办法仍是 h2 。而 mTLS over h3/quic 这个，目前只能在定制场景中，自己写才可以得到较好的支持。

在这之后，我终于想起来看看微信小程序的开发。出乎我的意料的事，这件事在 Linux 环境下其实可以做。原先我以为需要一台苹果或者视窗系统。结果发现，微信本身有一个代码上传工具，加上多端应用开发框架(我选的是 uni-app ，不过这并不重要)，其实不再需要微信开发工具。这么做当然有不少局限性，但是对于极为简单的应用其实已经足够了。而且大模型告诉我，它可以直接在应用中集成调试终端面板，打印日志；更重要的微信本身也是实时日志功能，可以覆盖大部分情况。这样确实不方便。但这里是使用大模型进行开发，而大模型它不在乎这些。

这个过程中我还发现 uni-app 写的代码在不同目标上还是会有一些差异，当然 h5 必然是没有问题的。如果它构建微信小程序，还是有一些不兼容的地方。现在遇到了两个问题，一个是在组件间传递数值类型变量，在小程序会丢失。另一个是 i18n 时，模板中不能使用全局方法 $t() 来调用国际化文本，否则会出现非常麻爪的渲染问题。

当然前端这些还是小问题。如果想做一些略复杂的交互，比如说长按什么的，都会引入极高的复杂度，至于多端，如果考虑鼠标、触摸屏这些输入设备的不一致。前端的复杂度其实可以非常高。这种牵扯极多的开发其实我并不喜欢，但确实可以烧掉不少词元。如果想进一步探究大模型的编程能力，这个方向的开发是不二之选。

除了这些工作以外，我借助 OC 通过大模型来分析 Linux 桌面下的各软件的代码，来找出一些自己一直未能查清根源，仅仅通过重启解决的问题。比如说，我终于搞情楚了 pass_secret_service 不时卡住是因为 dbus 中的服务名冲突。这个问题其实还蛮让人头痛的。对于像我这种对系统一知半解的人来说，开源系统的好处变得极为明显。当然闭源系统上，大模型折腾反向工程打二进制补丁也是一个解决问题的思路。

我的另一个不爽的地方是 niri 隔几天就会因为浏览器这些东西，而直接禁掉硬件加速总体上并不是办法。