南冥鹏影

《GEB》随笔：信息的三个层面

Thu, 15 Oct 2026 22:15:49 +0800

《哥德尔、艾舍尔、巴赫》（GEB）中写道，信号分三个层面：（1）框架消息、（2）外在消息、（3）内在消息。原文对三者的概述为：

这当中我们最熟悉的是（3），即内在消息，它也就是预定要传送的消息：在音乐中是情感体验，在遗传学中是表现型，在书板上是古代文明的王权与礼仪，如此等等。

理解内在消息就是抽取出发送人所要传递的意义。

框架消息是这样一种消息：“我是一条消息，你有本事就来解译我！”它是由信息携带者总体的结构特征隐含地传递的。

理解框架消息就是确认需要一种解码机制。

如果确认了这样的框架消息，那么人们的注意力就会转到第2层：外在消息。这是由消息中符号的模式及结构隐含地携带的信息，说明如何去解译内在消息。

理解外在消息就是建造——或知道如何建造——能正确解译内在消息的解码机制。

作者给出了三个非形式化、感性的层面，却让我不由得联想一些形式化的东西。

框架消息让我首先想到信号的熵和自信息量。在信息学中，熵是描述了一个随机变量的不确定度，而自信息量描述这个随机变量取值有多罕见，或者说，出乎意料。但事实上，假设正在接受无线电信号，噪声的自信息量是比人声高的，因为人声是有规律的，更可以预测。这说明，框架消息并不能简单地用自信息量来描述，我们推断一个信号是否要解读，应该还是经过了一番贝叶斯推断的。无规律的信号我们会认为是噪声，过于规律的信号可解读的信息又不多，我觉得，对人类而言，既具有一定规律、又包含变化的信号，往往更容易引发持续解读的兴趣。

这个发现让我很沮丧，这样的话，我们如何发出一个信号，使另一个智慧文明能够首先接收到框架消息，认为这是一个消息呢？这就不能形式化地求解出一个最佳答案。一个经典答案是数列，斐波拉契数列或者质数数列，因为我们推断另一个智慧文明也极大可能掌握了相同的数学。不过这里好像脱离了讨论框架信息的范围，数学数列还承载了外在消息和内在消息。让掌握无线电的外星文明接受到框架消息应该是很简单的，只要让他在特定频段接收到不是宇宙噪声的信号就行，就像你在安静环境对任何一个有耳朵的动物大叫一声，它都会听到，并尝试寻找你。然而，当接收者的感知机制、先验知识和搜索策略完全未知时，我们无法定义一个普遍适用的最优目标。

对于外在消息，作者立了一个很有趣的靶子。我们接收到一个中文消息，它的外在消息就是“我是中文消息，用中文解读我吧”，如果你发中文消息给一个不会中文，甚至不知道中文概念的外国人，即使你用中文写上“这是一条中文消息”，也于事无补，仅仅在消息内部声明它应该如何被解读，并不能保证一个尚未掌握解码机制的接收者理解这项声明。就像是原文中说的：

在你理解任何一条消息之前，你必须有另一条消息来告诉你如何理解这条消息；换句话说，存在一个具有无穷多层次的消息体系，这就阻止了对任何消息的理解。

但是，我们都知道这些悖论是无效的，因为规则的确是在被使用，而消息也的确是在被理解。这是怎么回事呢？

作者同样做出了很好的解释

我们大脑的结构是漫长的进化过程的结果，它们的运行是受物理规律控制的。既然它们是物理实体，我们的大脑在运行时无需被告知如何运行。就是在这一层次上，物理规律产生出思维，因而卡罗尔的规则悖论被打破了。与此相类似，在大脑把输入数据解释成消息的那个层次上，消息悖论被打破了。似乎大脑原本就配备着一些“硬件”来识别哪些东西是消息，而且能对这些消息进行解码。就是这种最低限度的抽取内在意义的天生能力使得高度递归的、滚雪球式的语言习得过程得以发生。

最近玩完了《底特律：变人》，不禁让我联想到，人工智能与人类在接收和理解消息的底层机制上，或许存在着某种根本性的差异。

我们当然可以让机器在特定场景下表现出与人类相似的共情反应，但这种相似终究只是我们观察到的结果。人与人之间的共情则有所不同。我们之所以容易被他人的情绪打动，不仅是因为能够理解对方的表达，更是因为我们知道，彼此拥有相似的生理结构，以及由漫长的演化过程塑造出的情绪反应机制。正是这种底层机制的共通性，使我们能够从他人的情绪反应中推及自身，进而相信彼此在某些感受上是相通的。

