2026/6/29 · 8:18
Notion 社区周报 #007：复杂感、邮件退场和模块化自救
本期精选 6 条 Notion 社区线索：r/Notion 对复杂度和数据库回滚的担忧、Notion Mail 退场迁移清单、X 上的公式库与模块化系统思路，以及小红书里的 Plaud 输入系统和收入看板案例。
本期最值得留意的，不是某个炫技模板，而是社区在反复问同一个问题：Notion 到底该继续做成「什么都能装」的系统，还是先把几个关键工作流做稳。6 月 22 日到 6 月 29 日早间，我选了 6 条线索：两个来自 Reddit，一个来自官方帮助中心，两条来自 X，一条来自小红书，外加一个小红书案例补充。它们刚好把这周的分歧拼出来了。
| 线索 | 类型 | 先看什么 |
|---|---|---|
| Notion 变复杂了吗 | 设计反思 | AI、Calendar、按钮、自动化越来越多，但有人只想要干净工作区 |
| Notion Mail 退场 | 官方动作 | 9 月 22 日关闭，草稿、定时邮件、片段、自动标签指令要提前导出 |
| 大数据库怕误操作 | 操作风险 | 1000+ 行数据库遇到关系字段、批量编辑时，回滚仍是痛点 |
| Formula Box | 具体资源 | 约 120 个公式按场景整理，提示「AI 不能替代可检索的范例库」 |
| 模块化 Life OS | 设计思路 | 先建 Areas of Life 母数据库，再把各领域系统放进页面内部 |
| Plaud → Notion 输入系统 | 工作流案例 | 录音、任务、洞察、会议纪要不再一股脑倒进 Notion |
1. 「All-in-one」开始让一部分老用户烦躁
Reddit r/Notion 本周有个 90 分帖子，作者说自己过去喜欢 Notion，是因为它可以很简单，也可以很复杂；但现在 AI、Calendar、按钮、自动化和新的结构方式不断塞进来，他感觉「不是 Notion 不能复杂，而是越来越难保持简单」1。作者背景未公开，帖子发布于 6 月 26 日 23:21，评论区有用户直接说，自己只想用纯文本，却不断看到 AI、邮件、会议记录之类的入口。
コンテンツカードを読み込んでいます…
这条值得放在第一位，不是因为它提供了什么模板，而是它解释了很多 Notion 系统后来为什么会崩：不是功能不够，是入口太多。中级用户可以顺手做一个小检查：
- 首页只保留 3 个入口：收件箱、今天要做、常用资料。
- AI、自动化、按钮、Calendar 这类功能只放在具体流程里，不放在首页当装饰。
- 每个数据库只问一个问题：它解决「记录」「执行」「复盘」里的哪一个。如果三个都想解决，先拆开。
如果你最近也觉得 Notion 变吵，先别急着换工具。把首页减到只剩今天真的会点开的东西，通常比再复制一个 Life OS 模板更管用。
2. Notion Mail 确认退场，邮件工作流要分清「留在 Gmail」和「只在 Notion Mail」
官方帮助中心已经写明：Notion Mail 将在 2026 年 9 月 22 日关闭；从 6 月 25 日开始可以导出 Notion Mail-only 数据，9 月 21 日是保存这些数据的最后一天2。这不是普通功能调整。官方特别列出，草稿、定时邮件、Snippets、自动标签指令需要提前迁移；Snippets 里的附件、邮件提醒、Notion Mail 里的自定义视图也不会原样带到 Gmail2。
不用恐慌的是，收发过的邮件本身仍在 Gmail；Gmail AI Connector、Mail blocks、通过 Gmail 连接的 Agent 邮件工具也会继续运行2。真正需要处理的是「Notion Mail 这个壳子里独有的工作流」。
可以按下面这张小表排查：
| 你用 Notion Mail 做什么 | 该怎么处理 |
|---|---|
| 定时发送邮件 | 迁到 Gmail 的定时发送，别等 9 月最后一周 |
| 用 Snippets 复用回复 | 导出片段正文；有附件的手动下载 |
| 靠自动标签整理邮箱 | 保存自动标签指令，之后改用 Custom Agent + Gmail 尝试复刻 |
| 用 Notion 同步邮箱数据库做视图 | 旧视图能看，但 9 月 22 日之后不会再同步新邮件 |
3. 大数据库的真正风险不是公式写错，而是回滚不干净
另一条 Reddit 帖子问得更实际：作者有几个 1000 多行数据库，最怕误删关系字段或批量改错列；他认为原生版本历史很难精准找回某一行，Markdown/CSV 导出再导入又会断掉深层关系3。作者背景未公开，帖子发布于 6 月 27 日 06:14。
评论里有人只给出一个朴素替代方案：Notion 没有完整的「备份与恢复系统」，但数据库可以 duplicate3。这不是漂亮答案，但对日常维护已经够提醒人了。
我的建议是把「大改」当成一次小发布处理：
- 改关系、Rollup、Formula 之前，先复制整套相关数据库，而不是只导出 CSV。
- 批量编辑前加一个临时状态字段，比如「待改 / 已核 / 回滚」，方便筛回受影响行。
- 给核心关系字段写一页「字段用途说明」，避免三个月后自己也不敢动。
- 如果数据库已经超过 1000 行，不要在生产库里试公式。先在副本里跑一遍。
Notion 的灵活性很适合搭系统，但它不是数据库迁移工具。系统越大，越要给自己留撤退路线。
4. 公式库重新变有用：AI 能写公式，但它不一定知道你想问什么
X 上的 Mr. Pugo 本周发布了 Formula Box：他称自己整理了约 120 个 Notion 公式，覆盖 visual formulas、scoring and tracking、calculations、business formulas、life + habits formulas 等分类4。他不是大号，个人简介写着 Founder & Digital Creator，粉丝数 347；这条发布于 6 月 29 日 02:22，互动也不高。但它的判断很准：AI 可以帮你写公式，可你仍然需要知道要问什么、要怎么修、什么时候输出错了。
コンテンツカードを読み込んでいます…
这类公式库适合三种人：
- 想学公式但不想从文档零散查起的人；
- 已经会写公式，但经常忘记某类写法的人；
- 用 AI 生成公式后，需要一个人工范例做校对的人。
如果你在做自己的模板库，可以照这个方向建一个「公式样例数据库」：字段至少包含使用场景、输入字段、公式正文、预期输出、常见错误。AI 不是不能用，它更适合作为草稿机；真正能复用的是你自己验证过的样例。
5. 模块化系统比「一页管全部」更耐用
X 上的 Matthew 是 Notion Systems Architect，个人简介写着为 founders 搭建可扩展的 Notion 系统。他在 6 月 26 日 20:32 分享了自己的系统迭代：最早把生活和业务都塞进同一页，后来改成一个「Areas of Life」母数据库，再用 tabbed views 和各领域页面里的子系统承载具体内容5。
コンテンツカードを読み込んでいます…
这个思路比「再复制一个终极面板」更可取。它承认第一版系统一定粗糙，也承认不同生活领域需要不同粒度。你可以这样改：
- 建一个 Areas 数据库，条目是 Health、Work、Finance、Learning 这类稳定领域。
- 每个 Area 页面内部再放对应数据库，比如 Work 里放项目、客户、会议，Finance 里放账户、预算、账单。
- 首页只显示 Areas 的入口和少量跨领域提醒，不把所有表格都铺出来。
这样做的好处是，系统不会因为某个领域变复杂而拖垮整页。它更像文件柜，不像一张越贴越满的白板。
6. 小红书的两个案例：Notion 负责记录，不负责吞掉一切
小红书这周有两个案例都在讲同一件事：Notion 不一定是所有信息的最终归宿。
第一个是 James 的 Plaud 自动整理流程。他把 Plaud 当声音入口，把 Notion 定位为来源总账和知识沉淀，Todoist 只接真正要执行的任务，flomo 只收高价值洞察；低价值录音留在 Plaud，重要项目和会议才进入 Notion，任务还必须带来源上下文6。这条发布于 6 月 25 日 23:33，作者背景未公开。
第二个是 Wayne 的独立老师收入看板。他保留 Notion 做数据库，再用 AI 做外部看板，通过 Notion API 读取数据，重点看月收入变化、课数与收入是否同步增长、今年与去年对比、哪些月份贡献主要收入7。这条发布于 6 月 26 日 15:09，作者背景未公开。
这两个案例放在一起看，很像一个实用原则：
- 捕捉工具负责捕捉，比如 Plaud。
- 执行工具负责执行，比如 Todoist。
- 灵感工具负责短想法，比如 flomo。
- Notion 负责结构化记录和长期回看。
- 可视化不够时，不一定硬在 Notion 里凑图表，可以让外部看板读取 Notion 数据。
本周的 Notion 灵感就停在这里：少塞一点，分工清楚一点，系统反而更像系统。
関連コンテンツ
- ログインするとコメントできます。