在群晖 NAS 上搭了一套播客自动转写和 AI 整理系统

最近在群晖 NAS 上又折腾了一个东西。我之前一直用 Podsync 自动下载一些播客节目，基本上每天都会有新的音频下来，中文比较多，也有一些英文和葡萄牙语的节目。音频下载下来以后，平时当然可以直接听，但是我慢慢发现一个问题。播客这种东西，有的节目特别是存在多人交互的节目，废话比较多，音频不容易快速捕捉到关键需要的内容。所以我就想，既然这些节目已经全部自动下载到 NAS 里面了，能不能干脆再往后走一步：音频下载以后，自动转成文字，然后再通过 AI 整理成比较适合阅读的文章。这样以后一个节目既可以听，也可以看，还可以搜索和长期保存。于是就开始折腾。一开始想直接在 NAS 上跑 Whisper最开始我的想法其实很简单。既然文件都在 NAS 上，那就在 NAS 上部署一个 Whisper，下载完以后直接本地转写。但是检查了一下我的群晖以后，很快就放弃了这个方案。我这台是 DS218+，CPU 是 Intel Celeron J3355，双核。内存之前已经扩展到了大约 10GB，但是没有独立显卡，而且这个 CPU 连 AVX/AVX2 都不支持。小模型其实也不是完全不能跑。问题是，能跑和适合长

技术专业 · 10 天前
在群晖 NAS 上搭了一套播客自动转写和 AI 整理系统

机器怎么"想明白"一件你没告诉它的事？聊聊什么是本体推理

一个笨问题假设你在教一个从没见过世面的助手打理你家的事。你告诉它两句话：老王是我爸。 我是小明。然后你问它：老王和小明是什么关系？正常人零点几秒就答出来了。但对一台只会存数据的机器来说，这是个陷阱——它的库里只有两条记录，没有任何一条写着"老王是小明的爸爸"。所以标准答案是：查无此人此关系。要让它答对，传统做法是你再手写一条规则："如果 A 是 B 的爸爸，且 B 就是提问的人，则 A 是提问者的爸爸。"能用，但你很快会发现这条路走不通——爷爷、外甥、堂表兄弟、连襟、儿媳的妹夫，中国亲戚关系能把人绕死，你得写几百条。而且换个领域（比如公司的股权关系、疾病的分类体系、电信的资费结构），你又得从头再写几百条。本体推理想解决的，就是这件事：让机器只靠少量的概念定义，自己推出海量你没明说的结论。本体是什么：给世界画一张骨架图"本体"这个词听着玄，其实是从哲学里借的。哲学里的本体论研究"世界上到底存在什么"，计算机借来之后，意思务实多了：把一个领域里有哪些概念、概念之间什么关系、有哪些不可违反的规矩，用机器能读懂的方式写清楚。拿家庭举例，你要写的东西大概是这样：有哪些类：人、男人、女人谁包含谁：

技术专业 · 14 天前
机器怎么"想明白"一件你没告诉它的事？聊聊什么是本体推理

DSM 7.4 升级记：一次顺利升级，却留下了一个小遗憾

昨天看到群晖正式发布 DSM 7.4，一时间有些心动。不过，对于家里的这台 DS218+ 来说，我其实一直奉行一个原则：稳定压倒一切。这台 NAS 已经承担着家里的大部分服务，包括 Immich、Podsync、Tailscale、Docker 等十几个容器，最近好不容易把各种环境都调试稳定。如果因为一次系统升级导致某个服务出现兼容性问题，后面可能又要花不少时间排查和折腾。因此昨天一直没有下决心升级。社区评价基本打消了顾虑今天上午又花了一些时间看看 Reddit 和各大论坛上的用户反馈。让我比较意外的是，大家对于 DSM 7.4 本身的评价其实不错。升级过程普遍都比较顺利，没有看到大规模翻车案例。Docker、虚拟机、常用套件基本都能正常运行，不少用户甚至评价说：“升级之后什么变化都没有，这反而说明它足够稳定。”真正引发大量讨论的，其实并不是 DSM 7.4，而是 Synology 对新功能 Storage Efficiency（存储效率） 的限制。Storage Efficiency 成了最大的吸引力原本我只是准备观望一段时间。但在了解 DSM 7.4 的新功能时，Storage E

技术专业 · 07-20
DSM 7.4 升级记：一次顺利升级，却留下了一个小遗憾

iPhone 网络定位测试：用 Quantumult X 配置 WLOC 的一次记录