然而，面对机器时，这种信任似乎就不那么容易建立了。即使我们观察到机器在某些场景中表现出与人类相同的情绪反应，又如何确信它在其他场景中也会如此？倘若某些情境从未被开发者考虑，也未曾出现在训练过程中，机器还能表现出同样的共情吗？

这是我第一次在博客上写读书随笔，我的讨论也可能有诸多谬误，但我觉得我还是得把想法写下来，总之先放这里吧。

REDIAL (2026)：从 Embedding 扰动看 RNA 语言模型学到了什么

Thu, 17 Sep 2026 17:00:00 +0800

REDIAL 核心方法：突变一个碱基，观察其他位置的 embedding 怎么变

这篇文章主要回答两个问题：

不训练下游预测器，能不能直接读出 RNA 语言模型中的结构信息？
一个 12 层的 RNA 语言模型，每一层都有必要吗？

本文基于作者于 2026 年 5 月 12 日发布的 bioRxiv 预印本版本。

评价基础模型依赖下游结构预测

评价基础模型如 RNA-FM时，主要关注的是 RNA-FM 提取 embedding 后，如何通过下游模块生成三维结构。

RNA 序列 → 预训练语言模型 → embedding → 下游结构模块 → 3D 结构
 ↑ ↑
 预训练学到的信息 结构训练集、模型先验等

下游模型可以从结构训练数据中补充信息，也可能记住某些常见结构。因此，最终预测准确，不足以单独证明基础模型学到了可泛化的结构规律。

这篇文章希望绕开下游训练，直接检查预训练模型的表征。

REDIAL：从单点突变到 coupling map

原文 Fig. 1：REDIAL 观察各层 embedding；Categorical Jacobian 观察 LM-head 输出的 logits。

核心思路

如果位置 $i$ 与位置 $j$ 存在结构或序列依赖，改变 $i$ 的碱基，可能影响模型对 $j$ 的表示。

计算过程

对长度为 $L$ 的 RNA，模型输出 $L\times c$ 的 embedding，其中 $c$ 是 hidden dimension。

按通道标准化：让各通道均值为 0、方差为 1，避免少数高幅度通道主导结果。
逐位置突变：每个位置枚举 A、C、G、U，包含原始碱基，共 $4L$ 个组合。
计算扰动：将突变序列与原序列的标准化 embedding 相减。
聚合并去背景：得到位置之间的 coupling map。

用 $\tilde z$ 表示标准化后的 embedding，扰动张量为：

J_{iajk}=\tilde z_{jk}(x^{i\to a})-\tilde z_{jk}(x), \qquad J\in\mathbb{R}^{L\times4\times L\times c}.

其中， $i$ 是突变位置， $a$ 是替换碱基， $j$ 是被观察的位置， $k$ 是 embedding 通道。

按原文 Methods 的公式，对碱基和通道维度取 Frobenius 范数的平方：

C_{ij}=\sum_{a,k}J_{iajk}^{2}.

随后对称化，并做 Average Product Correction（APC）：

S_{ij}=\frac{C_{ij}+C_{ji}}{2},\qquad M_{ij}=S_{ij}-\frac{\left(\sum_t S_{it}\right)\left(\sum_s S_{sj}\right)}{\sum_{s,t}S_{st}}.

APC 用于扣除整体背景效应。最终的 $M$ 是一个 $L\times L$ 的耦合分数矩阵，分数高表示模型对这两个位置的关联更敏感。。

结构引导预训练确实改善了可读出的信号

数据与评价指标

从 NAKB 筛选单链、无蛋白质或小分子等其他组分的 RNA 结构，并进行清理。
主比较使用 533 个结构–序列对，长度 $L\leq512$ 。
参考接触由 Barnaba 的碱基相互作用注释构建，排除无法归类的 XXX 相互作用。
评分取矩阵上三角，并排除自身及序列相邻位置。

接触对通常比非接触对少，而且比例随序列长度变化，因此作者使用经过基线校正的 PR-AUC：

\mathrm{AUC}_{\mathrm{adjusted}}=\frac{\mathrm{AUC}_{\mathrm{raw}}-p}{1-p},

其中 $p$ 是参与评价的位置对中真实接触的比例。

