Presto 新架构人话版

这份文档不讲太多架构黑话，只解释一件事：Presto 如果从“一个很大的桌面软件”变成“一个会自己组装能力的创作系统”，它应该长什么样、怎么用、为什么不会乱成一锅粥。

常驻后台菜谱订阅插件服务可视化控制台可导入导出配置

一句话

Presto 以后可以不像一个“把所有功能塞进安装包里的大软件”，而像一个本地运行的小厨房：后台一直有一个管家，用户订阅菜谱，菜谱决定需要哪些工具，管家自动把工具准备好，桌面主程序只是看得见、摸得着的操作台。

先用一个厨房比喻说清楚

Presto 后台管家

也就是 prestod。它常驻在后台，知道现在装了什么、开了什么、缺什么、谁坏了、谁该被关掉。

插件就是工具和食材

Typst、Tinymist、PDF 导出、公文模板、AI 助手都可以拆成独立插件。需要时装，不需要时不启动。

菜谱是组合方案

用户不需要理解一堆底层能力，只要选“公文写作包”“教案计划包”“极简写作包”这种菜谱。

它和现在的软件有什么不同？

现在常见做法	新版 Presto 的想法	用户感受到什么
所有功能尽量塞进主程序。	主程序变轻，功能拆成可安装、可升级、可关闭的服务。	安装包更小，功能更新不一定要等整个 App 发版。
打开 App 才开始做所有事。	后台 `prestod` 可以先跑着，桌面只是连上它。	打开界面更快，后台能力状态更清楚。
插件页像应用商店，用户一个个装。	用户订阅“菜谱”，一次得到一组匹配好的插件和设置。	不用懂 Typst、Tinymist、provider 这些词，也能装好一套工作环境。
配置改了就直接生效，出了问题难回头。	先显示“将要改变什么”，确认后再应用，并支持回滚。	换配置、换菜谱、升级插件更有安全感。

最简单的运行过程

选择菜谱比如“公文写作包”或“教案计划包”。

后台解析看这个菜谱需要哪些插件、能力和默认设置。

生成计划告诉用户将安装什么、启动什么、覆盖什么。

自动准备下载插件、启动服务、检查健康状态。

开始使用桌面、CLI、API 都能调用同一套能力。

菜谱可以一层层叠起来

这点有点像 Docker 镜像分层。不是每份菜谱都独立启动一遍，而是先把它们叠成“最终配置”，再由后台决定真正要启动哪些服务。

官方基础包
最基础的写作、导出、模板能力。

官方 Typst 写作包
Typst 编译、Tinymist 预览、PDF 导出。

学校公文标准包
学校指定模板、导出格式、默认工作流。

我的个人偏好
我想用哪个 AI、哪些服务常驻、哪些功能懒启动。

→

最终得到一个当前环境

当前用哪个 Typst provider。
Tinymist 是否打开工作区时预热。
公文模板从哪个包来。
AI 文本生成走哪个 provider。
哪些服务常驻，哪些用完就关。

桌面主程序会变成什么？

它仍然是用户看到的 Presto

普通用户打开的还是一个完整软件，不会感觉自己在维护一套基础设施。

只是它背后连接的是常驻后台，所以能看到更清楚的插件、服务、日志和配置状态。

它也是 Runtime 控制台

用户可以在里面管理菜谱、切换配置、导入导出、看服务状态、查看失败原因、一键回滚。

它有点像 Docker Desktop、Clash Dashboard、系统服务管理器的温和合体。

用户会看到哪些页面？

页面	人话解释	典型操作
菜谱	我现在启用了哪些能力组合。	订阅官方菜谱、导入学校菜谱、调整层叠顺序。
当前环境	所有菜谱叠加之后，Presto 现在到底是什么状态。	查看某个设置来自哪一层，发现是谁覆盖了谁。
后台服务	哪些插件服务正在跑，哪些在等待，哪些失败了。	启动、停止、重启、查看日志、设置空闲自动关闭。
能力路由	每种能力现在由谁提供。	把 Typst 编译切到官方 provider，把 AI 切到个人 provider。
变更预览	启用新菜谱前，先告诉你会发生什么。	确认安装、取消变更、保存计划、回滚。

一个真实使用故事

用户第一次安装 Presto。

App 很轻。第一次打开时启动 prestod，然后提示是否启用官方基础菜谱。

用户选择“公文写作包”。

Presto 展示计划：会安装 Typst、公文模板、PDF 导出器，推荐安装 Tinymist 实时预览。

用户确认应用。

后台开始下载插件、检查版本、启动必要服务。界面先可用，预览能力显示 warming。

用户开始写文档。

文档可以立刻打开。Tinymist 准备好后，实时预览自动变成 ready；如果失败，普通编辑和导出仍可降级使用。

用户导入学校菜谱。

学校菜谱覆盖了默认公文模板和 PDF 导出设置。Presto 显示哪些地方被覆盖，用户确认后生效。

为什么这不是“复杂化上头”？

这套设计确实有复杂度风险。 所以它不能被做成“小型 Kubernetes”或“通用本地编排平台”。它只应该解决 Presto 自己的能力组合问题。

关键收敛原则是：用户配置只能声明“我要哪些能力、用哪个 provider、什么服务策略”，不能写任意命令、不能随便指向本地可执行文件、不能绕过插件市场。

哪些思想被吸收了？

来源	借什么	不借什么
Docker	后台 daemon、分层、服务运行心智。	不要求所有东西都容器化。
Homebrew	包、源、安装、服务管理、菜谱源。	不允许用户配置执行任意安装脚本。
NPM	依赖、版本、lockfile。	不把依赖树暴露给普通用户折腾。
VS Code	扩展贡献点、provider 选择。	不允许插件直接把任意前端组件塞进主界面。
Clash / Mihomo	core + dashboard + profile 的产品形态。	不继承任意节点配置的自由度。
K8s	期望状态、控制面、自动调谐。	不做多节点集群和复杂 CRD 生态。
Terraform / Vercel	变更预览、应用、历史、回滚。	不做云部署平台。

最稳妥的落地顺序

第一步：先把 Typst / Tinymist 插件化，做出最小插件市场、默认包和 provider 选择。
第二步：做 prestod 和 Runtime Console，能看服务状态、日志、启动/停止、导入导出配置。
第三步：引入菜谱和层叠规则，让官方包、组织包、用户偏好可以组合。
第四步：开放 CLI、API、MCP、第三方 Dashboard 这些多入口。
第五步：再考虑 Docker、远程服务、WASM 这些高级运行方式。

最后的判断

这个方向不是为了炫技，而是为了把 Presto 从“一个功能越来越重的桌面软件”变成“一个可以按工作流组装的创作环境”。

普通用户看到的是菜谱、状态、开关、回滚；高级用户看到的是 profile、lockfile、provider、service lifecycle。底层可以很工程化，但表面必须保持像一个好用的软件。