昵称没什么用，随便写都行

还不如直接去 OB 那里“胖巧侧记”“饮食力道”“醺醺善油”
让他们朝着思源的方向走呢

其实，既然用了 LLM 何必还纠结于跟自己这“一亩三分地”内的知识含量呢

又有几个人的第二大脑能超过 LLM 呢，想干啥，直接让 LLM 现编不就完了吗 😂

如果用 LLM 仅实现“相关度”实属用牛刀了

“那就在思源里继续增加 LLM 的使用场景啊”

这就还是个是倒醋或包饺子的问题啊，啧啧

看完三个开源项目 README.md，我 TM 人都傻了

我这天真的小脑瓜只会“把大象放冰箱”啊

就像第一步蒸馏数据，第二步塞给 LLM，最后得到相关性文档 😋

根据楼上大佬提供信息，我也都去瞥了一眼开源项目

假设已经有可行性的作业可以抄了

又一想，问题还是这蝶饺子不够大，做这蝶醋太费劲啊

开源呢，少有人能有 Z 佬级别的实力

诚然可以做付费，但这碟饺子又难以够量啊

还得继续思考，多过去看看人家的作业再说

也对，其实想到这个问题之前，就应该想到这个肯定有现成作业可看的

是啊

盲猜印象的应该是基于“词汇”的搜索，毕竟之前只有这技术

但是，时代变了啊，当前 LLM 才能更好的从“语义”层面实现相关性

“相关”是个很复杂的概念，比较难以实现，不论是“功能定义”上，还是算法实现上

搜索引擎技术并不是简单的技术，也很难找到简单的组件实现，集市倒是有个用 ES 的当作搜索的插件，但我觉得 ES 最多在搜索上丰富一下功能

要实现“相关”还是比较困难，因为思源是本地存储的笔记，所以本地使用 ES 也是一件几乎难以实现的事情

但当下的确有一条思路，那就是本地运行小参数量的 LLM，实现可能性倒是有了，但距离切实可操作性又是一道道鸿沟，比如合适的模型，较低的硬件需求，方便的部署方案

说到这里，想起可以用插件和在线 API 的形式实现，但要把自己的数据都给云端啊，虽然背离了本地隐私属性，但插件的使用总是因人而异

说到这里，flomo 最近的会员新功能似乎就是这个啊

（费曼说：这不是我的思考结果，这就是我的思考过程）

说白了，别家几百 G 的云笔记空间和这边 8G 的存储空间，不是一个东西

虽然容量可以比较

再就是当前的发展还处于“小而美”的阶段

移除了置顶更新信息还真有些不习惯呢

想起一个央视的采访，快过年了，主持人在高铁上采访“你买到票了吗”🤣

看板还没呢，感觉画廊更要等了

我也有这个问题

每周二最快乐的事就是更新了，这乐趣可不能少

好可爱呀

那李恶心了？

软件一直更新修复问题，完善功能怎么了？

什么时候更新更换数据路径了么？

就是不更新你就知道你数据存储路径了么？

“用户指南”哪里说的不明白了？还是不会找？

哪里给你体验感不好了，说说，说的合理了就可以完善，然后每周更新

有点萌 😄

任何笔记软件间的迁移都会损失格式

思源是开源软件，几乎可以最大程度上实现：

永久升级和维护

有了数据库基础，看板也应该优先从 0 到 1 嘛

现在就是拒绝剪藏整个页面

曾经剪藏过大量页面，后来一篇没看，就算重点标注的那些也没看了

关键剪藏那么多还会污染自己的搜索结果，就是搜索出很多和自己预期相距甚远的内容，还会稀释搜索结果

现在我就用五彩在网页标注好，然后同步到笔记中，按照“年份-月份”进行直接存放，再在其中打几个双链关键词就好了

最早是查找开源博客系统知道了链滴…

后来忘记了怎关注了公众号，很可能是绑定微信为了登录方便吧…

然后有一天那个万年不更的公众号突然说他们做了个笔记软件…

彼时我已经苦于 Evernote 许久…

我也简单的认为一下：

反链面板的功能性需求是远大于可读性需求的

对了，悬浮窗口预览每次只能查看有限的信息，哪里更好了？

我且认为“好的设计是趋同的”，“超乎寻常的论断需要超乎寻常的证据”

仅凭几句“我觉得”还很难谈论到“是否进了误区”的地步

我认为你的认为还不够成熟

还需要多看，多学习，多体会

不要总想搞个大新闻

“大人，时代变了”

这段代码实现了异步执行一个事件的功能。它创建了一个单线程的 ExecutorService，然后使用这个服务执行一个 FutureTask，这个 FutureTask 中包含了真正的事件执行逻辑。虽然这段代码能够工作，但是它有几个潜在的问题和改进的地方：

1. 资源泄露: 每次调用 fireEventAsynchronously 方法时都会创建一个新的 ExecutorService，但是这个服务并没有被明确地关闭。如果这个方法被频繁调用，那么将会创建大量的线程池，但这些线程池不会被自动回收，最终可能导致资源耗尽。为了避免这个问题，可以考虑使用一个共享的 ExecutorService，并在适当的时候关闭它，或者使用 try-with-resources 确保每个创建的服务都能被正确关闭。
2. 返回值问题: 这个方法的返回类型是 Future<T>，但在 Callable 的实现中返回的是 null。这意味着，即使调用者期待一个结果，也得不到有意义的返回值。这可能不是设计上的问题，但如果有返回值的期待，应该重新考虑这个实现。
3. 异常处理: Callable 中的 call 方法抛出了一个异常，但是在异步执行的环境中，异常的处理会比较复杂。调用者需要明确地从返回的 Future 中检查和处理异常，这可能是一个容易被忽视的地方。
4. 同步问题: 代码中使用了 synchronizedEventQueue.fireEvent(event); 进行事件触发，这表明可能存在对事件队列的同步控制。但是，在异步执行的环境下，仅仅依靠方法级别的同步可能不足以保证线程安全，具体取决于 synchronizedEventQueue 的实现和使用方式。
5. 效率问题: 如果事件处理通常很快，使用单独的线程池可能是一个过重的解决方案，因为线程的创建和销毁都是昂贵的操作。在这种情况下，可以考虑使用一个已经存在的线程池，或者其他轻量级的并发机制。

综上所述，虽然这段代码能够实现基本功能，但在实际使用中可能会遇到资源管理、性能和设计上的问题。考虑到这些潜在问题，重构代码以使用共享的 ExecutorService，改善异常处理和同步机制，以及澄清方法的返回值，都是值得考虑的改进方向。

禀赋效应，大概就是你觉得重要的功能就是“核心优势”
哈哈，其实思源是个复杂的系统，很难一概而论的

为什么要“有用”呢

明明就是喜欢啊

喜欢还不够吗

双链 + 本地 + 开源 + 插件 + 闪卡 + 手机伺服 + 敏捷开发 + 男女搭配干活不累

算是形成合力，复合优势吧

就算还有啥不顺手，也可以探讨，说不定下个版本更新上了

“数据历史”哪里不好用可以列一列，说不定就更容易的解决了

感谢付出，等待回归

不能听信一些小白在那里瞎提需求

不过，我觉得，就这句，说的，总还是，有那么点，道理的

我现在都还没摸索明白呢，赶紧深挖优化

自己都没搞明白，怎么就知道谁是大神了，因为他字多么