作者 | 陈一戈

责编 | 王轶群

出品丨GOSIM 开源创新汇

Dioxus 实验室创始人、Rust 前端框架 Dioxus 的创建者 Jonathan Kelley ，联合 Dioxus 实验室联创兼 AI 主管 Evan Almloff ，在GOSIM 2024 欧洲站为带来了《Dioxus Al：APP 开发的未来》的演讲。

作为 GOSIM 2024 欧洲站唯一一个双人阵容，该演讲以及其介绍的明星产品 Dioxus，成为大会现场人气最高、最受欢迎的内容分享。

完整演讲视频可点击下方链接访问：

Dioxus Al：APP开发的未来-CSDN直播

以下是演讲内容整理：

热爱开发者体验的 Dioxus

在演讲的一开始，Jonathan Kelley 为大家介绍了 Dioxus。Dioxus是一个用Rust编程语言构建跨平台应用开源框架，可以帮助开发者构建跨网页、桌面和移动设备的APP，并且只需用一套代码。只需要构建一次，就可以在任何地方发布。目前，Dioxus支持各种各样的平台，比如Mac、Windows、Linux、Android、和 iOS。

“我们在GitHub上拥有近20,000颗星。我们拥有几个热门项目——Taffy、Blitz、Dioxus本身。它被小型初创企业，以及一些大型组织所采用。”Jonathan 介绍道。Dioxus 被许多企业组织所采用，其中我们熟知的有空客（Airbus）和欧洲航天局（European Space Agency）。

（目前 Dioxus 在 GitHub 上得到了 19.4k 的星数）

接着Jonathon介绍了使用Dioxus构建新应用时的便利性，这全得益于一个命令行工具的存在，DX（Developer Experience），Jonathon 对其命名解释道：“因为我们热爱开发者的体验。”

那 DX 有什么功能和作用呢？

DX 可以使得新应用程序从初始状态到编译的过程不到12秒就完成。此外，通过一些代码示例（code example）的展示， Jonathon 也尝试告诉大家希望 Rust 成为开发者唯一学习的东西，因为它可以让 Dioxus 的应用程序是端到端类型安全的，极大地提高了开发效率。

然而得到广泛使用并获得近2万GitHub星数的Dioxus，并不是完美的。

随着 Dioxus 的广泛使用，社区的不断扩大，Jonathon也逐渐关注到了三个社区中大家最常提到，呼声最大的几个问题，并相应地给出了解释与说法。

1. 相比React，Dioxus的生态系统较小。

——对此Jonathon回应道，Dioxus还在逐渐进步中，目前只有两岁，比React年轻许多在同一时期。

2. Rust 这一编程语言对于新手来说非常有挑战性。

——Jonathon 也借此提到了了解尤其是UI的最佳模式与架构对于构建 Dioxus 与 Rust 应用的重要性，会使开发者的进程速度大大提升。

3. Rust 的迭代周期通常要比 JavaScript 慢。

——对此，Jonathon 表示相比 Javascript 的实时重新解释与重新加载，Rust 虽然要求开发者必须通过编译器的检查以及应用的重新编译，但是编译器在目前来看面对复杂的代码是非常有好处的。他对 Dioxus 提出的首要目标就是提升开发者的工作效率，如果能通过热重载、自动格式化、打包等方式更快地完成搭建，就可以更快地发布产品，从而为整个生态系统提供更多的库、文档与示例。而这些反过来又最终会促进开发者的效率。这也是当前 Jonathon 在探索 AGI 的方向。

解释完了 Dioxus 社区中目前关注度最高的几个问题，Jonathon 也为今后Dioxus 更快的应用构建提出了三个战略性工作目标：

1. 减少必须编写的样板代码量。

2. 提高 Dioxus 的可靠性以及构建应用程序的稳定性。

3. 缩短迭代周期，将想法到屏幕上的内容再到代码库的时间做到越短越好。

在本地终端运行，而非云端

随着 Jonathon 说到他们的硬件要求，Evan 登台开始了他的分享。Evan 表示在创建这个项目的时候，其中一个要求就是让这个项目可以在普通硬件上运行而非云端，主要原因有以下几点：

• 本地模型能生成的代码几乎与 Llama 70B一样好，经过微调后其效果更佳。

• 团队不想在 Dioxus 上运行任何服务器。没有服务器的运行，有助于更快的产品迭代，Dioxus 可以更快地将代码交付给用户，用户也能更快给予反馈帮助产品的改进，同时更易于开发者参与贡献——只需下载 Dioxus的库，执行 cargo 即可。

