一次 iCloud 冲突吞噬了一条关于客户广告活动结构的笔记。我三天后才发现。
这就是我在移动端使用黑曜石（Obsidian）第五个月的真实总结。我为四个客户运行广告运营自动化，同时还经营一项内容副业，因此上下文切换才是工作的核心，而非围绕工作的琐事。黑曜石移动端的卖点很简单：在离开办公桌时捕捉任何信息，并让其干净地落入我工作所用的同一个仓库中。但我没有考虑到的是，同步层表现得像一种静默故障模式。
在我的设置下，iCloud 大约每周会产生一次幽灵冲突。黑曜石将它们显示为带有时间戳后缀的重复文件——如果你不特意查看，很容易忽略。我编写了一个 Templater 脚本，在一个专用的“冲突”笔记中标记它们，这至少让它们变得可见。解决冲突仍然需要手动操作，但我现在能看到它们了。该脚本并不能解决根本问题；它只是意味着我不再丢失内容。
更难承认的一个更大的行为转变是：我不得不完全放弃在移动端维持桌面端的整理纪律。在手机上不进行链接、不打标签、不放置文件夹。文本直接放入收件箱，仅此而已。每次我试图在捕捉时正确放置笔记，我都会因为速度变慢而放弃，转而给自己发短信——这违背了初衷。经过六周的摩擦后，我才真正坚持这一规则。现在，我的每日笔记模板上的一个 Dataview 查询会显示过去 24 小时内修改的所有收件箱文件，我每天早上在桌面上花 8–12 分钟处理它们。耗时的波动几乎完全取决于前一晚捕捉的内容量，而与处理开销无关。
我还测试了一个月的黑曜石同步服务（Obsidian Sync）。冲突处理稍好一些，同步速度也更快。但这并不重要——真正的瓶颈从来都不是同步速度。无论底层文件传输机制如何，移动端本身的编辑体验、光标行为以及与长 Markdown 文件的键盘交互，确实比桌面端更差。支付更多费用以获得更快的同步速度并不能解决这个问题。
我在 dailyfocusmag 上写了完整的细分分析——包括我用于收件箱分类的 Dataview 查询，以及 18 个月评分卡的实际情况。
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
