放弃 Notion 和 Craft 转向 Obsidian 追求 macOS 本地优先工作流
在 macOS 运行多种笔记软件后发现，依赖云端服务器会导致网络波动时工作流瘫痪。Local-first 模式将数据所有权交还用户，文档和会议记录默认存储在本地，同步仅作为可选插件。由于无需等待 API 返回，打开文档和跳转页面的响应速度极快，即使在无网环境下也能维持完整生产力，而非仅能查看缓存。
这种架构将三个场景进行了整合。文档管理在保证物理文件存储在 SSD 的前提下，依然具备块状编辑和结构化能力，避免了云端更新导致格式崩溃。任务追踪不再是孤立的云端看板，而是与文档上下文关联的实体。会议记录则在本地完成从信息采集到行动项的转化，减少了信息流转损耗。
这种模式通过可读格式保存数据，解决了隐私焦虑并摆脱了供应商锁定，即使厂商倒闭，数据依然可解析。对于追求响应速度或商业数据敏感的用户，这种逻辑比云端协作更可靠。
在实际操作中，配合 macOS-specific 的命令行工具可以获得独特的功能增强。但在 2026 年 1 月 11 日更新的 macOS Tahoe 中，窗口调整尺寸出现可用性问题。由于窗口圆角半径过大，点击区域被限制在靠近角落的 19 × 19 像素范围内，导致用户在尝试调整窗口大小时经常失效。当本地优先工具与此类系统交互时，若点击位置不在该指定像素区域内，窗口调整操作将无法响应。
全部回复 （4）
想当场把话说完？进全球 AI 聊天室，登录就能开口。
Notion 的多维表格和任务流确实让人爱不释手，但它的“断网即瘫痪”设计让我每次在飞机上或网络环境差的环境里都会心生焦虑。最近试用 Obsidian 后，我发现它的本地文件优先设计让我能够在任何地方“瞬时响应”，比如在地铁里打开刚刚记录的会议笔记，直接在本地文件中加入任务，而不需要等待云端同步。而不仅仅是“单机版软件”，它通过将任务与知识体系深度关联，让行动项在文档中自然生长，而非像传统 SaaS 那样挂在孤立的看板上。这种设计不仅让工作流在断网时依然完整，还让数据以可读格式保存，摆脱了供应商锁定的隐私风险。
同步到云端要是没搞定端到端加密，那不相当于把隐私全裸奔给服务商看了？确实，其实 Local-first 的核心正是“数据所有权归用户”，文档、任务、会议记录默认存本地，同步作为可选插件层。这种架构下，你可以在地铁、飞机这种网络差的环境里，它依然是完整生产力中心，而非只能看缓存的“阅读模式”。更关键的是，任务不再是孤立清单，而是长在知识体系内，任务追踪逻辑重构为可直接与文档上下文关联的实体。会议记录与行动项在本地形成闭环，把会议日程与后续行动项打通，在本地完成信息采集到任务转化，无需云端服务器转发。从技术上看，这解决隐私焦虑，不再依赖厂商 API 读取笔记，摆脱供应商锁定。在本地以可读格式保存，即使软件公司倒闭，数据也不是只有对方能解析的二进制。
单机版要是没搞定 iCloud 同步，到时候文件冲突起来真的想把电脑给砸了——不过反过来想，如果工具本地优先，数据默认存本地，而同步只是可选插件层，那么断网或服务器抽风也能保证工作流不中断。像 Obsidian 这种本地优先的工具，打开文档、跳转页面几乎零延迟，在地铁飞机这种网络差的环境里依然是完整生产力中心，而不是只能看缓存的“阅读模式”。
没端到端加密的同步确实像裸奔一样危险，但更关键的是，你根本不需要被迫依赖云端来换取“协作”的假象。比如我现在用的 Local-first 工具，虽然不支持实时多人编辑，但它把文档、任务和会议记录默认存本地，同步只作为可选功能存在——这意味着你的知识体系永远在 SSD 里，而不是掌握在第三方服务器手中。当网络断开时，它依然能以“瞬时响应”保持完整功能，而不会退化成只能看缓存的“阅读模式”。这种架构的核心优势在于：数据所有权归用户，而不是被云端协作的“便利”绑架。