效率火箭

有些 App 可以共用 ChatGPT 和 Claude 订阅了，但为什么还要每月多付 10 美元？以 Raycast 为例。

Wed, 30 Sep 2026 10:02:33 +0800

现在的 AI 工具，很容易产生一种奇怪的重复账单。

我们可能已经在付 ChatGPT 或 Claude 的订阅费，然后又买一个 AI 写作工具、一个搜索工具、一个编程工具，再加一个所谓的 AI 生产力工具。它们背后用的可能还是同一批模型，每个 App 却都想再收一次 AI 订阅费。

所以，Raycast 在 2026 年 9 月推出 Bring Your Own Subscription 时，这个名字本身就很有吸引力：

把我已经买了的 ChatGPT 或 Claude 订阅，直接拿到 Raycast 里继续用。

这和过去常见的 BYOK （Bring Your Own Key）不一样，不是把 API Key 填进去以后，再按照 API 用量付费。Raycast v2.3 开始真正支持 ChatGPT 和 Claude 的现有订阅，模型使用量计入原有订阅的限额，不消耗 Raycast AI 自己的 credits。

不过，讽刺的是，这并不意味着「付了 ChatGPT，Raycast AI 就免费」。

「共用订阅」是 Raycast 付费方案的功能。换句话说，我们仍然需要一份付费 Raycast，最低每月 10 美元，或者每年 96 美元。

问题也就来了：

既然 ChatGPT 和 Claude 都有自己的应用，我也已经付钱给它们了，为什么还要多付 Raycast 这一层？

AI 订阅、API Key 和 Raycast credits，是三笔不同的账

ChatGPT 订阅和 OpenAI API 是两套独立的计费系统。Claude 的付费订阅与 Anthropic API 同样分别计费。

订阅聊天产品，并不意味着同时得到一包可以让任意第三方 App 调用的 API 额度。

Raycast 这次的方案比较特殊。它不是把聊天订阅当成 API 使用，而是通过电脑上的命令行工具接入账号：Claude 使用 Claude Code，ChatGPT 使用 Codex CLI。

这里所说的「现有订阅」，必须是 Raycast 能识别的有效 Claude 或 ChatGPT 订阅。只有 API 访问资格并不算，需要改走 BYOK，也就是自己填写 API Key。

接入订阅后，也不是自动获得供应商的全部模型。Raycast 会根据当前账号实际可用的模型显示选择，并随着供应商调整而变化。

因此，目前在 Raycast 里使用 AI，至少有三条路：

Bring Your Own Subscription

付费 Raycast + 现有 ChatGPT 或 Claude 订阅。

调用计入原订阅限额，不扣 Raycast credits。

Bring Your Own Key

付费 Raycast + 自己的 OpenAI、Anthropic、Google 或其他第三方 API Key。

模型费用由对应 API 账户另行承担。

Raycast 自带 AI

Raycast Pro 每月 10 美元，包含 500 credits；Pro+ 每月 20 美元，包含 3,000 credits；Max 每月 50 美元，包含 7,500 credits。

Free 方案不包含 Raycast AI。在 Raycast v2 中，BYOK、自定义 Provider、本地模型以及这次的订阅复用，也都需要付费版本。

因此，网上那些「Raycast 个人 BYOK 免费」的旧文章，在新版本下已经不再适用。

这里有一个很重要的利益关系：

即使模型不是 Raycast 提供的，Raycast 仍然要为模型外面的界面和工作流收费。

Raycast 的选择很明确，即使模型成本由用户承担，它仍然认为「工作流这一层」值得单独收费。

Raycast 怎么复用 ChatGPT 和 Claude 订阅

设置过程不算复杂，但也不是点击一个 OAuth 按钮就结束。

这条路线依赖本机上的 Claude Code 或 Codex CLI。安装以后，分别登录 Claude 或 ChatGPT 账号，Raycast 就能识别相应订阅以及可以使用的模型。

因为依赖本机工具，目前这套机制主要面向 macOS 和 Windows 桌面端。换一台电脑，也需要在那台设备上重新配置，不会完全跟着 Raycast Cloud Sync 自动完成。

而且，原有 ChatGPT、Claude 订阅的使用限额并没有消失。

在 Raycast 里调用这些模型，消耗的仍然是对应订阅的额度，而且会与其他使用场景共享。具体限额和重置方式，则取决于供应商当前的订阅方案。

所以，在 Raycast 里用得多了，回到 Claude 或 ChatGPT 自己的客户端，同样可能遇到订阅额度限制。

多付 Raycast 的钱，买的是上下文和动作

如果我只需要一个聊天窗口，Raycast 的价值其实很小。

现在这类工具已经铺天盖地。Claude 和 ChatGPT 的原生客户端本身也能进行长对话、读取文件，并且通常会优先获得各自最新的模型能力。

所以，Raycast 真正需要证明价值的地方，是模型周围的操作层。

看懂当前窗口，而不是反复复制粘贴

Screen Awareness 可以通过快捷键抓取当前聚焦的窗口，包括 App 名称、窗口标题、可读文本、当前选区、聚焦控件和截图。

如果是浏览器，配合 Browser Companion，还可以附上当前页面的标题、URL 和内容。

原生 ChatGPT 或 Claude 同样能看截图、读文件，而且也在不断增加桌面、网页和其他上下文能力。因此，不能简单地说它们每次都只能靠手工复制粘贴。

Raycast 的区别，是把「抓取当前窗口、选区和网页」做成统一的快捷动作，然后直接连接到后面的 AI 命令。

把回答直接写回原 App

Quick AI 可以从 Root Search 直接发问，结果出来后按回车，默认就能粘贴回先前聚焦的 App。

这对「选中一段话 → 改得更简洁 → 替换原文」这类高频操作很实用。

自定义 AI Command 还可以固定提示词、模型和动态占位符，再绑定全局快捷键。润色邮件、调整语气、总结选区、翻译和检查代码，都不必先切换到一个独立的 AI 聊天窗口。

让现有订阅获得 Raycast 的工具

Raycast 的 AI Extensions、MCP 和 Skills，也可以和订阅模型一起使用。

这意味着同一个 Claude 或 ChatGPT 模型，进入 Raycast 以后，可以调用 Raycast 提供的工具，读取日历、查找文件、运行终端命令，或者连接 GitHub、Linear 等外部服务。

这可能才是 Bring Your Own Subscription 值得关注的地方。

把聊天变成项目和定时任务

Raycast v2.3 还加入了 Projects 和 Automations。

Projects 可以把同一主题的对话、记忆和工作目录放在一起，直接指向一个代码库、Obsidian vault 或其他本地文件夹。

Automations 则可以按照计划自动运行 Prompt。官方给出的例子包括每天整理邮箱、定时检查 PR，以及根据会议笔记更新记忆。

不过，Automations 并不是一个完全运行在云端的定时服务。

它的计划和 Prompt 保存在创建它的设备上，不通过 Cloud Sync 同步。电脑需要保持唤醒，而且 Raycast 必须正在运行，任务才能准时触发。

从这些功能来看，Raycast 的确正在努力把自己从「Launcher 里的 AI 聊天框」，变成一个跨应用的 AI 操作层。

问题是，其中不少优势可能只是暂时的。

ChatGPT、Claude 以及其他 AI 客户端，也正在不断吸收类似的上下文、工具调用和 Agent 能力。

这层界面也有成本，而且不只是每月 10 美元

并非所有动作都会由我们自己的订阅模型完成。

例如图像生成这类由 Raycast 服务器执行的工具，仍可能调用 Raycast AI 模型，并消耗 Raycast credits。

当 Claude 或 ChatGPT 自己的订阅额度触顶时，Raycast 也不会自动帮我们切换到自己的 credits。我们需要等待额度重置，或者手动切换模型。

还有一个更直接的矛盾：

Pro 方案本身已经包含 500 Raycast credits。

对于一个本来就打算使用自己 Claude 或 ChatGPT 订阅的人来说，这些 credits 反而有点像被一起打包进来的附带商品。

社区里有人欢迎 Bring Your Own Subscription，因为终于不用担心 Raycast credits 很快耗尽；但另一个问题同样直接：

为什么使用我已经付费的订阅、API，甚至本地模型，还要先向 Raycast 付费？

这个问题没有统一答案。

答案取决于 Raycast 提供的这层工作流，对具体某个用户到底有什么价值。

Raycast 没有解决最根本的问题

我之前说过，我更希望 AI 直接发生在上下文中。

看网页时，就在当前 Tab 里问；修改文字时，就直接针对当前选区操作；编程时，就让 AI 面对当前代码库。

为了 AI 再打开一个所谓的「统一 AI 入口」，多少有点强迫症。

Bring Your Own Subscription 没有改变我的这个判断，但它确实让 Raycast 的位置变得更合理了一些。

Raycast 现在不只是让我们在另一个聊天框里使用同一个模型，而是试图把已经付费的模型拉到当前窗口、文本选区、文件、日历、扩展、MCP 和定时任务旁边。

换句话说，它正在努力从「统一 AI 入口」变成一个跨应用 AI 操作层。

但这不仅是效率问题，也是越来越激烈的入口竞争逼出来的选择。

ChatGPT、Claude 和其他 AI 客户端正在向用户桌面靠近，操作系统和浏览器也在加入竞争。有些产品自己拥有模型，有些拥有大量工具，有些则天然控制着用户正在工作的上下文。想想谷歌，想想微软，想想那些企业 SaaS 工具，再想想个人领域的 Meta，xAI Grok ……

在这种情况下，复用 ChatGPT 和 Claude 订阅，并不会自动让 Raycast 变成刚需。

它只是解决了一个越来越明显的问题：用户已经不愿意为了使用同一批 AI 模型，在每个软件里重新交一次钱。

可是，为了「共用」已经付费的模型，每月仍然需要额外支付至少 10 美元，这又把问题绕了回来。

我曾经很喜欢 Raycast。AI 普及以前，它是一款非常优雅、利索、干净的效率工具。但今天的竞争形势已经完全不同了。

仅靠把 AI 订阅方式做得更加灵活，恐怕改变不了更大的趋势：AI 模型公司、操作系统、浏览器和第三方效率工具，都在争夺同一个位置，也就是用户工作的入口。

这场竞争只会越来越激烈。

「文档即工具」开始成为现实，Capsule 想把 AI 生成的小工具存为「单个文件」。

Sat, 26 Sep 2026 15:02:31 +0800

我这几天看到一个让我眼前一亮的项目，叫做 Capsule。

现在让 AI 做一个小工具，已经不是什么特别稀奇的事情了。但一般来说，我们得到的还是一个类似网页的 Web App，需要部署到 Vercel 之类的平台才能运行。

这就让事情重新变复杂了。

先不说部署本身还有一点门槛，首先它通常需要联网运行，然后要考虑数据存放在哪里，有时还要考虑服务器和运行成本。

实际上，我觉得如果只是出于自用目的，让 AI 生成一个小 App，最理想的状态反而应该是在本地运行、本地保存数据。App 可以直接以文件的形式存在，随时复制到其他设备，也可以直接发给别人。别搞什么 SaaS 网站。

Capsule 想做的，就是把 App 和数据重新装回一个文件里。

Capsule 是什么？把小应用和数据放在一起

Capsule 可以理解为一套「应用文件格式 + 打开它的软件」。

我们可以把一个应用封装在 .capsule 文件里，然后双击运行，而使用过程中产生的数据也会保存在这个文件里。本地运行，本地存储。

按照官方的架构说明，.capsule 本质上是一个 SQLite 数据库文件，里面同时保存网页界面、代码、图片等资源，以及我们使用工具时产生的数据。

比如，我想做一个旅行开支本。

打开之后，有添加支出的按钮，有分类，也有统计。填进去的交通费、餐费和备注，同样保存在这个文件里。下次打开时，还可以继续查看、追加和维护之前的记录。

等到旅行结束后，我们甚至可以直接把这个开支本放进旅行文件夹，与行程计划、照片和其他资料一起归档。

我觉得这比单纯强调「AI 生成 App」更容易理解。

因为与其说我们创建了一个工具，不如说我们创建了一个文档，只是这个文档打开之后，本身就是一个工具。

文档即工具。

其实类似的思路以前就出现过。

之前我介绍过 TiddlyWiki（下图），它是一种小众的单文件 PKM，也是一个很早期的例子。整个系统就是一个 HTML 文件，用现代浏览器就能运行。打开文件有操作界面，保存的数据也会写回 HTML 文件中。

以后无论把这个文件带到哪里，里面的知识数据都会跟着走，而且几乎所有 OS 都有浏览器可以打开它。文件即 App。

再往前，还有 Microsoft Access 这类数据库工具。它可以把数据库保存在一个 .mdb 文件中，打开之后有界面，可以录入数据、查询和计算，甚至做成一个小型仓库管理系统。

现在 AI 又把这个老思路带了回来。

区别在于，以前制作这样的东西需要会开发的能力，而现在越来越可能只需要说清楚自己想要什么。

为什么 AI 让「工具即文档」重新有了吸引力

过去要开发一个工具 App，比如前面提到的基于 Access 的仓库管理小工具，你需要了解数据库结构，熟悉 SQL，还要懂一些程序逻辑。

而现在，基本上只需要用自然语言和 AI 对话，让它帮你生成程序、界面和数据库结构。

Capsule 也支持通过自己的 AI 服务来制作和修改 App。它本身坚持 local-first，不需要中央账号和云端文档服务器，AI 请求则可以使用用户自己选择的服务。

AI 显著降低了制作这些小工具的门槛。

我觉得这里甚至有一点 AI 带来「技术平权」的意味。我上次介绍 Raycast 推出的 Glaze，也有类似的感觉。

以前我们讨论了很多年的 Low Code、No Code，在 AI 面前，突然变得没有那么重要了。

既然 AI 已经可以帮我们直接做出工具，那么接下来的问题就变成了：

这些工具为什么还一定要成为一个网站或者 SaaS？

如果只是我自己用，一个能够保存、复制、同步、归档的本地文件，可能反而更加合理。

Capsule 怎么用？先从一个很小的需求开始

Capsule 官网已经准备了一批模板，包括待办清单、开支记录、笔记、闪卡、食谱和工时计费工具，可以先通过这些例子了解它的形态。

我会建议从这些非常具体的用途入手。

例如，一个食谱文件可以包含材料、做法、图片，以及按照人数调整用量的功能。一个工时本可以围绕项目记录时间，月底再查看汇总。

它们的共同点是需求比较明确，而且一个人就能用起来。

如果要交给 AI 定制，描述也应该尽量具体。

假设我们想做一个旅行开支本，可以先这样说：

帮我设计一个适合 Capsule 的旅行开支工具。每条记录包含日期、金额、类别和备注，能够按类别汇总。数据保存在文件里，不需要登录，也不需要汇率联网查询。

这只是一个需求示例。

实际生成之后，还需要检查计算和保存行为，不能只看界面是不是漂亮。

我会先录入几条测试数据，关闭文件后重新打开，看看记录是否还在；复制一份，看看能不能独立使用；需要修改功能时，再检查旧数据还能不能继续读取。

尤其是记账、计费这类用途，更需要认真验证。

按钮能按、图表能显示，只能证明界面已经做出来，并不能证明金额计算一定正确。这些逻辑仍然需要自己检验。

AI 降低的是开发门槛，并没有自动消除软件里的 Bug。

本地优先，「单文件」的能力边界

现在，我们有了一个本地文件。

这个文件是文档，也是数据库，也是 App。

一切看起来都很美好，但这种方式同样有自己的边界。

最明显的是，它天然更适合个人使用，而不是多人同时在线编辑。我们当然可以通过 Dropbox、iCloud、OneDrive 之类的文件同步服务跨设备使用，甚至分时进行多人协作，但它仍然不是 Google Docs 那种实时协作模式。

Capsule 已经专门为文件同步设计了一些事务机制用来处理不同设备上的文件副本发生分叉和冲突的问题，但是效果如何，有待实践检验。

不过，既然整个工具和数据都集中在一个文件里，备份本身就会变得更加重要。

安全也是另一个值得注意的问题。

.capsule 不只是普通文档，里面还包含可以运行的代码。Capsule 本身使用隔离的 WebView、Content Security Policy 和权限控制限制文件访问以及未经授权的网络请求，Web 版也会在浏览器沙箱中执行。

但用户自己分享和接收这种文件时，仍然需要有基本的安全意识。

另外，「工具和数据放在一起」既是它最大的优点，也会带来一个很现实的问题。

比如，我要把一个空白记账工具分享给别人，应该先制作一个干净的模板副本。如果直接把自己正在使用的 .capsule 文件复制出去，就可能连里面已经记录的消费数据一起发给别人。

工具和数据装在一起，意味着分享之前，你必须更清楚这个文件里面到底有什么。

一个 `.capsule` 文件能不能真的像文档一样流通？

单文件并不意味着完全不需要运行环境。

在桌面上，.capsule 文件需要 Capsule App 打开。目前提供 Windows、macOS 和 Linux 版本，移动端原生支持还在计划中。

不过，现在对方也不一定非要安装桌面 App。Capsule Web 可以直接在现代浏览器中打开 .capsule 文件，而且整个运行过程仍然在本地浏览器中完成，文件不会上传到 Capsule 的服务器。Web 版只是无法像桌面版那样直接原地保存本机文件，部分桌面能力也有所区别。

所以，它已经开始接近「发一个文件给别人，对方就能打开」这种体验。

但显然，它还远没有 HTML、PDF、Excel 那样普遍的兼容基础。

这也是 Capsule 能不能真正成立的关键之一。

单文件格式本身并不难做，难的是让这种文件活得足够久，并且十年以后还有稳定的方法打开它。

最后

目前，我更愿意把 Capsule 看成一种值得尝试的个人小工具方案。

先找一个非常小的需求，用少量数据验证，再决定要不要长期使用。

没有必要一上来就把整个资料库搬进去。我们以前折腾笔记软件时，已经见过太多次这样的循环，新工具看起来很理想，等真正积累了大量资料之后，才发现维护和迁移没有想象中那么简单。

很多只属于个人的小需求，完全可以重新变成一个我们自己能够保存、复制、同步、归档，甚至真正拥有的文件。

我甚至希望 DHH 有一天能在 Omarchy Linux 中集成 Capsule，或者某种类似的框架，用来扩充自己的轻量 App 的生态。这其实也很符合 Omarchy 所强调的 AI 原生调性。

总的来说，Capsule 代表的这个方向，我是喜欢的。 AI 降低软件生产成本之后，我们未必需要因此得到更多 SaaS。让 App 重新变成文件，工具重新变成文档。

【免费教程】Omarchy 入门指南（订阅读者专属 PDF）

Tue, 22 Sep 2026 20:03:13 +0800

Vivaldi 8.2 把 Chrome 扩展带到 Android，桌面上的浏览器工作流也能带到手机上了

Tue, 22 Sep 2026 15:01:49 +0800

Chrome 扩展早已进入很多人的日常工作流。

桌面浏览器之所以好用，很大一部分原因就是：我们可以根据自己的需求安装各种扩展。

有人用扩展改善阅读体验，有人用它执行自己的网页过滤规则，也有人习惯把文章按照固定模板保存进 Obsidian。像我自己会使用 Raindrop。

不管具体用什么，换一台电脑时，只要重新安装好这些扩展，或者通过账号同步回来，熟悉的网页处理环境基本也就恢复了。

而到了手机上，这件事一直比较麻烦。

在 iOS 上，Safari 已经支持 Safari Web Extensions（下图），一些原本面向 Chrome、Firefox 或 Edge 的扩展，也可以由开发者转换成 Safari 扩展。

Android 上的情况则更加分散，不同浏览器对于扩展的支持程度差异很大。一个比较变通的办法，是使用 Tampermonkey 这样的脚本管理器，通过用户脚本实现一部分原本由扩展完成的功能。

现在，Vivaldi Android 最近正式加入了 Chrome 扩展支持，让手机直接运行 Chrome 扩展有了新的选择。

2026 年 9 月发布的 Vivaldi 8.2，已经把 Chrome 扩展支持带进 Android 正式版。手机和平板可以直接通过 Chrome Web Store 安装扩展。

我更感兴趣的是：

我们在电脑上积累的网页处理方法，终于有机会直接带到手机上。

Vivaldi Android 怎么安装 Chrome 扩展？

Vivaldi 已经是一款相当老牌的浏览器产品，一直有不少区别于 Chrome 的定制化功能。

比如桌面版直接集成了日历、任务、邮箱以及多面板操作。我一直觉得，它是一款相当有个性的浏览器。

要在手机上使用扩展，首先需要安装 Vivaldi Android 8.2 或更高版本。

然后：

点击地址栏上的拼图图标，进入扩展菜单。
打开 Chrome Web Store，搜索需要的扩展。
点击 Add to Vivaldi，然后确认 Add extension。

这里有一个很容易忽略的细节。

安装扩展时，需要保持 Vivaldi 菜单里的 Desktop Site，也就是「桌面版网站」选项开启。

否则，Chrome Web Store 可能无法正常显示扩展安装界面。

后续操作和桌面版大同小异。安装扩展以后，可以把最常用的扩展固定到地址栏，也可以进入扩展管理页面调整网站权限。

由于手机浏览器的地址栏空间有限，我自己只会留下一个最常用的扩展入口，其余扩展放在菜单中。

Vivaldi 浏览器本身可以免费下载，第三方扩展以及扩展所连接的服务，仍然可能需要各自的账号或订阅。

需要注意的是，这套 Chrome 扩展支持目前主要针对 Android。iOS 受到平台扩展机制限制，目前 Vivaldi 并没有提供同样的支持。

Vivaldi Android 的 Chrome 扩展都能正常使用吗？

还需要注意一点，桌面版 Chrome 扩展不一定都能在 Vivaldi Android 上按照预期运行。

这其实不难理解。很多扩展原本就是为鼠标、宽屏和桌面操作系统设计的。放到手机以后，可能会遇到输入框、软键盘、页面尺寸，以及调用其他 App 等适配问题。

我自己目前测试的几个扩展没有遇到明显问题，但这并不代表所有扩展都一样。

谨慎起见，如果准备把某个扩展正式放进日常工作流，可以拿同一个网页分别在电脑和手机上测试一次：能不能正常打开？能不能输入？能不能执行操作？最后保存的结果是否一致？

尤其是自己最常使用的几个核心扩展，更值得提前测试清楚。

如果只是轻量使用扩展，Tampermonkey 处理一些网页脚本，其实也是不错的选择。尤其对于喜欢 Firefox、对 Chrome 生态没有太大兴趣的用户，用户脚本依然是一种相对开放的方案。

如果完全使用 Apple 生态，Safari 自己的扩展体系目前反而更加自然，在 iPhone、iPad 和 Mac 上都有完整的平台支持。

但我自己的实际情况是同时使用 macOS、Windows、Android 和 iOS，所以我更期待一种不被单一平台锁死的解决方案。

最后

总的来说，Safari 的优势，是 Apple 提供了一套相对受控的移动扩展平台。

Android 的不同之处，则在于各家浏览器是否愿意投入资源实现完整的扩展支持。

Tampermonkey 则把问题缩小成「运行网页修改脚本」，降低了跨平台适配的门槛，但它依然无法消除 API、权限、沙箱以及后台生命周期等方面的限制。

Vivaldi Android 加入 Chrome 扩展支持以后，手机浏览器开始进一步接近桌面端的使用方式。

整理、过滤、剪藏，都有机会继续沿用我们已经熟悉的工具。

不过需要注意，Vivaldi 毕竟不是 Chrome。扩展本体目前不会随 Chrome 上的 Google账号自动同步到 Android，每台设备仍然需要单独安装，这其实有点麻烦。部分扩展的数据可以通过 Vivaldi Sync 在设备之间同步，但具体效果仍然取决于扩展自身的实现方式。

所以我的建议不是把桌面上的几十个扩展全部复制到手机，而是按照自己的需求，只手动安装几个真正重要的核心扩展。

我更看好的是这种跨平台的延续性。

当我们在手机上看到资料时，就能当场按照自己的规则整理、过滤或保存；回到电脑以后，可以直接接着工作。

这种「延续性」本身，就是一种非常实际的生产力。

Vivaldi Android 官网

https://vivaldi.com/android/

Workflowy 2026：有了多窗格、表格和日历，它还是那个极简大纲笔记吗？

Sun, 20 Sep 2026 15:02:06 +0800

如果你已经很多年没有打开 Workflowy，可能还记得它当年最经典的样子：一张白纸，一串圆点，按 Tab 就能继续缩进。

简洁、优雅，也启发了那个年代的很多大纲笔记工具。在我的印象中，Workflowy 几乎是最早开创「大纲笔记」这类产品的工具之一，那已经是十多年前的事了。

我只需要把一个念头写进去，再拆成几个子项。点开其中一个圆点，整个页面就会聚焦到这个节点。这种方式几乎简单到了极致。我们不必先决定内容属于文档、任务还是项目，先写下来就可以了。

到了 2026 年，再用「极简大纲笔记」来概括 Workflowy，已经有些不够了。Workflowy 在 6 月底加入了 Tables 表格功能，9 月发布的月度更新又带来了 Panes 多窗格。加上这一年持续完善的 Calendar，以及原有的 Board，它看起来越来越像一个能承载完整项目的工作台。

说实话，看到老产品有了新变化，我总会感到欣喜，仿佛一位久未谋面的老朋友，从远方归来。

但我更在意的是：各种新功能增加之后，它会不会变得臃肿、繁琐？

Panes：解决大纲工具里一个很实际的麻烦

在大纲里一路往下钻，是使用 Workflowy 时很舒服的体验。眼前只剩下正在处理的内容，很容易集中注意力。大纲笔记的迷人之处，就在于此。

不过，如果需要一边看资料、一边写东西，这种聚焦也意味着要在不同节点之间来回跳转。

Panes 让你可以在同一窗口中，并排打开大纲的不同位置。每个窗格都有自己的导航、搜索和滚动位置；它打开的是原有节点，编辑也会作用于原内容。这让我想到一些 IDE 工具的分屏功能：阅读一段较长的代码时，可以通过多个窗格分别查看不同位置的内容。

目前，Panes 仅支持桌面浏览器和桌面 App，移动端暂不支持，可能是受限于屏幕大小。

例如，左边放选题资料，中间写提纲，右边列出今天要完成的事情。现在，可以把它们同时放到眼前。

我喜欢这类变化：它不要求用户先建立一个复杂的仪表盘，就能减少工作时的来回寻找。

打开新窗格的方式也很直接。按住 Alt 键，Mac 上则是 Option 键，再点击一个圆点，就能在新窗格中打开这个节点。

Tables：为什么适合放进 Workflowy？

大家也许知道，高度结构化的树状节点，其实可以转换为表格，反过来也一样。

Tables 让 Workflowy 变得更完整。

Workflowy 的表格仍然建立在大纲上：一层子节点成为行，下一层子节点成为单元格。

单元格仍然保留了节点的能力，可以继续添加备注、日期、附件或更深层的内容；需要时，还能切回大纲列表。

这很适合用来整理对比表和资料清单。

比如，准备写一篇浏览器文章时，可以先用几行列出候选工具，再加上平台、扩展支持和待核查的问题。某个单元格需要详细解释，继续往里写即可。

在普通表格里，我们经常要在「格子不要太长」和「信息要写完整」之间取舍。大纲式单元格提供了另一种处理方式：概览或许可以很短，细节也可以在将来展开。

Workflowy 也支持从 Excel、Google Sheets、Markdown 或 TSV 粘贴表格内容，并以 HTML、Markdown 或 TSV 格式导出。

不过，不能因此把它直接当成电子表格软件。如果公式计算、复杂的数据关系和大规模分析是工作的核心，我仍会把这些工作留给专门的表格工具。Workflowy 表格更吸引我的地方，是整理文字信息时，不用让注意力离开大纲。

Calendar 和 Board：让资料关联时间与进度

只有资料和提纲，只是一个项目的轮廓，项目还没有真正动起来。

Calendar 提供了每天的记录位置，也能把散落在大纲里的日期事项带到眼前。我们可以把节点移到今天、明天或指定日期。2026 年 5 月加入的 Timeline，又提供了更方便的日程浏览和安排入口。

Board 则适合呈现事情进行到了哪一步。它把子节点作为列，再下一层作为卡片。我们可以在看板里拖动卡片，展示不同的进度阶段。

Board 并不是这次才出现的新功能。值得重新关注的是，它现在可以与表格、日历和多窗格结合使用，效果更好。比如：可以一边看着日历，一边调整看板。

另外，表格和看板对层级的解释不同：一个把子节点当作行，一个把子节点当作列。因此，不能觉得把任意表格可以直接切换成看板。要想得到合理的项目布局，还是需要用户做一些设计。

功能增加之后，它会不会变得太复杂？

这是像我这样的老用户重新打开 Workflowy 时，很自然会产生的疑问。

从目前的设计来看，它仍然保留着同一个基础：节点大纲，再根据需要改变显示方式。官方入门文档仍然从输入、缩进、放大和搜索开始。这让我倾向于认为，它仍然保留着简单的使用入口作为核心功能。

不过，新能力之间的组合，确实增加了些许复杂度。不熟悉这些功能的用户，可能一时分不清节点、表格、多窗格和看板之间的关系。尽管我一开始就注意到：这些变化仍然围绕节点大纲展开，但在上手时，还是琢磨了一阵。

所以，重新尝试时，我会先放进一个小项目，看看并排阅读、编辑和移动节点是否顺手，再决定是否把更多日常事务放进来。

最后

今天的 Workflowy 依旧在向前推进，不断挖掘节点大纲的应用潜力。这种围绕最初产品哲学理念，并逐步拓展应用范围的方式，对我很有吸引力。

相比之下，另一个类似的节点笔记工具 Tana，就已经彻底转型了。

当然，想要使用现在的 Workflowy，费用也需要一起考虑。截至 2026 年，官网列出的 Basic 免费方案包含全部功能，每月可新增 100 个节点；Pro 按月订阅为每月 8.99 美元，按年订阅则折合每月 6.99 美元。

最后，我非常喜欢 Workflowy 的产品理念，但唯一让我不太满意的是，它是一款云端工具，所有内容都存储在 Workflowy 的服务器上。这也是我一直以来力求避免的。我曾经喜欢 Logseq，就是因为节点内容都存储在本地。如果有一款工具，既拥有 Workflowy 目前的功能，又坚持本地优先，对我来说就完美了。

Workflowy 官网地址

https://workflowy.com

Mac、Windows、Linux 文件怎么互传？我现在用 LocalSend 和 Syncthing

Thu, 17 Sep 2026 15:02:08 +0800

如果需要在 Windows、macOS 和 Linux 之间传文件，最直接的办法当然还是 Dropbox、OneDrive 之类的云盘。但如果只是临时传几个文件，或者几台自己的电脑之间长期同步一批资料，其实不一定要先上传到云端，更不一定要为了传几个文件专门登录云盘账号。

我现在主要用两个工具：LocalSend 用来临时跨设备传文件，Syncthing 用来长期同步文件夹。

它们都是免费、开源的，也不要求把文件先存进某个云盘。对于同时使用 Mac、Windows 和 Linux 的「多机党」，基本覆盖了我日常绝大多数文件互传需求。

最近我给两台旧笔记本安装了 Omarchy。之前介绍 Omarchy 时，我提到自己给两台旧笔记本安装了这套 Linux 系统。不过，系统装好以后，还有一个非常实际的问题：原来 Windows、Mac 电脑上的一些文件和配置，怎么搬过去？

如果已经安装了 Dropbox 之类的服务，当然可以直接通过云端同步。或者，提前配置 Syncthing，也可以让文件夹自动同步。

但我的情况是，Omarchy 刚刚装好，还没有规划好到底要安装哪些东西，也没打算马上在这台机器上登录自己的各种云账号。我就只是想把几个文件先从这台电脑扔到另外一台电脑。

这种时候，LocalSend 就特别合适。

LocalSend：适合临时跨设备传文件

LocalSend 支持 Windows、macOS、Linux、Android 和 iOS，免费、开源，而且不需要注册账号。

它的一个核心特点就是不需要云端中转。几台设备位于同一个局域网时，文件直接在自己的网络里传输。官方也把它定位成一种跨平台的本地文件共享方案。

