Notion 太贵想换掉？这个 7.8 万星的开源工作区能接替多少，我逐项对了一遍

先说结论：AppFlowy 是个好东西，但它的「免费」和很多人想的不一样。

这条视频的文案其实写得挺克制——原话是「官方并未宣称功能和设计全面超过 Notion」。这句话是对的，也是这篇文章的出发点。网上把 AppFlowy 吹成「Notion 杀手」的文章很多，但没人告诉你 2026 年 9 月它悄悄改了自托管的授权方式。如果你正打算给团队搭一套「零人头费」的自建 Notion，先把这篇看完再动手，能省你不少返工。

AppFlowy 到底是什么

一句话：它是一个用 Flutter 写界面、Rust 写内核的开源协作工作区，定位就是 Notion 的开源替代。GitHub 上现在 78,056 个 star，6,142 个 fork，最新版本 0.14.11（2026 年 10 月 26 日发布），最近一次代码提交是 10 月 28 日——这个活跃度是健康的，不是那种拿完 star 就停更的项目。

这里有个技术细节值得单独说：它不是 Electron 套壳。现在市面上大量「桌面版」应用本质是把网页塞进 Chromium，开三个窗口内存就吃掉 2 GB。AppFlowy 的界面层是 Flutter（自绘渲染，不依赖系统 WebView），数据层是 Rust + SQLite，官方标称的安装包 Windows 版只有 87 MB。你在任务管理器里看不到一排 chrome.exe 子进程，这是它和同类产品最实在的区别之一。

平台覆盖也齐：Windows、macOS、Linux、iOS、Android，外加一个 Web 版。Linux 那边除了官方包，FlatHub 和 Snapcraft 都有收录，Debian/Ubuntu 用户直接 apt 也能装。

它能干哪些活

功能上分三大块，跟 Notion 的骨架是对齐的：

一、文档与团队 Wiki

层级页面、富文本块编辑、评论、@提及、页面版本历史，这些基础能力都有。文档可以无限嵌套，适合搭部门 Wiki、产品文档、会议纪要这类东西。有一点比 Notion 舒服：完全离线也能写，地铁上、飞机上、客户内网里都不受影响。

二、关系型数据库，九种视图

这是 AppFlowy 做得最认真的一块。同一个数据库可以切换成九种视图来呈现：

视图	典型用途
Grid（表格）	资产清单、客户名录、参数对照
Kanban（看板）	任务流转、招聘漏斗、故障工单
Calendar（日历）	内容排期、交付节点
Timeline（时间线）	项目排期、路线图
Gallery（画廊）	素材库、产品图册
List（列表）	轻量待办、检查项
Feed（动态流）	按时间倒序浏览记录
Chart（图表）	状态分布、数量统计
Form（表单）	对外收集需求、报修登记

支撑这些视图的是完整的字段体系：关联（relations）、汇总（rollups）、公式（formulas）、联动视图（linked views）、数据库模板、批量编辑，都在。

还有一个设计跟 Notion 一样、但很多人没注意到的关键点：数据库的每一行本身就是一个完整页面。也就是说，一条「工单」记录不光有编号、状态、负责人这些结构化字段，还能在下面写详细的处理过程、贴截图、加检查清单。这个设计决定了它能不能替代 Notion 做实际业务系统，而不仅仅是个表格工具。

和 Notion 逐项对一遍

不吹不黑，直接摆表格：

维度	Notion	AppFlowy
开源情况	闭源	客户端 AGPL-3.0；生产自托管服务端为商业许可
数据存放	云端为主	默认本地 SQLite，可选接云同步
离线可用	有限，首次打开必须联网	完整可用，无需账号
部署方式	只能用它家的 SaaS	SaaS / 私有云 / 自托管 / 气隙环境
数据库视图	最全，关联逻辑最成熟	九种视图齐全，复杂关联不如 Notion
模板生态	极庞大，社区产出多	明显偏小，多数要自己搭
网页剪藏	有官方浏览器插件	没有对应功能
白板 / 画布	有	没有，要视觉化请换 AFFiNE
移动端	打磨精细	能用，但明显落后于桌面端
多人实时协作	体验顺滑	功能有，手感差一档
AI 能力	Notion AI，按人头加价	可接本地模型，免费
费用（客户端）	免费层限制块数	完全免费，不限量

