大大，请问这个由段落块转变为嵌入块有什么语法吗？

ob 里面是！[[]]这种，将引用块转变为嵌入块

思源里，没有搜到类似的快捷键

补充楼下的，还有另外两种方法可供参考（只是目前你说的那种“置顶”功能，在文档树里只能手动置顶，狗头无奈，没有像传统笔记软件在右键选项里有“置顶”选项——这个可能是需要 js 动作就能实现？？？最开始是可能有点不习惯，用惯了就会发现这种置顶需求还有更优解）

第一种：用“pin”功能，在横向 tab 栏钉住文档（这可能算是一种置顶吧，弊端是 pin 多了，比较占 tab 栏的位置），将这个文档当做 moc 目录，选你觉得重要的文档复制引用块到里面就行了

第二种：用思源的“小记”插件，使其以 dock 形式常驻（即把那个小记面板调出来，让其常驻思源界面）

之后选择你需要的文档以“复制 md 超链接”的方式，在小记里创建 memo，一个 memo 卡片可以放置很多“引用文档”

建议 memo 卡片也加上标签辅助管理，但弊端也是类似，卡片多了，上下滑动起来可能也不容易找到

不过这个插件目前还在开发中（开发者大大在论坛），后续应该还会继续优化吧

我个人认为，在“书签”“pin”“小记”这三种方式中，最后一种“小记”用来当“索引 index”的潜质最大，因为它可以聚合最多内容，同时管理成本算是相对最低的（不过，如果不是重度需求，还真用不上这个，有点杀鸡焉用牛刀的既视感 😂 ）pin 和书签合起来就可以满足大部分需求了。

元思的最大优点是“卡片式的直观”，它和另一种“画廊”模式还不同，它是真的做到以双链把一张张小卡片链接起来了——这种设计的优势就是，卡片越多效果越好（也不需要整理）【它就是 lattics 那个卡片库之设计理念的移动版，哈哈哈】

然而思源的小记本体，估计不会发展成这个路线，它和思源联动起来，或许可以模拟一个超大号的元思？？？

本来都卸载元思小半年了，你说了之后我又重新去下载

元思是干货卡片，小记是便签，这就是我的分类了，元思可能是我之前用法不对（太花心了，那时候把 ob 思源 logseq 全部都用上，现在慢慢去繁求简），现在我才注意到它有一个 md 导出，以后做多卡片了，可以导出到思源来整理——然而保存的双链啥的就别想了

元思笔记，我是没有想到一个好用的复用机制，但它用来做干货卡，是最方便

感谢，这个关注好几天了，确实很有用。我也有差不多类似的需求，只是之前一直偷懒没有多想（懒到宁愿一直用文档树那个小折叠号，一直都这么麻烦），而且也描绘不清楚这个痛点究竟该怎么解决，800 分太壕了，感谢发帖的大大和回帖的大大 😄 造福一众小白啊哈哈

确实。元思笔记，这种设计用来做卡片体验很好。不过我习惯用手机端记录，pc 端整理，它的整理机制不是很好用……就这点，忍痛弃掉了。但，它才是那个真正符合“卡片笔记”（碎片化）的设计理念，flomo 或者小记，在我看来都是随便用来乱写的便签哈哈哈（微博段子式）

重点还是使用者的取舍 😄

画廊作为一种查看视图，本身就是在提升管理笔记的效率啊。

看板应当是融入工作流，而非工作流本身。

对于一部分只是用思源来记笔记的使用者，看板确实用处不大。

看板适合那种在做某个具体事情，并且每个步骤都会有即时反馈的场景

而笔记的话，则讲究积少成多，注重秩序和管理，画廊以卡片形式分布，更直观易于回顾，增加使用者对自己笔记的掌控和熟悉。（至于画廊有没有图片，应当是使用者自己对于美观的选择罢了）

参考 notion 那种，变成画廊模式后，可以拖来拖去的（再加上思源本体还有文件树），两种视图结合起来，管理和查看的效率还是不错的。

卡片笔记……卡片笔记应该是挺重要的，不是吗？新一代的笔记厂家，受到吸引来选用软件的使用者，所关注的卖点里，核心底层就是这个吧。

赞同。画廊是目前来说，最接近仿真卡片的布局设计

看板背后是很精深的项目管理思维，实际是个很复杂的工具。

