我用 Tauri 把这套视频生成平台“包”了起来

  • King
  • 发布于 1天前
  • 阅读 106

视频生成平台跑通之后,其实还有一个绕不开的问题:这东西,怎么用?命令行当然可以,但也只适合我自己。一旦你希望它变成一个「能长期使用的工具」,可用性就会变成第一优先级。于是今天,我又往前走了一步——用Tauri把整套视频生成平台包装成了一个桌面应用。为什么不是Web,而是Ta

视频生成平台跑通之后,其实还有一个绕不开的问题:

这东西,怎么用?

命令行当然可以,但也只适合我自己。 一旦你希望它变成一个「能长期使用的工具」,可用性就会变成第一优先级。

于是今天,我又往前走了一步——

用 Tauri 把整套视频生成平台包装成了一个桌面应用。


为什么不是 Web,而是 Tauri

很多人第一反应是:

做个平台,不就上个 Web?

但对我来说,Web 反而不是最优解。

原因很现实:

  • 视频生成强依赖本地算力
  • 合成、转码、文件操作都在本地
  • 上传 / 下载视频素材非常重
  • 还要处理 FFmpeg、模型、缓存目录

👉 这些事情,天然更适合本地应用,而不是浏览器。

而 Tauri 正好卡在一个很舒服的位置:

  • 前端是 Web 技术,开发效率高
  • 后端是 Rust,能直接复用已有平台代码
  • 应用体积小、资源占用低
  • 跨平台(macOS / Windows / Linux)

几乎是“为这个场景量身定做”。


Tauri 在这个项目里的角色

我并没有把 Tauri 当成“前端框架”,而是当成:

一个“人和平台之间的交互壳”。

整体分工非常清晰:


Rust 核心平台:完全不改

  • 任务系统
  • 视频生成流程
  • 资源调度
  • 状态机

👉 这部分依然是一个纯后端库,甚至可以单独跑。


Tauri 只做三件事

在 Tauri 层,我严格限制它的职责:

  • 发起任务
  • 展示状态
  • 拿结果

所有复杂逻辑,一律不进 UI 层。

这条原则帮我避免了一个大坑:

👉 “把业务写进前端,最后谁都不敢动。”


前端 = 状态可视化

前端页面做得非常克制:

  • 当前有哪些任务
  • 每个任务跑到哪一步
  • 哪一步失败了
  • 最终生成了哪些文件

它不“聪明”,但非常清晰。


为什么“桌面化”这一步很重要

在真正用起来之后,我发现 Tauri 这一层带来的变化,比我预想的大。

从“工程工具”变成“日常工具”

以前是:

我要专门打开终端,跑命令

现在是:

打开应用,点一下,任务就开始跑了

使用门槛直接降了一大截。


状态可见,心智负担骤降

视频生成是长任务,如果你不知道它在干嘛,就会焦虑。

UI 把这些不确定性都摊开了:

  • 正在生成文案
  • 正在合成音频
  • 正在渲染视频

👉 人会更愿意等待一个“看得见进度”的系统。


为“给别人用”扫清障碍

当一个东西:

  • 不需要配置一堆环境
  • 不需要懂命令行
  • 打开就能用

它才真的具备“被分享”的可能。


一个很关键的设计取舍

我在这里刻意没有做在线化、账号、云端同步

不是不能,而是没必要。

这个阶段我更关心的是:

  • 单机是否稳定
  • 流程是否顺滑
  • 用户(包括我自己)是否愿意天天用

👉 先把“一个人用得爽”做到极致,再谈规模。


当前状态 & 接下来

到现在为止,这套系统已经完成了三次跃迁:

  1. 手工做视频
  2. Rust 平台化
  3. Tauri 桌面化

它已经不再是一个 Demo,而是一个我每天真的在用的生产工具

接下来我可能会继续做的事情包括:

  • 任务模板化
  • 更多视频风格
  • 插件化生成步骤
  • 或者,把它开源出来?

慢慢来,但方向很清晰。

点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
King
King
0x56af...a0dd
擅长Rust/Solidity/FunC/Move开发