看这张表能得出一个很实用的判断：AppFlowy 强在「数据归你」和「不花钱」，弱在「生态」和「打磨程度」。如果你的工作流重度依赖 Notion 社区模板、网页剪藏、白板，那搬过来是给自己找罪受；如果你只是要一个能写文档、能管任务、能自己掌控数据的地方，它完全够用。

跟同类怎么选：AFFiNE、Outline、Docmost 摆一起看

搜「开源 Notion 替代」会跳出一堆名字，很多人卡在这一步。这四个是 2026 年真正还在活跃、口碑也稳的，各自的定位其实分得很清楚：

产品	最强的地方	明显短板	适合谁
AppFlowy	关系型数据库（九种视图）、全平台原生客户端、离线优先、可接本地 AI	生态小、无白板、无剪藏	要管结构化数据 + 要数据自主
AFFiNE	文档与无限白板一体，视觉化思维、画原型、头脑风暴	数据库只有表格和看板两种视图，比 AppFlowy 单薄	设计、产品、偏视觉的工作
Outline	纯文档 Wiki，界面和搜索体验最精致，团队知识库首选	几乎不做数据库，项目管理要靠别的工具	只想写文档、建公司 Wiki
Docmost	轻量，部署最省事，协作流畅	数据库功能弱，生态最小	小团队快速搭个协作 Wiki

选型其实就三个问题：你要不要管结构化数据？要不要白板？能不能接受自建？

三个都要就得分主次。我的排序建议是：需要管资产、工单、客户名录这类结构化内容的，选 AppFlowy；需要画图、做视觉规划的，选 AFFiNE；只是想把散落的 Word 文档集中起来让人能搜到，选 Outline 或 Docmost，别为了「功能多」去上 AppFlowy，配置成本不划算。

顺便说一句，AppFlowy 和 AFFiNE 不是互斥的。我见过有团队两个都装，AppFlowy 管数据和任务，AFFiNE 用来画架构图和流程图，各干各的活。

「本地优先」到底意味着什么

这个词被用烂了，具体到 AppFlowy 身上是三件很实在的事：

第一，不注册也能用。下载完打开，直接就是一个本地工作区，不需要邮箱、不需要登录、不需要连网验证。这对内网环境、对不想留手机号的人，是刚需。

第二，数据就是一个 SQLite 文件。备份这件事变得极其简单——把数据目录复制走就完了，不需要导出、不需要等它生成 zip、也不用担心导出丢了格式。反过来，恢复也就是覆盖回去。做过备份的人都懂，能直接复制文件备份的系统，和只能靠应用自己导出备份的系统，可靠性差一个量级。

第三，断网不影响。这一点在客户现场特别有用。你去客户机房调试，内网没有外网出口，Notion 直接白屏，AppFlowy 该干什么干什么。

能接本地大模型，而且免费

这是 AppFlowy 2026 年的一个明显加分项，也是很多测评漏掉的。

从 v0.8.7（2025 年 3 月）开始，本地 AI 对所有用户免费开放，通过 Ollama 接入，模型完全跑在你自己的机器上。设置路径是：打开 AppFlowy → Settings → AI Settings → 打开 Local AI → 填 Ollama 地址（默认 http://localhost:11434）。

官方点名支持 Llama 3.1、DeepSeek R1、Gemma 3、Phi4 这几款。因为我这边刚好在本地跑着 Qwen3，顺手测了 OpenAI 兼容接口，一样能接——只要 Ollama 那边起得来，模型名填对就能用。