看板是应对任务，画廊是应对笔记。

看板有其他专业软件啊，真要 all—in—one，有点不好评，我的看法是专业工具做专业的事。

而画廊是笔记的一个变体形式，本质还是在服务于笔记。

就是需要有一个简单轻量的记录方式来满足心理洁癖啊。

这就是最大的需求。

非要把笔记玩得复杂化，市面上一堆软件。

轻量的小而美的记录软件，三端同步，便于管理的，很少。

每个人都有不同的信息处理流，我不太喜欢 dn 记录一些无关紧要的碎片信息，这就是习惯方式的不同，也不打算改变。

我也不喜欢那种万能军刀的工具箱，因为大多数时候可能就只需要其中某个功能，更不必说，工具箱的众多功能，可能还有其他小插件可替代。

平时经常面临的问题就那么几个，几个小插件就能解决的事，每次都要一个调出工具箱，太繁琐了。

你想的太复杂了，你所谓的那套笔记流，应该是比较正式的

我关注小记，就是因为它和 flomo 的属性重合，而 flomo 是个独立 APP，管理起来比较麻烦，小记直接在思源里，管理起来方便。

你说到 lifelog，难道你会用小记 or flomo 这种来做 lifelog 吗？工具属性都完全不同。

对，和我想的差不多。

我所说的卡片库，不是闪卡，也不是 lattics 那种知识卡。

只是以库的形式将 inbox 的内容分门别类，用于管理。

小记现在，比较偏向 flomo，记录起来倒是方便，管理起来相当麻烦。

所以，我的意思是，一种具备 flomo 轻量记录特性，但又要比 flomo 容易整理的轻量记录插件

支持画廊模式。

看到看板的，大家是不是忘了现在有数据库？

之前用数据库做任务管理，感觉比看板更丝滑。

看板在任务管理方面，感觉更适合多人协同。

在项目推进方面，我是用 dn，这个感觉更顺手，看板那种，记录形式大于实用性，即大多数时候都在纠结看板而没有心力专心做事了。

话说看板我一向的用法，是拿它做读书清单……不过画廊好像也能做到。

支持大大这种记录方式，因为本人也是这种习惯。

有些东西，确实完全不需要用文档来记录啊，真就是些碎碎念。（电脑上也有其他便签，只是有一个和思源联动起来方便整理挺好的）

dn 那种，应用于专项项目，按时间流来记录项目演进很不错，旁支末节最好也围绕着一个项目来记录。而小记的 memo，记的可能是八竿子打不着的东西。

思源本体的记录功能够强大了，不管是闪卡，双链，dn 等等（甚至二级树这种接续传统笔记设计的插件都出来了）所以“大”笔记可能面临的记录整理问题，思源本体基本都有解决方式。

现在就需要小记这种，应用于解决“小”memo 的记录。

总觉得联动方向应该是减少思源本体的管理压力，而不是在小记整理一遍，又放到本体里去整理一遍（对于懒人来说真可怕……）

不太支持这种做法。

我所说的卡片库，只是卡片形式的 memo，不是摘录文本制作的那种卡（那种思源本体有插件，就用本体来做）

并且如果要使用 dn 法，那就直接用思源本体加日历插件就可以了。

小记要是变成思源本体那种复杂的编辑方式，为什么不直接用 dn 呢？

小记本身的轻量记录优势完全被压盖了。

越是碎片越需要一种高效整理法。

dn 以时间纬度，小记是另一种纬度。

小记本身就只是一个便签软件。最好还是围绕这个本质来发散吧。

如果给它赋予太多其他意义，它会不会变成个 mini 版思源？那么和大号思源的联动，又该如何处理？器具越复杂，使用者负担也不小。

哈哈，我想的倒是没有你设计的那么复杂。

我觉得小记这种轻量记录 memo，不太适合当“素材库”（再说思源本体有文件夹和双链，不需要它承担这么重的功能）

我也是看到 lattics 的卡片库受到启发。

但在小记这个插件里——

我定义的“A 小记卡片库”，应当都是即时记录，自己输入的内容（灵感，想法，一些碎碎念）

而 lattics 的卡片库 B，应当类似 anki 那种知识卡吧，知识含量比较高，它还给弄了个闪卡功能辅助，它的卡片库是卡片形式的双链