今天尝试了一个 iPhone 网络定位测试方案：通过 Quantumult X 拦截苹果的网络定位请求，替换 Wi‑Fi/基站定位返回的坐标。它不是修改 GPS 硬件信号，而是影响苹果网络定位服务的结果。因此在室内、GPS 信号较弱时更可能有效；如果在室外，真实 GPS 信号很强，地图 App 可能仍优先使用真实位置。配置过程使用的工具是 Quantumult X，并导入 WLOC 的重写资源：https://raw.githubusercontent.com/Yu9191/wloc/refs/heads/main/modules/wloc.conf导入时需要放在 Quantumult X 的“重写资源（Rewrite Resources）”中，而不是节点订阅。导入成功后，MITM 主机名中会自动出现：gs-loc.apple.com gs-loc-cn.apple.com这两项配置正确，且应避免添加 *.apple.com 或 * 之类的全域规则，以免扩大 HTTPS 解密范围。证书配置由于定位响应使用 HTTPS，Quantumult X 必须生成并安装自己的 CA 证书。流程如下

技术专业 · 07-16
iPhone 网络定位测试：用 Quantumult X 配置 WLOC 的一次记录

折腾记：大疆4G模块刷出新玩法

最近跟风买了一个大疆的 4G 模块。一开始我只是想看看它能不能接到 NAS 上，用来做一个短信收发管理工具。结果一路折腾下来，发现这东西确实有点意思，但也不是“插上就能用”。一开始的目标我的初始目标很简单：把这个大疆 4G 模块接到自己的设备上，实现短信集中收发管理。最好可以放在 NAS 上，因为 NAS 长期开机、管理方便，也适合跑一些 Web 服务。后来又看到网上有人把这个模块识别成 Quectel EC25 后，配合 VoHive 使用，可以管理短信、eSIM、设备状态，甚至通过 Telegram 做通知，于是就开始评估是否要刷机或改设备信息。要不要刷机？刚开始比较担心“刷机”这个词，因为涉及固件、NV 参数之类的东西，风险不低。后来确认下来，这次并不是传统意义上的刷固件，而是通过 AT 命令修改 USB 识别信息。这个大疆 4G 模块本质上是移远 Quectel EG25-G 的变体，默认 USB ID 是大疆私有的：2ca3:4006 修改后可以让系统把它识别成更通用的 Quectel EC25：2c7c:0125 修改之后，Linux 内核就能比较自然地加载 optio

技术专业 · 07-09
折腾记：大疆4G模块刷出新玩法

折腾记：自建 peer relay 与 DERP，把 Tailscale 内网延迟从 300ms 打到 30ms

起因手机上通过某第三方客户端内嵌的 Tailscale 模块连回家里内网，延迟高得离谱——tailscale ping 动辄 300ms 起步，还会抖到 1.6 秒，速度慢到基本不可用。表面是"网络慢"，深挖下去是一整条链路的问题。这篇记录完整的排查与解决过程，也算给自己留个底。第一步：定位根因——中继落在境外高延迟在 Tailscale 场景里几乎都指向同一个根因：流量走了 DERP 中继，而不是 P2P 直连。先在 NAS 上定位：tailscale ping 100.x.x.x # pong from node via DERP(hkg) in 381ms ... direct connection not establishedvia DERP(hkg)——中继落在境外节点。再看 netcheck：Nearest DERP: Hong Kong hkg: 145.6msNAS 到官方境外 DERP 就要 145ms，手机（蜂窝网络）到该节点又是一段，两段叠加加抖动，300ms+ 就是这么来的。P2P 直连没打通，全程依赖这个远距离中继。结论：得把中继点从境外换到境内。第二步

技术专业 · 07-09
折腾记：自建 peer relay 与 DERP，把 Tailscale 内网延迟从 300ms 打到 30ms

Immich 3.0 升级实录：DS218+ 从 2.7 升级到 3.0

最近看到 Immich 正式发布了 3.0 版本。作为我 NAS 上最重要的应用之一，自然第一时间关注了一下这次的大版本更新。在升级之前，我先对比了一下 3.0 与我目前使用的 2.7 版本有哪些值得升级的新功能。为什么升级？官方这次 3.0 并不是一次简单的版本更新，而是一次比较大的功能升级。比较吸引我的几个新特性包括：内置 AI 修图（Image Editing），可以直接在 Immich 中完成简单的照片编辑，而不用再导出到其它软件。更完善的照片管理能力，包括更好的浏览体验和细节优化。搜索和 AI 能力持续增强，后续还有更多基于视觉模型的扩展空间。底层架构升级，数据库向量引擎等组件进行了优化，为后续功能提供基础。对于我来说，最有价值的还是修图功能。平时大量照片都是手机自动同步到 NAS，偶尔需要裁剪、调整亮度或者做一些简单编辑，以前都需要下载到手机或电脑处理，再重新上传。现在如果能够直接在 Immich 中完成这些操作，整个照片管理流程会方便很多。综合评估之后，我决定将家里的群晖 DS218+ 升级到 Immich 3.0。我的环境升级前的环境如下：NAS：Synology DS