如果把 AirDrop 看作 Apple 设备之间的快速传输工具，那么 LocalSend 很像一个跨平台版 AirDrop。

Windows 发给 Mac，Mac 发给 Linux，Linux 再发给手机，不需要考虑对方是不是同一个生态。

Windows 和 Mac 用户可以直接从 LocalSend 官方下载页面找到相应版本。Linux 则可以根据自己的发行版选择 AppImage、DEB、Flatpak、Snap、AUR 等安装方式。

如果实在不知道怎么安装，我现在在 Linux 上还有一个越来越常用的方法：**直接让 AI Agent 帮我找安装方式，再帮我安装。**当然，这么做显然也存在风险。（AI 一把删光我的文件也是可能的）

如果你用的也是 Omarchy Linux，事情会更简单一些。

Omarchy 已经把 LocalSend 纳入自己的应用组合，在应用启动器中就可以找到。官方手册甚至专门介绍了 LocalSend，把它称作类似 AirDrop 的同网络文件传输工具。

Omarchy 默认会开启防火墙，但专门为 LocalSend 使用的 53317 端口留下了例外，所以装好以后基本可以直接使用。

你当然完全可以自己装 Linux，然后从网络、防火墙到应用逐一配置。但 Omarchy 已经替用户做了一些取舍。这就是我之前所说的 DHH「主厨精选」比较舒服的地方。

LocalSend 怎么用？

具体传输操作非常简单，几乎不用我多费口舌。

如果几台电脑就在身边，而且连接到同一个局域网，两边都打开 LocalSend：

选择文件，找到对方设备，发送，对方接受。基本就是这样。

LocalSend 会给网络中发现的设备显示设备名，也会分配一些奇怪的代号，避免同一个网络里同时出现几台电脑以后搞不清楚发送目标。

LocalSend 还支持通过浏览器链接分享文件。这个功能我觉得特别实用。

因为临时给另外一台设备传文件时，对方不一定已经安装 LocalSend。这时候可以开启链接分享，让对方直接通过浏览器访问。

也就是说，一边有 LocalSend，另外一边甚至可以不用提前安装客户端。特别适合临时使用。

LocalSend 偶尔为什么传不了？

我绝大多数时候使用 LocalSend 都没有什么问题。

非常偶尔，也遇到过明明能看到设备，却无法正常传输的情况。我最后排查下来，主要还是自己的防火墙和网络配置问题。

这也是局域网传输工具共同存在的一个局限。

它不依赖云服务器是优点，但也意味着设备之间首先得真的能够互相访问。如果公司、酒店、公共 Wi-Fi 对设备之间的访问进行了隔离，或者自己的防火墙规则有问题，那么 LocalSend 自然也没有办法凭空打通。这方面，我有些个人经验。对于家里或者自己的工作网络，一般不是什么问题。

如果你只是想找一个 Windows、Mac、Linux 之间临时互传文件的方法，我会首先推荐 LocalSend。

如果我希望一个文件夹今天在 Windows 上修改，明天打开 Linux 时已经自动变成最新版，那就需要另外一种工具了。

Syncthing：适合多台电脑长期同步文件

这时候登场的是 Syncthing。

Syncthing 同样免费、开源，而且也不要求注册一个 Syncthing 云账号。

不过，它和 LocalSend 解决的是完全不同的问题。

Syncthing 更像是让几台电脑上的某个文件夹一直保持同步。

如果一定要拿大家熟悉的产品类比，我觉得可以把它理解成一种没有中央云盘的 Dropbox。

Dropbox 的基本逻辑是：

电脑 A → 云端 → 电脑 B。

而 Syncthing 更强调让自己的设备互相同步。官方对它的描述也很直接：文件不会上传到 Syncthing 云端，而是在用户自己的设备在线时进行交换。

这正好适合我现在这种情况。

我有 Windows 主力电脑、Mac，还有几台 Linux 机器，希望其中一些 Markdown、项目资料、脚本和配置文件长期保持一致。总不能每天用 LocalSend 发一遍吧。这种事情交给机器自动处理才合理。

Syncthing 怎么工作？

Syncthing 第一次配置比 LocalSend 稍微复杂一点。

它会给每台设备生成一个 Device ID。想让两台电脑同步，首先要让它们通过 Device ID 互相认识，然后指定哪些文件夹需要共享。

而且这个授权是双向确认的，并不是知道另外一台设备的地址以后，就可以随便访问它的文件。

配置完成以后，就可以基本忘掉它。

例如，我在 Windows 上建立一个名为 Research 的文件夹，然后把它通过 Syncthing 分享给 Linux。

以后往这个文件夹里新增文件、修改 Markdown，甚至删除文件，相应的变化都会继续同步到其他设备。Syncthing 会监测文件变化，并让参与同步的设备逐渐达到一致状态。

这就是它和 LocalSend 最大的区别：

LocalSend 是一次性的传输动作，Syncthing 是一种持续的同步关系。

Syncthing 本身也比较特别，它更像一个后台服务，没有一般桌面软件那种传统的管理界面。主要通过浏览器打开 Web 管理界面进行配置。有点像路由器，需要进入一个特定的网页维护配置。

第一次使用时，看到 Device、Folder、Remote Device 这些概念，可能会觉得它没有 LocalSend 那么简单。但一般只要第一次设置完成，以后反而基本不用再管。

而这个设置最主要的操作，就是在不同设备之间配对文件夹，让「文件夹对」保持同步。

LocalSend 和 Syncthing 怎么选？

所以，这两个工具其实并不是竞争关系。

我自己的选择非常简单：如果只是偶尔跨设备传文件，我觉得甚至没有必要去折腾 Syncthing。

反过来，如果有几个资料库，几台自己的电脑长期使用同一批文件，而且不想依赖云盘或云端中转的话，那可以考虑 Syncthing。

如果更看重省心，而且愿意使用云服务，Dropbox 之类的云同步体验通常会更好。

简单来说：LocalSend 负责 Send，Syncthing 负责 Sync。

但是，同步不是备份

这里还有一个非常重要的区别。

Syncthing 是文件同步工具，不应该直接把它当成备份工具。

这一点其实和 Dropbox、OneDrive、iCloud Drive、Google Drive 一样容易让人产生错觉。

看到三台电脑上都有一份文件，人很自然会觉得：我已经有三份了，应该很安全。但问题在于，它们之间是同步的。

如果你在其中一台电脑上误删了文件，这个删除本身也属于一种文件变化，完全可能继续同步到其他设备。

Syncthing 可以配置 File Versioning，帮助保留被替换或者删除文件的旧版本，但这依然不应该替代真正独立的备份。

所以：传输是传输，同步是同步，备份是备份。

LocalSend 帮我把文件送过去；Syncthing 帮我让几台设备长期保持一致。而真正重要的数据，还是应该另外有一份不跟着日常操作自动变化的 Backup。

最后

现在安装一台新电脑以后，我不再第一时间考虑我要先登录哪个云盘。

我的 Omarchy Linux 现在完全可以先保持一个很干净的状态。

需要临时拿几个文件过来，打开 LocalSend。
确定以后这台机器会长期参与某项工作，再把对应文件夹加入 Syncthing。
真正重要的数据，另外进入自己的备份体系。

特别是在 Windows、Mac、Linux 混用以后，我越来越觉得，跨设备并不天然等于上云。云盘当然非常方便，我也完全没有打算弃用 Dropbox 或其他云服务，而是让各种方案发挥各自长处。

但以前，我们经常把「让另一台电脑得到这个文件」和「把这个文件先上传到一家公司的服务器」看成同一件事情。其实完全不是。逐渐把数据和文件的控制权拿回自己手里，掌握自己的系统，这是我一直在追求，也建议所有人关心的事。

【速报】本地优先的 Notion 替代品 Anytype 为什么要被重写？

Sun, 13 Sep 2026 10:02:05 +0800

被称作「本地 Notion」的 Anytype 已经出来 6 年了。

最近的消息表明，他们要推出下一代重构版的 Anytype 了。新产品名为：Anytwo，其实就是「Anytype 2.0」

Anytwo 希望解决旧架构留下的问题，也把迁移、兼容旧版本Anytype 放入了计划。目前还处在很早期的阶段。不久后就会有测试邀请，新版本不承诺和 Anytype 功能完全一样，

为什么要重写，而不继续加功能？

Anytype 原来的理念很吸引人：把笔记、人物、项目等作为对象（Object），通过关系把信息组织起来。我现在还记得当时创始人说如何用 Anytype 的对象来整理他个人生活的信息，比如：联系人，书单 ……

难能可贵的是，Anytype 同时坚持 local-first，让数据先保存在自己的设备上，支持离线使用、加密同步和自托管。

问题在于，理念能走多远，也受底层架构的限制。

按照官方说法，复杂的旧中间层已经拖累稳定性和开发速度，沿用了六年的编辑器也积累了不少问题。Anytwo 用新数据库替换旧中间层，并重做文件节点。

我的理解是，历史包袱太重，旧有代码难改。很多产品到后期都很难维护，这是实情，不如推倒重来。

写作和整理功能都会重做

Anytwo 的笔记表编辑将改用 Lexical 框架，目标是改善 Markdown、响应速度和编辑体验。Lexical 是模块化的编辑框架，可以扩展列表、链接、表格等能力（下图）。

对普通用户来说，框架叫什么其实不重要。但这几年笔记编辑框架已经有了日新月异的升级；当年我个人预测的 Notion-like 的模块化编辑将成为很多软件的标配；现在来看已经实现，甚至已经达到开源人人可用的级别。

另一个重大改动是：Collections 2.0。
在宣布重做 Anytype 之前，官方就已经开始讲他们引入 Collections 2.0 的概念。我那时看见了，只以为是 Anytype 要添加了一个加强功能，没想到是要重做整个产品。

Collections 2.0 想降低组织资料的负担。现有 Anytype 要区分类型、集合、查询等概念；新的设计弱化单一类型限制，让同一个对象可以进入多个集合，在不同上下文里呈现相应属性。

比如，一份采访材料可以同时属于「本周选题」和「某家公司」。用户更容易围绕正在做的事情整理资料，不必先花太多时间决定它到底算哪一种 type 的对象。说到这里，也许就能理解，为什么新品名字恐怕都不能继续叫 Anytype 了。

笔记之外的能力

Anytwo 还计划加入 Mini Apps、连接邮件和日历等外部工具的 Connectors，以及可选的 AI Agent。

这些能力放在一起，就能看出重构的另一层意图：笔记和数据库成为基础，上面可以运行不同的小工具，再由 Agent 协助操作。新的底层文档也把数据库、程序运行和加密同步放在同一个体系里。

我觉得，这也是本地优先笔记向「个人计算平台」延伸的信号。目前几乎每天都有 Markdown 本地编辑器+ AI Agent 的所谓新品诞生。说明这是一种趋势，Anytype 想要跟上，但又受限于旧架构，那么重做势在必行。

实际上，大家有没有发现，如果撇开 Anytype P2P 架构，其实 Anytype 在现代是一个几乎没有有差异性的 PKM 产品。尽管在诞生之时，「万物皆对象」的理念很惊艳，但是随着 Obsidian 丰富了「元信息」管理功能，又有 Capacities 这样主打对象笔记管理的产品，再加上其它 PKM 多少都能兼容「对象管理」，一切似乎也没有那么神秘。

不过，对现有用户来说，眼前更重要的是接下来怎么办。

对现有 Anytype 用户，有哪些实际影响？

现有 Anytype 可以继续用，但开发会放慢

官方表示会继续支持旧产品，同时把主要精力转向 Anytwo。这意味着，你不需要因为新平台出现就立刻搬家，但期待中的改进可能要等得更久甚至遥遥无期。

这次需要迁移，不能当作普通升级

新平台放弃了向后兼容，Anytype 团队计划提供迁移桥梁。旧资料如何进入新环境、原来的组织方式如何对应，都需要等迁移方案明确。

而且，新版本早期并不具备旧版的全部功能。如果依赖于旧版某些功能的要慎重。

付费权益如何衔接，还没有定案

Anytwo 计划提供免费层，但会员结构，以及旧用户权益怎样转移，仍待公布。据说，之前Anytype 的付费率是 2%，已经可以养活团队。

以上这些也是 Anytype 讨论社区反应比较复杂的原因。有用户期待新编辑器和更快的开发，也有人担心测试风险和兼容性，感叹之前花时间熟悉的系统又要重新学习了。

最后

我个人挺期待 Anytype 进行彻底翻新的，旧架构的维护问题总是棘手的。AI Agent 的普及也使得很多年以前的旧产品必须重新考虑能否跟得上。

但对现有用户来说，我还是更关心：资料能否顺利迁移，原来的工作能否继续，新的体验是否确实更好。

如果 Anytype 已经承担了正式工作，建议先保留在现有版本；有兴趣就用独立测试资料体验 Anytwo，等迁移工具和功能覆盖更清楚，再决定是否切换。

从更长远看，就会发现 Obsidian 从一开始就已经在架构上考虑到兼容未来新的技术或 App。 File Over App 理念的含金量还在提高。 Anytype 的重写更像是增加了一个脚注。

参考

文件优先，本地优先，我对 File over App 理念的理解

Notion 能导出，却未必能恢复：真正该备份的不是文件，而是业务连续性

Thu, 10 Sep 2026 15:02:26 +0800

备份不是恢复

Notion 是一个出色的在线工作空间。我觉得最好的使用方式，就是在上面工作，而不要去想完整备份和恢复这件事。

使用 Notion，多少需要有一点这样的「信仰」。

这也是阻止 Notion 深入一些真正「重要」工作场景的障碍。它可以在许多较浅的工作流里表现得非常出色，但一旦进入「深水区」，很多事情就只能祈祷 Notion 官方帮你搞定一切。

最近，Notion 已经逐步取消了整个工作区的 PDF 导出。不过，这项调整只针对 PDF 格式。工作区仍然可以导出为 HTML、Markdown、CSV，单独页面也仍然可以导出为 PDF。

所以，Notion 并不是不允许你把数据导出来。

但是，也千万不要因此松一口气。我从一开始就没有太看好 Notion 的整套导出机制。

这就像有人给我一把锤子、一把铲子、一把汤勺，再加几十个纸板箱，让我去「打包」一座宫殿。

现在只是告诉我，锤子不能用了，但其他工具仍然可以继续使用。要我说，这并不改变结果。因为整套「打包工具」本身，就不足以完成真正的「恢复」，那么「打包」的意义何在？不如说是「拆卸」？

我们首先要弄清楚，「导出」到底是为了什么？

在我的理解里，至少涉及两件事情：

数据所有权，以及业务连续性。

我们不能把所有数据都押在单一供应商的在线存储上。所谓备份，就是当这个供应商失效时，我仍然有办法保证数据不会丢失，工作还可以继续。

而到了 Notion 这种程度，问题早就不只是「数据存在哪里」了。

回想起来，Notion 早期更接近一个使用模块搭建页面和工作空间的工具，但发展到今天，它已经变成了一个综合性的工作平台。数据库、项目管理、Wiki、表单、自动化、权限、协作，再加上 AI，这种绑定还在不断加深。

所以设想一下，如果某一天 Notion 暂时失效，问题已经不只是页面和表格还能不能下载下来。

整个工作流都可能一起失效。

这里需要把几个经常混在一起的概念分开：

导出，是把数据拿出来。

备份，是留下可以使用的数据副本。

恢复，是发生问题后，能够恢复原来的工作状态。

迁移，是换一个系统之后，工作仍然能够继续。

这四件事完全不是一回事。

还是回到那座宫殿。你可以用铲子、汤勺和纸板箱，把壁画、柱子、雕像、家具一样一样取出来。但你不能指望靠这些东西，轻松复原出原来的宫殿。

因为真正重要的东西之一，是它们之间的结构关系。Notion 也一样。

这种导出可以把页面、表格、图片、附件等内容取下来，但复杂的映射关系、工作流逻辑、数据库计算、权限，以及越来越重要的 AI 协作上下文，并不会完整地跟着这些文件一起离开。

事实上，Notion 官方自己也明确说明，你无法简单地把导出的整个工作区重新上传，然后直接重建出原来的 Workspace。更不用说，要把这一切完整迁移到另外一个系统。

换句话说，如果你没有一套不依赖 Notion 的备用方案，那么一旦平台出了严重问题，你的工作就可能实质性停摆。

这不仅仅是 Notion 的问题

不敢说所有，但很大一部分在线 SaaS，尤其是前几年一窝蜂兴起的那些「大而全」的平台，都存在类似的问题：

可以导出数据，却未必能够恢复工作。

换句话说，使用这些平台，多少都需要对平台怀有一点「信仰」。

当然，在严肃的业务场景下，我们还有 SLA、合同、法律责任之类的保障。但这些终究只是协议，并不能替代技术上的可恢复能力。

最可靠的保障，还是自己拥有数据，同时有能力恢复工作。

我相信，类似 Notion 的产品一开始并不是刻意设计成这样的。但随着功能不断增加，尤其是 Database、自动化和 AI 加入以后，事情开始迅速变得复杂。

这就像一家公司。即使我拿到了一个伟大公司的所有纸面文件，也无法据此重新建立这家公司。因为真正宝贵的东西，可能是几十年来形成的组织关系、企业文化、合作默契，以及大量没有被明确写下来的隐性上下文。

至于那些会议记录和财务报表？3个月以后，其中相当部分可能已经只是归档仓库里的历史资料了。

软件平台也是一样。

当一个工作系统足够复杂以后，真正值钱的就不再只是「文件」，而是文件之间的结构、关系、状态，以及围绕这些东西形成的上下文。

所以，既然事情已经发展到了这个阶段，就应该重新思考这个问题。

我不太想给出一个 Old School 的答案，比如加强数据备份和恢复能力、完整保留更多元数据、建立更复杂的灾备机制……

这些当然都有用。但在讨论解决方案以前，我们还应该继续往下挖一层。

AI 正在改变 SaaS 原来的价值

Notion 这类工具，包括很多类似的 SaaS 平台，其实有一个很有意思的尴尬：

它们大多是在 AI 兴起以前设计出来的。

这些产品过去的一个共同商业逻辑，是用便利换取用户留存、平台绑定和付费。

类似乐高积木的页面排版方式、随时在线访问、多人实时编辑、嵌入文档体系的数据库、各种视图和自动化……

这些当然都有价值。但其中相当一部分价值，本质上是我们过去面对数据和流程复杂性时做出的妥协。

以前一个普通用户不会写数据库查询，不会写自动化，不会自己搭接口，也很难把几个不同的软件连接起来。

所以平台说：

把所有东西放进来吧，我给你一个简单的按钮。

于是人们愿意为了这种便利，把自己的数据、结构和工作方式都放进同一个系统。

但 AI 正在改变这个前提。

当 AI 可以帮普通用户整理文件、查询数据、修改文档、建立工作流，甚至直接操作多个不同的软件时，原来很多依赖「把所有东西塞进同一个平台」才能获得的便利，价值就可能越来越弱。

这些 SaaS 必须继续提供更高层面的便利。而那个「更高层面」已经是一个截然不同的竞争领域，周围也早已有后起之秀环伺。

还有另外一个变化。过去生产力软件最重要的问题之一是：解决人与人协作的困境
未来则会越来越多地变成：怎么帮助人与 AI 协作

过去的软件设计，把大量精力花在权限、评论、通知、分工、审批，以及各种人与人之间的沟通机制上。

以后很大一部分设计重点，会逐渐转向如何让 AI 理解数据、获得上下文、执行工作，并把结果交还给人。

至少从 Notion 这些年对 AI 的投入来看，它显然已经在往这个方向大幅押注。

所以，数据备份和恢复看起来是一个老生常谈的问题，背后却出现了一个全新的挑战。

只要业务可以继续，现代的用户其实未必那么关心原来的 SaaS 到底提供了多少「便利」，也未必在意接替工作的到底是另外一个软件，还是 AI。恢复到原来那个 SaaS 上反而是一个掣肘的选项。

所以，这已经超出了导出和备份的范围，开始变成一个如何重新设计「业务连续性」的问题。

替代方案可能反而很直接

那么怎么办？

我的思路并不是「彻底离开 Notion」，而是：

重新安排 Notion 在整个工作系统里的位置。

Notion 是一个很好的工具。但它不应该成为那个唯一承载一切数据、一切结构和一切工作流的工具。

只要做到这一点，备份和恢复的问题反而可以简单很多。

缩减 Notion 的作用，让它做自己擅长的事，而不是全部

Notion 最强的地方，是轻量协作、快速搭建、信息展示和共享。

那就让它专注在这些「浅水区」。项目看板、团队 Wiki、对外页面、临时协作，这些都是很合适的用途。

而真正构成业务核心的东西，比如核心数据、关键逻辑和长期资产，不要只存在 Notion 里面。

把 Notion 当成一个「界面」和「协作层」，而不是唯一的「持久数据层」。 让它只是一个前端。这样，即使有一天失去它，也不再是一场灾难，而只是换一块显示屏。

不要让 AI 成为「平台附庸」

与其依赖某个平台内嵌、无法真正带走的 AI，不如围绕自己的数据，建立自己可以掌控的 AI 协作方式。

现在这样的 AI 工具已经越来越多了。让 AI 直接面对你本地的、开放格式的文档和数据，而不是隔着某个供应商专属的 AI。当然，Notion 大概不会喜欢我这个建议。

从用户角度来说，这意味着 AI 积累的上下文、形成的理解，以及围绕你工作建立起来的能力，都更接近你自己的资产，而不是某个 SaaS 平台的护城河。

未来业务连续性中越来越重要的一部分，可能就是：

AI 上下文的连续性。

换一个模型、换一个 Agent、换一个前端，只要核心数据和上下文还掌握在自己手里，工作就可以继续。这样，你也不必再把某个平台自身的完整恢复能力，当成唯一退路。

本地优先（Local-first）

这是整个方案的地基。

数据的「持久性」应该首先存在于你自己能够完全掌控的地方。

本地磁盘、自己的仓库，以及开放、持久的格式，比如 Markdown、纯文本、SQLite、CSV，这些几十年以后大概率仍然能够被读取的东西。

云端可以是「同步」和「协作」的便利层，但不应该成为唯一的持久化存储层。

Local-first 真正重要的是：即使明天所有 SaaS 都关门，打开自己的电脑，数据依然在那里，工作依然可以继续。 而且，这些数据还可以通过更多更基础的方式进行备份、迁移和恢复。

构建工具链，而不是依赖单一平台

与其把整座宫殿盖在别人提供的一块地基上，不如使用一组可以互相替换的积木，搭建自己的工作流。

每一个环节，包括编辑、存储、同步、检索、AI，都应该尽可能可以被替换。

判断标准其实很简单：假如这个供应商明天消失，替换它需要付出多大代价？

如果答案是「整个业务停摆」，那说明你已经把太多东西押在它身上了。一个健康的工具链，应该做到任何一个环节都可以拔下来换掉，而整体仍然可以继续运转。

这当然意味着前期要接受一点「不方便」。你可能需要接受不那么丝滑、不那么「一站式」的体验。但换来的，是自由和韧性。

最后

Notion 取消整个工作区的 PDF 导出，本身其实是一件小事。甚至可以说，PDF 本来就是几种导出格式里面最不适合恢复工作的一种。

但这件小事提供了一个很好的提醒：你手里那把「导出」工具，从来就不是为了「恢复」准备的。

备份从来不等于恢复。能下载，也不等于能继续工作。

我并不是在针对 Notion。恰恰相反，我觉得只有认清一个工具的边界，才能更加放心地使用它，同时又不必把自己的身家性命一起交给它。

信仰可以有。但信仰不该成为唯一的备份方式。

所以，还在下载那几十个装满壁画、柱子和雕像的纸板箱？还在纠结到底应该选择 PDF、HTML 还是 Markdown？这些其实都不是最重要的。

真正要紧的是：

把宫殿建在自己能够掌控的坚实地基上，而不是建在某个单一供应商的平台里。

把屏幕上的问题说清楚，重新认识 ZoomIt ：放大、标注、长截图和录屏

Tue, 08 Sep 2026 15:02:25 +0800

电脑上有一类操作，很多人每天都在做：看到一个问题，截张图，圈出位置，发给别人。

现在有了 AI，这件事情似乎变得更有价值了。我就经常截取屏幕、加上标注，然后发给 AI Agent，让它帮忙分析、策划，或者排查问题的原因。很大程度上，把 AI 当作一个同事或工作伙伴来沟通就可以了。但即便如此，基于屏幕内容的沟通仍然很重要。

比如，让 AI 看看某个产品的按钮设计是否合理；或者某个工具打不开、没有按我的意思运行时，附图问问 AI 这是为什么。甚至直接把一堆报错信息扔过去，或者扔过去一张网页截图。（对，我连复制网页地址都懒得弄了。）

有时候一张图就够了。有时候内容超过一屏，需要长截图。还有些问题，用文字解释半天也说不清，但录下十几秒操作，对方马上就明白了。又或者加个箭头、画个框，立刻就容易理解很多。

无论是对人还是对 AI，清楚表达意图的能力都非常重要。

所以，我觉得屏幕工具很值得有一套顺手的工作流。能让人看清楚、指出重点，再把结果带走，发到原本就在用的邮件、聊天工具或 AI 客户端里。

Windows 上有个老牌工具，ZoomIt，我觉得就很适合从这个角度重新认识。

ZoomIt 是什么？一个随时叫出来的屏幕工具

ZoomIt 来自微软 Sysinternals，由 Mark Russinovich 开发，现在也已经整合进 PowerToys。

这个工具的历史相当悠久。Sysinternals 最初是一家开发 Windows 系统工具的独立公司，后来被微软收购。ZoomIt 也一直保留着那种老派实用工具的味道，不太讲究花哨的包装，重点是把事情做好。

很多人对它的印象，仍然是演讲时放大画面、画个红圈的小工具。其实它已经把屏幕放大、标注、截图、滚动长截图、快速录屏和简单视频裁剪放到了一起。实时演讲，只是其中一种用途。

而且，说句公道话，演讲和远程会议通常都有专门的屏幕标注工具，比如 Zoom 就自带类似功能。ZoomIt 的吸引力，在于它离日常操作很近，不局限于演示或开会。无论我眼前是网页、表格、软件设置，还是一条报错，都可以从当前屏幕立刻开始处理。

先说明一下，本文以 Windows 版为主。可以下载独立版本，也可以在 PowerToys 设置中启用 ZoomIt。我发现两者的版本略有不同步，所以具体功能和快捷键，还是以自己安装的版本为准。

另外，ZoomIt 现在也有了原生 macOS 版。微软在 2026 年 7 月 24 日宣布推出 ZoomIt for Mac，包含放大、标注、截图、录屏、视频裁剪和 Panorama 等功能。苹果用户也可以体验了。

但说实话，这种偏实用主义的小工具风格，未必符合所有 macOS 用户的审美。而且 macOS 上也有不少类似的付费工具，选择并不缺乏。

ZoomIt 是免费的，本身不要求订阅云存储服务，也不需要付费账号或邀请。这种老工具诞生的时候，根本没有那些概念，也不需要依赖这些东西。

我个人也很反感有些工具：明明只是一些简单功能，却要收月费、年费。某种程度上，就是赌普通用户不了解还有哪些更多的选择。

放大和标注，一个人用电脑时也用得上

先说最简单的用途：看清一处细节。

比如软件里有一段很小的提示，或者想仔细看某张图的局部。按 Ctrl + 1 进入普通放大，滚轮调整倍率，就可以临时把注意力集中到那里。

如果需要一边放大、一边继续点菜单或操作应用，用 Ctrl + 4 开启 LiveZoom，完成后再按一次退出。

这两种模式要分清：普通放大适合停下来观察和标注；实时放大适合继续操作。在普通放大模式下，单击鼠标会进入绘图模式，不要把放大画面里的按钮当成原应用继续点击。

正如前面所说，标注也未必要有观众在场。

自己检查一个页面时，可以临时圈出待检查的位置；整理反馈时，可以给有问题的地方画框。按 Ctrl + 2，就能在不放大的情况下进入绘图。绘图时按住 Ctrl 拖动可以画矩形，按住 Ctrl + Shift 拖动可以画箭头，画错了用 Ctrl + Z 撤销。

这里的笔迹属于屏幕上的临时标注，不会修改网页或原文件。

想留下来，就把它变成截图。只用来帮助自己看清楚，用完退出即可。

圈出问题，截图，直接放进邮件和聊天

这是我觉得最容易融入日常的一段流程。

我常用的 Snipaste 也有类似功能，只不过 Snipaste 是先截图，再标注；ZoomIt 是先标注，再截图。甚至两者可以混用，ZoomIt 主打标注，Snipaste 则可以灵活地选取截图区域。

假设我们收到一张表格，需要告诉同事：「总额没有问题，但这里的负责人选错了。」

可以按下面的顺序处理：

把订单页面调整到合适的显示大小，保留订单名称和负责人字段，让对方知道这是哪一项。
按 Ctrl + 2 进入绘图，给负责人字段画一个框。
在绘图模式下，按 Ctrl + Shift + C 裁取需要的画面到剪贴板；也可以用 Ctrl + C 复制当前截图。
退出标注，切回支持图片粘贴的邮件或聊天输入框，按 Ctrl + V。
补上一句具体要求：「请把这张订单的负责人改为 Jane。」

如果只是截取一块区域，不需要标注，可以直接用 Ctrl + 6；想直接保存区域截图，用 Ctrl + Shift + 6。

截图保留足够的上下文，标注只突出一个重点，通常比画满箭头更好理解。

这种方式用在和 AI 交流时，同样有效！

一屏放不下，就用 Panorama 滚动长截图

普通截图遇到长页面，往往会变成好几张图。

一段设置说明、一张较长的清单，或者需要保留上下文的页面，分开截以后，对方还要自己拼出顺序。ZoomIt 的 Panorama 就是为这类滚动内容准备的。

默认按 Ctrl + 8 启动，选择要捕获的区域，再滚动内容，完成后按同一快捷键结束。它会把滚动过程中捕获的画面拼接成一张长图，并复制到剪贴板。需要直接保存文件，可以使用长截图保存快捷键，默认为 Ctrl + Shift + 8。

比如，同一个设置面板里的几组选项需要一起给对方看；或者一段错误信息很长，单张截图装不下；更常见的就是一个网页，一路滚动下去，生成长截图。

操作时可以先让页面加载完整，尽量只框正文区域，缓慢、连续地滚动。保存后检查接缝、重复行和缺失内容。页面里有悬浮栏、动画或边滚边加载的内容时，更值得看一眼结果。

长截图也有一个很现实的问题：发进聊天以后，预览可能被缩成细长的一条。就像下面这样：

因此，留资料时可以保存完整长图；要求对方处理某个具体问题时，另外附一张局部截图，或者在文字里写清楚看哪一段。

长图负责保留上下文，局部图负责让人快速找到重点。

动作说不清，就录十几秒，再裁掉多余时间

我知道有很多简易录屏工具，有段时间我一直用 ScreenToGif。ZoomIt 也有类似的功能。

有些事情，录一段几秒钟的动图，通常比啰嗦地写一串「先点这里，再点那里」更省事。顺便一说，有些高级 AI 也已经能理解视频内容了。我越来越觉得，AI 有潜力成为一个不错的工作伙伴。

ZoomIt 可以录整个屏幕，也可以只录区域或鼠标所在窗口。默认入口分别是 Ctrl + 5、Ctrl + Shift + 5 和 Ctrl + Alt + 5。

结束录制后，内置的 Trim 编辑器可以在保存前截短片段。新版还支持追加其他片段，并在片段之间选择简单的转场，已经不只是剪掉头尾那么简单了。

不过，它仍然是一套偏轻量的录屏处理工具。如果不想把整个桌面录进去，应当在开始时就选择区域或窗口录制；如果需要复杂剪辑，还是要使用专门的视频编辑工具。

输出格式可以选 MP4 或 GIF。我的取舍是：普通操作反馈先考虑 MP4；很短、无声、适合循环看的动作用 GIF。GIF 没有声音，也不意味着文件一定更小。收件端能否直接播放、附件大小是否合适，发送前看一下即可。