• 本地 AI 对于代码生成的私密性以及支持离线开发也十分重要。

但是 Evan 表示也有一些问题需要解决，其中一个问题就是将人们提供的提示词变成代码。

他向大家展示了目前最好的开源模型无法生成 Dioxus 代码，即使通过上下文学习，并且大型模型如 Llama 70B，在生成 HTML 时的缺陷：图像质量不佳。微调可以缓解一点这种问题，那么如何找到合适的提示词呢？可通过生成合成数据集，用 Dioxus 生成自己的代码。

那如何来运行良好的模型呢？

Evan 提到了一个他参与开发的一个名为 Kalosm 的库。Kalosm 可以使像笔记本电脑的商用硬件上运行量化模型变得简单，可以运行量化的文本、音频和图像类型。同时可以利用受限生成技术过滤模型的输出来保证其遵循用户设定的格式。并且它有上下文提取和数据库集合的功能，使用户使用的模型与数据更好地结合。

为此，Evan 准备了一个 UI 生成的 demo，演示了根据一个介绍 Dioxus 的网站如何生成一些卡片。可以看到，几张关于 Dioxus 的卡片会根据当前设备作出响应，其布局会自动根据使用者的需要做出调整。

此外，为了验证用户创建的 UI 是否正确且易于阅读，Evan 提到了 Kalosm 的 Agent，并进行其 Demo 演示通过 Agent 实现自动化的质量保证。

Jonathon 说到当有能力运行本地模型或操作代码库之后，可以做很多有趣的事情，比如可以添加可访问性属性、主题制定、生成组件的变体，还可以建议重构（suggested refactors）——用非常智能的方式分解一个非常大的组件：通过 VS code 自动拆分组件、分解数据，一些非常复杂难以处理的重构可以在编辑器中仅基于上下文完成。

当进行 React-type 的状态管理时，比如提升状态，一个组件内的状态可以立即做到与其它多个组件共享，与自己操作相比可以节省几十分钟甚至一小时的时间。 

成为下一代 APP 开发框架

对于当下即将席卷全球的 AI 革命，Jonathon 充满激情，但他对于 AGI 还是持较为保守的态度，同时他也相信自己的工具开发会对下一代 APP 开发框架带来增益。

当考虑到一个完美的 Dioxus Copilot 是什么样子时，Jonathon 希望能够因此以极少的阻力构建和改进实际视觉 UI，希望整个迭代的过程尽可能实现无阻力。他也希望可以在测试应用时自动展现质量保证，更快完成迭代。

Jonathon 同时也希望可以对已编写的代码进行原地修改，希望在编写完内容后在原地进行风格、布局、样式等方面的更改与迭代。

下一步 Jonathon 和 Evan 打算在 Dioxus 做哪些改进？他们将主要从以下四点出发：

1. 性能，Dioxus CLl+ VSCode 扩展集成。Jonathon 表示在消费级硬件上减少 token、retokenizing 的数量是很有意思的探索过程。他们目前正在计划在接下来的几个版本中推出开发工具以及一些更有趣的功能并打算发布一个更加微调的Phi-3 及 Llama 70B 版本，使得任何人都可以下载使用。

2. 增加交互式 UI 生成功能。帮助用户提供不同变体以及喜欢的样式，无需编写 Tailwind Classes，只需查看可选项并进行选择。

3. 自动化 UX 测试。利用 Kalosm 的 OCR 功能来分析，告诉使用者一些基本问题，比如用户体验、页面显示、配色方案以及布局方案等，并给出改进建议。

4.其他框架的通用实现。

5. 投入生产！大家可以在 GitHub 或 Dioxus Labs 的页面上看到其团队的所有工作。

GitHub 网址：

https://github.com/DioxusLabs/dioxus-ai

Dioxus Labs 官网：

https://dioxuslabs.com/

现场QA

Q：我很好奇你们的盈利模式是什么？是仅仅出于对开源社区的善意才做的这一切吗？

Jonathan：目前我们的目标是尽可能让 Dioxus 变得出色，如果试图从开发工具中获利，与一些巨头，比如 Flutter，竞争是很困难的。所以坦白来讲，我们目前只希望 Dioxus 变得更好。未来可能通过打破不同平台，比如安卓、苹果等之间的壁垒来挖掘价值。

