-
Obsidian 笔记库如何加密同步：用 Cryptomator 配合 Dropbox
笔记库里只有读书摘录时，把它放进 Dropbox，往往是件很自然的事。两台电脑共享一个文件夹，在哪台设备上修改，另一台就能接着看。
但如果里面开始出现合同附件、个人财务记录、尚未公开的项目方案，问题会变得具体：能不能继续用熟悉的 Obsidian 和 Dropbox，又让上传到云端的文件保持加密？
Cryptomator 可以加入这条路径。它在电脑上处理加密和解密，Dropbox 负责传递加密后的文件，Obsidian 则通过解锁后的入口读写笔记。要把这套方案用明白，需要知道文件在哪一步变成密文，以及哪些副本始终留在这条路径之外。
本文以两台桌面电脑之间使用一个敏感笔记库为例。手机上的访问方式另有约束，不能把桌面配置直接照搬过去。
先让笔记经过加密，再交给网盘
Obsidian 的一个仓库，首先是本地文件系统里的一个文件夹。笔记以 Markdown 纯文本保存，附件也是普通文件。换一个文本编辑器，通常仍能读到笔记内容。这种开放性让资料容易迁移，也意味着“放进 Obsidian”本身不会给文件加密。Obsidian 的数据存储方式
假设有一篇
客户报价.md。直接把它放进普通同步文件夹，交给同步工具的就是这份可读文件；在本机先加密，再让同步工具上传，交出去的才是密文。要实现本文的目标，决定性的一步发生在上传之前。Dropbox 自身已经提供传输加密和服务器存储加密。Cryptomator 增加的是由你掌握解锁凭据的一层保护：云端收到的内容需要先经过你这一层解密，才能成为可读笔记。这里以普通 Dropbox 同步目录为前提；部分团队方案另有端到端加密文件夹，应按其实际配置另行判断。Dropbox 的安全机制、端到端加密团队文件夹
Cryptomator 属于客户端加密工具。“客户端”就是你使用的这台电脑。它加密文件内容及文件、文件夹名称，并混淆目录结构。另一台电脑即使已经下载了这些文件，也需要具备解锁凭据才能读到其中的笔记。Cryptomator 的安全范围
可以把它粗略理解为：每份资料分别装进加密封套，再交给 Dropbox 传送。对应关系是资料与文件、封套与加密处理、运输与同步。不过这个类比只解释分工；软件还要处理目录、文件名和持续修改，并非每次编辑都让用户手动拆包、重新封装。
它适合经常读写的笔记，正是因为加密能够嵌入日常文件操作。你不必每写一段话，就把整个笔记库重新打包一次。
理解两个位置，才不会同步错东西
配置时最容易混淆的，是 Cryptomator 加密库的实际存储位置，与解锁后显示出来的位置。
位置示意 这里是什么 主要由谁使用 Dropbox/PrivateNotes加密后的文件及库配置 Dropbox 同步，Cryptomator 管理 解锁后的虚拟盘中的 Notes可以正常读写的笔记视图 Obsidian 打开为仓库 这里有两个“库”：外层是 Cryptomator 的加密库，内层
Notes才是 Obsidian 仓库。名字可以自己取，职责不能混在一起。解锁后，Cryptomator 会提供一个虚拟盘或挂载目录。Obsidian 请求读取笔记时，Cryptomator 按需解密，再把可读内容交给它；Obsidian 写入修改时，数据经过加密，落到外层存储目录。这个机制叫透明加密：应用仍按普通文件的方式工作，加密层处理转换。虚拟盘的工作方式
flowchart LRA[Obsidian 读写笔记] <-->|明文读写| B[Cryptomator 虚拟盘]B <-->|按需加解密| C[Dropbox 本地密文目录]C <-->|同步密文| D[Dropbox 云端]D <-->|同步密文| E[另一台电脑的密文目录]另一台电脑也要用 Cryptomator 解锁，再让那台电脑上的 Obsidian 读取虚拟盘。
虚拟盘并不意味着 Cryptomator 必须在硬盘上长期保存第二份完整明文库；它通过即时加解密提供访问。但应用取得明文后，仍可能自行生成缓存、快照或导出文件。这两件事要分开理解。Cryptomator 的架构说明
因此，Dropbox 应同步外层密文目录，Obsidian 应打开内层解锁视图。 如果把可读笔记另复制一份放进普通 Dropbox 文件夹，那份副本就绕过了加密层。锁定原来的加密库，也不会替你收回它。
把这条路径在两台电脑上走通
初次配置，可以先用几篇无敏感信息的笔记、一张图片和一个 PDF 建立测试库。测试的目的，是看完整流程能否成立，包括附件、链接和换机后的再次编辑。
- 在第一台电脑建立外层加密库。 安装并配置好桌面端软件，在 Cryptomator 中新建加密库，把存储位置选在 Dropbox 的本地同步目录。为它设置独立的强密码，并将恢复密钥保存在库外的安全位置。Cryptomator 本身不承担云端同步，仍需 Dropbox 客户端工作。创建加密库
- 解锁后建立内层笔记库。 在虚拟盘里新建
Notes，让 Obsidian 将它作为仓库打开。复制现有库试用时，应同时检查附件、相对链接和隐藏的.obsidian配置目录；先确认复制来的插件与同步设置，避免顺带启用另一条上传路径。 - 让密文在本地保持完整。 在 Dropbox 中把整个加密库目录设为“可离线使用”，并等待下载完成。“看得见文件名”不等于文件内容已经在本地；仅在线文件可能只是占位符。对这套需要反复读写的方案，保留完整本地密文更容易排除网络和按需下载带来的干扰。Dropbox 的离线文件说明
- 在第二台电脑添加已有加密库。 先让 Dropbox 同步完整目录，再在 Cryptomator 中添加这个已有库并解锁。随后，用 Obsidian 打开虚拟盘里的
Notes。不要在第二台电脑另建一个同名空库，以为名称一样就会自动连接。
接着做一轮往返验证：在第一台新增笔记并引用附件，等同步完成后，在第二台检查文字、图片和链接；再从第二台修改一个段落，让第一台收到变化。还可以在密文完整下载后断网，确认本地能正常解锁和读取；离线期间的修改，要联网同步后才会到达另一端。
这些是依据产品机制设计的验证步骤，不是对任意系统、插件和软件版本的兼容保证。正式迁移时，保留原库与独立备份，直到自己的设备完成这轮验证。
保存、锁库与同步完成，是三个不同的时刻
假设你在电脑 A 改完一份合同笔记，立即合上电脑，走到电脑 B 前继续写。B 打开的仍可能是旧版，即使 A 上的修改已经保存。
原因很简单：本地保存只代表修改进入了本机的文件处理流程；Dropbox 上传和另一端下载，还需要各自完成。Cryptomator 锁定加密库，则是关闭解锁后的访问入口。锁库不会替 Dropbox 完成上传，也不是“现在才开始加密”。 文件在正常写入时已经经过加密。文件访问与锁定、Dropbox 的同步与离线行为
比较稳妥的换机习惯是：在 A 上结束编辑并关闭该 Obsidian 库，确认能够正常锁库，再等 Dropbox 完成上传；到 B 上先等下载完成，再解锁并打开笔记。这样做减少了切换时尚未写完或尚未传完的变量。使用过程中可以持续同步密文，不必每次修改都先锁一次库。
如果两台电脑离线时都改了同一篇笔记，问题就更明显。A 修改了报价，B 修改了交付日期，两个版本都可能包含需要保留的内容。加密层没有足够的信息替你判断应该保留哪句，更不负责把业务含义合并正确。
发生冲突时，Cryptomator 能将某些云端冲突副本以带后缀的可读文件名显示出来，但仍需用户检查版本并合并内容。保留两个版本再判断，比仅凭修改时间删除其中一个更可靠。也不要直接在外层密文目录中挑选看不懂的文件进行“整理”。Cryptomator 的冲突处理
所以，给文件加密之后，错峰编辑、等待同步、处理冲突这些习惯仍然有用。它们解决的是不同版本如何汇合的问题。
保护能到哪里，要看明文在哪里出现
这套路径可以让云端存储的笔记内容和名称保持加密，但文件数量、存储大小及时间戳等信息仍可能暴露。它也不会把已经失守的电脑重新变安全：笔记解锁后，拥有相应访问权限的程序能够读取明文。安全范围与不加密的元数据
对 Obsidian 用户，尤其值得检查的是“文件恢复”。这是核心插件，会保存笔记的完整快照；官方文档明确说明，快照位于库外的全局设置位置。因此，即使
Notes放在 Cryptomator 虚拟盘里，这些快照也不会自动受到该加密库的保护。Obsidian 文件恢复这并不表示 Dropbox 必然拿到了快照，而是提醒我们：云端只同步密文，与本机没有可恢复的明文副本，是两个要求。如果后一个要求也很重要，就需要检查快照设置、导出位置和备份目标，并结合设备本身的保护措施安排恢复能力。
插件同样位于这条边界上。Obsidian 官方说明，社区插件会继承应用的访问权限，能够访问文件和连接网络。如果一个插件读取笔记并把内容发送到外部服务，磁盘上的加密层无法阻止这次发送。敏感库只启用确有需要、来源可信的插件，才与前面的保护目标一致。Obsidian 插件安全说明
迁移还有一个时间上的边界：把今天的文件放进加密库，不会反过来加密昨天已上传的副本。旧的明文库、导出文件和云端历史版本需要单独盘点；Dropbox 的历史恢复能力受方案及保留范围约束，不能把“当前位置已删除”理解为“所有旧副本都不存在”。Dropbox 版本历史
手机端的问题则更多是应用能否取得合适的访问入口。Cryptomator 在 iOS 上可以通过“文件”应用访问解密内容，但“能打开一个文档”并不等于“能让 Obsidian 持续读写整个库”。Obsidian 要处理链接、改名和附件，需要整个仓库的访问能力；官方也未将 Dropbox 列为 iOS 上正式支持的同步方式。Cryptomator 的 iOS 文件访问、Obsidian 跨设备同步说明
Android 也应按具体版本核查跨应用目录访问，不能因为三个应用都能安装，就推断这条链路已经贯通。如果手机是主要写作设备，应先验证手机端完整读写和回传，再决定是否采用这套方案。把文件解密导出到手机的普通文件夹，虽然可能便于编辑，却又产生了需要单独保护和同步的副本。
能打开备份，这套方案才算走完
加密之后，恢复需要同时满足两个条件：数据还在，而且你拥有解密所需的凭据。
在普通密码保护的库中，Cryptomator 先生成库使用的关键密钥，再用从密码计算出的另一把密钥保护它们。解锁时先恢复这些关键密钥，才能读取文件。恢复密钥提供另一条恢复访问的路径，因此必须像密码一样保密，并且不能只存在同一个加密库里。密钥架构、密码与恢复密钥
密码与恢复密钥都不能代替文件备份。一个容易理解的反例是：如果误删同步到了另一台电脑，两端都失去某个文件，恢复密钥不会把已经消失的文件重新生成。反过来，即使完整密文还在，所有可用的解锁凭据都丢了，也不能指望厂商代为重设密码。密钥和数据缺一不可。
还要避免一个误解：更改库密码通常不会把全部文件重新加密。它改变的是对既有密钥的保护；如果旧的密钥文件版本仍可被取得，弱旧密码带来的风险未必随着改密消失。因此，初建库时就应使用足够强且独立的密码。改密机制与历史版本限制
我更倾向于给这类敏感库保留独立、有历史版本的备份。若备份外层密文目录，就在结束写入、正常锁库并确认本机数据完整后保存整个库，包含密文数据及相关配置文件。不要只挑几个看起来像附件的大文件复制走。Cryptomator 的备份建议
恢复演练可以很具体：将一份完整备份恢复到另一个、不参与云同步的位置，在 Cryptomator 中作为第二个库添加并解锁，检查几篇笔记和附件能否读取。官方也推荐通过这种方式恢复文件；它能避免直接用旧文件覆盖正在工作的同步库。从备份恢复文件
对主要在桌面电脑之间使用、需要经常修改的敏感笔记，这套组合有明确价值：Obsidian 保留文件式工作方式，Dropbox 继续传递文件，加密在两者之间完成。代价是多管理一层解锁入口，并认真对待冲突、凭据和恢复。
是否值得采用，可以落到一件具体的事上：换一台电脑，你能否从同步下来的密文读到正确笔记；再换成一份独立备份，能否找回误删的附件。两条路径都走得通，这些笔记才既能日常使用，也有机会在出问题时回到你手里。
-
Logseq DB 版体验：告别本地 Markdown，数据同步与「本地优先」该何去何从？
最近，我下载了 Logseq 最新的公开测试版，也就是所谓的 DB 版。它采用了 SQLite 数据库代替原本的 Markdown 文件库。
我尝试把原来的 Markdown 笔记导入 DB。大约 1000 个节点，导入后用起来依然流畅。有几个节点显示兼容问题，总体问题不大。
性能还没有专门测试，超大库的表现暂时不好下结论。目前既能导入旧笔记，也能直接创建原生数据库图谱。
但是，这次变化让我更在意的是，原来的文件同步方式在未来将处于什么位置。
本地 Markdown 文件给我安全感
我们知道，Logseq 以前的笔记就是一批 Markdown 文件。我可以自己选同步工具、自己做备份，某一篇出问题，就打开那篇检查。即使换个编辑器，正文也能继续读写。
同步时，Markdown 也可能有冲突。两台设备同时改一篇笔记，虽然概率不大，但仍需协调处理。比如同步未完成、错误覆盖之类的情况。
Logseq 的块引用和查询，也未必能被其它 Markdown 笔记软件完整解析。但是只要是 Markdown 文件，涉及个别文件的问题，通常可以局部单独处理。
对我来说，本地优先的吸引力就在于：数据可以放在自己的电脑上，自己信任的云盘上，完全自主掌握。
DB 版的同步，该怎么做？
Logseq DB 版把图谱内容及配置放进
db.sqlite，附件仍单独存放。两台电脑即使改的是不同笔记，除了附件以外，也很可能分别产生一个不同版本的数据库。
网盘能传输数据库文件，却未必（几乎肯定不会）懂得合并里面的节点。直接挑一个「较新的文件」覆盖过去，另一台设备的修改可能就丢了。
我们知道，数据库本身有事务保护，不容易损坏。但是粗暴的文件级别同步就很难说了。我几乎不会再考虑普通基于文件的同步方式了。
过去能逐篇打开、逐篇修复的内容，现在更依赖专门机制。如果出了问题，用户很难直接处理，也许有专门的数据库修复机制，或者就应该多做备份。
如果撇开传统的文件备份，Logseq DB 也提供了官方的 Sync 服务，类似 Obsidian 的官方 Sync，另外，Logseq DB 也支持自托管同步。用户还是有些选择权的。
可是，选择一个熟悉的网盘，与部署维护一套同步服务，对普通用户来说是不同的门槛。如果你执意要使用 DB 版的话，官方服务可能因此成为许多人最现实的选择。
Markdown Mirror
现在的 2.0.2 桌面版还提供 Markdown Mirror，把数据库内容反向生成出 Markdown 文件。但它是单向输出，修改镜像文件不会回写到数据库，也不能把它当成保证完整恢复图谱的备份。
作为一种备份手段，这有一些价值，但是不大。
我们可以这样理解，Markdown Mirror 更像是一种审计，Logseq 能产生出凭证，让你放心 DB 里面有这些内容，由于直接访问 DB 对于一般人来说门槛太高，所以生成 Markdown 文本这种大家能看懂的文件作为凭证，而且查看可以独立于 Logseq 本身，使用任何文本编辑器即可。
最后
我的心情有点复杂。Logseq DB 版应该是在性能上做出了极大进化，原来那种基于分散文件存储的方式，效率肯定是低下的，巨大数量节点的解析一定是痛苦的，现在这个问题算是解决了。
但是，数据的主动权、同步的便利性、基于纯文本的透明性也都失去了。
其实 Logseq 应该参考 Obsidian，MD 文件仍旧保持，同时在不同设备上建立自己本地的数据库索引，这样可以兼顾数据同步和访问效率。
准备迁移的老用户，一定要先用一个副本尝试 DB 版，把同步和恢复的机制弄清楚，再决定是否迁移主库。测试版阶段尤其应该留住原始 Markdown 文件。
如果管理自己数据的能力，越来越依赖专门服务和技术知识，那么即使数据库还在硬盘上，本地优先原来吸引我的意义，也已经打了折扣。希望有个开源且兼顾文件和 DB 版本的 Logseq 出现，在不久的将来，也许 AI 能为我们带来一个。
-
【免费教程】Omarchy 入门指南（订阅读者专属 PDF）
-
Mac、Windows、Linux 文件怎么互传？我现在用 LocalSend 和 Syncthing
如果需要在 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 或其他云服务，而是让各种方案发挥各自长处。
但以前，我们经常把「让另一台电脑得到这个文件」和「把这个文件先上传到一家公司的服务器」看成同一件事情。其实完全不是。逐渐把数据和文件的控制权拿回自己手里，掌握自己的系统，这是我一直在追求，也建议所有人关心的事。
-
把屏幕上的问题说清楚，重新认识 ZoomIt ：放大、标注、长截图和录屏
电脑上有一类操作，很多人每天都在做：看到一个问题，截张图，圈出位置，发给别人。
现在有了 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 里。真的是：效率拉满。
-
收件箱不是仓库：从 Obsidian 到 Todoist 的效率系统反思
最近读到 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 的「选择过多」
我一直认为，「有选择」是一件好事，但极端的「选择过多」却可能成为一场灾难。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 正是这种理念的一次优秀实践。
手册来了
之前说的我会准备了一份 Omarchy 的 上手指南，现在可以放出了。
免费的，但是给真实需要的小伙伴们，需要订阅本博客，才能免费下载。 链接如下。【免费教程】Omarchy 入门指南（订阅读者专属 PDF）
之前准备手册前，给了下面的调查，继续长期有效。我会不定期来看看。
-
笔记与任务的边界正在消失？从 Craft 3.5 的 All Tasks 说起
笔记和任务
笔记和任务之间的分界线已经越来越模糊。
开会时，在笔记中写下一句「周五前把完善的报价单发给客户」；写某篇文章草稿时，有了一个灵感，顺手留一个下篇文章候选的主题；做旅行计划时，又在文档里勾出「订酒店」和「买保险」。这些东西最初看上去很像是笔记的一部分，但写下来的那一刻，它们又变成了任务。
待办事项如果留在原文档里，那么显然上下文很完整，却也很容易被淹没在笔记海洋里；如果复制到 Things、Todoist 或 Microsoft To Do 这类专门的 Todo App 里，确实不会忘记，但列表里往往只剩一句没头没尾的「跟进一下」「搞一下」（我最讨厌这种偷懒的表达），过几天还得回头找它到底在说什么，如要补充或回想上下文的话，还是会额外耗费很多精力。
所以，很多笔记软件走到后来，都会忍不住把手伸向任务管理。Notion 有跨数据库汇总的 My Tasks，Evernote 也早就可以让任务留在笔记中、但同时出现在统一的 Tasks 视图里，Capacities 最近也把「带上下文的任务」做成重点功能。
现在，我个人比较欣赏的笔记文档工具 Craft 终于走出了这一步，Craft 3.5 推出了更复杂的「任务视图」 。
这次最重要的变化，不是 Craft 终于可以在文档里打勾了——这个早就能做到——而是它终于把散落在整个 Space、各个文档、Daily Notes、Page 和 Collection 里的待办，真正收进了一个可以统一管理的地方。
以前的问题：写任务方便，找起来麻烦
Craft 的任务一直有一个很自然的起点：它首先是文档里的一个 Block。
我们可以在项目方案、会议记录、读书笔记或每日笔记里，把一行文字直接变成待办。任务可以设置 Schedule、Deadline 和 Reminder，也可以重复；下面还能继续放说明、链接、子任务甚至更多页面内容。
这套设计很适合真实工作，因为任务并不是凭空出现的，有真实上下文。
比如：「修改文案」通常来自一次产品讨论；「联系供应商」来自一份采购计划；「补一张对比图」来自正在写的文章。让任务留在这些文档里，显然比把它单独抄到一个列表里更合理。这点对于其他类似的笔记工具都完全适用，这里只是拿 Craft 作为一个说明的例子。
不过，任务只要一多起来，文档上下文的优势也会立刻变成弱点。
我们记得自己还有事情没做，却未必记得它藏在哪一篇文档里。过去 Craft 已经有 Inbox、Calendar 和一些按文档查看任务的能力，但如果想确认「整个资料库里还有哪些待办没有完成」，体验仍然不够直接。查询和过滤是一种对用户有一定要求的主动行为。
这也是 Craft 用户社区里长期出现的抱怨：任务可以散落在任何地方，却缺少一个真正完整的总览。很有意思的是，在 3.5 发布之后，我看到 Craft 社区里的一条反馈就是：终于来了。
All Tasks：所有文档多了一层索引维度
Craft 3.5 现在提供四个主要任务入口：
- Inbox：先快速记下来、暂时还没有归属的任务
- Today：今天计划处理的任务，包括之前遗留下来的项目
- Upcoming：未来几天、几周或几个月已经安排好的任务
- All Tasks：整个 Space 里所有文档中的任务
All Tasks 才是这次更新的核心。
它会把散落在不同文档里的任务集中到一张列表中，可以按照文档分组，按照计划日期或截止日期排序，也能使用筛选，并把重要文档固定在顶部。藏在 Page 或 Collection Item 下面的任务，还会带着一个「来源标记」，这个标记提醒我们它并不是一条孤零零的待办。
All Tasks 替笔记建立了一层统一索引。在任务中心打勾、改日期或者调整安排，原文档里的同一条任务也会同步变化；从原文档操作，Today 和 Calendar 里的状态也会一起更新。
这就解决了笔记与任务之间最麻烦的矛盾：执行时需要总览，真正动手时又需要上下文。
我在四五年前的那个创业产品里，就已经强烈建议产品经理，应该做到笔记中的内容可以被另一个视图快速整合，例如：Todo，例如某个标记，又例如某个项目索引……这种 Block 级别引用再整合才是真正的生产力。不过很遗憾，后来产品由于其他原因脱离了设想的轨道，那是另外一个故事。
Craft 3.5 已经做到了一部分，而且有潜力做得更多。实际上，已经有部分产品可以做到了「再索引」「再整合」，但是对用户的要求比较高，一般不太讨好，比如：Obsidian 的 Dataview，LogSeq、Tana Outliner 的「超级标签」，Roam Research 的块级引用和查询……
从文档里来，还要回到文档里去
只有 All Tasks，还不足以让 Craft 变成一套真正可用的任务系统。一个待办列表如果录入慢、改日期麻烦、每次都要打开多个面板，很快就会被用户放弃。
所以这次更新还有一批看起来零散、实际很重要的改进。
在 Craft 的任何位置按下
Command + J，可以直接创建任务；选中一个 Block，也能用快捷键把它转换为任务并安排日期。新的任务窗口会浮在当前工作内容上方，不需要离开正在编辑的文档。多选也终于变得实用了。我们可以一次选中多条任务，批量安排日期、设置 Deadline、完成或移动。Today 视图在取消分组之后支持手工排序，这个顺序还会反映到 Calendar 和 Daily Note 中。
Calendar 这一层也被重新整理。安排了日期的任务会和日历事件、每日笔记放在一起；当天完成的任务会留在当天，形成一份简易的工作记录。Apple Reminders 中今天和未来的提醒事项，也能出现在相关视图中。
日期选择器现在支持自然语言输入，可以在安排任务时顺便设置具体时间的提醒。到了 3.5.2，Craft 又补上了几个细节：任务改期时，原本属于当天的提醒会跟着移动；选中多条任务后，还可以直接把它们生成一篇新文档。
笔记软件为什么都想吃掉任务管理？
从用户角度看，最直接的原因当然是少切换一个 App。加入任务之后，笔记就从静态信息变成了工作现场。
我一直往待办事项的「描述」字段里面填入事件的「上下文」，举个很常见的例子，如果去订酒店，很自然就会在描述字段中把酒店的名称、订单号、日期、地址之类的信息补充进去。任务提醒时，就不用再去翻其他订票 App 或网站查询信息了，直接就可以在待办事项现场进行参考或处理。
但我觉得更深一层的原因是：笔记记录的是「我知道了什么」，任务记录的是「接下来要做什么」。如果一款笔记软件只能保存前者，它就很容易变成一个不断囤积、很少回访的资料仓库。
再举一个常见的例子，会议记录也不只是会后归档，它应该在明天把需要跟进的事项重新推到我们面前；项目文档也不只是背景资料，它应该还告诉我们下一步要做什么；Daily Note、Calendar、Reminder 和文档之间才能开始形成交互循环。
而且到了 AI 时代，笔记和任务的边界会继续变模糊。
AI 可以从会议记录里提取行动项，从研究文档里生成下一步计划，也可以根据截止日期重新安排今天的工作。可是，如果笔记在 Craft，任务在 Todoist，日历在另一个 App，AI 想理解整个项目，就必须跨越多个系统、处理多套权限和数据结构。
把内容、任务和日历放在同一个上下文里，显然更容易讲出「AI 工作空间」的故事。这也是为什么任务管理不是笔记软件随手添加的一个小功能，而正在变成它们争夺工作入口的关键一层。我个人推崇的是，信息可以被统一索引访问，最好在本地，未必是在一个封闭的 App 里，但无论如何不应该被割裂在几个封闭的App里。
这就是，虽然 All-in-one 的诱惑很大，代价也同样明显：软件会越来越复杂，原本只想安静写字的用户，可能并不欢迎侧边栏里不断增加的新入口。而且随着 AI 能力越来越强，我们大脑对上下文的处理可能越来越依赖 AI，笔记软件或待办事项都得向后退一步。
试想，如果我们把所有的行程安排、会议记录以及所有的事情，一股脑都跟同一个 AI 助理说，让它来整理安排事项，那么 AI 就是一个秘书。我们不用记那些事情，不需要使用什么 App 工具；许多公司的管理层就是这样运作的，只不过他们有一个真人秘书罢了。
这就像是个鱼吃鱼的过程，一环想吃掉另一环，最终总有一环想取代我们所有身边发生的事情。所以与其说，笔记和任务的边界变得模糊，不如说对一些人而言所有事情的边界可能都将变得模糊。
Things、Todoist 之类的工具还有用武之地吗？
专业任务管理器经过多年打磨，在快速录入、视图、优先级、标签、筛选、重复规则和细节交互上，仍然更成熟。Things3、Todoist（下图）、TickTick 并不会因为 Craft 多了一个 All Tasks 就突然失去价值，甚至对原本的核心用户群都很难有影响。
待办事项的核心用户是任务已经庞杂到无法轻易管理的那一类人。如果笔记中的待办事项达到那个层级的话，笔记本身也已经膨胀到另一个高度了，可能更适合一个庞大的业务系统，而不是单纯的一个笔记软件或个人待办提醒系统可以解决的。
Craft 3.5 这次改进，其实尤其适合不想维护一套复杂 GTD 系统、只希望别再忘记文档里那些待办的人，但总的来说是一个轻量系统。
如果工作需要团队分派、复杂依赖、精细标签、成熟自动化，或者已经在 Things、Todoist、TickTick 中形成了稳定习惯，还是得靠那些专业的任务管理工具甚至业务系统。就目前而言，这点对其他笔记自带任务管理的工具也同样适用。
最后
总的来说，Craft 3.5 这次的方向，我觉得是非常合理的。大量任务本来就诞生在文档里。把它们重新索引、统一安排，又不丢失原始上下文，是一个自然而然的需求。
All Tasks 做的事情听起来很普通，无非是把所有待办放到一起。但对于文档型笔记软件来说，这恰好是非常棒的「快捷方式」。
而最终不少笔记App其实不仅想吃掉任务管理，还想吃掉一切。在 AI 加持下，这个趋势越发明显，看看 Notion 就知道了。Notion 变成了一个工作台，如果接受它的理念和便利，那么所有一切事情几乎都要经过它，关于这点，我想我会另外撰文讨论一下。
不管怎么样，Craft 是我挺欣赏的一个工具，很期待能看到它有更多关于生产力提升方向的发展。
Craft 官网地址
-
用 AI 处理 Office 文档，未必只有 Copilot：看看 OnlyOffice 带来的选择权
虽然现在已经是 2026 年 ，但仍然有很多公司在使用微软的 Office 系列。大量文档的格式被锁定在其中，成为历史遗留的一部分；也有很多公司和个人早已形成习惯，用 Word 处理文档，用 Excel 处理表格。尤其是表格，历史上 Excel 实在太成功了，成功到变成了不少公司的业务基础。
尽管在线的文档、表格和演示文稿已经很多，但当人们想要一份保存在本地的 Office 文件时，仍然很难不想到微软 Office。
只是， Office 也有自己的问题。大多数人用不到其中复杂的功能，只需要一些基础的处理，却要承担高昂的授权费用。现在微软又推进订阅制，并绑定了自家的 AI，也就是 Copilot。
所以今天只要一说「Office 文档结合 AI」，很多人的第一反应就是微软 Copilot。Word、Excel、PowerPoint 本来就是微软的产品，Copilot 又被直接放进了这些软件里。写一份报告，让 AI 帮忙改写；打开一张表格，让 AI 分析数据；给它一份 Word 文档，让它生成演示文稿，这条路线听起来几乎顺理成章。
而且 Copilot 并不是只有一个聊天框。如果公司已经把文件、邮件、会议和协作都放在 Microsoft 365 里，它可以借助 Microsoft Graph 调用我们有权限访问的邮件、聊天和文档。微软最近还在继续强化 Word、Excel 和 PowerPoint 中的 Agent 能力，Excel 里甚至已经出现了编辑、规划和聊天三种模式。
所以，我并不是说 Copilot 不好，也不是说 Office 不好。我想说的，和此前文章一贯的观点一样，始终是「选择权」的问题。
如果我只是想在 DOCX、XLSX、PPTX 或 PDF 里使用 AI，但更喜欢 Claude、Gemini、DeepSeek、Mistral，或者干脆想在本机运行 Ollama；如果我希望 AI 是可以更换的，而不是跟着 Office 订阅一起打包；那么我还有没有别的选择吗？
这时候，OnlyOffice 提供了另一条很有意思的路线。
它最强大的地方，不是做了一个比 Copilot 更聪明的模型，而是：它允许我们使用任何模型，也就是所谓的 BYOK（Bring Your Own Key）。
我最早想写这篇文章，是因为有个客户在使用 Nextcloud，向我咨询自部署在线 Office 的事情。Nextcloud 本身可以通过连接器接入 OnlyOffice，于是我顺手试了一下，结果发现它提供了非常开放的 AI 集成，这恰恰是微软没有做到的。
OnlyOffice 不只是一个免费的 Office 替代品
很多人第一次见到 OnlyOffice，会觉得它只是一款长得比较像微软 Office 的免费办公软件。
OnlyOffice 桌面版是一套免费的跨平台办公软件，可以在 Windows、macOS 和 Linux 上运行（部分 Linux 发行版会直接预装 OnlyOffice，作为默认的办公套件）。文字文档、电子表格、演示文稿、PDF 和表单被放在同一个带标签页的应用里。桌面版可以离线打开本地文件，源代码也公开在 GitHub 上，采用 AGPL v3 许可证。
截至目前，它虽然还没有微软 Office 那么庞大，但早已不是只能做简单排版的轻量替代品。对于个人、家庭和小型企业这类一般的文档表格需求，OnlyOffice 在功能性上绰绰有余，Ribbon 式界面也让传统微软用户更熟悉，而且还是免费的。
OnlyOffice 有一个很明确的产品取向：把 DOCX、XLSX、PPTX 这些 Office Open XML 格式当作主要工作格式，而这些格式都是开放标准，不是专有格式。
文件格式是否被锁定，一直是我个人很看重的一点。Markdown 之类的格式之所以能大行其道，正是因为格式彻底开放。
也正因为如此，当一套软件已经可以比较可靠地承载日常 Office 文件时，它再接入 AI，才真正有意义。否则 AI 写得再好，文件打不开、格式错乱，一切都是白费。
最重要的是模型选择权
微软 Copilot 的逻辑，是把微软提供的 AI 能力融入 Microsoft 365。它的优势是省事，而且可以和 OneDrive、SharePoint、Outlook、Teams 以及企业权限体系打通。对企业用户来说，考虑到既有投入，这是一条不错的延续路径。
OnlyOffice 的思路则更像一个「AI 插座」。我们可以自己接入 OpenAI、Anthropic、Google Gemini、DeepSeek 等服务，也可以连接任何兼容 OpenAI API 的其他模型——大多数第三方服务和企业内部的定制开发，如今都会沿用这套兼容规则。
更进一步，不同任务还可以分配给不同模型：文本生成用一个，摘要用另一个，图片、语音、视觉分析或代码辅助再各用其他模型，从而在性能、质量和成本之间自行权衡。
比方说，我可以让擅长长文本的模型修改报告，让成本较低的模型做翻译和摘要，让视觉模型理解图片；以后某个模型涨价、降级或者停止服务，也可以随时换掉，甚至在本地算力足够的情况下，直接改用离线的本地模型。
配置路径本身并不复杂，大致就是「插件 → AI → 设置 → 添加供应商」，填入 API Key、选择模型和用途，有时候还要补一个 Base URL。
这种模式当然没有 Copilot 那么开箱即用，对完全不想碰设置的用户，这肯定不算优点。不过想必各位最近也没少折腾这类工具，什么 Hermes Agent、OpenClaw、OpenCode……走的都是同样的 BYOK 模式。
对我来说，工具链一直是需要优先考虑的事情：Office 编辑器是一层，AI 模型是一层，文档文件又是另一层。三者可以协作，却不必永远捆在一起。不该有任何一家同时锁定我的模型、我的工具和我的存储——而这恰恰是很多 SaaS 产品的梦想：尽可能垄断用户的选择权。
AI 已经不只是帮我们续写几段文字
早期的 Office AI 插件，大多是「选中一段文字，然后让 AI 摘要、翻译或改写」。这当然有用，但本质上和把内容复制到 ChatGPT、再粘贴回来没有太大区别。
OnlyOffice 最近两年的变化，是 AI 开始真正操作文档环境。
现在的 AI 插件不仅能在文档、表格、演示文稿和 PDF 编辑器中完成生成、改写、总结、翻译以及语法拼写检查，还能自动生成并编排内容——这就是所谓的 Agent 操作。
例如在文字文档里，我们可以让它：
- 续写一段内容
- 改写当前段落，并保留修订痕迹
- 在批注里解释选中的术语
- 根据内容直接生成一份演示文稿
这和单纯「问 AI 一个问题」完全不同。AI 开始知道我们正在操作的是一份文档，结果也不只停留在侧边栏里，而是可以变成标题、表格、格式、批注、修订和表单字段。
不过需要特别提醒的是，AI Agent 目前仍然带着 Beta 标签。它能做什么，很大程度上取决于编辑器已经开放了哪些工具、所选模型能不能正确调用这些工具，以及当前文件是否足够规范。它还不是万能的 Office「自动驾驶」系统，但方向已经相当清楚了。
把自己的提示词，做成 Office 工具栏按钮
OnlyOffice 最近有一个很实用、却很容易被忽略的功能，是「自定义 AI 助手」。
我们可以给助手取一个名字，写好固定提示词，再选择结果如何回到文档里：
- 只显示建议，不修改原文
- 直接替换选中的文字
- 一边给出提示，一边执行替换
设置完成以后，这个助手就会出现在 AI 工具栏里。以后选中文字，点一下即可，不用反复输入同一串要求。
比如，我可以做几个自己的按钮：
- 精简表达：删除套话和重复表达，但保留原意、数字和专有名词
- 合同风险：只标出可能存在歧义或责任不对等的句子，不直接改写
- 商务口吻：把内部说明改为礼貌、清晰的客户沟通语言
- 提取事实：只提取时间、人物、金额、任务和截止日期
在我看来，这相当于在 Office 里自制微型工作流。对于每天重复处理固定格式文档的人，可能比任何花哨的功能都实用。
本地模型：与 Copilot 最不同的地方
如果只是把 ChatGPT API 接进 OnlyOffice，数据仍然要发送给在线模型。它解决了模型选择问题，却没有自动解决隐私问题。
真正不同的地方，是 OnlyOffice 还可以连接 Ollama、LM Studio、LocalAI 等本地服务。如果不方便把内部草稿发给公共 AI 服务，不希望按用户购买统一的 Copilot 订阅，或者身处没有外网访问权限的环境，本地模型就可以派上用场了。
不过以目前的技术水平，普通笔记本要流畅运行足够实用的本地模型仍然非常非常吃力，对多数人来说还不太现实。但等到时机成熟，本地 AI 会像今天的手机一样普及，真正自主的 AI 也就不再是奢望。
最后
OnlyOffice 最有价值的地方，并不是它能不能在所有功能上正面击败微软 Office。至少目前，它不能；在深度兼容和性能速度上，也还存在一些问题。
这一点我想再重申一次：如果各位深度使用微软 Office，诸如复杂的表格、图表、宏、定制的 VBA 程序等等，那么出于兼容性考虑，微软 Office 仍旧是最好的选择。据我所知，甚至有些私募机构的核心运算都建立在 Excel 之上，这方面微软有着无可撼动的优势。
微软还有几十年的积累，Copilot 又可以调用 Microsoft Graph，把邮件、会议、聊天、组织权限和文档连接起来。对于已经「住在」Microsoft 365 里的企业，这种整合非常强大，也很难复制。
但 OnlyOffice 提供了另一种我更喜欢的结构：Office 文件属于文件系统，编辑器可以替换，AI 模型也可以替换。妥妥的「工具链」模型。
如果说， 微软 Copilot 的目标是把我们更深地带进 Microsoft 365 订阅；OnlyOffice 的强项则是让 AI 来到文档旁边，却不会因此成为文档、账号、模型和工作流的唯一主人，用户仍旧具有选择权，甚至可以替换 OnlyOffice 的能力。
OnlyOffice 官网地址
-
【译】Notion 正在变成一个臃肿的烂摊子？
写在前面
我先声明，我无意打击 Notion 的爱好者和资深用户。Notion 是一款优秀的笔记工具和信息组织工具，甚至被一些小企业当作轻量数据库和业务管理工具使用。虽然在我看来，多数小企业并不适合把 Notion 当作核心业务系统，市面上显然还有更专业、更稳定的选择。
但是走到今天，Notion 似乎已经忘记了初心，越来越像另一个 Evernote。
Evernote 曾经是明星独角兽，早期的用户体验也相当出色，但数据被牢牢锁在云端，随后又开始走大而全的路线，什么都想沾一点。再后来，产品迭代逐渐失去方向，用户受到越来越多限制，价格却不断上涨，最终经历出售和重组，被新一代笔记工具取代，逐渐淡出主流用户的视线。最后留下来的，往往是那些大量数据已经沉淀其中、却又难以迁移的用户。讽刺的是，当年取代 Evernote 的「后浪」中，就有今天要说的 Notion。
另一个问题，是无处不在的 AI。我觉得 AI 本身很有用，但它也毁掉了不少原本简单、克制的工具，让它们不断膨胀，最后变成怪物，有点像《指环王》中的「魔戒」：强大，却也容易让人迷失。说句题外话，我曾经熟悉的 Taskade 也是一款新颖的「小而美」工具，主打整合待办事项、思维导图和项目管理；但在这两年 AI 叙事的加持下，它现在已经变成了一个「怪物」。
也许 AI 本身就会摧毁很多传统软件。传统软件在找不到更好出路时，似乎只能给自己贴上 AI 标签，仿佛这样才能继续活下去。这和当年互联网泡沫时期很相似，许多传统企业硬说自己是互联网公司，再包装出一些与主业无关、近乎天方夜谭的项目。
所以，当我最近看到下面这篇文章时，几乎没有犹豫，就想把它分享给大家。不只是因为文章中的许多观点让我产生了强烈共鸣，也是因为它再次提醒了我：不要重蹈当年 Evernote 用户的覆辙，包括我自己。
以下正文，原作者：Michael Swengel，原文链接：https://medium.com/@michaelswengel/notion-is-turning-into-a-bloated-mess-2240d0e4be1f 火箭君翻译并略作编辑。
正文
很长一段时间里，我是 Notion 的忠实信徒。每当我重装 Windows 或 macOS 系统时，Notion 总是名列我首批需要快速重装的应用清单前列。因为，它保存着我所有重要的笔记。
工作笔记、个人笔记、食谱，甚至还有我的一些财务记录（现在看来，这可能不是个好主意）。
我曾深爱着 Notion。但后来，出于对 Notion 在隐私保护方面相对薄弱的担忧，我转投了 Obsidian 的怀抱。对此我毫无怨言，也毫不后悔。
而在最近几周，看到 Notion 的种种举动，让我更加确信自己的决定是正确的。Notion 已经忘却了它的初心，正在变成一个彻底的「烂摊子」。
Notion 曾经的辉煌
当我还在使用 Notion 时，我纯粹因为它的特质而喜爱它：一个简单却功能强大的笔记工具，完美契合我的思维方式。我对它了如指掌，能够快速、轻松地在其中穿梭。简直爱不释手。
它处理表格、图片和富文本的方式堪称绝妙。我根本不需要多想，只需把各种内容扔进笔记里，然后就可以抛之脑后了。
这正是 Notion 用起来如此令人愉悦的原因。它与我协同工作，而不是与我作对。它懂我想要做什么，哪怕我无法清晰地表达出来。而且，它的呈现方式总是那么优雅美观。
这款应用设计精良，运行流畅，哪怕是在配置极低的「老爷机」上也能跑得动。真是太棒了。
日益增长的担忧
然而，当我开始思考我在 Notion 中存储的所有数据的隐私问题时，我的幻想破灭了。你看，我用它记录了多年的个人笔记、业务信息、内容创意，甚至还有一些我绝不希望被外人窥探的极其私密的数据。
我知道 Notion 声称拥有相当不错的安全性，而且至今仍这么说。但如果没有端到端加密，同样不可否认的事实是：虽然我的数据在静态存储时是加密的，但 Notion 团队依然掌握着所有的解密密钥。
如果别人手里有钥匙，那我把门锁上又有什么用呢？
过去（现在也是如此）没有任何机制能真正阻止 Notion 的内部人员，无论普通员工还是恶意破坏者，在未经我知情或允许的情况下访问我的私人数据。
我无从得知我的私人数据是否真的……私密。
就在那时，我转向了 Obsidian。
迷失方向
从那时起，我一直关注着 Notion。尽管我现在非常喜欢 Obsidian，但 Notion 依然是我的 first love。我内心深处一直期盼着 Notion 团队有朝一日能幡然醒悟，意识到端到端加密绝非微不足道的细节，而以非专有格式存储数据的能力也绝非锦上添花。它们是不可或缺的基础。
然而，Notion 却来了一个急转弯，朝着相反的方向狂飙突进。
Notion 团队没有去打造一个更安全、更面向未来的工具，反而一头扎进了泥潭，将全部筹码押注在人工智能上。
当 Notion 专注于做一个出色的笔记工具时，它确实做到了。抛开安全隐患不谈，我认为没有人会否认这样一个事实：Notion 曾是世界上用于记笔记和整理信息的最佳应用之一。
但现在呢？Notion 似乎想同时成为 ChatGPT、Zapier、Slack 以及一大堆其他工具的集合体，结果却每一样都没做好。
专心做好一件事
我认为古老的 UNIX 哲学在这里非常适用。做一件事，就做一件事，并且把它做到极致。如Doug McIlroy （火箭君注：Unix 早期重要推动者，Unix哲学提出者）所言：「让每个程序做好一件事。如果要承担新的任务，请重新构建，而不是通过添加新功能来使旧程序变得复杂。」
背后的逻辑很简单：避免臃肿，避免不必要的复杂功能，维护好核心产品。
然而，Notion 却把这种哲学揉成一团，扔进了垃圾桶。
Notion 把它曾经做得极好的一件事拿来，试图在上面强加 日历（Notion Calendar）、邮件（Notion Mail 稍后会详细讲）、智能体（Agents）、Notion MCP 等等，这早已远远超出了我们曾经认识并喜爱的那个核心简单的小巧工具。
这就是问题所在。
Notion 不再专注于把一件事做好。它现在变成了一个由各种产品拼凑而成，而且拼凑得支离破碎的生态系统。
是平台还是工具
在我看来，Notion 似乎正试图超越一个简单工具的范畴，膨胀成一个臃肿的软件平台，靠着胶带和梦想把一系列功能和连接器强行拼凑在一起。
Notion 已经不满足于仅仅做一款笔记软件了。它想要掌控你整个数字生产力生活。而这，是我绝对无法安心接受的。
画地为牢，彻底锁定
我跳船到 Obsidian 的一个重要原因，是内心始终萦绕的恐惧：如果 Notion 明天就消失了，我的数据会怎样？
诚然，这不太可能发生，但也并非绝无可能。软件的兴衰更迭，在软件世界里是再正常不过的事。
把时间（甚至可能是金钱）投入到一个我无法保证它不会突然消失并带走我所有数据的软件中，这让我感觉很不好。（火箭君注：如果早10年，这就是我面对 Evernote 一样的恐惧，而且事实证明，有些担心早晚会发生）
我很高兴看到 Notion 坚持了这么多年，但我的这种担忧也同样持续了这么多年。当你使用 Notion 套件时，你就是在选择被锁定在一个以非标准格式存储数据的系统中，而且存储位置完全不受你控制。
换句话说，你的数据任由 Notion 摆布。如果 Notion 宕机了怎么办？如果你的账户被盗了怎么办？那你就完蛋了。
这理应让大家感到害怕。反正它已经足以让我吓得弃船逃跑了。
受够了 AI 的狂轰滥炸
我累了。我对这种持续不断的 AI 推销感到无比厌倦。AI 越来越像是一个企业界的流行语，被肆意地撒在任何东西上。
我已经受够了。
但 Notion 呢？Notion 正在全力押注 AI，将自己标榜为「为你工作的 AI 工作空间」。让我作呕。
当我最初接触 Notion 时，我并不是冲着 AI 来的。我开始使用它，是因为 Notion 在记笔记和存储信息方面表现得极其出色。
后来他们添加了 AI 功能，并推出了付费的 AI 工具，我并不介意。事实上，在当时，我还对它们的 AI 能力感到印象深刻。感觉还挺不错的。
但那是在 Notion AI 仅仅作为 Notion 用户的得力助手的时候。而现在，它喧宾夺主了。
今天呢？这个是 AI，那个也是 AI，到处都是 AI。以至于 Notion 现在被冠以「AI 工作空间」的名号。
这感觉就像是 AI 发起的一场恶意收购，而不是 AI 对工具的增强。它让 AI 感觉像是一种接管了系统的病毒，不再像过去那样，是一个在我不需要时懂得乖乖让路的有用助手。
我甚至无法在不同的 Notion 工作空间之间切换，因为中间总是会弹出一个 Notion 智能体（Agents）的广告。
当然，当我进入工作空间后，我看到了什么？更多的 AI 推销。
什么 「AI 会议笔记」？Notion，你能不能别挡道，让我按照自己的方式创建笔记？「新建 AI 会议笔记」以及它上方「连接你的日历」的提示就那么杵在那里，白白占用空间。呵呵，真酷。
但等等！还有更多。在那下面，我们看到了什么？
智能体（Agents）。同样在占用空间。
过去，所有这些空间都填满了我自己的笔记和页面。现在呢？它们被挤到了屏幕的一半以下，只为了给这些垃圾腾出地方。
幸运的是，点击三点菜单并选择“隐藏部分”，可以将这两个板块隐藏起来。
但即便如此，它们默认存在的事实依然令人反感。Notion，你并没有让我对转投其他软件感到后悔。这真是糟糕透顶的用户体验设计。
重新审视担忧
需要极其明确的一点是，这绝不是在讨论 Notion 或其周边工具是否优秀。完全不是。
当我抛弃 Notion 时，并不是因为它是一个糟糕的工具。它过去不是，现在也不是。
事实上，即使在转投 Obsidian 之后，我依然怀念 Notion 的某些功能。Notion 和 Obsidian 有很多重叠之处，但如果我说我不喜欢 Notion 处理某些事情的方式，那我一定是在撒谎。
但工具的强大与否并非问题所在。依赖它们的明智程度才是。
我很高兴看到 Notion 为所有依赖它的人继续取得成功。真的。但它的扩张只会加深我的担忧。
只要 Notion 仍然是一个以专有格式将数据存储在你我都无法控制的位置的工具，那么无论这些工具多么优秀都无济于事。
完全依赖它们是充满风险的。而在我看来，Notion 的扩张恰恰是在鼓励人们这样做，将自己的数据投入到他的「黑洞」中。
万物皆有终时
关于这一点，最好的例子莫过于直接看看 Notion Mail。回溯到 2024 年，Notion 收购了 Skiff (上图)，这是一款隐私优先、端到端加密的电子邮件客户端。
收购完成后，Skiff 的所有服务（邮件、云盘和日历）都被关闭了。
2025 年 4 月，Notion 推出了 Notion Mail，它实际上只是 Gmail 的一个收件端。
而现在，Notion Mail 也要关闭了。
Notion 关闭 Notion Mail 的理由是什么？为了专注于 AI。他们一本正经地声称“超过一半的 Notion Mail 用户在管理邮件时，甚至从未打开过他们的收件箱。”
就算这是真的，那剩下的将近一半用户呢？
那篇公告接着写道：“因此，我们将全力以赴，使用智能体（Agents）来运营你的收件箱。”
不。不。绝对不行。不。这主意糟透了。
在我看来，这恰恰说明 Notion 宁愿成为一个 AI 工具，也不愿成为一个旨在满足普通用户需求的生产力套件。
尾大不掉，难以信任
早在 Notion 还只是一个笔记工具的时候，我就对它存储数据的方式感到担忧。我至今仍有这些担忧。只是今天更甚。
但现在，既然 Notion 正在全力押注 AI，并且为了实现这一目标，甚至不惜扼杀像 Notion Mail 这样相对较新的产品……我不得不怀疑，我到底还能对 Notion 各种繁杂的产品抱有多大的信任。
我怎么知道核心应用剩下的部分，有朝一日不会以 AI 智能体的名义被吞噬？我能得到任何不会发生这种事的保证吗？
听起来，Notion 团队似乎对 AI 的热情远胜于服务其长期用户。当然，他们会否认这一点，但事实胜于雄辩。
至少在我看来是这样。
照目前的情况来看，我不信任 Notion。在他们全力押注 AI 之前，我不信任它，是因为它缺乏端到端加密，而且我无法将数据存储在我拥有并信任的地方。现在，我不信任它，不仅因为上述原因，还因为 Notion 已经膨胀得失去了自我，而 Notion Mail 的终结已经让我们看到了最初的端倪。
我为自己抛弃它而感到庆幸的理由正在不断增加。
Notion 的核心产品过去是，现在依然是一个好工具，但它已经变得如此臃肿，充斥着 AI，并且持续存在隐私隐患，以至于我认为我无法再向任何人推荐用它来处理任何重要的事情。
说实话？这让我感到悲哀。
至于现在，我会继续使用 Obsidian，保持我的笔记备份并进行端到端加密。对于像我这样一个见证了太多系统兴衰更迭的人来说，这才是最重要的。
高效搞定事情，尽情享受生活