如果需要口头说明，检查录制设置里的麦克风输入。只发操作步骤，就确认音频选项符合自己的需要。不要默认录屏一定同时录到了自己的声音。

还有一个小提醒：录屏前最好先关掉可能弹出私人信息的通知，检查桌面上有没有不想让对方看到的内容。屏幕工具越方便，越容易顺手把不该发出去的东西也录进去。

DemoMirror 和实时演讲，是屏幕工具的另一种输出

前面几种用法，最后交出去的是图片或视频。而 DemoMirror 是一个较新的功能，需要当面讲解时，我们交出去的就是实时画面。

DemoMirror 可以把整个屏幕、选定区域或鼠标下的窗口镜像到第二块显示器，并带上鼠标指针。窗口跟随选项 Track window region 会随着窗口移动和改变大小，调整镜像区域。

比如，自己坐在电脑前操作，让旁边的人看另一块显示器；或者做培训时，在笔记本上操作软件，把内容显示到投影屏。当然，也可以配合刚才说的放大和标注。

可以把它理解成 Windows 屏幕镜像功能的加强版，能够选择特定区域或窗口进行共享，而不只是把整个桌面原样投过去。

默认 Ctrl + 9 用于启动和停止整屏镜像，Ctrl + Shift + 9 选择区域，Ctrl + Alt + 9 选择鼠标下的窗口。双屏场景先用 Windows 的扩展显示模式，并确认目标屏幕上的内容正确。

最后

如果每天只是偶尔截一张图，现有截图工具已经很顺手，没必要为了功能更多就换掉。

但是，考虑到 ZoomIt 整合了好几种常见的屏幕处理功能，一个工具就能覆盖多种需求，还是值得安装试试。

最可能需要注意的是「快捷键」。ZoomIt 的默认快捷键大多是 Ctrl + 数字，这些组合在其他软件里也常有用途（比如：Chrome），可能需要到设置里换一组。还有就是，对快捷键熟练后，我们的操作会很方便很快速，但前期适应过程会比较痛苦，而其它精美 GUI的截图工具，就显得很友好。

另外需要注意的是，PowerToys 和 ZoomIt 独立版，不要同时启用。为避免快捷键、托盘和进程冲突，选择其中一种使用即可。

我觉得 ZoomIt 最有价值的地方是，非常简单实用，没有花哨的修饰，以解决实际日常问题为主。

这些零碎的屏幕处理需求，可以随手解决；处理完后，图片和视频就能直接扔进邮件、聊天、文档或 AI Agent 里。真的是：效率拉满。

Prompt 正在从一次性输入，变成可以复用的「工作规则」，Google 开始测试 Workspace Skills

Sun, 06 Sep 2026 15:02:27 +0800

很多人每天都在重复写同一类 Prompt。起初可能只是一句「把这几份记录整理成报告。」然后会不停修正提示词，直到满意，下一次最好从已经更新过的版本开始，有可能再修正。随着时间推移，Prompt 会和工作流紧密贴和在一起，成为某种「最佳实践」。

我周围有些人，已经有意识的在收集保存自己的「提示词」了，防止每次「从零开始」和 AI 交流。事实上现在许多 AI 应用带有记忆，即使我们的要求比较模糊，也能根据以往的修改建议自行迭代优化，并且记住复用。甚至有人在做这类产品，这我觉得倒没有特别的必要。

而 Google 最近在 Workspace Studio 里推出的 Skills 测试，就很好地印证了这种变化，Prompt 将离开聊天框，从一次性文字变成可以保存、命名、共享和调用的长期工作资产。我的理解是，Skill 就是用户能意识得到，而且可复用的 Prompt。

Skill 更接近过去的 Office Template 或者 Macro 之类的东西了，只是普通人建立规则的门槛低了很多，如果这些规则只留在某一段聊天记录里，它们就很难被稳定复用，也无法交给其他人复用。从这个角度来说，Prompt 实际已经开始承担 SOP 的功能。

Google Workspace Skills 做了什么

Google 在 2026 年先为 Chrome 推出 Skills，让用户把 Gemini 侧边栏里验证过的 Prompt 保存成一键工具，在不同网页上重复使用。只要用 / 就可以调出 Skills 列表，这也是主流的做法。

到了 8 月，Workspace Studio 里的 Skills 又向前走了一步。

用户可以建立一套可复用指令，让 Gemini 使用团队规则、模板和 Google Drive 中的参考文件来完成任务。Skill 可以被分享给团队，也可以通过 @ 提及，在 Gmail、Docs、Slides、Drive 和 Chat 的 Gemini 侧边栏中调用。

例如，一家公司可以建立「客户提案」Skill，里面不只是写一句「帮我制作提案」，还可以包含：

先从当前邮件和 Drive 文件提取客户背景；
必须使用公司批准的品牌语气；
按照指定 Slides 模板生成；
……

这时，Prompt 已经不是一次输入，而是一套随时可以被调用的「工作流规则」了。

Skill 不只是保存了一段 Prompt

最简单的 Prompt Library，只是把常用文字存起来，使用时再粘贴。

Google 由于有 Workspace 生态， Skill 通常至可以支持：Instructions、References 和 Template。

Instructions 规定 AI 怎样做。它包括步骤、语气、判断条件、禁区和验收标准。

References 提供完成任务时应该相信的资料。例如品牌手册、产品价格、以往周报、合同条款和研究数据。这样 AI 不必每次重新询问背景，也不应该随意用互联网内容替代内部标准。

Template 规定结果应该长什么样。它可以是一份 Docs 结构、一套 Slides 母版、一张表格，或者一封已经经过团队认可的客户邮件。

把三者放在一起，Skill 才从「更长的 Prompt」变成一种完整的可复用能力。虽然设置迭代和调整会费些力，但一旦设置成熟，后续就能大幅提高生产力。

我能立刻想到的场景

报告汇总

把本周会议记录、项目文档和任务更新作为 References，要求 AI 固定输出「完成事项、延期、风险、计划」，并给每条结论保留来源链接。

只需要调用 Skill，不必重新解释格式和汇报口径。

如果大量文档表格和邮件甚至日历事项都在Google Workspace 生态里的话，这种报告汇总简直是杀手级别的场景。这也是 Notion 费了那么大力气，收购了一堆办公应用却很难做到的事情。

提案

前面我举的那个例子就是提案，把品牌规范、标准服务范围、成功案例和 Slides 模板组合起来。AI 根据客户邮件生成第一版提案，但特殊的价格和承诺只能来自额外的信息，需要人工介入和调整。

肯定减少了大量复制粘贴，当然销售与法务检查还是必须的。

客户回复

这个也很实用，规定语气、响应时限、可承诺范围和升级条件。普通咨询生成草稿，涉及退款、法律或安全问题时只做分类并转交人工。

感觉重点是让AI 写得礼貌并不难，难的是要清楚什么时候不要自做主张回答去转交人工。

研究模板

要求 AI 先区分官方资料、媒体报道和用户反馈；每个关键结论都附来源；事实与推测分开；最后列出仍未验证的问题。

我觉得很有潜力，但需要反复迭代，把一套适合自己的方法逐渐固化为一个模板。尽管 AI 也不能保证研究一定正确，需要自己核对，这仍旧节约了大量的时间。

现在仍然只是趋势的早期阶段

Workspace Studio Skills 目前只向加入 Gemini Beta 的 Workspace 客户开放，能否使用还取决于管理员设置。不同账号和产品里的 Skills 也并不完全相同：Chrome Skills 更像网页上的 Prompt 快捷方式，Workspace Studio Skills 则可以结合团队规则、模板、资料和流程。

这意味着，大多数普通用户现在未必马上用得到完整版本。产品名称和入口也很可能继续变化。

但我感觉趋势已经很清楚。 Claude、Codex、Gemini 和越来越多生产力软件，都在用各自方式保存可复用 Instructions、工具和参考资料。大家使用的格式还没有统一，背后的方向却一致：AI 不再只处理一次对话，而是开始记住「这类工作应该怎样做」。

最后

Google Workspace Studio Skills 将来如果能普及，应该会成为事实标准。微软 Office 系列应该也会跟上，而现在微软那套 Copliot Flow ，Power Automate 什么的，太复杂了， Google 的Skill 就很平易近人，任何人都可以上手设置。

不过我最期待的是，第三方开源本地优先的文档产品可以真正跟上这个潮流，让用户不仅可以享受 AI 便利，也没有锁死在供应商平台上的风险。说到这点，我个人还是强烈建议，手头要有一份最新版的 AI Skill 提示词，和相关资料副本（比如：模板文档），这才能方便切换到其它 AI 应用上。而不是偷懒把一切都交给一个供应商或者一个应用。

Apple Notes 本来就该是这个样子，Notomo 给它装上了一个现代笔记的扩展

Wed, 02 Sep 2026 10:02:39 +0800

很多人折腾完一圈笔记工具之后，最后还是会回到 Apple Notes。

原因也挺简单。Apple Notes 已经出厂装在每一台 Mac、iPhone 和 iPad 里，打开就能记录，扫描、手写、附件、共享一应俱全，而且 iCloud 同步也很自然，还是免费的。

对于大多数人来说，这些基础体验已经比许多付费订阅的云笔记好用得多，虽然它依旧是一个相对封闭的系统。

但 Apple Notes 的问题也很明显。

它明明拥有几乎最好的系统入口，却一直缺少一些现代笔记工具早就应该具备的能力，比如 Markdown 快捷输入、命令面板、模板、快速跳转，以及可以重复使用的 AI 工作流，也就是类似 Skill、Artifact 这样的机制。

这也给了 Bear 这类笔记工具崛起的空间。它们绕开 Apple 自带的笔记系统，索性自建一整套编辑和数据机制，因此可以更自由地加入各种功能和体验上的改进，虽然很多时候，它们本身依旧是另一个封闭系统。

最近出现了一款比较新的小工具，Notomo，选择了一条很聪明的路线。

它不再重新做一个笔记 App，也不要求用户迁移资料，而是直接给 Mac 上的 Apple Notes 装了一个「扩展程序」。

Notomo 是怎么做的？

Notomo 官方把自己称为 Apple Notes 的 companion。

安装之后，我们写笔记的地方依然是 Apple Notes，资料仍然保存在原来的账户里。Notomo 不会建立另一套数据库，也不要求迁移旧笔记。

它借助 macOS 的辅助功能权限和 Apple Events，判断当前打开的是哪篇笔记、光标在哪里、选中了哪段文字，然后把自己的工具栏、命令面板和 AI 助手放在 Apple Notes 旁边。

操作结束之后，格式和文字依然写回原来的笔记。

我以前介绍过另一款工具 ProNote，走的也是类似的路线。

这种感觉很像浏览器扩展，只不过这次被扩展的是一个原本没有插件系统的 Mac 原生 App。

它最大的好处，是几乎没有迁移成本。

即使以后不再使用 Notomo，原来的笔记也不会消失，Apple Notes 原本的同步、协作和移动端体验也都会保留下来。

Apple Notes 本来就应该是这个样子

Notomo 首先补上的，是类似 Markdown 的快捷输入体验。

在一行开头输入 #、##、>、[] 或代码块标记，它会自动将这些内容转换成 Apple Notes 原生的标题、引用、待办和代码块格式。

需要注意的是，Notomo 并没有把 Apple Notes 变成真正的 Markdown 编辑器。

最后保存下来的，仍然是 Apple Notes 原生的富文本格式。

从 macOS Tahoe 26 开始，Apple Notes 已经可以导入和导出 Markdown，但那个功能主要解决的是文件交换问题。Notomo 解决的，则是写作过程中直接使用 Markdown 语法输入的体验。

除此之外，它还加入了斜杠命令、行内工具栏、Quick Open 和命令面板。

输入 /，可以插入格式、日期、时间、模板，或者调用 AI。
按下 ⌘O，可以快速搜索笔记和文件夹。
命令面板则可以集中处理复制链接、复制为 Markdown、导出等操作。

模板的实现方式也很自然。

用户只需要在 Apple Notes 中建立一个顶层的 Templates 文件夹，其中每一篇普通笔记都可以成为一个模板，之后再通过斜杠命令插入即可。

这些功能单独来看都不算新鲜。

但把它们放回 Apple Notes 之后，会产生一种很强烈的感觉：

Apple Notes 本来就应该允许用户只靠键盘完成格式调整，通过统一的 Slash 入口调用命令，并且让常用模板可以被反复使用。

这些能力如今在不少付费订阅的笔记软件里，早就已经司空见惯。

我甚至觉得，Apple 要不干脆把 Bear 收购算了，说不定真能大幅改善 Apple Notes 的体验。

在这之前，Notomo 和我之前介绍过的 ProNote，都会有继续存在的意义。

Obsidian 已经定义了现代笔记工具的部分标准

为什么我们会觉得这些功能已经理所当然？

很大程度上，是因为 Obsidian（下图为 Obsidian 的Command Palettee）、Notion、Craft、Bear 这些现代笔记工具，已经改变了用户对于「笔记软件应该是什么样」的预期。

比如 Obsidian，它不只是普及了 Markdown 和双向链接，也让很多人习惯了一套新的操作逻辑。

命令面板负责快速调用功能，模板负责复用结构，插件负责扩展能力，普通文本和链接，则让内容可以继续被其他工具处理。

现在回头来看，一款现代笔记工具是否好用，早就已经不只取决于能不能输入文字、插入图片和建立文件夹。

我们还会期待键盘优先的操作方式、统一的搜索和命令入口、可以复用的模板，以及让 AI 和自动化工具参与工作流的能力。

Apple Notes 在同步、扫描、手写、分享和系统集成方面一直很强，但在「可扩展」这件事情上却始终非常保守。

它没有 Obsidian 那样的插件生态，也很难让用户按照自己的习惯重新组织操作。

Notomo 做的事情，其实就是把现代笔记工具已经形成的一部分标准，重新移植回 Apple Notes。

Skills 让普通笔记也可以执行 AI 操作

Notomo 中比较符合现在 AI 使用习惯的一项功能，是 Skills。

用户可以在 Apple Notes 里建立一个顶层的 Skills 文件夹，每一篇普通笔记都可以保存一套指令。

例如：

检查语法和拼写
提取会议中的任务
总结文章
按照固定的语气改写内容
根据预设结构整理笔记

使用 AI 助手时，可以用 @ 引用当前笔记、当前选区或者某个 Skill，然后交给自己选择的模型处理。

因为这些 Skills 本身就保存在 Apple Notes 里，所以它们可以像普通笔记一样编辑和同步，不需要额外维护一套 Prompt Library。

这件事其实很有意思。

过去我们经常把 Prompt 当成一次性的输入内容，但随着 AI 更深入地进入日常工作流，这些 Prompt 越来越像模板、宏或者自动化指令。

把它们当成普通笔记保存，反而是一种非常容易理解的方式。

Notomo 还可以把这些 Skills 带到 Apple Notes 之外。

例如，在 Mail、Safari 或其他支持文本输入的应用中选中文字，然后运行来自 Apple Notes「Skills」文件夹里的 Skill，最后选择「替换选区」或者「复制处理结果」。

Notomo 提供了全局快捷键 ⌥⌘P，也提供了 PopClip 扩展作为入口。

另外一个我比较喜欢的地方，是 Notomo 自己并不销售 AI Credits。

用户可以连接自己的账户或者 API Key。不过这里也需要区分一下，BYOK 并不等于本地 AI。主动提交给 AI 的内容，依然会发送给你所选择的模型提供商。

这种「扩展」方式也有明显代价

Notomo 当然远非完美。

我个人其实很喜欢它的设计思路，但对于这种依赖非官方机制实现的「扩展」，还是会心存一些隔阂。

第一，它依赖辅助功能权限、Apple Events、活动窗口、光标和选区。

从官方更新记录来看，Notomo 一直在修复窗口跟踪、快捷键、输入法、焦点恢复和 AI 回写相关的问题。

暂且不论其中可能存在的隐私风险，单是 macOS 或 Apple Notes 的一次更新，就有可能让其中某些操作暂时失灵。

这种问题不是 Notomo 独有，只要工具建立在另一个没有正式插件机制的 App 之上，就很难完全避免。

第二，增强功能只存在于 Mac。

笔记和模板当然可以通过 iCloud 同步到 iPhone 和 iPad，但 Markdown 快捷输入、命令面板和 Notomo AI 这些增强能力，并不会一起同步过去。

所以从跨设备体验来看，它依然是不完整的。

第三，底层数据依旧属于 Apple Notes。

Notomo 可以导出 Markdown，却没有把整个资料库变成一组用户可以直接管理的 .md 文件。

如果你重视 File over App、Git 版本管理，或者希望 AI Agent 能够直接读写本地资料库，那么 Obsidian 这类真正基于本地文件的工具，依然更加合适。

最后

Apple 的思路一直很有意思。

它经常会先观察第三方 App 对系统原生 App 做了哪些补强，等某种交互方式被验证之后，再把其中的一部分重新做成原生功能。

所以说不定某一天，Notomo 现在这些「小心思」，真的会变成 Apple Notes 的原生能力。毕竟 Apple Notes 已经有非常好的同步、移动端体验和系统入口。它缺少的只是让用户自己定义「怎么写、怎么调用、怎么复用、怎么自动化」。

Notomo 把这一层实现了出来。

如果大家本来就喜欢把 Apple Notes 作为整个笔记体系的核心，又觉得它的操作方式这些年始终有点跟不上现代笔记工具，那么 Notomo 值得尝试一下，也可以试一下 ProNote（以前介绍的，类似机制）。

但如果大家真正看重的是开放文件格式、长期可迁移性、Git、自动化，以及未来让 AI Agent 直接处理整个知识库，那么与其继续给 Apple Notes 加扩展，可能还是直接考虑 Obsidian 之类的第三方工具更加合适。

收件箱不是仓库：从 Obsidian 到 Todoist 的效率系统反思

Sun, 30 Aug 2026 10:02:11 +0800

最近读到 Stéphane Sulikowski 的一篇文章《The Inbox Is the Most Dangerous Folder in My Obsidian Vault》，文章开篇就打动了我：

「我的收件箱之所以有用，恰恰在于它不应该是一个让人感到舒服的地方。如果一条记录在里面停留太久，那一定是哪里出了问题。」

原作者讨论的是他的知识管理工具 Obsidian，而作为一个深度依赖 Todoist 多年的任务管理用户，我却在屏幕前停顿了很久。

因为在很长一段时间里，我的 Todoist 收件箱（Inbox）正是那个看起来最井井有条、实则最危险的「数字沼泽」。

无论是在笔记软件里收集文章和灵感，还是在待办工具里捕捉任务和念头，我们几乎都在重复同一种自欺欺人的游戏：

把「收集」当成了「行动」，把「推迟判断」当成了「掌控生活」。

我称之为「战术性拖延」，这个说法也许有些夸张，却准确描述了我的真实状态。

收集的幻觉，廉价而即时的多巴胺奖励

现在的生产力工具，把「捕捉（Capture）」做得太丝滑了。

在 Mac 上按下一个全局快捷键，或者在手机锁屏小部件上轻轻一点，Todoist 的快速添加窗口就会弹出来。

在电梯里、会议间隙，或者浏览网页的某个瞬间，任何一个闪过的念头都能被迅速捕获：

看一看那个新的开源项目
重构个人知识库的工作流程
读完那篇深度长文
尝试一下某某产品

敲下回车，弹窗消失，任务落入 Inbox。

在那个瞬间，大脑仿佛获得了一次即时的多巴胺奖励，让我产生一种「这件事已经被妥善处理了」的释怀感和掌控感。

我会觉得自己雷厉风行、高效且自律，仿佛只要记下来，这件事就已经完成了一半。

但正如 Stéphane 在文章中犀利指出的：

「记录不是免费的，它只是被推迟的判断（Deferred Judgment）。」

每一次轻率的收集，本质上都是在给「未来的自己」派发一张无薪加班的工单。

未来的你需要重新查看这条记录，回忆当时的上下文，搞清楚那句话究竟是什么意思，判断它是否值得执行，拆解下一步行动，再为它分配时间。或者，在拖延了三个月之后，羞愧地承认，它其实根本没有那么重要。

收集并没有解决任何问题，它只是把认知负担延期交付了。

数字垃圾场与认知负债

如果一个系统的流入速度远大于流出速度，那么崩溃只是时间问题。

我的 Todoist 收件箱曾经堆积了大量待办事项：

有些任务是半年前随手记下的灵光一闪，现在看起来如同天书，完全想不起当时的上下文；
有些是某篇高赞文章的链接，当时觉得自己「非读不可」，现在却连点开的欲望都没有；
还有大量模糊的目标，准确地说，它们既没有被分解，我也懒得分解。

收件箱之所以是一个「礼貌的数字垃圾场」，是因为里面的每一条记录看起来都有价值，也都有被保留的理由，但它们并没有真正推动任何行动。

当收件箱膨胀到这个程度时，系统的性质就变了。

原本希望它成为一个「第二大脑」，我其实很讨厌这种说法，现在更讨厌了，结果它却变成了「大脑以外的负担」。

每天打开 Todoist，光是看到收件箱，或者「已逾期（Overdue）」旁边那个两位数的红色角标，心里就会升起一股隐隐的内疚和压迫感。

这些堆积在 Inbox 里的项目，都是一笔笔微型负债（Tiny Liabilities）。

它们污染视线，稀释我们对真正重要事情的注意力，把原本应该用于执行任务的精力，白白消耗在「我要不要做这个」和「这个应该放在哪里」的反复纠结中。

收件箱只是过道

痛定思痛之后，我重新审视了收件箱的定位。

原文作者 Stéphane 提到了一个非常形象的比喻：

收件箱就像门厅玄关处放钥匙的托盘，是进门之后做出决策之前的临时存放处。它不是起居室，更不是储藏室。

东西可以穿过收件箱，但不应该住在收件箱里。

在 Todoist 中，为了不让 Inbox 重新沦为泥潭，我给自己确立了一套严格的处理准则。

清空收件箱时，每条任务都必须接受以下四种「判决」之一。

1. 删除（Drop）

这是最重要、也最容易被低估的动作。

重新审视那条灵光一现，问问自己：

「如果我现在删掉它，我的生活会受到任何影响吗？」

如果答案是否定的，或者那个瞬间的热情已经消退，就立刻按下快捷键，把它删掉。

承认一个念头不值得执行，不仅不是失败，反而是对注意力最高级的保护。

我们不需要为每一个转瞬即逝的想法负责，也没有义务把每一种可能性都变成现实。

2. 立即执行（Do）

如果一条待办事项只需要两分钟，比如回复一封邮件、支付一笔账单、确认一条快递信息，就不要再给它分配项目、标签和日期。

立刻把它做完，然后勾选完成。

不要让一个原本只需要两分钟的动作，因为复杂的任务管理流程，变成一项需要反复查看和重新判断的心理负担。

3. 明确并归类（Clarify & Move）

如果是一件必须完成的事情，那么收件箱绝对不能成为它的终点。

你不能只在里面留下一条名为「写年度总结」的任务，因为它只是一个模糊的目标，而不是可以立即执行的行动。

你必须把它动词化、具象化，比如：

「列出年度总结中的 3 项核心成果。」

或者：

「围绕 3 项核心成果，拟定年度总结大纲。」

接下来，为它设定截止日期和优先级，再将它移入对应的「工作」项目。

收件箱可以接受粗糙的念头，但一条记录在离开收件箱时，必须已经变成清晰的行动指令。

4. 留待未来（Someday / Maybe）

有些想法并非毫无价值，只是暂时没有优先级。

例如想看的电影、准备阅读的书、值得关注的冷门工具，以及未来也许可以尝试的个人项目。

对于这些「以后有空可以看看，但目前并不重要」的内容，我不会让它们继续留在主视线里，而是将它们移入专门的「未来／也许」项目。

不给日期，不设提醒，也不让它们产生红色角标，确保它们彻底离开日常工作流。

这其实是一种取巧，相当于给 Inbox 再设置一个 Inbox。

但两者之间存在一个重要区别，真正的收件箱要求我及时做出判断，而「未来／也许」列表允许我暂时忘掉那些内容。

即使以后再也没有打开过这个列表，我的生活也不会因此遭受什么损失。

战胜对丢弃的恐惧

很多时候，我们不敢清空收件箱，本质上是因为 FOMO（害怕错过）。

我们害怕删掉那篇想读的文章后，会错过某次关键的认知升级；我们害怕删掉那个模糊的项目想法后，会丢失一个可能改变职业生涯的机会。

我们总觉得：

「万一以后有用呢？」

但事实往往是残酷的。

如果记下后的 48 小时内，都没有重新意识到它的重要性，那么 48 天后，它大概率只会变成一串失去上下文的字符。

一个好的任务系统，衡量标准从来不是你记录了多少宏伟的计划，而是它能否在每天早晨，为你提供一份极度清晰、几乎不会带来心理阻力的执行清单。

每一次果断删除，都是在为真正重要的任务腾出带宽。

你所放弃的，不是可能性，而是那些关于未来的不切实际的幻想；你所保留的，才是自己真正能够支配的现实生活。

最后

回到最初的那句话：

「收件箱不应该是一个让人感到舒服的地方。」

如果你的 Todoist 收件箱让你感到舒适、安逸，甚至成了一个可以随时往里丢东西的垃圾场，那么它就已经变成了整个系统里最危险的角落。

我依然离不开 Todoist 的快速收集功能。

在灵感出现或突发事务到来时，我仍然会毫不犹豫地把它们放进 Inbox。因为收件箱真正的价值，在于保护当下的专注，避免琐事打断正在进行的心流。

但我也会时刻提醒自己：

快速收集只会产生一笔注意力负债，并不会自动转化为认知的资产。

Omarchy 为什么深得我心？用「主厨精选」对抗 Linux 的「选择过多」

Thu, 27 Aug 2026 20:02:34 +0800

我一直认为，「有选择」是一件好事，但极端的「选择过多」却可能成为一场灾难。Linux 就存在这个问题。

很多人以为，Linux 最大的使用门槛是「命令行」这种工作方式。诚然，这是一个问题，不过如今 Linux 上也已经有了许多设计精美的 GUI 应用，用户也并不是非得接触命令行。

真正的问题在于「碎片化」，或者换句话说，「选择过多」。

Linux 有无数个发行版、不同的软件生态与技术分支、微妙的兼容性问题，以及截然不同的界面风格和使用习惯。对于资深 Linux 用户来说，这些都不是问题。因为看透这些差异之后就会发现，它们背后都是相同的 Linux 内核。至于那些纷杂的界面与操作，不过是外在表象而已，颇有几分佛法的意味。

但对于初学者、日常用户，乃至拥有其他操作系统使用经验的开发者而言，Linux 仍然是一个不太容易接近的操作系统。

真正开始使用 Linux 后，人们会发现，更常见的障碍其实是：几乎每一件事，都有太多种做法。 而网上的不同资料，往往只适用于各自特定的环境。

先不说发行版之间的差别，桌面环境应该选择 GNOME 还是 KDE？要不要使用 Hyprland？状态栏用什么？启动器、终端、文件管理器、剪贴板和截图工具又该怎么选？

每个工具背后还有各自的主题、插件、快捷键与配置选项，有时甚至需要修改千奇百怪的配置文件。

可以说，Linux 给了用户非常大的自由，「拥有选择权」的确是一种自由。不过，用户的注意力也可能被过多的「选择」淹没。

Omarchy 带来了什么？

如果理解日本料理中的 Omakase，也就是所谓的「主厨推荐」，我觉得就不难理解 Omarchy。

Omarchy 是一个预先搭配好各种应用并完成环境配置、力求做到「开箱即用」的操作系统。

其实，Windows 和 macOS 在某种程度上都是「开箱即用」的操作系统。它们各自拥有一套相对稳定的界面与设计风格，甚至内置了一些基本应用。

总体而言，macOS 在整体搭配与一致性方面做得更好，也更受用户喜爱。相比之下，Windows 的整体搭配显得随意一些，用户通常仍然需要自行安装应用、调整设置并补充一些功能。

Omarchy 也试图沿着这个方向发展。它提供了一套预先精选的方案，让用户不必再为琐碎的配置费心。

当然，「主厨推荐」本身也很有讲究，体现的是选择者的品味。

Omarchy 官方甚至很直白地表示，它不是简单地预装一堆软件，而是「everything I use」，基本上就是「主厨」本人每天使用的那套电脑环境。

这就要说到 Omarchy 背后的「主厨」，DHH，也就是 David Heinemeier Hansson。

他是 Basecamp 和 HEY 背后的公司 37signals 的共同所有者和 CTO，也是 Ruby on Rails 的创造者。后来，他还开发了 Hotwire、Kamal 等一系列工具。

2024 年，他开始公开推动 37signals 的开发团队从长期使用的 Mac 转向 Linux。随后，他推出了运行在 Ubuntu 上的 Omakub，并进一步发展出基于 Arch Linux 和 Hyprland 的 Omarchy。

2026 年 8 月，Omarchy 4，也就是 Quattro，正式发布。它一如既往地替用户做好了大部分决定。

的确，用户不应该被迫反复处理那些已经可以由别人代为做好的决定。

为什么我会欣赏 Omarchy

简单来说，它非常符合我个人的使用习惯和理念。

根据我的实际体验，Omarchy 提供的许多「预设」，本来就有不少是我正在使用并积极实践的方案。

例如，Hyprland 和 Quickshell 组成的桌面与窗口管理环境非常高效。我甚至一直在其他操作系统中寻找类似的替代方案。

无论是窗口平铺还是桌面切换，体验都堪称一流。它没有过多花哨的装饰动画，一切都很流畅。这才是真正的生产力系统。

最新的 Quattro 更进一步。以前分散在 Waybar、Walker、Mako、SwayOSD、hyprlock 等不同组件中的状态栏、启动器、通知、锁屏和控制面板，现在被整合进一个基于 Quickshell 的统一桌面环境。

Omarchy 还内置了许多应用与功能，都很符合「生产力优先」的取向。例如我喜欢的 Obsidian、LocalSend 和 Chromium，以及内置的剪贴板管理功能。

此外，系统还提供了许多候选安装项，用户可以通过安装菜单快速获取。

整个系统主要围绕键盘操作展开。重视生产力的用户，应该会喜欢这种以键盘为中心的操作方式。

按下 Super + Space 就能打开统一菜单，其作用相当于 Windows 的「开始」菜单。我真希望 Windows 能在这方面好好学一下。

打开菜单后，用户可以直接用键盘进行筛选，并执行相应的项目。干净利落！

一个由 AI Agent 引导的操作系统？

我要单独谈谈这件事。

发展到目前这个版本，Omarchy 已经开始把 AI Agent 当成系统中的「一等公民」。

Claude Code、Codex、OpenCode、Gemini CLI 等主流 Agent 都可以直接调用。用户还可以配置默认 Agent 和模型提供商，通过快捷键随时启动，甚至可以让 Agent 带着具体任务直接进入工作环境。

有意思的是，AI 与操作系统的集成并不只是为了陪我们聊天，而是为了直接解决问题。

Omarchy 提供了专门的 Agent Skill，让 Agent 能够理解这套系统的结构。它可以修改 Hyprland 配置、调整桌面组件、制作主题，甚至参与排查系统崩溃等问题。

例如，我想为笔记本触摸板配置一套通过滑动手势切换虚拟桌面的操作方式，只要把意图告诉 Agent 即可。我使用的是 OpenCode，连接的模型是 GPT 5.6 Luna。很快就搞定了。

我知道，如果没有 AI 辅助，我肯定得上网查询应该修改哪个配置文件、具体改动哪几行，然后再亲自打开文件进行调整。只是想想这些，就觉得麻烦。

现在，我只要说一句话就能完成。

我不是资深 Linux 用户，记不住那么多操作与配置。我也不认为自己有必要记住这些细节，只要让知道如何处理的人或程序去做就可以了。

当然，这种自然语言式的命令行交互可能有些激进。因此，在执行关键操作前，大家仍然应该做好备份与回滚的准备。