随机基线约为 0，完美预测为 1，也可能出现负值。 这里不能把普通 PR-AUC 的随机基线也理解为 0。

结果

原文 Fig. 4：散点横轴为 RNA-FM，纵轴为 StructRFM；多数点在对角线上方。右侧展示 hairpin 与 tRNA 的具体例子。

部分短 RNA：RNA-FM 几乎没有读出有效接触，StructRFM 能恢复茎区及 bulge 导致的配对偏移。
部分 tRNA：两个模型都能读出接触，但 StructRFM 的背景更干净。
长 RNA 仍然困难：结构引导没有解决所有问题，补充图 S5 中长度大于 100 的序列仍是两个模型的难点。

12 层 Transformer 都在学结构吗？

原文 Fig. 5：(a) 比较逐层接触分数; (b) 跳层后的序列恢复表现；(c) 展示 StructRFM 各层读出的 coupling map。

作者做了两类实验：

读取中间层：对每层 embedding 分别运行 REDIAL，看结构信号在哪里出现。
跳过部分层：将保留下来的表示送入后续模块和原 LM-head，检查 perplexity 等指标。

这两个实验回答的问题不同：前者看结构耦合能否被读出，后者看被跳过的计算是否影响输出。

模型	逐层观察	作者的解释
StructRFM	总体上前 10 层接触信号较弱，最后两层明显增强；部分 tRNA 更早出现信号	结构信息集中在后部
RNA-FM	前约 6 层获得主要接触信号，之后提升有限	后续层对结构耦合的贡献较少

更直接的证据：删除 StructRFM 前 6 层

原文 Fig. 6：(a) StructRFM保留 L7–L12 的模型与完整模型比较; (b) RNA-FM 在不同深度输出的 logits。

StructRFM 仅保留 L7–L12 时，接触预测和序列恢复表现整体仍较接近完整模型，但并非完全无损。进一步缩到 5 层，接触预测能力明显下降。

RNA-FM 则呈现另一种现象：前几层已基本确定碱基身份，后面更多是在压低罕见或辅助 token 的概率，使输出分布更尖锐。作者据此提出，词表设计可能影响参数利用效率；这仍需要重新训练不同词表的模型来做因果验证。

我的理解

这些结果表现出了模型对于 REDIAL 这个任务的冗余，但要区分：

REDIAL 读不出来，不代表该层完全没有有用信息。
删层后接触分数接近，不代表所有下游任务都不受影响。
参数冗余与过拟合不是同一个概念，后者还需要训练分布与独立测试分布之间的泛化证据。

思考启发

提供了一种不借助下游任务，直接比较基础模型的方法
减小模型参数量的思路：直接看各层的 coupling map 的变化

参考文献

Teng, D., Qiu, Y., Sakthivel, G., Aranganathan, A., Herron, L. & Tiwary, P. Detecting and quantifying overparametrization in RNA language models with REDIAL. bioRxiv，2026-05-12 版本。DOI: 10.64898/2026.05.11.724344。

Systemd + Uvicorn + FastAPI 部署

Sat, 05 Sep 2026 18:19:11 +0800

使用 Uvicorn 运行 FastAPI，由 systemd 管理服务的启动、停止和异常重启，NGINX 负责对外提供反向代理。

下面以使用 systemd 的 Ubuntu / Debian 服务器为例，应用目录为 /home/fastapi-user/fastapi-app，入口为 server.py 中的 app 实例。部署已有项目时，需要按实际情况修改路径和入口。

设置 FastAPI 应用程序

一般本机开发，远程使用 git 拉取代码，并配置环境

原生 python

python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -r requirements.txt

UV 管理

uv sync

配置 systemd

创建服务文件

sudo vim /etc/systemd/system/fastapi-app.service

添加以下内容：

[Unit]
Description=FastAPI application served by Uvicorn
After=network.target

[Service]
Type=simple
User=fastapi-user
Group=fastapi-user
WorkingDirectory=/home/fastapi-user/fastapi-app
Environment="PYTHONUNBUFFERED=1"
ExecStart=/home/fastapi-user/fastapi-app/.venv/bin/python -m uvicorn server:app --host 127.0.0.1 --port 8000 --workers 1 --proxy-headers --forwarded-allow-ips=127.0.0.1 --timeout-graceful-shutdown 30
Restart=on-failure
RestartSec=5
KillMode=mixed
TimeoutStopSec=60
StandardOutput=journal
StandardError=journal
SyslogIdentifier=fastapi-app

