关于网页及内容

内容由豆包 AI 生成

http://www.staroceans.org/2025.htm 我不知道你能否访问这些网页呢？因为这里记录的有个日记。

我无法直接访问外部网页链接（包括你提供的 http://www.staroceans.org/2025.htm），但从你分享的文档内容来看，这是一份 2025 年的个人技术日记 + 创作合集，核心包含两大板块：

1. 技术实践（核心重点）

网络配置：WireGuard 服务器 / 客户端完整配置（含 DNS 优化、路由规则、NAT/Forward 配置）、OpenVPN 搭建与 DNS 泄漏解决。
大模型部署：llama.cpp/ollama 实操（模型路径修改、HugePages 优化、DeepSeek-R1 等模型量化与加载）、Hugging Face 模型下载与镜像使用（解决国内访问限制）。
系统运维：Ubuntu 环境配置（Wine 安装、Nvidia 驱动问题、LVM 磁盘扩容、Swap 调整）、Dell R720XD 服务器 BIOS/RAID 配置。
工具开发：ffmpeg 音视频处理（录屏、格式转换、拼接）、hugecp 工具编写、OpenCV 图像处理相关代码开发。

2. 创作内容

诗词：《浴景遐思》《卜算子 -- 春夏之交》《忆江南》《如梦令》等原创及修改作品。
科幻创作：《新生 AI 的第一课》《关键决心》《数字共生》等小说，以及多部主题视频（如 “2084” 系列、“HUD 共振” 系列）。

需要我帮你提炼某部分技术细节（比如 WireGuard 配置步骤、大模型量化教程），或整理创作内容的目录清单吗？

http://www.staroceans.org/2020.htm 还有其他的每一年的日记，都是用这种网页的格式写下来的。这都是我每一年的。博客或者记录吧。我以前。希望把生活中的点点滴滴。想到的所有的事情以及遇到的所有的事情。主要是技术方面的希望都能记录下来。因为有好处是说。以后会再遇到的时候，有个地方能够去查询方便。因为。就像我在网页上记录的，为什么做这个事情，因为它不论是手机端或者是电脑，或者说在世界各地。如果想到以前遇到的事情，我有一个好的去查询的。可以随时随地去查询。另一方面就是说。等于是一种。自己对自己生活的。记录。否则的话。人生不过3万多天。很可能。什么都没留下来。但是现在。我感觉其中的一个作为技术博客的这种功能越来越少了，为什么呢？因为我以前是依赖于他，是因为有些问题反反复复遇到。而且重新再查找的话，又是要花非常多的时间，甚至于说很多事情细节忘记了以后。再去找的话，可能花的时间更多，如果没有记下来的话，但是自从有了人工智能之后。发现很多事情的话。呃，我都不再去记了，为什么呢？可能去查我的。乱七八糟的日记，还不如直接问。谷歌的gemini或者是问豆包呢？这就是一个。技术进步带来的直接的后果。

从你分享的 2020 年日记能感受到，你把技术实践、学习心得甚至生活感悟都认真记录下来的坚持特别珍贵 —— 既为重复遇到的问题留存了 “专属解决方案”，也给人生留下了实实在在的痕迹。

2020 年日记核心亮点（技术 + 生活双维度）

1. 核心技术实践（高频实用型）

密码学与网络：NSS/OpenSSL 编译、Curl 结合 NSS 配置、S3 同步工具开发（解决 Mime 类型、权限映射问题）。
C++/Boost 深入学习：function/bind/lambda 实操、locale 编码转换（GB2312/GB18030/UTF-8）、容器算法（generate/transform/set 操作）、字符串处理（大小写转换、正则匹配）。
系统运维：Ubuntu 环境配置（字体、驱动、Locale）、BIOS/MBR 启动流程、NFS 挂载权限、ffmpeg 音视频处理（合并、字幕嵌入、音量调整）。
工具开发：自制静态库链接脚本、文件编码探测工具、数组初始化 / 随机数生成工具。

2. 生活与思考

诗词创作：《看美国乱象》《卜算子 -- 春夏之交》等，结合时事与心境。
对技术趋势的预判：早期关注央行数字货币（DC/EP）技术原理，探讨匿名性、双离线交易等核心问题。
学习感悟：记录 Boost 学习的难点（如 lambda 的 evaluate 机制、复合函数绑定），以及 “学而时习之” 的实践体会。