Omarchy 目前还远远称不上成熟的「Agentic OS」，但它已经相当具体地展示了一种可能性：未来操作系统的易用性，未必来自把底层的一切全部隐藏起来，也可能来自让 AI 帮助普通用户驾驭一个原本完全开放的复杂系统。

实际使用中遇到的一些问题

虽然我很喜欢 Omarchy 的理念，但不得不说，我在实际使用中还是遇到了一些恼人的问题。

我给两台旧笔记本电脑安装了 Omarchy，其中一台遇到了比较严重的兼容性问题：

无线网卡无法正常识别。
从休眠状态恢复时，系统偶尔会卡死，只能强制关机。
一些应用在启动后会崩溃。
连接外部显示器时，有时会出现画面闪烁或跳动。

安装 Omarchy 时，需要通过 USB 引导启动，并在 BIOS 中关闭 Secure Boot。

面对不同型号的笔记本电脑，我一开始甚至不知道该如何在开机时进入 BIOS。对新手来说，可能第一步就会被卡住。

这也解释了为什么 Windows 和 macOS 更容易被普通用户接受。

Windows 背后有长期发展形成的 PC 兼容标准和成熟机制。各家供应商也会按照相应标准生产硬件，并由操作系统进行统一适配。

Windows 在早期同样存在大量兼容性问题，只是这些问题后来逐步得到了改善。

至于 macOS，其软硬件均由苹果统一掌控，就连 CPU 芯片也由苹果自行设计，因此不必适配数量庞大的第三方硬件组合。

而 Omarchy 本质上仍然是 Linux，需要面对数量庞大且高度碎片化的硬件设备。理论上，Linux 可能遇到的兼容性问题，它同样都可能遇到。

除非 Omarchy 将来推出自己的计算机硬件，以保证经过「主厨挑选」的软硬件能够严格兼容。

说不定以后真的会有。我觉得，如果 Omarchy 真能推出自己的硬件，其吸引力或许会超过基于 ChromeOS 的 Chromebook。

最后

Omarchy 虽然是「主厨精选」，但也保留了让用户自己动手的权利。

传统 Linux 经常先把所有选择摆出来，让用户自行组装。Omarchy 则让用户先沿着一条主路前进，等真正遇到不合适的地方时再作调整。

不让用户把过多注意力投入「折腾」，本身就很有价值。

有时，工具越灵活，我们就越容易把时间花在「设计、配置一套理想工作流」上，而不是去完成真正重要的工作。

安装一堆 Obsidian 插件，不等于留下了更多有价值的笔记；做出一个漂亮的 Notion 仪表盘，不等于项目推进得更快；把 Raycast 配置成瑞士军刀，也不代表每天真的会用到那些命令。

我越来越觉得，生产力更依赖几条稳定、重复，并且几乎不需要思考的路径。

不必过度关注别人所谓的「终极生产力系统」或「知识库体系」。那些东西很可能成为「注意力杀手」，把我们的注意力引向枝微末节，反而让我们忘记真正的目的。

一个固定的收件箱、一套够用的模板、几个已经形成肌肉记忆的快捷键，可能比一个拥有无限可能与无限选择的系统更有效。

在我看来，Omarchy 正是这种理念的一次优秀实践。

Google Sheets 恐怕不是简单的「在线表格」了：Smart Fill、AI 公式函数，以及最新的 Sheets Canvas

Sun, 23 Aug 2026 15:02:17 +0800

我对 Google Sheets 最早的印象是「在线版 Excel」。随着 Excel 逐渐显得原地踏步，后来我发现 Sheets 甚至可以对标早期的 Airtable，比如生成表单（Forms）等功能。

再后来，我发现 Google 作为主流的 AI 应用玩家之一，非常擅长把 AI 落地到具体的工作场景中。像 Gmail、Docs、Sheets 都是极佳的切入点。目前，放眼整个办公 SaaS 领域，除了微软，其他竞争者差距依然明显。偶尔有些挑战者，像 Notion 也在跃跃欲试；又比如 Grammarly 收购了 Superhuman 和 Coda 试图打造 AI 集成办公环境，但手上的底牌终究不如 Google 雄厚。

我们就来看看，在 AI 加持下的 Sheets 正在走向何方。

过去几年，只要哪个产品宣布接入 AI，大家的第一反应通常是：它是不是又在右边塞了一个聊天框？Google 也未能免俗，早早给 Sheets 安排了一个 Gemini 侧边栏（微软则是 Copilot）。

恕我直言，如果只是生硬地塞进一个聊天框，难免有偷懒之嫌。只有深度融入业务流程的 AI，才是优秀的集成方案。这也是为什么 Google Sheets 最近的一系列变化，非常值得单独聊聊。

现在的 Sheets，既有 Smart Fill 这类自动发现规律的传统智能特性，也有可以直接写进单元格的 =AI() 函数；既能通过 Gemini 侧边栏用自然语言创建、修改和分析整张表格，最近还在小范围测试 Sheets Canvas，让同一份表格数据直接生成看板（Kanban）、仪表盘（Dashboard）、日历（Calendar）以及其他具备交互能力的小应用。

如果把这些更新串联起来看，Google 显然不仅是给 Sheets 简单粗暴地加几个 AI 按钮而已。随着 Sheets Canvas 的亮相，表格甚至不再只是一个单纯存放数据、编写公式的地方。它正在演变成一个以数据为底座、以自然语言为交互、能随需即时生成界面的轻量工作台。

这究竟是如何一步步实现的？

AI 函数

真正让生成式 AI 进入表格细胞（单元格）内部的，是 =AI()（亦可写作 =Gemini()）。

早在生成式 AI 刚落地时，这曾是一个非常抓人眼球的功能：用自然语言描述需求，让系统自动执行。当时甚至有创业团队仅凭这一特性就大做文章，扬言要颠覆在线表格。如今回看，这不过是在线表格的一个基础 AI 补丁罢了；如果仅以此作为「颠覆性产品」，未免有些幼稚。

例如，在一张客户反馈表里，A2 单元格保存了用户留言，我们可以在 B2 输入：

=AI("把这条反馈概括成不超过 20 个汉字", A2)

也可以继续增加几列：

=AI("判断情绪，只返回正面、中性或负面", A2)

AI 函数不仅能生成文本、总结内容、归类信息、判断情绪，还能借助 Google Search 补充实时公开信息。比方说，在某一列写上人名，AI 就可以在相邻列搜索并自动生成人物的背景概要。

Spreadsheet 原本是一个严格的确定性计算环境。而 AI 函数将自然语言封装成了大家所熟悉的单元格引用方式，上下文引用直接对应其他单元格，逻辑非常清晰直观。

Fill with Gemini

AI 函数只是第一步。很多人第一次看到 Fill with Gemini 时，会以为 Google 又推出了一套全新的表格 AI。其实，它更像是 Smart Fill（智能填充） 与 AI 函数 的结合体。

Fill with Gemini 主要有两种使用方式：

拖拽填充：如果某一列已经填好了至少一个单元格，我们可以从全新的拖拽手柄向下填充。Gemini 会结合整表上下文和已有结果，为后续每一行推导并生成内容。
选区生成：选中一片空白区域，直接描述希望填入什么内容。可以交由 AI 自行判断规律，也可以输入一段明确的 Prompt。

这两种方式切中并解决了 AI 函数最大的门槛：绝大多数普通用户根本不想学习新语法，甚至压根不想去理解「公式」这个概念。

用户最熟悉、最肌肉记忆的操作，就是选中、拖拽和填充。Google 巧妙地把生成式 AI 藏进了这些既有动作中。我们不再需要费心去记 =AI()，也不必繁琐地复制函数，只需像过去一样随手一拖，Sheets 就从「机械复制相同值/简单序列递增」升级为「理解这一列的任务目标，并为每一行生成贴切的结果」。

它极其适合处理那些 大量重复、以文本为主、且每一行内容均有细微差异 的任务。

AI 函数：显式声明，适合在单元格中精确定义任务与引用范围；
Fill with Gemini：隐式操作，把 AI 函数封装成更符合直觉的拖拽与选区填充。

越依赖复杂语义判定的任务，越适合写 AI 函数；而追求高效率的批量处理，Fill with Gemini 则更直接快捷。

Gemini 对话

AI 对话框终究也是必不可少的。

如果说 AI 函数是在微观的单元格里派发具体任务，那么右侧的 Gemini 对话面板处理的就是宏观的整张表格。

早期的侧边栏更像一个「被动回答者」。我们可以向它提问：“这张表体现了什么趋势？”“业绩最好的是哪个部门、发生在什么时候？”而现在，它越来越像一个坐在你身边的「全能操作员」了。

目前，Gemini 已经能够直接建表、写公式、分析数据、生成可视化图表，还能主动添加条件格式、创建数据透视表、执行排序与筛选、查找替换文本，以及进行插入、编辑、删除和冻结行列等操作。

在 AI Agent 浪潮下，它甚至开始接管跨场景的复合任务。例如：用户只需用自然语言提出诉求，Gemini 可以从 Gmail、Google Drive、Chat 乃至互联网中检索相关信息，先梳理出一份执行计划交由用户确认，随后全自动建立起包含格式、公式、透视表和图表的完整报表。

短期内，我更倾向于将它定位为一个手脚麻利的初级操作员，而非资深的数据架构专家。但随着时间推移，它大概率会愈发成熟，甚至能够自主设计并操作完整的业务流。

Sheets Canvas

前面提到的功能，无论体验多么智能，用户最终面对的依旧是一张传统的电子表格（Spreadsheet）。

而 Sheets Canvas 这个目前仅在小范围测试的功能，才真正称得上是令人眼前一亮的「重头戏」。

Google 在公布 Sheets Canvas 时，将其定义为建立在表格数据之上的**「交互式小程序」（interactive mini-app）**。

现在，AI 可以根据一个 Sheet 工作表和一句自然语言指令，快速生成 Dashboard（仪表盘）、Heat map（热力图）、Kanban（看板）、Gallery（画廊）、Calendar（日历）乃至更自由的自定义交互布局。

虽然我目前尚未拿到该功能的内测资格，未能亲自实操，但仅从公开展示的能力来看，就已经足够震撼。

简单来说：Canvas 充当了读写交互界面，而底层 Sheets 则是数据源。

我们在 Kanban 里拖拽移动一张任务卡，原表中的状态字段会同步变更；在日历里修改日期、新增记录或删除项目，改动会直接写回底层表格。反之，一旦原始数据发生变动，Canvas 界面也会即时响应刷新。

假设一个小团队使用 Sheets 管理内容排期，表内包含选题、负责人、发布渠道、状态、发布日期和优先级。过去，团队可能会为了看板特意搬去 Trello，为了日历视图搬去 Notion，为了看数据汇总又得接入第三方 BI。而现在，只需对 Gemini 提一条要求：

“根据 Status 列建立一个内容看板，卡片显示标题、负责人、渠道、发布日期和优先级；逾期项目用醒目颜色标出，并允许编辑者拖动卡片改变状态。”

Gemini 便会在原始数据之上直接搭建起一层全新的可视化操作层。数据依然安稳地躺在 Sheet 表格里，但并非所有团队成员都需要面对密密麻麻的行列，业务人员只需在直观的看板上查看进度、拖拽更新状态即可。

这一步标志着 Sheets 开始跨越传统 Spreadsheet 的边界，蜕变为一个极轻量化的无代码（No-Code）平台，让懂业务、会用表格的人，能够零代码生成供整个团队协同的微型业务应用。

未来图景的一瞥与边界

与当下热门的 Vibe Coding 类似，「快速生成一个 Demo」和「长期维护一套生产系统」有着本质区别。

一套严谨的企业级业务系统，需要稳定的字段设计、主键约束、关系引用、细粒度权限管控、自动化流程、操作审计、测试及版本发布机制。Sheets Canvas 目前更擅长基于一张规整的明细表，快速搭建一个好用的操作界面，其本质仍是轻量级应用。至于企业的关键核心业务流程，现阶段显然还不适合直接托管于其上。

展望未来，我毫不怀疑 AI 具备整合复杂数据、构建复杂流程并提升系统可维护性的潜力。但这仍需要时间演进。

当看到 AI 函数、Gemini 自动化操作以及 Sheets Canvas 展现出的能力时，很多人容易产生一种错觉：以后我们是不是完全不需要学公式和表格操作了？

这恰如大家在讨论 Vibe Coding 时的疑问：以后是不是完全不需要学编程了？

答案是否定的。只要一个任务存在明确的业务逻辑与计算规则，就应该优先交由普通公式或确定性机制去处理。
例如：税额计算、日期差、库存结余、主键查找匹配等。这些计算必须保证确定性与绝对准确，绝不能因为模型重新生成一次就得出不一样的结果。

AI 目前更适合处理难以用规则穷尽、但人类凭语境能轻松判断的任务；而对于严密的流程设计与确定性计算，AI 仍不适合完全放手让其自主决策。

因此，更合理的落地姿态并非让 AI 大包大揽接管整张表，而是将确定性能力与生成式能力进行分层：

底层：原始数据与核心计算留给传统表格机制（保证数据精准性）；
中层：AI 负责难以规则化的非结构化文本处理，辅助列记录数据来源与人工核验状态；
顶层：Canvas 作为友好的展示与交互界面。

未来，AI 或许会承担起调度和编排确定性函数与 API 的角色，但最终的校验把关与责任归属，依然需要人类来掌控。

结语

据我观察，许多小团队生命周期里的第一个业务系统，往往就是一张本地 Excel 表格或在线 Google Sheets。

客户名单、项目看板、内容排期、库存台账、预算追踪，通常都是从区区几列字段起步的。随着数据膨胀、业务复杂化，团队才不得不逐步迁移至 Airtable、Notion、Trello、AppSheet，乃至定制开发独立的业务系统。

Google Sheets 如今所发力的方向，正是尽可能延缓这种迁移的发生，它把「搭建轻量业务工具」的门槛压到极低，从而让用户与团队能够更长久地留在 Google 的生态体系之中。

【速报】Zotero 10 发布了！老牌的研究工具没有盲目加入AI，而是继续在「读PDF」和「高级搜索」上加强。

Tue, 18 Aug 2026 15:01:59 +0800

2026 年 8 月 17 日，Zotero 10 正式发布。

Zotero 10 最显眼的变化是重构了「高级搜索」，并新增多 Collection 选择；此外还带来了批量编辑与撤销，以及能重排 PDF 版面的 Reading Mode。

这次更新挺有意思的，在多数生产力工具都急着加上 AI 对话框讲故事的时候，Zotero 相当克制。它想解决的像是资料库膨胀之后、资深用户才会真正遇到的那些痛点。

当资料库超过几千篇，「收集」就不再是重点

Zotero 是一个开源工具，本地使用完全免费。如果要用官方的同步存储，超出免费额度（目前 300MB）后需要付费订阅，模式和 Obsidian Sync 接近。

Zotero 最初主要用于学术文献管理，很多人后来会把它当成自己的 PDF 资料库。再后来，论文、行业报告、电子书、网页快照、课程资料，甚至扫描件，都被扔了进去。

浏览器里的 Zotero Connector 很方便，看到一篇资料甚至博客，点一下就保存了；如果拖进一个 PDF，它又会尽量识别标题、作者、DOI 等元数据。

收集太容易，反而会制造另一个问题：资料库开始膨胀。

刚开始只有几十条记录时，Collection 就像整齐的书架。到了几千篇以后，同一篇资料可能同时属于一个项目、一个研究主题和一个客户；有些 PDF 做过批注，有些只看过摘要；还有些是十年前导入的，标题和作者字段早就不统一了。

这时候有些工具就会「自作聪明」地端出 AI 分类、AI 摘要、AI 清洗等功能……但 Zotero 没有跟风，而是转头去加强资料库的基础设施。

更高级的「高级搜索」

Zotero 以前当然也有高级搜索，但更像一个独立的小工具。以前的流程是：打开高级搜索窗口，组合条件，查看结果；要把复杂条件长期保留下来，往往还要做成 Saved Search（保存的检索）。麻烦的是，一些跨层级查询需要串联多个 Saved Search 才能实现。

Zotero 10 把高级搜索放回了主窗口。快速搜索栏旁边现在有一个筛选按钮，点开后，条件会直接出现在条目列表上方。它可以过滤当前的 Library（文库）、Collection 或 Saved Search，结果出来以后，也可以马上选择、编辑和整理。

这个位置上的变化看起来不大，实际影响不小。搜索不再是一个打开、查完、关掉的独立窗口，而成了资料库界面里的常驻过滤层。

如果先在快速搜索栏里输入关键词，再点高级搜索，Zotero 还会自动把现有查询转换成对应条件。高级搜索面板在切换 Collection 时不会消失，相当于终于可以「钉住」一组条件，再去不同的资料范围里反复查看。

而且，搜索条件开始理解 Zotero 的层级关系。

一篇论文是顶层条目，下面可能挂着 PDF 附件、笔记和批注。以前想找「作者是某人，而且其 PDF 里有黄色或红色批注的论文」，得先想清楚自己到底是在搜条目、附件还是批注。Zotero 10 可以先指定结果层级，例如顶层条目或批注，再组合嵌套条件，Zotero 会自动把不同层级的条件映射到目标结果上。

换句话说，我们可以这样找：

作者是某人，并且下面存在黄色或红色批注的论文；
带有「待引用」标签，而且附件正文中出现某个术语的顶层条目；
某几个项目 Collection 中，最近读过、至少有一条笔记的资料；
某位作者名下的所有批注（而不必先找论文，再逐篇展开附件）。

高级搜索还增加了批注颜色、批注类型、笔记数量，以及「为空」「不为空」等条件。对于长期积累的 Library，这些条件不是炫技，而是让过去留下的阅读痕迹重新变得可用。

另外，跨语言、跨排版形式的搜索也很实用：cafe 能匹配 café，纯文本的 H2O 也能匹配带下标排版的 H₂O。

这些功能很专业，门槛也确实不低。对于积累不多、并非专职做研究的用户，可能一时感受不到价值，但这大概也正是 Zotero 长期被当作专业研究工具的原因。

多 Collection 选择，改变的其实是整理思路

Zotero 的 Collection 并不是真正的磁盘文件夹。同一条资料可以同时放进多个 Collection，不会复制出多个条目。这更像播放列表，而不是传统意义上像文件夹目录树那样。

但由于过去一次只能进入一个 Collection（传统意义），很多人还是会下意识地搭出一棵越来越深的目录树：领域下面分项目，项目下面分主题，主题下面再分「已读」和「未读」，层层嵌套，越理越乱。

Zotero 10 终于支持在左侧栏同时选择多个 Collection、Saved Search，甚至多个 Library，并在中间列表里查看合并结果。

例如，我们可以同时选择「AI Agent」「知识管理」和某个正在进行的客户项目，再用顶部的高级搜索面板过滤：附件正文包含 local-first，而且存在黄色批注。以前这种查询往往迫使我们移动条目、临时加标签，或者串联多个 Saved Search；现在不必为了一次查询去重构资料库。

我觉得，这会让 Collection 回到它更适合的位置：用来表达资料属于哪些项目或场景，而不是强迫每篇资料只能住在唯一的抽屉里。有点像「标签」，但我觉得「播放列表」这个比喻更合适。

Reading Mode：把论文重排成能读的样子

除了搜索，这次更新的另一个亮点是 Reading Mode。

Zotero 10 为 PDF 增加了 Reading Mode。它会分析文档结构，把正文重排成单栏、可连续滚动的阅读视图，去掉页眉、页脚和原始分栏，还可以调整字体、字号和行距。碰到无法转换成文本的图片、表格和图形，则保留原始 PDF 的渲染结果，避免内容直接消失。

提取后，我们仍然可以在 Reading Mode 里高亮、加下划线和写笔记，这些批注会同时出现在普通 PDF 视图中；在两个视图之间切换时，阅读位置也会保留。不过区域截图、图片和手写类批注目前仍然只能在 PDF 视图里显示。我觉得，如果能同步呈现在侧边栏，体验会更好。

Read Aloud：略有加强

Read Aloud 是 Zotero 9 加入的朗读功能。Zotero 10 没有停留在增加几个新音色这种层面上，而是改进了朗读背后的文本解析。目前朗读仅在桌面端支持。

过去的 PDF 朗读经常会把页眉、页脚、文内引用、表格单元格、坐标轴和公式全部念出来，双栏或跨页的段落也可能被截断。Zotero 10 的文档分析系统会尽量识别这些结构，跳过文内引用、页眉页脚、表格、图形和公式，让跨栏、跨页的段落能连续读下去，听起来更连贯自然。

朗读时默认按句子高亮，而不是一次亮起整段；也新增了「上一句／下一句」按钮。对于长文档，开始朗读前的等待时间也缩短了。

需要说明的是，不注册账号也能使用朗读，但要用上高质量的 Zotero Voices，必须联网并登录 Zotero 账号；离线时，默认调用操作系统自带的语音。更高质量的语音需要把文本上传到云端生成。因此，如果材料涉及未发表成果、商业机密或个人隐私，不建议使用在线音色。

Zotero 10 没有 AI？

Zotero 生态里其实并不缺 AI。像我这样极力推崇「工具链」思维的人，第一反应就是：根本不需要 Zotero 自己集成 AI，只要让 AI 能访问 Zotero 就够了。

Zotero 确实有开放 API，也有插件机制，再配合 MCP，完全可以把 AI 能力延伸到 Zotero 内部。从这个角度看，Zotero 10 的高级搜索、全文索引、Reading Mode 和文档分析系统，其实也在为未来的 AI 工作流打地基。只不过它没有急着把最终界面做成一个对话框，这点我很欣赏。

最后

Zotero 10 并不是一次让人眼花缭乱的更新。

Zotero 本来就不是那种被吹得天花乱坠的「下一代 AI 研究工具」，也不是风投眼中颠覆性的魔法产品，更不是社交平台上被反复转发的「效率图腾」。

Zotero 一直就是一个看似枯燥、实则强大的纯粹工具。对一个积累了几千篇资料的研究者来说，这次更新带来的是真正的效率提升。

当然，研究工具的下一步肯定会有 AI 接入。我们会让 AI 帮忙找论文、比较观点、解释公式、整理批注，甚至参与部分创作。但我觉得这更像一个分工问题：不必把所有能力都塞进一个「大而全」的应用里，各司其职、让用户自由组合，才是更好的答案。

Reflect Open：当云笔记主动拆掉自己的数据围墙，回到「本地优先」

Sun, 16 Aug 2026 20:01:58 +0800

我之前的文章介绍了很多 PKM 工具，其中一大类就是「云笔记」。但我一直推崇「本地优先」，希望大家在条件许可的情况下，将重要的笔记和文档存储在本地，或自己信任的云存储中，不要被 App 自带的云服务「绑架」。

从商业角度看，用户将越来越多的笔记存入 App 的云端，由厂商负责保存、同步和搜索。数据越积越多，迁移成本也越来越高。只要服务保持稳定，用户就会一直订阅下去，难以脱身。

所以，2026 年 7 月，Reflect 发布 Reflect Open 时，我觉得这件事比市面上又多出「一款本地 Markdown 笔记工具」有意思多了。

Reflect 原本卖的就是一款云笔记订阅服务。它有自己的笔记格式、同步引擎和云端数据库，也曾把端到端加密作为核心卖点。现在，它却重新造了一个 Reflect：不需要 Reflect 账号，不再依赖 Reflect 的笔记服务器，数据直接保存为本地 Markdown 文件。Mac 版免费，并采用 MIT 许可证开源；AI 也需要用户自己提供模型密钥，也就是 BYOK。

换句话说，Reflect 主动拆掉了过去最像订阅护城河的那部分，从「云端订阅」回到了「本地优先」。

这到底是为什么？

Reflect Open 是一款全新的产品

Reflect Open 并不是在现有的 Reflect App 中增加「本地保存」功能或「离线模式」。

它是一款独立的新应用。旧版云端 Reflect 仍然保留，官方会继续维护并修复问题，现有用户也没有迁移期限；但新的开发重心已经转向 Reflect Open。用户从旧版导入数据时，得到的是一份独立副本，之后两边的修改不会继续同步。

这意味着两套 Reflect 应用将同时存在。

旧版 Reflect 的基础，是私有笔记格式、Reflect 自建的同步引擎和云端服务。笔记在客户端加密后上传，官方此前采用加密存储方案，也接受过第三方安全审计。对普通用户来说，这套方案的好处非常直接：登录账号，多台设备自动同步，后端全部由厂商负责维护。

Reflect Open 的架构思路则与 Obsidian 十分接近。

Reflect 所说的本地资料库，也就是 graph，现在只是一个普通文件夹。在那个时期，将资料库称为 Graph 曾是一种流行做法，意在强调这是一套「链接优先」的笔记系统，其中的一切内容都可以被视为 graph 中的节点。

现在，每日笔记放在 daily/，其他笔记放在 notes/，图片和附件放在 assets/。Markdown 文本文件才是资料库的主体。

我们可以在 Finder 中直接看到笔记，也可以使用其他 Markdown 编辑器进行修改，将整个目录纳入 Git 管理，或者让脚本和 AI Agent 直接读写。即使 Reflect Open 有一天停止维护，文件也不会跟着失效。

这就是 Reflect Open 最大胆的地方：它不再要求用户必须经过 Reflect，才能接触自己的知识库。

云端数据库，为什么会在 AI 时代显得沉重

以前，云端数据库通常意味着更强的产品能力。

开发团队可以自行决定文档结构，精准控制实时同步、冲突处理、权限、版本历史和离线状态。用户不需要看到磁盘上凌乱的文件，也不需要理解 Git 是什么。Notion、Craft、Roam 和旧版 Reflect 都在不同程度上受益于这条路线。

但在 AI Agent 出现之后，衡量一套笔记架构的标准发生了变化。

过去，我们主要要求 App 自己能够读写笔记。现在，我们还希望 Claude Code、Codex 或其他 Agent 能够搜索资料库、批量整理标签、修改文章、生成项目摘要，并将结果直接写回资料库。

面对普通的 Markdown 文件，AI 早已知道该怎么办。它可以遍历目录、进行全文搜索、比较版本、修改指定段落，也可以借助 Git 查看每一次变化。即使不使用 Reflect Open 自带的 AI，用户仍然可以将同一个文件夹交给其他工具。

面对 App 的云端数据库，事情就复杂得多。对外部工具而言，它往往像一座封闭的信息堡垒。

为了实现数据互通，每个 App 都需要先开发 API，再设计授权范围，维护 SDK、MCP 接口或数据导出机制，还要明确哪些字段允许读取、哪些操作允许写回。

如果接口不完整，AI 只能看到厂商愿意开放的一小部分能力；如果必须先将整套资料上传至厂商服务器，再由厂商调用模型，隐私、成本和模型选择也就全部被绑在了一起。

我相信，在过去 20 年里，云端存储、自有格式和同步引擎在各自出现的时期，都是合理甚至先进的设计。但它们也带来了大量复杂性，使产品越来越难以演进，信息则变得越来越封闭和孤立。

过去，笔记软件比的是谁能把数据封装得更好，让用户在享受便利的同时越来越难以迁移；现在，如果数据无法顺畅地开放给 AI，就很可能被更适应 AI 时代的替代品取代。

BYOK AI

Reflect Open 自带 AI Chat，可以跨笔记提问并返回引用，也支持选中文本后进行改写、总结和翻译，还可以运行用户保存的提示词。

可选的语义搜索功能会在本机生成嵌入向量（Embedding），使用随应用提供的本地模型，索引也可以随时重建。

不过，Reflect 并没有将云端 AI 作为一项打包服务提供给用户。

用户需要自己填写 OpenAI、Anthropic、Google 或 OpenRouter 的 API 密钥，密钥保存在操作系统的钥匙串中。请求会由 App 直接发送给相应的模型提供商，Reflect 不做代理，模型调用费用也由用户自己承担。用户还需要在不同设备上分别设置密钥。这也是最近比较流行的一种方式，我们上次提到的 Raycast 工具也在今年推出了 BYOK AI 接口。

Raycast 的 BYOK 宣传图

比较巧妙的是，用户可以为本地 Reflect 笔记设置「私有属性」，防止相关内容被 AI 或其他需要读取笔记的外部服务获取。

所以，「本地优先」不等于「所有 AI 都在本地运行」，BYOK 也不意味着数据一定不会离开电脑。

数据只是默认留在本地；当用户启用某项外部服务时，内容会直接流向用户选择的服务商，而不是先经过 Reflect。

同步和加密，从产品能力变成了用户选择

旧版 Reflect 的端到端加密是产品架构的一部分，Reflect Open 则不再额外提供自有的端到端加密层。

Mac 上的资料库可以放在任意本地文件夹中。如果要在 Mac、iPhone 和 iPad 之间同步，最简单的方法是将其放入 iCloud Drive；用户也可以连接 GitHub，或使用由自己控制的其他 Git 远程仓库。

Git 的优势在于能够保留完整的版本记录，但私密仓库、密钥、权限和备份是否设置妥当，都需要用户自己负责。

用户拥有了更多选择，也必须为这些选择承担相应的责任。

为什么不直接用 Obsidian

看到本地 Markdown、双向链接、日记、标签、附件和 Git，大多数人的第一反应恐怕都是：这不就是另一个 Obsidian 吗？

除了 Obsidian（下图），现在也已经出现了不少采用「本地 Markdown + BYOK AI」模式的工具，我此前介绍过其中一些。

Obsidian 已经拥有成熟的跨平台应用、庞大的插件生态和多年的用户积累。Reflect Open 目前还没有 Windows 和 Android 版本，Mac 是主要平台，iPhone 和 iPad 版本仍处于有限范围的 TestFlight 测试阶段。

Reflect Open 的优势并不是功能更多，而是更加克制。

它试图保留原版 Reflect 最受欢迎的部分：打开就是今日日记、快速记录、反向链接、键盘操作，以及不需要用户事先搭建一套复杂系统的界面。

对于不喜欢折腾插件和主题的人来说，这种具有鲜明设计取向的本地 Markdown App，仍然有其价值。

尤其对于原本就在使用 Reflect 或其他云端双链笔记工具的用户来说，Reflect Open 的界面会显得更加亲切。用户可以较为轻松地将原有习惯迁移到本地笔记环境中，而不需要重新学习一套复杂的工作方式。

我个人认为 Reflect Open 值得持续观察，但它恐怕在很长一段时间内都不会撼动 Obsidian 的地位。

它今天之所以值得一谈，是因为它代表了一种从「云端订阅」回归「本地优先」的趋势。Reflect 愿意在开放的数据基础上，继续打磨一种更精致、更具自身特色的产品体验，这是一次值得鼓励的尝试。

这一切，都是为了让用户真正拥有更多选择。

最后

风向可能正在改变。

以前，App 通过「云端订阅」锁定用户数据，从而掌握主动权。但在 AI 时代，当 AI 需要直接读取和修改知识库时，这些「云端数据」可能从资产变成摩擦。

Reflect Open 给出了一个新的表态：回归本地优先，为 AI 提供更顺畅的数据接口。

需要注意的是，在多人实时协作、精细权限管理、结构化业务流程和强一致性要求较高的场景中，云端数据库仍然比一组本地 Markdown 文件更合适。

Notion 这样的产品，几乎不可能只依靠文件夹完成团队协作。企业知识库也不能将访问控制完全交给 Git 或本地共享文件夹。

这并不是一个「本地文件必然战胜云端数据库」的故事。

当数据主要属于一个人，而 AI、脚本和多个编辑器都需要访问它时，私有格式为厂商带来的用户锁定价值，可能会越来越难以抵消它造成的接入成本。

用户不再只问「这款 App 能做什么」，还会问：

「如果我不再使用这款 App，我的资料还能做什么？」

我很认同 Reflect 选择的这个方向，但现在还不会急着宣布它已经成功，因为它的商业模式仍不明朗。原本依靠云存储获得的订阅收入（每月10 美金），未来要从哪里补回来？

毕竟，拆掉一堵数据围墙也许不难；但在没有围墙之后，继续建造一座让人愿意长久居住的房子，或许还要设法从中收租，这才是 Reflect Open 接下来真正困难的部分。

当会议机器人消失：Wispr Notetaker 与「隐形转录」

Fri, 14 Aug 2026 00:01:59 +0800