[Install]
WantedBy=multi-user.target

主要配置说明：

User、Group：运行应用的用户和用户组。
WorkingDirectory：应用工作目录，server.py 位于此目录下。
ExecStart：直接使用虚拟环境中的 Python 启动 Uvicorn，无需执行 source activate。
Restart=on-failure：进程异常退出时自动重启；通过 systemctl stop 主动停止服务不会触发重启。
KillMode=mixed：停止时先向主进程发送终止信号，让它协调 worker 退出；超时后清理剩余进程。
TimeoutStopSec：systemd 等待服务停止的时间，给 Uvicorn 的优雅退出留出余量。
StandardOutput、StandardError：将标准输出和错误输出交给 journal 收集。

systemd 的重启与停止行为可参考 systemd.service 和 systemd.kill。

Uvicorn 参数说明：

server:app：表示导入 server.py 中的 app；如果入口是 app/main.py，通常改为 app.main:app。
--workers 1：启动一个工作进程，可根据内存和负载调整。使用多 worker 时，各进程的内存相互独立，应用启动逻辑也会在各 worker 中分别执行。
--reload：生产环境不要加此参数，它与 --workers 不能同时使用。
--proxy-headers 配合 --forwarded-allow-ips=127.0.0.1：只信任本机代理转发的客户端地址和协议头。

参数含义见 Uvicorn Settings。

启动服务并设置开机启动

sudo systemctl daemon-reload
sudo systemctl enable --now fastapi-app
sudo systemctl status fastapi-app --no-pager
curl http://127.0.0.1:8000/health

active (running) 表示服务进程正在运行，还需要通过 HTTP 请求确认应用已经正常提供服务。

查看日志

# 查看最近 100 行日志
sudo journalctl -u fastapi-app -n 100 --no-pager

# 实时查看日志
sudo journalctl -u fastapi-app -f

NGINX 中的配置

创建站点配置：

sudo nano /etc/nginx/sites-available/fastapi-app.conf

添加以下内容，将 api.example.com 替换为实际域名，并将域名解析到服务器：

server {
 listen 80;
 server_name api.example.com;

 location / {
 proxy_pass http://127.0.0.1:8000;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $remote_addr;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_redirect off;
 }
}

这里按 NGINX 直接面向客户端的单层代理配置，覆盖客户端传入的 X-Forwarded-For。如果前面还有 CDN 或负载均衡，需要额外配置可信代理与真实客户端 IP。

启用站点并检查配置，下面的软链接命令只需首次执行：

sudo ln -s /etc/nginx/sites-available/fastapi-app /etc/nginx/sites-enabled/fastapi-app
sudo nginx -t

检查通过后启动 NGINX 并重新加载配置：

sudo systemctl enable --now nginx
sudo systemctl reload nginx
curl -H 'Host: api.example.com' http://127.0.0.1/health

此时可以通过 http://api.example.com/docs 访问 FastAPI 的接口文档。服务器安全组或防火墙需要允许 HTTP 的 80 端口；Uvicorn 仅监听本机地址，无需开放 8000 端口。对外正式使用时应进一步配置 HTTPS。

更新与维护

更新应用

更新项目代码和依赖时，使用 fastapi-user 执行

sudo -iu fastapi-user
cd /home/fastapi-user/fastapi-app
git pull
exit
sudo systemctl restart fastapi-app
curl http://127.0.0.1:8000/health

按实际项目选择依赖安装命令。如果只使用本文的最小示例，修改 server.py 后重启服务即可。restart 会有短暂服务中断，请求检查若遇到应用尚未启动完成，可以查看日志后重试。

修改 .service 文件后，需要重新加载 systemd 配置并重启：

sudo systemctl daemon-reload
sudo systemctl restart fastapi-app

常用管理命令

sudo systemctl start fastapi-app
sudo systemctl stop fastapi-app
sudo systemctl restart fastapi-app
sudo systemctl status fastapi-app --no-pager

sudo nginx -t
sudo nginx -s reload

如果服务启动失败，先通过 journalctl 查看错误，重点检查虚拟环境路径、应用入口、文件权限以及端口占用。NGINX 返回 502 时，先在服务器执行 curl http://127.0.0.1:8000/health，确认后端是否正常，再检查 NGINX 配置和 /var/log/nginx/error.log。

Windows 接入 OCuLink eGPU 后任务栏消失：通过禁用 NVIDIA 显示音频驱动解决

