短答：不能"直接转换"。Multica 和 Paseo 在跨端上做了相反的选择。Paseo 共享的是"UI 本身"（一份界面渲染到 6 端）；Multica 共享的是"大脑/逻辑"，UI 则分成两套皮——Web/桌面共用一套（React DOM），手机(iOS/Android)是另起炉灶的 React Native 皮，只复用逻辑层。
core/ui/views）。但这套 UI 无法快速搬到手机——因为它用的是 shadcn / Base UI / TipTap 这些只跑在浏览器 DOM 的库。手机端 apps/mobile 是独立的 React Native 实现，只复用 @multica/core（数据与逻辑），不复用界面。这叫"共享大脑、各画各的脸"。
同样想"少写点、多端复用"，但复用的层次完全不同。
apps/mobile 完全不导入这两个包换句话说：Web 和桌面之间是"真·一套代码"（连 UI 组件都共用）；Web/桌面 与 手机之间只是"共用一颗大脑，各画各的脸"。
证据来自三个 app 的 package.json 依赖声明。
"@multica/core", "@multica/ui", "@multica/views" ← 三个都用
"@multica/core", "@multica/ui", "@multica/views" ← 和 web 一模一样
"@multica/core" ← 只有 core！没有 ui，没有 views + nativewind, react-native, expo-router, @rn-primitives/* ← 自带一整套 RN UI
结论一目了然：手机端只从共享 monorepo 拿走了 core（逻辑），界面是用 React Native 生态另写的。
| 维度 | Multica（共享大脑） | Paseo（共享 UI） |
|---|---|---|
| Web + 桌面复用 | 极好，连 UI 组件都共用 | 好（桌面=web 套壳） |
| 手机端复用 UI | 不复用，要重写界面 | 复用，一份 RN UI 直接跑 |
| 手机端复用逻辑 | 复用（core 白拿） | 逻辑其实在 daemon，端上很薄 |
| Web 质量 | 真 Next.js（SSR/SEO/DOM 生态齐全） | react-native-web（偏重，SSR/SEO 吃力） |
| 各端原生手感 | 每端都地道（web 像 web，app 像 app） | 统一但偏"一个模子" |
| 维护成本 | 要维护 2 套 UI 皮 | 1 套 UI + 平台分叉小文件 |
| "改一处多端生效" | 仅逻辑层成立；UI 改动要改两处 | UI 也基本成立 |
没有谁绝对更好：Multica 用"两套皮"换来了每端地道体验和一个真正的 Next.js Web；Paseo 用"一套皮"换来了极致复用，但 Web 是 RN-web、且要吞平台分叉的复杂度。
Web/桌面的 UI 建在 shadcn / Base UI / Tailwind-DOM / TipTap 之上，这些库不在 React Native 里跑。想让手机复用它们，等于把整个 Web 前端用 React Native + react-native-web 重写，并放弃现有 DOM 组件库——这是大改造，不是"快速转换"。
Multica 已经把 @multica/core 刻意做成零 DOM 的 headless 层，正是为了让 RN 端能白拿逻辑。所以"起一个手机端"不用重写业务逻辑、API、状态管理——只需要重画界面。它选择的是"逻辑一次写、界面按平台族写两次"。
Paseo 是本地优先、端很薄（逻辑在 daemon），UI 统一成 RN 代价小、收益大。Multica 是云优先、要一个 SEO/SSR 齐全的营销+产品 Web 站，用 Next.js(React DOM) 是更对的选择——而 Next.js 的 DOM UI 天然没法直接搬去手机。
如果目标是"手机和 Web 长得尽量一致又省事"：与其模仿 Paseo 推倒重来，不如继续吃 core 的复用红利，在 RN 侧建一套对齐设计规范的组件库（NativeWind 已在用），用设计 token 保证视觉一致，而不是共用代码。