实际能干什么、不能干什么，得分清：

能力	支持情况
AI 对话、问答	支持
文档摘要、提炼要点	支持
改写、润色、续写	支持
工作区内容检索（问 AI 你的文档）	支持
文生图	不支持，这块只能走云端服务

对中小企业 IT 来说，这个组合的价值在于：员工的文档内容一个字都不出内网，AI 照样能用。用云端 AI 处理公司内部制度、合同、客户资料，合规上一直是个灰区；本地模型 + 本地工作区，这个顾虑直接消失。代价是本地模型的能力和速度取决于你的硬件，8B 级别做摘要改写够用，别指望它写方案。

不过「支持本地 AI」这句话，建议你自己验一遍再拿去跟老板汇报。方法很简单，三步：

1. 断网测试——把网线拔掉或者关掉 Wi-Fi，然后打开文档让 AI 写一段摘要。能正常出结果，就说明模型确实跑在本地；如果转圈或者报错，那它偷偷走了云端。
2. 看端口——命令行执行 netstat -ano | findstr 11434，能看到本地 Ollama 在监听，就说明请求链路是通的本地链路。
3. 关外网出口——真要上生产环境，直接在防火墙层面封掉对外的 443 端口（只放开白名单），这样即使哪天配置被改回云端，数据也发不出去。

第三点是很多单位真正需要的做法。光靠「设置里选的是本地」不够，网络层封住才叫真的不让数据出去。这一套我们在客户内网部署时是标准动作。

重点来了：自托管在 2026 年 9 月变了

接下来这段是本文最有价值的部分，因为绝大多数中文教程还停留在旧信息上。

以前的玩法是：克隆 AppFlowy-Cloud 仓库，docker compose up -d，一台 2 核 4G 的服务器就能给自己团队搭一套，人随便加。网上那些「零成本自建 Notion」的文章全是这么写的。

但现在不一样了。我核实了 GitHub 上的仓库状态：

项目	状态	说明
AppFlowy-IO/AppFlowy	活跃	客户端本体，AGPL-3.0，78,056 星
AppFlowy-IO/AppFlowy-Cloud	已归档（2026-09-11）	旧自托管仓库，停止维护
AppFlowy-IO/AppFlowy-SelfHost-Commercial	当前生产版	采用 AppFlowy 自托管商业许可，不是开源协议

也就是说，AppFlowy 走上了 open-core 路线：客户端和 Web 端继续开源，生产用的自托管服务端改成商业许可。你在 2026 年 9 月之后如果还照着旧教程去克隆 AppFlowy-Cloud，装出来的是个已经没人维护的版本。

免费自托管层，只有 1 个席位

这才是真正的关键数字。当前自托管的免费层配额是：

• 1 个正式用户席位
• 外加最多 3 名访客编辑（只能编辑你共享给他的指定页面）

付费层级：One 计划仍然是 1 个席位（这条很多人会看错），Team 计划最多 1,000 席位，Enterprise 不限席位。

于是就出现一个很尴尬的结论：「自建服务器省人头费」这笔账，在 2026 年 9 月之后不成立了。

拿一个 10 人团队算一下：Notion Plus 每人每月 10 美元，10 个人一年约 8,600 元人民币；而 AppFlowy 自托管免费层只给你 1 个席位，想坐满 10 个人必须上 Team 计划，同时你还要自己掏服务器钱、自己负责备份和升级。这时候「省钱」这个理由已经站不住了，能站住的只剩「数据必须在自己手里」这一条。

反过来说，有一类人反而赚到了：个人用户、5 人以下小团队，根本不需要自托管。直接下客户端用本地工作区，功能完整、完全免费、没有席位限制、不需要服务器——这个用法所有限制都碰不到。

真要自托管，一次要动多少东西

如果确定要走自托管（比如客户有数据合规要求），提前知道这些能少踩坑：

