正在加载，请稍候
桌面端 AI 功能的验收清单常只写"功能可用"。这篇只解决一件事：把首帧、常驻内存、主线程长任务、每任务成本写成可执行的验收条款——含测法、环境与 P95 口径。
桌面端 AI 功能最容易被漏掉的验收项，是装上之后冷启动从 1.2 秒变成 4 秒、常驻内存悄悄翻倍——而验收清单上只写了「功能可用」四个字。
这篇只解决一件事：把性能验收写成可执行的条款。包体与运行时数值、席位成本、权限与安全边界各自有专文，本篇不重复展开，只用内链把边界划清。
桌面端 AI 功能与 Web 版的核心差别在资源约束归属：Web 只借用户浏览器的一个标签页，关掉就还回去；桌面端要长期常驻，独占本地 CPU、内存、磁盘与文件权限。
这个差别让验收指标整套失效。Web 侧看 LCP、TTI、CLS 就够，桌面端真正决定用户骂不骂你的是三件事：双击图标到看见可用界面多久、挂着不动占多少内存、AI 流式输出时输入框还跟不跟手。第四件事属于商务侧但同样硬——每个真正跑完的任务花多少钱。
先把结论摊开：这四条都必须写进合同附件，用 P95 而不是平均值验收。平均值会被大量空转样本稀释，而你买单的是最差那 5% 的用户体验。
桌面端 AI 客户端的冷启动首帧建议卡在 800ms 以内，且首帧窗口里不允许出现任何网络等待——模型列表、历史会话、上次的草稿都要先读本地缓存再后台补同步。
测法比阈值更重要。请用一台 4 核 8G、装了企业安全客户端、首次安装后的干净机器测，不要用开发机。测三次取 P95：第一次冷装、第二次常驻重启、第三次系统休眠唤醒后。三种场景的耗时常差 3 倍以上，只测其中一种等于没测。
Electron 官方性能文档点名了一个非常具体的坑：早期不少应用为了检测网络是否在线，引入了一个 isOnline() 模块，该模块的依赖链最终会在 require() 时读取并解析一个十万行以上的端口 JSON 文件，官方原文说「在慢机器上可以耗掉整整几秒」。启动路径上任何一个老实的 Node 模块都可能变成这几秒。
工程上的处理顺序是：先把启动路径的模块按需化（能动态 import 的不静态引），再谈渲染层优化。反过来做通常白干。
桌面端 AI 应用的常驻内存应按功能档位分档定预算：纯壳 150MB 以内、带本地全文索引 400MB 以内、内置本地小模型单独报备 2GB 起，且闲置 10 分钟必须能回落到壳档位。
「越小越好」是错的，因为 AI 客户端的常驻内存里有一块是买体验的：会话向量索引、最近文件摘要、模型元数据。把它们放进内存，用户翻历史会话才是秒开；全部挤到磁盘，每次切换都要几百毫秒的 IO 抖动。真正要防的是三件事：内存只涨不落、多窗口各存一份、切走标签后不释放。
测法用操作系统自带的进程组统计，把所有子进程加起来看，别只看主进程。Electron 系应用天然多进程，只看主进程会漏掉渲染进程和 GPU 进程那一大块；用系统 webview 的方案也要注意插件宿主进程。
流式 token 每 30 到 80 毫秒追加一次渲染，如果与本地检索、文件读写、JSON 解析挤在同一条主线程，输入框会出现 200ms 级延迟卡顿——这是桌面端 AI 功能最典型的「说不上哪里卡但就是卡」。
Electron 官方性能清单把「阻塞主进程」和「阻塞渲染进程」分别列成独立条目，这不是重复，因为两者的修法完全不同。主进程被阻塞，窗口事件、菜单、拖拽全停；渲染进程被阻塞，滚动和输入掉帧。
我们的工程建议是把 AI 调用通道整体挪出 UI 进程，做成独立的 Agent Host 进程，主进程只做路由和权限校验。理由有三条：模型调用本身是长连接且可能被取消；本地检索是 CPU 密集；进程级隔离之后，单个通道崩溃不会带走整个应用。
对应到验收上，用「主线程单次长任务超过 50ms 的次数」作为指标，在用户连续滚动会话列表同时触发一次流式回答的情况下测。这个复合场景比任何单项压测都准。
包体积不只是下载快慢，它直接决定你的版本迭代能多快——桌面端每一次热修都要过签名、过企业白名单、过员工自助更新，体积越大这条链越容易断。
Tauri 官方文档的说法是：Tauri 应用使用系统已有的 webview，只包含自身代码与资源，不需要每个应用都打包浏览器引擎，因此一个最小应用可以小于 600KB。官方还给了 release 档的裁剪建议：codegen-units = 1、lto = true、opt-level = "s"（体积优先，速度优先则用 3）、panic = "abort"、strip = true。
反过来，自带浏览器引擎的方案体积基线高，但换来渲染一致性：企业内网里老系统残留、旧版 webview 运行时、各种双核浏览器外壳，都会让「用系统 webview」这条路在交付时被客服电话打爆。这不是技术优劣，是交付环境现实。
| 维度 | 用系统原生 webview（Tauri 系） | 自带浏览器引擎（Electron 系） |
|---|---|---|
| 安装包量级 | 官方口径：最小应用可小于 600KB | 需打包整个渲染引擎，基线高一个量级 |
| 渲染一致性 | 依赖各系统 webview 版本，需逐机型回归 | 全平台同一渲染内核，回归面窄 |
| 内存基线 | 较低，但受宿主 webview 影响 | 多进程结构，进程组统计才有意义 |
| 生态与人力 | 核心逻辑需 Rust，团队要有人扛 | Node 生态成熟，招人容易 |
| 适合的落地场景 | 企业内部工具、对体积与更新频次敏感 | 面向外部用户的商业客户端、重前端体验 |
选型本身已有专门讨论，可参考站内Electron/Tauri 选型与 AI 原生改造决策，以及更细的桌面端 AI 架构工程账本：包体、显存与首字延迟；本篇只补它们没覆盖的部分：不管你选哪边，体积预算要按「安装包 + 首次解包后磁盘占用 + 每次增量更新的下载量」三个数一起报，只报安装包是最常见的偷懒。
桌面端 AI 功能的经济性必须按「单位有效任务成本」核算：分母是端到端跑完并通过验收的任务数，不是对话轮次、不是生成的行数，也不是 token 数。
这个口径来自我们在项目复盘里踩过的坑。早期按 token 结算时，一个反复重试 6 次最后失败的会话显示「消耗不低」，而一个真正交付价值的短会话显示「消耗很低」，指标和业务结果方向相反。换成有效任务为分母后，重试与人工返工的算力成本立刻显性化。
桌面端还要额外折进一块容易忽略的成本：本地算力。用户在笔记本上跑本地检索或本地小模型，你省了 API 账单，但换来风扇噪音、电池续航和客服投诉。折算方法不必精确，只需在同一张表里把它标出来，让决策者知道这笔钱从云端挪到了用户设备上。席位与额度的完整拆法见桌面端 AIcoding 成本测算。
关于「我们交付了什么」，这里把口径说清楚：截至今日，本站已发布的 7 个交付案例中，技术栈集中出现在 Next.js（7 个）、PostgreSQL（7 个）、Go（5 个）、React（4 个），行业分布为人工智能 2 个、企业服务 2 个、教育培训 2 个、文旅消费 1 个，端形态以 Web 为主。也就是说，本文的桌面端阈值不是从案例库外推出来的结论，而是官方文档口径加上工程判断——想看具体项目形态，可以翻已发布的交付案例自行核对。
require() 时就开始读文件的依赖。最后一条不是技术洁癖。2026 年 10 月，InfoQ 报道了多起 Agent 误删数据库的事件，题目直接问「几十年前就有的数据库防呆机制是不是不管用了」——桌面端把 AI 和本地文件系统放在同一台机器上，风险比服务端更高，因为用户的数据没有备份兜底。权限边界怎么划，站内这篇企业 AI 桌面助手的权限边界与安全验收给了更完整的做法。
不一定，但这两个是目前中文团队最容易招到人、最容易找到踩坑资料的两条路。如果团队已有 .NET 或 Qt 存量能力，用原生栈接 AI 反而更省；关键原则是把 AI 调用通道与 UI 进程隔离，用什么框架都要守。
先卡主线程长任务，它的修复收益最快且几乎不影响产品功能。流式输出挪到独立通道通常是一到两周的改造，但用户对「卡不卡」的感知强度远高于启动慢 300ms。
没有，这是工程判断而非标准。官方文档只给了包体积与性能陷阱的口径，具体毫秒阈值取决于功能密度和目标机型。建议先测出你现有版本的基线，再把目标设为基线的 70%，比照抄任何外部数字都靠谱。
会，而且这是最大的隐性成本。交付前必须列清目标机型的 webview 版本清单并逐机型回归，做企业内网客户端时尤其致命，因为客户机器上的运行时你无法升级。
账面上能，但要把设备成本折进来。省下的 API 账单要同时扣掉用户设备的算力占用、续航损耗与支持成本，多数情况下结论是只在离线、涉密这类特定场景才划算。
如果你正在验收一个桌面端 AI 客户端，带着目标机型清单和现版本的启动、内存基线来找我们，比先聊框架更快：联系蓝曜炬辉，我们在广州，也可以远程协作。