-
把剪贴板变成 AI 收件箱：我最近整理信息碎片的方法
我已经很少使用剪藏类插件了
最近我在试一种很朴素却很顺手的信息整理方法：浏览网页时，先不要急着分类或收藏为笔记，更不要打开某个复杂的知识管理系统，我会把看到的内容先丢进剪贴板历史里，对，就是一股脑都复制到剪贴板里。
顺便一说，这不是什么心血来潮，临时拼凑的技巧，我已经实践了6，7个月了，才在这里分享给大家。
这个方法的前提很简单：我每天会浏览很多网页，包括产品文档、博客文章、论坛讨论、工具说明、GitHub issue、用户反馈、新闻资料、摘要，甚至一些社交媒体里的短句。过去我总想在看到一段内容时，就立刻判断它应该放到哪里：是项目资料，还是产品灵感，还是写作素材，还是某个主题研究的一部分。
这种刚看到内容就开始分类的动作，其实很打断心流。
阅读时，我不应该过早切换到整理状态。阅读本来应该保持流动，一旦开始思考「这段内容放在哪个文件夹」「要不要新建一篇笔记」「标题该怎么写」「标签用哪个」，阅读节奏就被彻底打断了。
所以我现在的第一步过程非常「粗暴」：看到有用的内容，就直接复制。
先复制，不整理
这里的关键不是复制全文，这点很重要。
无脑复制全文，本质上还是另一种通篇收藏。多数时候，我只是复制一段文字，有时候只复制一句话。有时候是网页里的观点，有时候是某个段落里的描述，有时候只是一个让我想起别的问题的表达。
复制之后，我不马上处理，也不马上写进 Obsidian 或其他笔记工具，而是继续阅读下去。
我用的是 Ditto 这样的剪贴板历史工具。Ditto 是 Windows 下的工具，我用了很多年。macOS 下也有类似的 Paste 等工具。它们会把复制过的片段临时存起来。等浏览告一段落，再从 Ditto 里把最近一批剪贴板内容一次性导出或粘贴出来，生成一个很大的文本块。整个过程都是快捷键操作，并不复杂。
这个打包在一起的「大文本块」通常很乱。里面可能有重复内容，可能有网页残留格式，也可能是标题和正文混在一起，不同文章之间未必有明确划分。
以前我一定不会这样做，因为保存的结果根本没法直接用，还要花很多心思整理。现在有了 AI 之后，我反而觉得，这种杂乱但有一定筛选痕迹的文本块，正是 AI 适合处理的材料。
我只负责在阅读时判断什么值得留下，AI 则负责把这些碎片信息整理成可用的笔记。
把大文本扔给 AI
我现在会把这份大文本扔给 Codex，或者其他支持文件读写的 AI 客户端，比如 OpenCode、Claude Code 之类都可以。
重点不是一定要使用哪一个客户端，而是它要能根据预设规则，把一大堆杂乱的信息拆成多篇可读的 Markdown 笔记，并保存到指定位置。
这一步我通常不会只说一句「帮我整理一下」，这可能是最糟糕的指令，就像和老板和员工说，「帮我弄一下」，这是什么意思？。
我会预先准备一个技能、规则文件，或者 prompt，让 AI 按照固定方式工作。每个人可以按照自己的习惯和领域，给 AI 设置不同要求。我的基本规则大致是：
- 先识别不同主题，不要把明显不相关的内容混成一篇。
- 每个主题生成一篇独立的 Markdown 笔记。
- 笔记标题要根据内容自动概括，或者识别出剪贴板内容里已经存在的标题文本。
- 不要随意改写原文，重要表述保留摘录状态，并串联在一起。
- 将结果保存到指定目录，比如
Inbox/Clipboard/，或者某个分类文件夹。
这样做以后，剪贴板就变成了一个很轻量的 AI 收件箱。
我不需要在浏览时停下来建笔记。复制动作本身就是采集动作。等到后面统一处理时，AI 再帮我做分割、命名、归类和初步摘要。
标签不要靠临场发挥
这套流程真正变得稳定，是从我开始给 AI 预先设置标签规则之后。
如果完全让 AI 自由发挥，它很容易生成一堆看似合理、但实际不可维护的标签。比如今天生成
productivity，明天生成productivity-tools，后天又来一个workflow。这些标签单独看都没错，但长期会把笔记系统搞乱。所以我更倾向于给它一张固定标签表，或者至少给出明确的标签规则。
下面只是一个例子，不是我的实际标签表：
allowed_tags:- ai- workflow- pkm- writing- product-research- investment-research- obsidian- local-first- automation- reading-notes然后要求 AI：
- 只能从
allowed_tags中选择标签。 - 每篇笔记至少 1 个标签，最多 4 个标签。
- 如果没有合适标签，使用
inbox，不要创造新标签。 - 如果内容涉及多个主题，优先选择最具体的标签。
我更希望 AI 根据内容理解来分类，而不是随手发明一套新的元数据。
这样生成出来的笔记不会特别完美，但基本能进入我的系统，而不是变成另一批需要整理的垃圾。
也不要对标签有过度苛刻的要求。因为有了 AI 之后，完全可以事后按照新的标签规则，对已经保存的文件重新分类。换句话说，不要苛求一次到位。
这比直接保存网页更适合我
很多工具都支持网页剪藏，但我一直觉得网页剪藏有一个问题：它太「无脑」了。
收藏网页很容易带来一种错觉，好像内容已经被处理过了。实际上，它只是被保存了，甚至可能从来没有被完整读过一次。
剪贴板方法反而更克制。因为我复制的是当下注意到的部分，而不是整页网页。它天然已经经过第一轮粗筛。即使复制得很随意，也比完整网页更接近我的真实兴趣点。
换言之，网页剪藏保存的是网页，剪贴板保存的是注意力。它更接近我当时真正注意到的东西。这里面已经包含了一层筛选和判断。如果能顺手加上批注，就更好了。
浏览时只负责阅读和发现，AI 处理时负责拆分，笔记系统负责长期保存。每个环节只做一件事，反而比一边阅读一边整理更稳定。
进阶：让 AI 定期做二次整理
在这套流程基础上，还可以加一层定期总结。
比如每周两次，让 AI 扫描
Inbox/Clipboard/里最近新增的笔记，生成一篇阶段性总结。如果是按周总结，还可以让 AI 找出更高层次的趋势。比如这一周我复制了很多关于某类 AI 工作流的材料，那它就应该提醒我：这不是孤立兴趣，而是一个正在形成的研究方向。
这个总结不一定要自动写进正式笔记。它可以先放在
Review/Weekly/文件夹里，作为二次加工的入口。真正有价值的内容，再进入项目笔记或者 backlog。还有一个很实用的地方：一旦标签分类规则发生改变，可以事后让 AI 对存量文件重新分类。
这在以前是无法想象的工作量。但是有了 AI 之后，这件事不再复杂，反而很实用。这也是一种二次整理。
我现在更愿意把 AI 当成一个助理，而不是一个代替我思考和阅读的大脑，我现在非常反感「第二大脑」的说法，一般当作低劣的营销噱头来看。AI 不需要也不应该替我决定什么重要，但它可以帮我把散落的内容粘合起来，分堆、贴标签，并生成初步索引。
工具为次，理念为先
这套方法最有价值的地方，不是 Ditto，不是 Codex，甚至都不是具体的 prompt。
它真正改变的是信息整理的顺序。
过去常见的顺序是：
看到信息 → 判断价值 → 找位置 → 建笔记 → 写标题 → 打标签 → 保存
稍微偷懒一点，则变成：
看到信息 → 保存收藏 → 想着以后整理 → 大概率吃灰
现在变成：
看到信息 → 复制 → 继续阅读 → 复制 …… → 批量交给 AI → 自动拆分 → 自动打标签 → 定期回顾
之前要求我在阅读过程中不断切换身份：一会儿是读者，一会儿是资料管理员，一会儿是编辑，一会儿又是项目经理。后者则让我专注眼前的阅读，把一些琐碎的整理动作规则化，并交给 AI 自动处理。
当然，这不是一个完美系统。它仍然需要定期清理，也需要不断调整标签规则。AI 也会误判主题，偶尔会把应该分开的内容合在一起，或者把一个片段解释得过头。
剪贴板原本只是一个临时缓存。加上剪贴历史工具和 AI 之后，它可以变成一个低摩擦的信息入口。
这大概也是我现在对 AI 工具最实际的期待：不是替我思考，而是把我已经注意到的东西，按我设定的规则整理好就行。
-
压缩个人的知识线索，把 Markdown 批注重新找回来：Obsidian SideBar Highlights 的侧边栏工作流
关于 Markdown 批注
我一直有给笔记做批注的习惯。
有时候只是把一句话高亮标出来，提醒自己以后再看；有时候则会在后面写一段自己的评论，记录当时为什么觉得这句话重要，或者它和我正在研究的某个问题有什么关系。
这件事听起来很小，但如果长期阅读、写作、做研究，或者经常整理资料，就会发现：高亮和批注其实不是装饰，而是一种非常基础的信息加工动作。对于很多基于 PDF 论文工作流的人来说，这已经是日常操作。只不过我面对的不是 PDF，而是 Markdown 笔记。
毕竟原文可能只是网页摘录，也可能来自别人的观点，批注才真正属于自己。
过去很长一段时间里，我对 Markdown 语法的用法了解得并不深，所以一直用最简单的方式处理这类需求。比如用「加粗」表示重点，用「斜体」表示补充说明，或者直接在原文下面另起一行，写上「我的看法」。（很粗糙的做法，是吗？）
这种方式当然也能用，而且很直接。但它不够清晰。
一篇文章里如果到处都是加粗，很快就分不清哪些是原文重点，哪些是我自己的判断；如果评论直接混在正文里，过一段时间再打开，就会有点像考古：当时这句话到底是引用，还是我自己写的？这段补充是临时想法，还是已经整理过的结论？
后来我才知道，Markdown 生态里其实有一些更适合批注的写法。
比如在很多 Markdown 工具里，可以用：
==高亮部分==用来表示高亮内容。
在 Obsidian 里，还可以用：
%%批注内容%%用来生成备注或注释。
这比单纯加粗要明确得多。高亮就是高亮，批注就是批注，正文、重点和个人评论之间开始有了边界。
再后来，我又查到了一种叫 CriticMarkup 的标注语法。它看起来比普通 Markdown 稍复杂，但表达能力也更完整。它不仅可以表示新增内容、删除内容，还可以表示替换、评论和高亮。比如：
{++新增内容++}{--删除内容--}{旧内容~>新内容}{>>评论内容<<}{==高亮内容==}它的思路很像一种纯文本版本的「修订模式」。
过去我们在 Microsoft Word 里审阅 DOCX 文件时，会看到某个人增加了哪句话，删除了哪一段，旁边还有评论气泡。CriticMarkup 想做的事情，某种程度上就是把这套审阅动作搬回到纯文本里。
这点对我很有吸引力。因为它不依赖某一个特定软件，也不一定要进入复杂的在线协作系统。只要文本本身还在，标注信息就依然还在，不会被锁进某个云端 SaaS 的评论数据库里。
当然，CriticMarkup 原本更偏向多人协作场景。几个人共同修改一份文章、文档或手稿，需要知道谁删了什么、谁加了什么、哪些地方还有争议。这套逻辑和 Word 的审阅功能有点像，只是表达方式更朴素，也更接近 Markdown 用户熟悉的纯文本工作流。
但我后来意识到，它也不一定只能用于多人协作。到了今天，另一个很常见的批注者，可能就是 AI Agent。
比如我写完一段文章，让 AI 帮我 review，它不一定非要直接改掉原文。更好的方式可能是：保留原文，让 AI 用某种批注语法标出哪里表达不清、哪里逻辑跳跃、哪里可以补充例子。
这样我既能看到建议，又不会失去对文章的控制权。这和我一直喜欢的本地优先工作方式很契合。
我不太喜欢把所有资料都塞进一个在线平台，再依赖平台提供的评论、任务、协作和版本功能。它们确实强大，但也会让一份原本简单的文本变得越来越重。
相反，如果批注本身就能留在 Markdown 文件里，那么无论我用 Obsidian、VS Code，还是其它本地编辑器打开，它都仍然是可读、可检索、可迁移的。
这时候，Markdown 也可以变成一种轻量的审阅格式。
我可以给摘录加高亮，可以给段落加评论，可以让 AI 留下修改建议，也可以在以后重新回到这些批注里，判断哪些想法值得展开，哪些只是当时的一闪而过。
不过，高亮和批注只是第一步。
真正的问题是：当我们有了足够多的笔记高亮和评论批注之后，下一步该怎么办？
一开始，几条高亮很好处理。它们就躺在原文里，打开笔记就能看到。
但当一个资料库里有几十篇文章、几百条摘录、上千处高亮之后，情况就变了。高亮不再只是「醒目的黄色标记」，而会变成一堆散落在不同文件里的信息碎片。
你曾经觉得重要的句子，可能已经被埋在很深的目录里；你写过的评论，可能再也不会被重新看见。
这时候，我们需要的就不只是「能高亮」了。
我们需要的是：能把高亮和批注重新收集起来、整理出来，变成可以回顾、筛选、重组的材料。
也就是说，批注的价值不只在于标记当下，而在于它们能否在未来再次浮现出来。
这也是我后来开始关注 SideBar Highlights 这类 Obsidian 插件的原因。
SideBar Highlights 登场
我试过很多 Obsidian 插件，但真正能留下来的并不多。
有些插件野心太大，什么都想做，界面复杂，设置复杂，工作流也复杂。还有一些插件则刚好相反，功能太薄，几乎没有真正解决问题。
所以我后来对 Obsidian 插件有一个很朴素的判断标准：它最好只解决一个清晰的问题，但要把这个问题解决得足够顺手。
对于高亮和批注这件事，我还有一个附加要求：批注信息必须保留在原来的 Markdown 文本文件里，不要另外开一个数据库出来。
因为一旦批注被单独存到某个插件数据库里，它就开始脱离原文了。
今天这个插件还在，当然一切都好；但如果以后插件停止维护、换设备、迁移笔记库，或者我只是想用 VS Code 打开这些 Markdown 文件，那些批注信息还能不能跟着走，就变成了问题。
我不希望自己的阅读痕迹被锁在某个插件里。
我更希望它们就是文本本身的一部分。高亮也好，评论也好，任务也好，都应该和原文待在一起。这样哪怕脱离 Obsidian，哪怕以后换一套工具，这些信息依然可以被看见、被搜索、被处理。
SideBar Highlights 基本上正好符合我的需求。
侧边栏高亮列表
最核心的功能当然是侧边栏列表。
打开一篇笔记后，SideBar Highlights 会把里面的高亮内容集中显示出来。对于长文来说，这个体验非常直接。你不用在正文里滚动查找，只要看侧边栏，就能知道这篇笔记里有哪些地方曾经被你标记过。但需要注意的是，这里所谓的高亮，是指 == ，%%，和脚注（包括 尾注 和 inline）；但并不支持 CriticMarkup 语法， CriticMarkup 太专业了，更适合协作，而不是个人批注使用。
这有点像给长文自动生成了一份「个人重点目录」。
普通目录显示的是标题结构，而 SideBar Highlights 显示的是阅读结构。标题是作者安排的，高亮是我自己留下的。两者合起来，才更接近一篇文章真正被理解和处理过的样子。
也可以把它理解成一份围绕个人阅读痕迹生成的侧边目录。
你不需要重新阅读整篇文章，就能先看到自己当时标出来的重点。看到某一条内容时，也可以直接跳转回原文所在位置。
这就很适合二次阅读。
第一次阅读时，我可能只是顺手高亮；第二次打开时，我不一定想从头读到尾，而是想快速回到那些曾经触动我的地方。
SideBar Highlights 提供的侧边栏列表，就像是把这篇文章压缩成了一组可以跳转的线索。
颜色和 Collection
更进一步，SideBar Highlights 不只是显示高亮。
如果你给不同类型的批注使用不同颜色，它也可以帮助你区分这些内容。
比如我可以把事实信息标成一种颜色，把值得引用的句子标成另一种颜色，把需要追问的问题标成第三种颜色。这样一来，高亮就不只是「我觉得这里重要」，而可以进一步变成一种分类动作。
如果想把散落在各篇笔记里的标记聚合到一起，除了通过颜色区分，也可以通过 Collection 重新组织。
Collection 可以理解成一个分组，或者类似文件夹结构，用来把选定类型的批注汇聚到一个地方。
不过这里也要注意：Collection 会保存到专门的外部文件中，所以它和直接留在 Markdown 原文里的高亮不完全一样。不是说 Collection 不能用，而是它已经不是完全嵌在原 Markdown 文件里的信息了。从数据迁移和长期可控的角度看，这里多少会有点风险。
所以我个人觉得，如果没有强烈需求，未必一定要用 Collection。只靠 Markdown 原文里的高亮、注释和颜色分类，对很多个人使用场景来说，已经足够了。
筛选和过滤
有了高亮列表，并不意味着我一定要一次看完所有高亮，而可以只看某一类标注。
比如只看某种颜色，只看某一组 Collection，或者只看当前阶段真正关心的内容。
当高亮越来越多之后，新的问题很快就会出现：信息太多了。
原来我们是担心重要内容被正文淹没，现在又变成了高亮本身太多，需要继续筛选。
SideBar Highlights 支持多种筛选语法。对多数个人使用场景来说，已经足够。
比如我只想看「问题类批注」，或者只想看某个项目相关的高亮，就不必再从全部标记里手动翻找。它本质上是在高亮之上，又加了一层索引能力。
从正文，到正文的索引，再到索引的索引，某种程度上，这正是我们学习和整理知识的过程：从复杂材料中抽象出一个压缩模型。LLM 理解语言世界的方式，或许也有点类似。
默认隐藏的 Task Tab
还有一个容易被忽略的小功能：SideBar Highlights 里有一个默认隐藏的 Task Tab，我也是无意中发现的。
打开之后，它可以把 Markdown 笔记中的代办任务（
- [ ]语法）汇聚到一起显示。也就是说，那些散落在不同笔记里的任务，不再需要靠手动翻找了。
这点和高亮列表的逻辑其实是一致的。
高亮负责把重要内容从正文里提取出来，Task Tab 则负责把后续行动从笔记里提取出来。这样一来，一边批注，一边生成后续任务，也就变得很自然。
比如我在阅读时看到一个问题，可以在旁边写下评论；如果这个问题值得继续研究，就顺手写成一个 Markdown 任务。之后再回到 Task Tab，就能看到这些从阅读中自然生长出来的行动项。
更妙的是，这些任务仍然留在 Markdown 里。
不一定需要额外的待办工具，而且任务和上下文天然绑定在一起。它不是孤零零的一条 todo，而是和原文、摘录、评论、高亮待在同一个语境里。
这对我来说很重要。
很多任务管理工具的问题是，任务被抽离得太干净了。你只看到「继续研究某某问题」，但过了几天，可能已经忘了这个任务是从哪篇文章、哪句话、哪个想法里来的。
而如果任务本身就留在 Markdown 笔记里，它的上下文就不会丢。
最后
所以我觉得，SideBar Highlights 的意义更像是把高亮变成了一种可操作的对象。
以前高亮只是留在原文里的颜色痕迹，现在它可以被集中查看，可以跳转，可以筛选，可以分类，也可以放入 Collection。
它开始变成一种真正的索引，就像标签一样；也是一种回到原文的入口，就像标题目录一样。
更重要的是，我一直觉得这是一种把长文，或者大量笔记，重新压缩成个人可理解知识的方法。
Markdown 给了我一个足够简单、足够稳定的文本底座。高亮和批注让我在这个文本底座上留下自己的阅读痕迹。而 SideBar Highlights 做的事情，就是把这些痕迹重新收集起来，让它们不只是躺在原文里，而是重新变成可以被看见、被筛选、被组织、被再次利用的材料。
这也是我喜欢这类小插件的原因。它只是围绕一个很具体的问题，并给出完美的的解决，把那些散落在 Markdown 里的高亮和批注压缩成为个人的「知识线索」。
SideBar Highlights 官方开源地址
https://github.com/trevware/obsidian-sidebar-highlights
直接在Obsidian 插件社区搜索 SideBar Highlights，就能安装。
-
【译】我在 OmniFocus 中待了九年。然后我改用文本文件来管理。
写在前面
在 GTD 风潮兴起的时期，OmniFocus 曾经是任务管理 App 中的一代经典。
直到今天，OmniFocus 仍有大量粉丝。毫不夸张地讲，它影响了后来很多 todo 类工具，甚至在苹果自带的「提醒事项」里，也能看到 OmniFocus 的影子，比如后文会讲到的「透视图」。
我个人从 OmniFocus 2 开始入坑，但现在已经退烧很久了。我很想讲讲自己为什么退烧，但又很难归纳。最近，我看到一篇文章，讲述作者如何从 OmniFocus 切换到纯文本任务管理，我觉得和自己的经历有不少相似之处。因此，特别想分享给大家。
在分享之前，我要提醒一下：下面的文章对于一些读者来说，可能比较生涩。我已经尽力简化和注释了。我觉得文章的理念比较重要，大家不要纠结于里面的具体代码。即使完全不会代码，也有大量第三方工具可以实现类似的功能。
大家会看到 Obsidian、Logseq 的影子。如果看到 Denote 那部分，是不是也会对「文件名标签」唤起一丝熟悉感？而纯文本对同步的友好性，以及对 AI 工具的加成，例如 Claude Code、Codex，也会是未来的重要方向。这一切，都是效率火箭这些年来反复提到的东西。
最后再啰嗦一句，每个人的情况都不太一样。OmniFocus 之类的 todo 工具仍旧有用武之地，只是一部分作用被分流出去了。原作者恰好是一名后端工程师，那么绝大多数工作任务都可以被更「接地气」的方式分流出去，并不是说每个人都要做相同的实践。
我个人也仍旧保留了 todo 工具，但显然也注意到，大量具体工作任务已经被分流到了具体的项目文件夹里，并且开始和 AI 进行协作。可能这也是 OmniFocus 这类重度 todo 工具逐渐退出我视线的原因之一。
原作者：Max Holovanov
原文链接：https://medium.com/@maxclax/i-spent-9-years-in-omnifocus-then-i-switched-to-a-text-file-4190628ed11f
火箭君整理、编辑、翻译。以下正文。正文
我觉得，OmniFocus 是花钱能买到的最好任务管理器。我用了九年，然而现在我转向了「纯文本」。
与 OmniFocus 共事的九年
我大约在 2011 年开始使用 OmniFocus。
九年来，它管理着我的生活，直到 2020 年，我把一切迁到了 org-mode。我想一开始就说清楚：它是一款出色的软件。如果今天有人问我「花钱能买到的最佳任务管理器是什么」，我仍会毫不犹豫地说是 OmniFocus。
它把重要的东西做得恰到好处。收件箱捕捉是瞬时的。项目模型可靠。推迟日期、回顾周期、视角，整个 GTD 机制都在，而且打磨得光亮如新。移动端应用也确实出色：可以随时随地捕捉想法，也可以在火车上回顾任务，或站在商店里查看某个情境。多年来，那恰恰是我生活所需的视图，它实现了这一点。我通过它推进的每一个项目都达成了结果，没有任何事情被遗漏。
这是一个故事：一个曾经非常有用的工具，如何因为「用户摩擦」而逐渐退出我的工作流。
没人提起的「摩擦」
以下是我在日复一日使用 OmniFocus 时开始感受到的问题：我花在视图切换上的时间出乎意料地多。
OmniFocus 是围绕透视视图构建的。透视视图本质上是保存好的筛选器，可以按情境、项目、标签、可用性来划分任务。透视视图很强大。但功能强大，也意味着透视视图很容易越建越多。
我会打开应用，然后开始来回切换：收件箱，然后是预测视图，然后是一个自定义透视视图，然后是项目，再切回。每次切换都很微小。它们都不是实际工作，而是工作的管理，是运行一个复杂到需要导航的系统所付出的代价。
把每天一个微小的代价乘以多年，它就不再微小。
我一直在反复思考一个挥之不去的问题：如果系统可以变得更简单会怎样？不是能力降低，而是更简单。如果我的任务更贴近实际工作所在，而我不必特意去「导航」到它们那里，会怎样？
为什么选择 Org-mode
我在其他一切事情上已经生活在 Emacs 里。Org-mode 就在那里，优势显而易见：任务就是
.org文件中的纯文本。没有数据库，没有同步引擎，没有专有格式。任务就是一行。项目就是一个文件。议程是对那些文件的一次查询。诚实地说，Org-mode 真正阻碍我的问题是「移动端」。OmniFocus 的手机应用是我九年来一直依赖的东西，我不想放弃人在办公桌以外的任务捕捉和回顾能力。
现在，BeOrg 这款 App 完全解决了这个问题。这是一个 iOS 应用，可以直接从 iCloud 或 Dropbox 读取和写入纯 Org 文件。在手机上捕捉到收件箱、勾掉 TODO、浏览议程，离线也可用，并且会以纯文本同步回去。只要我确认移动端捕捉仍然可行，留下来的最后一个理由就消失了。
桌面端的捕捉保持刻意简单，甚至有些无趣。一个收件箱文件，一个模板：
(setq org-default-notes-file(expand-file-name "inbox.org" org-directory))(setq org-capture-templates'(("t" "Quick todo → inbox" entry(file org-default-notes-file)"* TODO %?")))用快捷键输入想法，完成。从手机上的 BeOrg 应用也会追加到同一个
inbox.org。一个收件箱，两台设备，零转换。
真正的原因：任务就在工作发生的地方
移动端曾是阻碍。但那并不是根本原因。真正的原因是：
当我在处理一个项目时，我已经在它的目录和文件中。使用 Org-mode，我可以直接在上下文中写下任务，不需要切换应用，也不需要在一个单独的工具中重新查找项目。每个项目都有自己的路线图文件
ROADMAP.org，所谓的 Agenda（议程视图）则简单地将它们全部收集起来。
这是 OmniFocus 透视视图从未给过我的东西。任务不再驻留在一个我必须专门去访问的工具里。它就位于我正在执行的工作旁边，议程只是负责把它们汇总出来。
这一单一改变，几乎一次性消除了所有视图切换的摩擦。再也没有「打开任务管理器」这一步了。任务管理器就是我已经在编辑的那些文件。
我重新调整了流程，因为议程扫描会蔓延
我的第一个本能，是把
ROADMAP.org文件直接散布在每个代码仓库里。感觉很纯粹：路线图就和工作文件、源码并排而居。后来事实证明，这是个错误，Emacs 很快就让我意识到了这一点。每次启动都变得更慢。
一旦你看到原因，它其实很简单。Org 的议程通过扫描目录来构建文件列表。如果你把它指向包含代码项目的目录树，它会递归进入
node_modules、.git、build/、vendor/，成千上万的文件在每次议程构建时都要走一遍。要么你永远维护一份小心翼翼的排除列表，要么你接受慢启动。这两者都意味着系统开始要求你管理系统本身，而这正是我想要逃离的东西。于是结构演进了。我没有再把路线图文件散落在各个代码仓库里，而是迁移到一个单一、专用的笔记目录，并为每个项目创建一条自己的 Denote 注记。
Denote 是一个极简的笔记包：每个文件都有一个带时间戳和关键词标签的名称，基本上这就是全部理念。设置很简单：
(use-package! denote:config(setq denote-directory "~/org")(setq denote-file-type 'org);; Lifecycle keywords — project / area / resource / archive(setq denote-known-keywords'("project" "area" "resource" "archive""reference" "meeting" "idea" "someday")))火箭君注：Denote 是一个文本笔记，但是 文件名上包含标签和时间戳之类的「元信息」，这样系统就可以根据预定义规则，按照标签等条件筛选内容展示。
每个项目就是一条 Denote 笔记，标记为
project，并具有一个可预测的内部结构：目标、下一步动作、未来某天。议程只扫描这一目录，而这个目录也只包含笔记。没有需要排除的东西，因为这个目录附近根本没有node_modules：;; Skip dotfiles; only ever scan the notes directory — never code repos(setq org-agenda-file-regexp "\\`[^.].*\\.org\\'")(setq org-agenda-files(seq-filter(lambda (f) (not (string-match-p "/templates/" f)))(directory-files-recursively "~/org" "\\.org$")))是的，我放弃了「任务就在源文件旁边」那种纯粹性。换来的回报是，一个启动即用、永远不需要调校的系统。这个权衡显然是正确的。Denote 最终让整件事呈现出来的是简单，而不只是纯文本。
关于同步：别想太多
有一段时间，我用 Syncthing 来同步一切。它能用，而且如果设备从不接触商业云服务，它仍然是个相当不错的选择。
但对于纯粹的 Org 文件来说，说实话，这有点大材小用。Org 模式下，信息只是一些小小的纯文本文件而已。没有什么数据库会损坏，没有复杂的数据结构，也不需要合并引擎。所以我让显而易见的工具做显而易见的事情：笔记目录放在 iCloud Drive 上。BeOrg 在我手机上读取同一个 iCloud 文件夹。当然，Google Drive 同样可以胜任。
纯文本才是这里的特点。任何同步方式都行，因为没有什么需要智能同步。它只是单纯的文件而已。
我没料到的回报：AI 时代的纯文本优势
当我在 2020 年切换时，我根本没在考虑人工智能。事实证明，它比这份清单上的其他任何东西都更重要。
Org-mode 不会删除已完成的工作，它会把它归档。在一个已完成的任务上按下一组快捷键，整个子树就会移动到一个归档文件：标题、
CLOSED时间戳、优先级、标签，以及你一路上添加的所有笔记。;; Completed tasks move to a dated archive, not the void(setq org-archive-location "~/org/archive/%s_archive::")想想那个归档实际上是什么。Git 历史记录告诉你代码发生了什么变化。你的 Org 归档告诉你，你决定做什么、为什么要做，以及它已经完成。这些都用你自己的话记录了意图和结果。这是一种不同的、在某些方面更丰富的日志：项目的记忆，而不仅仅是差异。
而且因为它是纯文本，人工智能可以读取所有内容。我可以把六个月的归档任务交给模型，并提出真实的问题：是什么一直阻碍了这个项目？时间到底都花在哪儿了？我上次接触这个东西时都说了什么？归档不再是坟场，而是一个输入。项目的每一个新阶段，都可以以它自身的历史作为上下文，既为我提供参考，也为模型提供参考。
专有的任务数据库做不到这一点。它的历史被锁在只有供应商应用才能理解的格式里。纯文本对所有工具都保持可读，包括那些在你写下这些内容时还不存在的工具。这就是纯文本在长期里悄然胜出的理由：你不是在为当下的应用选择格式，而是在为明年的工具仍能读取的格式做选择。
Org-mode 负责运行任务，我仍然手工规划结果
到这里，如果用「现在一切都在 Org-mode 里」来给本文作结，会显得优雅整洁。但那并不真实。
Org-mode 运行我所有的任务和整个日程，包括捕获、项目、截止日期、每日回顾。那是执行层，而且完全数字化。但高于任务的那一层，也就是决定一个季度走向的少数几件事，我仍然手工规划。
为此，我为 Kindle Scribe 自己制作的一个计划本，因为在四月之前，市面上的七个现成计划本都没能满足我。
每天三件成果，每周三件，每月三件，每年三件。这个限制「三」就是重点。
「三」会迫使我做出真正的选择，而不是列一张愿望清单。并且成果要写成已经完成后的状态：不是「完成报告」，而是「我完成了报告，现在我可以……」。这会把注意力拉到影响上，而不是动作本身。
为什么把那部分保留为纸质？因为任务和成果需要不同的仪式。任务需要快速、可查询、可自动化，这正好是 Org-mode 的风格。成果则需要慢下来。我用电子墨水手写，没有通知，也没有可点按的东西。这种摩擦反而是有益的：它让我在 Org-mode 把一周填满动作之前，先静下来思考什么是真正重要的。
所以真正的系统是两层的。决策目标用手写，决定三项成果。Org-mode 以数字形式，执行所有属于这些成果的任务。纯文本并没有取代纸张，它解放了纸张，让纸张去做它仍然最擅长的那一件事。
这一切值得吗？
诚实地说，总有取舍。
OmniFocus 更加精致。它的移动端、复习模式、推迟和预览体验，所有这些都确实比我搭建的任何东西好。如果你想要一个安装当天就能完美运行的系统，就买 OmniFocus，别再往下看了。
Org-mode 是一个项目，而不是一次购买。我花了真金白银的时间去让捕捉、议程和 Denote 协同工作。你在读这篇文章，是为了跳过其中的一些步骤，但不可能全部跳过。
前提是，工作流里本来就需要 Emacs。我并不是为了任务采用 Emacs；我本来就长期生活在 Emacs 里。如果各位没有这种需求，情况就完全不同。
火箭君注：即使大家不是代码开发者，比如作者，比如分析师，比如咨询业，只要工作围绕着数字文件展开，其实仍旧可以基于项目文件夹工作，就像我一样，因此这个思路一样成立。这也是 Obsidian 之类工具兴起的原因之一。
我获得的是：我的任务不再是我偶尔访问的地方。它们和我的工作并列，以纯文本文件存在，由议程统一查询，再通过一个文件夹完成同步。那种视图切换的成本，每天一点点，持续九年，终于消失了。
OmniFocus 并没有输。我只是想要更少的系统，而纯文本是唯一能给我这种感觉的方式。
补充
原作者的完整 Org 和 Denote 配置：
https://github.com/maxclax/dotfiles
BeOrg 官网：
-
对于不得不使用 Windows 的生产力用户来说， 一定要装上 最新的 PowerToy，它原本就应该集成在 Windows 里面
写在前面
我不想争论是 Windows 系统优秀，还是 macOS，还是 Linux。三者各有千秋，而且不少地方也有逐渐趋同的样子。一定要概括一下三者的优劣，我大概会这么说：
macOS：更好的使用体验，绝大多数消费级软件（除了游戏）的支持，苹果生态的加成，但也有较狭隘的硬件选择范围，和较高的苹果税。macOS 面向消费者更多些，而且用户体验相对出色。
Windows：有很多习惯上和历史上的积累，更好的外设驱动，更多的硬件选择，预算可以从简朴到奢华，也有不少可折腾的地方；但是原生功能和体验经常让人无语。很多时候我甚至觉得，Windows 应该放弃桌面，只保留运行时，其它东西索性交给第三方算了。Windows 面向工作者更多些。
Linux：很适合折腾，但对于消费级用户和传统意义上的生产力用户，实在不算友好。如果只是学习和测试，Windows WSL、macOS 终端都有很不错的替代性。考虑到 Linux 是大量网络，移动设备和云端系统的基础操作之一， Linux 面向开发者更多些。
我们还是说回 Windows。Windows 不是那种特别适合伴随我们生活的系统，但是工作上可能会非常需要，尤其是追求结果而不是过程的那种工作。
问题在于，Windows 自带的很多功能都缺乏考虑。即使对专业用户来说，也经常有掣肘。
所以，我今天想说的就是 PowerToys，一整套为 power user 准备的 Windows 实用工具。它可以改善 Windows 缺失的那些功能，如标题所说，其中很多功能，原本就应该集成在 Windows 里面。
新版 PowerToys 登场
截至目前，PowerToys 最新稳定版是 v0.99系列，真正值得关注的新功能包括 Power Display、Grab And Move，以及 Command Palette、Dock、Keyboard Manager、ZoomIt 等工具的改进。
PowerToys 出自 Microsoft 自己，是一套免费、开源的 Windows 工具集合。微软是一个很奇怪的组织，里面山头林立，有些部门的产品就让人很伤脑筋，而有些部门的产品就很优秀，比如： WSL，Powershell 这种就很优秀， 也许普通用户注意不到，但生产力用户就很受用。
PowerToys 的定位是：帮助 power users 和开发者更好地使用 Windows，补足一些系统本身没有提供，或者提供得不够顺手的能力。呵呵，像是一个部门对另一个部门的补丁。
早年的 PowerToys 只是零星几个小工具，后来逐渐壮大，变成了一个包罗万象的工具箱。现在它已经不是简单的「高级用户玩具」，而是很多 Windows 用户都可以直接受益的生产力补丁。
它主要包括几类工具：
- 第一类是窗口和桌面管理，比如 FancyZones、Always On Top、Grab And Move、Workspaces。
- 第二类是文件处理，比如 PowerRename、Image Resizer、Peek、File Explorer add-ons、File Locksmith。
- 第三类是输入和快捷操作，比如 Keyboard Manager、PowerToys Run、Command Palette、Quick Accent、Advanced Paste。
- 第四类是屏幕工具，比如 Color Picker、Screen Ruler、Text Extractor、ZoomIt、Mouse utilities。
- 第五类是系统增强，比如 Awake、Hosts File Editor、Environment Variables、Registry Preview、Mouse Without Borders。
微软官方文档目前列出的可用工具已经超过 25 个。
这套工具最有意思的地方在于，它不是一个巨大的软件，而是一组可以单独开关的小工具，加上一个中心控制面板。小工具我们不需要全用，也不需要被迫接受某种工作流。只要根据需要开启对应的小工具选项即可。
这次比较有特色的新增功能：Power Display
新版 PowerToys 里，我最先注意到的是 Power Display。
这个功能解决的是一个很具体、但很多桌面用户都会遇到的问题：外接显示器太难调了。
很多显示器的实体按键都藏在背后，菜单逻辑也很别扭。调个亮度、对比度、输入源，像是在和显示器斗智斗勇。尤其是多显示器用户，或者一台显示器接多台设备的人，调整显示器设置一直是一件小但烦的事情。
Power Display 的思路很直接：把显示器控制放到 Windows 系统托盘里。启用之后，它会自动检测连接的显示器。如果显示器支持相应控制能力，就可以直接调整亮度、对比度、音量、输入源、色彩配置等内容。它还支持创建 profiles，也就是显示器配置预设，方便一键切换不同场景。
这类功能本来就应该是系统级能力。笔记本内屏可以调亮度，外接显示器却经常要靠显示器背后的按钮，这件事终于有解决了。
Grab And Move：移动窗口终于不用瞄准标题栏
另一个新增功能是 Grab And Move。 我个人超级喜欢。
它的作用非常简单：默认按住 Alt，然后在窗口任意位置左键拖动，就能移动窗口；按住 Alt 右键拖动，就能调整窗口大小。如果 Alt 和你的使用习惯冲突，也可以换成 Win 键（我就换成了 Win 键）。
这听起来像是一个小功能，但用过类似桌面环境的人应该知道，它会明显减少窗口管理里的摩擦。
Windows 里很多窗口边缘很窄，标题栏又经常被各种自定义界面改掉。特别是在大屏、多屏、远程桌面、高分辨率屏幕上，移动和调整窗口并不总是舒服。Grab And Move 让你不需要去找标题栏，也不需要精准对准边缘，只要鼠标在窗口里面，就能完成操作。
Command Palette 和 Dock：Windows 本该有一个命令入口
PowerToys 以前最受欢迎的功能之一是 PowerToys Run，一个类似启动器的工具。现在 Microsoft 明显在推动 Command Palette，把它变成更统一的命令入口。 根据我以前的印象， PowerToys Run 似乎和 Wox 这款知名的 Windows 启动器有一定的渊源。
Command Palette 不只是打开 App，还可以访问命令、工具、扩展、计算器、Terminal profiles 等。新版里，Command Palette 和 Dock 有很多改进，包括 Compact Dock、始终置顶、计算器历史、命令固定方式优化，以及扩展内容显示能力增强。
Windows 的入口一直太分散。开始菜单、搜索框、任务栏、系统托盘、右键菜单、快捷键、设置页，各管各的。Command Palette 的意义不是替代所有入口，而是给重度用户一个更快、更统一的操作中心。 这是 Windows 应该自带的，就像 macOS 的 Spotlight，结果 Widnows11 原生给了一个不知什么东西糊的开始菜单。
如果我们每天反复打开固定工具、运行固定命令、切换 Terminal 环境，Command Palette 就会比开始菜单更像一个真正的工作台。
我个人比较喜欢的几个老功能
如果你第一次装 PowerToys，我不建议一口气把所有功能打开。我个人比较喜欢的几个老功能是 FancyZones、Peek、PowerRename、Image Resizer。
FancyZones 是窗口分区工具。Windows 自带分屏已经比以前好很多，但还是不够自由。FancyZones 可以自己画窗口布局，把软件拖进去自动吸附。对 27 寸以上显示器、超宽屏、多屏用户来说，这个功能很值得开。
Peek 是快速预览文件。选中文件后，不用打开完整应用，就能看内容。图片、PDF、Markdown、代码文件、文本文件都很适合这种方式。它有点像 macOS 里的快速查看，但放在 Windows 里就显得格外必要。
PowerRename 用来批量改名。替换文件名、正则匹配、撤销操作，这些功能如果没有专门工具，靠 Windows 原生资源管理器会很痛苦。
Image Resizer 则适合经常处理图片的人。右键就能批量调整尺寸，不用每次打开图片编辑软件。写博客、发图、整理截图时很省事。
一些比较小众的工具
下面这些，也许不是人人需要，但我有时或之前会用到。
Always On Top，可以快速将一个窗口 始终钉在最前面，就像固定桌面便签那种。 我发现还是有些 bug 的，不是所有窗口有效。
Keyboard Manager，这个工具可以重映射按键和快捷键，比如把不常用的按键改成更顺手的组合。实际上，我后来都是用 AHK 替代。
如果你经常临时需要电脑不要休眠，比如下载文件、跑任务、开会投屏，可以开 Awake。它的好处是不用改系统电源计划，用完关掉即可，类似 macOS 下的 Amphetamine 这类工具。
Advanced Paste，它可以把剪贴板内容转换成你需要的格式，也包含可选的 AI 能力。但我不推荐使用，因为剪贴板工具很多，而且剪贴板内容很敏感，经常会有账户密码之类的信息。
最后
PowerToys 最有价值的地方，不是它有多酷，而是它真的在补 Windows 的日常短，PowerToys 是 Windows 最应该内置的补丁包。
如果我们现在还在用 Windows，而且每天都要在文件、窗口、截图、文本、显示器之间来回切换，PowerToys 值得安装一次。也不要功能全开，只挑真的会用的那几个工具打开使用即可。
PowerToys 不会把 Windows 变成 macOS，也不会把桌面系统变成什么理想形态。它只是让 Windows 多一点顺手，让我们将更多精力投入专注工作，这就够了。
PowerToys 官网地址
-
Markdown已死？ HTML才是未来？ 这可能是个巨大的误解。
突如其来的唱衰
这周，突然一篇来自 Claude Code 内部人员 Thariq 的文章，在圈内大火。 引起了非常热烈的讨论。
这篇名为《Using Claude Code: The Unreasonable Effectiveness of HTML》的文章，大意是说，应该用 HTML 作为 人与AI交流的基本格式； 而不是目前广泛采用的 Markdown 格式。 原作者列出了一堆理由，也列举出了利弊。
但是在我看来，这篇唱衰 Markdown 的文章，并不是那么简单，复合了不少的误解。下面我会附原文的翻译摘要和我的观点一起进行讲解。
原文很长，但是翻来覆去就是几句话，大致核心是：AI 能力的提升，传统的 Markdown 格式已经成为限制，AI 代理（如 Claude Code）和人的交互应该全面转向 HTML，以获得更高的信息密度、更好的视觉体验和交互能力。。
原文摘要及我的的观点
1. 关于“信息密度与表现力”
原文观点引用：
“HTML 能传达比 Markdown 丰富得多的信息。它不仅能处理文本，还能通过 CSS 呈现设计、用 SVG 绘制插图。这完美替代了 Markdown 中低效且难看的 ASCII 字符画。”火箭君的观点：复杂不等于高效，内容与表现应该分离。
Markdown 的核心哲学正是「内容与表现分离」，它强迫 AI 和 用户专注于逻辑和文本本身。
让 AI 生成包含大量 HTML 标签、内联 CSS 和 SVG 路径的代码，会引入海量的无意义样板代码。此外，现代 Markdown 除了可以 完美的HTML 渲染以外，还可以通过集成 Mermaid 或 PlantUML 完美实现流程图和架构图。这种声明式的图表语法比臃肿的 HTML/SVG 源码更干净、更易于人类修改。
2. 关于“视觉清晰与易读性”
原文观点引用：
“超过 100 行的 Markdown 几乎没人愿意仔细看。而 HTML 可以通过标签页、折叠面板、响应式排版等视觉结构，将庞杂的系统设计或代码逻辑整理得井井有条。”
火箭君的观点：源码的可读性才是更重要的可读性。
HTML 只有被渲染后才易读，其纯文本源码（Raw Source）是完全反人类阅读的。而 Markdown 无论是否经过渲染，其纯文本本身就具备极强的结构化和可读性，这对于习惯在终端或代码编辑器中工作的知识工作者至关重要。无论是写文章还是写代码都是一样的，这是参与思考的过程。
当然，现在有种观点，人类未来不需要阅读源码，无论是写作，报告，还是 vibe coding， 源码都交给 AI 就好了。那我只能说，放弃读源码，实际是在外包自己的思考过程，等到大家都不再思考源码时，大家也就没有了自己的思考能力，只能看着 AI 生成的华丽输出傻笑了（目前已经明显有这个趋势了）。
3. 关于“分享体验”
原文观点引用：
“Markdown 在浏览器中缺乏原生渲染支持，往往需要作为附件发送。而 HTML 文件只需上传（如 S3）即可生成链接，同事们可以在任何设备上直接点开阅读，大大提高了分享效率。”火箭君的观点：增加了基础设施依赖与安全风险。
实际上，HTML 的分享门槛远高于 Markdown。分享稍微复杂一点的 HTML 需要专门的托管服务（如 AWS S3、Vercel 等），这不仅增加了基础设施成本，还带来了权限控制和数据泄露的安全风险。
相反，Markdown 是现代协作工具的“通用语言”。你可以直接将 Markdown 粘贴到 GitHub、GitLab、Notion 或 Slack 中，它们都会提供完美的原生渲染。不需要任何“上传文件并生成链接”的繁琐步骤。
我个人也介绍了很多 Markdown 编辑器（含渲染），Windows Notepad 也开始支持 MD 了， 这已经是一种默认的新文本文件格式了。 很难想象，2026年，一个严肃的知识工作者居然会打不开 Markdown 文件。
4. 关于“双向交互与自定义编辑器”
原文观点引用：
“HTML 支持双向交互。当文本框难以描述需求时，你可以让 AI 为你写一个‘一次性编辑器’（如拖拽式的工单看板、特性开关表单），调整满意后再将数据导出回 AI。”
火箭君的观点：过度工程化且充满安全隐患。
让 AI 编写带有 JavaScript 的“一次性交互界面”实在是过度工程化了。
首先，运行 AI 生成的未经审查的 JavaScript 代码可能导致 XSS 攻击或本地数据泄露。 原本只要好好的看文本，现在变成了还要运行代码。
其次，AI 生成的交互逻辑往往存在 瑕疵 Bug，难道还要为调试这些“一次性工具”，去花费的时间？直接用文本解决原问题，不是更好吗？我一直主张，关注内容，关注问题本身，而不是花哨的形式。 纯纯的 shi 上雕花。
5. 关于“生成速度与 Token 成本”
原文观点引用：
“虽然生成 HTML 通常比 Markdown 慢 2-4 倍，且消耗更多 Token，但在当前百万级上下文窗口下，这点消耗微乎其微，结果绝对物有所值。”火箭君的观点：稀释 用户 和 AI 两方的注意力。
姑且我们相信仅仅慢了2-4 倍。 抛开这些问题，因为AI算力，我假设以后一直会增长，一年后或许的确不是大问题了。
但在交互式 AI 体验中是灾难性的。哪怕慢2-4倍，等待几分钟只为了看一个排版花哨的报告，会严重打断用户的心流。
更重要的是，即使上下文窗口足够大，生成大量冗余的 HTML 标签也会严重稀释 AI 的注意力（Attention 机制），导致模型在长文本中迷失核心逻辑，增加产生幻觉的概率。同时，输出 Token 的成倍增加直接等同于 API 成本的激增。
而这一切，原本都是没有必要的。（哦，对了，你们是按 token 用量卖套餐的，这就解释得通了）
6. 关于审查和版本控制
原文观点引用：
“这是最大的缺点。HTML 的 Diff 噪音很大，确实不如 Markdown 容易审查。”火箭君的观点：无法进行审查，注定只能是玩具。
原文作者轻描淡写地承认了这一点。但是审查和版本管理，尤其是审查是不可避免的，如果我们讨论的是严肃的生产力的话。审查意味着有人参与的阅读理解，或者工具辅助的比较（比如 diff，但是多数情况下，非代码类的可能用不到 diff，但肉眼审查还是需要的）
不能被审查，意味着不能进入合规的企业用途，也很难成为效率生产的一部分（后续会带来混乱），只能在很浅的应用里打转，接近于轻娱乐和自嗨这类，我一直喜欢说的，这就是另一个“AI玩具”，闪闪发光，好玩，有新鲜感，然并卵，热度褪去后，什么也不是。
Claude Code 原本是一个真正的生产力工具，最后却要和一众 AI 玩具争夺市场？
最后
《HTML 超乎想象的有效性》一文确实展示了 AI 在前端生成方面的强大能力，HTML 也确实能做出好看的“演示工具” 或者 “AI玩具”，这是事实。
但是，Markdown 才是知识工作实践的基石。用 HTML 替代 Markdown 交互，本质上是为了追求视觉上的“华丽”，而牺牲了源码可读性、安全性、生态兼容性和审查控制能力。
在生产力的领域里，这不是专业的做法，也无疑是本末倒置的做法。无论 AI 以什么方式介入我们的工作，保持简单、专注内容，才是高效工作或协作的真正解法，这也是我这么多年的经验之谈。
顺便一说，Claude Code 借内部人士之口，鼓励大家用更耗 token 的方式使用 AI， 属于利益相反（COI），本身就有商业伦理上的可疑之处，值得我们注意。 （他原本完全可以说，给你们提供一个输出方式的选择 HTML，而不是说替代 Markdown ）
Thariq 原文地址
-
【译】Obsidian 实际上是一个自定义的应用平台，而 AI Coding让每个人都能解锁它
写在前面
我突然意识到，Obsidian 之所以在一些用户中受到欢迎，是因为很多知识工作者的日常工作流，其实都可以简化为基于纯文本的记录。
不需要特别的专有程序。
如果各位需要画 CAD、剪视频、数学建模、电路设计……那可能就需要专门工具了。即使如此，仍旧有相当一部分工作流，只需要文本记录即可，比如协作沟通记录、文摘、脚本草稿、写作草稿……
我一直推崇 Obsidian 的 File over app 理念。简单的文件成了主角，双链引用和标签则成了连接信息的枢纽。而它真正的平台潜力，正来自这种可扩展性。
如果大家关注 Obsidian 这几年的发展，可能会产生一种感觉：且不说无数第三方插件，随着官方 Canvas、Bases 陆续推出，Obsidian 已经不再只是一个单纯的 Markdown 笔记工具，而更像是一套基于新理念的个人工作台。
它是一个开放平台。如果你想在 Obsidian 里加入一个自己的应用，完全可以通过插件的形式来实现。这是以前 MS Office 很难做到的事情。一定要做当然也可以，但非常复杂。
现在有了 AI，实现 Obsidian 插件的门槛就更低了。
最近我读到 TfTHacker 一篇文章。他是很有影响力的海外科技博主，文章里分享了自己为何以及如何构建一个基于 Obsidian 的自用西班牙语学习 App。
看到开头部分时，我立刻感到它和我之前的想法高度吻合，同时也提醒了我一些此前忽略的事情。于是，我毫不犹豫地决定翻译并分享给大家。
以下正文，火箭君翻译并略作编辑。原作者：TfTHacker，原文出自：https://tfthacker.com/
正文
我刚刚构建了一个完全可用的学习 App：抽认卡（Flashcards）、语音识别、临时刷题模式。
而且，我自己一行代码都没写。
它完全本地运行，没有服务器，没有数据库，也不需要托管费用。它能在我的电脑、手机和平板上运行，甚至任何人都可以安装。
听起来很神奇，其中的秘密是：我把这个 App 做成了一个 Obsidian 插件。
而我是通过和一个 AI 对话，完成了整个构建过程。
让我解释一下为什么这件事很重要。
我们共同的问题
也许每个人都有过一个关于工具的想法。
这个工具往往和自己的工作或学习方式密切相关。我们去应用商店寻找，却发现没有合适的。
我们有时也想自己构建它，但现实很快摆在面前：也许我不是开发者，所以不知道如何构建应用。即便我是开发者，也需要一台 Web 服务器、一个数据库、前端代码、后端代码、托管和部署。
为了一个可能只有自己会用的个人工具，付出这么多努力？
那就有点过头了。
于是，这个工具 App 的想法就在脑中夭折了。
和其他大多数想法一样。
Obsidian 里藏着一些东西
大多数人忽略了一点：Obsidian 不仅仅是一个 Markdown 编辑器。
它是一个完整的应用运行时。
Runtime，火箭君注：可以简单理解为一个程序运行所需要的环境。
在底层，Obsidian 是一个 Electron 应用。也就是说，它本质上是一个可以运行网页应用的完整浏览器环境。
它支持 HTML、CSS 和 JavaScript。这些也是驱动互联网大多数内容的基础技术。
这让它成了一块非常适合构建界面的灵活画布。
但它还不止于此。
Obsidian 还悄悄提供了每个应用都需要的三样东西。
存储
我们的 vault 就是数据库。
数据保存在你自己拥有的本地文件中。不需要 SQL，不需要云端配置，也不需要第三方依赖。
同步
如果你使用 Obsidian Sync、iCloud 或类似服务，你的数据本来就已经可以在设备之间同步。
你的应用可以直接继承这一点。
分发
我们构建的一切，都可以以 Obsidian 插件的形式存在。
插件有一条明确的分发路径：你可以通过 BRAT 私密分享，也可以提交到 Obsidian 的社区插件目录。
界面、存储、同步、分发。
这四件事组合在一起，就是一个完整的应用平台。
而它其实一直就在那里。
AI Coding 改变了谁能构建软件
通过与 AI 代理对话来构建软件。
描述你想要的东西，让 AI 编写代码。
像 OpenAI Codex 和 Claude Code 这样的工具，已经让这件事变得可行。
关键转变在于：我们需要的核心技能不再只是编程，而是清晰表达。
我们能描述 App 应该做什么吗？我们能测试它，并用语言解释哪里出问题了吗？
如果能，我们就能构建软件。
我们是产品经理，AI 就是开发者。
现在，我们把这些点连起来。
AI 编码降低了亲自编写代码的必要性。Obsidian 降低了对服务器、数据库和部署基础设施的依赖。
二者结合，创造了一种新的可能性：一个个人应用平台。任何愿意描述自己想要什么，并持续迭代直到可用的人，都可以尝试构建属于自己的工具。
我亲自测试过，下面是整个过程。
我构建了一个西班牙语数字学习插件
我在学西班牙语。
根据以往的语言学习经验，我知道，掌握数字是基础。
我需要一个非常具体的工具：用于识别书面数字的抽认卡、用于强化训练的突击模式，以及用于通过听力识别数字的听力练习功能。
现有工具都无法按我需要的方式，同时满足这三点。
我需要一个专门为我打造的应用。
于是，我在屏幕一侧打开 AI 代理，另一侧打开 Obsidian。
我告诉 AI，我正在构建一个 Obsidian 插件，并让它参考正确的 Obsidian 文档，包括示例插件、开发指南、发布规范和 CLI 参考。
它读完这些内容后，很快理清了方向。
然后，我们一起制定规格说明。
我描述每个功能：抽认卡流程、突击模式逻辑、数据存储、视觉布局。
AI 代理会在对话过程中，把规格说明整理出来。
接下来就是一个循环：
AI 生成代码，我把它放进 Obsidian 里测试。
我会告诉它：
「这个按钮应该放在这里。」
「数据在不同会话之间没有保存下来。」
「突击模式需要提高答错数字的出现权重。」
AI 会进行修改。
如此反复继续。
当它能在电脑、手机和平板上运行时，我让 AI 代理把项目整理成可以发布到 GitHub 的状态，包括 README、许可证、发布配置和完整的打包步骤。
最后，我把它发布了。
其他用户可以通过 BRAT 安装。
在这个过程中，我从未直接接触过代码。
整个应用都是通过对话构建出来的。
接下来，说些真实感受
我不会夸大其词。
实际上，过程中遇到的问题大致如下。
引导一个 AI 代理，本身就是一项真正的工作
你可以把它当成一个聪明但缺乏经验的合作者来管理。
它能产出惊人的成果，但它不会读心术。
你要提供方向，发现错误，并在它偏离时纠正路线。
规格说明是最难的部分
在任何代码编写之前，你必须深入思考自己真正想要什么。
功能是什么？流程是什么？边界情况是什么？
AI 代理可以帮助制定规格，但主导者仍然是你。
AI 开发速度更快，但并不是瞬间完成
我的西班牙语数字插件，是一个相对聚焦的应用。
即便如此，它也花了大约一天半。
如果手动编写代码，可能要花我一周左右。
这确实是显著提速，但别指望能在一小时内，把一个想法直接变成成品。
测试能发现 AI 漏掉的问题
我的插件在为某些数字类型生成西班牙语时出错。
这可能会让用户学到错误内容。
我不得不添加额外验证，并推动 AI 代理写出更好的测试。
AI 捕捉不到所有 bug。
我必须自己对质量负责。
发布过程仍然有些技术性
我需要阅读文档，并理解 Obsidian 插件分发系统的基本概念。
这不一定需要亲自编写代码，但确实需要获取相关背景信息。
我希望 Obsidian 未来能进一步简化这一过程。
谁应该尝试这个？
对于希望根据自己的工作流精确定制工具的个人用户来说，这种 AI Coding 方法很理想。
对于通过共享 vault 或共享文件夹来同步插件和数据的小团队来说，这种方法同样适用。
它并不是为复杂后端、大规模多用户应用而设计的。
但如果是个人工具、小团队实用程序和定制工作流呢？
它确实打开了一种新的可能性。
更大的图景
我们正处于一个转折点。
AI 大幅降低了构建软件的门槛，但软件仍然需要一个运行和承载的地方。
它需要界面、存储、同步，以及分发给用户的方式。
Obsidian 提供了所有这些。悄无声息。没有喧嚣。它一直就是一个应用平台。
想一想，大家希望存在的那个工具。
那个完全符合你需求、完全匹配你工作流的工具，可能一直不存在。
而且，应用商店里往往也找不到它。
现在再想想，构建它的门槛从未如此之低。
几乎不需要学习编程。不需要搭建服务器。
你只需要描述自己想要什么，并愿意不断迭代，直到它真正可用。
平台已经在那里，AI 也已经足够可用。
剩下的问题是：你是否真的知道自己想要一个什么工具，并愿意把它一点点打磨出来。
原文作者（TfTGancker）制作西班牙语学习 App 的 Github repo:
-
让 AI 帮我们画流图，我试了几种 Excalidraw MCP 方案
很久以前，我介绍过一些在线流程图工具，当时有很多人都表现出极大的兴趣。如今转眼已经到了 2026 年，在 AI 大行其道的当下，我突然发现，已经出现了可以几乎完全依赖 AI 来绘制流程图的方案。
只要把要求交代给 AI，它就能先把图画出来，后面我再细调或修改，效率比以前手工绘制高了不少。
首先还是要讲一下 Excalidraw。它是一个流行的开源绘图工具，不过这并不是今天的重点。这个工具已经出现很久了，很多软件都围绕它做了集成或插件支持，比如 VSCode、Obsidian，甚至它的官网在线版也是开箱即用。
顺便一说，Excalidraw 插件比 Obsidian 官方的 Canvas 还要早，直到今天仍然位居插件下载排行前几名。开源也意味着它更容易被 AI 接入和操作。
所以，今天真正要讲的重点还是 AI。毕竟，不管是 Excalidraw，还是其他那些画面更精致、功能更丰富的流程图工具，选择其实很多。但 AI 集成是另一回事。
这里我更看重的是智能化体验。和 AI 说话，直接出图，不用关心具体工具细节，也不用研究各种操作技巧。我们可以把自己想象成一个管理者，只负责把需求讲清楚，剩下的事情交给操作员去完成。至于操作员用什么工具、怎么画，那反而不是重点。
开始之前，先准备好 AI 客户端
在开始之前，我们得先准备好 AI 客户端。这虽然不是本期画图的重点，但几乎是之后所有 AI 协作的前提之一。
我们以前介绍 Obsidian Skills 时，也是一样需要 AI 客户端。当时我印象里用的是 Goose，这次我试了试 Codex。
除了 Codex，我们也可以用 Claude Code、OpenCode、Goose 等等。可选择的 AI 模型也各不相同，这个就按大家的喜好来选即可。就我自己的判断看，AI 客户端这一层很难拉开长期差距，最终大多会趋同，你有的功能我也会有，而且迭代速度都很快。
Excalidraw 官方 MCP
Excalidraw.com 官方也下场做了 MCP，走的是 MCP Apps，也就是交互式界面这条路线。它更像一个带交互界面的 MCP 应用，可以在聊天窗口里直接生成 HTML 交互界面。
设置也很简单。告诉 AI 客户端，我要使用
github.com/excalidraw/excalidraw-mcp，帮我把它封装成一个 Skill，以后我就可以通过 Skill 远程调用这个官方 MCP。AI 会自动查询文档并完成 Skill 设置。不同客户端的操作方式可能略有不同，但核心机制是一样的。需要注意的是，这个官方开源 MCP 既可以自部署，也可以远程调用。我们这次主要试了试远程调用，后面也会讲到另一个偏本地自部署的方案。
AI 设置完毕之后，后面就可以直接通过 Skill 要求它出图了。
比如，我这里的使用方式就是这样。
AI 在完成思考并调用 MCP 之后，就会生成这样的图。我们可以直接在 Excalidraw 官网打开，再进行编辑、保存和导出。
从我的理解看，Excalidraw.com 官方的思路，可能就是通过 MCP 把用户引导到 Excalidraw 网站上。这个网站本身就是个在线工具，免费开箱即用，甚至可以把本地文件直接拖进去立刻编辑。如果有更重度、更高频的需求，包括更紧密的 AI 集成，以及云端分享和协作，官网也会进一步把我们引导到 Excalidraw+ 的付费订阅方案上。
就我的实际使用感受来说，官方 MCP 的整体表现算是中规中矩，速度也比较一般，而且最后还是要回到网页里打开。当然，你也可以把 MCP 自行部署到本地或自己的服务器上。总体来说，这更适合轻量、临时的使用场景。如果你本来就有比较重度的画图需求，那我反而会建议直接订阅 Excalidraw+ ( 7美金每月 )。
@cmd8/excalidraw-mcp：一个纯本地的 Excalidraw MCP
如果你和我一样，更偏向本地优先，那我会更推荐
@cmd8/excalidraw-mcp这款开源 MCP。它不是最花哨的，但它很可控。这是目前最贴合我工作流的方案。它的路线相当克制，从安装那一刻起，它就要求你指定一个明确的本地路径。它暴露给 AI 的能力也很克制，比如创建节点、创建连线、删除元素、读取整张图的状态等等。
这意味着我们不需要开网页，也不用经过 Excalidraw 官网。你只需要像平时让 AI 改代码一样，把需求甚至修改意见直接交给它，AI 就会去修改本地那个
.excalidraw文件。
因为它本质上就是本地文件，所以很适合直接纳入版本管理，方便审阅和提交。这一下就把整条工具链打通了。查看绘图文件需要我们自己安装一个可以打开的工具，比方说，我这里是 VSCode 加 Excalidraw 插件，或者其它的什么兼容的 App 都可以。对于 Codex 这类本就擅长处理本地工程文件的 AI 客户端来说，这种方案确实非常顺手。
同样，初始设置也不复杂。我们只要告诉 AI，要封装一个 Skill，基于
@cmd8/excalidraw-mcp这个开源项目来生成图，剩下的基本就交给 AI 去处理即可。其它选择
除了上面两个 Excalidraw 相关的 MCP 之外，其实还有一些别的路线。
比如
yctimlin/mcp_excalidraw，这是一套更「重」的实时白板工作台。它需要在本地同时跑两个进程，一个是本地网页上的 Canvas server，另一个是 MCP server。它提供了几十个工具，支持元素级的增删改查、场景描述，甚至截图导出。但对我来说，这条路线就有点太重了。如果我真的有这种需求，我大概率会选择某种本地专业工具来完成操作，让 AI 先给个草稿，再回到专业工具里编辑，但是长远来看，未来的 AI 或许真的可以事无巨细的全包下来。
另外，还有一个不属于 Excalidraw 体系的替代选择。那就是：如果我们本身就是 Obsidian 的重度用户，那我上次介绍的 Obsidian Skills，其实已经包含了对 Obsidian Canvas 的操作能力，也能画出流程图，而且能更好地和 Obsidian 笔记引用结合，整体上也更轻量。
唯一的遗憾是，Canvas 和 Excalidraw 毕竟是两套不同的体系。Obsidian Canvas 只属于 Obsidian，而 Excalidraw 的生态基础更广，在各种软件里也更容易找到现成的集成和兼容支持。
最后：AI 应用风暴，才刚刚开始
如果只是想最快看到效果，或者想给团队做个酷炫一点的演示，那就选官方方案，体验在聊天窗口里直接出图的感觉。
如果想要一个能反复打磨细节的画图助理，那可以去折腾
yctimlin的实时画布方案。如果想要 All-in-Obsidian，那就继续用 Obsidian Skills 去制作 Canvas。虽然不是 Excalidraw，但在 Obsidian 工作流里依然很好用。
而如果和我一样，只是想在 Codex 这类客户端里，把架构图当成本地资源的一部分来管理，那我会更推荐
@cmd8/excalidraw-mcp。至于 MCP 或 Skill 的未来，也许真的会像官方方案暗示的那样，把聊天客户端逐步变成一个个真正的应用容器。这件事很值得期待，因为它很可能会让不少套壳式 AI 产品或轻量工具，开始显得没有那么必要。
AI 生成流程图、架构图、关系图这些能力，可能还只是个开始。更大范围应用形态变化的「风暴」，恐怕已经在路上了。
-
在 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 集成那种「赶时髦」类型，属于朴素但实用的功能。希望大家如果真正需要生产力，能够用得上。
高效搞定事情，尽情享受生活
