-
Ulysses 又能买断了？199.99 美元永久授权，软件订阅制开始退潮？
看到 Ulysses 又有了买断选项，我第一时间想到，软件付费模式的钟摆，从最早的「买断」摆到「订阅」，现在似乎又摆回到「买断」上来了。
Ulysses 是一款老牌写作工具。远在 Obsidian 这类 Markdown 工具流行起来之前，就已经受到不少写作者的推崇。那时候，使用 Ulysses 甚至有点身份象征的感觉，仿佛事业有成的人必配一支名牌钢笔。Ulysses 的价格一直不便宜，早期采用买断制，后来转向订阅，如今也可以通过 Setapp 使用。
可是一款写作工具，每个月或每年都要交一笔不小的续费，哪怕我一个字也没写。这总让我觉得，自己像个佃农。
截至 2026 年 10 月 9 日，Ulysses 在 App Store 已经重新提供买断选项，同时保留订阅。价格依旧不菲，在如今写作工具层出不穷、花样天天翻新的年代，这个价格仍然让我有些难以接受。
本文所有价格均为美国市场的美元标价，以 2026 年 10 月 上旬为准；历史价格另行注明。
2017 年，Ulysses 为什么从买断转向订阅？
Ulysses 转向订阅的时间很明确：2017 年 8 月 10 日。当时公布的美区价格是 $4.99/月，或 $39.99/年，一份订阅覆盖 Mac、iPad 和 iPhone。这是当年的价格，并非现在的月费。当年公告
当时的理由很明确：老用户一次付款，却持续获得更新，后续开发就得依赖新用户的收入。大版本发布时销量上来，热度过去又回落；但系统适配、问题修复和新功能开发，却不能跟着销量一起停下来。订阅在 Ulysses 看来，可以为持续开发提供更稳定的收入。
这个理由，我完全能理解。
软件需要维护。操作系统更新以后，一款昨天还好好的 App，今天可能就出了问题（尤其是macOS ，有时需要新版重新适配）。我们平时感受不到的稳定，背后也有人在持续投入维护。
当年的旧买断版也没有立即失效。官方说明，它们停止销售后仍可完整使用，并适配了当时的 High Sierra 和 iOS 11，只是未来的新功能会进入订阅版。
但站在用户这边，感受仍然可能是：我已经买过这个工具，想跟着它继续走，却需要重新接受一套长期付款的关系。
现在 Ulysses 重新提供买断，这段历史自然会影响老用户的判断。新用户大概以为捡了便宜，老用户就可能还会多想一想：这次真的靠谱吗？
Ulysses 买断价格 199.99 美元，永久授权包含什么？
这次最新的永久授权，覆盖当前 App Store 上的 Ulysses，以及支持的 Mac、iPhone 和 iPad 版本。官方明确说明，授权包含当前这款 App 未来的更新，包括大版本更新、修复、改进和新功能。官方授权说明
所以，不能把它理解成只买下今天这个版本，下一个大版本就一定还要重新交钱。至少从目前公开的官方条款来看，并不是这样。
同时，官方也保留了现实边界：不保证无限期增加新功能，未来更新可能要求更新的操作系统；兼容性维护和问题修复，会在合理可行的范围内持续提供。永久授权有明确的对象，也有维护承诺的范围。另外，永久授权本身不提供试用期，如果想先体验，可以使用订阅方案提供的免费试用。
再看具体价格。美区永久授权为 $199.99，常规订阅为 $39.99/年，或 $5.99/月。永久授权价格来自美区 App Store，常规订阅价格也与官网定价页一致。
$199.99 ÷ $39.99，约等于五年。 假设常规年费不变，而且一直使用，买断金额相当于约五年的年费。这里比较的是连续年付，不是只在需要时订阅几个月。
美区 App Store 还列有 $29.99/年 的套餐，但公开页面没有说明适用资格，不能把它当成所有新用户都能拿到的价格。如果你实际享有这个年费，$199.99 相当于约 6.67 年 的订阅费用。年费折扣越大，买断在价格上追平订阅所需的时间反而越长，因此还是应该按自己的实际续费金额计算。
如果 Ulysses 是你每天工作的主力工具，承担长文、书稿和资料整理，买断可能很合适。如果你一年只打开几次，或者正在尝试其他写作方式，「以后不用续费」也未必值得提前付出 $199.99。
AI 让老工具更难靠习惯收租
我觉得，这次变化值得放进一个更大的背景里看：AI 和各种新产品不断出现，正在考验我们对旧工具的忠诚。
过去，熟悉一套软件、整理好文库、养成工作习惯之后，换工具是件麻烦事。每年再付一笔钱，很容易被解释成维持现状的成本。
现在，我更关心另一件事：完成同一份工作，还需要原来那一整套工具吗？
假设一个写作者，已经在 AI 工具里整理材料、推敲结构和修改句子，最后只需要一个地方保存、排版和导出。那么，他给写作软件分配的预算，就可能与过去不同。即使旧软件依然好用，它在整套工作中的位置也可能变了。
当然，流畅的编辑体验、可靠的文稿管理，以及自己多年建立的习惯，仍然有价值。每天靠 Ulysses 完成工作的人，完全可能觉得年费值得。
但品牌需要重新证明这种价值。过去喜欢过它，用它写过很多文章，并不能自动证明今天还值得继续付费。
用户的预算不会因为新工具越来越多，就越变越大，更可能的情况是：削减一部分，补贴另一部分。 比方说，削减了某个写作工具的预算，转而补贴 ChatGPT。
这也是我对「用户变得更理智」的理解：付费时开始看实际使用频率、节省了多少时间、解决了什么问题。情怀或许可以让人多留一阵，长期账单终究还是要看实际用途。
我不能据此断言，Ulysses 就是被 AI 竞争逼着增加买断选项。官方没有给出这样的解释。但从用户预算如何分配来看，我认为旧产品依靠品牌和惯性持续收租，会越来越难。
有意思的是，我觉得同样的变化也一样会让「买断」变得更难。既然明年可能换工具，为什么要现在预付相当于约五年常规年费的金额？Ulysses 增加了付款选择，却仍然需要回答那个老问题：未来几年，我为什么还要用你？从厂商角度看，这也像是把用户未来多年的付费提前一次性收回来。
钟摆荡回来以后，软件付费模式还会怎么变？
我不觉得，接下来的方向会是所有软件一起回到过去的买断制。
我的判断是，传统工具依靠用户惯性维持订阅收入的好日子，正在过去。尤其是把成熟功能统统放进年费里，期待用户因为习惯而一直续下去，这种模式会越来越受到挑战。
更何况，连一批早期的 AI 工具，现在想靠订阅活下去也变难了，因为大公司已经把类似服务集成进现有的 AI 客户端。传统工具还想争取同一笔预算，就更难了。
厂商已经在调整。Ulysses 让买断与订阅并行；Notability 也在 2026 年 7 月重新推出了 Classic 一次性购买方案，并在官方公告中明确回应了用户对额外月费的厌倦。
这些变化让我觉得，钟摆虽然在往回摆，但最后停下来的地方，未必和从前一样。
未来可能出现更多组合：基本工具一次购买，值得升级的新功能另外付费；在线服务按需订阅，AI 消耗按用量计费；或者付一段时间的更新费，停止续费以后仍能使用已经买到的功能。
这些办法有些早已存在，新的变化可能来自它们如何组合，以及用户愿意把钱花在哪一部分。
我欢迎 Ulysses 增加买断选项。它至少承认了，有些用户愿意付钱，却不愿意增加一笔长期循环账单，也不愿被长期锁定在一种使用习惯里。
但我也不会因为看到「永久」两个字，就立刻把钱交出去。还要看自己究竟用不用得上，以及是否愿意相信它会继续值得用。
订阅也好，买断也好，最后还是要靠产品赢得信任。
不要过度相信「永久」。除非在你自己手上，否则没有东西是真正「永久」的。
说一句 Ulysses 可能不爱听的话：只要确实有足够多的用户需要它，AI 正在让个人和小团队复刻这类工具的核心功能变得越来越容易。
已经有团队用 AI 复刻 Adobe 家族的产品了（下图）， 而且免费发布。 你说一个文字编辑器的复刻又有什么难的呢？
当然，复刻功能不等于能轻易替代多年积累的体验和维护。但这种可能性，本身就会改变传统软件的竞争格局。
也许，这也是许多其他工具产品将要面对的未来。
-
【速报】Obsidian 1.14 正式发布：库外 Markdown、Bases 看板与多色高亮
Obsidian 又迎来了一次挺实用的大更新。
2026 年 10 月 5 日，Obsidian 1.14 正式向所有用户开放。桌面端的重点是直接打开库外 Markdown、Bases 看板和多色高亮；移动端则带来了 iOS 快速记录等改进。
其中，我最喜欢的，是那个看起来再普通不过的功能：终于可以直接打开一个 Markdown 文件了。
库外 Markdown，终于可以直接打开了
以前想用 Obsidian 处理一份临时下载的
.md文件，通常得先把它放进库，或者把所在文件夹打开成一个库。所以一般我都会另外安装一个 Markdown 编辑器，例如 MarkText，Tyopra，只是为了看一下，临时的，或不在Obsidian 库里的 Markdown文件。现在，Obsidian 桌面端新增了
Open file from outside the vault…命令，可以在当前窗口直接打开库外 Markdown。而且，Obsidian 也会出现在系统的 “打开方式” 菜单里，可以设为
.md文件的默认打开程序。我测试了一下， .txt文件 竟然不可以，只支持 markdown 文件。macOS 还加入了 Quick Look 支持，不启动 Obsidian 也能快速预览 Markdown。
这对临时阅读、修改下载件，或者查看项目里的 README，都很方便。已经习惯 Obsidian 编辑界面的用户，现在可以少安装一个 Markdown 工具了。
不过有一说一，现在这个模式，也有缺点，它只是解决了可以打开的问题，但远非完美。因为，每次双击打开外部 MD 文件时，Obsidian 还是会 默认打开上一次的库。 只是为了将外部文件展示出来，就需要打开整个库，而且那个库和临时打开的文件未必有关。 我觉得，应该有一个机制，让 Obsidian 打开外部文件时，处于一个没有库的状态，然后让用户可以快速决定将文件扔到某个库里，或者索性临时编辑，用完就走。
Bases 加入原生看板
Bases 是 Obsidian 用来整理笔记和属性的核心插件。这次新增了 Kanban 看板视图，可以把笔记按属性分成不同列。
比方说，博客选题按“待研究”“写作中”“已发布”排列。使用可编辑的笔记属性分组时，把卡片拖到另一列，就会更新对应属性。看板里的卡片仍然对应笔记文件，数据也继续保存在本地 Markdown 及其属性中。
在其它在线表格应用里，表格转换成看板已经是标配应用了，如今Obsidian将这项功能带到了 本地Markdown 笔记数据库里面来。 和之前大家以为的 用户可以构建任意看板不同，这次更新是基于 Bases 的，所以本质上还是一个 表格的视图。 Obsidian 已经将起锚定在 Bases 上了，不像以前的Canvas 那样是天马行空的全新类型。
同时，新的 Group 菜单可以调整分组顺序、隐藏或添加分组。表格、卡片和列表视图也支持折叠分组。
如果平时已经在用 Bases 管理笔记清单，这次就多了一种更直观的浏览方式。
高亮文字，现在有六种颜色
我之前专门介绍过 高亮语法，以及 Obsidian 注释插件。 现在 Obsidian 官方也开始重视起来了。
Obsidian 1.14 加入了红、橙、黄、绿、蓝、紫六种高亮颜色。可以从格式菜单选择，也可以在高亮内容开头加入对应的彩色 Emoji。输入==时，编辑器会提示颜色选项；在实时预览中，还能点击色块调整颜色。对于习惯边读边标注的人，这个小功能超级实用。比如用黄色标重点、红色标疑问，回头整理时更容易区分。
iOS 快速记录，不必等整个库加载
移动端最值得关注的是 Quick Capture。
在 iOS 26 上，可以通过锁屏、控制中心、主屏幕小组件或快捷指令直接记录，不必先等待资料库加载完成。记录位置可以设为新笔记、当天的日记、已收藏笔记或指定笔记，也支持可选模板。
随手记一个想法时，现在可以 少等几秒、少点几下了。
升级时，记得重新下载安装包
有一点需要特别提醒：**要使用桌面端的库外文件打开功能，需要从官网下载最新安装包并重新安装，不能只做应用内更新。
我觉得这次更新的几个重点都很贴近日常使用：临时文件更容易打开，已有笔记更方便整理，手机上的想法也更容易及时记下来。
对于已经在用 Obsidian 的朋友，非常值得更新看看。
-
从 Evernote 新增的 PDF 编辑功能，到 免费开源的 Stirling PDF：我为什么更想搭自己的工具链
我许久没怎么关注 Evernote，最近偶尔打开，发现它又加了一批新功能，其中比较显眼的是 PDF 编辑。这原本更像 Adobe 家族工具的领地，这几年已经成了各种免费工具的常客，现在又被放进 Evernote，感觉像随订阅附送的赠品。
我觉得大多数人对 PDF 的操作，用不到那些专业特性，大概也就是文字编辑、拆分合并、页面整理、批注签名这类常规功能。
现在 Evernote 把大多数常规 PDF 操作放进了桌面端和网页端。对本来就把 PDF 存在 Evernote 里的人，这当然方便，文件不用从笔记里拿出来，就能继续处理。
看完这次更新，我反而更想聊聊另一款免费开源的 PDF 工具 Stirling PDF，以及另一种组织个人工具的方法。
总的来说，外面已经有不少成熟的免费方案。为了处理一份 PDF，我们未必需要把更多工作搬进某个封闭的商业笔记平台。
对个人资料管理，我更信任围绕通用文件搭起来的工具链：每个工具负责一段工作，需要时接上，不合适时换掉。
这条路一开始要自己做一点整理，但用得越久，价值越明显。
功能越来越全，入口也越来越集中
首先，我能理解 Evernote 的产品方向。资料既然已经在笔记里，顺手编辑 PDF，也完全合理。
目前 Evernote 较新的功能，包括 PDF 编辑、日历增强和 AI 处理，都属于这种「顺便一做」的入口。每一种功能，都在给现有订阅多加一个付费理由。这是让用户走进平台、并且留下来的一种办法。
假设我每天都要剪藏网页、写笔记，但每个月只合并两次 PDF。新增的 PDF 功能当然有用，可它对我的价值，只对应那两次操作，并不会自动让一整套订阅更划算。
何况，PDF 处理要求较高的人，多数在接触 Evernote 之前就已经有熟悉的工具。笔记软件再加一套，反而要改造现有工作流，连带改掉一些已有习惯。
尽管如此，Evernote 加这类功能仍然合乎产品逻辑。因为「便利」，或者说「低摩擦」，会慢慢改变人的习惯，最终把用户留在 Evernote，形成新习惯，想要再离开就不容易了。
也正因为如此，我对「一个 App 解决很多问题」的观点始终有所保留。App 把入口集中起来，也可能把原本可以分开处理的需求绑在一起。以后续费、换软件、迁移资料，都得重新考虑整套安排。
很多时候，这种绑定是不得已的，因为 App 有自己的文件格式，或封闭的云端存储。相比之下，PDF 和 Markdown 这类通用格式，就很适合独立出来，不必过度依附某个平台。Evernote 的笔记是自有格式，存储也在云端，再集成 PDF 编辑，用意很明显：希望用户把资料尽量都放进 Evernote 的平台。
免费 PDF 工具已经能接下很多日常工作
先讲讲 Stirling PDF。它可以理解成一个专门处理 PDF 的工具箱，免费开源，也有面向企业的付费方案。
它覆盖合并、拆分、调整页面、格式转换、压缩、OCR 等常见需求。比如收到一份扫描件，想把横过来的页面转正，去掉空白页，再把补充材料合进去，最后生成一份方便发送和归档的 PDF，这些都易如反掌。
Stirling PDF 目前有 Free 方案，个人在本机使用已经够用，也有面向团队的付费服务。
如果只是偶尔改一改简单 PDF 里的文字或对象，可以考虑免费的 LibreOffice Draw，改完再导出 PDF。我们之前介绍过的 ONLYOFFICE，也是不错的选择，可以做轻量 PDF 编辑。
免费但不开源的 PDF 工具就更多了。功能更强的商业 PDF 软件里，也有一次性买断的，同样值得考虑。
按自己的 PDF 编辑需求，完全可以找到很丰富的选择，不必买下一整套用不到的能力，也不必锁在一个平台上。
通用文件是基础，再把工具接起来
所谓工具链，并不是很复杂的概念。
以一份项目资料为例，我会这样安排：原始 PDF 放进项目文件夹，用 Stirling PDF 整理出一份阅读版，在笔记里记下判断，并链接到对应文件，需要交付时再输出一份发送版。
原件、整理后的文件和自己的笔记，各有位置。工具之间传递的是文件，不必依赖平台刚好做了集成。依赖平台的问题，除了锁定，有时更像一种平台「恩赐」：平台不给某个功能，这个功能就不存在，这时再接第三方工具，反而更麻烦。
自己选工具、再组合，就没有这个问题，除非某一类工具本来就没什么选择。PDF 处理和笔记工具并不是选择太少，而是选择太丰富，更没有必要依赖平台集成。
诚然，挑选工具、整合工作流是有成本的。但整理规则由自己掌握，更换 PDF 工具时，通常不用跟着重建整套资料系统，因为用的都是开放格式。反过来，迁移封闭平台的资料就痛苦得多。Evernote 笔记是这样，Notion 也是这样，有些信息甚至会丢掉，最后只剩基础内容。
最后
对多数个人用户，一套熟悉的笔记工具、一个清楚的文件目录，再加一个 PDF 工具，已经足够开始。等高频动作确实需要自动化，再去加连接，或换更专业的商业工具。而一个 可替换，可迁移的「工具链」的思路，才是每个人值得投资的理念。
最后，顺便一说，Evernote 的订阅其实并不便宜，我觉得，Starter版其实很薄弱，Advanced 才是个人可用的选择。最近的种种更新很像在证明它自己值这个价钱。为了证明这点，于是往里面塞了一堆功能。在 AI 盛行的年代，单个工具以后可能会变成溢价较弱的一环，AI 随时可以按需要定制工具或工作流。而这才是我期待的时刻，因为它意味着彻底摆脱了平台锁定，把工作完全放进自己的工具链里。
-
有些 App 可以共用 ChatGPT 和 Claude 订阅了，但为什么还要每月多付 10 美元？ 以 Raycast 为例。
现在的 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 生成的小工具存为「单个文件」。
我这几天看到一个让我眼前一亮的项目，叫做 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）
-
Vivaldi 8.2 把 Chrome 扩展带到 Android，桌面上的浏览器工作流也能带到手机上了
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 官网
-
Workflowy 2026：有了多窗格、表格和日历，它还是那个极简大纲笔记吗？
如果你已经很多年没有打开 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 官网地址
-
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 或其他云服务，而是让各种方案发挥各自长处。
但以前，我们经常把「让另一台电脑得到这个文件」和「把这个文件先上传到一家公司的服务器」看成同一件事情。其实完全不是。逐渐把数据和文件的控制权拿回自己手里，掌握自己的系统，这是我一直在追求，也建议所有人关心的事。
-
【速报】本地优先 的 Notion 替代品 Anytype 为什么要被重写？
被称作 「本地 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 的重写更像是增加了一个脚注。
参考
高效搞定事情，尽情享受生活