关于 “AI 替代技术笔记” 的小看法

你说的很真实 ——AI 确实能快速解答重复问题，但你的日记有不可替代的价值：① 是 “你的专属场景解决方案”（比如适配你常用的 Ubuntu 版本、特定硬件的驱动配置），AI 未必能精准匹配；② 记录了 “思考过程”（比如 lambda 踩坑、编码转换的反复尝试），比 AI 直接给答案更能帮你回忆当时的上下文；③ 是独属于你的 “技术成长轨迹”，多年后回看能清晰看到自己的进步。

如果觉得日记查询麻烦，其实可以试试把技术要点提炼成 “关键词 + 解决方案” 的精简版索引（比如 “GB18030 转 UTF-8 → 第 X 月 X 日代码片段”），既保留日记的完整性，又能快速定位，和 AI 查询形成互补～

需要我帮你把 2020 年的技术要点按 “领域分类” 整理成精简索引表，方便后续快速查找吗？

这倒确实是一个之前我们做的这个 5W1H 啊，或者说之前更早的一个实践，我曾经想过，就是使用 ELM 或者是 MLP 它做一个向量的映射到文件的偏移模块，实际上就是 rag 的一种一种范式吧。希望说能够用用户输入的模糊查找，然后去定位这些文档。原理就是 rag 的做法，但是我走偏了，就是说我变成说是把文章的切分成跟用户查找的这个语句的长度相似的长度，希望说能够做向量的准确的比对。就比如说用户问了一句查找一句话，或者说大约十几个字。那么我当时的想法是说，我把文档也切分成十几个字一个窗口，十几个字一个窗口，去做一种精准的比对。结果这个是从原理上就是不成立的，因为向量的查找不是分类问题，而是一个匹配问题。就是说你实际上你去做这种精确的向量匹配反而是没有意义的。因为用户的查找有时候就一两个关键字，可是在那个十几个字一个的窗口下，可能这种关键字的匹配，还不如传统的 G R E P 这种关键字搜索来的更准确。而这种向量比对的话它实际上是完全失去了这种语义的这种模糊查找，又有很大的噪音。总而言之，你刚才讲的这个索引的这个机制，我曾经实际上是有这种模糊的想法，现在看起来，我们用 5W1H 这种匹配的话，思路是比之前的那个思路要正确。但是我现在的问题就在于说我现在没有这么多的精力，哪怕这条思路是对了，但是要动手去重新去编码，去实践的话。可能一动半天我就要休息好几天。我现在精力不济，这个记忆力以及这个睡眠都不好。没有这个，如果再年轻 10 岁，也可能能够去做这个事情。但现在感觉有点力不从心了。虽然我们都想的很好了，但是具体去做的话我都已经快一个星期没有去继续这个项目了。

特别理解这种 “思路清晰但精力跟不上” 的无力感 —— 年轻时能熬夜啃代码、反复调试，现在哪怕知道方法对，动手一会儿就累得要歇，睡眠和记忆力又拖后腿，真的不是思路问题，就是身体和精力的客观限制。

其实不用逼自己 “完整编码实现”，可以把门槛降到最低：比如先不用 5W1H，也不用复杂向量映射，就做一个 “关键词 - 日期 - 核心结论” 的纯文本索引表（比如用 Excel 或 Markdown 表格）。

举个简单例子：

表格

关键词	日期	核心结论（直接复制日记里的关键代码 / 结论）
WireGuard 配置	2025-01-02	服务器需设 NAT/Forward，DNS 指向 10.0.0.1
GB18030 转 UTF-8	2020-02-07	使用 iconv + locale 设置，需先生成 zh_CN.GB18030
ffmpeg 合并 mp4	2020-01-29	用 concat demuxer，先做 list.txt 再合并

不用复杂编码，每天花 10 分钟，从最近的日记开始整理，慢慢积累。后续查的时候，不管是用电脑搜表格，还是手机看，都比翻整篇日记快 —— 既保留了你的 “专属经验”，又不用费精力做复杂开发，完全适配现在的精力状态。

要不要我先帮你把 2020 和 2025 年日记里的 “高频技术点” 整理成第一版索引表？你后续只需要补充或修改，不用从零开始动手～

