UI测试是AI需要的护栏：clipboardwire的故事

从去年12月起，作者一直忍受着日常工作中的小烦恼：他同时使用两台机器——运行Wayland的Ubuntu笔记本和一台Windows PC。通过Deskflow（Synergy的免费延续版）从Linux控制Windows，键盘鼠标同步完美，但剪贴板不同步。而Deskflow在X11下可以同步剪贴板，却与Wayland不兼容。

他尝试了KDE Connect等替代方案，但都不稳定，有时能用，有时需要重启或重新配对。对于需要始终可用的工具，这种不一致性比没有更糟。于是他不得不通过Google Chat给自己发送剪贴板内容，繁琐且低效。

在论坛上，他发现了一个有前景的方案：ClipCascade。它有Linux和Windows客户端，通过中央中心转发消息。然而，它基于Spring Boot的Java应用，推荐的最小堆内存是512MB。为了同步几行文本，在本地网络上运行这样一个庞然大物，作者无法接受。他关闭了浏览器，打开了Claude Code。

“让我们用Rust重写它”

作者从未认真写过Rust，只读过一两章相关书籍。他选择Rust是因为两个硬性要求：单一二进制、无运行时加载，以及内存安全。如果一个进程要在网络中监听端口，他宁愿任何错误以panic结束，而不是缓冲区溢出。他还明确从一开始就优先支持Wayland。

与Claude Code合作有一个独特的节奏：他给出高级指令，然后让AI运行，自己去做其他工作。一段时间后回来审查diff，指出下一步方向，再次让AI继续。几天后，一个可用的工具诞生了：两个客户端、一个中心、WebSocket消息、基础认证。

然而，bug开始出现。每次修复一个bug，另一个可能又回来，或者出现新问题。因为没有持久记忆，AI不记得之前修过同样的问题。几天后，作者意识到问题不在于AI，而在于没有测试来验证修复是否破坏了其他功能。这是一个带图形UI和异步行为的系统托盘应用，手动测试困难且容易遗漏。

于是作者花了一整天时间，要求AI生成一套涵盖图形UI的测试套件。他坚持要实现：每次push运行的第一层冒烟测试、通过DBus驱动Linux托盘菜单测试、使用UI Automation API的Windows托盘图标测试、用egui_kittest的设置对话框UI测试，以及检查单例锁的集成测试。CI在每次push时都在Linux和Windows上运行所有测试。

有了测试之后，一切发生了改变。AI变得更加可靠，因为每当它破坏某项功能，我们能立即发现；修复时也能确认真的修好了。作者认为这是整个项目中最可复用的教训：测试不是“你应该做”的负担，而是AI代理需要的护栏，使其不会偏离轨道。

在项目过程中，作者自己做出了一些关键决策：

• 简化认证：ClipCascade有复杂的认证方案，作者将其简化为基于TLS的HTTP Basic认证，因为运行在自己的LAN和VPN中，不需要PBKDF2或密钥派生轮数。
• 诚实威胁模型：中心在TLS终止后能看到明文剪贴板，没有客户端间端到端加密。这是故意为之，因为机器在自己控制下；如果信任自己的机器（存有SSH密钥、Cookie等），添加E2EE只是安全剧场。
• 单二进制三种模式：同一个可执行文件可作为客户端（connect）、中心（serve）或两者同时运行（host），方便打包和部署。
• 系统托盘而非守护进程：托盘图标显示实时状态（连接中/已连接/断开连接），让用户粘贴前即可看到状态，而非失败后才察觉。

关于Wayland，作者特别指出，一旦明确要求优先支持，GTK + libayatana-appindicator的实现在第一次尝试就成功，没有怪异的hack或X11回退。这也许在2026年已不令人惊讶，但正是Deskflow不支持Wayland促成了整个项目。

作者总结了三个意想不到的体会：

• 瓶颈是AI接收反馈的质量，而非其编码能力。在手动诊断bug时，速度为零；一旦有测试给出明确的“通过/失败”信号，速度倍增。
• 作者真正的贡献在于方向，而非编程。最重要的决策——简化认证、优先Wayland、定义威胁模型、推动UI测试——都是产品和架构决策，而不是代码。
• “不懂Rust”在几小时内就不再是障碍。不是因为他学会了Rust（他仍不传统地懂Rust），而是因为他能够通过阅读diff、理解整体结构来指导项目，让AI处理惯用细节。这既令人解放也令人失落。

项目名为clipboardwire，托管在github.com/davefx/clipboardwire，每个发布版有.deb、.rpm和.msi包。macOS版本即将到来。作者每天在Linux和Windows之间使用，服务器仅占用数MB内存，而Ctrl+C终于不再需要经过Google Chat。