-
在 Obsidian 里，笔记标题是如此重要，写得越笼统，思考的价值越低
回想一下，也许几年前，我们刚建好第一个 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。
写在前面
无意冒犯，我知道 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 分钟的上下文时。
选择尊重专注的工具。否则就继续困惑于为什么你的“企业文化”从未奏效。
-
【速报】Chrome 最新的 3 个加强功能，终于开始认真整理浏览器工作台了
Chrome 2026 的一些新的发展方向
最近十年浏览器上的新功能层出不穷。单独作为产品的新概念浏览器也不少，从早期的分屏浏览器到现在最新的AI浏览器 ，从小众的 Opera Neon，Sigma OS 到后来一度大火的 Arc，现在的 Dia，Comet，Atlas …… 想必各位也没有少见。
但是，一直掌握市场份额的还是 Chrome， 在这点上，Chrome 的做法像苹果的风格，等各位折腾得差不多了，它官方出一个集成功能，然后就结束了。比方说，一度大火的 浏览器AI插件，甚至 AI 浏览器，现在 Google 将 Gemini 内置于浏览器中，随时打开侧边栏就能处理。注意 Gemini，需要谷歌账号为 英语美国地区，英语首选语言，以及各种魔法设置，不是本文重点。
我今天介绍的 不是 Gemini in Chrome，而是几个大家可以立刻用得上的，而且非常实用的更新功能。这波 Chrome 更新，难得有点「回到工作台」的味道。Google 官方在 2026 年 2 月公开强调了桌面端的生产力增强，试着把浏览器重新整理成一个更像工作界面的地方。
下面我们逐个来介绍。
Vertical Tabs：把标签页从顶部救出来
先说最有「形式感」的那个。 这里感谢 沉浸式翻译 Owen 的提醒，此功能我以前只知道是 Beta 版功能，其实最近已经加入了最新的正式版（但是仍旧需要手工开关设置）
Vertical Tabs，也就是「垂直标签页」；一个Windows用户，如果使用自带 Edge 浏览器的话，对垂直标签页一定不会陌生。 这个功能一度成为 Edge 与其它浏览器区别的标志，甚至有人为了这个特性改投 Edge， 其实非 Windows 环境 也是有 Edge 的。
「垂直标签页」本质就是把传统的顶部标签栏搬到侧边，改成纵向列表。这个变化听起来不大，但标签页一多就会立刻有感觉。顶部标签栏的问题很简单，一旦标签页超过十几个，标题几乎都会被压缩到只剩图标。换成纵向排列后，网页标题能显示得更完整，和标签组配合起来也会清楚很多。
它最适合的场景，其实就是重度浏览器用户的日常。比如查资料时同时开着文档、搜索结果、后台、笔记页；比如写文章时一边参考多个来源，一边还挂着素材站和管理后台；再比如开发者一边看文档，一边看调试页和仓库。过去这类工作流最大的问题不是没有工具，而是标签页太快失控。
Vertical Tabs 的价值，就在于让标签重新变得「可读」。尤其是在我个人喜欢的桌面大屏幕环境，特别是宽屏显示器上，拿一点横向空间换更清晰的组织结构，往往是划算的。
Vertical Tabs 开启方法也很直接，只是目前还不算完全公开。更新到 Chrome v146 正式版（之前是 145 beta 就有了）然后打开
chrome://flags/#vertical-tabs把实验开关设为 Enabled，重启浏览器后再到Settings > Appearance，把Tab strip position从Top改成Side。
Split View：终于不用在两个页面之间来回切换
如果说 Vertical Tabs 是解决「过多」的问题，那 Split View 处理的就是「同时看」的问题。
Split View （分屏浏览）它允许我们在同一个 Chrome 窗口里并排显示两个网页。官方给出的用途：比较信息、参考不同来源、复制粘贴内容，以及同时处理不同网页任务。原本需要两个窗口排列、或者反复切标签页才能完成的动作，直接在浏览器内部视图中就可以完成了。
「分屏」这个功能，熟悉火箭君的读者应该已经至少看到我在不同产品里面强推无数次了。很多场景会用到。比如：写作和笔记，左边看资料，右边写稿或者整理提纲。对比和筛选，比如并排放两个商品页、两个文档版本、两组数据来源。边看边做，左边教程、右边后台，或者左边会议记录、右边任务系统。Chrome 直到现在才把它做成原生功能。
开启方法已经很成熟。可以右键当前标签页，把它加入新的 Split view；也可以右键某个链接，直接选择在 Split view 中打开；还可以把标签页或链接拖到窗口左边或右边来触发。
桌面端快捷键也已经有了，Windows 和 Linux 是
Shift + Alt + N，Mac 是Cmd + Option + N。进入分屏后，还能交换左右位置、单独关闭其中一侧，或者把它拆回普通标签页。Chrome 甚至允许把 Split view 图标固定到工具栏，后面直接一键调用。对大多数人来说，这会是这 3 个功能里最容易立刻用起来的一个。我个人建议，Chrome 可以考虑再增加一个 click 快捷键，就像 CTRL+ click， Shift+click 一样，专门用于拆分屏幕打开链接。
PDF annotations：把文档动作留在浏览器里
PDF annotations 处理的是浏览器里的文档动作，也就是让 Chrome 内置 PDF 查看器不仅能看，还能直接画、标、签、记。
浏览器一般都是 PDF 阅读器，这点本来没有什么好说的，但是早期仅限于阅读，后来 Edge 把 PDF 注释高亮和简单编辑 也加入浏览器之后，大家发现既然一样都要打开阅读了，浏览器完全可以胜任一个轻量的 PDF 标注编辑工具。
我个人之前都是拿 Edge 作为 默认 PDF 浏览器的，现在开始考虑转向 Chrome了。
Chrome 官方页已经明确写道，Chrome 现在可以在 PDF 上高亮、批注、绘制，也能填写和签署表单，还支持做个人笔记。绝大多数时候，我们对 PDF 的需求并不复杂，无非就是划重点、做标记、签个名、改一改表单。以前为了做这些小动作，总得下载到本地，再扔进另一个软件里处理。
更值得一提的是，Chrome 对扫描型 PDF 还加入了 OCR 处理。官方说明里提到，这类 PDF 会在设备本地自动转换成可搜索、可选择的文本，之后就能高亮、复制、查找，而且整个转换过程可以在本地完成，不会把数据发给 Google 或第三方。
使用方式也不难。直接在 Chrome 里打开 PDF，在查看器顶部选择
Draw，右侧会出现工具面板，可以选 pen 或 highlighter 来绘制和标注；完成后下载时还能选择保留修改内容。要是希望 PDF 默认在 Chrome 中打开，而不是每次都先下载，可以到chrome://settings/content/pdfDocuments里调整。还有，Google 也是有点小心思的， 编辑完的 PDF 可以一键转存到 自己的 Google Drive 上，属于Google生态圈互相加成了。
最后
把这 3 个功能放在一起看，这次 Chrome 的思路其实很清楚。（注意，以上都在当前最新版Chrome中 v146测试通过）。
- Vertical tabs 处理的是标签组织
- Split view 处理的是并行浏览
- PDF annotations 处理的是浏览器里的文档动作
它们组合起来，确实在认真整理浏览器工作台，让桌面端成为一个生产力工作界面。仔细想想，上述功能的场景都是在足够繁琐复杂的任务下才会出现，甚至对屏幕都有要求，桌面端环境最适合了。
应该说，上面说的这些功能都是呼声很高的生产力方向，不像浏览器自定义酷炫颜色换肤，或者什么都要 AI 集成那种「赶时髦」类型，属于朴素但实用的功能。希望大家如果真正需要生产力，能够用得上。
-
【译】不要纠结于DOCX、PDF、Markdown、HTML …… 我只以一种格式制作文档
写在前面
如今许多 Markdown 编辑器都标配了多格式导出功能，其底层核心往往离不开 Pandoc 的支持。长久以来，我对 Pandoc 仅停留在概念层面的了解。直到近期阅读了一篇深度分享，作者讲述了如何通过 Pandoc 与 Org 模式构建「单一格式笔记库」，从而彻底摆脱排版与格式的束缚，这让我对其背后的工作流产生了浓厚兴趣。
采用单一纯文本格式（如 ：Markdown）的核心优势，不仅在于创作时能屏蔽排版干扰、专注内容本身，更在于其极低的数据解析门槛。纯文本天然具备极佳的机器可读性，这意味着在 AI 时代，AI Agent 可以无缝接入并处理这些笔记。
这正是纯文本笔记面向未来的核心竞争力。云端笔记的智能化受限于平台生态，封闭或复杂的混合格式则存在巨大的数据转换摩擦；而纯文本（Markdown, Org, YAML, LaTeX 甚至 JSON）则完全规避了这些痛点，是真正的 AI-Ready 资产。
在这样的工作流中，Pandoc 扮演了不可或缺的「桥梁」角色。它补齐了纯文本生态的最后一块短板，打破了单一格式与复杂应用场景（如出版、分发、打印、网页渲染等）之间的转换壁垒，让内容创作与最终呈现形成清晰的「工具链」分工。
原作者：Joe Riad； 原文地址：
https://medium.com/gitconnected/i-only-make-documents-in-one-format-8b50bd61972d
火箭君翻译，并略做编辑。
正文
我一直讨厌和同学/同事一起处理共享文档。总会有人因为使用的 Word 版本略有不同，或者干脆用了另一套办公软件，结果在自己的电脑上出问题。我们也可以共享 PDF，但不容易编辑。
假设我们对共同的文档格式达成了一致，那那些期望我把网页发布到共享服务器上的人怎么办？我是否必须把 Word 文档的信息重复一遍以 HTML 格式呈现？虽然有导出服务，但还是很麻烦。
简而言之，在对文档有不同假设和不同使用场景的人之间共享文档，很容易变成一场噩梦。这就是为什么当我发现有一个可以为我处理所有这些工作的自由软件工具时，我感到震惊。更重要的是，它让我只需撰写一次文档，就能根据需要将其发布为多种不同的格式。
我要介绍的是 Pandoc 。它几乎可以在你能想到的任意两种文档格式之间进行转换。将内容与格式分离
在我谈论 Pandoc 之前，我想介绍一下我不久前接触到的文档设计概念。这种思路影响了我在 Pandoc 中制作文档的方法。这个想法很简单：文档的内容应该与其格式相互独立。在处理文档时，应当先填写内容，之后再考虑格式。如果我们只编辑过 Office Word 文档，这个概念可能会让人感到很陌生。
在 Word（或 LibreOffice Writer 或类似软件）中编辑文档时，通常在输入内容的同时编辑格式。我们会关注字体大小、颜色、哪些内容加粗、哪些不加粗、标题如何格式化等……如果更有经验一些，可以使用文本样式。例如，可以指定所有标题应为加粗、14 磅并使用某种字体，而普通文本应为 12 磅并使用另一种字体。
这样在创作内容时我们就不必纠结于格式的细枝末节了。这是将格式与内容分离的第一步。Word 仍然可能具有干扰性，因为你在输入时就能看到最终文档的大致样子，所以你会更容易对格式问题敏感并产生分心。
我第一次真正接触到这个概念是在大学开始用 LaTeX 写学术论文的时候。在 LaTeX 中，我们在输入时看不到最终文档的样子（不过，也可以参见 LyX）。
我们只需指定内容和结构元素（例如：这是一级标题、这是列表中的一项等……），LaTeX 引擎会将你的指令编译成最终文档。它使用预定义的样式完成排版，能以很小的成本让文档看起来相当专业。
当然问题是，与不太懂 LaTeX 的人协作处理 LaTeX 文档相当困难。最终文档是 DVI 或 PDF 格式，也不容易编辑。
有一段时间，我只能在个人写作中采用这种文档设计方式。任何需要与他人分享的东西都必须是 Word 文档，用惯了 LaTeX 之后，Word 这种方式让我感到相当沮丧。
我的理想情况是用一种标记语言（比如 Markdown）来指定文档的内容和结构，然后让一个引擎将其格式化为我所需的文档类型。 Pandoc 正是提供了这一点，这也是我第一次接触它时，会觉得它带来了一种范式转变的原因。。
关于 Pandoc
Pandoc 几乎可以在我听过的任何两种文档格式之间进行转换。我认为，如果格式不是 Pandoc 能处理的那些之一，那么它大概非常小众，用户自己应该已经是这种格式的专家了，并且能够把它转换为其他格式。为了高效实现这一点， Pandoc 将任何文档格式转换为一个通用的内部表示（中间码），然后再把该内部表示翻译为目标格式。这样，与其为每一对可能的格式编写转换器，不如只需为每种格式实现与内部表示之间的翻译器。
这种能力的妙处在于，它允许你用一种格式来撰写文档，并根据需要使用相同的源文档发布为多种不同的格式。关键是选择一种表达力足够强的格式。当我刚开始使用 Pandoc 时，我认为 Markdown 非常适合这个目的。
下面是一个包含不同结构和格式元素的 Markdown 文档的小示例：
要将此文件（假设名为 mydoc.md ）转换为 docx 格式，我可以在命令行中这样做：
pandoc -f markdown -t docx -o output_file_name.docx mydoc.md
其中 -f 指定 源格式， -t 指定 目标格式。下面是该文档在我的 LibreOffice Writer 中的渲染效果：
由于 Markdown 允许我指定标题级别， Pandoc 会识别文档结构并在 docx 文件中使用标题样式进行复现。因此一级标题使用「Heading 1」样式，二级标题使用「Heading 2」样式。这意味着，例如，如果我想要的话，可以很容易地生成目录。
但乐趣并未止步于此。我可以使用相同的 Markdown 源文档来创建一个 HTML 文档：pandoc -f markdown -t html -o mydoc.html mydoc.md
得到如下结果：
当然，这只是普通的 HTML。通过指定一个 CSS 文件可以让它变得更好。下面是一个示例 CSS 文件。如果我将其保存为 pandoc.css 并以这种方式转换我的文件：
pandoc f markdown -t html -o mydoc.html mydoc.md--css=pandoc.css --standalone
同理，我也可以将相同的文档转换为 PDF，或其它格式。
即使像方程式这样的专业支持也非常棒。如果转换为 HTML，我们可以使用 MathJax 让它们以类 LaTeX 的质量渲染。如果转换为 PDF，它们会通过 LaTeX 渲染；如果转换为 docx、odt、pptx 等格式，它们则会被转换为本地的、可编辑的方程式。我们在 Markdown 中输入方程时，仍然使用 LaTeX 语法。
也可以通过 YAML 向文档添加元数据：
可以通过过滤器进一步扩展功能，你甚至可以使用 Lua 为自己的文档格式编写自定义转换器（关于这点，请参见 Pandoc 网站）。长期以来，这一直为我带来极大帮助，但我总觉得 Markdown 在表达能力上相当有限。这就引出了我今天实际使用的文档格式。
Org 与 Pandoc 导出
当我遇到 Markdown 的局限时，我也刚开始接触 Emacs。Emacs 里有一个名为 Org 的模式，它本身就是一套效率很高的生产力工具。在其众多功能中，它有一种用于指定文档结构的标记语言。
当我调出 Org 导出对话框时，看到的是：
类型非常丰富，我很难想到我可能需要使用却找不到的格式。当然，如果找不到，Org 也允许我编写自定义导出器。大家可能会认为我在从 Markdown 切换到 Org 时遇到了问题。因为我已经有很多用 Markdown 写的笔记和文档，需要花时间将它们转换为 Org。
事实证明这根本不是问题： Pandoc 当然可以将 Markdown 转换为 Org！
有时，我希望 Pandoc 的功能比现有的稍微强大一些。这时我发现了过滤器。基本上可以拦截 Pandoc 所理解的文档内部结构，并在导出前对其进行修改。
Pandoc 过滤器
正如此处详细解释的， Pandoc 首先将文档转换为它可以以 JSON 格式输出的抽象语法树（AST）。筛选机制允许你编写自己的代码来拦截此 JSON，对其进行修改，然后输出供 Pandoc 完成将其转换为目标格式的剩余工作。
Pandoc 的创建者创建了 pandocfilters Python 包以便于这一过程（https://pypi.org/project/pandocfilters/）。
大家也可以使用过滤器来预处理引文和参考文献（这就是我最初的用例），将实时获取的数据（例如股票行情）注入到文档中，或使用几乎任何只要 Python 能做到的方式来转换文档。
我自己的例子
以下是以 Org 为核心采用这种创作流程后，我获得的一些具体收益：
我用 Org 写完了整篇博士论文，并通过 LaTeX 导出成 PDF。这是一个巨大的工程，涉及自定义 LaTeX 样式文件和参考文献样式等……最棒的是，我不用处理 LaTeX 的样板内容就能发布高质量的 LaTeX 文档。到了准备答辩幻灯片的时候，我使用了 LaTeX Beamer。我能够毫无阻碍地将论文 Org 文件中的内容直接复制到演示文稿的 Org 文件中。
我把在工作中学到的所有东西（从修复常见 IT 问题到新的技术知识）都记在 Org 里。我能把部分笔记以 HTML 的形式发布，供队友参考，也把一些笔记以 docx 格式发布，为我的主管生成任务报告。这让我看起来像是愿意多下功夫制作高质量文档的人。当然，我不需要为实现这一点而操心 HTML 或 docx 的细节。
在手机上访问我的 Org 笔记并不容易，所以（有趣的是）我用 Pandoc 将它们全部转换成 Markdown，以便在 Joplin 中用更友好的方式浏览它们。最后
为了避免在我必须为不同场景创建并与同事共享的各种文档格式之间频繁切换，我决定大多数文档都用 Org 撰写，然后导出为所需的任何格式。为此我使用 Org 的导出引擎或 Pandoc 。
我喜欢这种方法的原因是它完全免费且完全以纯文本形式存在。我可以将文档放入版本控制、检索它们、对其中一些处理流程做自动化处理等…… 然后再发布一些真正精美的文档与他人共享。
如果大家也需要产出大量文档，我强烈建议和我一样尝试使用单一文本格式 Org， 或者 Org+Pandoc 两者兼用。
-
Obsidian 推出了 Defuddle， 把 Obsidian Web Clipper 推到了一个新的高度
我一直很喜欢 Obsidian 的核心理念：本地优先，万物皆文件，而且是单纯的 Markdown 文本文件。在这样的模式下，笔记完全属于我们自己，我们可以自由地搭配各种组件或插件，按照自己的习惯去定制操作和工作流。 而且，信息的保存备份同步，都在我们自己的控制下。
我之前介绍过 Obsidian 自家推出的 Web Clipper， 一个网页剪藏类的浏览器插件，同样秉承了上述的「文件中心」理念，把我们正在浏览的网页内容变为一个Markdown 笔记， 存入 Obsidian 的资料库中，而且还包含元信息。
最近 Obsidian 推出了 一个新的网站，Defuddle.md，Defuddle 是 Obsidian 本地文件生态系统里一个非常强力的工具，通俗来说，是 Obsidian Web Clipper 的网页版。
如果把 Obsidian 看作一个本地笔记的 OS， 我们之前介绍过 CLI（命令行接口），这个 Defuddle 更像Obsidian Web Clipper 的一个 URL 接口。
所以，在详解 Defuddle 之前，我们先快速回顾一下 Web Clipper。
Obsidian Web Clipper ：网页变 Markdown
聊到 Obsidian Web Clipper，我个人觉得它最吸引人的地方，在于它早就超越了传统的网页保存抓取功能。
它不仅仅是把网页抓下来，更厉害的是它支持极其灵活的 Obsidian 模板。Web Clipper 能够提取网页里的各种元数据（比如作者、发布时间、甚至特定的页面元素）。更让我惊喜的是，它现在还支持条件判断、循环这些逻辑操作。这意味着，在采集网页的阶段，我们就可以按照自己的规则把内容整理好，直接变成干净、结构化的本地 Markdown 文件。
当然弊端是，如果用户不喜欢默认的整理模板，需要自己配置，这个过程可能会有一些门槛（其实可以让 AI 来配）。
但总的来说，Obsidian Clipper 完美契合了 Obsidian 的生态，让网页内容非常顺滑地融入我们个人的知识库。对于 Power User，又提供了自己捣鼓的空间。不要小看这些 Power User， 那么多 Obsidian 插件，大多都是用户自己捣鼓出来的。
Defuddle.md：专注清洗的抽取层
而 Defuddle 的出现，让我觉得 Obsidian 是把 Web Clipper 背后最核心的网页抽取能力单独开放出来了。
如果，大家是某个信息领域的资料收集者，调研者，数据分析者 …… 如果自己又能稍微捣鼓两下，又或者借助 AI（包括最近大火的小龙虾）捣鼓两下。 那么Defuddle.md 绝对是一个惊喜！
给 Defuddle 一个链接，它就能帮你清洗掉网页上的广告、推荐区等杂乱元素，尽量提取出干净的正文和结构化的元数据。它就像是一个专门负责把复杂网页转化为标准 Markdown 文本的净化器。 有了这个，任何人都可以做一个自己的 Web Clipper，而且不用隶属于 Obsidian。
Defuddle 提供几种访问方式。
- 普通用户，浏览器访问，输入需要转换的网页网址，查看清洗过的 HTML 或 Markdown
- AI Agent 或 开发者， 通过 URL 接口，获取清洗转换结果
- Obsidian 用户， 直接使用 Web Clipper 插件 即可（背后就是 Defuddle）。
其中最有价值的，我觉得就是 「URL 接口」，想象我是一个小龙虾，又聋又瞎，按用户要求收集访问网页非常痛苦，又是无头浏览器，又是被屏蔽，即使取得网页，里面的杂质噪音又很多； 现在好了，直接调用 Defuddle 一切解决。
而且，很重要的是，Defuddle 是开源的。我们甚至可以自己本地部署。这就很 Obsidian 了。 让 App 成为用户自己可以控制的系统，而不是把用户变成 App 的附庸。
最后
市面上，其实剪藏插件很多，其中不少的目的是锁定用户到某个特定App。 而 Obsidian Web Clipper 不同， 因为 Obsidian 理念是 File Over App。 现在，更进一步， Defuddle 被开放出来，大家可以直接用了，而且还是开源的。 所以，有点太阔绰了，反而不适应了。
如果对这类网页抓取（作为PKM重要组成部分）有兴趣的话，之前 Jina.ai 也提供了付费的 Reader API （下图）。Jina 是很多 AI 从业者的首选，现在则感觉有了一个免费开源的对手。当然，Jina号称是 AI模型 清洗抓取，还略有不同。
说实话，我现在反而开始担心 Defuddle 要被人滥用了（或者被屏蔽了）。
-
当 AI 语音输入法等工具 开始「看」我的屏幕，它是更聪明了，还是更危险了？
我之前介绍过我一些表现非常出色的 AI 语音输入法。 我当时提到是：性能出色，但隐私还要谨慎留意。 现在有越来越多的证据表明，一些 AI 语音输入法（确切的说，已经超出了输入法的权限），正在看我们的屏幕，从而获得更准确的「上下文」，提供更好的语音识别和内容生成。
通过给屏幕截图，分析上面出现过的内容，然后再结合我们的语音，AI 显然可以给出更准确的识别结果。 比方说，我正在写一篇 关于 笔记工具 的 文章， 当 AI 输入法看到了我屏幕上的文章时，再听到我说 Notion，Obsidian 时 会给出更好的识别， 这是单纯语音识别难以做到的。
有各家 AI工具 厂商已经明示或暗示了用户：
- 比如 ChatGPT 桌面端明显在强调「chat about … anything on your screen」，并提供截图工具让我们把当前屏幕内容交给它分析。
- Microsoft 的 Copilot Vision 也走同一路线，官方描述就是「让 Vision 看见屏幕上打开的浏览器窗口或 App」，然后基于画面给我们步骤式指导。
- 而在「AI 语音输入/听写」圈子里，Superwhisper 这类工具把它叫做 Context Awareness，明确列出多种上下文来源（应用的情况/选中的文本/剪贴板等）。
- Wispr Flow 甚至直接写在页面上：会用「limited screen context」来保证在消息和邮件里把不常见的人名拼对。
但「屏幕」一旦它变成模型的上下文来源，风险可能远比想象的要大，尤其是那些采用云端模型的AI 工具，基本上自己做的任何事情毫无隐私可言，等于提供了在别人面前裸奔的条件。
「主动看」还是「偷偷看」
我把常见做法粗暴分成三档，方便大家判断自己在用的 AI输入工具处在哪一档：
1）显式截屏/手动投喂（相对可控）
典型是桌面端的「Take Screenshot」：我点一下，选一个窗口或区域，再发给 AI。
这档的关键是：我知道自己交出了什么。但显然会比较麻烦，所谓的「摩擦」比较大。
2）读取活动 App/输入框内容（危险从这里开始）
很多「跨 App 听写」工具为了让你在任何地方都能说话输入，会用系统级权限去读当前画面的输入框、选中内容，甚至还会在后台看看剪贴板等。Superwhisper 文档里就把这些上下文来源写得很清楚。
这类能力常常依赖操作系统权限，比如： macOS 的辅助功能/权限体系，或者 Android 的无障碍（Accessibility）能力。3）持续快照/时间线式记录（最危险）
这类不是「为了当下输入更准」，而是把整个屏幕历史当作可检索的记忆库。典型例子：
- Windows 以前提起的的 Recall（下图）：以「snapshots」方式保存用户做过什么，并提供暂停/开关等控制。
- macOS 的 Rewind 这类「记录一切」App：媒体报道过它的核心卖点就是记录你在 Mac 上看过/做过的内容以便回溯搜索。
也不是「会不会上传云端」这么简单
很多产品会强调「本地处理」「不上传云端」。这当然重要，但远远不够。因为风险分布在三个层面：采集、存储、传输/处理。下面是我认为最要命的几类：
1）输入 A，AI 顺手把 B 也带走了
语音输入的真实场景是碎片化的：我们可能在回复 Slack，旁边开着客户合同、工资单、2FA 验证码、病历报告。
一旦工具获取的是「活动窗口」甚至「屏幕画面」，就很容易把没打算分享的东西当成上下文一起打包，生成隐私敏感的内容。2）权限不可逆的「心理麻痹」
macOS 对屏幕录制权限的描述其实已经很清楚：可以控制哪些 App 允许录屏，而且如果允许第三方 App 录屏，它收集到的信息受对方条款和隐私政策约束。
很多用户第一次弹窗会认真看，几次之后就只想点「允许」了。之后它就长期存在，直到哪天想起来才去关。3）企业/客户数据合规直接爆炸
在公司电脑上开会、写 PRD、看工单、处理客户资料，如果语音输入法/助手有屏幕上下文权限，那就是把「屏幕上出现过的一切」纳入了第三方软件的处理范围。
哪怕它声称不上传，光是「采集能力」和「潜在外发路径」就足够让很多组织的合规部门头大。4）很难验证「它到底抓了什么」
最糟糕的一点：很多工具不会给我们一个「将要发送的上下文预览」，或者一个审计日志。
没有预览就没有可审计性。只能相信它的自我描述，而这在软件世界里属于最奢侈也最不靠谱的信任方式。 「零留存」「不保存」「不滥用」「不作恶」…… 我现在是一个字都不相信，我只看对方的信用等级和作恶的后果来决定。 对于一家新兴的小公司，尤其拿了点融资急于想证明自己的那种，完全不用给它任何隐私信用，这是最理智的。
我自己的取舍：把「上下文」当成高危权限对待
我并不反对上下文。相反，我之前文章就承认，现在的 AI 识别效果真的很理想：拼写准确、指代清晰、语气更贴合场景。像 Wispr Flow 这种「用有限屏幕上下文拼对名字」的思路，本质上就是在追求极低的输入摩擦。
但我的原则是：
- 默认关闭一切「自动屏幕上下文」（尤其是持续型、全局型）。
- 需要上下文时，用「选中文本」代替「整屏/整窗口」。
- 只在「我能接受泄露」的场景主动启用，比如写公开内容、写无敏感信息的草稿。
- 某些企业环境建议直接一刀切：公司机器不装、不授权，别拿同事和客户当实验材料。
另外，除了「看屏幕」，键盘记录，扫剪贴板，扫本地文件 都是非常危险的行为。 不能因为只要是AI需要「上下文」就能以此为借口，随便乱来。 这种事情已经不是单纯的工具使用原则了，可能有更广泛的参考意义。 如果有人以让我方便的名义，任意收集我的隐私，嘴上还说为我好，我就十分警惕。 是否要「牺牲隐私换取效率」，这点大家自行决定，但我的建议是要谨慎。
最后
AI 语音输入法要变好，理解语境「上下文」的确是很重要的。
但屏幕的隐私程度太高了。而且未必有能审计的系统。如果一个 AI 工具必须靠「持续看屏幕」才能显得聪明，那它多半不是聪明，只是单纯想多看些屏幕。最后，我个人已经完全卸载了这类需要收集屏幕信息并发送到云端的AI 输入法。 这种不能审计的系统，在我不明确已知的情况下收集信息，背后又是一些拿了融资随时可以跑路的小公司，我认为这些都是危险的特征信号，不值得大家冒这个险，AI 大有有可为，但不是用在这个上面。
至于大家怎么想，见仁见智，欢迎告诉我。
-
目前的 Siri 其实非常适合 Apple 提醒事项（比想象的更好用）
很长时间，我觉得在 Siri 在没有接入真正的第三方强力 AI 之前，语音理解和操作的能力非常有限。而且我相信即使接入了 AI，如果没有彻底开放操作应用的权限，尤其是苹果自家那几个经典应用，AI 的作用也仅限于查询问答或改个图之类，没有什么实质性生产力。
跟 Google Assistant 比，Siri 似乎显得完全不在状态，还有种种玄学原因，我个人会常听到 Siri 说「抱歉，出了点问题」，因此前几年我使用 Siri 的兴趣不是很大。有时我上手新设备就直接禁用 Siri。
但是，有一点，我也是这两年才逐渐感受到，Siri 不是个聊天机器人，我觉得 Siri 在处理 Apple Reminders 时，非常智能。算得上专属「语音输入层」了。
以前我们一直寻找一个 记录「闪念」的工具，但实际上，在苹果生态里，Siri+Reminder 就是绝配了，几乎没有第三方工具可以打破，我也是这两年才意识到这点，而在近一年里，由于频繁使用而逐渐加深了这个印象。
在我这里，Apple Reminders 是「收件箱」。任务、想法、日程、乱七八糟的灵感先进去，之后再整理。开车、走路、外出活动 这类不方便直接打字的场景，Siri 反而很稳定。 个人经验，如果配上Apple Watch 更是锦上添花，抬起手腕，说话，就记录到 Reminder 了。
我撰写此文，并不是我突然心血来潮，一方面是长期使用有所积累，另一方面是最近看到了下面这篇文章，恰好提醒了我。
Siri + Apple Reminders (It Works Better Than You Think) https://medium.com/macoclock/siri-apple-reminders-productivity-fdebab2ca767
所以我结合自己的感受和上述文章所述（大量引用和翻译），整理了一些 Siri+Reminder 的经验分享给大家。
为什么 Siri 配合 Reminders 更好用
因为提醒事项是结构化的，而 Siri 只要把语音映射到结构字段就够了。
一个提醒事项（task）通常就这些字段：
- 动作（要做什么）
- 列表（放哪）
- 时间（可选）
- 地点（可选）
- 重复规则（可选）
这套结构「可预测」。Siri 对可预测输入的容错会高很多。所以，按 Siri 目前的能力，基本不要问 Siri 复杂问题，只给短指令即可。可以理解成：我在用语音「填表」。
我的 Reminders 基础结构
先说前提：要让 Siri 稳，列表结构需要干净。
常用的列表不用很多，但边界要清晰：
- Work
- Personal
- Groceries （这个列表 Apple Reminder 显然意识到了，经常会建议我添加）
- Ideas
- Inbox（纯收件箱，用于不想分类的时候）
列表名尽量短、好读、互不混淆。不要出现「工作」和「工作计划」这种自找麻烦的同义词对。
最常用的 5 种 Siri 指令
1）「任务 + 列表」：最快的捕捉方式
很多人会说：「嘿 Siri，把橄榄油加到我的购物清单里。」当然能用，但太长了。
我更常用这种句式：
- 「Groceries：橄榄油」
- 「Work：准备发票」
- 「Ideas：写一篇 语音输入的对比文章」
不需要加「添加到提醒事项」「加入列表」这些废话。列表结构越清晰，Siri 越不容易理解错。
关键点：把列表名当成标签说出来。
就是在告诉 Siri「放到哪个字段」。什么「Siri 填表专家」，不是浪得虚名的。
2）「任务 + 地点」：最被低估的提醒能力
位置提醒是 Apple 生态里那种典型的「明明很强，但没人用」的功能。我用它来卸载脑内记忆负担。
常见句式：
- 「当我到办公室时提醒我给 Jane 打电话」
- 「我到超市时提醒我买电池」
- 「到家提醒我准备明天的材料」
这类提醒的爽点在于：不用记得「稍后要做」，设备会到合适的地方时提醒。比定时更贴合现实。（Omnifocus 以及一些 同类App 内 所谓的「地理上下文」，苹果已经彻底学会了）
3）「相对时间」：比手动选日期快太多
我很少打开 Reminders 里那个日期选择器去滑来滑去，完全没必要。
我会直接说：
- 「30 天后提醒我审查财务」
- 「下周一上午 9 点提醒我看网站数据」
- 「两小时后提醒我把衣服从烘干机拿出来」
相对时间是 Siri 的舒适区。由于给的是明确的结构，Siri 就能把时间字段填好，又是填表，我个人觉得这个时间段填写 比很多第三方 App 强太多了，像我前次文章吐槽过的 Todoist Ramble， 那才真是一言难尽。
4）「重复规则」：用 Reminders 管小习惯
我不太爱装一堆 habit app，因为大多数最后都变成图标收藏。我更愿意把小日常放在 Reminders 里，让它做系统级提醒。
句式也很固定：
- 「每周一晚上 7 点提醒我倒垃圾」
- 「每月第一天提醒我回顾目标」
- 「每天早上 8 点提醒我补充维生素」
Reminders 原生支持重复逻辑，Siri 只是输入，不需要它做复杂的事情，Reminder会处理剩下的。
5）「提醒我这个」：上下文捕捉（我最爱）
这是我最常用也最省事的功能：如果在 Safari 看文章、在 Mail 看邮件、甚至在某些 app 里刷到一个东西，我会直接说：
- 「提醒我这个」（Remind me about this）
它会生成一个带链接的提醒事项，之后我点开提醒就能跳回原内容。出乎意料的好用，我猜很多人不知道这点。
这本质上是一个「稍后读 + 待办」的合体动作，而且不需要你手动复制链接、粘贴、再命名。系统级集成的好处就是这么朴实无华且有效。
Siri 不单是添加任务，也能用来查询
我偶尔也会用 Siri 做快速回顾，尤其在手忙脚乱的时候：
- 「显示我的提醒事项」
- 「我今天有哪些提醒」
- 「Work 列表有什么」
- 「本周有什么到期的提醒」（这句有时会因语言环境表现不一）
依然是同一个原则：短、结构化。
结论
如果你期待 Siri 变成聊天的 AI 助手，那失望几乎是必然的。AI聊天的话，我个人用的 豆包 倒是不错，我强烈建议豆包和 Siri 合体。Siri 确实不擅长长对话，也经常在追问里翻车。
但，如果你把 Siri 当成 Apple Reminders 的「快速输入层」，它反而是一个很可靠的生产力组件：短指令进系统，结构化字段由系统处理，提醒触发交给时间和地点。
最后，搭配 Apple Watch， 双击手指（设定到启动 Siri），抬起来说话，「提醒我……」，这一套流程是非常好用的随时记录方式，我个人强烈推荐。
-
Obsidian CLI：命令行工具如何改变笔记管理
终于，Obsidian 推出了官方 CLI（Command Line Interface，命令行接口）。
Obsidian 将变成可脚本化、可自动化、可集成的终端工具。CLI 随 Obsidian 1.12（Desktop，Early Access）上线。
但先别急着去下载，这个 CLI 目前仍是 Early Access 功能，需要版本 Obsidian 1.12+。而 1.12 现在还是早期版本，并且需要 Catalyst 资格（也就是要付费获得「内测用户」资格）。同时官方也提前打了预防针：命令和语法在后续版本中可能会变化。
但不管如何，Obsidian 走出了那一步，把自己更彻底地融入「工具链」的一环中。这也符合 Obsidian 一直以来的哲学：做开放生态的生意，不做封闭的大而全系统。
Obsidian CLI 是什么？
对于不熟悉 CLI 概念的小伙伴来说，很多人从第一次使用软件或 App 开始接触的就是图形界面，我们称之为 GUI。更早一些，图形界面还不发达，终端曾经是主流，那类界面通常被称为 TUI（终端界面）。命令行接口就是典型的「TUI 时代」产物，通过命令与软件交互。除了人工操作外，它也非常适合脚本运行。
直到今天，Linux 用户和一些运维场景仍然大量使用 TUI，很多应用程序也通过 CLI 进行交互。
在 API（应用程序接口）盛行的今天，CLI 其实也可以被理解为一种 API，一种更古老的 API。我以前喜欢把它称为「字符界面」的命令组合。
Obsidian CLI 大概长这个样子（下图），这是官方示例。通过命令可以创建、查询我们的笔记。
详细的命令规则说明，请看官方文档：
Obsidian CLI 为什么会出现？
时至今日，CLI 这种古老概念为什么会被套在一个新兴的笔记工具上？我觉得这和 AI 的强势崛起有关。
有一个大胆的预言：未来相当数量的软件不再主要直接为人类服务，而是为 AI 提供服务。对 AI 来说，GUI 那种花哨的图形界面反而可能是生产力倒退，它更需要简单、干净的命令来调用和操作软件。前段时间大热的 MCP 就是此类接口协议，而 CLI 也是一种更传统、也更容易被人机双方接受的实现方式。
这并不意味着图形界面不再重要，只是说 CLI 会为 AI 或自动化程序打开大门，而这些都是通向生产力的必经路径。一条笔记只是自己手写出来欣赏，和用 AI 批量生成报告、批量分析，是截然不同的事情。这是小作坊单件生产和工厂规模化生产的区别。CLI 就是那条自动化流水线的基座。
对于一般用户，CLI 能带来什么好处？
我相信这是大家特别关心的问题。下面是一些可能的场景，但我觉得肯定是我想象力有限。再过几年回头看，可能会出现更突破的应用场景，显得我现在的描述反而保守了。
未来更合理的收集流程
- 我们在任何地方输入一句话（系统搜索栏、手机快捷指令，甚至语音）
- AI 将信息自动追加到 Obsidian 的某个「Inbox」笔记
- 顺手按我们自定的规则打上时间、来源、标签
- 晚点我们再进 Obsidian 里处理
未来会议记录
- 日历会议开始前，AI 自动在 Obsidian 新建会议笔记（按照预设模板，包含参会人、议程、链接等）
- 会议记录可以语音输入，或者与第三方会议工具集成
- 会议结束后，自动把笔记移动到对应项目文件夹，并生成一条回顾任务
- 如果你在会议里记了待办，自动汇总到任务列表
- 如果里面触发了一些预设标签，则执行相应动作，比如启动聊天机器人去指派任务
未来的整理流程
- 把一堆零散笔记丢进 Inbox
- 每晚系统自动跑一次：统计今天新增了哪些 tags、哪些 properties、哪些未分类文件
- 生成一份「待整理清单」写进 Daily Note 或周报笔记
- 周末只要照着清单处理即可
最后：会不会走向 headless Obsidian？
目前，官方的 Obsidian 还不是一个无头（headless）工具。所谓「无头」，就是没有用户界面，一切都是为程序接口服务的。很多后台服务程序，比如收发邮件、网页服务，都是「无头」的。它们不需要和人直接打交道（虽然有日志）。
有喜欢折腾的小伙伴的确手工自制了一个 「准无头Obsidian」（其实是让 Obsidian 以为自己有头），但主要是在服务器端用于同步，具体可参考下文：
https://rolle.design/setting-up-a-headless-obsidian-instance-for-syncing
现在，随着 CLI 出现，更简单的 headless Obsidian 已经呼之欲出。 像上文费劲同步什么的，现在就是 CLI 下的 一个命令而已，别折腾了。
我们也许早晚会发现，AI 一旦能真正发挥威力，很多交互界面都会被取代。或者换句话说，任何人如果想要自己定制的界面，AI 都能按需生成；那么，折腾插件、界面美化主题的价值可能也会减小。到那个时候，Obsidian 以及任何其它笔记工具，可能就只剩下 CLI、Skills、MCP 这类核心接口了。
当然，短期内这个变化应该还不会那么激进。但「无头化」，或者说软件不再主要与人打交道，这个方向值得我们注意。我隐约觉得：对消费级用户来说，AI 交互（复合语音输入、定制 GUI）可能真的会逐步淘汰传统 GUI（软件预设的按钮、图标、列表视图），就像 GUI 当年淘汰终端命令行一样。
-
我用了一个月 的 Todoist Ramble 功能，最后却回到了滴答清单
写在前面
滴答清单一直是我的常备工具，Todoist 则是我以前很爱用的一款 Todo 工具。我对两者都非常了解。
最近，Todoist 上线了一个新功能，名为 Ramble，引起了我的兴趣。
简单来说，Ramble 是一个「语音输入任务」功能。它不只是把语音转成文字，而是号称能把我们的碎碎念直接拆成多个结构化任务。我承认，我看到宣传时被勾起了兴趣，因为我一直在追求更低的任务「捕捉摩擦」，就像我上次提到的 Typeless 输入时一样。
在 Ramble 之前，其实已经有一些工具号称可以通过 AI 把一段口语描述整理成任务。但恕我直言，我用下来这些都不行。原因很简单：语音转任务这种功能，必须依附在一个成熟的 Todo 工具之上，它应该是「底座能力上的加成」，而不是一个全新的独立 App。
一个新 App 号称能把语音备忘变成任务，多半只是玩具。因为 Todo 工具里一堆基础能力它都没有积累，等于凭空造楼台。同理，类似单薄的 AI 玩具还有很多，比如语音转流程图、AI 转设计图，甚至 AI 编程、AI 写作。没有基础能力支撑，上来就以 AI 为噱头，号称什么都能做，那就活该只能停留在玩具程度。我觉得这才是 Vibe Coding 里「Vibe」真正暗示的含义。
所以我当初看好 Todoist Ramble，正是因为 Todoist 本来就是优秀的 Todo 工具，基础够扎实。
但在我实际使用 Todoist Ramble 一个月后（全功能会员，不是免费试用版），我的观点发生了一些变化，在这里分享给大家。
初步认识 Todoist Ramble
我对语音输入，尤其是「任务安排」这个场景，一直很矛盾。
键盘输入更精准，也更能跟上思考节奏。但现实生活里，任务最常出现的时候，偏偏是最不方便打字的时候：在路上、会议间隙、电话之后……除非一天都坐在办公桌前，否则很大概率任务年头出现时，手上没有键盘，甚至手机输入也不方便。
因此「闪念」类应用有市场是挺有基础的，但闪念类 App 又很难组织成任务，往往只是隔离的备忘录或清单。
我理想中的语音 Todo 体验是这样的：
- 我说一段话，不需要停顿组织
- 它自动拆成多条任务
- 日期、时间、项目、优先级能顺手识别
- 我说完就走，之后再回 Inbox 整理，甚至不用整理了
Ramble 的定位刚好在这点上：把语音当作成熟任务管理工具的「任务入口」。
初次使用时，如果运气够好（注意这个限定），App 恰好命中所说的内容，真的会觉得它像魔法一样。它不像传统语音输入那么简单：Ramble 会识别出多条任务，也能停下来等我确认，甚至让我用语音修改之前的任务，像在和人交谈一样。
我就是这样「上钩」的。
实际使用体验
Ramble 和很多 AI 功能一样，是有额度的，而且要会员才能用。所以我买了一个月会员。要知道 Todoist 的会员并不便宜，而且除了 Ramble，其他增值功能我兴趣都不大（什么更复杂的筛选器、更多背景、协同任务等）。
这一个月下来，我直接说结论：挺沮丧的。
我没有要黑 Todoist 的意思，Todoist 在我心里一直是优秀工具的代表，但 Ramble 这个功能目前还不行。
最大问题是语音识别。我强烈怀疑他们用的 AI 模型是不是某种廉价小模型，识别成功完全拼运气。有时能非常准确理解意图，有时就要反复修改，而且还得用语音继续修改。
我也看到网上有人说是环境噪音导致识别错误。但 Ramble 这种「闪念记录」场景，环境噪音的处理本来就应该是默认考虑进去的因素。
另一个问题是对网络依赖非常敏感。网络稍有延迟或连通性问题，语音识别就会直接失效。我遇到过在信号不好的地方，越着急越没法用语音输入，这就很傻了。
多条任务的自动整理也是一把「双刃剑」。当它一把梭哈命中用户意图时，Todoist 可以很连贯地一次性输入多条任务。但一旦中间有识别错误，修改就会异常困难。
它确实支持语音智能识别并修改个别任务，但这时又被语音识别准确性限制住了。更麻烦的是，稍微复杂一点的时间节点任务，它表现出来的「智商」很有问题。
举个实际例子：我说「下周日 5 点开始某个任务」，它理解成「明天下午 5 点」。我说不是明天，是下周日。App 把日期改成下周日，但同时把「下午 5 点」给去掉了。我只能再重复一遍：下周日的下午 5 点。
这种感觉倒真像和人交流，只不过是和一个不太上心的实习生交流。以前某段时间（现在好像改了），我在某巴克点「大杯冰拿铁」，服务员会先问：要中杯还是大杯，再问要冷的还是热的……等等，那么我说「大杯冰拿铁」这句话服务员觉得是什么意思？Ramble 就是这种体验。
所以到了这一步，取消订阅已经难免。
可以考虑的替代品
回头看，可能还是我对 Ramble 的期待太高了。
实际上，不需要那么复杂，也不一定要用昂贵的付费功能。现有工具里，已经有不少能实现语音意图识别，并转成任务管理。
比如 iPhone 的 Siri 就很好。它直接连通「提醒事项」这款内置应用，当我们说「帮我提醒 + 时间 + 任务」时，它会把任务安排进提醒事项里，通常很准确，出错很少。我一直说 Siri 不行，但提醒这件事，Siri 做得很好。
再比如，我爱用的滴答清单（下图），长按添加任务的加号可以语音输入（有些小伙伴可能并不知道）。如果我们描述时间和任务足够准确，它也能在清单里正确添加任务，不用反复修改。
但这些替代方案的缺点也很明显：任务会更零散，没法一次性添加多条。这需要用户有更强的脑内整理能力，能分门别类地在合适的位置输入合适的任务，并且描述足够清晰。
最后
Todoist Ramble 原本想成为一个轻松入口：通过一次轻松的交谈，完成复杂且专业的任务编排。但现实来看，这并不理想。我踩坑了，有点失望。
不过我仍然希望 Ramble 的智能将来能大幅增强，因为这种语音输入方式确实更像一个能解放生产力的方向。
换个乐观角度想：当前这些困境，比如不得不混用多种工具、自己拆分任务，也可以理解为对思维的一种训练。让自己的逻辑能力变强，而不是变成被 AI 养懒的人。我们在驯服 AI，而不是被 AI 驯服，我只能这么安慰自己。
-
可能是目前最理想的智能语音输入了，从排斥语音输入到遇见 Typeless
为什么我不太喜欢语音输入法
如果大家用过 Windows （下图）和 macOS 的系统自带听写，大概都会对「语音输入」保持一种谨慎的期待：它当然有用，但也很容易让人失望。
最早的阶段，我们用 OS 自带听写，说两句话，屏幕上会出现一段大致正确的文字。可那种体验往往也就止步于「能用」。因为说完之后，还是需要大量手工编辑：口语里的停顿、重复、改口，甚至口误，都会被原封不动地「转录」进文本里，最后修稿的成本并不低。
我很多时候还是更喜欢键盘输入。原因很简单：键盘允许我们边写边停顿，来回修改，甚至先打出半句话再推翻重来，这里面有一种很舒服的「思考节奏感」。有人说这样效率低，我倒不完全认同。我更愿意相信：慢也是一种快。
还有一个无法忽略的因素，是「公共场合的尴尬」。在办公室、咖啡馆、地铁上，对着手机或电脑说话，总会让人感觉自己像个傻瓜。哪怕周围的人根本不在意，我们自己也很难完全放松。
所以坦白说，很多时候我还是会退回键盘，甚至会在很长一段时间里排斥语音输入。
当然，语音输入并非一无是处。它其实很适合两类场景：
一类是大段文字的一次性输入，事后再统一编辑。比如写长文时，削弱输入成本的价值就很明显。
另一类是非常简短的交互，听写几乎不会产生歧义，也不需要手工修正，这时候回报也很直观。但对「介于两者之间」的内容，尤其是那种边写边想、随时调整结构的文本，传统语音输入就很难发挥作用。边说边改，太痛苦了。
因此，我们会自然回避「边说边改」这种场景。但再进一步想：既然 AI 已经这么发达了，为什么它不能更准确地一次识别，甚至顺手优化我们的口语表达，把结果变成一段更令人满意的文本呢？
直到最近，AI 输入法的变化才开始显得有意思。
Typeless 登场
我接触到 Typeless 这种 AI 语音输入法之后，第一次感觉语音输入不必再被拿来和「键盘」竞争了。Typeless 的体验确实胜过我之前用过的很多所谓「智能」语音输入法。对比之下，有些产品更像是在吹牛。
不过我也清楚，这个窗口期可能并不长。很快其他语音输入法就会跟上，整体质量会大幅上升，甚至 Windows 和 macOS 自带的听写也可能会变得和 Typeless 一样优秀，这只是早晚的问题。也许不用一年，甚至在大家读到这篇文章时，类似的产品或更新就已经出现了。所以接下来我对 Typeless 的介绍，就当作让大家提前看了一眼不久后的未来。
先说现状：Typeless 是个多操作系统，多端的产品。其它也有一些类似的 AI 输入法，我相信它们很快会对照 Typeless 的方向做增强。
如果 Typeless 只是「更准一点」的转录听写，那我觉得完全没有必要专门写它。关键在于，它不只是听写转录，更像是一种「语言意图识别」：输入法仿佛理解了我们在说什么，并重新组织文本。可以把它当作一个随身听写秘书，负责把口语里的重复、改口、语气词清理掉，把段落和列表顺手排好，最后落在屏幕上的，是一段更接近「我们本来就想写出来的那段话」。
举个实际例子：按下听写快捷键后，我们说一段话，松开快捷键，Typeless 会思考几秒钟，然后一段整理过的文本就会跃然屏上。
有时候，在当前没有输入焦点的情况下，这段整理后的文字也会直接进入剪贴板，我们可以稍后粘贴到任何地方。Typeless 后台也有转录历史记录，支持随时关闭，或者设置定时自动清理。
还有一个挺神奇的功能：我们可以在屏幕中选中一段已有文本，然后按下快捷键说「帮我翻译成某某语言」，比如「西班牙文」，这段文字就会立刻变成期望的样子。这一下子把很多翻译类小应用、小插件的价值空间都挤压了。
实际上，「输入法」只是个开始。Typeless 的目标不只是帮我们更快输入，而是通过语音接口更好地表达意图。翻译、听写都只是起点，很多 AI 小插件以后恐怕真的可以洗洗睡了。更现实一点说，在操作系统面前，Typeless 也只是个小插件，macOS 和 Windows 随时都可以把这些能力系统级集成进去。只不过大厂通常动作更慢，它们往往会等市场足够接受、反响足够好之后，再来一次性「摘桃子」。
一些注意点
需要注意的是隐私问题：Typeless 目前不是端侧本地模型的输入法。这也解释了为什么它识别时会「思考」几秒，因为需要云端解析。
我们说的话会被传送出去。无论商家如何承诺「零留存」「无记录」来保护隐私，我们始终要意识到：数据确实离开了设备。至于是否愿意承受这个代价，或者只对「不敏感」内容使用听写，这是见仁见智的选择。
Typeless 有免费使用额度，超过额度可以订阅 Pro 版。但定价模式我个人不太喜欢。虽然它功能表现出色，确实容易让人产生付费冲动，但高昂的月付价格配上大幅折扣的年付价格，总让人感到一种熟悉的「捆绑用户」套路。时间窗口也许不长：暗示不到一年，市场可能就会有大变化，所以先把用户锁一年是比较理性的策略。 尽管如此，我还是不得不说，Typeless 产品体验的确很出色，还是有资格要价的，不像那些吹牛骗人的 AI 玩具。 不过还是老生常谈，隐私非常重要，注重隐私的用户，选择 Typeless时 需要非常谨慎。
最后
总之，优秀的语音输入法并不意味着键盘会退场。它只是提供了一种新的选择：我们可以按照自己的表达习惯更流畅地输出内容，AI 帮我们处理剩下的一切。而乐观地看，未来竞争只会更激烈，这类产品会层出不穷。对所有用户来说，这反而是一件大好事。
高效搞定事情，尽情享受生活
效率火箭，火箭君的新博客 