Q：你们为什么想在本地运行？考虑到能够离线编程，无需自己搭建服务等这些因素。但你们这样做是否也是有意地尝试让它变得安全通过远离公众？比如保持你们代码的私密性？

Evan：我认为隐私是一个重要因素，这也是我最初构建 Kalosm 的原因之一。因为很多本地 AI 硬件初创公司在兴起，比如Humane AI pen和兔子，这些设备拥有大量你不希望外泄的数据，目前它们通过选择性录制来缓解这一问题在每种设备中通过按下每一个设备中的一个按钮来录制周围环境。如果这一些都在本地进行，你可以做到不将任何数据发到云端。就像我们一样，你无需向我们发送任何可能包含你的密码、API 密钥或公司信息的 Dioxus 代码。

Q：从 HTML 转换到你们的语言，这只是普通代码吗？是一个正则表达式还是带有生成器的 HTML 解析器？

Evan：是的，目前是 HTML 解析器，然后从那里生成 RSX。它只是为代码中易于解析的部分生成 RSX。因此你可以知道元素名称，属性名称以及其值。对于闭包等更复杂的内容，我们希望最终能结合硬编码与 AI 技术来处理。所以有些函数翻译起来非常简单，但有一些难度较大。为了将所有 JavaScript 函数或闭包转换成 Rust，可能需要进行一些结构调整。这无疑是我们未来希望改进的领域。

Q：你是考虑过使用 LSP 将代码编辑引入不同的编辑器？

Jonathan：理论上是可以的。目前，我们还没有实现完整的 LSP。维护这些工作量很大，但很快就会有的。我不明白为什么我们不能将这一代的大量内容置于LSP之后。因此，那些嵌入提示，实际上你必须是 LSP 才能提供这些。所以我们想要提供这些，为此我们将不得不成为LSP。在这种情况下，你将能够在任何编辑器中使用 LSP，比如 Vim、Helix，或任何其它编辑器。所以是的，你可以在普通编辑器中完成所有这样。

Q：你是否注意到 Phi 和 Llama-3 之间有任何显著差异？比较这些模型的向量是什么？

Evan：关于 Llama-3 ，我注意到的一点是，比如 Llama-3 8B，它在遵循提示方面比 Phi 要好得多， 但它的运行速度也慢得多。因此，Phi 在能够轻松使用约束生成使其遵循给出的指令的场景中表现出色。但如果做不到这点且遇到难以约束的情况，那么 Llama-3 8B 更为合适，因为它能根据系统提示来执行指令。

Q：与 70B 模型相比，是否存在显著差异？

Evan：是的，70B 模型在生成代码方面表现更佳。但你可以对 70B 模型进行微调以获得相似的性能，尤其在有非常特定用例的情况下。

Q：你是基于有效字符来限制输出，难道不能用这个方法来迫使语言模型直接输出 DSX 而不是 HTML？

Evan：是的，这是我们未来想要探索的方向之一，即直接生成 RSX。目前，我们不得不通过 HTML，因为这些模型已经在大量 HTML 数据上进行了训练而我们没有那么多 RSX 作为训练数据。我们确实有一些精细调整的数据，我们有大约10000个例子，实际上通过了我们的过滤的有1500个。如果我们有更多这样的数据，仅针对 RSX 进行精细调整就会有效。理论上，这会为我们节省一些 token，因为你不需要为所有内容生成结束标签。但在那个阶段，我们也可以探索不同的 token 化方式，这样无论你生成的是哪种 HTML 语法结构都不重要。

Q：你们在微调上花费了多少时间？

Evan：随着数据量的增加，我们进行了几次不同的运行。但在 T100 上使用 QLORA 进行微调花费了一个小时。而且那是在我们的训练集上进行了五个周期。

Q：你用了多少 RAM？

Evan：我不清楚，应该不到 16GB。

Q：有关于生成 UI 主题的想法，或者在美学设计方面的考虑吗？

Evan：是的，这就是闭环发挥作用的地方。一旦我们的测试代码运行得非常好， 理论上我们可以用它来获取我们输出的代码，进行测试，并确保它看起来不错，拥有一个合理的用户界面。然后如果看起来不错，再用来过滤输出。然后要么用它来生成一个看起来更高质量的合成数据集。它确实有效，对屏幕尺寸的变化有反应， 但看起来并不出色。所以生成看起来更好的代码和界面绝对是我们未来想要深入探讨的。