作为一个经常和服务器、运维打交道的人，我的 Blinko 里积累了大量的：


服务器账号密码


运维命令脚本


各种技术技巧


但有个问题： AI 在帮我工作时，往往先去查文档或百度，而不是先看我已有的笔记。
“你笔记里明明有，为什么不先查？”
所以我决定：让 AI 把我的笔记当作权威知识库。
Blinko 是什么
Blinko 是一个开源、自托管的 AI 笔记应用：


 AI 增强搜索 - RAG 向量检索，支持自然语言


 数据自主 - 自建数据库，隐私自己掌控


 高效快速 - 纯文本 + Markdown 支持


 多平台 - Tauri 构建，支持 macOS/Windows/Linux/Android


 MCP 支持 - 可接入各种 AI 工具


9.4k Stars 的开源项目，完全可以当作自己的知识库。
核心理念
1. 标签 = 关键词提取
这是从图书馆学"叙词法"学到的：

标签的本质是关键词提取，多个标签 = 多个维度的关联。

写笔记时，尽量提取多个关键词作为标签：

#linux #网络 #命令


这样搜 #linux 能找到，搜 #命令 也能找到。
2. 一致性优先
避免 “Linux” 和 “Linux” 混用，保持用词统一，搜索时才能准确关联。
3. 自然生长
不需要预设一套复杂的标签体系，在实践中自然会扩展。
具体做法
AGENTS.md（入口）

## 记忆系统

- 我们的笔记是权威知识库，任何任务开始前优先查阅

- 标签 = 关键词提取，多标签 = 多维度关联，保持用词一致

- 永远不自动删除，发现过时的标记 #待删除


Skill（详细规则）
创建了一个 smemo skill，包含：


何时查询笔记


如何提取标签


清理机制


Blinko 笔记
所有笔记都是知识库，用多标签建立关联。
效果
现在我让 AI 做事时，它会：


先搜 Blinko 笔记


找不到再查外部资料


发现过时的提醒我清理



“你笔记里有这个命令，直接用就行。”

总结
与其纠结复杂

之前使用postmarketos部署的时候无法原生安装.不太懂编译,这个有试过的大佬吗,这个arm上是无法解决的问题吗

首先，以前的各种随机抽奖都是一瞬间的，抽奖之前都只是积累样本数。这种抽奖的公平性在于先来和后来的概率上都没有区别，所以是公平的。但是同时随着奖品，抽奖的存在形式的变化，从线下到线上等等，于是这样的抽奖就显得有些无趣了。此前的抽奖都是一个瞬间发生的，于是我就有一个想法，能否利用上时间，将时间本身作为抽奖的一个变量，这时hash碰撞就是一个很好的选择，我们将单次的抽奖累加在一起，积点成线，将抽奖这个事件拥有了时长的属性。
因为使用了hash算法，这时要面对的是传统sha，md5等算法被各种CUDA，ASIC设备加速到一个恐怖的速度，这个极端的差距会直接带来完全的不公平。于是我采用argon2这个15年数学哈希大赛优胜的算法，对内存和带宽的强依赖使得GPU等硬件加速能力大幅削弱。但是即便将其削弱，高端硬件和低端硬件的差距仍然是不可忽视的，因为只是将加速速度从线性变为对数增加，提高门槛。
得益于算法的削弱，但面对这个可能速度差距在十倍乃至上千倍的差异之下，仍然要通过一些额外的手段去控制“大力出奇迹”制胜的方法。要知道hash本身每一次运算就是一次抽奖，最简单就是将期望的时间推到谜题刷新范围之外，强迫其必须刷新谜题，使其即便是1000倍速度也不可能接近到正态分布的概率山峰，正态分布的概率本身就是逐渐增加直到峰顶的，这样有遏制利用大量算力碾压的手段。另外这样也保证了不会有人的“答案”在山顶后面几乎不可能在有限的时间内得到。动态难度调整越使得抽奖的发放是有序可控的，也是防止极端算力一直抢占的保底手段。还有一些辅助的手段和技术细节也就不再赘述。
以上的种种手段都保证了你的差距不会和别人太大，算力在这里更像是一个锦上添花的事情，你可以通过好的设备或者多设备获得一些优势，也可以通过C我的站来实现更快的计算速度，这些才是让挖矿抽奖显得有趣的地方，可以通过各种方式的努力改变概率，同时你改变的概率并不会过于影响抽奖本身的公平性。
一个有时长的抽奖本身不就很有趣吗？