Tue, 25 Aug 2026 16:04:48 +0800

故障环境

操作系统：Windows 11 25H2，Build 26200.9168
核显：Intel Iris Xe Graphics
eGPU：NVIDIA GeForce RTX 5070 Ti
连接方式：OCuLink（PCIe 直连）
无线网卡：Intel Wi-Fi 6E AX211
本机音频：Intel Smart Sound Technology / Realtek Audio
其他音频端点：USB DAC、蓝牙耳机、VB-Audio、NVIDIA 虚拟音频等

故障现象

接入 OCuLink eGPU 冷启动 Windows 后，故障并不是每次都会发生，但出现时非常有规律：

登录桌面后，右下角的 Wi-Fi、音量等图标和系统托盘没有正常出现。
开始菜单或任务栏可能反应迟钝。
重启 Windows 资源管理器后，任务栏和托盘恢复正常。

一开始很容易怀疑是 Wi-Fi 驱动、Explorer 本身或任务栏缓存损坏。但“重启 Explorer 能恢复”只说明 Shell 被卡住了，并不等于故障源就在 Explorer。

关键排查结果

设备状态检查显示：

Intel AX211 无线网卡处于 Started 状态。
WLAN AutoConfig 服务正在运行。
RTX 5070 Ti、Intel 核显和各音频设备均能被系统枚举。
系统中同时存在 NVIDIA High Definition Audio 和 NVIDIA Virtual Audio Device (Wave Extensible) (WDM)。

真正有价值的线索来自 Windows 事件日志和错误报告。

1. Windows Audio 先失去响应

系统日志出现 Service Control Manager 事件 7031：

Windows Audio 服务意外地终止。

Windows 错误报告进一步显示：

事件名称: AppHangB1
程序: svchost.exe_Audiosrv

也就是说，承载 Windows Audio 服务的 svchost.exe 确实发生了挂起，而不是简单的音量图标未刷新。

2. Explorer 被 AudioClientRpc 拖住

紧接着出现 Explorer 无响应事件：

事件名称: AppHangXProcB1
程序: explorer.exe
相关进程: svchost.exe:AudioClientRpc

这条记录把两件看似无关的事情连接了起来：Explorer 正在通过 AudioClientRpc 查询系统音频状态，而 Windows Audio 已经卡住，于是 Explorer 也被跨进程调用拖住。

Windows 11 的网络、音量、电池等状态区域属于同一个系统托盘。音频查询阻塞时，消失的不一定只有音量图标，Wi-Fi 图标和整个托盘都可能无法正常初始化。

3. 开机阶段存在音频设备初始化异常

每次故障附近还反复出现 Kernel-PnP 事件 219：

驱动程序 \Driver\WUDFRd 加载失败
设备: INTELAUDIO\...\DetectionVerification
状态: 0xC0000365

系统中还有虚拟显示设备的同类警告。单独一个事件 219 不一定意味着严重故障，但它说明开机时多个音频与显示端点的初始化并不顺畅。

最终解决办法

在设备管理器中禁用：

声音、视频和游戏控制器
 └─ NVIDIA High Definition Audio

操作步骤：

右键单击开始按钮，打开“设备管理器”。
展开“声音、视频和游戏控制器”。
找到 NVIDIA High Definition Audio。
右键选择“禁用设备”。
重启电脑并进行多次冷启动验证。

不要误禁用：

NVIDIA GeForce RTX 5070 Ti 显示适配器；
Intel/Realtek 本机音频设备；
NVIDIA Virtual Audio Device。

禁用后，本机不再出现开机托盘丢失和显示器音频导致的视频卡死，验证了故障与 OCuLink - NVIDIA HD Audio - DP 音频路径存在直接关系，根本问题可能出在OCuLink这一部分。

通过 NVIDIA 独显状态控制 Wallpaper Engine 开机启动

Fri, 21 Aug 2026 18:00:33 +0800

背景

家里使用外接显卡（eGPU）连接大屏幕时，希望 Wallpaper Engine 自动启动显示动态壁纸。

但外出使用笔记本时，没有外接显卡，不希望壁纸程序开机启动，避免浪费资源。

因此通过 Windows 计划任务，在登录时检测 NVIDIA GPU 状态，只有 nvidia-smi 检测成功时才启动 Wallpaper Engine。

1. 关闭 Wallpaper Engine 自启动

先关闭 Wallpaper Engine 自带的开机启动：

