-
「稍后阅读」App 的分岔：Instapaper 回归阅读，Readwise 走向资料库
发生了什么？
去年 Pocket 关闭时，很多人都觉得，「稍后阅读」这类产品可能真的没什么新花样了。
我用了很长一段时间的 Readwise，现在却已经退化到只使用 Raindrop 这类书签管理工具，或者直接把文章发送到 Todoist 里。Readwise 的一大堆功能，我似乎都不太用得上，只是偶尔才会用到。
大多数时候，我只希望 Readwise 做好收藏，让我能在合适的时候舒服、安静地阅读而已。所以，我并不太关心 Ghostreader、AI 操作和大量自动分类之类的功能。
也许不少人收藏的内容越来越多，真正读完的却越来越少。每个人一天只有 24 小时，真正能够集中注意力的时间也就那么几个小时。
而且现在，浏览器已经有了成熟的阅读列表和书签工具，可以直接保存网页。更重要的是，这些年 AI 已经能够在几秒钟内总结一篇长文。为了「以后可能会读」而单独安装一个 App，看起来反而有些奇怪了。
没想到，到了 2026 年夏天，两款最有代表性的「稍后阅读」工具却几乎同时迎来了重大更新。（以前还有 Pocket，现在已经没了。）
近期，Instapaper 发布了十多年来规模最大的 iOS 更新，重建了网页版，并将 AI Voices 带到了 Android。
Readwise 则通过 Reader Public Beta Update，集中展示了 Global Ghostreader、Readwise V2、移动端对话、新版搜索，以及已经投入使用的增强版 MCP 和 CLI。
Readwise 和 Instapaper 这两个老牌的「稍后阅读」工具，正在走向两条不同的道路：
- Instapaper 仍然相信，「稍后阅读」首先应该是一个安静、简单，而且让人愿意打开的阅读器。
- Readwise 则正在把 Reader 和 Readwise 组合成一座资料库：我们不仅可以阅读和划线，还可以搜索、提问、引用和整理，甚至让 AI Agent 直接操作里面的内容。
我不止一次想过，当我们按下「Read It Later」按钮时，未必是在承诺：「我以后一定会读。」
更多时候，我们只是在想：
以后可能有用，我害怕失去它。
Instapaper 和 Readwise 的分岔，就发生在这里。
Instapaper 10：把一个经典阅读器重新做好
Instapaper 这次大规模重写了网站。新版网页加入了三栏阅读界面、多选功能和完整的键盘快捷键，同时提升了页面加载速度。
Instapaper 10 还重新设计了 iPhone 和 iPad App，新增了阅读字体、列表样式和主屏幕小组件，并改善了后台同步、文章下载速度和 iPad 多任务体验。
但我也有一种感觉：这就像商场总以为大幅翻修便能吸引新顾客。
这些都不是什么特别时髦的概念。
三栏界面让我们更容易在列表和正文之间切换；键盘快捷键让归档、移动和添加标签变得更加顺手；新的视觉样式让文章读起来更舒服；小组件则把收藏的内容重新放到用户眼前。
Instapaper 似乎相信，只要提供这些便利和更好的视觉体验，人们就更容易回来，把留到「稍后」的文章真正读完。
不过，它并没有假设每个人都需要将未读内容清零，也没有要求用户先搭建一套复杂的整理系统，更不会让人产生一种仿佛必须把阅读库变成个人知识管理系统（PKM）的错觉。
这次甚至连唯一显眼的 AI 功能：Android 上的 AI Voices，本质上也仍然服务于更舒适的阅读体验。
AI 被用来提供更加自然的语音，把「看文章」变成「听文章」，而不是在列表上方放一个对话框，替我们决定这些文章究竟是什么意思。
但话说回来，这也不是什么新鲜事了，对吧？都 2026 年了，一些媒体网站甚至已经自带「朗读」按钮了。
新版发布后，有人说新的外观让自己从 Raindrop 重新回到了 Instapaper；也有人不适应重建后的网页，询问能否继续使用旧版，或者反馈同步和阅读进度方面的问题。
作为 Raindrop 用户，我没有太大动力回到 Instapaper。仅仅换一个地方做同样的事情，还不足以打动我。
作为一个已有近二十年历史的老工具，Instapaper 不需要我们重新学习一套阅读哲学。我觉得它本身是一个了不起的工具，但时代或许已经变了。
Readwise V2：朝着资料库方向一去不返
Readwise 的情况复杂得多。
2026 年 8 月发布的 Reader Public Beta Update，更像是一次阶段性汇总。Readwise V2 已经在不久前正式发布，更完整的云端搜索功能也在更早之前开始测试，新版 MCP、CLI 和预制 Skills 则在此前陆续推出。
在 8 月这轮更新中，Global Ghostreader 和 Reader 移动端的对话功能被推到了前台。
过去，Ghostreader 主要围绕当前打开的文档工作。我们可以让它解释一句话、总结一篇文章，或者围绕某个段落继续提问。
现在，Ghostreader 可以在整个资料库中查找相关内容，从不同文档里抽取段落，再附上可点击的引用来回答问题。
它还拥有可以重复使用的 Skills，并且能够调用工具，为文档添加标签、撰写笔记、保存新内容和修改元数据。
比方说，我可以问它：
我保存过哪些反对把个人知识库完全交给云端 AI 的观点？
这已经不是传统意义上的「阅读辅助」了，而是我在上文提到的、截然不同的另一条路：直通 AI 加持下的个人知识库。
讽刺的是，为了回答「有哪些观点反对把个人知识库完全交给云端 AI」这个问题，我需要先把自己的阅读记录和收藏内容全部交给 Readwise 的云端服务管理。
Ghostreader 会先检索整个资料库，再组织答案。我们也可以让它找出最近保存但尚未处理的相关文章，推荐合适的标签，或者将一批低优先级内容移出 Inbox。
如果觉得 Readwise Reader 自带的 AI 不够强劲，Readwise MCP 又把这套能力开放给了 Claude、ChatGPT、Codex 和 Cursor 等外部 AI 客户端。
AI Agent 可以执行全文搜索和语义搜索，获取文档与划线内容，创建笔记，添加或移除标签，修改元数据，也可以在 Inbox、Later、Shortlist 和 Archive 之间移动内容。
这些功能确实让我感到兴奋。它们足够出色，也顺应潮流。
但转念一想，我仍然认为这些信息应该保存在本地，而不是托管在 Readwise 那里。为了让 AI 访问自己的资料而增加一层云端托管，似乎有些多余。
尽管如此，看到 Readwise V2，我还是挺兴奋的。只不过在个人选择上，我仍然更加偏好「本地优先」。
最后，真正改变的是……
如果只制作一张「功能对比表」，那么 Instapaper 和 Readwise Reader 仍然都是典型的稍后阅读工具。
它们都能保存网页、清洗正文、离线阅读、划线、搜索和使用语音。
但它们想要解决的问题已经不一样了。
一个希望你回归阅读的本质，保持克制和保守；另一个则希望你积累更多资料，建立更大的资料库，完成更加复杂的工作，甚至远远超越阅读本身，成为思考过程的一部分。
这本身没有对错，最终取决于用户的偏好和目标。
用户可以自行选择，通往目标的路并不只有一条。产品有差异，用户有选择的余地，这本身就是一种「幸福」。
传统的「稍后阅读」工具有一个隐含假设：我们要亲自打开并读完保存下来的内容。每多收藏一篇文章，就像多欠下了一笔注意力债务。
但这套逻辑建立在 AI 出现之前。现在，情况已经发生了变化。
我甚至觉得，不先经过 AI 的提炼就直接阅读，似乎有点对自己的注意力不负责任。当然，即使 AI 很擅长减少我们必须亲自阅读的内容，它也不能替我们完成所有真正有价值的阅读。
关于 Readwise MCP 的实际使用讨论中，已经出现了这类工作流。
有用户让 AI 分析自己的阅读时段和阅读习惯，再据此设计 Filtered Views；也有人让 Agent 自动为每天新增的内容打上标签，或者区分哪些文章只需要阅读摘要，哪些文章值得阅读全文。
Instapaper 似乎还没有引入这类工作流，我觉得这是它目前最大的问题。
即使产品选择保持克制和保守，一切以良好的阅读体验为中心，也至少应该提供相应的接口，例如 MCP 或某种 API，让其他工具，尤其是 AI，能够访问其中的内容。
即使文章都保存在本地，我也会引入这样的访问机制。毕竟，本地文件天然具备被其他工具访问的条件。
归根结底，「稍后阅读」仍然是「稍后阅读」。
但未来真正发生重大变化的一定是：
由谁来稍后阅读。
-
【速报】Notability 实行订阅制四年后，又把一次性买断请回来了，而且带来了 Android 版
就在上个月（2026 年 7 月），知名的手写笔记 App Notability 宣布，重新向所有用户开放一次性买断的 Classic 方案。而在本月（2026 年 8 月），Android 版也已上架 Google Play。
关于买断（一次性购买），官方的说法是：用户反复表达「我喜欢 Notability，但我不想再多一笔月费」，所以他们决定听取这些声音，面向只需要核心功能、又不愿接受订阅的用户，恢复 Classic 买断方案。
而在 2021 年 11 月，Notability 曾从一次性付费 App 转向「免费下载 + 年度订阅」。这一变化在当时引发了很大争议，尤其是已经付费买过 App 的老用户，一度担心自己买到的功能也会在一年后失效。官方很快承诺老用户可以继续终身使用原有功能，由此才有了后来的 Classic 老用户方案。
现在，四年多之后，Notability 又转身回到了买断制。
2021 年的那次订阅转向
Notability 曾经是 iPad 上最有代表性的付费笔记 App 之一。
它把几件最重要的事做得很到位：手写体验稳定，可以导入和批注 PDF，录音会和书写时间同步，回放时点一下笔记中的任意一处，就能听到当时讲到了什么。对学生、教师、采访者和经常开会的人来说，甚至值得为它单独配一台 iPad 和 Apple Pencil。
当时的商业关系也很简单：用户付一次钱，买下一个笔记工具。
2021 年 11 月，Notability 11.0 上线，App 本身改为免费下载，高级功能则转为年度订阅。考虑到要支撑持续运营以及 Notability Gallery 等在线服务，我觉得倒也合理，尤其是对手写笔记有刚性需求的重度用户来说。
问题不在于订阅本身，而在于老用户以为自己已经买下来的东西，会被重新收走。我以前买断过一些 App，后来它们陆续都推出了订阅方案，不过一般会保留原有的买断权益，或更名为 Legacy 方案。
Notability 当时也是如此：官方随后承诺，所有在 2021 年 11 月 1 日前购买过 App 的用户，可终身保留已有功能、无限编辑和 iCloud 同步。这就是后来所谓的 Classic 用户。
Classic 回来了，但订阅并没有离开
这次重新推出的 Classic 买断，价格相当直接：按照官网目前的定价，返校季优惠期间售价 39.99 美元，App Store 内购买则是 49.99 美元。官方把它称为一次性购买，即没有自动续费，也不需要每年重新付钱。
Classic 包含的主要功能有：
- 无限数量的笔记
- 手写识别与手写内容搜索
- 将手写数学公式转换为 LaTeX
- 实时协作
- 通过 Notability Cloud 跨设备、跨平台同步
- 7 天版本历史
需要说明的是，早年 Classic 老用户拿到的承诺是 iCloud 同步，而新版 Classic 已经切换到官方自建的 Notability Cloud，覆盖范围反而更广。对于在 2021 年订阅转型之前就买过 Notability 的 Classic 老用户，这次不需要再付一次钱：官方会免费把他们升级到新版 Classic，并逐步提供 Notability Cloud、协作和跨平台同步等新能力。
单看这份清单，Classic 已经覆盖了绝大多数人理解中的「完整笔记 App」。写字、批注 PDF、整理文件、搜索手写内容、备份与同步，这些都不需要继续订阅。
但 Notability 并没有因此放弃 Lite、Plus 和 Pro 这些订阅方案。
- Lite：价格最低的无限笔记订阅。
- Plus：加入录音转写、AI 生成的测验与闪卡、YouTube 视频转笔记，版本历史延长到 30 天。
- Pro：提供不限量转写、实时摘要、与笔记对话等更完整的 AI 学习能力，版本历史 90 天。
后两档所依托的，是官方称为 Notability Learn 的一整套 AI 学习功能。官方对它显然很有信心。
换句话说，Classic 买到的是一个长期可用的核心笔记工具，而不是「今后 Notability 推出的所有功能」。
音频转写和 Notability Learn 都不包含在 Classic 中。未来如果出现新的高成本云端功能，官方也没有说一定会免费加进买断版。按照正常的商业逻辑，订阅专属的新功能大概率不会自动下放到买断版，否则谁还去订阅？
所以，这次回归的是一个边界清楚的基础层。这样挺好，大家各取所需。
买断与订阅，本来就不必二选一
长期以来，大家习惯把买断和订阅看成非此即彼的两条路。好像只要保留一次性购买，团队就没有收入，产品就会停止更新；而一旦采用订阅，所有用户都必须持续付钱，哪怕他根本用不到云端服务和 AI。
现在看来，中间其实还有很大的空间。
手写、PDF 批注、文件管理和本地编辑，主要消耗的是一次性的开发成本，适合用一次性价格出售；AI 对话、云端转写、实时协作、跨平台存储和较长的版本历史，则会持续产生模型、带宽与服务器开销，更适合、也应该走订阅。
只想要一张稳定数字纸张的人，可以买 Classic；偶尔使用又不介意持续付费的人，可以选择 Lite；需要音频转写和 AI 学习工具的学生，可以订阅 Plus 或 Pro。Classic 用户日后临时升级订阅，取消后仍会回落到原有的 Classic 权益，不会失去买断资格。
题外话：微软的 Office 其实也保留了单机买断版本，只是价格偏高，且缺少 AI 和部分新功能（也许普通人根本用不上）。总体上，微软显然还是希望大家去订阅 Microsoft 365。我个人不太喜欢这套路数，之前的文章里我也说过，Office 这类文档软件已经是基础设施，用户理应对自己的文件保有所有权。
为什么偏偏是现在？
官方把这次变化归因于用户反馈和订阅疲劳。这当然是真的，但应该不只是这个原因。
过去四年多，Notability 确实获得了可观的订阅收入，也把产品从 Apple 生态里的手写 App，逐步扩展成一个包含 Web、协作、云同步和 AI 学习功能的平台。如今官网首页上，iOS、Android、Web 三端下载已经并排列出，这在四年前是不敢想的。
但竞争对手也一直在提醒 Notability：用户并没有放弃买断。手写笔记的另一代表 Goodnotes 6 （下图）在上线时就同时提供年度订阅和一次性购买，后来又把方案整理为面向 Apple 设备的 Special Edition 与跨平台订阅。两家公司最终都走向了类似的分层，基础数字纸张可以买断，跨平台云服务和高级 AI 继续订阅。
更重要的是，笔记不是一项可以轻易搬家的服务。用户一旦存下几百本课堂笔记、PDF 和录音，迁移成本只会越来越高。正因为数据会长期沉淀，用户才格外在意：自己有没有一条即使停止付费也能继续工作的底线。有 Evernote 的前车之鉴，这一代用户早就被市场教育过了。
现在应该怎么买？
如果你本来就是 2021 年 11 月之前的付费用户，先别急着再次购买。只要购买记录仍然对应原来的 Apple ID，理论上就属于被「继承保留」（grandfathered）的 Classic 老用户，可以免费获得新版 Classic。如果后来订阅过 Plus，取消订阅、等当前订阅周期结束后，也会回到 Classic。如果系统没能正确识别，再联系官方支持处理。
如果你是第一次使用 Notability，又只需要手写、PDF 批注、录音、手写搜索和基本同步，我会优先推荐 Classic。一次性付费之后，不必每年思考是否续订，这很符合笔记工具应该有的稳定感。
如果你的主要目的是课堂录音自动转写、生成摘要、制作闪卡和测验，或者希望直接和笔记对话，那么 Plus 或 Pro 才是完整方案。为了省订阅费而买 Classic，最后发现最常用的功能恰好都在 Learn 里，就没有意义了。
如果你只是偶尔记几条内容，免费的 Starter 目前允许保留最多 5 篇笔记，可以先体验手写与编辑工具。若需要无限笔记但只是短期使用，Lite 的年费也比 Classic 的一次性价格更低。
最后
Notability 把一次性买断请回来，值得肯定。我还是那句话：有选择总归是好事。
不过，Classic 也不等于 Notability 简单地回到过去。过去的买断模式，是用户付一次钱，期待未来不断免费更新；如今的混合模式，则是把稳定的本地核心能力卖给用户，把真正持续产生费用的云端和 AI 服务留在订阅层。
这倒是一种更健康的关系。
Notability 官网
-
【速报】Airtable 将卖身 Bending Spoons，而 Obsidian 顺手递上了数据迁移工具
Bending Spoons（下图为官网截图，展示旗下的产品） 就是那家买下 Evernote 的公司。而就在宣布收购 Airtable 计划的同一天，Obsidian 的官方导入器正式支持 Airtable。
我在判断一款生产力工具是否值得长期使用时，不会只看它今天有多少功能，还会问一个更朴素的问题：如果这家公司明天换了主人，我的数据还能不能完整地带走？
最近，类似 Evernote 的命运突然落到了 Airtable 用户面前。巧的是，买家还是当年收购 Evernote 的那一家，Bending Spoons。
据报道，Bending Spoons 已经与 Airtable 达成收购协议，将以现金收购这家知名的在线数据库公司。消息出来之后，网上很快浮现出熟悉的担忧：会不会裁员？会不会涨价？免费版会不会进一步缩水？那些已经在 Airtable 里跑了好几年的业务流程，会不会被重新改造一遍？
几乎在同一时间，Obsidian 更新了官方 Importer，正式加入 Airtable 导入功能。它给出的方向也非常 Obsidian：不要只是从一个在线数据库搬去另一个在线数据库，而是先把记录、字段和关系变成本地 Markdown 文件，再用 Bases 把它们重新组织成表格。
我觉得时机恰到好处。每一次云端工具被收购或重组，用户都有理由重新担心自己的数据。
当然，这并不是 Airtable 这款产品本身的问题，它只是又一次提醒我们云端工具共同的风险。
Airtable 以远低于巅峰估值的价格卖身
截至本文写作时，双方只是达成了最终收购协议，并不意味着交割手续已经全部完成，更不意味着 Airtable 即将停止服务。
按照媒体披露的口径，Bending Spoons 支付的是现金对价，而这个数字与 Airtable 在 2021 年融资时达到的 117 亿美元峰值估值相比，已经大幅缩水，甚至可能低于它历年融资的总额。
但我要强调：这不代表 Airtable 是一款失败的产品。
我个人很欣赏这款产品。事实上很多年前，我们也做过类似 Airtable 的东西，国内到今天也还有一些同类产品在运营。
Airtable 是成熟的低代码数据库工具。它把关系型数据库包装成普通人也能理解的表格，支持 Linked records、Lookup、Rollup、公式和多种视图。很多团队并不是拿它做一张简单清单，而是把它当成一个完整的业务系统在跑。作为一个长期写生产力工具的博主，我留意它很久了。
而这正是 Airtable 最有价值、同时也最容易锁住用户的地方：一般人以为不过是些表格数据，导出 CSV 就完事了；但深度用户早已围绕这些数据搭起了一整套工作流，而工作流是很难导出的。
又是 Bending Spoons
如果收购方是 Atlassian、微软这类老牌软件公司，用户反应可能不会这么大。
但 Bending Spoons 已经收购过 Evernote、WeTransfer、Vimeo、Meetup、AOL 等一大批知名互联网产品。它的玩法也相当清楚：收购拥有稳定品牌和用户群的成熟软件，重组团队、统一技术与运营体系，压低成本、改善利润，再用现金流继续收购更多产品。
Evernote 被收购之后经历了大规模团队调整，免费版限制收紧，订阅价格明显提高；WeTransfer 被收购后也有类似动作。这已经形成了一种很强的市场印象：Bending Spoons 很擅长让老牌软件重新赚钱，但这个过程未必让所有人舒服。
当然，事情也有另一面。
有一说一，Evernote 被收购之后并没有停止更新，反而在同步速度、移动端性能和产品功能上做了大量改进，不少长期用户认为新版本比过去更稳定、更积极；只是价格也确实涨得更辣手，免费用户和轻度用户承受了更多限制。到底是变好还是变坏，取决于你站在哪一层。
所以，不能简单断言 Airtable 被收购之后一定会怎样。但可以合理预期的是，定价与免费额度的分层策略大概率会更激进。仅仅是这一点变化，就足以让一个在 Airtable 里放了好几年重要数据的人，认真考虑一下后路。
Obsidian 的反应很快，但不是一晚上赶出来的
收购消息发布之后，Obsidian 社区很快开始传播一条非常应景的信息：现在可以把 Airtable 转换成本地的、可长期保存的 Markdown 文件和 Bases。
从时间上看，确实像是隔壁刚宣布换老板，Obsidian 立刻把搬家公司的车开到了门口。
但这个功能并不是临时赶工。这个需求从以往记录来看，已经提出好几个月了，只是很巧，它最终赶在 Airtable 收购消息传出的同一天正式发布出来。
目前的 1.9.1 导入器的改进：
- 导入速度大幅提升；
- Rollup 直接导入 Airtable 已经计算好的值；
- 空 Rollup 结果不再在 frontmatter 里写成
NaN； - 指向未选中表格的链接，会显示记录名称，而不是
Unknownxxx；
以前我们也可以在 Obsidian 里搭建本地数据库式的视图，但要把已经沉淀在 Airtable 里的数据搬过来，仍然得导出 CSV、写转换脚本，或者依赖第三方插件。现在官方 Importer 可以通过 Airtable 授权直接读取 Base，整个迁移的门槛低了一大截。这点我很喜欢。
每一条 Airtable 记录，变成一个 Markdown 文件
Obsidian Bases 和 Airtable 长得有点像，但底层思路完全不同。
在 Airtable 里，一行是一条云端数据库记录。它住在 Airtable 的系统里，字段、关系和视图都由 Airtable 解释。我们可以下载 CSV，但 CSV 只是一张拍扁的表，很多关系、公式和产品行为不会跟着一起离开。
在 Obsidian 里，每一条记录可以变成一个独立的
.md文件：字段写进文件顶部的 YAML frontmatter（也就是 Obsidian 里的 Properties），正文仍然是普通 Markdown。表格只是这些文件的一种视图，由.base文件负责筛选、排序、分组和展示。也就是说：不再是数据住在表格 App 里，而是表格 App 临时读取我们自己的文件。
这两句话看起来差不多，实际差别很大。
导入之后，即使 Obsidian 有一天不再维护，你依然可以：
- 用任何文本编辑器打开每一条记录；
- 用 Git 查看修改历史；
- 用 Dropbox、iCloud、Syncthing 或 NAS 同步；
- 让 Python、命令行工具和 AI Agent 直接读取。
.base视图可能需要 Obsidian 来解释，但也不难理解，真正的内容和属性仍然留在普通文件里。这就是 Obsidian 一直强调的 File over App：文件先于 App 存在，也长于 App 存在。
能搬走数据，未必搬得走业务
Importer 能把 Airtable 数据转成 Markdown 和 Bases，不代表 Obsidian 已经是 Airtable 的完整替代品。这还差得很远。
对于书单、选题库、客户资料、设备清单、研究资料、个人 CRM、简单项目列表这类「一条记录本来就很像一篇笔记」的数据，Obsidian 的模型非常自然。记录变成文件之后，还能在正文里继续写长文本、插图片、链到其它笔记，而这恰恰是 Airtable 不擅长的方向。
但如果一个 Airtable Base 已经依赖下面这些能力，迁移就不可能一键完成：
- 多人权限管理；
- 表单收集与对外展示页面；
- 邮件发送、Webhook、定时触发之类的自动化逻辑；
- 大量复杂公式、Lookup、Rollup 和跨表业务逻辑；
- 与 Slack、Google Workspace、Salesforce 等外部系统的连接；
- 把 Airtable 当作其它应用后端的 API。
尤其要注意公式和 Rollup。Obsidian 方面说明写得很明白：导入的是「Airtable 已经计算出来的值」，这和把计算逻辑本身迁移过来完全是两回事。导入当下的数据是完整的，但上游字段一旦变化，本地文件不会自动重算。
所以，把 Obsidian Importer 理解成一个优秀的个人数据迁移工具更合适，而不是企业数据库或业务系统迁移器。
不急着放弃，但要做备份
如果我们大家目前仍然满意 Airtable，完全没必要因为一条收购新闻就立刻停掉所有业务。立刻放弃，本身也并不能自动解决锁定问题。
真正合理的解法是：让底层数据至少存在一份开放、完整、可验证的副本。上层工具可以继续用，也可以随时换。
更稳妥的做法，是趁服务一切正常的时候，把下面几件事做完：
- 盘点一下：哪些 Base 只是普通资料，哪些已经承载自动化和关键业务。
- 原样备份：用 Airtable 自带的导出功能保留原始 CSV，另行下载附件，同时记录公式、视图、自动化与外部集成的配置。
- 试跑导入：在一个单独的 Vault 或测试文件夹里，用最新版 Importer 做一次完整导入。
- 逐项校验：检查记录数量、关联记录、附件、日期、单选/多选字段和 Rollup 结果，不要只看表格第一页。
- 并行运行：新旧系统并行一段时间，确认确实可用之后，再决定哪些内容继续留在 Airtable。
至于要不要真的搬家，我的判断是：
- 个人资料库、内容日历、研究表格、简单 CRM ：我会很认真地考虑迁到 Obsidian。这些数据本来就适合成为 Markdown 文件，而 Bases 的筛选、排序、公式和多视图已经够用。
- 多人协作的运营系统 ：别搬到 Obsidian 了吧。轻量用途先看看 Excel、Google Sheets 能不能顶上。
- 承载大量业务逻辑的系统 ：老老实实先续费，同时找机会自建或重构。反正现在有 AI 帮忙，重构系统在有经验的人手里，也不算太难。
最后
我并不认为所有软件都该本地化，也不认为云端服务一无是处。
Airtable 的价值恰恰来自云端：团队成员打开浏览器就能共同编辑，同一份数据可以同时驱动表单、视图、自动化和外部应用。要在本地完整重建这些能力，成本高到不现实。
所以更实际的姿势是：继续使用方便的云端工具，同时让数据定期落到自己控制的格式里。 个人知识和长期资料，直接用本地文件；团队业务系统，至少保留结构化导出、附件副本、字段说明和自动化文档。
收购只是最容易让大家注意到风险的那一刻。真正的不确定性还包括涨价、封号、公司转型、功能下线、地区限制、API 变更，甚至只是某一天你自己不想再续费了。
如果所有价值都藏在某个 App 内部，那么每一次变化都会变成危机；如果 App 只是文件之上的一层界面，变化就只是一次工具选择。而「选择权」才是最重要的东西。 这也是我欣赏 Obsidian「File over App」的地方。
-
笔记与任务的边界正在消失？从 Craft 3.5 的 All Tasks 说起
笔记和任务
笔记和任务之间的分界线已经越来越模糊。
开会时，在笔记中写下一句「周五前把完善的报价单发给客户」；写某篇文章草稿时，有了一个灵感，顺手留一个下篇文章候选的主题；做旅行计划时，又在文档里勾出「订酒店」和「买保险」。这些东西最初看上去很像是笔记的一部分，但写下来的那一刻，它们又变成了任务。
待办事项如果留在原文档里，那么显然上下文很完整，却也很容易被淹没在笔记海洋里；如果复制到 Things、Todoist 或 Microsoft To Do 这类专门的 Todo App 里，确实不会忘记，但列表里往往只剩一句没头没尾的「跟进一下」「搞一下」（我最讨厌这种偷懒的表达），过几天还得回头找它到底在说什么，如要补充或回想上下文的话，还是会额外耗费很多精力。
所以，很多笔记软件走到后来，都会忍不住把手伸向任务管理。Notion 有跨数据库汇总的 My Tasks，Evernote 也早就可以让任务留在笔记中、但同时出现在统一的 Tasks 视图里，Capacities 最近也把「带上下文的任务」做成重点功能。
现在，我个人比较欣赏的笔记文档工具 Craft 终于走出了这一步，Craft 3.5 推出了更复杂的「任务视图」 。
这次最重要的变化，不是 Craft 终于可以在文档里打勾了——这个早就能做到——而是它终于把散落在整个 Space、各个文档、Daily Notes、Page 和 Collection 里的待办，真正收进了一个可以统一管理的地方。
以前的问题：写任务方便，找起来麻烦
Craft 的任务一直有一个很自然的起点：它首先是文档里的一个 Block。
我们可以在项目方案、会议记录、读书笔记或每日笔记里，把一行文字直接变成待办。任务可以设置 Schedule、Deadline 和 Reminder，也可以重复；下面还能继续放说明、链接、子任务甚至更多页面内容。
这套设计很适合真实工作，因为任务并不是凭空出现的，有真实上下文。
比如：「修改文案」通常来自一次产品讨论；「联系供应商」来自一份采购计划；「补一张对比图」来自正在写的文章。让任务留在这些文档里，显然比把它单独抄到一个列表里更合理。这点对于其他类似的笔记工具都完全适用，这里只是拿 Craft 作为一个说明的例子。
不过，任务只要一多起来，文档上下文的优势也会立刻变成弱点。
我们记得自己还有事情没做，却未必记得它藏在哪一篇文档里。过去 Craft 已经有 Inbox、Calendar 和一些按文档查看任务的能力，但如果想确认「整个资料库里还有哪些待办没有完成」，体验仍然不够直接。查询和过滤是一种对用户有一定要求的主动行为。
这也是 Craft 用户社区里长期出现的抱怨：任务可以散落在任何地方，却缺少一个真正完整的总览。很有意思的是，在 3.5 发布之后，我看到 Craft 社区里的一条反馈就是：终于来了。
All Tasks：所有文档多了一层索引维度
Craft 3.5 现在提供四个主要任务入口：
- Inbox：先快速记下来、暂时还没有归属的任务
- Today：今天计划处理的任务，包括之前遗留下来的项目
- Upcoming：未来几天、几周或几个月已经安排好的任务
- All Tasks：整个 Space 里所有文档中的任务
All Tasks 才是这次更新的核心。
它会把散落在不同文档里的任务集中到一张列表中，可以按照文档分组，按照计划日期或截止日期排序，也能使用筛选，并把重要文档固定在顶部。藏在 Page 或 Collection Item 下面的任务，还会带着一个「来源标记」，这个标记提醒我们它并不是一条孤零零的待办。
All Tasks 替笔记建立了一层统一索引。在任务中心打勾、改日期或者调整安排，原文档里的同一条任务也会同步变化；从原文档操作，Today 和 Calendar 里的状态也会一起更新。
这就解决了笔记与任务之间最麻烦的矛盾：执行时需要总览，真正动手时又需要上下文。
我在四五年前的那个创业产品里，就已经强烈建议产品经理，应该做到笔记中的内容可以被另一个视图快速整合，例如：Todo，例如某个标记，又例如某个项目索引……这种 Block 级别引用再整合才是真正的生产力。不过很遗憾，后来产品由于其他原因脱离了设想的轨道，那是另外一个故事。
Craft 3.5 已经做到了一部分，而且有潜力做得更多。实际上，已经有部分产品可以做到了「再索引」「再整合」，但是对用户的要求比较高，一般不太讨好，比如：Obsidian 的 Dataview，LogSeq、Tana Outliner 的「超级标签」，Roam Research 的块级引用和查询……
从文档里来，还要回到文档里去
只有 All Tasks，还不足以让 Craft 变成一套真正可用的任务系统。一个待办列表如果录入慢、改日期麻烦、每次都要打开多个面板，很快就会被用户放弃。
所以这次更新还有一批看起来零散、实际很重要的改进。
在 Craft 的任何位置按下
Command + J，可以直接创建任务；选中一个 Block，也能用快捷键把它转换为任务并安排日期。新的任务窗口会浮在当前工作内容上方，不需要离开正在编辑的文档。多选也终于变得实用了。我们可以一次选中多条任务，批量安排日期、设置 Deadline、完成或移动。Today 视图在取消分组之后支持手工排序，这个顺序还会反映到 Calendar 和 Daily Note 中。
Calendar 这一层也被重新整理。安排了日期的任务会和日历事件、每日笔记放在一起；当天完成的任务会留在当天，形成一份简易的工作记录。Apple Reminders 中今天和未来的提醒事项，也能出现在相关视图中。
日期选择器现在支持自然语言输入，可以在安排任务时顺便设置具体时间的提醒。到了 3.5.2，Craft 又补上了几个细节：任务改期时，原本属于当天的提醒会跟着移动；选中多条任务后，还可以直接把它们生成一篇新文档。
笔记软件为什么都想吃掉任务管理？
从用户角度看，最直接的原因当然是少切换一个 App。加入任务之后，笔记就从静态信息变成了工作现场。
我一直往待办事项的「描述」字段里面填入事件的「上下文」，举个很常见的例子，如果去订酒店，很自然就会在描述字段中把酒店的名称、订单号、日期、地址之类的信息补充进去。任务提醒时，就不用再去翻其他订票 App 或网站查询信息了，直接就可以在待办事项现场进行参考或处理。
但我觉得更深一层的原因是：笔记记录的是「我知道了什么」，任务记录的是「接下来要做什么」。如果一款笔记软件只能保存前者，它就很容易变成一个不断囤积、很少回访的资料仓库。
再举一个常见的例子，会议记录也不只是会后归档，它应该在明天把需要跟进的事项重新推到我们面前；项目文档也不只是背景资料，它应该还告诉我们下一步要做什么；Daily Note、Calendar、Reminder 和文档之间才能开始形成交互循环。
而且到了 AI 时代，笔记和任务的边界会继续变模糊。
AI 可以从会议记录里提取行动项，从研究文档里生成下一步计划，也可以根据截止日期重新安排今天的工作。可是，如果笔记在 Craft，任务在 Todoist，日历在另一个 App，AI 想理解整个项目，就必须跨越多个系统、处理多套权限和数据结构。
把内容、任务和日历放在同一个上下文里，显然更容易讲出「AI 工作空间」的故事。这也是为什么任务管理不是笔记软件随手添加的一个小功能，而正在变成它们争夺工作入口的关键一层。我个人推崇的是，信息可以被统一索引访问，最好在本地，未必是在一个封闭的 App 里，但无论如何不应该被割裂在几个封闭的App里。
这就是，虽然 All-in-one 的诱惑很大，代价也同样明显：软件会越来越复杂，原本只想安静写字的用户，可能并不欢迎侧边栏里不断增加的新入口。而且随着 AI 能力越来越强，我们大脑对上下文的处理可能越来越依赖 AI，笔记软件或待办事项都得向后退一步。
试想，如果我们把所有的行程安排、会议记录以及所有的事情，一股脑都跟同一个 AI 助理说，让它来整理安排事项，那么 AI 就是一个秘书。我们不用记那些事情，不需要使用什么 App 工具；许多公司的管理层就是这样运作的，只不过他们有一个真人秘书罢了。
这就像是个鱼吃鱼的过程，一环想吃掉另一环，最终总有一环想取代我们所有身边发生的事情。所以与其说，笔记和任务的边界变得模糊，不如说对一些人而言所有事情的边界可能都将变得模糊。
Things、Todoist 之类的工具还有用武之地吗？
专业任务管理器经过多年打磨，在快速录入、视图、优先级、标签、筛选、重复规则和细节交互上，仍然更成熟。Things3、Todoist（下图）、TickTick 并不会因为 Craft 多了一个 All Tasks 就突然失去价值，甚至对原本的核心用户群都很难有影响。
待办事项的核心用户是任务已经庞杂到无法轻易管理的那一类人。如果笔记中的待办事项达到那个层级的话，笔记本身也已经膨胀到另一个高度了，可能更适合一个庞大的业务系统，而不是单纯的一个笔记软件或个人待办提醒系统可以解决的。
Craft 3.5 这次改进，其实尤其适合不想维护一套复杂 GTD 系统、只希望别再忘记文档里那些待办的人，但总的来说是一个轻量系统。
如果工作需要团队分派、复杂依赖、精细标签、成熟自动化，或者已经在 Things、Todoist、TickTick 中形成了稳定习惯，还是得靠那些专业的任务管理工具甚至业务系统。就目前而言，这点对其他笔记自带任务管理的工具也同样适用。
最后
总的来说，Craft 3.5 这次的方向，我觉得是非常合理的。大量任务本来就诞生在文档里。把它们重新索引、统一安排，又不丢失原始上下文，是一个自然而然的需求。
All Tasks 做的事情听起来很普通，无非是把所有待办放到一起。但对于文档型笔记软件来说，这恰好是非常棒的「快捷方式」。
而最终不少笔记App其实不仅想吃掉任务管理，还想吃掉一切。在 AI 加持下，这个趋势越发明显，看看 Notion 就知道了。Notion 变成了一个工作台，如果接受它的理念和便利，那么所有一切事情几乎都要经过它，关于这点，我想我会另外撰文讨论一下。
不管怎么样，Craft 是我挺欣赏的一个工具，很期待能看到它有更多关于生产力提升方向的发展。
Craft 官网地址
-
用 AI 处理 Office 文档，未必只有 Copilot：看看 OnlyOffice 带来的选择权
虽然现在已经是 2026 年 ，但仍然有很多公司在使用微软的 Office 系列。大量文档的格式被锁定在其中，成为历史遗留的一部分；也有很多公司和个人早已形成习惯，用 Word 处理文档，用 Excel 处理表格。尤其是表格，历史上 Excel 实在太成功了，成功到变成了不少公司的业务基础。
尽管在线的文档、表格和演示文稿已经很多，但当人们想要一份保存在本地的 Office 文件时，仍然很难不想到微软 Office。
只是， Office 也有自己的问题。大多数人用不到其中复杂的功能，只需要一些基础的处理，却要承担高昂的授权费用。现在微软又推进订阅制，并绑定了自家的 AI，也就是 Copilot。
所以今天只要一说「Office 文档结合 AI」，很多人的第一反应就是微软 Copilot。Word、Excel、PowerPoint 本来就是微软的产品，Copilot 又被直接放进了这些软件里。写一份报告，让 AI 帮忙改写；打开一张表格，让 AI 分析数据；给它一份 Word 文档，让它生成演示文稿，这条路线听起来几乎顺理成章。
而且 Copilot 并不是只有一个聊天框。如果公司已经把文件、邮件、会议和协作都放在 Microsoft 365 里，它可以借助 Microsoft Graph 调用我们有权限访问的邮件、聊天和文档。微软最近还在继续强化 Word、Excel 和 PowerPoint 中的 Agent 能力，Excel 里甚至已经出现了编辑、规划和聊天三种模式。
所以，我并不是说 Copilot 不好，也不是说 Office 不好。我想说的，和此前文章一贯的观点一样，始终是「选择权」的问题。
如果我只是想在 DOCX、XLSX、PPTX 或 PDF 里使用 AI，但更喜欢 Claude、Gemini、DeepSeek、Mistral，或者干脆想在本机运行 Ollama；如果我希望 AI 是可以更换的，而不是跟着 Office 订阅一起打包；那么我还有没有别的选择吗？
这时候，OnlyOffice 提供了另一条很有意思的路线。
它最强大的地方，不是做了一个比 Copilot 更聪明的模型，而是：它允许我们使用任何模型，也就是所谓的 BYOK（Bring Your Own Key）。
我最早想写这篇文章，是因为有个客户在使用 Nextcloud，向我咨询自部署在线 Office 的事情。Nextcloud 本身可以通过连接器接入 OnlyOffice，于是我顺手试了一下，结果发现它提供了非常开放的 AI 集成，这恰恰是微软没有做到的。
OnlyOffice 不只是一个免费的 Office 替代品
很多人第一次见到 OnlyOffice，会觉得它只是一款长得比较像微软 Office 的免费办公软件。
OnlyOffice 桌面版是一套免费的跨平台办公软件，可以在 Windows、macOS 和 Linux 上运行（部分 Linux 发行版会直接预装 OnlyOffice，作为默认的办公套件）。文字文档、电子表格、演示文稿、PDF 和表单被放在同一个带标签页的应用里。桌面版可以离线打开本地文件，源代码也公开在 GitHub 上，采用 AGPL v3 许可证。
截至目前，它虽然还没有微软 Office 那么庞大，但早已不是只能做简单排版的轻量替代品。对于个人、家庭和小型企业这类一般的文档表格需求，OnlyOffice 在功能性上绰绰有余，Ribbon 式界面也让传统微软用户更熟悉，而且还是免费的。
OnlyOffice 有一个很明确的产品取向：把 DOCX、XLSX、PPTX 这些 Office Open XML 格式当作主要工作格式，而这些格式都是开放标准，不是专有格式。
文件格式是否被锁定，一直是我个人很看重的一点。Markdown 之类的格式之所以能大行其道，正是因为格式彻底开放。
也正因为如此，当一套软件已经可以比较可靠地承载日常 Office 文件时，它再接入 AI，才真正有意义。否则 AI 写得再好，文件打不开、格式错乱，一切都是白费。
最重要的是模型选择权
微软 Copilot 的逻辑，是把微软提供的 AI 能力融入 Microsoft 365。它的优势是省事，而且可以和 OneDrive、SharePoint、Outlook、Teams 以及企业权限体系打通。对企业用户来说，考虑到既有投入，这是一条不错的延续路径。
OnlyOffice 的思路则更像一个「AI 插座」。我们可以自己接入 OpenAI、Anthropic、Google Gemini、DeepSeek 等服务，也可以连接任何兼容 OpenAI API 的其他模型——大多数第三方服务和企业内部的定制开发，如今都会沿用这套兼容规则。
更进一步，不同任务还可以分配给不同模型：文本生成用一个，摘要用另一个，图片、语音、视觉分析或代码辅助再各用其他模型，从而在性能、质量和成本之间自行权衡。
比方说，我可以让擅长长文本的模型修改报告，让成本较低的模型做翻译和摘要，让视觉模型理解图片；以后某个模型涨价、降级或者停止服务，也可以随时换掉，甚至在本地算力足够的情况下，直接改用离线的本地模型。
配置路径本身并不复杂，大致就是「插件 → AI → 设置 → 添加供应商」，填入 API Key、选择模型和用途，有时候还要补一个 Base URL。
这种模式当然没有 Copilot 那么开箱即用，对完全不想碰设置的用户，这肯定不算优点。不过想必各位最近也没少折腾这类工具，什么 Hermes Agent、OpenClaw、OpenCode……走的都是同样的 BYOK 模式。
对我来说，工具链一直是需要优先考虑的事情：Office 编辑器是一层，AI 模型是一层，文档文件又是另一层。三者可以协作，却不必永远捆在一起。不该有任何一家同时锁定我的模型、我的工具和我的存储——而这恰恰是很多 SaaS 产品的梦想：尽可能垄断用户的选择权。
AI 已经不只是帮我们续写几段文字
早期的 Office AI 插件，大多是「选中一段文字，然后让 AI 摘要、翻译或改写」。这当然有用，但本质上和把内容复制到 ChatGPT、再粘贴回来没有太大区别。
OnlyOffice 最近两年的变化，是 AI 开始真正操作文档环境。
现在的 AI 插件不仅能在文档、表格、演示文稿和 PDF 编辑器中完成生成、改写、总结、翻译以及语法拼写检查，还能自动生成并编排内容——这就是所谓的 Agent 操作。
例如在文字文档里，我们可以让它：
- 续写一段内容
- 改写当前段落，并保留修订痕迹
- 在批注里解释选中的术语
- 根据内容直接生成一份演示文稿
这和单纯「问 AI 一个问题」完全不同。AI 开始知道我们正在操作的是一份文档，结果也不只停留在侧边栏里，而是可以变成标题、表格、格式、批注、修订和表单字段。
不过需要特别提醒的是，AI Agent 目前仍然带着 Beta 标签。它能做什么，很大程度上取决于编辑器已经开放了哪些工具、所选模型能不能正确调用这些工具，以及当前文件是否足够规范。它还不是万能的 Office「自动驾驶」系统，但方向已经相当清楚了。
把自己的提示词，做成 Office 工具栏按钮
OnlyOffice 最近有一个很实用、却很容易被忽略的功能，是「自定义 AI 助手」。
我们可以给助手取一个名字，写好固定提示词，再选择结果如何回到文档里：
- 只显示建议，不修改原文
- 直接替换选中的文字
- 一边给出提示，一边执行替换
设置完成以后，这个助手就会出现在 AI 工具栏里。以后选中文字，点一下即可，不用反复输入同一串要求。
比如，我可以做几个自己的按钮：
- 精简表达：删除套话和重复表达，但保留原意、数字和专有名词
- 合同风险：只标出可能存在歧义或责任不对等的句子，不直接改写
- 商务口吻：把内部说明改为礼貌、清晰的客户沟通语言
- 提取事实：只提取时间、人物、金额、任务和截止日期
在我看来，这相当于在 Office 里自制微型工作流。对于每天重复处理固定格式文档的人，可能比任何花哨的功能都实用。
本地模型：与 Copilot 最不同的地方
如果只是把 ChatGPT API 接进 OnlyOffice，数据仍然要发送给在线模型。它解决了模型选择问题，却没有自动解决隐私问题。
真正不同的地方，是 OnlyOffice 还可以连接 Ollama、LM Studio、LocalAI 等本地服务。如果不方便把内部草稿发给公共 AI 服务，不希望按用户购买统一的 Copilot 订阅，或者身处没有外网访问权限的环境，本地模型就可以派上用场了。
不过以目前的技术水平，普通笔记本要流畅运行足够实用的本地模型仍然非常非常吃力，对多数人来说还不太现实。但等到时机成熟，本地 AI 会像今天的手机一样普及，真正自主的 AI 也就不再是奢望。
最后
OnlyOffice 最有价值的地方，并不是它能不能在所有功能上正面击败微软 Office。至少目前，它不能；在深度兼容和性能速度上，也还存在一些问题。
这一点我想再重申一次：如果各位深度使用微软 Office，诸如复杂的表格、图表、宏、定制的 VBA 程序等等，那么出于兼容性考虑，微软 Office 仍旧是最好的选择。据我所知，甚至有些私募机构的核心运算都建立在 Excel 之上，这方面微软有着无可撼动的优势。
微软还有几十年的积累，Copilot 又可以调用 Microsoft Graph，把邮件、会议、聊天、组织权限和文档连接起来。对于已经「住在」Microsoft 365 里的企业，这种整合非常强大，也很难复制。
但 OnlyOffice 提供了另一种我更喜欢的结构：Office 文件属于文件系统，编辑器可以替换，AI 模型也可以替换。妥妥的「工具链」模型。
如果说， 微软 Copilot 的目标是把我们更深地带进 Microsoft 365 订阅；OnlyOffice 的强项则是让 AI 来到文档旁边，却不会因此成为文档、账号、模型和工作流的唯一主人，用户仍旧具有选择权，甚至可以替换 OnlyOffice 的能力。
OnlyOffice 官网地址
-
AI 工作台一定要住在云端吗 – 最近火起来的 Rowboat，把 AI 的长期记忆写回了 Markdown
现在有不少 AI 工作台，似乎很自然地都把信息扔在了云端。
我们在 ChatGPT、Claude、Notion AI 或其它在线工具里聊天、上传文件、连接邮箱，然后期待 AI 可以慢慢理解我们的工作。
但是，当一个 AI 真正开始接触邮件、会议、项目和联系人时，另一个问题就浮现了出来：这些逐渐积累起来的工作记忆，到底属于谁？ （下图为 ChatGPT memory）
如果换一个模型、取消订阅，或者某个产品突然调整方向，AI 对我们的了解还能不能一起带走？
我个人更倾向于上下文都囤积在本地，AI 模型只是一个可选供应商的模式。我用 Codex 就是这样做的，至少理论上，就算 Codex 不存在了，换上 OpenCode 也可以继续工作，就是界面会略有不同。
但这不是全部，很多日常工作并不是完全基于本地 Codex 的，还是将大量上下文托付给了云端，确切地说是绑定了 AI 供应商。
最近在 Hacker News 和 GitHub 上火起来的 Rowboat，给出了一个很有意思的答案：AI 可以调用云端模型，也可以在本地运行，但它的长期记忆不必锁在某个厂商的数据库里，而是可以写回我们自己电脑上的 Markdown 文件。
截至我写这篇文章时，Rowboat 的 GitHub 项目已经超过 1.6 万颗 Star。它是 Y Combinator 项目，采用 Apache-2.0 许可证，支持 Windows、macOS 和 Linux。2026 年 7 月，它又以「开源、本地优先的 Claude Desktop 替代品」登上了 Hacker News 首页。
不过，我觉得如果仅仅把它说成 Claude Desktop、Codex 的替代品，反而低估了它真正有意思的地方。
Rowboat 不只是另一个 AI 聊天框
Rowboat 把自己称作一个「有工作记忆的 AI coworker」。它不是只提供一个聊天窗口，而是试图把我们日常工作中的几个主要界面放到一起，包括：
- 邮件客户端
- 会议记录
- Markdown 笔记
- 内置浏览器
- Code Mode
- 后台 Agent
- 可以自己生成的工作 App
这些界面背后共用同一个被称为 Brain 的知识层。邮件、会议、Slack 对话以及和 AI 的聊天，会被整理为人物、公司、项目和主题等节点，再通过双向链接连接起来。
最近比较火的另一个产品 Scape，也是类似的风格，将邮件收件箱、会议记录和待办事项融为一体，成为一个新的工作平台入口。
举个例子，某个客户在邮件里提出了一个改功能的要求，几天后的会议又修改了优先级。Rowboat 的目标不是把两份原始内容随便塞进什么 RAG 向量数据库，等我们下次提问时再抠字眼、做向量搜索，而是持续更新这个客户和项目对应的笔记，把当前状态、历史决定、承诺和待办事项保留下来。
下一次再让 AI 准备会议材料、起草回复或者制作路线图，它不必等我们重新解释一遍背景。
这听起来似乎只是「更强的 RAG」，但两者的重心不太一样。传统 RAG 更像临时检索：提出一个问题，系统去一堆资料里寻找可能相关的片段。Rowboat 更像让 AI 平时就整理工作，把散落的信息压缩成一批持续更新的主题笔记。前者关心「这次找到了什么」，后者更关心「关于这个人和项目，我们现在知道什么」。
当然，这也是 Rowboat 最需要经过长期检验的地方。邮件中的同名人物能不能准确合并？项目改名之后会不会产生重复节点？一封营销邮件会不会污染联系人图谱？旧信息和新信息冲突时，AI 会不会悄悄覆盖掉重要背景？
我个人觉得这是另一种形式的「记忆」，最早是纯文本存储，然后是向量化存储，现在则按照语义上下文进行整合后存储。
最有意思的是 Markdown
如果 Rowboat 只是把这些信息保存在自己的本地数据库里，我觉得它的吸引力会小很多。大家知道我最不喜欢那种封闭结构。我喜欢直接可以打开的 txt、markdown、json、html 这类，PDF 在我这里都要打个折扣了。
真正让我感兴趣的是，它把知识图谱中的节点保存为普通 Markdown 文件，并且使用类似 Obsidian 的双向链接。我们可以在 Rowboat 里浏览和修改，也可以直接把这个目录当作 Obsidian Vault 打开。
这意味着，AI 的长期记忆第一次变成了一批我们可以直接阅读的文件。
AI 要是误解了一个出现人物的身份，我们可以打开笔记直接改掉。要是项目状态过期了，我可以手工修正。要想知道它最近改了什么，可以用 Git 查看差异；想备份，可以使用 Dropbox、Syncthing、NAS 或任何习惯的工具；以后不再使用 Rowboat，这些 Markdown 文件也仍然存在。
这整个风格和我现在的其他工作流（主要是基于 Obsidian + 文件同步）非常接近了。
很多 AI 产品都在宣传「Memory」，但这些 Memory 通常更像产品内部的一种能力。我们很难完整看到 AI 记住了什么，也不知道它在什么时间修改过，更难把这些记忆交给另一个工具继续使用。
而 Markdown 把记忆从某个 App 的功能，变成了用户拥有的数据。它不保证 AI 一定记得正确，却至少允许我们检查、纠正、备份和迁移。相比一个号称无所不知、实际上完全看不见的黑盒，我反而更信任这种有点笨、但可以打开查看的方式。
工作界面，比一个万能聊天框更合理
Rowboat 最近加入的 Work Surfaces，也很符合我对 AI 工作台的理解。
邮件就应该在邮件界面里处理，会议就应该在会议界面里记录，网页研究最好发生在浏览器里，代码则应该留在代码工程和版本差异中。聊天可以用来表达意图，但没有必要承载所有的工作。
Rowboat 的邮件界面可以区分重要邮件，并结合长期上下文生成回复草稿；会议记录工具会读取电脑的麦克风和扬声器，不需要让一个机器人加入会议，结束后再把摘要和行动项写回 Markdown；内置浏览器与日常浏览器隔离，只登录我们愿意交给 Agent 操作的账号；Code Mode 则可以调用 Claude Code 或 Codex，让编码 Agent 使用会议和项目中的背景信息。
更进一步，我们还可以让它根据需求生成一个小型工作 App。比如，把邮件、会议和 Slack 里的功能要求收集起来，做成一个排序面板，再让编码 Agent 根据排在前面的需求准备实现方案。
这和单纯让 AI「帮我做个网页」不太一样。小 App 不是一次性的展示结果，而是连接在同一个工作记忆上，可以继续被后台 Agent 更新。
我一直觉得，让 AI 发生在上下文里，比在任何地方都弹出一个聊天框更加自然。Rowboat 在产品结构上好像理解了这一点。
本地优先，并不等于完全离线
不过，看到「local-first」时，还是需要保持一点警惕。
Rowboat 的 Markdown Vault 的确保存在本机，应用也不必依赖 Rowboat 自己的服务器。模型可以选择 Ollama 或 LM Studio，在电脑上本地运行；也可以使用 OpenAI、Anthropic 等托管模型。（说实话，本地运行现在还是比较吃力的，而且成本也惊人。）
但只要选择在线的 AI 模型，发送给模型的上下文仍然会离开电脑。类似地，语音转文字可以使用 Deepgram，语音输出可以使用 ElevenLabs，网页搜索可以接入 Exa，其它外部工具还可能通过 MCP 或 Composio 连接。
所以，Rowboat 更准确的说法应该是：数据的主副本和长期记忆可以放在本地，但实际计算和外部动作是否留在本地，取决于我们的配置。**我不想让人产生一切都是「本地的」的误解。
本地 Markdown 解决了数据所有权和迁移问题，却不会自动解决隐私、安全和合规问题。如果我们把整套公司邮箱交给云端模型处理，文件最后保存在本机，并不代表中间的数据从未出门。
另外，本地文件本身也需要保护。邮件、会议和联系人被整理成可读的 Markdown 后，一旦电脑或同步目录泄露，别人甚至不需要懂某种专有数据库格式就可以直接阅读。因此，备份、同步范围和账号权限，反而比以前更值得认真设置。
另外 Rowboat 虽然是开源的，但也不等于绝对安全。它只是让代码可以被检查，并不代表真的已经有人替我们完成了完整的安全审计。
评价不错，但也有争议
Rowboat 最近的热度不低，支持者最喜欢的部分也很一致：开源、模型无关、Markdown 可读，以及不必把长期记忆押在一个云端厂商身上。
我看了一圈，有人认为它塞进了邮件、浏览器、笔记和编码等太多功能，自己真正需要的只是一个安静运行、可以通过 Git 审阅结果的 Agent；也有人担心，AI 工具不断生成摘要、邮件和报告，最后不是减少工作，而是制造更多需要人阅读和验证的内容，这对用户也是一种负担。考虑到有些用户想要的是放弃自己思考的所谓「第二大脑」，自然这种需要亲力亲为的工具就不受待见。
另外，一些功能的成熟度仍然有限。目前邮件重点仍然是 Gmail，非 Google 邮箱用户并不方便；知识图谱我个人觉得很鸡肋，Obsidian 也一样，我从来不用。
还有，各位自己用了就知道了，这类工具都要自己配置的，一堆 API 配置，权限管理也远比普通笔记软件复杂。什么「开箱即用」那是做梦了，至少要有折腾复杂配置的觉悟。
Rowboat 现在更适合愿意尝试前沿 AI 工作流、能够理解模型和权限边界的个人用户或小团队。对于需要多人协作、严格合规、成熟管理后台和稳定技术支持的企业来说，它肯定不是一个可以直接全面部署的成品。
而且，如果我们的工作主要是临时问答、翻译和偶尔写一篇文章，根本没有多少跨越数周和数月的项目上下文，那么这套长期记忆系统很可能显得过重。这就是我前面说的，对我而言 Codex 以外还有很多工作其实没有本地记忆。
AI 记忆只有不断积累时才有价值。如果没有长期稳定的工作线索，知识图谱就只是一个更加复杂的空文件夹。
最后
那么我们回到开头的问题：AI 工作台一定要住在云端吗？
我的答案是：不一定。
真正需要区分的，是 AI 工作台的每一层到底放在哪里：
- 工作文件和长期记忆由谁保存？
- 模型在哪里计算？
- 外部工具通过什么权限连接？
- Agent 的操作能不能被看见和撤销？
- 换掉 App 或模型之后，数据还能不能继续使用？
未来一段时间比较现实的方案，很可能不是完全本地，也不是完全云端，而是一套「混合架构」。强大的在线模型继续负责复杂推理，而本地模型处理敏感或简单任务，用户自己的文件系统保存长期记忆。
在这样的架构里，模型是可以替换的计算资源，App 是可以替换的操作界面，Markdown 才是长期留下来的数据层。
这也是我觉得 Rowboat 最值得关注的原因。它今天未必已经是最成熟、最好用的 AI 工作台，甚至有可能因为功能铺得太开，走上一条很难维护的路。但它至少提出了一个正确的问题：
AI 可以越来越了解我们，但这种了解不应该只能存在于某个公司的云端。
Rowboat 官网
Rowboat GitHub
-
【译】Notion 正在变成一个臃肿的烂摊子？
写在前面
我先声明，我无意打击 Notion 的爱好者和资深用户。Notion 是一款优秀的笔记工具和信息组织工具，甚至被一些小企业当作轻量数据库和业务管理工具使用。虽然在我看来，多数小企业并不适合把 Notion 当作核心业务系统，市面上显然还有更专业、更稳定的选择。
但是走到今天，Notion 似乎已经忘记了初心，越来越像另一个 Evernote。
Evernote 曾经是明星独角兽，早期的用户体验也相当出色，但数据被牢牢锁在云端，随后又开始走大而全的路线，什么都想沾一点。再后来，产品迭代逐渐失去方向，用户受到越来越多限制，价格却不断上涨，最终经历出售和重组，被新一代笔记工具取代，逐渐淡出主流用户的视线。最后留下来的，往往是那些大量数据已经沉淀其中、却又难以迁移的用户。讽刺的是，当年取代 Evernote 的「后浪」中，就有今天要说的 Notion。
另一个问题，是无处不在的 AI。我觉得 AI 本身很有用，但它也毁掉了不少原本简单、克制的工具，让它们不断膨胀，最后变成怪物，有点像《指环王》中的「魔戒」：强大，却也容易让人迷失。说句题外话，我曾经熟悉的 Taskade 也是一款新颖的「小而美」工具，主打整合待办事项、思维导图和项目管理；但在这两年 AI 叙事的加持下，它现在已经变成了一个「怪物」。
也许 AI 本身就会摧毁很多传统软件。传统软件在找不到更好出路时，似乎只能给自己贴上 AI 标签，仿佛这样才能继续活下去。这和当年互联网泡沫时期很相似，许多传统企业硬说自己是互联网公司，再包装出一些与主业无关、近乎天方夜谭的项目。
所以，当我最近看到下面这篇文章时，几乎没有犹豫，就想把它分享给大家。不只是因为文章中的许多观点让我产生了强烈共鸣，也是因为它再次提醒了我：不要重蹈当年 Evernote 用户的覆辙，包括我自己。
以下正文，原作者：Michael Swengel，原文链接：https://medium.com/@michaelswengel/notion-is-turning-into-a-bloated-mess-2240d0e4be1f 火箭君翻译并略作编辑。
正文
很长一段时间里，我是 Notion 的忠实信徒。每当我重装 Windows 或 macOS 系统时，Notion 总是名列我首批需要快速重装的应用清单前列。因为，它保存着我所有重要的笔记。
工作笔记、个人笔记、食谱，甚至还有我的一些财务记录（现在看来，这可能不是个好主意）。
我曾深爱着 Notion。但后来，出于对 Notion 在隐私保护方面相对薄弱的担忧，我转投了 Obsidian 的怀抱。对此我毫无怨言，也毫不后悔。
而在最近几周，看到 Notion 的种种举动，让我更加确信自己的决定是正确的。Notion 已经忘却了它的初心，正在变成一个彻底的「烂摊子」。
Notion 曾经的辉煌
当我还在使用 Notion 时，我纯粹因为它的特质而喜爱它：一个简单却功能强大的笔记工具，完美契合我的思维方式。我对它了如指掌，能够快速、轻松地在其中穿梭。简直爱不释手。
它处理表格、图片和富文本的方式堪称绝妙。我根本不需要多想，只需把各种内容扔进笔记里，然后就可以抛之脑后了。
这正是 Notion 用起来如此令人愉悦的原因。它与我协同工作，而不是与我作对。它懂我想要做什么，哪怕我无法清晰地表达出来。而且，它的呈现方式总是那么优雅美观。
这款应用设计精良，运行流畅，哪怕是在配置极低的「老爷机」上也能跑得动。真是太棒了。
日益增长的担忧
然而，当我开始思考我在 Notion 中存储的所有数据的隐私问题时，我的幻想破灭了。你看，我用它记录了多年的个人笔记、业务信息、内容创意，甚至还有一些我绝不希望被外人窥探的极其私密的数据。
我知道 Notion 声称拥有相当不错的安全性，而且至今仍这么说。但如果没有端到端加密，同样不可否认的事实是：虽然我的数据在静态存储时是加密的，但 Notion 团队依然掌握着所有的解密密钥。
如果别人手里有钥匙，那我把门锁上又有什么用呢？
过去（现在也是如此）没有任何机制能真正阻止 Notion 的内部人员，无论普通员工还是恶意破坏者，在未经我知情或允许的情况下访问我的私人数据。
我无从得知我的私人数据是否真的……私密。
就在那时，我转向了 Obsidian。
迷失方向
从那时起，我一直关注着 Notion。尽管我现在非常喜欢 Obsidian，但 Notion 依然是我的 first love。我内心深处一直期盼着 Notion 团队有朝一日能幡然醒悟，意识到端到端加密绝非微不足道的细节，而以非专有格式存储数据的能力也绝非锦上添花。它们是不可或缺的基础。
然而，Notion 却来了一个急转弯，朝着相反的方向狂飙突进。
Notion 团队没有去打造一个更安全、更面向未来的工具，反而一头扎进了泥潭，将全部筹码押注在人工智能上。
当 Notion 专注于做一个出色的笔记工具时，它确实做到了。抛开安全隐患不谈，我认为没有人会否认这样一个事实：Notion 曾是世界上用于记笔记和整理信息的最佳应用之一。
但现在呢？Notion 似乎想同时成为 ChatGPT、Zapier、Slack 以及一大堆其他工具的集合体，结果却每一样都没做好。
专心做好一件事
我认为古老的 UNIX 哲学在这里非常适用。做一件事，就做一件事，并且把它做到极致。如Doug McIlroy （火箭君注：Unix 早期重要推动者，Unix哲学提出者）所言：「让每个程序做好一件事。如果要承担新的任务，请重新构建，而不是通过添加新功能来使旧程序变得复杂。」
背后的逻辑很简单：避免臃肿，避免不必要的复杂功能，维护好核心产品。
然而，Notion 却把这种哲学揉成一团，扔进了垃圾桶。
Notion 把它曾经做得极好的一件事拿来，试图在上面强加 日历（Notion Calendar）、邮件（Notion Mail 稍后会详细讲）、智能体（Agents）、Notion MCP 等等，这早已远远超出了我们曾经认识并喜爱的那个核心简单的小巧工具。
这就是问题所在。
Notion 不再专注于把一件事做好。它现在变成了一个由各种产品拼凑而成，而且拼凑得支离破碎的生态系统。
是平台还是工具
在我看来，Notion 似乎正试图超越一个简单工具的范畴，膨胀成一个臃肿的软件平台，靠着胶带和梦想把一系列功能和连接器强行拼凑在一起。
Notion 已经不满足于仅仅做一款笔记软件了。它想要掌控你整个数字生产力生活。而这，是我绝对无法安心接受的。
画地为牢，彻底锁定
我跳船到 Obsidian 的一个重要原因，是内心始终萦绕的恐惧：如果 Notion 明天就消失了，我的数据会怎样？
诚然，这不太可能发生，但也并非绝无可能。软件的兴衰更迭，在软件世界里是再正常不过的事。
把时间（甚至可能是金钱）投入到一个我无法保证它不会突然消失并带走我所有数据的软件中，这让我感觉很不好。（火箭君注：如果早10年，这就是我面对 Evernote 一样的恐惧，而且事实证明，有些担心早晚会发生）
我很高兴看到 Notion 坚持了这么多年，但我的这种担忧也同样持续了这么多年。当你使用 Notion 套件时，你就是在选择被锁定在一个以非标准格式存储数据的系统中，而且存储位置完全不受你控制。
换句话说，你的数据任由 Notion 摆布。如果 Notion 宕机了怎么办？如果你的账户被盗了怎么办？那你就完蛋了。
这理应让大家感到害怕。反正它已经足以让我吓得弃船逃跑了。
受够了 AI 的狂轰滥炸
我累了。我对这种持续不断的 AI 推销感到无比厌倦。AI 越来越像是一个企业界的流行语，被肆意地撒在任何东西上。
我已经受够了。
但 Notion 呢？Notion 正在全力押注 AI，将自己标榜为「为你工作的 AI 工作空间」。让我作呕。
当我最初接触 Notion 时，我并不是冲着 AI 来的。我开始使用它，是因为 Notion 在记笔记和存储信息方面表现得极其出色。
后来他们添加了 AI 功能，并推出了付费的 AI 工具，我并不介意。事实上，在当时，我还对它们的 AI 能力感到印象深刻。感觉还挺不错的。
但那是在 Notion AI 仅仅作为 Notion 用户的得力助手的时候。而现在，它喧宾夺主了。
今天呢？这个是 AI，那个也是 AI，到处都是 AI。以至于 Notion 现在被冠以「AI 工作空间」的名号。
这感觉就像是 AI 发起的一场恶意收购，而不是 AI 对工具的增强。它让 AI 感觉像是一种接管了系统的病毒，不再像过去那样，是一个在我不需要时懂得乖乖让路的有用助手。
我甚至无法在不同的 Notion 工作空间之间切换，因为中间总是会弹出一个 Notion 智能体（Agents）的广告。
当然，当我进入工作空间后，我看到了什么？更多的 AI 推销。
什么 「AI 会议笔记」？Notion，你能不能别挡道，让我按照自己的方式创建笔记？「新建 AI 会议笔记」以及它上方「连接你的日历」的提示就那么杵在那里，白白占用空间。呵呵，真酷。
但等等！还有更多。在那下面，我们看到了什么？
智能体（Agents）。同样在占用空间。
过去，所有这些空间都填满了我自己的笔记和页面。现在呢？它们被挤到了屏幕的一半以下，只为了给这些垃圾腾出地方。
幸运的是，点击三点菜单并选择“隐藏部分”，可以将这两个板块隐藏起来。
但即便如此，它们默认存在的事实依然令人反感。Notion，你并没有让我对转投其他软件感到后悔。这真是糟糕透顶的用户体验设计。
重新审视担忧
需要极其明确的一点是，这绝不是在讨论 Notion 或其周边工具是否优秀。完全不是。
当我抛弃 Notion 时，并不是因为它是一个糟糕的工具。它过去不是，现在也不是。
事实上，即使在转投 Obsidian 之后，我依然怀念 Notion 的某些功能。Notion 和 Obsidian 有很多重叠之处，但如果我说我不喜欢 Notion 处理某些事情的方式，那我一定是在撒谎。
但工具的强大与否并非问题所在。依赖它们的明智程度才是。
我很高兴看到 Notion 为所有依赖它的人继续取得成功。真的。但它的扩张只会加深我的担忧。
只要 Notion 仍然是一个以专有格式将数据存储在你我都无法控制的位置的工具，那么无论这些工具多么优秀都无济于事。
完全依赖它们是充满风险的。而在我看来，Notion 的扩张恰恰是在鼓励人们这样做，将自己的数据投入到他的「黑洞」中。
万物皆有终时
关于这一点，最好的例子莫过于直接看看 Notion Mail。回溯到 2024 年，Notion 收购了 Skiff (上图)，这是一款隐私优先、端到端加密的电子邮件客户端。
收购完成后，Skiff 的所有服务（邮件、云盘和日历）都被关闭了。
2025 年 4 月，Notion 推出了 Notion Mail，它实际上只是 Gmail 的一个收件端。
而现在，Notion Mail 也要关闭了。
Notion 关闭 Notion Mail 的理由是什么？为了专注于 AI。他们一本正经地声称“超过一半的 Notion Mail 用户在管理邮件时，甚至从未打开过他们的收件箱。”
就算这是真的，那剩下的将近一半用户呢？
那篇公告接着写道：“因此，我们将全力以赴，使用智能体（Agents）来运营你的收件箱。”
不。不。绝对不行。不。这主意糟透了。
在我看来，这恰恰说明 Notion 宁愿成为一个 AI 工具，也不愿成为一个旨在满足普通用户需求的生产力套件。
尾大不掉，难以信任
早在 Notion 还只是一个笔记工具的时候，我就对它存储数据的方式感到担忧。我至今仍有这些担忧。只是今天更甚。
但现在，既然 Notion 正在全力押注 AI，并且为了实现这一目标，甚至不惜扼杀像 Notion Mail 这样相对较新的产品……我不得不怀疑，我到底还能对 Notion 各种繁杂的产品抱有多大的信任。
我怎么知道核心应用剩下的部分，有朝一日不会以 AI 智能体的名义被吞噬？我能得到任何不会发生这种事的保证吗？
听起来，Notion 团队似乎对 AI 的热情远胜于服务其长期用户。当然，他们会否认这一点，但事实胜于雄辩。
至少在我看来是这样。
照目前的情况来看，我不信任 Notion。在他们全力押注 AI 之前，我不信任它，是因为它缺乏端到端加密，而且我无法将数据存储在我拥有并信任的地方。现在，我不信任它，不仅因为上述原因，还因为 Notion 已经膨胀得失去了自我，而 Notion Mail 的终结已经让我们看到了最初的端倪。
我为自己抛弃它而感到庆幸的理由正在不断增加。
Notion 的核心产品过去是，现在依然是一个好工具，但它已经变得如此臃肿，充斥着 AI，并且持续存在隐私隐患，以至于我认为我无法再向任何人推荐用它来处理任何重要的事情。
说实话？这让我感到悲哀。
至于现在，我会继续使用 Obsidian，保持我的笔记备份并进行端到端加密。对于像我这样一个见证了太多系统兴衰更迭的人来说，这才是最重要的。
-
围绕 ChatGPT，OpenAI 最近更新调整了一系列产品，是故弄玄虚？还是渐入佳境？
OpenAI 被 微软「改名部」附体？
这些天，OpenAI 一口气调整了不少产品。
GPT-5.6 发布了，GPT-Live 重做了语音交互，Codex 被直接塞进新的 ChatGPT 桌面应用，刚推出不久的 Atlas AI 浏览器则准备关门。另外，ChatGPT Work、Sites、插件目录和 PowerPoint 等一批新功能也同时涌现出来。
OpenAI 这些年的产品命名一直很折腾，颇有一种被微软「改名部」附体的感觉，经常翻来覆去地做一些意义不明的名称调整。这个问题，下面还会详细说。
不过，最近这次大改动，目的至少还是比较明确的：把过去一年散落在各处试验的模型、智能体和独立应用，重新收回 ChatGPT 里面。
由于这次 ChatGPT 系列改动很多，我也会结合自己的实际使用体验，聊聊这些变化到底意味着什么。
GPT-5.6：命名已经玩出花了
2026 年 7 月 9 日，OpenAI 推出了 GPT-5.6 系列：
- Sol：负责高难度任务；
- Terra：在速度、性能和价格之间取得平衡；
- Luna：价格更低，适合大量调用。
最初它还是分批推送的。到各位看到这篇文章时，GPT-5.6 应该已经全面进入 ChatGPT、Codex 和 OpenAI API。
虽然我不知道 GPT-5.6 为什么要用太阳、地球和月亮来命名，但我觉得，这个坏头是 Claude 开的。Claude 已经开始用 Haiku、Sonnet、Opus 这类文学或音乐相关的名称，来区分不同等级的模型。现在 OpenAI 也开始往这种方向走，模型名称越来越像某种神秘学等级体系。
从目前的实际体验来看，我感觉 GPT-5.6 和 GPT-5.5 并没有什么特别明显的区别。
当然，也有人认为它在某些领域进行了针对性优化，这完全有可能。
现代大模型其实并不是一个笼统、单一的智能体，更像是多种专家能力的组合体。比如有的擅长文书处理，有的擅长常识推理，有的擅长编程。
所以，即使模型确实得到了优化，也未必每个人都能在每一种使用场景中感知到。
对实际用户来说，这些模型名称更像是在测试用户对资源消耗的敏感程度：你愿意多花多少钱、多消耗多少额度，或者多等待多长时间。
某种程度上，这和星巴克用不同杯型区分价格与容量，有异曲同工之妙。
目前能够明显感知到的区别是：GPT-5.5 Instant 负责快速问答，而 GPT-5.6 Sol 更偏向高强度推理任务。
至于那些「超级付费玩家」，则可以选择 Pro、Max 或 Ultra，让模型获得更多时间进行检查和修改，甚至同时调度多个智能体，再把结果汇总起来。
说到底，这些能力都是靠疯狂堆算力、烧钱换来的。
但和微软一样，OpenAI 改名也会带来一系列混乱。
它一边想把旧模型藏到后台，一边又不断创造新的名称。GPT-5.5、GPT-5.6、Instant、Medium、High、Pro、Max、Ultra，再加上 Sol、Terra 和 Luna，已经不是普通用户愿意主动理解的东西了。
而且我发现，「改名部」现象的出现，往往还是一个标志。
它可能意味着公司内部存在多个产品团队，每个团队都有自己的产品路线，也都想获得命名和产品定义上的主导权。
微软就是一个典型例子，山头林立。
这一点，在 OpenAI 后面的产品调整中还会继续体现出来。
GPT-Live：语音不只是把答案念出来
这项改进，我非常喜欢。
以前的 AI 语音对话，很多时候更像对讲机。
用户先说完一段话，系统把语音转成文字，模型生成回答，再把文字转换成语音。只要中间停顿一下、打断一下，或者临时改口，整个对话节奏就很容易崩掉。
GPT-Live 主要解决的就是这个问题。
它提供了更自然的对话流，也让用户更容易打断、改口和补充内容。
2026 年 7 月 8 日，OpenAI 发布了 GPT-Live，并将其用于新版 ChatGPT Voice。付费用户主要使用 GPT-Live-1，免费用户则使用 GPT-Live-1 mini。
它采用全双工架构，可以持续听取声音，同时判断什么时候回答、什么时候停顿，以及什么时候继续等待用户说完。
我试了一下，感觉非常逼真，甚至有种正在和真人交流的错觉。唯一的问题是反应速度略微慢了一点。不过，它毕竟需要进行网络通信和模型计算，有时还要查询网络，因此出现延迟也可以理解。
而且，在等待过程中，ChatGPT Voice 还会加入一些语气词，来缓和停顿。比如「嗯……让我看看」「哦……」之类。
尤其是在我们打断它说话时，它不会像以前那样直接卡住，而是会自然地停下来，重新判断我们的意思。这种细节对语音体验的提升非常明显。
尽管它离电影里的全能语音助手还有一段距离，但我觉得，这种神奇的东西已经真的有可能在不久的将来实现了。
Codex 并入 ChatGPT：功能统一了，项目管理却更乱了
这次最容易让人困惑的，还是 Codex 和 ChatGPT 的合并。
新版 ChatGPT 桌面应用把三个入口放到了一起：
- Chat：普通聊天和问答；
- Work：研究、分析和办公任务；
- Codex：代码、文件和工程任务。
原来的 Codex 应用会迁移到新版 ChatGPT 桌面应用，旧版 ChatGPT 桌面端则可能暂时以 ChatGPT Classic 的形式保留。是不是让人想起了微软折腾 Outlook 名称时的经历？New Outlook、Outlook Classic……
所以，Codex 并没有消失。
它只是从一个相对独立的应用，变成了 ChatGPT 里面的一种工作模式。它依然保留代码差异编辑、Pull Request 审查、多代码仓库、本地和远程开发环境等功能。
但我打开新版入口时，最先产生的问题就是：原来 ChatGPT 里的项目和 Codex 里的项目，现在到底算什么关系？
它们并没有被整合进一个清晰、统一的项目结构里，也缺少一个足够直观的切换和分类界面。
功能上统一了入口，数据和工作上下文却仍然分散。在新版桌面应用中，Chat 只占据了一个很不起眼的位置。虽然依然可以访问过去的聊天记录，但整体体验已经大不如前。
所以，我现在主要使用网页版来访问原有的 ChatGPT 对话，那里至少还保留了过去熟悉的项目结构。
从宣传上看，ChatGPT 的 Chat、Work 和 Codex 可以划分得很清楚：Chat 负责交流；Work 负责知识工作；Codex 负责操作文件和执行环境。
但现实中的任务，根本不会划分得这么清楚。
这里还牵涉到本地与云端的区别。一般来说，Chat 主要运行在云端，而 Codex 和 Work 中的很多项目，则是基于本地文件夹展开的。
另外，还有插件与第三方应用之间的跨 App 上下文、Browser Use 与浏览器之间的关系、Computer Use，以及办公软件、Figma 等一系列扩展能力。
所有这些东西加在一起之后，边界其实越来越模糊。
而且在我看来，这次新增的 Work，很大程度上就是原来 Codex 使用方式的延伸，只是换了一个更宽泛的名字。
很多有经验的用户早就知道，Codex 本来就不只能写代码。它完全可以用来处理研究、整理资料、修改文档、生成报告等各种基于文件的 AI 工作。
所谓的「统一桌面应用」，如果只是把几个入口放进同一个窗口，那显然还远远不够。
那只是名称和界面上的统一，并不是数据、项目和上下文的真正统一。
这同样很有微软特色。比如 Microsoft Copilot 365，就是一个试图统合 Word、Excel、PowerPoint、AI 以及无数产品和服务的统称。但普通用户很难理解，这个名字究竟代表什么。
Atlas 浏览器下线：取代浏览器没有那么容易
Atlas 浏览器将在 2026 年 8 月 9 日停止运行。
书签、历史记录和已经打开的标签页，也不会全部自动迁移，用户需要提前导出或保存。
对于一款推出不久的产品来说，这基本就等于失败了。
不过，我对 Atlas 的退场并不意外。刚推出时，我简单试用了一下，很快就放弃了。
它的功能太简单，离一款合格的浏览器还很远，更像是一个试验品。
浏览器看起来只是一个普通软件，实际上却非常难以替代。除了打开网页，它还涉及账号登录、密码管理、插件生态、网站兼容性、安全更新、下载管理，以及大量已经形成的使用习惯。
用户可能愿意安装一个 AI 工具，却不一定愿意为了 AI 更换自己的默认浏览器。
用户甚至可能更愿意使用 Browser Use，让 Agent 在后台浏览网页，而不是亲自适应一款全新的浏览器。
OpenAI 现在放弃的就是「单独再造一个浏览器」这条路线。至于 Browser Use，从目前的产品方向来看，应该仍然会得到重点支持。
Atlas 中的多标签页操作、网页导航、文件下载、账号登录，以及在网站和文件之间执行任务的能力，也会继续迁移到 ChatGPT 和 Codex。新版 ChatGPT 桌面应用也开始内置浏览能力。
当然，喜欢 AI 浏览器的用户仍然有其他选择。比如： Perplexity 的 Comet 浏览器、Dia Browser，以及 Chrome 和 Gemini 的组合，都可以继续尝试。
不过我仍然认为，AI 浏览器真正的价值，不是做一个更花哨的网页外壳，而是让智能体接管部分浏览、操作和资料整理流程。
Sites、插件和 PowerPoint：OpenAI 想接管最后的交付环节
OpenAI 这次还推出或调整了 Sites、插件目录和 PowerPoint 等功能。ChatGPT Sites 可以根据文件、数据和提示内容，生成一个交互式网站。比如仪表盘、项目追踪器、信息门户，或者简单的产品原型。
不过我觉得，这项功能目前还太新，很难真正委以重任。谁也不知道它会不会哪天突然下线。
插件目录则开始取代原来的应用目录。这里的插件不再只是调用一个第三方接口，而是把应用连接、技能、模板和操作说明打包成一整套工作流。
ChatGPT for PowerPoint 也开始面向 Business 工作区推出，可以直接创建和修改可编辑的演示文稿。
从产品方向来看，这些功能都指向同一个目标：
OpenAI 不再满足于只负责生成内容，它还想接管最后的交付环节，直接帮用户做成网站、PPT、报告、工作流和应用。
但我仍然会关注同一个问题：生成出来的东西，究竟属于谁？网站能不能完整导出？生成的 PPT 是否真的是标准、可编辑的 PowerPoint 文件？插件工作流能不能保存和迁移？用户离开 ChatGPT 后，项目是否还能继续使用？
如果这些问题没有处理好，所谓「让 ChatGPT 成为统一工作操作系统」的愿景，最后可能只是把它变成一个功能更多、依赖更深的云端平台。
OpenAI 是故弄玄虚，还是渐入佳境？
我的判断是：OpenAI 的产品大方向，确实比以前更清楚了，技术实力也依然强大。
过去一年，OpenAI 同时尝试了模型、智能体、浏览器、代码工具、语音助手、办公软件插件和各种独立应用。
现在，它终于开始把这些东西重新收回 ChatGPT。从战略上看，这个方向是合理的。
ChatGPT 已经拥有用户、账户、订阅、历史记录和品牌认知，把新能力集中在这里，总比不断推出新的独立产品更容易管理。
但在命名和产品结构上，OpenAI 仍然有相当明显的故弄玄虚成分。GPT-5.6、Sol、Terra、Luna、Instant、Pro、Max、Ultra，再加上 Chat、Work、Codex、Sites、插件和各种 Agent 功能，普通用户已经很难搞清楚它们之间的关系。
同时，这些变化也隐约暴露出公司内部产品线林立、团队各自为政，以及管理层雄心，或者说野心，可能过大的苗头。
所以，与其说 OpenAI 已经渐入佳境，不如说它终于开始收拾房间了。
最终，OpenAI 或许想把 ChatGPT 变成 AI 时代的工作操作系统。
它可能管理用户的聊天、文件、代码、网页、办公文档、应用和工作流程，甚至成为一个长期控制用户信息入口与出口的庞大生意。
我希望 OpenAI 的产品能够成功，但我不希望它形成垄断。
我希望用户永远有更多选择。
无论是 扶不上墙的 Windows、在 AI 上后发追赶的 macOS、占据浏览器霸主地位的 Chrome，还是同样属于实力派的 Claude，只要这些竞争者一直存在，没有任何一家能够彻底垄断市场，用户就有机会获得更开放的 AI 环境。
只要竞争还在、没有一家独大，整个 AI 行业就会进步得更快。
-
知名的生产力工具 Raycast， 近期又在整什么新活？ 他们推出的全新工具 Glaze 又是什么？
Raycast 不想只做启动器了
Raycast 这几年给我的感觉很奇妙。
我最早对它的印象，就是一个快速启动器工具，而且是苹果生态独占的。那时候 macOS Spotlight 还不是很强，而老牌启动器 Alfred 似乎又显得有点老了。所以当年 Raycast 横空出世的时候，确实像是一股新鲜血液。
后来我对 Raycast 的印象逐渐开始淡化，因为启动器工具（Launcher）本身不是一个特别厚重的叙事。它想成为一切功能的快捷入口，但这件事其实很难。它要和操作系统、浏览器、各种其它生产力工具竞争，同时还要整合它们，这是很吃力不讨好的事情。
比方说，苹果自带的 Shortcuts（Workflow）也在做类似的事情，Spotlight 这几年也得到了很大加强；很多浏览器开始集成命令面板和地址栏一键搜索；各种笔记工具有自己的快捷命令输入框；各种花式 AI 工具就更不用说了；还有一些剪贴板工具、窗口管理工具，也在分走 Raycast 的使用场景。
也许有人会说，Raycast 很全面，既能这样又能那样……但是根据我的经验，大多数人只有那些特别重要、特别频繁的动作，才需要快捷支持。有的人可能是剪贴板动作，有的人可能是搜索，有的人可能是窗口管理。大家未必有一个强烈需求，非要把所有东西统一到同一个入口里。这一点我后面会结合自己的例子再讲。
所以，我感觉 Raycast 一直不甘心只做启动器。尤其是拿了融资之后，单纯的启动器故事，很难再讲得更大。
这就是我们前些时候看到 Raycast 开始推出 Ask AI 入口，并把它作为 Pro 版的一个付费功能。这很好地迎合了当时花式 AI 工具兴起的潮流，也算是把启动器向前推进了一步，开始瞄准 ChatGPT、AI 翻译、AI 查询工具这一类入口。
但最近 Raycast 的变化，已经不能再用简单的「启动器」或「入口」来理解了。
它似乎有了更大的野心。
它近期有三件事值得注意：
- 把自己从 Mac 专属工具变成跨平台工具，扩充用户来源。
- 把 AI 更深入地塞进系统操作入口。
- 推出 Glaze，用于「生成个人桌面 App」。
我们逐个来看一下。
Raycast V2：走向多平台
Raycast V2 最直观的变化是界面。
它适配 macOS Tahoe 的视觉风格，Root Search、AI、文件搜索、快捷键、Quicklinks、Snippets、Tags、Dictation 等入口都重新整理过。
同时，新增的 Windows 版本也进入了 public beta。我已经安装试用了。
官方技术文章里说，V2 是一次跨平台重写，混合了 TypeScript、Swift、C#、Rust、Node 和 React。它既不是纯原生，也不是简单套一个 Electron 壳。
早期得益于 Mac 生态独占，Raycast 最吸引人的地方，就是它非常轻，非常快，非常像系统的一部分。一旦重构之后出现更高内存占用、更明显的 Web UI 痕迹，或者某些 V1 功能暂时缺席，老用户可能会不满。
我试用 Windows 版本时，刚过 5 分钟，就意识到一个经典问题：macOS 上可能不明显，但 Windows 上不少套壳移植 App 都容易在这里翻车，那就是屏幕 DPI 适配。
我手上这个版本，会造成部分界面在某些设置了 DPI 缩放的大屏幕上不能完整显示，这就让实用性大打折扣了。希望后续能尽快修正。
另外，macOS 上很多经典实用的用例，在 Windows 上其实早就被其它工具占领了。
比如我用 Ditto、PowerToys，有的人还用 Everything。Windows 自带的窗口分屏管理也不错。Windows 用户似乎早就熟悉了快速把事情搞定的生产力哲学，不太喜欢过分精致的统一入口，也不一定欣赏那种整齐优雅的感觉。大家主要还是集中在把事情搞定上。
Ditto 很丑陋，但是很实用。Windows 自己的一些快捷键只要熟练了，也根本不需要什么优雅界面。文件搜索就更不用说了，Everything 的惊人实力大家也是知道的，只要不太介意界面是否漂亮。
尽管如此，我还是希望 Raycast 可以做出一个很好的示范，给 Windows 用户提供更多选择，尤其是那些刚入门生产力工具的用户。
还有就是，很显然，多平台的 Raycast，也是在为后面的 AI 和 Glaze 铺路。
AI：Raycast 不只是一个聊天框
很多软件都在加 AI，早期大多都是类似 ChatGPT 的套壳聊天框。Raycast 最早也类似，但现在 Raycast 的 AI 路线有点不一样。
现在的 Raycast 不是只放一个聊天窗口，而是把 AI 放进命令系统里。
Quick AI、AI Chat、AI Extensions、MCP servers，这些东西组合在一起，意味着 AI 不只是回答问题，而是可以拉取上下文、调用扩展、跨应用执行动作。
有点像在浏览器里对着具体的 Tab 发问，对着某篇笔记、某个操作界面、某个 Todo 任务发问。官方给出的例子包括创建 Linear issue、搜索代码库等动作。
这其实很接近我理解中的「AI 操作层」：在某个入口里直接说出目标，让 AI 去调用本机和第三方工具。
听起来很理想，是吗？
但是，过去 Raycast 执行的是确定命令。我按下回车，打开 App，复制文本，搜索文件，结果很明确。现在如果想让 AI 更准确地识别意图，还是少不了选择命令或菜单。由于它集成了太多功能，结果反而有点更麻烦了。
比方说，我使用 Perplexity 查询时，以前有个快捷键，可以一键呼出 Perplexity / PPLX 界面，输入查询，已经形成肌肉记忆了。
现在变成：呼出 Raycast，输入或选择 PPLX，回车，再输入内容。这样一圈下来，到底意义何在？
又比方说，原本做网页内容总结，我们可以通过集成 Gemini 的浏览器，或者 Atlas、Comet 这类浏览器，在当前页面里一键唤起 AI。现在则是呼出 Raycast，输入指令，粘贴网址。当然，也可以用浏览器插件简化，但交互上显然还是更绕了一点。
我的意思是，让 AI 发生在上下文中是最好的，而不是另起一个统一接口，除非是一些非常通用的查询。
让 AI 发生在上下文里，这是目前所有主流软件或网站都已经在做的事情。即使不是发生在第一现场，Codex、Claude Code、OpenCode 也有很好的 AI 接口。所以 Raycast 处在一个很尴尬的 AI 入口位置，我个人不太看好它作为 AI 统一入口的长期位置。
Glaze：Raycast 真正的新玩具
Glaze 是 Raycast 最新推出的 AI App builder，之前有过预告和内测，现在终于公开可用了。
Glaze 的核心卖点是：用自然语言描述需求，Glaze 帮我们生成一个真正运行在电脑上的桌面 App。
Glaze 官方强调，生成的 App 可以运行在本机、离线使用、访问文件系统、支持快捷键、菜单栏和后台进程。目前它要求 macOS Tahoe 和 Apple Silicon，未来计划支持 Windows 和 Linux。
我下载了 Glaze，还没有真正用它生成 App，只是先看了看它的 App Store，也就是别人把生成的 App 放上去、供大家公开下载的地方。
挺有趣，但目前看下来，更多还是一些小工具，有些还挺简陋的。
不过我知道，真实需求往往就是很小：一个收据整理器，一个 Markdown 文件目录生成器，一个菜单栏计时器，一个本地截图归档工具，一个团队内部 review 面板，一个只服务某个项目的资料 dashboard。、
很多人都有自己变通的生产力方式。以前这些小需求可能用脚本、快捷指令、Excel、Notion、AppleScript、Python 或者各种临时方案勉强解决。现在如果可以通过 Glaze 打包成一个本地 App，然后立刻使用，这确实是一件好事。
而且 Glaze 和 Raycast 天然契合。Raycast 是入口，Glaze 是工具生成器。用 Glaze 做出来的小 App，未来很可能可以通过 Raycast 启动、搜索、调用，甚至嵌入到 AI workflow 里。
这是一个很好的点子。
但我也不会把 Glaze 说成是什么特别颠覆式的发明。它更像是 GPTs、Skills 这类东西的 GUI 包装。对特定人群很实用，但也不必把它说得过于神奇。
这类生成出来的小工具，质量往往良莠不齐，后续维护也是个问题，试想我怎么敢把几百条书签放在一个 莫名其妙没有经过时间和用户检验的 Glaze 小工具里面？尤其是当一个小工具真的被用户依赖之后，它就不再只是一个随手生成的玩具，而会变成一个需要长期维护的软件。
但总的来说，Glaze 是个很好的尝试，尤其是 Glaze App Store 提供了各种可能性。
最后
Raycast 的发展很有趣，但后面可能也会越来越难。
尤其是拿了融资之后，它就不能再只是一个「小而美」的工具，而是必须讲出一个更庞大的叙事。
现在来看，Raycast 确实很会整活，但我也希望它不要忘记初心。我见过很多类似例子，前期吹得很大，最后草草收场，或者被收购，用户被扔在了一边。 什么 Evernote？我有说过吗？
希望 Raycast 可以走得更远。至少，它可以继续给大家带来更多工具选择和启发。
Raycast 官网
Raycast Glaze 官网
-
【速报】Notion Mail 宣布关闭：邮箱正在从 inbox 变成 AI agent 的输入流
Notion 官方已经确认，Notion Mail 将在 2026 年 9 月 22 日正式关闭，Web、桌面与 iOS 客户端都会停止服务。从 2025 年 4 月上线，到 2026 年 9 月关停，这款产品大约只存在了 17 个月。
官方给出的理由，并不只是普通的「产品调整」，而是一个更激进的选择：随着 Notion Agents 能力提升，越来越多用户已经不再亲自打开收件箱处理邮件。公司决定把资源集中到 AI Agent 路线，而不是继续维护一个 inbox 产品。
以前我看到的所谓智能邮箱，大多只是借助 AI 筛选、分类邮件，形成一个更聪明的 inbox。比如 HEY、Superhuman 这类产品，甚至 Gmail 这样的主流邮箱服务，也在朝这个方向演进。
但最近的趋势更加激进：邮箱不只是变聪明，而是直接变成 Agent Mail。人甚至不再需要亲自查看收件箱，邮件处理全部交给 AI。
一个只活了 17 个月的邮箱实验
2025 年 4 月，Notion 推出 Notion Mail，试图把邮箱纳入自己的生产力版图。它并不是一个独立邮箱服务，而是与 Gmail 深度同步的 AI 邮件客户端：邮件实际仍保留在 Gmail，Notion 提供的是数据库式视图、自动标签、snippet 模板、状态管理和 AI 辅助写作等增强层。
所以更准确地说，Notion Mail 仍然是一个增强型邮箱客户端。
从产品想象上看，它延续了 Notion 一贯的路线：不是只给用户一个应用，而是把信息对象重新结构化，让邮件也能像页面、任务和数据库一样被重新编排。
我之前有过文章介绍，2024 年 2 月，Notion 收购了以隐私和端到端加密著称的生产力平台 Skiff。后者提供文档、云盘、日历和邮箱服务。收购完成后，Skiff 产品进入关停和迁移期。因此，外界很自然地把 Notion Mail 视为这次收购后的延伸。
但一年多之后，故事急转直下。
2026 年 6 月，Notion 在帮助文档中明确宣布，Notion Mail 将在 9 月 22 日关闭。用户从 6 月 25 日起，可以导出草稿、定时发送邮件、snippet、自动标签规则和自定义视图等仅存在于 Notion Mail 内的数据。9 月 21 日之后，未导出的内容将被永久删除。
当然，Gmail 中保存的邮件本身不会丢失。真正需要注意的是，9 月 22 日之后，不会再有新邮件同步进入 Notion Mail 的数据库视图。用户真正需要处理的，也不是 Gmail 邮件本身，而是 Notion Mail 内部那些增强数据的导出。
所以这件事不必过度恐慌，但也不能完全忽略。
Notion 对外讲述这次关停时提到：随着 Notion Agents 能力增强，越来越多用户已经把邮件工作流交给 AI Agent 处理，而不再通过传统 inbox UI 自己逐封点开邮件。
我们也能看到，Notion 最近一年讲的核心故事就是 AI Agent，很多产品叙事都在向这个方向靠拢。从 Notion 的逻辑看，维护一个跨平台邮箱客户端的成本很高，而把邮件处理能力沉到 AI Agent 基础设施里，则可以同时服务日历、任务、文档和自动化工作流。
当然，这套叙事也有一个明显的公关优势：它把 Notion Mail 的结束包装成「产品升级」，而不是一次普通的产品关停。
从 HEY 到 Agent Mail：邮箱行业的三代演化
如果把 Notion Mail 放回整个邮箱行业，会更容易理解它为什么在这个时间点下线。
过去几年，撇开传统邮件客户端不谈，智能邮箱大致经历了三代演化。
第一代是 UI-first 的「重做收件箱」。HEY 是代表性产品，它通过 Screener 让用户先审核陌生发件人，再把邮件拆进 Imbox（不是 Inbox，Hey 自创了一个词）、The Feed 和 Paper Trail 等不同区域。本质上，它是在用一套强观点的界面设计，帮助用户重新夺回邮箱控制权。
这类产品相信，邮件问题首先是交互问题。只要 inbox 设计得更合理，人就能重新管理好注意力。其实，很多非邮件产品也遵循类似逻辑。这个「以人为本」的方向我一直很尊重。
第二代是 AI assistant 型产品。Superhuman、Shortwave、Gmelius、Lindy 等工具，则开始在现有邮箱或工作流之上叠加 AI 能力：自动总结长线程、给出回复草稿、安排 follow-up 提醒、识别优先级、与日历或 CRM 同步。
AI 让用户处理同样数量的邮件时更快、更省力，但用户依然需要每天打开 inbox。只是旁边多了一个勤快的助手。
第三代是 Agent-first 型产品。越来越多产品直接以「AI email agent」或「autonomous agent email software」来定义自己。它们的卖点不再是更漂亮的收件箱，而是 AI Agent 自动整理邮件、抽取结构化信息、生成回复、更新 CRM、触发工单。只有在高风险场景下，才把决策重新交给人工审核。
在这套逻辑里，邮件不再是你每天反复打开的应用，而是一种被 AI Agent 持续监听、解析和行动的信息输入流。
收件箱正在退居幕后
Agent Mail 一类的新工具，标榜的是「让 AI 先管理邮箱」。
无论是各类自主邮件 agent 工具目录，还是 2026 年大量「AI email agents」榜单，强调的能力都非常一致：自动分拣邮件、提取任务、生成或直接发送回复、与销售和客服系统同步，并在低风险场景中尽可能减少人工介入。
在这里，收件箱不再是主战场。真正的竞争点，变成了 AI Agent 对上下文的理解、对组织知识的调用，以及何时应该把控制权还给人类。
顺便一说，国内某家大厂最近也跟进了这波 Agent Mail 趋势。
我真正担心的部分
这次事件还有一个容易被忽略的背景：Notion Mail 的技术和团队背景，部分来自 Skiff，而 Skiff 原本讲述的是一个完全不同的故事。
Skiff 的核心标签是隐私、端到端加密和去平台化。它试图提供一个不依赖大平台的工作套件，也试图重建一套更独立、更私密的邮件基础设施。
这意味着，Notion 收购 Skiff 之后，并没有真正延续「重建底层邮件基础设施」的隐私路线，而是更务实地把收购转化为产品能力和人才资产。当 AI Agent 成为新的重点后，这个取向更加清晰：Notion 要的不是做一个最独立、最私密的邮箱产品，而是让用户的邮件、日历、文档和任务都能流进同一个 AI 驱动的工作流中。
从商业角度看，这当然可以理解。
但是，「隐私优先」和「数据自我控制」这套叙事，似乎正在被挤到越来越边缘的位置。越是把邮件交给 AI，越应该明确哪些东西可以自动化，哪些东西必须保留在人自己手里。
Notion Mail 所代表的这种升级，更适合工作场景中套路固定的邮件往来，也适合那些已经成形的组织工作流。比如销售跟进、客服分派、会议安排、状态更新、CRM 维护，这些场景本来就有明确流程，也更容易设定规则和边界。
但在私人邮件场景里，它恐怕还不太适合，也不应该轻易让 AI 全面接管（我已经脑补出了邮件 提示词注入攻击窃取个人信息了）。
AI 可以帮助处理邮件，但不应该默认接管所有私人通信。工作流可以自动化，个人边界和数据控制权仍然要留给用户自己，这也是我一贯的立场。
高效搞定事情，尽情享受生活