技术专业 · 07-09
Immich 3.0 升级实录：DS218+ 从 2.7 升级到 3.0

Podsync 的一次"空时长"崩溃排障：从 bad format string 到 PO Token 补全

家里 NAS 上跑着三个 podsync 容器，把一个频道转成播客音频喂给我的播客客户端。这套东西平时很省心，直到某天日志里开始反复刷同一条错误。这篇是完整的排障记录——之所以写下来，是因为过程里有三次方向判断被推翻，而每一次被推翻，都比一开始"猜对"更能说明这个系统到底是怎么运转的。一、现象日志里，某一个 feed 每轮更新都失败，其它 feed 正常：ERRO ... failed to update feed: https://www.youtube.com/channel/UC.../videos error="update failed: failed to parse duration : bad format string"注意报错里 duration 后面那个值是空的。而且它只影响 A01——后面的 A02、A03 照常下载，说明 podsync 是逐个 feed 更新的，一个挂了不拖累其余。损失面很小，但这条错误会一直刷，且只要触发条件在，就不会自愈。二、定位：三次推翻第一次判断：加个过滤把它挡掉 —— 失败第一反应是：列表顶部大概有一个

技术专业 · 07-09
Podsync 的一次"空时长"崩溃排障：从 bad format string 到 PO Token 补全

从 VPS 被入侵，到建立网站备份体系

最近我的私有 VPS 被部署恶意程序的事件，对我最大的触动其实不是如何清除病毒，而是意识到另一个经常被忽略的问题——数据安全。以前更多关注的是服务器安全：关闭端口、最小权限、防火墙、监控告警……这些都很重要。但真正静下心来思考后发现，即使安全措施做得再完善，也没有任何人敢保证服务器永远不会出现问题。真正能够降低风险的，不仅是防御，更是可恢复能力（Recoverability）。因此，在完成 Sentinel 安全监控体系之后，我又开始补齐另一块短板——应用数据备份体系。为什么要做备份对于 我的 网站来说，真正有价值的并不是代码。代码可以通过 GitHub 恢复，可以重新部署；真正难以恢复的是：SQLite 数据库中的业务数据配置文件网站运行过程中不断积累的数据如果服务器被删除、磁盘损坏，甚至再次遭遇攻击，没有备份意味着这些数据可能永久丢失。所以这次工作的目标很明确：让任何一台服务器出现问题，都能够在最短时间内恢复业务。第一层：服务器本地自动备份首先为项目新增了独立备份脚本。备份策略分为两类：数据备份每天自动执行使用 SQLite Backup API 导出数据库避免直接复制正在运行中的

技术专业 · 07-03
从 VPS 被入侵，到建立网站备份体系

一次 VPS 安全事件后的反思：从问题发现到建立完整监控体系

最近这几天，几乎把所有业余时间都投入到了 VPS 安全排查中。事情的起因，是一台 Oracle Cloud VPS 被发现运行了疑似恶意程序。虽然最终没有造成明显损失，但整个事件却让我意识到一个问题：真正危险的不是服务器被攻击，而是服务器被攻击了很久，而自己却毫不知情。这次事件，也促使我重新设计了整个 VPS 安全监控体系。从最初的发现异常，到紧急处置，再到监控体系建设和持续能力升级，对自己的运维理念产生了很大的影响。一、问题的发现：一次持续多天的安全隐患最初收到的并不是入侵告警，而是一条来自自己编写的巡检脚本的提示：可疑高 CPU 进程。登录服务器后，很快发现了异常。进程运行在 /tmp 目录，文件名随机，长期占用大量 CPU，父进程指向 LiteLLM，随后又发现多个 Python Loader 以及已经退出的僵尸进程。继续分析时，所有程序已经全部删除，只留下运行痕迹。整个行为非常符合目前 Linux 挖矿木马常见的模式：下载恶意程序临时运行删除自身不留下文件虽然最终没有找到矿池地址和程序样本，无法做到百分之百确认，但综合各种行为特征来看，基本可以判断是一类典型的 CPU 挖矿木马

技术专业 · 07-02
一次 VPS 安全事件后的反思：从问题发现到建立完整监控体系
2016 - 2026 自由翱翔：十年学习成长之路. All Rights Reserved.
Theme Jasmine by Kent Liao