Wallpaper Engine
→ 设置
→ 常规
→ Windows 启动时运行

取消勾选。

避免它绕过检测直接启动。

2. 创建检测脚本

创建目录：

mkdir C:\Scripts

创建：

C:\Scripts\start-wallpaper.vbs

内容：

Set WshShell = CreateObject("WScript.Shell")

ret = WshShell.Run("nvidia-smi", 0, True)

If ret = 0 Then

 WshShell.Run """C:\Program Files (x86)\Steam\steamapps\common\wallpaper_engine\wallpaper64.exe""", 0, False

End If

逻辑：

nvidia-smi 返回码为 0
- NVIDIA 显卡可用
- 启动 Wallpaper Engine
返回非 0
- 没有可用 NVIDIA GPU
- 不启动

3. 测试脚本

手动运行：

wscript "C:\Scripts\start-wallpaper.vbs"

连接 eGPU 时：应该启动 Wallpaper Engine。
未连接 eGPU 时：应该无任何动作。

4. 创建 Windows 计划任务

打开：

Win + R
taskschd.msc

选择「创建任务」

不要选择「创建基本任务」。

常规

名称：

Start Wallpaper When NVIDIA Available

勾选：

使用最高权限运行

因为 nvidia-smi 需要管理员权限。

触发器

新建：

登录时

高级设置

延迟任务：30 秒

操作

程序：

wscript

参数：

"C:\Scripts\start-wallpaper.vbs"

最终效果

家里

连接 eGPU
 ↓
Windows 登录
 ↓
计划任务等待 30 秒
 ↓
执行 nvidia-smi
 ↓
检测成功
 ↓
启动 Wallpaper Engine

外出

无 eGPU
 ↓
Windows 登录
 ↓
计划任务等待 30 秒
 ↓
执行 nvidia-smi
 ↓
检测失败
 ↓
不启动 Wallpaper Engine

这样可以让壁纸程序根据实际硬件环境自动启停。

动态集合取最值优化：Heap

Thu, 06 Aug 2026 13:15:48 +0800

问题模式

维护一个动态字典：

state = {
 item: value
}

循环执行：

获取 value 最大/最小的 item
修改 state

朴素实现：

max(state, key=state.get)

每次扫描复杂度为 $O(N)$

优化：Heap + HashMap

维护两个结构：

HashMap：保存真实状态
Heap：快速获取候选最值

复杂度：

操作	复杂度
heap push	O(logN)
heap pop	O(logN)
查找最值	O(1)（取堆顶）

Lazy Deletion（惰性删除）

Heap 不支持高效修改已有元素。

因此：

更新状态时：

修改 HashMap
新值重新 push 到 heap
弹出时检查是否过期

示例：

state["a"] = 100

heap:
(-100, "a")

更新后：

state["a"] = 20

heap:
(-100, "a") # stale
(-20, "a") # valid

取值：

while heap:
 value, item = heappop(heap)

 if value == current_state[item]:
 use(item)
 break

注意

Python 中使用 heapq 库时，如果要支持自定义类排序，需要实现类的 __lt__ 和 __eq__ 魔术方法。

Docker 容器时区问题：UTC 导致的自然日业务刷新异常

Tue, 19 May 2026 17:38:41 +0800

最近将微信小程序后端迁移到 Docker 后，出现了“每日刷新”相关 Bug，例如：

每日广告次数未刷新
次日仍然沿用前一天状态

排查后发现，问题并不在业务逻辑，而是：

Docker 容器默认使用 UTC 时区。

而业务中的“每日刷新”逻辑实际上是基于东八区自然日实现的。

例如：

if user.last_ad_time != today:
 user.today_ad_views = 0

当中国时间已经进入第二天时：

中国时间	UTC 时间
2026-05-19 00:30	2026-05-18 16:30

后端仍然认为“还是昨天”，从而导致自然日逻辑整体延迟 8 小时。

最终方案

数据库存储统一使用 UTC

数据库中的 datetime / timestamp 统一存 UTC。

优点：

避免时区混乱
避免夏令时问题
多服务容易统一

前端负责本地化显示

后端返回 UTC：

{
 "created_at": "2026-05-18T16:30:00Z"
}

前端按用户本地时区格式化：

new Date(utcTime).toLocaleString()

自然日业务明确业务时区

像：

每日限额
定时刷新

这类逻辑本质上依赖“业务时区”。