自从 AI 会议转录产品在前两年迅速走红以来，我们参加远程会议时，经常会看到一个陌生的「助手」提前坐在会议室里。

这个「助手」不开摄像头，也不说话，只是安静地旁听，经常出现在 Zoom、Google Meet、Slack 或 Microsoft Teams 中。大家都知道，它就是一个 bot——会议转录机器人。

会议转录机器人一开始只能将语音转换成文字，后来逐渐可以区分说话者、利用 AI 总结和整理内容，甚至生成下一步的行动提纲。显然，大家已经被无尽的会议折磨太久了，因此这类 AI 转录机器人一直是热门应用。

所以，当 Wispr 推出 Wispr Flow Notetaker 时，大家对此似乎已经失去了新鲜感。

但是等等，Wispr 表示：会议转录可以继续，却不再需要派机器人加入会议。

Wispr 就是那家做语音输入工具的公司。有些人可能尝试过 Wispr Flow。它刚推出时或许让人觉得很惊艳，但还不到一年，市面上就已经出现了各种 AI 语音输入替代品，其中既有开源版本，也有不少工具类 App 自带语音输入功能，例如 Todoist（下图）。

于是，Wispr 这次决定做些不一样的尝试。

它新推出的 Notetaker 直接运行在用户设备上，捕获麦克风输入和系统播放的会议音频。无论使用 Zoom、Meet、Teams，还是 Slack Huddle，即使临时开始一场没有写进日历的通话，它也可以提供实时转录，并在会议结束后生成摘要，整理会议决定和后续事项。

简单来说，就是：

录音 + 转录 + 整理

至少现在，不会再有一个陌生的机器人突然加入会场了。

但问题也恰恰出在这里。

以前那个显眼的机器人虽然很烦，却也是一种非常有效的提醒：

房间里还有一套系统正在转录会议。

现在，机器人消失了，记录行为却没有消失，甚至可能变成秘密转录。

Wispr 改变的是音频捕获入口

Wispr Flow 原本是一款语音输入工具。Notetaker 现在把这套能力从「我说一句，它写一句」扩展到了多人会议场景。

Notetaker 会在会议中提供实时转录。会议结束后，它还会结合上下文重新处理整段对话。

它会利用 Flow 的个人词典识别公司简称、产品名称和行业术语，也会读取日历邀请中的姓名，降低行动事项被分配给错误对象的概率。

这其实是 Wispr 一直在打磨的能力。

它不甘心只做一款普通的语音转录工具。Flow 会获取用户的个性化信息，包括过去常说的词汇组合、名称和语气。总之，它会获取一切有助于提高后续识别准确率的上下文信息。

这会形成一道很强的壁垒。一旦成型，其他语音输入工具就很难替代它。

毕竟，你怎么会放弃一个对你了如指掌的秘书，转而去找一个凡事都要从头教起的陌生实习生呢？

除了实时会议，用户或许还可以用它处理其他录音，例如 AI 时代之前留下的传统会议录音或电话录音。

此外，Notetaker 还会按主题整理讨论内容，提取会议决定、时间点和负责人。我们还可以检索过往会议，进行跨会议提问，或者通过 MCP 把会议内容交给 Claude、ChatGPT 及其他 AI 工具继续处理。

这样看来，AI 的确已经大有用武之地。

「在设备上捕获」不等于「完全在本地处理」

如果一款产品写着「runs on your device」，人们很容易将其理解为：数据都在我的电脑里，厂商无法获取会议内容。

目前来看，这可能是一个危险的误解。

我个人认为，在端侧 AI 尚未成熟和普及之前，AI 工具恐怕很难在完全不上传业务资料的情况下完成分析。AI 模型仍然运行在云端，可能只有录音或音频捕获过程发生在本地。

Wispr 明确选择的只是设备端音频捕获。当前版本的 Notetaker 必须开启 Cloud Sync 才能使用。

会议音频会经过加密，并在设备上短期保留。在某些情况下，音频也可能暂时进入云端，用于恢复会议、核验转录结果或排查故障，之后再按照相应设置删除。

逐字稿、摘要、行动事项和其他会议数据，则可能根据账户设置继续保留。

Wispr 也可能调用第三方 AI 服务。其政策称，服务商不得使用这些内容训练模型，相关内容通常会在 30 天内删除，但仍然会受到服务商自身规则及当地法律的约束。

开启 Privacy Mode 并不等于关闭云端存储。Notetaker 目前仍然依赖 Cloud Sync 才能工作。

所以，更准确的说法应该是：

Notetaker 在设备上捕获会议音频，再通过云端同步和 AI 服务完成整套体验。

如果会议中涉及真正敏感的商业秘密，比如大家正在开发一款准备干掉 Wispr Notetaker 的产品，那最好不要让 Notetaker 为你提供转录。

机器人很碍眼，但「碍眼」反而是一种功能

传统的会议机器人会占据一个参会席位，而且所有人都能看见。

出于法律或合规要求，有些产品在录制会议内容时，会明确告知参会者当前会议正在被录制。

这些设计都能让其他人意识到：会议正在被记录。

大家可以询问缘由、拒绝录制，或者直接把机器人移出会议。

Otter 是一款比较知名的 AI 会议记录工具。目前，它仍然会让记录程序以具名访客的身份出现在会议中，并在聊天区发出转录提示。

一般来说，这类产品的典型工作流程也是让机器人加入通话。这当然不等于获得了完整的知情同意，却至少提供了一个明显的标志。

因此，Wispr 也提醒用户：由于 Notetaker 不会以机器人身份加入会议，其他参与者可能收不到自动通知，使用者有责任在会议开始前告知所有人。

当然，我们都知道，这也是一种免责表述。

Granola 和其他类似工具

Wispr 并不是第一家采用无机器人记录方式的产品厂商。

Granola 很早就开始直接从电脑的麦克风和系统音频中捕获会议声音。

根据 Granola 的说明，会议音频仅在实时转录过程中被临时缓存。转录完成后，相关音频会从 Granola 及第三方服务中删除，不会被保存为可以永久回放的录音；逐字稿和笔记则会保存在服务器上，并同时缓存在用户设备中。

所以，Granola 也不是完全在本地运行。

它减少了原始音频被长期保存所带来的暴露风险，但文字资料仍然会进入云端。逐字稿可以被搜索、复制，还可以交由 AI 批量分析，因此未必比录音更加无害。

需要注意的是，许多 App 所说的 Zero Data Retention，通常是指第三方服务商在完成处理后，不再保留相关内容，也不将其用于模型训练。

但这并不代表内容从一开始就不会被保存在云端，也不能完全消除第三方处理会议内容所带来的风险。

所以，真正的差异已经不再是谁能够生成摘要，而是：

谁启动了记录；
其他参与者能否看见；
是否保存原始音频；
逐字稿和摘要会保存多久；
会议内容还会流向哪些第三方。

这些第三方，一般也就是大大小小的 AI 模型和云服务提供商。

一般团队应该如何使用

我认为，团队不需要一开始就编写几十页的 AI 治理白皮书，但至少应该建立以下几条规则。

第一，如果允许使用 AI 工具录音，就必须事先告知所有参会者

有没有机器人加入会议，并不是判断是否需要告知的标准。

只要会议内容正在被录音、转录或者交给 AI 分析，参与者就应该知道。

第二，对会议进行分级，不要允许 AI 记录所有会议

普通的项目进度同步、公开信息讨论和常规工作汇报，或许适合使用 AI 工具进行记录。

但涉及商业秘密、人事决策、法律事务、客户隐私和安全事件的会议，则应该更加谨慎，甚至直接禁止使用 AI 转录工具。

第三，制定相关政策，明确数据的保留期限

团队应该明确规定音频、逐字稿和摘要分别保留多久。

如果使用 AI 记录会议只是为了推动下一步行动，那么原始音频完全可以在转录完成后删除；逐字稿可以短期保留，以便核对内容；最终摘要则可以作为项目文档长期归档。

毕竟，有些会议中真正有价值的信息本来就不多，浓缩以后可能还不到一页纸。

最后

我个人很喜欢 Wispr Notetaker 所代表的方向。

过去的会议机器人很可能只是一种过渡形态，是早期受技术限制而采用的方案，没有必要成为 AI 会议记录的永久形态。

不过，不管有没有 AI 机器人，下面这些问题都值得关注：

会议内容究竟有没有被录制？
数据被送到了哪里？
数据由谁处理？
数据未来将如何保存？
参与者是否知道这一切？

Wispr Notetaker 这类产品接下来的竞争，不应该只是看谁能够做得更加隐形。

只有在隐私保护和合规处理都落实妥当之后，真正的竞争优势才会像前文所说的那样，落到一个问题上：

谁的 AI 更懂你？

这也是为什么除了 AI 会议记录以外，几乎所有 AI 助手类产品都在疯狂收集用户的业务「上下文」。

毕竟，还有什么能比会议记录提供更理想的业务「上下文」呢？

「稍后阅读」App 的分岔：Instapaper 回归阅读，Readwise 走向资料库

Wed, 12 Aug 2026 00:02:08 +0800

发生了什么？

去年 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 版

Fri, 07 Aug 2026 10:02:28 +0800

就在上个月（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 官网

https://notability.com

【速报】Airtable 将卖身 Bending Spoons，而 Obsidian 顺手递上了数据迁移工具

Thu, 06 Aug 2026 20:01:46 +0800

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；
指向未选中表格的链接，会显示记录名称，而不是 Unknown xxx；

以前我们也可以在 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 说起

Wed, 05 Aug 2026 10:01:43 +0800

笔记和任务

笔记和任务之间的分界线已经越来越模糊。

开会时，在笔记中写下一句「周五前把完善的报价单发给客户」；写某篇文章草稿时，有了一个灵感，顺手留一个下篇文章候选的主题；做旅行计划时，又在文档里勾出「订酒店」和「买保险」。这些东西最初看上去很像是笔记的一部分，但写下来的那一刻，它们又变成了任务。

待办事项如果留在原文档里，那么显然上下文很完整，却也很容易被淹没在笔记海洋里；如果复制到 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 官网地址

https://www.craft.do

用 AI 处理 Office 文档，未必只有 Copilot：看看 OnlyOffice 带来的选择权

Sun, 02 Aug 2026 15:01:33 +0800

虽然现在已经是 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 官网地址

https://www.onlyoffice.com

AI 工作台一定要住在云端吗 – 最近火起来的 Rowboat，把 AI 的长期记忆写回了 Markdown

Sun, 26 Jul 2026 15:01:31 +0800

现在有不少 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 官网

https://www.rowboatlabs.com

Rowboat GitHub

https://github.com/rowboatlabs/rowboat

【译】Notion 正在变成一个臃肿的烂摊子？

Sun, 19 Jul 2026 10:02:35 +0800

写在前面

我先声明，我无意打击 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 最近更新调整了一系列产品，是故弄玄虚？还是渐入佳境？

Sun, 12 Jul 2026 15:02:32 +0800

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 又是什么？

Sun, 05 Jul 2026 15:01:28 +0800

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 官网

https://www.raycast.com

Raycast Glaze 官网

https://www.glaze.app

【速报】Notion Mail 宣布关闭：邮箱正在从 inbox 变成 AI agent 的输入流

Sun, 28 Jun 2026 10:01:30 +0800

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 可以帮助处理邮件，但不应该默认接管所有私人通信。工作流可以自动化，个人边界和数据控制权仍然要留给用户自己，这也是我一贯的立场。

把剪贴板变成 AI 收件箱：我最近整理信息碎片的方法

Sun, 21 Jun 2026 15:01:34 +0800

我已经很少使用剪藏类插件了

最近我在试一种很朴素却很顺手的信息整理方法：浏览网页时，先不要急着分类或收藏为笔记，更不要打开某个复杂的知识管理系统，我会把看到的内容先丢进剪贴板历史里，对，就是一股脑都复制到剪贴板里。

顺便一说，这不是什么心血来潮，临时拼凑的技巧，我已经实践了6，7个月了，才在这里分享给大家。

这个方法的前提很简单：我每天会浏览很多网页，包括产品文档、博客文章、论坛讨论、工具说明、GitHub issue、用户反馈、新闻资料、摘要，甚至一些社交媒体里的短句。过去我总想在看到一段内容时，就立刻判断它应该放到哪里：是项目资料，还是产品灵感，还是写作素材，还是某个主题研究的一部分。

这种刚看到内容就开始分类的动作，其实很打断心流。

阅读时，我不应该过早切换到整理状态。阅读本来应该保持流动，一旦开始思考「这段内容放在哪个文件夹」「要不要新建一篇笔记」「标题该怎么写」「标签用哪个」，阅读节奏就被彻底打断了。

所以我现在的第一步过程非常「粗暴」：看到有用的内容，就直接复制。

先复制，不整理

这里的关键不是复制全文，这点很重要。

无脑复制全文，本质上还是另一种通篇收藏。多数时候，我只是复制一段文字，有时候只复制一句话。有时候是网页里的观点，有时候是某个段落里的描述，有时候只是一个让我想起别的问题的表达。

复制之后，我不马上处理，也不马上写进 Obsidian 或其他笔记工具，而是继续阅读下去。

我用的是 Ditto 这样的剪贴板历史工具。Ditto 是 Windows 下的工具，我用了很多年。macOS 下也有类似的 Paste 等工具。它们会把复制过的片段临时存起来。等浏览告一段落，再从 Ditto 里把最近一批剪贴板内容一次性导出或粘贴出来，生成一个很大的文本块。整个过程都是快捷键操作，并不复杂。

这个打包在一起的「大文本块」通常很乱。里面可能有重复内容，可能有网页残留格式，也可能是标题和正文混在一起，不同文章之间未必有明确划分。

以前我一定不会这样做，因为保存的结果根本没法直接用，还要花很多心思整理。现在有了 AI 之后，我反而觉得，这种杂乱但有一定筛选痕迹的文本块，正是 AI 适合处理的材料。

我只负责在阅读时判断什么值得留下，AI 则负责把这些碎片信息整理成可用的笔记。

把大文本扔给 AI

我现在会把这份大文本扔给 Codex，或者其他支持文件读写的 AI 客户端，比如 OpenCode、Claude Code 之类都可以。

重点不是一定要使用哪一个客户端，而是它要能根据预设规则，把一大堆杂乱的信息拆成多篇可读的 Markdown 笔记，并保存到指定位置。

这一步我通常不会只说一句「帮我整理一下」，这可能是最糟糕的指令，就像和老板和员工说，「帮我弄一下」，这是什么意思？。

我会预先准备一个技能、规则文件，或者 prompt，让 AI 按照固定方式工作。每个人可以按照自己的习惯和领域，给 AI 设置不同要求。我的基本规则大致是：

先识别不同主题，不要把明显不相关的内容混成一篇。
每个主题生成一篇独立的 Markdown 笔记。
笔记标题要根据内容自动概括，或者识别出剪贴板内容里已经存在的标题文本。
不要随意改写原文，重要表述保留摘录状态，并串联在一起。
将结果保存到指定目录，比如 Inbox/Clipboard/，或者某个分类文件夹。

这样做以后，剪贴板就变成了一个很轻量的 AI 收件箱。

我不需要在浏览时停下来建笔记。复制动作本身就是采集动作。等到后面统一处理时，AI 再帮我做分割、命名、归类和初步摘要。

标签不要靠临场发挥

这套流程真正变得稳定，是从我开始给 AI 预先设置标签规则之后。

如果完全让 AI 自由发挥，它很容易生成一堆看似合理、但实际不可维护的标签。比如今天生成 productivity，明天生成 productivity-tools，后天又来一个 workflow。这些标签单独看都没错，但长期会把笔记系统搞乱。

所以我更倾向于给它一张固定标签表，或者至少给出明确的标签规则。

下面只是一个例子，不是我的实际标签表：

			

allowed_tags:
  - ai
  - workflow
  - pkm
  - writing
  - product-research
  - investment-research
  - obsidian
  - local-first
  - automation
  - reading-notes

		

然后要求 AI：

只能从 allowed_tags 中选择标签。
每篇笔记至少 1 个标签，最多 4 个标签。
如果没有合适标签，使用 inbox，不要创造新标签。
如果内容涉及多个主题，优先选择最具体的标签。

我更希望 AI 根据内容理解来分类，而不是随手发明一套新的元数据。

这样生成出来的笔记不会特别完美，但基本能进入我的系统，而不是变成另一批需要整理的垃圾。

也不要对标签有过度苛刻的要求。因为有了 AI 之后，完全可以事后按照新的标签规则，对已经保存的文件重新分类。换句话说，不要苛求一次到位。

这比直接保存网页更适合我

很多工具都支持网页剪藏，但我一直觉得网页剪藏有一个问题：它太「无脑」了。

收藏网页很容易带来一种错觉，好像内容已经被处理过了。实际上，它只是被保存了，甚至可能从来没有被完整读过一次。

剪贴板方法反而更克制。因为我复制的是当下注意到的部分，而不是整页网页。它天然已经经过第一轮粗筛。即使复制得很随意，也比完整网页更接近我的真实兴趣点。

换言之，网页剪藏保存的是网页，剪贴板保存的是注意力。它更接近我当时真正注意到的东西。这里面已经包含了一层筛选和判断。如果能顺手加上批注，就更好了。

浏览时只负责阅读和发现，AI 处理时负责拆分，笔记系统负责长期保存。每个环节只做一件事，反而比一边阅读一边整理更稳定。

进阶：让 AI 定期做二次整理

在这套流程基础上，还可以加一层定期总结。

比如每周两次，让 AI 扫描 Inbox/Clipboard/ 里最近新增的笔记，生成一篇阶段性总结。

如果是按周总结，还可以让 AI 找出更高层次的趋势。比如这一周我复制了很多关于某类 AI 工作流的材料，那它就应该提醒我：这不是孤立兴趣，而是一个正在形成的研究方向。

这个总结不一定要自动写进正式笔记。它可以先放在 Review/Weekly/ 文件夹里，作为二次加工的入口。真正有价值的内容，再进入项目笔记或者 backlog。

还有一个很实用的地方：一旦标签分类规则发生改变，可以事后让 AI 对存量文件重新分类。

这在以前是无法想象的工作量。但是有了 AI 之后，这件事不再复杂，反而很实用。这也是一种二次整理。

我现在更愿意把 AI 当成一个助理，而不是一个代替我思考和阅读的大脑，我现在非常反感「第二大脑」的说法，一般当作低劣的营销噱头来看。AI 不需要也不应该替我决定什么重要，但它可以帮我把散落的内容粘合起来，分堆、贴标签，并生成初步索引。

工具为次，理念为先

这套方法最有价值的地方，不是 Ditto，不是 Codex，甚至都不是具体的 prompt。

它真正改变的是信息整理的顺序。

过去常见的顺序是：

看到信息 → 判断价值 → 找位置 → 建笔记 → 写标题 → 打标签 → 保存

稍微偷懒一点，则变成：

看到信息 → 保存收藏 → 想着以后整理 → 大概率吃灰

现在变成：

看到信息 → 复制 → 继续阅读 → 复制 …… → 批量交给 AI → 自动拆分 → 自动打标签 → 定期回顾

之前要求我在阅读过程中不断切换身份：一会儿是读者，一会儿是资料管理员，一会儿是编辑，一会儿又是项目经理。后者则让我专注眼前的阅读，把一些琐碎的整理动作规则化，并交给 AI 自动处理。

当然，这不是一个完美系统。它仍然需要定期清理，也需要不断调整标签规则。AI 也会误判主题，偶尔会把应该分开的内容合在一起，或者把一个片段解释得过头。

剪贴板原本只是一个临时缓存。加上剪贴历史工具和 AI 之后，它可以变成一个低摩擦的信息入口。

这大概也是我现在对 AI 工具最实际的期待：不是替我思考，而是把我已经注意到的东西，按我设定的规则整理好就行。

压缩个人的知识线索，把 Markdown 批注重新找回来：Obsidian SideBar Highlights 的侧边栏工作流

Sun, 14 Jun 2026 15:01:31 +0800

关于 Markdown 批注

我一直有给笔记做批注的习惯。

有时候只是把一句话高亮标出来，提醒自己以后再看；有时候则会在后面写一段自己的评论，记录当时为什么觉得这句话重要，或者它和我正在研究的某个问题有什么关系。

这件事听起来很小，但如果长期阅读、写作、做研究，或者经常整理资料，就会发现：高亮和批注其实不是装饰，而是一种非常基础的信息加工动作。对于很多基于 PDF 论文工作流的人来说，这已经是日常操作。只不过我面对的不是 PDF，而是 Markdown 笔记。

毕竟原文可能只是网页摘录，也可能来自别人的观点，批注才真正属于自己。

过去很长一段时间里，我对 Markdown 语法的用法了解得并不深，所以一直用最简单的方式处理这类需求。比如用「加粗」表示重点，用「斜体」表示补充说明，或者直接在原文下面另起一行，写上「我的看法」。（很粗糙的做法，是吗？）

这种方式当然也能用，而且很直接。但它不够清晰。

一篇文章里如果到处都是加粗，很快就分不清哪些是原文重点，哪些是我自己的判断；如果评论直接混在正文里，过一段时间再打开，就会有点像考古：当时这句话到底是引用，还是我自己写的？这段补充是临时想法，还是已经整理过的结论？

后来我才知道，Markdown 生态里其实有一些更适合批注的写法。

比如在很多 Markdown 工具里，可以用：

==高亮部分==

用来表示高亮内容。

在 Obsidian 里，还可以用：

%%批注内容%%

用来生成备注或注释。

这比单纯加粗要明确得多。高亮就是高亮，批注就是批注，正文、重点和个人评论之间开始有了边界。

再后来，我又查到了一种叫 CriticMarkup 的标注语法。它看起来比普通 Markdown 稍复杂，但表达能力也更完整。它不仅可以表示新增内容、删除内容，还可以表示替换、评论和高亮。比如：

			
{++新增内容++}
{--删除内容--}
{旧内容~>新内容}
{>>评论内容<<}
{==高亮内容==}

		

它的思路很像一种纯文本版本的「修订模式」。

过去我们在 Microsoft Word 里审阅 DOCX 文件时，会看到某个人增加了哪句话，删除了哪一段，旁边还有评论气泡。CriticMarkup 想做的事情，某种程度上就是把这套审阅动作搬回到纯文本里。

这点对我很有吸引力。因为它不依赖某一个特定软件，也不一定要进入复杂的在线协作系统。只要文本本身还在，标注信息就依然还在，不会被锁进某个云端 SaaS 的评论数据库里。

当然，CriticMarkup 原本更偏向多人协作场景。几个人共同修改一份文章、文档或手稿，需要知道谁删了什么、谁加了什么、哪些地方还有争议。这套逻辑和 Word 的审阅功能有点像，只是表达方式更朴素，也更接近 Markdown 用户熟悉的纯文本工作流。

但我后来意识到，它也不一定只能用于多人协作。到了今天，另一个很常见的批注者，可能就是 AI Agent。

比如我写完一段文章，让 AI 帮我 review，它不一定非要直接改掉原文。更好的方式可能是：保留原文，让 AI 用某种批注语法标出哪里表达不清、哪里逻辑跳跃、哪里可以补充例子。

这样我既能看到建议，又不会失去对文章的控制权。这和我一直喜欢的本地优先工作方式很契合。

我不太喜欢把所有资料都塞进一个在线平台，再依赖平台提供的评论、任务、协作和版本功能。它们确实强大，但也会让一份原本简单的文本变得越来越重。

相反，如果批注本身就能留在 Markdown 文件里，那么无论我用 Obsidian、VS Code，还是其它本地编辑器打开，它都仍然是可读、可检索、可迁移的。

这时候，Markdown 也可以变成一种轻量的审阅格式。

我可以给摘录加高亮，可以给段落加评论，可以让 AI 留下修改建议，也可以在以后重新回到这些批注里，判断哪些想法值得展开，哪些只是当时的一闪而过。

不过，高亮和批注只是第一步。

真正的问题是：当我们有了足够多的笔记高亮和评论批注之后，下一步该怎么办？

一开始，几条高亮很好处理。它们就躺在原文里，打开笔记就能看到。

但当一个资料库里有几十篇文章、几百条摘录、上千处高亮之后，情况就变了。高亮不再只是「醒目的黄色标记」，而会变成一堆散落在不同文件里的信息碎片。

你曾经觉得重要的句子，可能已经被埋在很深的目录里；你写过的评论，可能再也不会被重新看见。

这时候，我们需要的就不只是「能高亮」了。

我们需要的是：能把高亮和批注重新收集起来、整理出来，变成可以回顾、筛选、重组的材料。

也就是说，批注的价值不只在于标记当下，而在于它们能否在未来再次浮现出来。

这也是我后来开始关注 SideBar Highlights 这类 Obsidian 插件的原因。

SideBar Highlights 登场

我试过很多 Obsidian 插件，但真正能留下来的并不多。

有些插件野心太大，什么都想做，界面复杂，设置复杂，工作流也复杂。还有一些插件则刚好相反，功能太薄，几乎没有真正解决问题。

所以我后来对 Obsidian 插件有一个很朴素的判断标准：它最好只解决一个清晰的问题，但要把这个问题解决得足够顺手。

对于高亮和批注这件事，我还有一个附加要求：批注信息必须保留在原来的 Markdown 文本文件里，不要另外开一个数据库出来。

因为一旦批注被单独存到某个插件数据库里，它就开始脱离原文了。

今天这个插件还在，当然一切都好；但如果以后插件停止维护、换设备、迁移笔记库，或者我只是想用 VS Code 打开这些 Markdown 文件，那些批注信息还能不能跟着走，就变成了问题。

我不希望自己的阅读痕迹被锁在某个插件里。

我更希望它们就是文本本身的一部分。高亮也好，评论也好，任务也好，都应该和原文待在一起。这样哪怕脱离 Obsidian，哪怕以后换一套工具，这些信息依然可以被看见、被搜索、被处理。

SideBar Highlights 基本上正好符合我的需求。

侧边栏高亮列表

最核心的功能当然是侧边栏列表。

打开一篇笔记后，SideBar Highlights 会把里面的高亮内容集中显示出来。对于长文来说，这个体验非常直接。你不用在正文里滚动查找，只要看侧边栏，就能知道这篇笔记里有哪些地方曾经被你标记过。但需要注意的是，这里所谓的高亮，是指 == ，%%，和脚注（包括尾注和 inline）；但并不支持 CriticMarkup 语法， CriticMarkup 太专业了，更适合协作，而不是个人批注使用。

这有点像给长文自动生成了一份「个人重点目录」。

普通目录显示的是标题结构，而 SideBar Highlights 显示的是阅读结构。标题是作者安排的，高亮是我自己留下的。两者合起来，才更接近一篇文章真正被理解和处理过的样子。

也可以把它理解成一份围绕个人阅读痕迹生成的侧边目录。

你不需要重新阅读整篇文章，就能先看到自己当时标出来的重点。看到某一条内容时，也可以直接跳转回原文所在位置。

这就很适合二次阅读。

第一次阅读时，我可能只是顺手高亮；第二次打开时，我不一定想从头读到尾，而是想快速回到那些曾经触动我的地方。

SideBar Highlights 提供的侧边栏列表，就像是把这篇文章压缩成了一组可以跳转的线索。

颜色和 Collection

更进一步，SideBar Highlights 不只是显示高亮。

如果你给不同类型的批注使用不同颜色，它也可以帮助你区分这些内容。

比如我可以把事实信息标成一种颜色，把值得引用的句子标成另一种颜色，把需要追问的问题标成第三种颜色。这样一来，高亮就不只是「我觉得这里重要」，而可以进一步变成一种分类动作。

如果想把散落在各篇笔记里的标记聚合到一起，除了通过颜色区分，也可以通过 Collection 重新组织。

Collection 可以理解成一个分组，或者类似文件夹结构，用来把选定类型的批注汇聚到一个地方。

不过这里也要注意：Collection 会保存到专门的外部文件中，所以它和直接留在 Markdown 原文里的高亮不完全一样。不是说 Collection 不能用，而是它已经不是完全嵌在原 Markdown 文件里的信息了。从数据迁移和长期可控的角度看，这里多少会有点风险。

所以我个人觉得，如果没有强烈需求，未必一定要用 Collection。只靠 Markdown 原文里的高亮、注释和颜色分类，对很多个人使用场景来说，已经足够了。

筛选和过滤

有了高亮列表，并不意味着我一定要一次看完所有高亮，而可以只看某一类标注。

比如只看某种颜色，只看某一组 Collection，或者只看当前阶段真正关心的内容。

当高亮越来越多之后，新的问题很快就会出现：信息太多了。

原来我们是担心重要内容被正文淹没，现在又变成了高亮本身太多，需要继续筛选。

SideBar Highlights 支持多种筛选语法。对多数个人使用场景来说，已经足够。

比如我只想看「问题类批注」，或者只想看某个项目相关的高亮，就不必再从全部标记里手动翻找。它本质上是在高亮之上，又加了一层索引能力。

从正文，到正文的索引，再到索引的索引，某种程度上，这正是我们学习和整理知识的过程：从复杂材料中抽象出一个压缩模型。LLM 理解语言世界的方式，或许也有点类似。

默认隐藏的 Task Tab

还有一个容易被忽略的小功能：SideBar Highlights 里有一个默认隐藏的 Task Tab，我也是无意中发现的。

打开之后，它可以把 Markdown 笔记中的代办任务（- [ ] 语法）汇聚到一起显示。

也就是说，那些散落在不同笔记里的任务，不再需要靠手动翻找了。

这点和高亮列表的逻辑其实是一致的。

高亮负责把重要内容从正文里提取出来，Task Tab 则负责把后续行动从笔记里提取出来。这样一来，一边批注，一边生成后续任务，也就变得很自然。

比如我在阅读时看到一个问题，可以在旁边写下评论；如果这个问题值得继续研究，就顺手写成一个 Markdown 任务。之后再回到 Task Tab，就能看到这些从阅读中自然生长出来的行动项。

更妙的是，这些任务仍然留在 Markdown 里。

不一定需要额外的待办工具，而且任务和上下文天然绑定在一起。它不是孤零零的一条 todo，而是和原文、摘录、评论、高亮待在同一个语境里。

这对我来说很重要。

很多任务管理工具的问题是，任务被抽离得太干净了。你只看到「继续研究某某问题」，但过了几天，可能已经忘了这个任务是从哪篇文章、哪句话、哪个想法里来的。

而如果任务本身就留在 Markdown 笔记里，它的上下文就不会丢。

最后

所以我觉得，SideBar Highlights 的意义更像是把高亮变成了一种可操作的对象。

以前高亮只是留在原文里的颜色痕迹，现在它可以被集中查看，可以跳转，可以筛选，可以分类，也可以放入 Collection。

它开始变成一种真正的索引，就像标签一样；也是一种回到原文的入口，就像标题目录一样。

更重要的是，我一直觉得这是一种把长文，或者大量笔记，重新压缩成个人可理解知识的方法。

Markdown 给了我一个足够简单、足够稳定的文本底座。高亮和批注让我在这个文本底座上留下自己的阅读痕迹。而 SideBar Highlights 做的事情，就是把这些痕迹重新收集起来，让它们不只是躺在原文里，而是重新变成可以被看见、被筛选、被组织、被再次利用的材料。

这也是我喜欢这类小插件的原因。它只是围绕一个很具体的问题，并给出完美的的解决，把那些散落在 Markdown 里的高亮和批注压缩成为个人的「知识线索」。

SideBar Highlights 官方开源地址

https://github.com/trevware/obsidian-sidebar-highlights

直接在Obsidian 插件社区搜索 SideBar Highlights，就能安装。

【速报】Hermes Agent 终于有了官方桌面版：AI Agent 开始从命令行走向真正的工作台

Sun, 07 Jun 2026 15:01:30 +0800

最近 Nous Research 正式推出了 Hermes Desktop，也就是 Hermes Agent 的官方桌面版。

部分朋友可能对 Hermes Agent 还比较陌生，我简单介绍一下背景。前段时间，「小龙虾」（OpenClaw）这个 AI 个人助理工具火了一阵，Hermes Agent 是类似的助理工具。我当时对比了两者之后，毫不犹豫选择了 Hermes，此后再没用过 OpenClaw。Hermes 的配置和交互更人性化，支持自学习和持久记忆，也兼容多种 IM 工具和 TUI，迭代节奏一直很快。