A 和 B 的区别是

A 是用来辅助文章本体，真的需要引用吗？我看未必。

我设想的是，A 这种卡片库的用法是——

1. 当你看到某个笔记，产生新的想法后，一时又不知道这个想法放在哪里，那就先放在小记里（用来减少产生新的双链，毕竟双链太多，管理成本会增高）如果写着写着变成长篇大论，当然还是挪到思源本体。这里是用来取代 dailynote，让 dailynote 专注于专项任务，只是用来即时记录那无处安放的脑洞，这些脑洞后续可能没有啥价值可能就会随手删掉
2. 当你整理思源笔记时，短期内需要聚合几个跨区文件时，使用小记将其聚在一起，即类似于短期寿命的 moc，用完了就删掉
3. 即，A 只是辅助，思源本体才是真正重要的内容

• 不管是 1，还是 2，它的卡片寿命都比较短暂，达不到素材级别的那种长期，只是作为“提醒”
• 有些 memo，处理的优先级别不同，可能会造成一定累积。
• 小记里的卡片，最后的归宿要么是被删掉，要么就被发送到思源本体，不会长期存在。

而 lattics 的卡片库 B，创始者对 B 的设计理念里，这种卡片库似乎是浓缩的精华。

1. 不可否认，lattics 的卡片库，也具备即时记录充当小记的功能，但介乎它的闪卡 + 全局思维导图这种设计，如果把它当成碎碎念的卡片库，那么这些无关紧要的 memo 就会严重增加管理成本，干扰到真正有价值的内容卡片
2. lattics 里，卡片库的文件夹和左侧文件树直接联动，B 里面的卡片位置，受到左侧树的局限，受到管理成本的驱动，这种设计使得使用者最好别瞎写乱记，只能写下精华思考（这的确是符合卡片笔记法的原教旨设计）
3. B 的卡片库，使用者通过频繁使用和引用，最后会对 B 里面的卡片内容很熟悉。而 A 的卡片库，只是为了记载使用者一闪而过的念头(放在思源里，比放在其他电脑便签软件里，方便整理，仅此而已，它的本质，还是个便签，只是以卡片的形式呈现出来）
4. 即，A 卡片库里的卡片，乃是相对长期，乃是任务卡片，等待删除或整理而已，而 B 卡片库里的卡片，lattics 的设计，分明是希望它变成永久知识卡片，使用次数越多价值越高。

• 综上，如果要达到 B 的卡片库这种设计，对开发者可能是不小的负担，而且我觉得既然都有了 lattics 专器专用，思源的小记没必要李代桃僵。各自发挥所长就行了。
• 再碎碎念一句，lattics 这种卡片库的设计我认为很妙，但在真正实践过程中，这种卡片库的使用上限就是论文，而综合大型的知识管理，我还是倾向于直接用双链来取代这种卡片，毕竟，卡片多了真是非常非常难以管理啊，双链好一点。

大大，写了一点东西，希望可以给你参考。小记插件，未来要当卡片库吗？ - 链滴

下一步，应当是要去研究小记怎么和思源联动了吧。

我之前用过语雀，小记当个三端便签挺好用的，但除此之外，也没其他竞争力。

大大在思源里开发的小记，总感觉只是当个 inbox，有点可惜（毕竟思源本身，比语雀本体好用）

❤️ 这下是真的桌面便签了，赞一个。大大

点赞大大。

现在的全局调用，基本做到了类似桌面便签的效果。

提醒一下，其他小伙伴，想要达到这个效果 ，最好先在思源里设置快捷键，应用于隐藏 or 开启思源界面

如此使用流程就是

1 使用 C S Y 在其他界面可调出小记，记录并使用 C+ 回车保存

2 再使用之前所设置的隐藏思源的快捷键，就可以直接将思源最小化，

全程都不需要使用鼠标，只需要按三次快捷键。

这样问题就来了——

我在想的是，这三个步骤中，调用小记界面 + 隐藏思源界面，这两个快捷键是不可或缺的，但是其中的第二个步骤是否可以去除？

即，调用小记界面，记录内容后，这个保存（C+ 回车）步骤，是必须的吗？如果去除这个步骤，只要写了东西就自动保存，整个记录流程会不会更顺手点？

鉴于这种记录流程一旦确定，就会一直保持，so 积少成多，两步记录的效率，应该总会比三步高出许多来。

只是我不确定，这个插件可以做到这点吗？还是说，这个 C+ 回车用以确定保存的步骤，保留下来更好一点？？？

大大，第二个 issue，这个插件似乎缺了一个面板切换的快捷键。

如图，左上角思源——面板——我所安装的插件中，基本上其他的都有可以切换面板的快捷键，而小记这个，只能通过打开边框栏来跳跃（而我最停驻的面板是二级树插件，没地方放小记了——需要跳跃）

我个人是把边框栏给收起来了，因为感觉有点占位置。

小记重点应该侧重在记录和即时查看，并不需要长期停靠，但有快捷键来辅助面板跳跃，这样更可能方便即时查看和整理吧。

在快捷键列表里，现在只有关于添加 memo 的快捷键。

感谢。这样的话，这个小记可以当做全局便签，同时又联动了思源这个大后方统管的主笔记，可以秒杀其他桌面便签了 😋

大大，请问一下，这个全局调用——

定义是“在打开思源界面的时候开启调用”，以后可能变成在思源界面最小化的时候，使用快捷键也可以将其调用出来吗？

这个应该是思源的设计还是这个插件的问题？

我没有导出过 pdf😂 不好意思没法帮你

第一个要求没太明白意思，可以给个图示来说明一下。

第二个是一个插件，“二级文档列表”，蓝色的那个小图标，意思就是这个二级文档以 dock 状态开启

这种解法我个人持保留意见，看别人的接受度吧。

和大大有同样疑问的人也可以在发帖啊，再讨论其他的改进办法，而不是一味反对现在的需求者啊。

退一步讲，如果保持不变，那么请问大大有可解决这个“子块反链问题”的办法吗？

我给的办法当然不是完美解法，可是现在反链面板的这种展示逻辑，除了重构，还有其他办法可以直接解决需求者所吐槽的问题吗？（既然目前还有 50% 的人投赞成票，无论如何说明，这至少不算个小问题吧）

移动端本来就一般，如果改成类似 logseq 那种，参考 logseq 移动端的反链，我的接受度反而会高一点。

另外，这个问题看似是这几天提出来，其实可以去论坛搜一下，至少两年前就开始有人在陆续提出各种对“反链面板”的吐槽了，建议都差不多类似，关键词【反链面板】这次这个帖子有点类似汇总，不是什么突发奇想。

第一个问题：

通过浮窗确定文档-ctrl 点击标题在编辑器中点开文档查看（alt 则分屏查看），偶尔也要结合一下下方的“提及”面板，快速当然是达不到你要的标准，不过我更偏向这种方式（因为反链面板那点展示空间太小了）

第二个问题：

解法参考第一个问题，另一个方法则是，直接点开要查看的页面，查看页面标题处的数字角标（即不通过反链面板而是浮窗）

仅供参考。

答主，这个解法可否部分解决你的问题？

logseq 支持到页级，这对某些用户是简洁。

思源支持到块级，这对某些用户来说是繁琐。

对这些用户而言，思源的这种块级反链麻烦到没法用，甚至也会有其他次生问题，而这种繁琐，没法通过其他任何插件来避免，只能重新构设面板。

而你的建议，用反链面板来显示反链字块，实际思源还有另一种更高效的“浮窗显示反链”，即对于你的问题，思源早就给出了更加好用的解法，是有备选项的。

一种是必须重新构设才能解决的问题，一种是目前就有备选项可以解决的问题。（相信如果没有浮窗 or 聚焦类似这种辅助，大家也会很乐于支持反链面板支持到块级）

重构后的反链面板能够兼容目前反对者的问题，也没有损害这类人的根本利益，而反对者们的主张 or 建议，既无法兼容这些需求者面临的问题，也没有对人家的问题有什么实质性帮助。

哪个问题更迫切，无需多言。

题主的问题可能是“文档树和大纲”同时放在了左上角

两个挂件占了同一个位置，各有各的宽度限定，当然没法统一。

这里的解法，应当是文档树放左上角，大纲放左下角，这样两个就会统一。

如果必须是“二选一”这种切换选项，宽度会根据标题来变的，当然会切换。

哈哈哈，每个人对工具的理解和用法都不同啦。

对我这样喜欢二级文档树的（以二级树为工具有一套自己方法论的），肯定是质变。

如果不能理解，说明目前的你并不需要二级树，恒河里。

这个帖子，乃是为了回应帮助那些和我一样喜欢二级树的用户，还有吹一波开发者大大而写的。

所写这些，无意冒犯，只是答主的论述实在不够有说服性，建议仿效上一位 @8V9q7V 直接说自己的利益比较好。

因为一个新用户发起的、仅有几十人参与的投票，修改一款有至少几万人的用户的软件长久以来的设定，我觉得是不合理也不合适的。如果当前逻辑不合理，那这几万人这三四年以来用的是什么呢？

这段话语的潜在语境，是在指责这个帖子“用少数绑架多数”，可是答主的说辞，是不是也在用“多数批判少数”？答主的语境是否是“人数多就是正确？”

我这里并不是要批判这个“设定”，而是这个前设放在这个场景下有很多其他因素干扰其推演之结果 light。

举例说明：

1. 为什么只有 31 票？有没有可能长期活跃于论坛所以即便在这种随机时间也会关注到这个帖子的就只有这些人？
2. 由此推导，那些没关注没投票的人，有没有可能并不需要 or 不在乎这个功能？那些不在这个时间段参与投票的用户，有没有可能并不是这个功能的深度使用者或者甚至不是思源笔记的深度使用者？
3. 再进一步推导，万人用户中，小白的比例构成渐占多数，而前行的用户亦并非一开始就是大佬，也是从小白升级而来，一路上经验较多踩坑较多故而问题较多需求较多，这些前行者尽可能填现在的坑，是否也能便于后续用户发现思源其他更多可能修复的坑，而不是大家一起泥足深陷在一个老坑呢？

并且目前的反链逻辑没有任何问题，新用户提完意见用几天没新鲜感走人了，到下一家软件“提意见”，倒霉的是老用户。

没有任何问题，这种论断，可能是否是答主的一家论断？

按答主的逻辑，我也可以说——现在的反链面板一定有问题，不然为什么有人甚至要兴师动众发帖投票要改呢？

至于后续说“新用户提完建议拍拍屁股走人”，这种假设性描述，无法构成事实性论据。

“没有任何问题”，基于客观基准的描绘，可以叫“稳定”，也可以叫“保守”，再过一段时间，可以叫“落后”。

答主还提到了“发帖者是新用户”，那么答主是否有去一一验证这些参与投票者每个人的资历构成，是否每个参与者都是新用户？是否只有一定等级属性的用户才可以参与投票 or 拥有话语权？

并且这个语境下，暗示“新用户不配或者资历经验不够提出这种重大意见”，答主有没有想过，双链笔记并非思源一家独有，也许这里所谓的“新用户”，可能早就是别的双链笔记的深度使用者，只是因为思源某些特质更吸引，所以转到思源。

用户在链滴论坛这个场景下是“新用户”，但大家对“双链”的理解和见解，则不能以此考量吧，重点还是取决于大家提出的看法是否专业与合理吧。

很多投票的人甚至都弄不清楚二者的区别，只是想要“和 rr 一样”

建议答主可以重点说明自己的述求，而不是用一种比较臆断的方式去描绘其他用户画像。

为什么答主认为“投票者弄不清楚二者区别呢？”有没有可能正是因为清楚“两者区别所以才会积极投票呢？”

真吃瓜群众，怎么会参与这种对自己毫无利益瓜葛的事呢？

我猜想你想说的功能应该是类似 obsidian 的 quick explore 这个插件

这个插件就能做到，开启标题级别的文档切换（在开启的文档间）

这种设计确实更让人安心，但就我的使用经验，它大致又是归于“我可以不用你不可以没有”这个区域。

因为真正频繁切换文档时，文档树的页面呈现更直观，调用度更高。

如果是利用标题来在文档树中切换 or 定位，这功能应用于少数文档还好，文档多了就会废（参考文档的移动设计，这时候还不如去文档树切换呢），耗费心智和目视注意力。

并且 因为现在有二级树，这个是不是和二级树的功能有一定的互相取代性？即开发的必要度好像又被降低了一点（要是没二级树的话，这个好像也不错 但文档的拖拽最后还得二级树来实现）

so，花架子，中看，有一定可用性，可以被替代，就是这功能的微妙尴尬之处了。