• 容器数量：一次拉起大约 10 个容器（后端起 3~4 个服务，加上 PostgreSQL、Redis、MinIO、Web 前端、Caddy 反向代理）。
• 服务器规格：2 核 4 GB 是能跑起来的底线，25 人以内够用；再往上要加内存。
• 数据在两处：PostgreSQL 存结构化数据，MinIO（S3 兼容）存附件。两边都得备份，只备份数据库等于没备份，这是自建文档系统最常见的翻车点。
• HTTPS：Docker Compose 里自带 Caddy，域名解析对了会自动签 Let’s Encrypt 证书，不用自己折腾。
• 升级：会跑数据库迁移，动的是生产数据。文档多的环境先在测试环境跑一遍。
• 首次启动：MinIO 的桶不会自动建，第一次上传附件会报错，要先进 MinIO 控制台（9001 端口）手工建 appflowy 桶。
• 命令写法：用 docker compose（两个词），不要用 docker-compose（带横线），新版 Docker 上会报一堆看不懂的容器链接错误。

你们公司如果已经在跑 1Panel 或宝塔这类面板，这套东西装起来不难，难的是后面每个月得有人管它——打补丁、查备份、处理证书、应对同事「我文档打不开了」的报障。这笔人力成本，才是自托管真正的隐性开销。

一个法务层面的提醒

客户端是 AGPL-3.0。这个协议有个「网络条款」：如果只是内部使用，改不改代码都没风险；但如果你修改了 AppFlowy 的代码，再把它作为对外提供的网络服务（比如做成 SaaS 卖给别人），就必须把你整个系统的源代码开源。

做 IT 外包的同行要特别注意这一条。拿它给客户做内部的文档系统，没问题；拿它包一层做产品卖，先找法务。这不是危言耸听，是 AGPL 的明确设计意图。

从 Notion 搬过来，实际会遇到什么

这一节讲实操，因为「迁移」是决定用不用得起来的关键，而官方文档在这块说得比较轻。

Notion 的标准导出格式是「Markdown & CSV」，导出来是一个压缩包，解开后你会看到：一个满是嵌套文件夹的目录树（对应页面层级），一堆 .md 文件，以及每个数据库单独一个 .csv。导入 AppFlowy 时它会尽量还原，但有几件事要有心理准备：

内容	迁移结果
页面层级结构	基本能保住，深层嵌套建议先拍平一点
普通文本、标题、列表	正常
数据库的记录与字段值	能进，但需要手工核对字段类型（尤其日期、选择项）
relations（关联）	基本会丢，要重建
rollups（汇总）	会丢，因为依赖关联关系
formulas（公式）	通常变成静态值，公式要重写
附件与图片	文件都在，但路径要重新挂一遍
部分特殊块（折叠、提示框）	可能退化成普通段落，样式丢失

所以现实一点的做法是：不要指望一键全量迁移。挑一个不那么关键、但结构又有点复杂的库先试迁一次，把 relations、formulas 重建流程跑一遍，估算出「每 100 条记录要花多久」——然后你才知道整个工作区迁完是什么量级。按经验，一千页左右的工作区，认真迁需要几天，不是一下午的事。

还有一条更省事的路：新东西直接在新工具里建，旧内容只读归档。老工作在 Notion 里保持只读，新项目全部在 AppFlowy 里起。这样没有迁移成本，代价是两边并存一段时间。对很多团队来说，这反而是最实际的选择。

一个可以直接抄的落地用法

光讲功能比较虚，我给一个中小企业 IT 真能用上的场景：把「IT 资产台账」和「报修流程」用同一个工具管起来。这个场景正好把前面说的「数据库行就是页面」和「多种视图」用满。

第一步，建「IT 资产」数据库。字段设成：设备编号、设备类型（单选）、使用人、所属部门、采购日期（日期）、保修到期（日期）、状态（单选：在用/闲置/报废）。日常用 Grid 视图当台账看，切到 Calendar 视图按「保修到期」排，快到期的设备一眼就能看到——比在 Excel 里设条件格式省事得多。