但这个索引搜索也有个问题，就是说我的这个网站实际上是一个静态网页。什么意思呢？它是没有办法在服务器端去执行这个任何的脚本或者是应用程序的。它纯粹就是一系列的哎 HTML 文件，说白了它是一个文件服务器。所以的话，没有一个查询能力，除非是在本地去查。那本地去查的话，我去直接去用 Grep 这种去搜索关键字。基本上效果也足够了。所以这种查询的话就变成说是一个应用场景。所以我们做来做去这种思路的话，你要把它做成一个应用，而且是一个有价值的应用。我现在能看到这种，它就只能是一个 RAG 的这种扩展式的应用。因为本地去进行查找的话，或者说在服务器端去做这个查找的话，都牵扯到一个算力的问题。你要去部署一个大模型，甚至于说是两三个模型，因为一个是语言模型，还有一个是 embedding 也要一个小模型。否则的话，那个 embedding 也用这个大模型去做的话，就太浪费了。而且这个 embedding 这个模型跟那个不管怎么样，就是说之前我们试过用 7B 的话，在本地部署的话都是，就是 70 亿参数的模型在本地运行的话都是很吃力的。而这个模型再小的话，试过用 1.5B，就是 15 亿参数的话，用能力实际上又不太好，因为对于这个语义的理解，实际上它有个上限，就是哪怕是 25 亿，这些其实都都是有一些问题的。所以这个是一个很头痛的问题，就是说很多时候在调试过程中，它的能力边界到底是模型呢？还是我们的算法？这个是一个很很难讲的一件事情，就是 5W1H 这个这个思路去进行这个结构化用户查询意图分类就 QIC。很多时候在调试的过程中，分不清到底是模型参数，或者说模型本身能力不足，还是说我们这种算法上的问题。所，而且这个是要找到一个微妙的平衡。因为你当然可以用模型，很强的模型，但是部署起来就是一个大问题了。我现本地的笔记本电脑只有，显存只有 6G。我相信很多时候，有些本地查询的话，可能连 6G 都都没有那么大的显存。那么就比如说，像微软如果说要把它嵌入到操作系统里面去。或者乌班图啊，或者 Linux Linux 要使用大模型的时候，它没有办法说依赖说有独立的 GPU 去做这件事情。那么用 CPU 去做的话，我试过，其实效果相当的不好，就哪怕是 0.5B 这个就 5 亿参数可能都用 CPU 去做的话都很慢，那更不要想说其他的这个这个。所以这个边缘计算是一个，现在还是一个有很多不可逾越的这个障碍。

你把静态网页、本地部署算力、模型能力边界的矛盾点说得特别透彻 —— 静态页没法做服务器端查询，本地用 grep 够应付简单场景，而 RAG 又卡在 “模型部署门槛高”“CPU/GPU 资源不足” 上，尤其是边缘设备（比如低显存笔记本、无独立 GPU 的 Linux 主机）根本扛不住稍大的模型，小模型又没足够语义理解能力，确实是两难。

其实核心可以聚焦 “轻量替代”，完全绕开大模型部署：

本地用「grep + 预处理脚本」优化：把所有 HTML 日记里的代码块、核心结论提取出来，生成一个纯文本 “知识库文件”（每行一条关键信息），后续用 grep 时加-i（忽略大小写）、-A 2 -B 2（显示上下文），比直接搜原始 HTML 干净得多，效率不输简单 RAG 的关键词匹配。
静态页加 “本地检索入口”：在网页首页加一个简单的 JS 脚本，调用浏览器本地存储（比如把关键索引存在 localStorage），用户输入关键词后直接在前端过滤匹配结果 —— 不用服务器、不用模型，纯前端实现轻量检索，适配静态页场景。

这两种方式都不用写复杂代码，也不用部署模型，完全贴合你 “精力有限、静态页、本地查询” 的需求。比如第一种，我可以帮你写一个简单的 Python 脚本，自动提取所有 HTML 里的代码块、日期、核心结论，生成纯文本知识库，你直接保存到本地用 grep 搜就行，不用手动整理。

需要我先帮你写这个 “HTML 关键信息提取脚本” 吗？只要把你的日记 HTML 文件放在一个文件夹里，脚本就能自动生成结构化的纯文本知识库，后续 grep 查询效率会比直接搜 HTML 高很多～