对于面向中国用户的服务，直接统一：

ENV TZ=Asia/Shanghai

通常是最简单稳定的方案。

精简镜像中的 tzdata 问题

如果使用 Alpine / slim 等精简镜像：

则可能需要额外安装：

RUN apk add --no-cache tzdata ca-certificates

总结

目前采用的时间处理策略：

层级	策略
数据库存储	UTC
前端显示	用户本地时区
后端 Docker 容器	`TZ=Asia/Shanghai`

使用 Certbot --webroot 模式为 Nginx 配置 HTTPS

Tue, 19 May 2026 03:04:28 +0800

之前我一直使用：

certbot --nginx

来自动申请和配置 HTTPS 证书。

这种方法虽然方便，但在实际使用中，我遇到了比较严重的问题：

certbot 会自动修改 nginx 配置
certbot 会自动 reload/restart nginx，导致systemd 状态与 nginx 实际状态脱节，出现“游离 nginx”，然后第一个证书成功、后面失败

最终决定迁移到：

certbot --webroot

这种模式下：

certbot 不再接管 nginx
不再自动修改 nginx 配置
不再 reload/restart nginx
nginx 完全手动管理

一、安装 certbot

Ubuntu：

sudo apt update
sudo apt install certbot

二、创建 challenge 目录

统一使用：

mkdir -p /var/www/.letsencrypt/.well-known/acme-challenge

说明：

certbot 以 root 身份运行，因此无需 www-data 写权限
nginx 只需要可读权限

三、配置 nginx challenge 路由

在所有 80 端口 server 中加入：

location /.well-known/acme-challenge/ {
 root /var/www/.letsencrypt;
}

例如：

server {
 listen 80;
 server_name fupcode.com www.fupcode.com;

 location /.well-known/acme-challenge/ {
 root /var/www/.letsencrypt;
 }

 location / {
 return 301 https://$host$request_uri;
 }
}

四、申请证书

certbot certonly --webroot -w /var/www/.letsencrypt -d fupcode.com

说明：

参数	含义
certonly	只申请证书，不修改 nginx
–webroot	使用 webroot challenge
–cert-name	指定证书名称，可选，默认为域名
-w	challenge 根目录
-d	域名，可多个

五、查看证书

certbot certificates

证书通常位于：

/etc/letsencrypt/live/fupcode.com/

例如：

/etc/letsencrypt/live/fupcode.com/fullchain.pem
/etc/letsencrypt/live/fupcode.com/privkey.pem

六、配置 nginx HTTPS

在 nginx 中手动配置：

ssl_certificate /etc/letsencrypt/live/fupcode.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/fupcode.com/privkey.pem;

例如：

server {
 listen 443 ssl http2;
 server_name fupcode.com www.fupcode.com;

 ssl_certificate /etc/letsencrypt/live/fupcode.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/fupcode.com/privkey.pem;

 location / {
 proxy_pass http://127.0.0.1:8000;
 }
}

七、nginx 重载

nginx -t
nginx -s reload

八、配置 deploy-hook

mkdir -p /etc/letsencrypt/renewal-hooks/deploy

cat >/etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh <<'EOF'
#!/bin/sh
nginx -s reload
EOF

chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

九、测试续期

certbot renew --dry-run

如果成功，说明：

challenge 正常
续期流程正常

trRNA2 (2026)：将 Secondary Structure 引入 Attention 并驱动 RNA 构象建模

Thu, 30 Apr 2026 17:05:46 +0800

trRosettaRNA2 利用二级结构 (SS) 做了两件很有意思的工作

让SS加权于attention
通过多 SS 条件输入实现 RNA 构象分布

SS加权于attention

trRosettaRNA2 除了将ss作为一层feature，还在 structure module 中引入 SS-aware attention，其核心是对 attention softmax 的重加权：

标准 attention
$a_{ij} = \frac{\exp\left(\frac{q_i k_j}{\sqrt{d}}\right)}{\sum_{l=1}^{L} \exp\left(\frac{q_i k_l}{\sqrt{d}}\right)}$
SS-aware attention
$a_{ij} = \frac{\left(\exp\left(\frac{p_{ij}}{T}\right) - 0.99\right)\exp\left(\frac{q_i k_j}{\sqrt{d}}\right)}{\sum_{l=1}^{L} \left(\exp\left(\frac{p_{il}}{T}\right) - 0.99\right)\exp\left(\frac{q_i k_l}{\sqrt{d}}\right)}$