第二步，建「报修单」数据库，挂一个 Form 视图。这是 AppFlowy 里最被低估的功能：表单视图会生成一个可分享的填写链接，员工点开就是干净的填空页，看不到你后台的其它数据。字段设成：报修人、部门、设备编号、故障描述、紧急程度、提交时间。发到公司群里就完事了，不用再拉微信群喊人。

第三步，切 Kanban 视图按状态流转。状态设成「待受理 → 处理中 → 待配件 → 已完成」。每天上班看一眼看板，哪台机器卡在「待配件」上超过三天，一目了然。这就是工单系统最核心的那点价值。

第四步，拿每一条记录当页面写。这是和用 Excel 管资产最大的区别：每张报修单点进去，下面可以贴故障截图、写排查过程、记录换了什么配件、留一句「下次同类问题先查电源」。这些经验沉淀在记录里，不会散落在聊天记录中找不到。新来的同事翻历史工单，等于看了一本现成的故障处理手册。

第五步，加一个 Chart 视图。按「设备类型」和「故障描述关键词」做分布统计，月底给老板汇报时，能直接说清楚「这个月打印机故障占了一半，建议整体换掉三台超保修的」。有数据支撑的建议和拍脑袋的建议，分量完全不一样。

这一整套不需要写一行代码，也不需要额外买工单系统。对 IT 只有一两个人的中小企业来说，这可能是 AppFlowy 最能立刻体现价值的地方。

它明确缺的东西

再好的工具也有边界，这几项 AppFlowy 现在确实没有，别到时候骂它骗人：

1. 白板 / 无限画布——完全没有。要做视觉化头脑风暴，去看 AFFiNE，那是它的主场。
2. 网页剪藏——没有对应的浏览器扩展。靠剪藏做资料收集的人，工作流要重做。
3. 模板生态——社区模板库比 Notion 小一个数量级，多数工作流得自己搭。
4. 移动端——iOS 和 Android 都有，但体验落后桌面端一档，重度手机办公的团队要先试。
5. 复杂关联数据库——relations 和 rollups 有，但成熟度不如 Notion，迁移前务必拿真实数据结构试。

谁该用，谁别用

适合：

• 个人知识管理、写作、研究资料整理——完全免费，离线，数据在自己盘上，零配置成本。
• 5 人以下小团队——直接每人装客户端，用共享链接协作，碰不到席位限制。
• 有数据合规要求的单位（医疗、律所、财务、政企）——内容不出内网，AI 也能本地跑。
• 内网 / 气隙环境——离线优先是它最大的结构性优势。

不建议：

• 重度依赖 Notion 模板和网页剪藏的团队，搬过去等于重建工作流。
• 需要白板的（转 AFFiNE）。
• 想给 10 人以上团队「零成本自建」的——2026 年 9 月之后这条路已经堵了，先算清席位费再决定。
• 指望本地 AI 帮你写方案的——8B 级别模型做摘要改写可以，写方案还差得远。

写在最后

AppFlowy 值得装，但值得装的理由不是「免费替代 Notion」，而是「你的数据不用交给别人」。这两个理由听起来像一回事，实际差很远——前者会让你在算完账之后失望，后者才是它真正不可替代的地方。

给你的建议是：先下客户端，用它当一个纯本地笔记工具跑两周。这个过程零成本、零风险，不注册不联网，随时可以删。两周之后你自然会知道，它到底能不能接住你的活。

如果你们公司在考虑自建文档系统，或者想把内部知识库和本地 AI 串起来，这块我们做过不少，可以聊聊具体情况。峰哥 17712677007，苏州本地可以上门看环境；外地的远程也一样处理，很多时候就是一台服务器加一套 Compose 的事。

文中方案如有疏漏，欢迎指正。技术选型没有标准答案，只有合不合适——有选型上的疑问，欢迎随时交流。