AIaW 已进入弃用状态：一个本地优先 AI 客户端的取舍与迁移路径
AI as Workspace - An elegant AI chat client. Full-featured, lightweight. Support multiple workspaces, plugin system, cross-platform, local first + real-time cloud sync, Artifacts, MCP | 更好的 AI 客户端
秒懂
- 它是什么？
- AIaW 是一个基于 Quasar/Vue 的跨平台 AI 聊天客户端，支持多工作区、MCP、插件与 Artifacts。README 顶部已标注弃用，作者转向重写项目 Nya AI，本文梳理它的机制、部署方式与迁移成本。
- 适合谁用？
- 已经在用 AIaW 并依赖本地数据与多工作区的团队，可以继续运行现有版本，但应先把 docs.aiaw.app/migration 的迁移说明读完，确认导出格式与 Nya AI 的导入路径匹配，再决定升级窗口。准备新选型的团队不要从这里开始，README 明确写着项目已被 Nya AI 取代，新项目提供大部分功能与一致的体验，从零接入等于主动选择一个停止演进的代码库。
- 能商用吗？
- 可以。BSD-3-Clause 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 121 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
弃用标注写在 README 最上方，这决定了整篇文章的读法
打开仓库首页，第一眼看到的不是功能列表，而是一段 WARNING：项目已弃用，由 Nya AI 接替，后者是用新技术栈做的完整重写，提供本项目的大部分功能与一致体验，并附带许多新功能和优化。作者同时给出迁移文档入口 docs.aiaw.app/migration/。这不是社区传言，是仓库自己写的。因此任何关于 AIaW 的评估都必须先回答一个问题：你是在维护存量，还是在做新选型。两种情况下的结论完全相反。存量用户关心的是数据能不能平滑搬走、现有版本还能跑多久；新选型用户关心的是，既然有官方指定的继任者，为什么还要看一个停更分支。本文按这个分叉来写，功能描述用于判断存量系统是否够用，而不是用来推荐新项目。
它解决的是本地优先与多工作区这两件事的组合
README 把数据存储单列一节：数据先存本地，可离线访问，加载即时；登录后可开启云同步，用于跨设备；同一浏览器开多个标签页时，数据在多窗口之间做响应式同步。这三句话对应三种不同的使用状态，本地优先解决的是断网和首屏速度，云同步解决的是多设备，多窗口同步解决的是同一台机器上开多个标签时的数据一致性。目标用户是有明确分主题需求的人：README 提到可以按主题创建多个工作区，工作区还能分组进文件夹并支持嵌套，助手既可以属于某个工作区，也可以是全局助手。把对话按项目隔离，再给每个工作区配不同助手和提示词变量，这套组织方式对同时处理多条产品线或多种语言任务的人有用。如果只是随手问几句，这些层级反而是负担。
MCP 与插件是两套并行的扩展机制，不是一回事
README 把 MCP 和插件系统分开描述，这个区分很重要。MCP 部分写明支持 Tools、Prompts、Resources 三类能力，连接方式有 STDIO 和 HTTP 两种，既可以装插件市场里的 MCP 类型插件，也可以手动添加 MCP 服务器。插件系统则是另一条线：内置计算器、文档解析、视频解析、图像生成，可从市场安装更多，还能把 Gradio 应用配置成插件，并兼容部分 LobeChat 插件。README 对插件有一句判断，插件不只是工具调用。这句话本身没有展开，文档里也没有给出更细的边界，所以插件到底能在对话流程里介入到哪一层，只能以 docs.aiaw.app/usage/plugins.html 为准。Artifacts 与这两者又不同：可以把助手回复的任意部分转成 Artifact，用户可编辑，带版本控制和代码高亮，并能控制助手对 Artifact 的读写权限，支持同时打开多个。三套机制叠在一起，能力面很宽，代价是配置项分散在三个文档页面里。
从源码到可运行：pnpm、quasar 与打包形态
README 给出的开发流程很直接：先 pnpm i 安装依赖，然后 quasar dev 启动开发模式，带热重载和错误上报。代码检查用 pnpm lint。生产构建分两种形态，quasar build 产出 SPA，quasar build -m pwa 产出 PWA。也就是说同一个代码库可以按需要打成普通单页应用或渐进式 Web 应用，这与它宣称的 Web (PWA) 平台支持对得上。仓库还提供自托管指南链接 docs.aiaw.app/self-host/，但 README 正文里没有展开具体的环境变量或配置键，因此部署时需要哪些参数、云同步指向哪个后端，必须去翻那份指南，不能从 README 推断。技术栈线索来自 topics 与构建命令：TypeScript、Vue、Quasar、Docker、PWA 都在列，说明官方也考虑过容器化部署。桌面端与 Android 的安装包走 GitHub Releases，最新版本为 v1.8.12。
Web 搜索默认依赖 SearXNG，这是部署时最容易踩的地方
README 说 Web 搜索基于 SearXNG，并且 ready to use out of the box，还提供按 URL 抓取网页内容的能力，两者都支持并发。这里存在一处需要读者自己判断的张力：SearXNG 是一个需要自行部署或指向实例的元搜索引擎，而 README 用开箱即用来形容它，说明要么项目内置了默认实例，要么在自托管时由部署者提供。README 没有写明是哪种。对自托管用户来说这不是细节，搜索请求发往哪个实例，直接关系到可用性、限流和隐私边界。并发搜索与并发抓取同样没有给出并发度上限，也没有说明失败重试策略。如果你的场景强依赖联网检索，这一块必须在自建环境里实测，不能只看功能列表。
轻量与跨平台是它的长处，但边界要自己划
README 用轻量和高性能作为卖点，具体表述是启动快、无需等待，对话切换流畅，并附了 Lighthouse 的桌面与移动评分截图。截图本身是仓库里的图片，本文没有复现过这些分数，也不把评分当作独立验证。跨平台方面，支持 Windows、Linux、Mac OS、Android 和 Web (PWA)，AI 提供方包括 OpenAI、Anthropic、Google、DeepSeek、xAI、Azure 等。真正需要留意的是它的能力边界：这是一个客户端。模型调用、密钥管理、配额与计费都不在它手里，README 的 Related Projects 里列了 New API，一个把多种大模型统一成 OpenAI 兼容格式的接口管理与分发系统，这个并列本身就说明作者预期用户会自己接一层网关。如果你需要的是服务端侧的审计、统一限流或团队级密钥托管，AIaW 不提供，得靠外部系统补。
Nya AI 不是替代品选项，而是官方指定的去向
讨论替代方案时，最直接的一个就是 Nya AI。作者对它的描述是完整重写、新技术栈、覆盖本项目大部分功能、体验一致，并带有新功能和优化。这意味着两个项目不是并存关系，而是接力关系，AIaW 的代码库不会再作为主线演进。与另一类做法相比，差异在于路线：有些项目选择在原有代码上持续迭代，保持数据格式和插件接口稳定；这里选择了重写，短期迁移成本更高，换来的是技术栈上的腾挪空间。README 没有说明哪些功能没有被带过去，只说大部分功能，因此迁移前必须逐项核对 docs.aiaw.app/migration/ 里的说明，尤其是工作区结构、提示词变量和插件配置这几类容易丢的东西。至于 LobeChat，README 只提到插件兼容性，没有做功能对比，本文不替它下结论。
许可与维护成本：BSD-3-Clause 之下的现实问题
许可证是 BSD-3-Clause，属于宽松型许可，允许修改和再分发，通常要求保留版权声明与免责条款。这里不做法律解读，只提示一点：宽松许可意味着你可以自行 fork 并继续维护，但 fork 之后上游的安全修复和兼容性更新就不再自动到来，你需要自己承担跟进成本。维护成本方面，README 没有给出支持周期、安全更新承诺或弃用时间表，只有一句请现有用户参考迁移文档。已经部署自托管的团队要注意，云同步依赖服务端，如果官方服务随项目一起收束，同步功能可能先于本地功能失效，而本地数据因为本地优先的设计，受影响相对小。这是一个从架构描述里能推出的判断，不是官方承诺。
编辑结论
已经在用 AIaW 并依赖本地数据与多工作区的团队，可以继续运行现有版本，但应先把 docs.aiaw.app/migration 的迁移说明读完，确认导出格式与 Nya AI 的导入路径匹配，再决定升级窗口。准备新选型的团队不要从这里开始，README 明确写着项目已被 Nya AI 取代，新项目提供大部分功能与一致的体验，从零接入等于主动选择一个停止演进的代码库。真正要先验证的一件事是自托管构建能否在你自己的环境跑通，也就是 pnpm i 之后 quasar build 或 quasar build -m pwa 是否产出可部署产物，以及 MCP 的 STDIO 与 HTTP 两种连接方式在你的网络里是否都能连通。
社区笔记