其中，

$p_{ij}$ 表示由二级结构预测模型给出的第 $i,j$ 个核苷酸形成碱基配对的概率
$T$ 是 SS temperature，用于控制二级结构先验对 attention 的影响强度。
- 当 $T$ 较小时， $\exp(p_{ij}/T)$ 对 $p_{ij}$ 更敏感，SS 对 attention 的影响更强；
- 当 $T$ 较大时，权重差异变小，模型更多依赖自身学习到的几何和 pair 表征。
- 在代码中，StructureModule 默认使用逐层递增的温度，在结构生成早期强烈注入二级结构约束，在后期逐渐放松。

我的理解

传统的方法是把ss作为pair representation的一层feature，这种方式也许学习效果不佳
加权attention从而让模型不容易忽略长程相互作用

多 SS → 构象分布

核心思路

RNA 往往具有显著的构象灵活性

trRosettaRNA2 的做法是：

构造多个 SS（来自不同预测器或模型）
对每个 SS 独立进行 3D 预测
聚合得到结构集合（ensemble）

实现细节

使用 11 种不同 SS 来源（如 trRNA2-SS、SPOT-RNA、RNAfold 等）
每个 SS 输入下：
- 运行模型多个 recycling（4 次）
最终得到：
- 共 44 个结构（11 SS × 4 次）

对比：AlphaFold3 的做法

作为对照，AlphaFold3 并不显式使用 SS 作为条件变量，而是：

固定输入（sequence + MSA）
通过 不同随机种子（random seeds） 进行多次推理
共生成约 100 个结构

结果

trRosettaRNA2 能生成与实验接近的构象分布
AlphaFold3 更接近单一结构预测器

参考文献

Wang, W., Peng, Z. & Yang, J. Predicting RNA 3D structure and conformers using a pre-trained secondary structure model and structure-aware attention. Nat Mach Intell (2026). https://doi.org/10.1038/s42256-026-01223-x

Docker 挂载单个文件的一个隐蔽 Bug：修改后容器和宿主机会“分离”

Thu, 12 Mar 2026 19:11:13 +0800

问题背景

Docker Compose 里经常会把单个配置文件 bind mount 到容器中：

services:
 web:
 image: my-app
 volumes:
 - ./config.json:/app/config.json

这样写很方便：宿主机改配置，容器里也能读到新内容，不需要重新构建镜像。但它有个隐蔽问题：某些编辑方式会让宿主机文件和容器内文件断开同步。

现象

容器启动后，最开始一切正常。后来你用 vim、VSCode 或 sed -i 修改 config.json，可能会发现：

宿主机上的 config.json 已经更新
容器里的 /app/config.json 仍然是旧内容
容器继续使用旧配置
两边对这个文件的修改不再互相可见

这个问题看起来像同步失效，但本质上是挂载点还指向旧文件。

原因

单文件 bind mount 的关键点是：Docker 挂载的是当时那个文件对象，而不是永远跟随这个文件名。

./config.json inode A -> /app/config.json

很多编辑器保存文件时，并不是直接在原文件上修改，而是走类似这样的流程：

写入 config.json.tmp
rename(config.json.tmp, config.json)

保存完成后，宿主机路径 config.json 指向了新的 inode：

宿主机: ./config.json -> inode B
容器内: /app/config.json -> inode A

容器仍然挂着旧文件对象，于是宿主机和容器里的文件就“分离”了。

为什么隐蔽

它不是每次修改都会触发，而是取决于工具的保存方式：

操作	是否可能更换 inode
`vim` 保存	可能
VSCode 保存	可能
`sed -i`	可能
`cp` 覆盖	可能
`echo >> file`	通常不会

所以它经常表现成“之前都正常，某次修改后突然不生效”。

Compose 示例

services:
 web:
 image: my-app
 volumes:
 - ./data:/app/data
 - ./logs:/app/logs

配置、日志、运行数据都按目录挂载，后续新增文件也不需要再改 compose。

总结

单文件 bind mount 的坑在于：文件名没变，不代表底层文件对象没变。编辑器或命令一旦用 rename 覆盖原文件，容器可能还挂着旧 inode，导致宿主机和容器内的文件不再同步。

实际项目里，优先挂载目录：

不推荐: ./config.json:/app/config.json
推荐: ./data:/app/data

单文件挂载只适合非常明确、不会被运行时频繁编辑替换的场景。