让我印象最深的一点是：Hermes 会把完成过的工作沉淀成 skill，下次遇到类似任务时主动复用。用起来更像一个积极主动的团队成员，而不只是一个工具。

桌面版出现之前，Hermes 的门槛在哪里

在桌面版推出之前，Hermes Agent 和小龙虾一样，本质上还是一个给技术用户准备的工具。用户至少要对 CLI、TUI 有基础，才能开始配置。配置文件、provider、API key、gateway、toolset、MCP、dashboard，每一项都是单独的门槛。对喜欢折腾的人来说，这些是高自由度；对普通用户来说，根本不知道从哪里下手。

因此，大多数只熟悉图形界面、习惯点击「下一步」的用户，基本上是无缘这类工具的。

不是另一个聊天客户端

理解 Hermes Desktop，首先要避开一个误区：它不是独立做了一个 ChatGPT 或 Codex 的替代品。

Hermes Desktop 用的是同一个 Hermes Agent core。CLI、TUI、Gateway、Desktop 不是几套割裂的系统，而是同一个 Agent 的不同入口。它们共享配置、API key、session、skill、memory。你可以在命令行里开启一个任务，再到桌面版继续查看；也可以在桌面版配置模型、管理 skill，再回到其他入口继续用。

严格来说，Hermes Desktop 是一个 agent 客户端，更接近 Codex 而不是 ChatGPT。Agent 会执行一系列动作，在获得授权后控制浏览器或文件系统，最终达成用户目标。对话 chatbot 只是 agent 的一个子集。

桌面版降低的是操作成本

虽然 Hermes Desktop 的主界面依然以会话为中心，但它不只是给你一个输入框加一串回答。

左侧导航用于管理多个 agent 会话，中间是对话区，可以看到 streaming response 和工具调用过程，右侧有 preview rail，可以并排查看网页、文件和工具输出。同时内置文件浏览器，让你不用离开 App 就能看到 agent 正在读写哪些项目文件。

这类设计看似普通，但对 AI Agent 非常关键。Agent 和普通聊天机器人的差别，正是它会「做事」——读文件、写文件、搜索网页、执行脚本、调用工具。如果这些动作全部藏在黑箱里，用户很难建立信任；如果每一步都要去看终端日志，普通用户又受不了。桌面版把 agent 的工作过程可视化，降低的正是这部分操作成本。

设置终于不再全靠 YAML 和命令行

我一直觉得，AI Agent 工具要进入日常工作流，最大的门槛不是模型能力，而是配置体验。

选 provider、配置模型、决定启用哪些工具、管理 API key、连接 MCP server、设置 gateway——如果这些全部散落在命令行参数和配置文件里，用户很快就会放弃。

Hermes Desktop 这次把这些配置都放进了 UI：provider、model、tools、credentials、MCP servers、gateway、session management，都可以在桌面端直接管理。

当然，这并不代表它变成了「下载就能无脑使用」的产品。复杂的配置仍然需要一定的专业背景，必要时还是得手动处理配置文件和命令行——毕竟它们本来就是一体的。但至少门槛从「必须会命令行」降到了「理解系统基本结构即可」。这已经是很大的变化。

Windows 用户也被照顾到了

这是我很在意的一点。

很多开源 AI Agent 项目，名义上支持跨平台，实际上主要面向 Linux / macOS，Windows 用户不是被要求装 WSL，就是在各种依赖里折腾半天。

我在 Windows 10 上测试了 Hermes Desktop 的原生支持：不需要 WSL、Cygwin 或 Docker，安装器会自动处理 Python、Node.js、PortableGit、ripgrep、ffmpeg 等依赖，放在用户目录下，不需要管理员权限。整体体验和 macOS 下几乎一致。

一个 AI agent 工具，如果只在 Linux 服务器上体验好，它更像是服务器基础设施；如果能在 Windows 和 macOS 桌面上跑起来，它才有机会成为个人工作流的一部分。Windows 和 macOS 互为竞争对手，是对用户最好的状态。一个 agent app 只有覆盖两边，才算完整。

我真正感兴趣的是持久记忆和 skill

现在很多 AI 产品都在讲 agent，但大多数实际还是一次性对话：给一个任务，做一次，做完结束。下次还要重新解释背景、偏好和注意事项。

Hermes Agent 更有意思的地方，是它强调 persistent memory 和自动生成的 skill。它不只是记住聊天记录，而是把解决问题的方法沉淀成可复用的 skill。

从生产力工具的角度看，这个方向比「一次性更聪明」重要得多。真实工作里，很多任务不是全新的，而是反复出现的——整理某类资料、生成某类报告、检查某类文件、定期做研究、把信息推送到某个渠道。如果 agent 每次都重新理解一遍，本质上还是高级聊天；如果它能把流程固化下来，下次自动套用，它才开始接近一个工作系统。

Hermes Desktop 把 skill、cron、profile、messaging、agents 和 command center 这些管理入口放进桌面端，本质上是把「长期运行的 AI 工作系统」搬到了用户更容易触达的位置。

我在 AI 普及之前就有这样的认识：真正的效率来自归纳。一类事情做多了，会形成工作流；工作流用多了，会沉淀成自动化工具。用现在的视角来看，这就是 agent 的 skill 迭代逻辑。

适合谁用

先泼一点冷水：Hermes Desktop 目前不是面向完全零基础用户的产品。

技术门槛之外，更主要的问题是它的能力边界太宽。Hermes 可以连接不同模型，调用工具，读写文件，跑浏览器自动化，执行定时任务，接 messaging gateway，连接远程 backend……

如果日常事务还没有复杂到需要 AI 介入，或者完全不想归纳自己的工作流，目前的 agent 工具帮不了太多。

我觉得 Hermes Desktop 目前最适合三类人。

第一类，已经在用 Claude Code、Codex、Cursor、OpenHands、OpenWebUI、n8n、MCP 工具的人。他们理解 AI 工具调用和自动化的价值，只是需要一个更完整的 agent 工作台。

第二类，研究型创作者、技术写作者、独立顾问、产品研究人员。他们经常需要收集资料、阅读网页、整理文件、生成报告、沉淀流程。Hermes 的 memory、skill、定时任务和多入口交互，可能会逐渐成为一套长期积累的个人研究助理。

第三类，有自部署习惯的人。比如愿意在本地机器、家用服务器、VPS 或 Tailscale 网络里跑自己工具的人，希望数据和流程尽量掌握在自己手里。Hermes 的整体方向和这类用户的偏好比较契合。

如果你只是想找一个简单的问答工具，ChatGPT、豆包、千问这类会更直接。

最后

Hermes Desktop 的发布，在某种意义上标志着开源 AI Agent 正在进入下一个阶段。

第一阶段是命令行和开发者工具，大家关心的是能不能跑、能不能调工具、能不能自动执行任务，它更像是 AI 基础设施。

第二阶段是桌面工作台，大家关心的是能不能看清楚它在做什么，能不能管理多个任务，能不能控制权限，能不能把经验沉淀下来，能不能长期陪伴一个项目。这才是逐渐面向最终用户的接口。

Hermes Desktop 目前仍然有些粗糙，也仍然需要用户理解不少 AI Agent 基础概念。但未来已经在地平线上浮现——下一个操作系统、下一个 Office、下一个浏览器，这种量级的应用框架已经有了雏形。无论最终是不是 Hermes，这个方向都值得认真关注。

【译】我在 OmniFocus 中待了九年。然后我改用文本文件来管理。

Sun, 31 May 2026 15:01:29 +0800

写在前面

在 GTD 风潮兴起的时期，OmniFocus 曾经是任务管理 App 中的一代经典。

直到今天，OmniFocus 仍有大量粉丝。毫不夸张地讲，它影响了后来很多 todo 类工具，甚至在苹果自带的「提醒事项」里，也能看到 OmniFocus 的影子，比如后文会讲到的「透视图」。

我个人从 OmniFocus 2 开始入坑，但现在已经退烧很久了。我很想讲讲自己为什么退烧，但又很难归纳。最近，我看到一篇文章，讲述作者如何从 OmniFocus 切换到纯文本任务管理，我觉得和自己的经历有不少相似之处。因此，特别想分享给大家。

在分享之前，我要提醒一下：下面的文章对于一些读者来说，可能比较生涩。我已经尽力简化和注释了。我觉得文章的理念比较重要，大家不要纠结于里面的具体代码。即使完全不会代码，也有大量第三方工具可以实现类似的功能。

大家会看到 Obsidian、Logseq 的影子。如果看到 Denote 那部分，是不是也会对「文件名标签」唤起一丝熟悉感？而纯文本对同步的友好性，以及对 AI 工具的加成，例如 Claude Code、Codex，也会是未来的重要方向。这一切，都是效率火箭这些年来反复提到的东西。

最后再啰嗦一句，每个人的情况都不太一样。OmniFocus 之类的 todo 工具仍旧有用武之地，只是一部分作用被分流出去了。原作者恰好是一名后端工程师，那么绝大多数工作任务都可以被更「接地气」的方式分流出去，并不是说每个人都要做相同的实践。

我个人也仍旧保留了 todo 工具，但显然也注意到，大量具体工作任务已经被分流到了具体的项目文件夹里，并且开始和 AI 进行协作。可能这也是 OmniFocus 这类重度 todo 工具逐渐退出我视线的原因之一。

原作者：Max Holovanov
原文链接：https://medium.com/@maxclax/i-spent-9-years-in-omnifocus-then-i-switched-to-a-text-file-4190628ed11f
火箭君整理、编辑、翻译。以下正文。

正文

我觉得，OmniFocus 是花钱能买到的最好任务管理器。我用了九年，然而现在我转向了「纯文本」。

与 OmniFocus 共事的九年

我大约在 2011 年开始使用 OmniFocus。

九年来，它管理着我的生活，直到 2020 年，我把一切迁到了 org-mode。我想一开始就说清楚：它是一款出色的软件。如果今天有人问我「花钱能买到的最佳任务管理器是什么」，我仍会毫不犹豫地说是 OmniFocus。

它把重要的东西做得恰到好处。收件箱捕捉是瞬时的。项目模型可靠。推迟日期、回顾周期、视角，整个 GTD 机制都在，而且打磨得光亮如新。移动端应用也确实出色：可以随时随地捕捉想法，也可以在火车上回顾任务，或站在商店里查看某个情境。多年来，那恰恰是我生活所需的视图，它实现了这一点。我通过它推进的每一个项目都达成了结果，没有任何事情被遗漏。

这是一个故事：一个曾经非常有用的工具，如何因为「用户摩擦」而逐渐退出我的工作流。

没人提起的「摩擦」

以下是我在日复一日使用 OmniFocus 时开始感受到的问题：我花在视图切换上的时间出乎意料地多。

OmniFocus 是围绕透视视图构建的。透视视图本质上是保存好的筛选器，可以按情境、项目、标签、可用性来划分任务。透视视图很强大。但功能强大，也意味着透视视图很容易越建越多。

我会打开应用，然后开始来回切换：收件箱，然后是预测视图，然后是一个自定义透视视图，然后是项目，再切回。每次切换都很微小。它们都不是实际工作，而是工作的管理，是运行一个复杂到需要导航的系统所付出的代价。

把每天一个微小的代价乘以多年，它就不再微小。

我一直在反复思考一个挥之不去的问题：如果系统可以变得更简单会怎样？不是能力降低，而是更简单。如果我的任务更贴近实际工作所在，而我不必特意去「导航」到它们那里，会怎样？

为什么选择 Org-mode

我在其他一切事情上已经生活在 Emacs 里。Org-mode 就在那里，优势显而易见：任务就是 .org 文件中的纯文本。没有数据库，没有同步引擎，没有专有格式。任务就是一行。项目就是一个文件。议程是对那些文件的一次查询。

诚实地说，Org-mode 真正阻碍我的问题是「移动端」。OmniFocus 的手机应用是我九年来一直依赖的东西，我不想放弃人在办公桌以外的任务捕捉和回顾能力。

现在，BeOrg 这款 App 完全解决了这个问题。这是一个 iOS 应用，可以直接从 iCloud 或 Dropbox 读取和写入纯 Org 文件。在手机上捕捉到收件箱、勾掉 TODO、浏览议程，离线也可用，并且会以纯文本同步回去。只要我确认移动端捕捉仍然可行，留下来的最后一个理由就消失了。

桌面端的捕捉保持刻意简单，甚至有些无趣。一个收件箱文件，一个模板：

			
(setq org-default-notes-file
      (expand-file-name "inbox.org" org-directory))
(setq org-capture-templates
      '(("t" "Quick todo → inbox" entry
         (file org-default-notes-file)
         "* TODO %?")))

		

用快捷键输入想法，完成。从手机上的 BeOrg 应用也会追加到同一个 inbox.org。一个收件箱，两台设备，零转换。

真正的原因：任务就在工作发生的地方

移动端曾是阻碍。但那并不是根本原因。真正的原因是：

当我在处理一个项目时，我已经在它的目录和文件中。使用 Org-mode，我可以直接在上下文中写下任务，不需要切换应用，也不需要在一个单独的工具中重新查找项目。每个项目都有自己的路线图文件 ROADMAP.org，所谓的 Agenda（议程视图）则简单地将它们全部收集起来。

这是 OmniFocus 透视视图从未给过我的东西。任务不再驻留在一个我必须专门去访问的工具里。它就位于我正在执行的工作旁边，议程只是负责把它们汇总出来。

这一单一改变，几乎一次性消除了所有视图切换的摩擦。再也没有「打开任务管理器」这一步了。任务管理器就是我已经在编辑的那些文件。

我重新调整了流程，因为议程扫描会蔓延

我的第一个本能，是把 ROADMAP.org 文件直接散布在每个代码仓库里。感觉很纯粹：路线图就和工作文件、源码并排而居。

后来事实证明，这是个错误，Emacs 很快就让我意识到了这一点。每次启动都变得更慢。

一旦你看到原因，它其实很简单。Org 的议程通过扫描目录来构建文件列表。如果你把它指向包含代码项目的目录树，它会递归进入 node_modules、.git、build/、vendor/，成千上万的文件在每次议程构建时都要走一遍。要么你永远维护一份小心翼翼的排除列表，要么你接受慢启动。这两者都意味着系统开始要求你管理系统本身，而这正是我想要逃离的东西。

于是结构演进了。我没有再把路线图文件散落在各个代码仓库里，而是迁移到一个单一、专用的笔记目录，并为每个项目创建一条自己的 Denote 注记。

Denote 是一个极简的笔记包：每个文件都有一个带时间戳和关键词标签的名称，基本上这就是全部理念。设置很简单：

			
(use-package! denote
  :config
  (setq denote-directory "~/org")
  (setq denote-file-type 'org)
  ;; Lifecycle keywords — project / area / resource / archive
  (setq denote-known-keywords
        '("project" "area" "resource" "archive"
          "reference" "meeting" "idea" "someday")))         

		

火箭君注：Denote 是一个文本笔记，但是文件名上包含标签和时间戳之类的「元信息」，这样系统就可以根据预定义规则，按照标签等条件筛选内容展示。

每个项目就是一条 Denote 笔记，标记为 project，并具有一个可预测的内部结构：目标、下一步动作、未来某天。议程只扫描这一目录，而这个目录也只包含笔记。没有需要排除的东西，因为这个目录附近根本没有 node_modules：

			
;; Skip dotfiles; only ever scan the notes directory — never code repos
(setq org-agenda-file-regexp "\\`[^.].*\\.org\\'")
(setq org-agenda-files
      (seq-filter
       (lambda (f) (not (string-match-p "/templates/" f)))
       (directory-files-recursively "~/org" "\\.org$")))

		

是的，我放弃了「任务就在源文件旁边」那种纯粹性。换来的回报是，一个启动即用、永远不需要调校的系统。这个权衡显然是正确的。Denote 最终让整件事呈现出来的是简单，而不只是纯文本。

关于同步：别想太多

有一段时间，我用 Syncthing 来同步一切。它能用，而且如果设备从不接触商业云服务，它仍然是个相当不错的选择。

但对于纯粹的 Org 文件来说，说实话，这有点大材小用。Org 模式下，信息只是一些小小的纯文本文件而已。没有什么数据库会损坏，没有复杂的数据结构，也不需要合并引擎。所以我让显而易见的工具做显而易见的事情：笔记目录放在 iCloud Drive 上。BeOrg 在我手机上读取同一个 iCloud 文件夹。当然，Google Drive 同样可以胜任。

纯文本才是这里的特点。任何同步方式都行，因为没有什么需要智能同步。它只是单纯的文件而已。

我没料到的回报：AI 时代的纯文本优势

当我在 2020 年切换时，我根本没在考虑人工智能。事实证明，它比这份清单上的其他任何东西都更重要。

Org-mode 不会删除已完成的工作，它会把它归档。在一个已完成的任务上按下一组快捷键，整个子树就会移动到一个归档文件：标题、CLOSED 时间戳、优先级、标签，以及你一路上添加的所有笔记。

			
;; Completed tasks move to a dated archive, not the void
(setq org-archive-location "~/org/archive/%s_archive::")

想想那个归档实际上是什么。Git 历史记录告诉你代码发生了什么变化。你的 Org 归档告诉你，你决定做什么、为什么要做，以及它已经完成。这些都用你自己的话记录了意图和结果。这是一种不同的、在某些方面更丰富的日志：项目的记忆，而不仅仅是差异。

而且因为它是纯文本，人工智能可以读取所有内容。我可以把六个月的归档任务交给模型，并提出真实的问题：是什么一直阻碍了这个项目？时间到底都花在哪儿了？我上次接触这个东西时都说了什么？归档不再是坟场，而是一个输入。项目的每一个新阶段，都可以以它自身的历史作为上下文，既为我提供参考，也为模型提供参考。

专有的任务数据库做不到这一点。它的历史被锁在只有供应商应用才能理解的格式里。纯文本对所有工具都保持可读，包括那些在你写下这些内容时还不存在的工具。这就是纯文本在长期里悄然胜出的理由：你不是在为当下的应用选择格式，而是在为明年的工具仍能读取的格式做选择。

Org-mode 负责运行任务，我仍然手工规划结果

到这里，如果用「现在一切都在 Org-mode 里」来给本文作结，会显得优雅整洁。但那并不真实。

Org-mode 运行我所有的任务和整个日程，包括捕获、项目、截止日期、每日回顾。那是执行层，而且完全数字化。但高于任务的那一层，也就是决定一个季度走向的少数几件事，我仍然手工规划。

为此，我为 Kindle Scribe 自己制作的一个计划本，因为在四月之前，市面上的七个现成计划本都没能满足我。

每天三件成果，每周三件，每月三件，每年三件。这个限制「三」就是重点。

「三」会迫使我做出真正的选择，而不是列一张愿望清单。并且成果要写成已经完成后的状态：不是「完成报告」，而是「我完成了报告，现在我可以……」。这会把注意力拉到影响上，而不是动作本身。

为什么把那部分保留为纸质？因为任务和成果需要不同的仪式。任务需要快速、可查询、可自动化，这正好是 Org-mode 的风格。成果则需要慢下来。我用电子墨水手写，没有通知，也没有可点按的东西。这种摩擦反而是有益的：它让我在 Org-mode 把一周填满动作之前，先静下来思考什么是真正重要的。

所以真正的系统是两层的。决策目标用手写，决定三项成果。Org-mode 以数字形式，执行所有属于这些成果的任务。纯文本并没有取代纸张，它解放了纸张，让纸张去做它仍然最擅长的那一件事。

这一切值得吗？

诚实地说，总有取舍。

OmniFocus 更加精致。它的移动端、复习模式、推迟和预览体验，所有这些都确实比我搭建的任何东西好。如果你想要一个安装当天就能完美运行的系统，就买 OmniFocus，别再往下看了。

Org-mode 是一个项目，而不是一次购买。我花了真金白银的时间去让捕捉、议程和 Denote 协同工作。你在读这篇文章，是为了跳过其中的一些步骤，但不可能全部跳过。

前提是，工作流里本来就需要 Emacs。我并不是为了任务采用 Emacs；我本来就长期生活在 Emacs 里。如果各位没有这种需求，情况就完全不同。

火箭君注：即使大家不是代码开发者，比如作者，比如分析师，比如咨询业，只要工作围绕着数字文件展开，其实仍旧可以基于项目文件夹工作，就像我一样，因此这个思路一样成立。这也是 Obsidian 之类工具兴起的原因之一。

我获得的是：我的任务不再是我偶尔访问的地方。它们和我的工作并列，以纯文本文件存在，由议程统一查询，再通过一个文件夹完成同步。那种视图切换的成本，每天一点点，持续九年，终于消失了。

OmniFocus 并没有输。我只是想要更少的系统，而纯文本是唯一能给我这种感觉的方式。

补充

原作者的完整 Org 和 Denote 配置：

https://github.com/maxclax/dotfiles

BeOrg 官网：

https://beorgapp.com

对于不得不使用 Windows 的生产力用户来说，一定要装上最新的 PowerToy，它原本就应该集成在 Windows 里面

Sun, 24 May 2026 10:01:29 +0800

写在前面

我不想争论是 Windows 系统优秀，还是 macOS，还是 Linux。三者各有千秋，而且不少地方也有逐渐趋同的样子。一定要概括一下三者的优劣，我大概会这么说：

macOS：更好的使用体验，绝大多数消费级软件（除了游戏）的支持，苹果生态的加成，但也有较狭隘的硬件选择范围，和较高的苹果税。macOS 面向消费者更多些，而且用户体验相对出色。

Windows：有很多习惯上和历史上的积累，更好的外设驱动，更多的硬件选择，预算可以从简朴到奢华，也有不少可折腾的地方；但是原生功能和体验经常让人无语。很多时候我甚至觉得，Windows 应该放弃桌面，只保留运行时，其它东西索性交给第三方算了。Windows 面向工作者更多些。

Linux：很适合折腾，但对于消费级用户和传统意义上的生产力用户，实在不算友好。如果只是学习和测试，Windows WSL、macOS 终端都有很不错的替代性。考虑到 Linux 是大量网络，移动设备和云端系统的基础操作之一， Linux 面向开发者更多些。

我们还是说回 Windows。Windows 不是那种特别适合伴随我们生活的系统，但是工作上可能会非常需要，尤其是追求结果而不是过程的那种工作。

问题在于，Windows 自带的很多功能都缺乏考虑。即使对专业用户来说，也经常有掣肘。

所以，我今天想说的就是 PowerToys，一整套为 power user 准备的 Windows 实用工具。它可以改善 Windows 缺失的那些功能，如标题所说，其中很多功能，原本就应该集成在 Windows 里面。

新版 PowerToys 登场

截至目前，PowerToys 最新稳定版是 v0.99系列，真正值得关注的新功能包括 Power Display、Grab And Move，以及 Command Palette、Dock、Keyboard Manager、ZoomIt 等工具的改进。

PowerToys 出自 Microsoft 自己，是一套免费、开源的 Windows 工具集合。微软是一个很奇怪的组织，里面山头林立，有些部门的产品就让人很伤脑筋，而有些部门的产品就很优秀，比如： WSL，Powershell 这种就很优秀，也许普通用户注意不到，但生产力用户就很受用。

PowerToys 的定位是：帮助 power users 和开发者更好地使用 Windows，补足一些系统本身没有提供，或者提供得不够顺手的能力。呵呵，像是一个部门对另一个部门的补丁。

早年的 PowerToys 只是零星几个小工具，后来逐渐壮大，变成了一个包罗万象的工具箱。现在它已经不是简单的「高级用户玩具」，而是很多 Windows 用户都可以直接受益的生产力补丁。

它主要包括几类工具：

第一类是窗口和桌面管理，比如 FancyZones、Always On Top、Grab And Move、Workspaces。
第二类是文件处理，比如 PowerRename、Image Resizer、Peek、File Explorer add-ons、File Locksmith。
第三类是输入和快捷操作，比如 Keyboard Manager、PowerToys Run、Command Palette、Quick Accent、Advanced Paste。
第四类是屏幕工具，比如 Color Picker、Screen Ruler、Text Extractor、ZoomIt、Mouse utilities。
第五类是系统增强，比如 Awake、Hosts File Editor、Environment Variables、Registry Preview、Mouse Without Borders。

微软官方文档目前列出的可用工具已经超过 25 个。

这套工具最有意思的地方在于，它不是一个巨大的软件，而是一组可以单独开关的小工具，加上一个中心控制面板。小工具我们不需要全用，也不需要被迫接受某种工作流。只要根据需要开启对应的小工具选项即可。

这次比较有特色的新增功能：Power Display

新版 PowerToys 里，我最先注意到的是 Power Display。

这个功能解决的是一个很具体、但很多桌面用户都会遇到的问题：外接显示器太难调了。

很多显示器的实体按键都藏在背后，菜单逻辑也很别扭。调个亮度、对比度、输入源，像是在和显示器斗智斗勇。尤其是多显示器用户，或者一台显示器接多台设备的人，调整显示器设置一直是一件小但烦的事情。

Power Display 的思路很直接：把显示器控制放到 Windows 系统托盘里。启用之后，它会自动检测连接的显示器。如果显示器支持相应控制能力，就可以直接调整亮度、对比度、音量、输入源、色彩配置等内容。它还支持创建 profiles，也就是显示器配置预设，方便一键切换不同场景。

这类功能本来就应该是系统级能力。笔记本内屏可以调亮度，外接显示器却经常要靠显示器背后的按钮，这件事终于有解决了。

Grab And Move：移动窗口终于不用瞄准标题栏

另一个新增功能是 Grab And Move。我个人超级喜欢。

它的作用非常简单：默认按住 Alt，然后在窗口任意位置左键拖动，就能移动窗口；按住 Alt 右键拖动，就能调整窗口大小。如果 Alt 和你的使用习惯冲突，也可以换成 Win 键（我就换成了 Win 键）。

这听起来像是一个小功能，但用过类似桌面环境的人应该知道，它会明显减少窗口管理里的摩擦。

Windows 里很多窗口边缘很窄，标题栏又经常被各种自定义界面改掉。特别是在大屏、多屏、远程桌面、高分辨率屏幕上，移动和调整窗口并不总是舒服。Grab And Move 让你不需要去找标题栏，也不需要精准对准边缘，只要鼠标在窗口里面，就能完成操作。

Command Palette 和 Dock：Windows 本该有一个命令入口

PowerToys 以前最受欢迎的功能之一是 PowerToys Run，一个类似启动器的工具。现在 Microsoft 明显在推动 Command Palette，把它变成更统一的命令入口。根据我以前的印象， PowerToys Run 似乎和 Wox 这款知名的 Windows 启动器有一定的渊源。

Command Palette 不只是打开 App，还可以访问命令、工具、扩展、计算器、Terminal profiles 等。新版里，Command Palette 和 Dock 有很多改进，包括 Compact Dock、始终置顶、计算器历史、命令固定方式优化，以及扩展内容显示能力增强。

Windows 的入口一直太分散。开始菜单、搜索框、任务栏、系统托盘、右键菜单、快捷键、设置页，各管各的。Command Palette 的意义不是替代所有入口，而是给重度用户一个更快、更统一的操作中心。这是 Windows 应该自带的，就像 macOS 的 Spotlight，结果 Widnows11 原生给了一个不知什么东西糊的开始菜单。

如果我们每天反复打开固定工具、运行固定命令、切换 Terminal 环境，Command Palette 就会比开始菜单更像一个真正的工作台。

我个人比较喜欢的几个老功能

如果你第一次装 PowerToys，我不建议一口气把所有功能打开。我个人比较喜欢的几个老功能是 FancyZones、Peek、PowerRename、Image Resizer。

FancyZones 是窗口分区工具。Windows 自带分屏已经比以前好很多，但还是不够自由。FancyZones 可以自己画窗口布局，把软件拖进去自动吸附。对 27 寸以上显示器、超宽屏、多屏用户来说，这个功能很值得开。

Peek 是快速预览文件。选中文件后，不用打开完整应用，就能看内容。图片、PDF、Markdown、代码文件、文本文件都很适合这种方式。它有点像 macOS 里的快速查看，但放在 Windows 里就显得格外必要。

PowerRename 用来批量改名。替换文件名、正则匹配、撤销操作，这些功能如果没有专门工具，靠 Windows 原生资源管理器会很痛苦。

Image Resizer 则适合经常处理图片的人。右键就能批量调整尺寸，不用每次打开图片编辑软件。写博客、发图、整理截图时很省事。

一些比较小众的工具

下面这些，也许不是人人需要，但我有时或之前会用到。

Always On Top，可以快速将一个窗口始终钉在最前面，就像固定桌面便签那种。我发现还是有些 bug 的，不是所有窗口有效。

Keyboard Manager，这个工具可以重映射按键和快捷键，比如把不常用的按键改成更顺手的组合。实际上，我后来都是用 AHK 替代。

如果你经常临时需要电脑不要休眠，比如下载文件、跑任务、开会投屏，可以开 Awake。它的好处是不用改系统电源计划，用完关掉即可，类似 macOS 下的 Amphetamine 这类工具。

Advanced Paste，它可以把剪贴板内容转换成你需要的格式，也包含可选的 AI 能力。但我不推荐使用，因为剪贴板工具很多，而且剪贴板内容很敏感，经常会有账户密码之类的信息。

最后

PowerToys 最有价值的地方，不是它有多酷，而是它真的在补 Windows 的日常短，PowerToys 是 Windows 最应该内置的补丁包。

如果我们现在还在用 Windows，而且每天都要在文件、窗口、截图、文本、显示器之间来回切换，PowerToys 值得安装一次。也不要功能全开，只挑真的会用的那几个工具打开使用即可。

PowerToys 不会把 Windows 变成 macOS，也不会把桌面系统变成什么理想形态。它只是让 Windows 多一点顺手，让我们将更多精力投入专注工作，这就够了。

PowerToys 官网地址

https://github.com/microsoft/PowerToys

2026 年，小而美 Markdown 编辑器，正在变成 AI Agent 的本地工作台

Sun, 17 May 2026 15:01:39 +0800

很久以前，Markdown 编辑器曾经很热闹

很长一段时间里，Markdown 编辑器这个品类似乎已经没有太多新故事了。

以前那些主打优雅写作体验的 Markdown 编辑器，很多早已淡出视野。有不少是 macOS 独占的，还有一些众筹之后因为交付和沟通问题引发争议的案例……现在回头看，很难想象一个 Markdown 编辑器在当年也能搞众筹。

如果现在只是写一篇文章，Typora 已经足够顺手。很久以前，每当我有新设备，总是会安装付费版的 Typora；后来转向了免费的 MarkText，也很出色，Typora 现在已经几乎消失在我的视野里了。

再后来，主角基本变成了笔记库。Obsidian 的崛起，已经带来了完整生态；如果要处理代码和相关文档，VS Code 也完全能胜任。于是很多人会觉得，新的 Markdown 工具是不是已经没有机会了？

但我最近连续看了一批新的 Markdown 工具之后，尤其是结合上次介绍的 Tolaria，我感觉有一个变化正在发生：新一代小而美 Markdown 编辑器，已经不只是为了「写 Markdown」而生，而是开始变成 AI Agent 可以直接接管的本地文本工作台。

也就是说，文件仍然是 .md，仍然在你的磁盘上，仍然可以用 Git、Syncthing、iCloud、Dropbox 或任何文件同步方式处理。编辑器旁边多了一层新能力：AI 可以搜索、总结、改写、整理、生成任务，甚至通过 MCP 直接读写同一个 vault。

这和许多把内容上传到云端再调用 AI 进行加工的笔记产品，是两种完全不同的路线。

不要再只把它们看成 Typora 替代品

下面这几款新兴工具，如果按老眼光看，很容易被理解成「又一个 Typora」，但实际上并非如此。

Clearly 的定位很克制：打开一个 .md 文件，写作，语法高亮，切换预览。它是 Mac 和 iPhone 原生应用，官网也直接写着 free and open source。我个人试了一下，的确很清爽，是 macOS 下的理想选择之一。(下图)

Cogito 则更接近「文件夹优先」的 Mac 原生笔记工具。它可以添加本地文件夹，支持 [[Wiki links]]、Obsidian 风格 embeds、任务勾选、PDF 导出，还内置 AI Chat，用来编辑和 review 文件。你也可以把它理解成一个更轻量级的 Obsidian。

writer.computer 走的是另一条更加工程化的路。它基于 Tauri v2、React、CodeMirror 和 Rust，文档保存在磁盘上，尊重 workspace 的 .gitignore，支持多窗口，也能渲染表格和 Mermaid。速度快，整体是很务实的工程化风格。

值得一提的是 Quarkdown。这是另一个很有意思的产品。它不是普通编辑器，而是 Markdown-based typesetting system，可以通过 .doctype 输出 papers、presentations、knowledge bases、static websites 等形态，并支持脚本化复用内容。如果想用 Markdown 生成更复杂、更正式的排版文档，Quarkdown 是个不错的发展方向。 (下图)

这些可以算是传统 Markdown 编辑器的升级版或后继者，但真正有意思的是另一批工具。

Markdown 开始变成 Agent 的操作界面

VMark、ZenNotes、SoloMD 这几款，已经不是简单地比谁的预览更漂亮，谁的主题更多。它们真正争夺的是：AI Agent 能不能安全、直接、可控地操作你的本地文本资料。之前介绍过的 Tolaria，也可以放在这个流派里。

VMark 自称它不只是 Markdown，而是一个 plain-text workspace，支持 Markdown、YAML、JSON、TOML、Mermaid、SVG、HTML、Code，并且通过 MCP 让 Claude、Codex、Gemini 直接读写同一批 artifact。

ZenNotes 的方向也很清楚：键盘优先、本地 Markdown vault、内置 MCP server、zen CLI，并支持 Claude Code、Claude Desktop 和 Codex 直接编辑同一批磁盘上的 Markdown 文件。它还支持 Mac、Windows、Linux 桌面端，以及自部署 Web App。(下图)

SoloMD 野心很大，似乎想把自己做成一个包罗万象的 Markdown editor，同时也是连接 LLM 的桥。它强调 local-first、Git 分支管理、RAG embeddings、密码存储保护，当然也内置 MCP server，可以让 Claude Code、Codex、Cursor 直接驱动你的 vault；同时支持多个 BYOK AI 服务商。但我个人觉得它有点复杂，试用之后，不太有继续使用的动力。我更喜欢 Tolaria 那种风格。

几款工具如何选择

如果只是单篇 Markdown 文件编辑和管理，我不会把问题复杂化。Clearly 足够轻，Cogito 和 Writer 的使用体验也很舒服。现在正在用的 MarkText 也很不错。但至少对我来说，Typora 已经不会再作为首选了，时代确实变了。

如果你要做正式文档或长期笔记管理，Obsidian 仍旧是首选。想要接入 AI，Obsidian + Claude Code、Codex、OpenCode 等等，我之前有介绍，仍旧是不错的实践方式。

如果你关心前沿的 AI Agent 工作流，喜欢 All-in-one，那么前面提到的 VMark、ZenNotes、SoloMD、Tolaria，都是值得一看的产品。

Markdown 编辑器层出不穷，但 Markdown 本身并不是一种过时格式，而是成为了 AI 时代最容易被人和机器共同理解的本地数据层。

其它候选工具

Moraya：Tauri + WYSIWYG + AI Agent，方向和 SoloMD 接近，但还需要观察成熟度。

Otterly：像是更加轻量的 Obsidian / Cogito 路线，本地 vault 是重点。

Marko：Tauri、文件夹、Wiki links、Git，朴素但实用。

Inkwell：便携、离线、无账号，适合只想打开文件写作的人。

MerMark Editor：适合 Markdown + Mermaid 技术文档场景。

Nimbalyst：不算纯 Markdown 编辑器，更像 Claude Code / Codex 的可视化工作台，但代表了 Agent workspace 的趋势。

MarkEdit：不算新兴，但依然是 Mac 上小而美 Markdown 编辑器的稳定样本（下图）。

最后

我以前看 Markdown 工具，主要看：写作体验、预览效果、导出能力。

现在，基础功能早已被反复实现，「重新造的轮子」都可以绕地球几圈了。尤其是 AI Coding 使得各种廉价工具层出不穷，它们多半会被遗弃，但总会有精华保留下来。我会观察它们能否长期留下来的几个方面：安全和隐私保护如何？信息组织方式如何？能不能接入 MCP、CLI、Git、本地搜索？

这也是为什么我会说，2026 年的小而美 Markdown 编辑器，正在变成 AI Agent 的本地工作台。

最可靠的工作流未必是把一切交给云端，而是保留一组自己能打开、能同步、能备份、能审计，也能让 AI Agent 安全参与的本地文本文件。我一直是这个观点。

这也正是 Markdown 大放光彩的时刻。

文中提到的几款工具

https://cogito.md/
https://quarkdown.com/
https://clearly.md/
https://writer.computer/
https://zennotes.org/
https://vmark.app/
https://solomd.app/

Markdown已死？ HTML才是未来？这可能是个巨大的误解。

Sun, 10 May 2026 10:01:37 +0800

突如其来的唱衰

这周，突然一篇来自 Claude Code 内部人员 Thariq 的文章，在圈内大火。引起了非常热烈的讨论。

这篇名为《Using Claude Code: The Unreasonable Effectiveness of HTML》的文章，大意是说，应该用 HTML 作为人与AI交流的基本格式；而不是目前广泛采用的 Markdown 格式。原作者列出了一堆理由，也列举出了利弊。

但是在我看来，这篇唱衰 Markdown 的文章，并不是那么简单，复合了不少的误解。下面我会附原文的翻译摘要和我的观点一起进行讲解。

原文很长，但是翻来覆去就是几句话，大致核心是：AI 能力的提升，传统的 Markdown 格式已经成为限制，AI 代理（如 Claude Code）和人的交互应该全面转向 HTML，以获得更高的信息密度、更好的视觉体验和交互能力。。

原文摘要及我的的观点

1. 关于“信息密度与表现力”

原文观点引用：
“HTML 能传达比 Markdown 丰富得多的信息。它不仅能处理文本，还能通过 CSS 呈现设计、用 SVG 绘制插图。这完美替代了 Markdown 中低效且难看的 ASCII 字符画。”

火箭君的观点：复杂不等于高效，内容与表现应该分离。

Markdown 的核心哲学正是「内容与表现分离」，它强迫 AI 和用户专注于逻辑和文本本身。

让 AI 生成包含大量 HTML 标签、内联 CSS 和 SVG 路径的代码，会引入海量的无意义样板代码。此外，现代 Markdown 除了可以完美的HTML 渲染以外，还可以通过集成 Mermaid 或 PlantUML 完美实现流程图和架构图。这种声明式的图表语法比臃肿的 HTML/SVG 源码更干净、更易于人类修改。

2. 关于“视觉清晰与易读性”

原文观点引用：
“超过 100 行的 Markdown 几乎没人愿意仔细看。而 HTML 可以通过标签页、折叠面板、响应式排版等视觉结构，将庞杂的系统设计或代码逻辑整理得井井有条。”

火箭君的观点：源码的可读性才是更重要的可读性。

HTML 只有被渲染后才易读，其纯文本源码（Raw Source）是完全反人类阅读的。而 Markdown 无论是否经过渲染，其纯文本本身就具备极强的结构化和可读性，这对于习惯在终端或代码编辑器中工作的知识工作者至关重要。无论是写文章还是写代码都是一样的，这是参与思考的过程。

当然，现在有种观点，人类未来不需要阅读源码，无论是写作，报告，还是 vibe coding，源码都交给 AI 就好了。那我只能说，放弃读源码，实际是在外包自己的思考过程，等到大家都不再思考源码时，大家也就没有了自己的思考能力，只能看着 AI 生成的华丽输出傻笑了（目前已经明显有这个趋势了）。

3. 关于“分享体验”

原文观点引用：
“Markdown 在浏览器中缺乏原生渲染支持，往往需要作为附件发送。而 HTML 文件只需上传（如 S3）即可生成链接，同事们可以在任何设备上直接点开阅读，大大提高了分享效率。”

火箭君的观点：增加了基础设施依赖与安全风险。

实际上，HTML 的分享门槛远高于 Markdown。分享稍微复杂一点的 HTML 需要专门的托管服务（如 AWS S3、Vercel 等），这不仅增加了基础设施成本，还带来了权限控制和数据泄露的安全风险。

相反，Markdown 是现代协作工具的“通用语言”。你可以直接将 Markdown 粘贴到 GitHub、GitLab、Notion 或 Slack 中，它们都会提供完美的原生渲染。不需要任何“上传文件并生成链接”的繁琐步骤。

我个人也介绍了很多 Markdown 编辑器（含渲染），Windows Notepad 也开始支持 MD 了，这已经是一种默认的新文本文件格式了。很难想象，2026年，一个严肃的知识工作者居然会打不开 Markdown 文件。

4. 关于“双向交互与自定义编辑器”

原文观点引用：
“HTML 支持双向交互。当文本框难以描述需求时，你可以让 AI 为你写一个‘一次性编辑器’（如拖拽式的工单看板、特性开关表单），调整满意后再将数据导出回 AI。”

火箭君的观点：过度工程化且充满安全隐患。

让 AI 编写带有 JavaScript 的“一次性交互界面”实在是过度工程化了。

首先，运行 AI 生成的未经审查的 JavaScript 代码可能导致 XSS 攻击或本地数据泄露。原本只要好好的看文本，现在变成了还要运行代码。

其次，AI 生成的交互逻辑往往存在瑕疵 Bug，难道还要为调试这些“一次性工具”，去花费的时间？直接用文本解决原问题，不是更好吗？我一直主张，关注内容，关注问题本身，而不是花哨的形式。纯纯的 shi 上雕花。

5. 关于“生成速度与 Token 成本”

原文观点引用：
“虽然生成 HTML 通常比 Markdown 慢 2-4 倍，且消耗更多 Token，但在当前百万级上下文窗口下，这点消耗微乎其微，结果绝对物有所值。”

火箭君的观点：稀释用户和 AI 两方的注意力。

姑且我们相信仅仅慢了2-4 倍。抛开这些问题，因为AI算力，我假设以后一直会增长，一年后或许的确不是大问题了。

但在交互式 AI 体验中是灾难性的。哪怕慢2-4倍，等待几分钟只为了看一个排版花哨的报告，会严重打断用户的心流。

更重要的是，即使上下文窗口足够大，生成大量冗余的 HTML 标签也会严重稀释 AI 的注意力（Attention 机制），导致模型在长文本中迷失核心逻辑，增加产生幻觉的概率。同时，输出 Token 的成倍增加直接等同于 API 成本的激增。

而这一切，原本都是没有必要的。（哦，对了，你们是按 token 用量卖套餐的，这就解释得通了）

6. 关于审查和版本控制

原文观点引用：
“这是最大的缺点。HTML 的 Diff 噪音很大，确实不如 Markdown 容易审查。”

火箭君的观点：无法进行审查，注定只能是玩具。
原文作者轻描淡写地承认了这一点。但是审查和版本管理，尤其是审查是不可避免的，如果我们讨论的是严肃的生产力的话。

审查意味着有人参与的阅读理解，或者工具辅助的比较（比如 diff，但是多数情况下，非代码类的可能用不到 diff，但肉眼审查还是需要的）

不能被审查，意味着不能进入合规的企业用途，也很难成为效率生产的一部分（后续会带来混乱），只能在很浅的应用里打转，接近于轻娱乐和自嗨这类，我一直喜欢说的，这就是另一个“AI玩具”，闪闪发光，好玩，有新鲜感，然并卵，热度褪去后，什么也不是。

Claude Code 原本是一个真正的生产力工具，最后却要和一众 AI 玩具争夺市场？

最后

《HTML 超乎想象的有效性》一文确实展示了 AI 在前端生成方面的强大能力，HTML 也确实能做出好看的“演示工具” 或者 “AI玩具”，这是事实。

但是，Markdown 才是知识工作实践的基石。用 HTML 替代 Markdown 交互，本质上是为了追求视觉上的“华丽”，而牺牲了源码可读性、安全性、生态兼容性和审查控制能力。

在生产力的领域里，这不是专业的做法，也无疑是本末倒置的做法。无论 AI 以什么方式介入我们的工作，保持简单、专注内容，才是高效工作或协作的真正解法，这也是我这么多年的经验之谈。

顺便一说，Claude Code 借内部人士之口，鼓励大家用更耗 token 的方式使用 AI，属于利益相反（COI），本身就有商业伦理上的可疑之处，值得我们注意。（他原本完全可以说，给你们提供一个输出方式的选择 HTML，而不是说替代 Markdown ）

Thariq 原文地址

https://twitter.com/trq212/status/2052809885763747935

【译】Obsidian 实际上是一个自定义的应用平台，而 AI Coding让每个人都能解锁它

Sun, 03 May 2026 10:01:33 +0800

写在前面

我突然意识到，Obsidian 之所以在一些用户中受到欢迎，是因为很多知识工作者的日常工作流，其实都可以简化为基于纯文本的记录。

不需要特别的专有程序。

如果各位需要画 CAD、剪视频、数学建模、电路设计……那可能就需要专门工具了。即使如此，仍旧有相当一部分工作流，只需要文本记录即可，比如协作沟通记录、文摘、脚本草稿、写作草稿……

我一直推崇 Obsidian 的 File over app 理念。简单的文件成了主角，双链引用和标签则成了连接信息的枢纽。而它真正的平台潜力，正来自这种可扩展性。

如果大家关注 Obsidian 这几年的发展，可能会产生一种感觉：且不说无数第三方插件，随着官方 Canvas、Bases 陆续推出，Obsidian 已经不再只是一个单纯的 Markdown 笔记工具，而更像是一套基于新理念的个人工作台。

它是一个开放平台。如果你想在 Obsidian 里加入一个自己的应用，完全可以通过插件的形式来实现。这是以前 MS Office 很难做到的事情。一定要做当然也可以，但非常复杂。

现在有了 AI，实现 Obsidian 插件的门槛就更低了。

最近我读到 TfTHacker 一篇文章。他是很有影响力的海外科技博主，文章里分享了自己为何以及如何构建一个基于 Obsidian 的自用西班牙语学习 App。

看到开头部分时，我立刻感到它和我之前的想法高度吻合，同时也提醒了我一些此前忽略的事情。于是，我毫不犹豫地决定翻译并分享给大家。

以下正文，火箭君翻译并略作编辑。原作者：TfTHacker，原文出自：https://tfthacker.com/

正文

我刚刚构建了一个完全可用的学习 App：抽认卡（Flashcards）、语音识别、临时刷题模式。

而且，我自己一行代码都没写。

它完全本地运行，没有服务器，没有数据库，也不需要托管费用。它能在我的电脑、手机和平板上运行，甚至任何人都可以安装。

听起来很神奇，其中的秘密是：我把这个 App 做成了一个 Obsidian 插件。

而我是通过和一个 AI 对话，完成了整个构建过程。

让我解释一下为什么这件事很重要。

我们共同的问题

也许每个人都有过一个关于工具的想法。

这个工具往往和自己的工作或学习方式密切相关。我们去应用商店寻找，却发现没有合适的。

我们有时也想自己构建它，但现实很快摆在面前：也许我不是开发者，所以不知道如何构建应用。即便我是开发者，也需要一台 Web 服务器、一个数据库、前端代码、后端代码、托管和部署。

为了一个可能只有自己会用的个人工具，付出这么多努力？

那就有点过头了。

于是，这个工具 App 的想法就在脑中夭折了。

和其他大多数想法一样。

Obsidian 里藏着一些东西

大多数人忽略了一点：Obsidian 不仅仅是一个 Markdown 编辑器。

它是一个完整的应用运行时。

Runtime，火箭君注：可以简单理解为一个程序运行所需要的环境。

在底层，Obsidian 是一个 Electron 应用。也就是说，它本质上是一个可以运行网页应用的完整浏览器环境。

它支持 HTML、CSS 和 JavaScript。这些也是驱动互联网大多数内容的基础技术。

这让它成了一块非常适合构建界面的灵活画布。

但它还不止于此。

Obsidian 还悄悄提供了每个应用都需要的三样东西。

存储

我们的 vault 就是数据库。

数据保存在你自己拥有的本地文件中。不需要 SQL，不需要云端配置，也不需要第三方依赖。

同步

如果你使用 Obsidian Sync、iCloud 或类似服务，你的数据本来就已经可以在设备之间同步。

你的应用可以直接继承这一点。

分发

我们构建的一切，都可以以 Obsidian 插件的形式存在。

插件有一条明确的分发路径：你可以通过 BRAT 私密分享，也可以提交到 Obsidian 的社区插件目录。

界面、存储、同步、分发。

这四件事组合在一起，就是一个完整的应用平台。

而它其实一直就在那里。

AI Coding 改变了谁能构建软件

通过与 AI 代理对话来构建软件。

描述你想要的东西，让 AI 编写代码。

像 OpenAI Codex 和 Claude Code 这样的工具，已经让这件事变得可行。

关键转变在于：我们需要的核心技能不再只是编程，而是清晰表达。

我们能描述 App 应该做什么吗？我们能测试它，并用语言解释哪里出问题了吗？

如果能，我们就能构建软件。

我们是产品经理，AI 就是开发者。

现在，我们把这些点连起来。

AI 编码降低了亲自编写代码的必要性。Obsidian 降低了对服务器、数据库和部署基础设施的依赖。

二者结合，创造了一种新的可能性：一个个人应用平台。任何愿意描述自己想要什么，并持续迭代直到可用的人，都可以尝试构建属于自己的工具。

我亲自测试过，下面是整个过程。

我构建了一个西班牙语数字学习插件

我在学西班牙语。

根据以往的语言学习经验，我知道，掌握数字是基础。

我需要一个非常具体的工具：用于识别书面数字的抽认卡、用于强化训练的突击模式，以及用于通过听力识别数字的听力练习功能。

现有工具都无法按我需要的方式，同时满足这三点。

我需要一个专门为我打造的应用。

于是，我在屏幕一侧打开 AI 代理，另一侧打开 Obsidian。

我告诉 AI，我正在构建一个 Obsidian 插件，并让它参考正确的 Obsidian 文档，包括示例插件、开发指南、发布规范和 CLI 参考。

它读完这些内容后，很快理清了方向。

然后，我们一起制定规格说明。

我描述每个功能：抽认卡流程、突击模式逻辑、数据存储、视觉布局。

AI 代理会在对话过程中，把规格说明整理出来。

接下来就是一个循环：

AI 生成代码，我把它放进 Obsidian 里测试。

我会告诉它：

「这个按钮应该放在这里。」

「数据在不同会话之间没有保存下来。」

「突击模式需要提高答错数字的出现权重。」

AI 会进行修改。

如此反复继续。

当它能在电脑、手机和平板上运行时，我让 AI 代理把项目整理成可以发布到 GitHub 的状态，包括 README、许可证、发布配置和完整的打包步骤。

最后，我把它发布了。

其他用户可以通过 BRAT 安装。

在这个过程中，我从未直接接触过代码。

整个应用都是通过对话构建出来的。

接下来，说些真实感受

我不会夸大其词。

实际上，过程中遇到的问题大致如下。

引导一个 AI 代理，本身就是一项真正的工作

你可以把它当成一个聪明但缺乏经验的合作者来管理。

它能产出惊人的成果，但它不会读心术。

你要提供方向，发现错误，并在它偏离时纠正路线。

规格说明是最难的部分

在任何代码编写之前，你必须深入思考自己真正想要什么。

功能是什么？流程是什么？边界情况是什么？

AI 代理可以帮助制定规格，但主导者仍然是你。

AI 开发速度更快，但并不是瞬间完成

我的西班牙语数字插件，是一个相对聚焦的应用。

即便如此，它也花了大约一天半。

如果手动编写代码，可能要花我一周左右。

这确实是显著提速，但别指望能在一小时内，把一个想法直接变成成品。

测试能发现 AI 漏掉的问题

我的插件在为某些数字类型生成西班牙语时出错。

这可能会让用户学到错误内容。

我不得不添加额外验证，并推动 AI 代理写出更好的测试。

AI 捕捉不到所有 bug。

我必须自己对质量负责。

发布过程仍然有些技术性

我需要阅读文档，并理解 Obsidian 插件分发系统的基本概念。

这不一定需要亲自编写代码，但确实需要获取相关背景信息。

我希望 Obsidian 未来能进一步简化这一过程。

谁应该尝试这个？

对于希望根据自己的工作流精确定制工具的个人用户来说，这种 AI Coding 方法很理想。

对于通过共享 vault 或共享文件夹来同步插件和数据的小团队来说，这种方法同样适用。

它并不是为复杂后端、大规模多用户应用而设计的。

但如果是个人工具、小团队实用程序和定制工作流呢？

它确实打开了一种新的可能性。

更大的图景

我们正处于一个转折点。

AI 大幅降低了构建软件的门槛，但软件仍然需要一个运行和承载的地方。

它需要界面、存储、同步，以及分发给用户的方式。

Obsidian 提供了所有这些。悄无声息。没有喧嚣。它一直就是一个应用平台。

想一想，大家希望存在的那个工具。

那个完全符合你需求、完全匹配你工作流的工具，可能一直不存在。

而且，应用商店里往往也找不到它。

现在再想想，构建它的门槛从未如此之低。

几乎不需要学习编程。不需要搭建服务器。

你只需要描述自己想要什么，并愿意不断迭代，直到它真正可用。

平台已经在那里，AI 也已经足够可用。

剩下的问题是：你是否真的知道自己想要一个什么工具，并愿意把它一点点打磨出来。

原文作者（TfTGancker）制作西班牙语学习 App 的 Github repo:

https://github.com/TfTHacker/spanish-learn-numbers/

Tolaria，一款结合 Obsidian 和 Notion 优势，又是本地，又是开源的笔记工具新品诞生了！

Sun, 26 Apr 2026 15:01:34 +0800

Tolaria，这款工具很新，也挺火。

如果你看过或者用过它，很难不被它吸引。且不论它能走多远，在大家以为 PKM 已经没什么新花样的年代，Tolaria 这样一个真正的后来者，能做到如此出色，确实让人感叹。

什么叫做后发优势？

经常读我文章的各位，想必已经对 Notion / Obsidian 之类的知识管理工具耳熟能详了，各种优劣点也能如数家珍。

先说 Notion。它的界面和操作足够友好，也有原生 AI 集成；但它锁定云端，没有本地优先的数据主权，也很难给用户留下自由折腾的空间。

再说 Obsidian。它插件众多，适合折腾，本地优先，数据自主；但云同步相对孱弱，协作也基本不要想了，AI 集成目前也仍在推进中。

还有一些 PKM 工具也各有特色，有的引入了 Type「类型」的概念，我个人很喜欢；有的则主打短平快，而且开源。

到了 2026 年，在 AI Coding 的加持下，少数人也终于可以打造出大家心目中的 PKM 工具，而且功能上几乎没有妥协。这个站在后发者角度出现的产品，就是 Tolaria。

和 Notion 相比，它有类似的 / 命令和文档模块，编辑界面也有相似之处；但 Tolaria 更像是一个本地优先的 Notion。

和 Obsidian 相比，它也有双向链接、纯本地 Markdown 文件和 YAML 支持；但 Tolaria 更像是一个开源取向的 Obsidian 替代品。

其实还不止这些。我只是想说，Tolaria 这个后来者非常熟悉它的前辈们，并且有针对性地找到了各自的差异点。这不像是一个笔记爱好者吹牛的作品，也不像是什么知识管理体系卖课的套路，反倒像是真正懂行的人出手做出来的结果。它虽然后发，却有一种集大成作品的气质。

Tolaria 登场

这款产品的常规特性我就不再介绍了，有常见笔记工具经验的用户肯定上手就会用。什么模块化笔记、双向链接、Markdown 语法……它基本都支持。

我就讲讲几个给我留下深刻印象的地方。

Obsidian File Over App 理念的继承者

在 Tolaria 里，没有黑盒数据库，没有云端同步的强制绑定。每一个笔记，就是一个干干净净的 .md 文本文件。

这意味着哪怕明天 Tolaria 这个软件彻底从地球上消失，我们的知识库依然完好无损。你可以用系统自带的文本编辑器打开它，我们的数据永远只属于我们自己。

这是 Obsidian 的核心理念之一，Tolaria 也是这一理念的继承者。这意味着 Obsidian 和 Tolaria 之间几乎没有太大隔阂，迁移和共存的成本都比较低，用户的选择空间和安全感也都得到了明显提升。

Git 成了内置标配

大多数笔记软件都有个「回收站」，但 Tolaria 没有。它直接把整个笔记库「Vault」变成了一个 Git 仓库。每一次修改和删除，都会在底层版本控制里留下痕迹。

对于非技术人员来说，这可能是噩梦，太极客了。但熟悉这种设定的用户，会获得一种前所未有的安全感：永远可以回滚到某个历史版本，再也不用担心误删或者改废了一篇长文。

看到那些 Diff 视图，我估计有人会感动到要哭。其实 Obsidian 也是可以集成 Git 插件的，只不过，在 Tolaria 里，Git 是内置标配。

引入了 Type 和视图

如果说上面两点只是技术选型上的偏好，那么 Tolaria 对「分类与标签」的处理，则展现了相当不错的产品判断。

用过 Notion 的人都知道，它的核心是 Schema「模式」。要建一个表格，往往需要先定义字段：这个是文本，那个是日期，另一个是单选框。这种「结构先行」的设计，导致很多人在记笔记前，要先花半小时搭框架。

Tolaria 提出了一个截然相反的理念：Types as lenses「类型作为透镜，而不是强制结构」。

在 Tolaria 里，你可以给笔记打上各种「类型」，比如 Project、Topic、Journal，并为它们设置不同的颜色和图标。但重点是：这些类型并不会强制你填写某些字段，也不会进行严格的字段验证。

它们只是帮助你在这个庞大的文本库里导航的「视觉提示」。你想填属性就填，不想填就空着；你想给这篇随笔标个红色的灵感图标就标，不想标，它就是一个普通的文档。

当我们需要汇总或查询特定类型、特定条件的文档时，可以创建一个筛选或查询视图，并保存下来供以后复用。

这种理念在其他笔记工具里也有体现。比如 Obsidian 其实也可以通过笔记关联、标签和查询视图达到类似效果，我也一直是这样做的。Tolaria 只是把它显式地表现了出来，并作为内置标配。

更独立的 AI 集成方式

过去一两年，几乎所有的笔记软件都在疯狂加 AI 功能：右键帮你总结、帮你润色、帮你扩写。

多数厂商出于商业目的，都希望用户使用 PKM 工具内置的 AI，并把它作为订阅收费的一部分。这其实和提供云存储一样，属于锁定基础设施并收费。各类云笔记几乎都是这样做的，这是重要的收入来源。

Obsidian 显然不会走这条路，所以它更像是在摸索一种独立于 App 自身的 AI 集成方式。用户可以选择与 Claude、ChatGPT 或其他 AI 客户端结合使用，Obsidian 只提供接口。这和 Obsidian 的一贯理念是吻合的。

Tolaria 本质上还是 Obsidian 的精神继承者，保留了用户对 AI 的独立选择。只要用户装过 Codex 或 Claude Code，就可以一键连接，开箱即用。至少在这一点上，它似乎走在了 Obsidian 前面。

Tolaria 内置了一个完整的 MCP「Model Context Protocol」服务器。通过 MCP，AI 可以直接读取整个笔记库，理解目录结构，甚至直接在里面新建文件、修改内容。

我们可以对 AI 说：「把过去一周我写的关于『管理学』的散碎笔记，整理成一篇结构化的长文，并更新到我的主页目录里。」

Tolaria 不做自己的封闭 AI，而是把自己变成了一个对所有外部 AI 极度友好的「容器」。这种 AI-first 但不 AI-only 的策略，也就是优先拥抱 AI，但不把用户锁死在某个 AI 服务里，确实聪明。

无论未来是 OpenAI 还是 Anthropic 出了更强的模型，Tolaria 的用户都可以持续接入更前沿的 AI 能力，而不必被绑定在某个软件的订阅费上。

最后

我已经简单试用了一会儿 Tolaria，但这个产品还很新，更新也很频繁。我建议大家先不要冲动迁移整个知识库，观察一段时间后，再做结论。原因如下：

（1）目前还存在不少小 bug，我都忍不住想提交修改了。

（2）AI 集成还需要更稳固的支持。这已经不是单纯挂一个 MCP 就能解决的问题，还需要更多真实使用场景的打磨。

（3）目前支持 Mac，好像也支持 Linux，但我还没试过；不过现在竟然还没有 Windows 版本。（这种 Tauri 项目居然还要挑挑拣拣……）

总体来说，Tolaria 潜力很高，作者一看就是懂行的人，非常清楚现有笔记产品的优劣点。

问题是，Tolaria 还太新，缺少时间积累，也没有插件生态支持。它看起来很像 AI Coding 或 Vibe Coding 加速下的产物，后续维护和修整仍有待考验。

但它的开源特性，又让这些问题有了被解决的可能。只要人气足够高，就可能有贡献者持续维护下去。再加上 AI Coding 的发展，这些问题也许并没有过去那么难解决。

所以，它现在最缺的，其实就是时间。

有兴趣的小伙伴可以立刻去试试看。不用注册账号，也不会让你月付、年付去订阅什么 AI 套餐。（AI 工具得自备，也就是 BYO。）

再强调一遍，Tolaria 不是一款 AI 套壳骗订阅的闪亮新鲜产品，它更像是 Obsidian 精神上的继承者。

Tolaria 官网地址

https://tolaria.md/

让 AI 帮我们画流图，我试了几种 Excalidraw MCP 方案

Sun, 19 Apr 2026 15:02:04 +0800

很久以前，我介绍过一些在线流程图工具，当时有很多人都表现出极大的兴趣。如今转眼已经到了 2026 年，在 AI 大行其道的当下，我突然发现，已经出现了可以几乎完全依赖 AI 来绘制流程图的方案。

只要把要求交代给 AI，它就能先把图画出来，后面我再细调或修改，效率比以前手工绘制高了不少。

首先还是要讲一下 Excalidraw。它是一个流行的开源绘图工具，不过这并不是今天的重点。这个工具已经出现很久了，很多软件都围绕它做了集成或插件支持，比如 VSCode、Obsidian，甚至它的官网在线版也是开箱即用。

顺便一说，Excalidraw 插件比 Obsidian 官方的 Canvas 还要早，直到今天仍然位居插件下载排行前几名。开源也意味着它更容易被 AI 接入和操作。

所以，今天真正要讲的重点还是 AI。毕竟，不管是 Excalidraw，还是其他那些画面更精致、功能更丰富的流程图工具，选择其实很多。但 AI 集成是另一回事。

这里我更看重的是智能化体验。和 AI 说话，直接出图，不用关心具体工具细节，也不用研究各种操作技巧。我们可以把自己想象成一个管理者，只负责把需求讲清楚，剩下的事情交给操作员去完成。至于操作员用什么工具、怎么画，那反而不是重点。

开始之前，先准备好 AI 客户端

在开始之前，我们得先准备好 AI 客户端。这虽然不是本期画图的重点，但几乎是之后所有 AI 协作的前提之一。

我们以前介绍 Obsidian Skills 时，也是一样需要 AI 客户端。当时我印象里用的是 Goose，这次我试了试 Codex。

除了 Codex，我们也可以用 Claude Code、OpenCode、Goose 等等。可选择的 AI 模型也各不相同，这个就按大家的喜好来选即可。就我自己的判断看，AI 客户端这一层很难拉开长期差距，最终大多会趋同，你有的功能我也会有，而且迭代速度都很快。

Excalidraw 官方 MCP

Excalidraw.com 官方也下场做了 MCP，走的是 MCP Apps，也就是交互式界面这条路线。它更像一个带交互界面的 MCP 应用，可以在聊天窗口里直接生成 HTML 交互界面。

设置也很简单。告诉 AI 客户端，我要使用 github.com/excalidraw/excalidraw-mcp，帮我把它封装成一个 Skill，以后我就可以通过 Skill 远程调用这个官方 MCP。AI 会自动查询文档并完成 Skill 设置。不同客户端的操作方式可能略有不同，但核心机制是一样的。

需要注意的是，这个官方开源 MCP 既可以自部署，也可以远程调用。我们这次主要试了试远程调用，后面也会讲到另一个偏本地自部署的方案。

AI 设置完毕之后，后面就可以直接通过 Skill 要求它出图了。

比如，我这里的使用方式就是这样。

AI 在完成思考并调用 MCP 之后，就会生成这样的图。我们可以直接在 Excalidraw 官网打开，再进行编辑、保存和导出。

从我的理解看，Excalidraw.com 官方的思路，可能就是通过 MCP 把用户引导到 Excalidraw 网站上。这个网站本身就是个在线工具，免费开箱即用，甚至可以把本地文件直接拖进去立刻编辑。如果有更重度、更高频的需求，包括更紧密的 AI 集成，以及云端分享和协作，官网也会进一步把我们引导到 Excalidraw+ 的付费订阅方案上。

就我的实际使用感受来说，官方 MCP 的整体表现算是中规中矩，速度也比较一般，而且最后还是要回到网页里打开。当然，你也可以把 MCP 自行部署到本地或自己的服务器上。总体来说，这更适合轻量、临时的使用场景。如果你本来就有比较重度的画图需求，那我反而会建议直接订阅 Excalidraw+ ( 7美金每月 )。

@cmd8/excalidraw-mcp：一个纯本地的 Excalidraw MCP

如果你和我一样，更偏向本地优先，那我会更推荐 @cmd8/excalidraw-mcp 这款开源 MCP。它不是最花哨的，但它很可控。

这是目前最贴合我工作流的方案。它的路线相当克制，从安装那一刻起，它就要求你指定一个明确的本地路径。它暴露给 AI 的能力也很克制，比如创建节点、创建连线、删除元素、读取整张图的状态等等。

这意味着我们不需要开网页，也不用经过 Excalidraw 官网。你只需要像平时让 AI 改代码一样，把需求甚至修改意见直接交给它，AI 就会去修改本地那个 .excalidraw 文件。

因为它本质上就是本地文件，所以很适合直接纳入版本管理，方便审阅和提交。这一下就把整条工具链打通了。查看绘图文件需要我们自己安装一个可以打开的工具，比方说，我这里是 VSCode 加 Excalidraw 插件，或者其它的什么兼容的 App 都可以。对于 Codex 这类本就擅长处理本地工程文件的 AI 客户端来说，这种方案确实非常顺手。

同样，初始设置也不复杂。我们只要告诉 AI，要封装一个 Skill，基于 @cmd8/excalidraw-mcp 这个开源项目来生成图，剩下的基本就交给 AI 去处理即可。

其它选择

除了上面两个 Excalidraw 相关的 MCP 之外，其实还有一些别的路线。

比如 yctimlin/mcp_excalidraw，这是一套更「重」的实时白板工作台。它需要在本地同时跑两个进程，一个是本地网页上的 Canvas server，另一个是 MCP server。它提供了几十个工具，支持元素级的增删改查、场景描述，甚至截图导出。

但对我来说，这条路线就有点太重了。如果我真的有这种需求，我大概率会选择某种本地专业工具来完成操作，让 AI 先给个草稿，再回到专业工具里编辑，但是长远来看，未来的 AI 或许真的可以事无巨细的全包下来。

另外，还有一个不属于 Excalidraw 体系的替代选择。那就是：如果我们本身就是 Obsidian 的重度用户，那我上次介绍的 Obsidian Skills，其实已经包含了对 Obsidian Canvas 的操作能力，也能画出流程图，而且能更好地和 Obsidian 笔记引用结合，整体上也更轻量。

唯一的遗憾是，Canvas 和 Excalidraw 毕竟是两套不同的体系。Obsidian Canvas 只属于 Obsidian，而 Excalidraw 的生态基础更广，在各种软件里也更容易找到现成的集成和兼容支持。

最后：AI 应用风暴，才刚刚开始

如果只是想最快看到效果，或者想给团队做个酷炫一点的演示，那就选官方方案，体验在聊天窗口里直接出图的感觉。

如果想要一个能反复打磨细节的画图助理，那可以去折腾 yctimlin 的实时画布方案。

如果想要 All-in-Obsidian，那就继续用 Obsidian Skills 去制作 Canvas。虽然不是 Excalidraw，但在 Obsidian 工作流里依然很好用。

而如果和我一样，只是想在 Codex 这类客户端里，把架构图当成本地资源的一部分来管理，那我会更推荐 @cmd8/excalidraw-mcp。

至于 MCP 或 Skill 的未来，也许真的会像官方方案暗示的那样，把聊天客户端逐步变成一个个真正的应用容器。这件事很值得期待，因为它很可能会让不少套壳式 AI 产品或轻量工具，开始显得没有那么必要。

AI 生成流程图、架构图、关系图这些能力，可能还只是个开始。更大范围应用形态变化的「风暴」，恐怕已经在路上了。

【速报】硬核的「在线大纲笔记」 Tana，现在要彻底转型了，不知是福是祸

Sun, 12 Apr 2026 10:01:29 +0800

Tana 最近的动作有点大。如果我们对它的印象还停留在那个硬核的「在线大纲 + 知识图谱」工具，现在得刷新一下认知了。

根据大约一周多前（3月31日）的官方公告，原来的 Tana 产品将正式更名为「Tana Outliner」；而「Tana」这个主品牌，则被拿去承载一个全新的、主打团队协作和 AI 代理（Agent）的产品。

全新的 Tana 官网首页已经直接挂出了新产品的口号：「Meetings that ship」，并开放了早期访问申请。

这已经不是什么常规的加强迭代了，新产品应该是另一个截然不同的生产力工具了。

新旧 Tana

Tana 的官方坦诚：Tana 的老产品（现在叫做 Outliner 了，下图）确实强大，但学习曲线太陡，一些小众用着爽，但想在团队里推广简直是灾难。面对这个情况，他们没有选择把老产品强行「降智」推向大众，而是直接分家。所以，大家不要期待 Tana Outliner 什么开箱即用，什么任务引导上手，什么视频教程 …… Tana Outliner 和以前一样高冷。（我甚至怀疑就是放弃了，想想 Arc）

那些喜欢折腾无限缩进和 Supertags 的硬核笔记玩家，继续用保留下来的 Tana Outliner；与此同时，Tana 官方另起炉灶，做了一个门槛更低、专攻下一代 AI 协作流的新 Tana。

新 Tana 的野心不在于「帮我们记住会议」，毕竟会议记录的 AI 产品太多甚至泛滥了，新 Tana 想做的是「开会时就把活干完」。看看口号 Meetings that ship，有点感觉了吧。

新 Tana 想要在开会的同时，把决策、bug、行动项直接塞进知识图谱，甚至顺手生成 PR、产品说明或用户旅程图。它自带视频会议体验，未来还计划接入 Zoom 和 Teams 这类现有会议工具。很明显，Tana 想把自己变成一个以会议为入口、AI Agent 为执行层的协作中枢。

从放出的功能清单看，新架构确实是冲着真正的大众市场去的：实时协作画布、细粒度权限、更像传统文档的编辑器，外加 GitHub、Slack、Linear 等一堆外部 App 接入，甚至一开始就考虑了移动端。

相比之下，以前的老 Tana 太像小众硬核玩家自娱自乐的系统了，非常不适合直接改成团队平台。这点，我个人也完全理解，以前的Tana 我也不知道怎样向一般人普及，门槛太高了，潜在用户最好先有一些普通笔记工具的经验，然后理解大纲笔记结构，需要思路逻辑严谨，对标签的本质，信息的聚合，数据的查询…… 最好都有理解，这已经不是一般用户了，妥妥的 power user。

老用户手里的 Tana Outliner 会被抛弃吗？

至少官方目前的态度是安抚。2026Q2 的更新计划里依然排着 API 修复、桌面端优化、分组能力和移动端改进。更远的路线图里甚至还有本地 AI 模型和日历同步。

但我心里还是有点不安，官方虽然承诺了不强制迁移、争取夏天前做出一键迁移、现有订阅不变；可是，最致命的几个问题——具体时间线、新定价模型、双产品数据怎么打通——目前还完全难以预测。

这也是为什么我自己一直用的是 LogSeq（Tana 实际上最初很像 LogSeq的在线版），我很推崇 Tana 的一些设计，尤其是 Supertag，但是当我一看到在线云端，我就知道如果没有协作需求，我是不会采用Tana 作为主力工具的。因为，我也担心，将来哪天 Tana 不玩了，数据和功能都完全受限于人。再仔细想到：这类大纲图谱工具，其复杂的数据结构还不是 Markdown文本可以简单导出的，这简直是个专有数据库啊，所以迁移成本必然很高，与其到时割爱，不如以终为始。

最后

把复杂硬核工具拆分，商业上是步好棋。纯个人知识管理（PKM）离钱太远，大家当做强身健体的爱好就行了（对个人还是非常非常有用的），而商业上，想靠 PKM 挣大钱的几乎没有。另一方面，如果不是面向个人，而是面向组织和生产力团队的知识管理是有利可图的，但目前也在受到各种花式 AI 方案的强力打压。

可以肯定的是，目前关于协作和执行的费用，仍旧是企业预算中重要的组成部分。Tana 描述这个新方向无可厚非。考虑到 Tana 背后已知的两轮融资，转型几乎是不可避免的。原有的小众 PKM 故事，根本撑不起这个上亿美元估值的叙事。

话说回来，如果各位现在就是 Tana的付费用户，建议很简单：先别慌，接着用 Tana Outliner。密切关注新 Tana 的定价和迁移方案即可。

至于，这次新 Tana 的重构能不能成，让我们拭目以待，不出几个月里面就会有分晓。考虑到现在 AI 热点高速演进，一个季度里面不出点成果的话，也就不用混了，要么 ChatGPT， Claude 自己已经实现了；要么海量第三方创业公司通过 Vibe Coding 也实现了；最最不济，如果这个点子真的有用，在稍微晚些时候，各大会议工具例如 Zoom，项目管理工具例如 Linear 也都会跟进实现。

所以说，留给 Tana 的时间其实不多了。Tana 团队赶紧开会，如果你们的新 Tana 真的像你们说的那样神奇，快点用你们自己的新工具，把自己的新产品自动交付出来吧。

在 Obsidian 里，笔记标题是如此重要，写得越笼统，思考的价值越低

Sun, 05 Apr 2026 10:01:33 +0800

回想一下，也许几年前，我们刚建好第一个 Obsidian Vault 的那个周末。

我们可能花了好几个小时折腾文件夹分类，挑了各种社区主题，装上了当时排名第一的 Dataview，晚些还会装上 Excalidraw，看板，日历，任务插件；然后对着那个空白的全局关系图谱（Graph View）发了一会儿呆，幻想它迟早有一天会变成什么复杂的的「第二大脑」图谱，炫酷的知识花园 ……。

一切准备就绪后，写了几篇不明所以的笔记后，我们早晚会郑重地敲下第一对双中括号 [[ ]]。

我们该引用或创建什么东西？202403 播客随想？《掌控习惯》第二章读书笔记？关于创造力的几个点子？

不用多久，当我们在快捷切换（Ctrl+O / Cmd+O）的搜索框里敲下“创造力”，看着跳出来的几十个毫无关联、面目模糊的搜索结果时，会感慨这到底都是些什么？

再看看我们的关系图谱，它根本不是什么「大脑神经网络」，这个比喻我一度觉得害了很多人，我相信大脑绝不是这样运作的；而且，也不是画个酷炫的图谱就掌握了知识连接的精髓。

经历这几年后，我可以很有把握的说，其实所有一切混乱的根源就在最开始，给笔记命名 这件事情上。

为什么在 Obsidian 里，标题就是一切？

在早期传统的笔记软件里，大家靠「树状目录」找东西，这也是更早期文件系统的映射。但我们知道在 Obsidian 里，核心玩法是双向链接，这是一等公民，但不是说传统分类不重要。

无论是双链，文件夹，还是标签……，我们在笔记之间的关联，仍旧和笔记标题有极高的联系。两年后，当迫切需要某个观点来支撑一篇文章时，大概率能让我们和那条旧笔记重聚的，就是它的标题恰好命中了我们大脑中自然浮现的那个搜索词。

我们不可能，在未来去深读每一篇文章，所有搜索关联，能浮现在我们脑海里的都变成了：简短的标题，关键词（也可以说：标签）。

这是我们的肉身大脑在处理复杂信息时，自发的一种信息压缩，为自己建立一个短索引表。我觉得这个短索引表更接近于我们掌握的知识，而不是那些花里胡哨的「第二大脑」。

标题的误区

如果上手不考虑一下标题，会直接导致了我们在建构 Vault 时遇到这样的麻烦。以下是我自己一路踩坑后的一些感悟。

误区1：用信息来源命名，而不是用观点

这是一种虚假的安全感。我们觉得自己在追踪信息源，很有条理。但「来源」只是收集那一刻，某一种维度的分类方式。尤其是到了现在，2026年了，Obsidian的插件，还有 AI已经足够发达，这些来源信息，很多时候都在收集的刹那被自动写入文件 meta 里了。标题上重复的意义就不大了；除非这个来源特别有意义，否则可以选择性忽略。

误区 2：使用笼统模糊的词汇

像 [[关于记忆的想法]] 或者 [[习惯的思考]]，这些根本不是标题，只是占位符。

当 Vault 里只有 50 篇笔记时这招管用；当有 500 篇笔记时，这就没什么用了。因为只能命中：「记忆」，「思考」，「习惯」这样的泛泛之词，没有更深度的见解，引用时，完全不知道是不是命中，除非再去读一遍原笔记，这样的话效率就非常低下了。标题的优势在于第一时间决定了什么要读，什么不要读。

正确的命名可能是：[[在长期记忆保留上，自我测试的效果优于重复阅读]]。

而且充分利用，Obsidian 的特性，多写一些「原子笔记」，千万不要把一大堆内容扔在一起，然后起一个笼统的标题（我以前常这样做，所以真的是深有体会）。

误区 3：用「问题」代替「答案」

[[什么是反脆弱？]] 或者 [[复利到底是怎么工作的？]]

用问题做标题看起来很有趣，但有趣没法帮我们建立有效的连接。

「问题」不是知识，「问题」只是待研究队列中的一个入口。
如果这是我们要准备去阅读去调研的空白笔记，这是一个不错的命名，但是如果作为一个归档的笔记，我会觉得欠妥。

如果真的思考过了，就直接写结论：[[反脆弱系统能从波动性中获益，而不仅仅是坚韧]]。

这是一句完整的论点。它可以被反驳，可以被其它笔记扩展讨论。如果目前还不知道答案，那这条笔记就不该成为归档笔记，它应该待在收件箱或者类似 Todo 的队列里。

根据我上面的理论，如果能写出这个结论标题，是因为我们自己努力过了，进行了信息压缩，使之进入第一大脑中的「短索引表」了。

误区 4：滥用 Zettelkasten ID

很多刚接触卡片盒笔记法的人，崇拜卢曼卡片笔记法，喜欢给每条笔记加上时间戳，比如 [[202403281423-刻意练习]]。我们知道，Obsidian 的确有这样的核心插件。

卢曼当年使用数字编号，是因为他用的是实体卡片和木头盒子，需要编号来确定物理位置。而我们用的是 Obsidian，拥有毫秒级的笔记搜索。

在数字软件里，时间戳可以作为 YAML 区的元数据（Metadata）保留，但最好不要让它占据标题的视觉重心。除非，时间特性很重要，比如时事新闻类。

如果要加前缀防止重名，至少要确保时间戳后面跟着的是一句完整的观点，而不是空白或一个干瘪的词汇。

误区 5：过度依赖剪藏插件

这个就是老生常谈了，数字囤积不是知识，囤积再多也没有用。

通常的场景是：我们用 Obsidian 网页插件，Readwise 或者 Omnivore 把一篇文章的高亮直接同步进了 Obsidian。系统自动用文章原名生成了标题，把几十条划线文本塞进页面。看着排版精美的页面，我们心满意足地关掉窗口。

笔记是建好了，但 真正的思考并没有发生。我们只是把互联网上的信息搬运到了自己的硬盘上。如果为了检索，还不如不要保存，以后需要时去搜Google 或者问AI。

解决办法是插件收藏的东西，不要进知识库，我现在收藏的东西都是单开一个 Vault 。我很清楚里面的东西全都是「阅后即焚」不会保留下来，即使长期不读吃灰也会定期彻底删除。这些收藏的东西，如果真的有价值，我会转换成有个有结论的标题，存入知识库，而且还不是全文文保存，只提取要点，这就是知识蒸馏（distill）。有了自己的标题，就有了自己的思考。

可是，这会不会太难了？

当真的去尝试这种「论点式」命名法时，我们就会发现一个残酷的事实：Vault 里一半以上的笔记，可能根本提炼不出论点。

而且，每次脑子里冒出一个小火花，都要打开 Obsidian，等那几十个插件加载完，再绞尽脑汁去想一个完美的标题……这种巨大的摩擦力，会让很多人陷入完美主义瘫痪，最后干脆什么都不记了。

如果大家也卡在了这里，我建议的解法极其简单粗暴：别在 Obsidian 里完成所有流程的事。
就像我收藏专门在另一个地方，写在另一个地方，Obsidian 知识库就是一个归档库。一个东西有了价值，有过自己的思考再放进 Obsidian，这时很容易给出一个标题。

把「收集」和「思考」在物理层面上拆开。

最后

所有这一切，看似在说笔记标题，我想说的重点在于「思考」。

收集的目的是为了给思考提供素材，不是为了囤积。收集时，很有可能起不出标题。
分类的目的，是为了决定思考的顺序，层级和结构。不要把单一分类信息作为标题。
蒸馏的目的，就是为了思考出结果，这时应该有标题了。
输出观点的目的，其实是思考成果的复习和再组织，应该会有更好的标题。

一切 AI 总结，高级搜索，或者未来科技如何发展，笔记的作用始终在于强化我们的第一大脑。任何让我们放弃思考的技术，或者代替我们思考的所谓「第二大脑」，都是非常危险的。

而检验或加深思考的最好办法，从命名笔记标题开始。我们可以立刻从现有的 Obsidian 笔记库开始逐条看看，能不能给出一个好标题。

【译】为什么我们解雇了 Jira 和 Slack。

Sun, 29 Mar 2026 10:01:33 +0800

写在前面

无意冒犯，我知道 Jira 和 Slack 有很多拥护者。所以，我今天选择介绍的译文，提到了「解雇 Jira 和 Slack」其实也不是针对这两种特定的工具。我只是看到了一些不同的观点，在不同的领域下，工具和用法的选择实际上是某种「工作文化」的显现。事实上，如果要说差劲管理，哪怕用 Excel + 邮件也能把人逼死。

关于如何更有效的协作，如何发挥团队成员的「自主性」，我觉得可以写一本书出来。但是，我想重点表达的是：对于很多需要创造力的工作，不应该把协作变成流程崇拜，也不应该把沟通交流变成实时的焦虑。这固然不是工具自身的问题，而是管理者选择工具和用法的问题。当做出了一种工具选择，其实就固定了一种工作文化。工具反映了一种意志，是面向监工管理者，还是面向真正的生产者？是提升监管力，还是提升了生产力？很遗憾的是，决定工具选择的人，往往不是生产者，而是管理者。

我个人始终觉得，对于那些有固定套路，需要僵硬流程束缚，需要实时响应的事情，应该逐渐让给 AI 或程序去完成。人不应该是机器里的齿轮。

今天要介绍的文章来自 https://medium.com/@mattlar.jari/we-fired-jira-and-slack-8febdc0a5843；原作者：Jari Mattlar；火箭君翻译并略作编辑。

以下正文。

正文

工具不仅仅是组织工作的手段。它们还在构建行为模式。

三个月前，我做了两个高管团队认为微不足道的决定：用 Linear 取代 Jira，用 Float 替换 Slack。“只是工具而已，”我们的首席技术官说。“请把注意力放在大事上——战略、愿景、招聘。”

他错了。那些“微小”的改动，比起两年间的高管离线会、核心价值观研讨会和团队建设静修，总共对我们公司文化的变化影响更大。

没人会告诉你这一点：工具选择就是你团队文化的一部分。不是你的使命宣言。不是你的全员大会演讲。团队每天使用的那些软件，比任何备忘录或喊任何口号都更能塑造人们的行为。

而且大多数公司在无意中正在建立一种混乱、分心和表面化工作的文化——但他们自己却毫无察觉。

对你公司的隐形税：与工作有关的工作

知识工作者把 60%的时间花在“与工作有关的工作”上——沟通任务、寻找文档、管理不断变化的优先级——而不是他们受雇来做的那种有技术含量、具战略性的工作。

想一想，也许每10个小时里就有6个小时要用在一些破事上。

美国员工专门用于“有关工作的工作”的时间占比为 61%，并且他们认为如果流程改进，每周可以节省整整一个工作日。这不是生产力问题。这是一个伪装成人员问题的工具问题。

残酷的算术：如果你支付一位高级工程师 15 万的年薪，你实际得到的是 6 万的工程产出。剩下的 9 万呢？都被 Slack 漩涡、Jira 考古学和日程拼图给吞没了。

为什么你的“最佳实践”工具正在扼杀文化

Jira是官僚机器？

我们最初采用 Jira 是因为我们认为“那才是真正的工程团队该用的东西”。但六个月内，发生了以下情况：

复杂螺旋：搭建项目变得如此复杂，我们还专门雇了一个人，整天的工作就是“Jira 管理员”。当你的工具需要一个全职的祭司阶层来解释时，你建立的不是一个系统，而是一种宗教。（火箭君注：太贴切了！）

信任崩溃：Jira 那些复杂的工作流传递出一个信息：我们不信任你去管理自己的工作。每个工单都需要审批。每个估时都要验证。每次状态变更都要给出理由。需要大量自定义和复杂层级的团队会选择 Jira——但代价是陡峭的学习曲线以及对小团队而言令人不堪重负的功能。

创新之死：初级工程师不再提出创意，因为为探索创建一个 Jira 工单感觉像是在傻傻地填表。提供摩擦不是一个功能——它是创新文化的杀手。

这个工具并没有在组织工作。它是在制度化一种不信任。

Slack是始终在线的焦虑机器？

典型的 Slack 用户每天登录 9 小时，但主动使用只有 90 分钟。换句话说：7.5 小时的背景焦虑，担心自己错过了什么紧急事项。

感到必须在下班后继续工作的员工，其生产力评分比在标准工作日结束时下线的员工低 20%。然而 Slack 的绿点制造了“在线监狱”——持续不断的压力，迫使人们看起来在线、回应及时、随时可用。

真正的损害？加州大学欧文分校的研究显示，开发者在被打断后平均需要 23 分钟才能重建专注力。记住是：每一次提示。

做个算术：6 次 Slack 打断 = 损失 138 分钟。那几乎是你工作日的一半，用来爬回被人问“快速问一下？”之前的状态。

用户在工作时间平均每天在 Slack 上花费 90 分钟，平台每天发送的消息超过 15 亿条。这不是生产力。这是大型表演——没有实质内容的工作幻象。

Linear：速度即信任

我们改用了 Linear，然后发生了出乎意料的事：工单开始更快地被关闭。并不是因为大家更努力了，而是因为这个工具不再与他们作对。

Linear 的加载速度大约是 Jira 的一半，并且提供了大量键盘快捷键，所以团队在更少挫败感的情况下工作得更快。但速度并不是最大的收获。

真正的胜利是文化上的。Linear 的极简设计传达出一个信息：我们信任你去做好你的工作。没有强制性的 14 项字段表单。没有工作流审批链。没有将注意力引导错位的 sprint 表盘。（火箭君注：这是敏捷管理术语）

使用 Linear 的团队表示他们“非常喜欢使用它”并为它代言，而 Jira 用户通常会回答“还行吧，我想”。这种情感上的差异很重要。当工程师喜欢他们的工具时，这表明领导层尊重他们的时间。

一位工程师告诉我：“Linear 感觉像是由会写代码的工程师打造的。Jira 感觉像是由监督别人写代码的管理者打造的。”

Float：以深度工作为默认

Float 的独到之处不在于功能，而在于理念。它没有把每条信息都当作紧急事项处理，而是将沟通按主题分成不同的收件箱：顾客紧急事件、团队更新、仅供参考。

这一改变带来了巨大的文化涟漪：

专注的许可：工程师可以在指定时间批量处理信息，而不是一直处于被动应对模式。半数办公桌工作者表示他们很少或从不休息，但 Float 的设计让休息成为默认而非例外。

设计即异步：当紧急信息放在单独的收件箱时，紧迫性偏差消失了。团队开始撰写更好、更周到的信息，因为他们知道回复不会是即时的。

不再演示“出勤”：没有了持续不断的绿色状态点，文化从“看起来很忙”转向“把事情做完”。只有 18%的人报告说自己一半时间内都不怎么高产，但平均员工有 60%的时间花在与工作相关的事务上——Float 直接针对这一差距。

数据不会说谎：工具塑造结果

全球员工敬业度在 2024 年降至 21%，生产力损失使全球经济损失达 4380 亿美元。这不是动机问题。这可能是由不合适的工具引发的疲惫问题。

95%的公司表示技术问题影响了生产力水平，包括软件滞后、连接性差以及登录困难。但“技术问题”其实是技术行话，意思是“我们的工具让工作更难，而不是更容易”。

在协作型组织工作的员工感觉自己更有准备应对挑战的可能性高出 79%——是那些不太协作的组织的四倍。但协作并不是拥有 Slack，而是拥有能够支持有意协作而非持续打扰的工具。

一些统计

在使用 Linear 和 Float 90 天后：

平均拉取请求周期时间：下降了 34%
“每周专注工作小时数”：从 8 小时增至 14 小时
下班后消息数：下降 67%
员工参与度评分：上升 28 分
自愿离职率：零（之前按年化计算为 23%）

但最重要的指标是：当我们对团队进行调查时，73%的人表示，工具的更换比过去两年里任何领导层的举措都更改变了我们的文化。

不是我们的新带薪休假政策。不是我们的远程优先规定。也不是我们修订后的薪酬结构。

只是更换了工具。

这比你想象的更重要的原因

大多数公司把文化当成一种软技能来对待——价值观海报贴在墙上、什么欢乐时光、分享宠物照片的 Slack 频道。但文化体现在那些工具每天强制执行一千次的微观行为中。

每次 Jira 为一个简单的错误强制填写十个字段时，它都在说：“我们不信任你的判断。”

每次 Slack 在晚上八点打扰你时，它都在说：“你的个人界限不重要。”

每次你从深入工作切换去回答‘有空吗？’时，它都在说：“被打断是常态，学会忍受吧。”

平均每位每周参加 21 小时会议的开发者，因上下文切换给公司带来的平均损失每年达 5 万美元。那不是夸张——那就是注意力碎片化的代价。

令人不舒服的真相

你无法通过研讨会把文化变好。也无法靠使命宣言做到这一点。

文化是你团队工具为你做出的无数微小选择的累积。而大多数工具的优化目标是管理的可见性，而不是创造者的生产力。

Jira 给管理者仪表盘。Linear 给工程师速度。
Slack 给管理者在线状态指示。Float 给工程师专注的权限。

问题不是哪个工具功能更好，而是哪个工具更契合你想建立的文化。

下一步该做什么

如果你是创始人、工程主管或产品经理，看到这篇文章时，也许在想“是不是我们的问题出在工具上？”，不妨试试下面这些统计：

做一次「打断」统计：记录你的团队每天被打扰的次数。乘以 23 分钟。这就是你们每天的上下文切换成本。
匿名调查你的团队：“这个 [具体的工具名] 是帮助你发挥最佳工作状态，还是在制造关于工作的额外工作？”答案会让人大开眼界。
选一个工具来替换：从小处着手。我们先用了 Linear，然后是 Float。不要贪多求全。但也别把工具更换当成小事。它们其实是伪装下的文化改写。
衡量行为，而不是采用率：别追踪“使用新工具的百分比”。追踪“深度工作小时数”、“下班后消息数”、“关闭工单所需时间”。文化通过行为体现。

你选择的工具并非中立。它们每天都在为你想要的文化投票——或者为你不得不忍受的混乱投票。

残酷的事实？公司文化不是在你的手册里定义的。它在下午 3:47 显现——当一名工程师收到第 6 条 Slack 通知，不得不第 6 次重建 23 分钟的上下文时。

选择尊重专注的工具。否则就继续困惑于为什么你的“企业文化”从未奏效。

效率火箭

有些 App 可以共用 ChatGPT 和 Claude 订阅了，但为什么还要每月多付 10 美元？ 以 Raycast 为例。

AI 订阅、API Key 和 Raycast credits，是三笔不同的账

Bring Your Own Subscription

Bring Your Own Key

Raycast 自带 AI

Raycast 怎么复用 ChatGPT 和 Claude 订阅

多付 Raycast 的钱，买的是上下文和动作

看懂当前窗口，而不是反复复制粘贴

把回答直接写回原 App

让现有订阅获得 Raycast 的工具

把聊天变成项目和定时任务

这层界面也有成本，而且不只是每月 10 美元

Raycast 没有解决最根本的问题

分享到：

Related

「文档即工具」开始成为现实，Capsule 想把 AI 生成的小工具存为「单个文件」。

Capsule 是什么？把小应用和数据放在一起

为什么 AI 让「工具即文档」重新有了吸引力

Capsule 怎么用？先从一个很小的需求开始

本地优先，「单文件」的能力边界

一个 .capsule 文件能不能真的像文档一样流通？

最后

分享到：

Related

【免费教程】Omarchy 入门指南（订阅读者专属 PDF）

订阅以继续阅读

分享到：

Related

Vivaldi 8.2 把 Chrome 扩展带到 Android，桌面上的浏览器工作流也能带到手机上了

Vivaldi Android 怎么安装 Chrome 扩展？

Vivaldi Android 的 Chrome 扩展都能正常使用吗？

最后

Vivaldi Android 官网

分享到：

Related

Workflowy 2026：有了多窗格、表格和日历，它还是那个极简大纲笔记吗？

Panes：解决大纲工具里一个很实际的麻烦

Tables：为什么适合放进 Workflowy？

Calendar 和 Board：让资料关联时间与进度

功能增加之后，它会不会变得太复杂？

最后

Workflowy 官网地址

分享到：

Related

Mac、Windows、Linux 文件怎么互传？我现在用 LocalSend 和 Syncthing

LocalSend：适合临时跨设备传文件

LocalSend 怎么用？

LocalSend 偶尔为什么传不了？

Syncthing：适合多台电脑长期同步文件

Syncthing 怎么工作？

LocalSend 和 Syncthing 怎么选？

但是，同步不是备份

最后

分享到：

Related

【速报】本地优先 的 Notion 替代品 Anytype 为什么要被重写？

为什么要重写，而不继续加功能？

写作和整理功能都会重做

笔记之外的能力

对现有 Anytype 用户，有哪些实际影响？

现有 Anytype 可以继续用，但开发会放慢

这次需要迁移，不能当作普通升级

付费权益如何衔接，还没有定案

最后

参考

分享到：

Related

Notion 能导出，却未必能恢复：真正该备份的不是文件，而是业务连续性

备份不是恢复

这不仅仅是 Notion 的问题

AI 正在改变 SaaS 原来的价值

替代方案可能反而很直接

缩减 Notion 的作用，让它做自己擅长的事，而不是全部

不要让 AI 成为「平台附庸」

本地优先（Local-first）

构建工具链，而不是依赖单一平台

最后

分享到：

Related

有些 App 可以共用 ChatGPT 和 Claude 订阅了，但为什么还要每月多付 10 美元？以 Raycast 为例。

一个 `.capsule` 文件能不能真的像文档一样流通？

【速报】本地优先的 Notion 替代品 Anytype 为什么要被重写？

【速报】Zotero 10 发布了！老牌的研究工具没有盲目加入AI，而是继续在「读PDF」和「高级搜索」上加强。