兴城的海，没有秦皇岛、青岛那种成熟海滨城市的精致感。

海岸线景区附近也有大量的破败的房屋和废弃的港口、渔船、酒店、烂尾楼，带着一点褪色和沧桑的气息。

兴城的游客也非常少，6 月的周末、晴天的下午，从龙回头到和平广场长长的一段栈道看不到多少人，到了和平广场更是显得空旷，下午三四点广场上几乎看不见人，旁边的高楼也分不清到底是住人了还是烂尾了，因为从外墙上看不出任何居住痕迹。

来这里的第二天，住进了一家 27 层的民宿，对面就是一望无际的渤海，今天空气通透度不高，连地平线都看不清，但是高处的视野和风景还是很夯的。

晚上的时候，只能吃泡面加饼干，不敢想象居然在非滑雪场景下，出门旅游住酒店吃这种东西当晚餐，因为周围实在是找不到任何一家可以吃的店子，包括外卖基本都在 6km 之外。

天黑了才发现，30多层的小区，楼下看不到海的楼层几乎都是黑灯瞎火的，而高层已经都被改成了民宿。

回北京的直达动车只有上午十点的一趟 D506，早早的起来坐 K1 公交车去兴城西站，发现司机还是来的时候的那位大叔，动车的乘务员说，下个月 D506 就变成 G 字头了，车票贵了几十块，速度还是不变。

有人说 CPU 被打满，有人发现机器里多了陌生 SSH 公钥，有人被云厂商发 abuse，还有人发现自己的小鸡被拿去挖矿、做代理、打流量。NodeSeek 上更直观，列表里隔几条就是一个哪吒相关帖子：求助、复盘、检测脚本、清理脚本、替代方案，什么都有。

我一开始也以为这只是“面板密码太弱”或者“SSH 被爆破”。后来越查越觉得不对。很多机器并没有对应时间段的 SSH 成功登录记录，但后门却几乎同时落地。这个现象很说明问题：攻击者很可能不是一台一台登录，而是先拿到了哪吒 Dashboard，然后通过 Agent 批量下发命令。

换句话说，平时的“集中管理”，出事时就变成了“集中沦陷”。

这篇简单记一下这次事件。不会写太深的漏洞分析，主要讲清楚几件事：为什么哪吒不是普通探针，漏洞大概怎么串起来，社区里看到了哪些中招痕迹，以及现在还在用的人该先做什么。

哪吒不是只读探针

很多人装哪吒，是为了看一个漂亮的服务器状态页。CPU、内存、流量、在线状态，一屏看完，确实舒服。

但哪吒不是只读工具。Dashboard 和 Agent 之间有控制通道，面板里能做不少运维动作：

• Web 终端
• 文件管理
• 计划任务
• 批量命令执行
• Agent 更新和配置下发

这些功能平时很方便。问题是，权限也很重。

如果 Dashboard 被接管，攻击者拿到的不是“看看监控”的权限，而是“让所有在线 Agent 执行命令”的权限。Agent 又通常是 root 跑的，所以面板里下发的一条命令，到了机器上可能就是 root 权限执行。

这也是这次事件影响范围容易扩大的原因。

公开漏洞

这次不是只有社区传言。哪吒官方已经有两个相关的 GitHub Security Advisory。

第一个是 GHSA-5c25-7vpj-9mqh：
https://github.com/nezhahq/nezha/security/advisories/GHSA-5c25-7vpj-9mqh

这个漏洞影响 < 2.0.13。问题出在 Dashboard 的前端 fallback 路由处理上。旧版本判断 /dashboard 路径时不够严，攻击者可以构造类似这样的请求：

1

/dashboard../data/config.yaml

默认部署下，这可能读到 data/config.yaml。里面有 jwt_secret_key、agent_secret_key 这些敏感配置。

其中 jwt_secret_key 特别危险。旧版本里，攻击者拿到它之后，就可能自己签一个合法的 Dashboard 登录态。也就是说，强密码还在，但密码这关已经被绕过去了。

第二个是 GHSA-99gv-2m7h-3hh9：
https://github.com/nezhahq/nezha/security/advisories/GHSA-99gv-2m7h-3hh9

这个漏洞影响 >= 1.4.0, < 2.0.8。它和计划任务权限有关。低权限用户可能通过计划任务接口创建命令，并广播到所有服务器。Agent 收到后会执行，于是就变成了跨主机的远程命令执行。

把这两件事放在一起，大概链路就是：

1
2
3
4
5
6
7

Dashboard 暴露公网
-> 读取配置文件
-> 拿到 JWT 密钥
-> 伪造登录态
-> 进入 Dashboard
-> 创建恶意计划任务
-> 所有在线 Agent 执行命令

所以很多人看到的是“所有机器一起出事”。这不是巧合。一个 Dashboard 后面挂了多少 Agent，攻击者就可能一次打到多少台。

时间线

这次比较容易让人误解的一点是：漏洞不是今天才修，但爆发却集中在这几天。

按公开资料和社区反馈，大概是这样：

• 2026-05-17：官方发布 GHSA-99gv-2m7h-3hh9，计划任务权限问题被披露，修复版本是 2.0.8。
• 2026-05-31：官方发布 GHSA-5c25-7vpj-9mqh，路径穿越问题被披露，修复版本是 2.0.13。
• 2026-06 上旬：社区里已经有人反馈异常 Agent、异常任务、陌生 SSH 公钥。
• 2026-06 中下旬：更多 VPS 用户开始集中发现 CPU 异常、挖矿、流量代理、随机后缀 Agent 服务。
• 2026-06-20 前后：哪吒主控最新版本已经到 v2.2.6，Agent 最新是 v2.2.2。

这说明修复版本早就有了，但暴露在公网的旧面板并不会自动消失。攻击者可能早就扫过一轮，真正变现的时候，大家才看到 CPU 和流量异常。

“养鱼”和“收网”这种说法听起来很戏剧化，我不想把它写成定论。能确认的是：漏洞公开存在，修复版本已经发布，社区里确实出现了批量中招。

为什么 SSH 强密码和 UFW 没挡住

很多人第一反应是：我 SSH 密码很强，甚至只开了密钥登录，为什么还会中？

因为攻击可能根本没走 SSH。

如果攻击者控制的是 Dashboard，那被控机器只要能主动连上 Dashboard 就行。UFW 通常拦的是入站连接，而 Agent 连 Dashboard 是出站连接。

也就是说，攻击路径更像这样：

1

攻击者 -> Dashboard -> Agent -> 服务器本机执行命令

而不是：

1

攻击者 -> SSH 登录每台服务器

所以 SSH 强密码、改端口、禁密码登录，这些都很重要，但它们防的是 SSH 这条路。这次的问题大概率是从控制面进来的。

社区里看到的中招痕迹

不同人机器上的载荷不完全一样。下面这些是社区复盘里反复出现的现象，适合拿来做排查方向，但不要当成完整 IOC。

有人从中招的 SQLite 数据库里提取到过恶意计划任务，内容包括：

1
2
3

写入 /root/.ssh/authorized_keys
curl / wget 下载远程脚本并执行
拉取挖矿或代理变现程序

也有人发现机器上多了随机后缀的哪吒服务：

1
2

nezha-agent-xxxxxxx.service
nazha-agent-xxxxxxx.service

对应的配置文件可能长这样：

1

/opt/nezha/agent/config-xxxxx.yml

这种做法会增加清理难度。只停掉原本的 nezha-agent.service 不够，随机后缀的服务可能还在运行。

还有一些机器出现了挖矿和流量套利程序，比如 XMRig、c3pool，或者一些代理/带宽变现容器。这类东西不一定马上把业务搞挂，但会悄悄吃 CPU、带宽和云厂商信用。

更麻烦的是内存驻留进程。有些复盘提到伪装成 kworker 的用户态进程、memfd 内存马、执行路径显示为 (deleted) 的进程。查文件不一定能看到，得看 /proc、进程树和网络连接。

我觉得比较实用的排查顺序是：

1
2
3
4
5
6
7
8

1. 查 Nezha 计划任务和 Dashboard 数据库
2. 查 systemd 服务，尤其是随机后缀服务
3. 查 crontab 和 /etc/cron*
4. 查 authorized_keys 是否多出陌生公钥
5. 查高 CPU 进程、挖矿进程和代理程序
6. 查 /tmp、/dev/shm、/opt、/root 下近期新增文件
7. 查 memfd、deleted exe、伪装 kworker 进程
8. 查 Docker 容器和镜像

一键清理脚本可以止血，但不能证明系统已经可信。机器被 root 权限控制过之后，更稳妥的处理方式仍然是重装系统，然后轮换所有可能泄露的凭据。

现在该做什么

如果你用过受影响版本，或者 Dashboard 曾经暴露在公网，我会按这个顺序处理。

1. 堵住入口

   先升级 Dashboard，不要让面板直接暴露公网。访问入口可以收敛到 WireGuard、Tailscale、Cloudflare Access、内网反代或 IP 白名单。随后轮换 jwt_secret_key、agent_secret_key，清理旧登录态和旧 token。

2. 检查控制面

   重点看 Nezha 计划任务、Dashboard 数据库里的异常任务、通知配置、Webhook、OAuth 设置，以及是否存在陌生用户或异常登录痕迹。

3. 逐台检查节点

   查随机后缀的 nezha-agent-*.service，查 /opt/nezha/agent/config-*.yml，查挖矿进程、代理容器、/tmp、/dev/shm。如果有条件，再查 memfd、deleted exe、伪装 kworker 这类更隐蔽的进程。

4. 轮换凭据

   SSH key、面板密码、云服务 API key、对象存储、邮件、支付、AI 服务等，只要这台机器上可能读到，都应该按泄露处理。

如果已经出现陌生 SSH key、挖矿进程、异常流量，或者你不确定机器到底被做过什么，别太相信“清理干净了”。备份必要业务数据后重装系统更稳。

以后还用不用这类面板

这次事件不是简单的“哪吒能不能用”。真正的问题是，所有“监控 + 控制”一体化面板都要按高危入口对待。

如果一个面板可以打开终端、管理文件、批量执行命令，那它就不只是监控面板，而是运维控制台。它不该直接暴露在公网，也不该和普通状态页一个安全级别。

监控最好尽量只读。能不用远程执行，就不要开远程执行。能让 Agent 低权限运行，就不要 root。能放内网，就别放公网。

说到底，漂亮 UI 不是安全边界。生产环境里，少一个控制入口，往往比多一个炫酷面板更值钱。

参考资料

• Aska あすか：哪吒监控安全事件复盘
  https://x.com/Asuka_Makina/article/2067017819099983926

• NodeSeek：哪吒探针漏洞攻击全记录
  https://www.nodeseek.com/post-786371-1

• NodeSeek：哪吒面板漏洞被批量植入后门全过程
  https://www.nodeseek.com/post-779143-1

• GitHub Security Advisory：GHSA-5c25-7vpj-9mqh
  https://github.com/nezhahq/nezha/security/advisories/GHSA-5c25-7vpj-9mqh

• GitHub Security Advisory：GHSA-99gv-2m7h-3hh9
  https://github.com/nezhahq/nezha/security/advisories/GHSA-99gv-2m7h-3hh9

黄土高原上的北魏古都，煤炭重镇，云冈大佛。

day 1 大同古城

大同给我的第一印象就是 —— 非常板正的一个城市，整个平城区就是从中间的古城开始，一个方框套着另一个方框。

七点多从酒店出来，步行到古城，从西边清远门进，逛到东边和阳门出，然后骑共享单车回来。

古城的灯一直开到十一点左右，晚上也很热闹。

day 2 云冈石窟 & 晋华宫矿坑

从平城市区出发，打车二十多块钱就可以到云冈石窟，大概半小时不到。

石窟本身规模很大，开凿于北魏，距今已经一千五百多年，很多佛像的脑袋已经被人摘走了，16-20 昙曜五窟很壮观，也可以直接室外露天观看。

其他的窟都需要门口排队进去，人很多，很挤。

推荐从 20 窟开始往回看，推荐参考 B 站「-小老西儿」的解说：

• https://www.bilibili.com/video/BV1g9bEzcEZR 云冈石窟教科书级讲解（上）
• https://www.bilibili.com/video/BV19mbEzPE3c 云冈石窟教科书级讲解（下）

云冈石窟对面的晋华宫矿坑公园倒是意外之喜。这里是一个废弃的露天煤矿改建的公园，在山顶可以俯瞰整个矿坑，工业遗址的震撼感远超对面的石窟——虽然没有下去，站在上面看已经觉得很值了。

虽然距离云冈石窟就不到1km，但两个景点可以说人流量一个天一个地，这个公园里面慢慢的晃悠一下还是很舒服的。

day 3 善化寺

一早出门就碰上沙尘暴，天色灰黄，风沙扑面。

想骑小黄车在古城里逛逛，换了七八个停车点，每一个都显示「此处不可停车」，明明画在标注的停车区域内。

骑车回酒店的路上，天气又突然变脸，瓢泼大雨砸下来，淋在身上变成泥水，而天气预报显示今天只是「普通阴天」。

感觉自己已经慢慢从 J 人往 P 人在迁移了，不管是工作还是旅行，你的计划总是赶不上变化，一直 J 就很痛苦。

但这一天也有唯一一个真正打动我的东西：吉祥天女。

逛了那么多石窟和佛像，大多数时候我是无感的，但这一尊例外。

几乎不像宗教造像，更像是某个真实存在过的人。

线下看到这尊佛像的时候真的很惊艳，就像东方的蒙娜丽莎，似笑非笑，似哭非哭，眼神里真的有佛家那种超然物外的感觉。

关于大同的吃的

这几天吃了好多碗刀削面，记录几家店子：

• 「龙聚祥烧麦馆」 - 点了烧麦、黄米凉糕、黑豆腐、茄盒。

  • 印象最深的是黑豆腐——烧得非常入味，豆腐外酥里嫩，极为好吃。
  • 黄米凉糕也很惊喜，口感糯，清甜，吃起来有种莫名的治愈感。
  • 烧麦和南方的烧麦不太一样，似乎这边做的更像是汤包？不过也挺好吃。
  • 燕麦茄盒也不错，油炸的，里面是芝士。

• 「喜晋道」

  • 据说是大同刀削面里的爱马仕，其他刀削面馆猪肉刀削面大概 10 元左右，这家 19，最主要是队排老长了，最好去古城外那几家分店吃，不然排几个小时都吃不上。
  • 刀削面中规中矩，没有惊喜，虎皮青椒和鸡爪做得比一般小馆子好一些——但考虑到价格，也很难说性价比高。

• 「东方削面」

  • 也是比较火的一家连锁面馆，牛肉刀削 14 一份，猪肉 10 元一份，比喜晋道便宜，但是还不如楼下苍蝇馆子的好吃。

• 「酒店楼下 — 日升面馆」

  • 楼下的苍蝇馆子，不管是青椒还是豆腐都做的比其他店入味，估计是汤里泡很久。
  • 除此之外面一般，甚至吃了10分钟，底下的面就坨了，东方和喜晋道的面就没有这种情况。
  

  

  

  

  

一些其他记忆

• 大同（平城区）的车道：主干车道往往是 8 车道甚至 10 车道，非常宽敞，非机动车道很有意思，和机动车道中间往往会隔一排人行道或者绿化带，然后和另一侧的人行道之间又是平行的（导致车开上人行道非常容易）。

  • 但不好的一点就是，很多车在非机动车道上行驶，然后在路上乱停的车也很多。

  

• 城市里没有地铁，打车还算方便，网约车到哪里基本都是 20 以内。

• 共享单车系统很烂，那么大一个古城区，几乎找不到共享单车停车位。

• 大同的风实在是太大了，地理位置近蒙古且没有高山阻挡，有沙尘暴也是最先受到侵袭的一批，就待了 2 天还给我踩中一天，主要的是，即使在沙尘暴之前的一天，甚至天气预报都没有提前预警。

• 恒山和悬空寺整个 4 月都在维护，原因也是因为风大怕吹下来石头，不过似乎我本身的2天行程也赶不上去恒山，除非特种兵。（有意思的是，似乎大同还不忍心放弃 5.1，维护到 4.30 就结束了。）

• 整体来说，如果想体验人文和古建筑，大同还是一个非常不错的城市，东西也算比较好吃的那一档。

  • （但我本身对这些历史文化不那么感兴趣，so… 以后旅行可能还是会优先考虑山川湖海）

准备

• 酒店: 是在招行上订的海景房，叫「汇泉王朝大饭店」(400/day)，就在第一海水浴场的上方，清明这个价格感觉是相当可以了，海景也很不错。

• 车票: 往返都是高铁，单程 400 左右，清明的票非常的不好买，于是请了一天年假早一天出发，也提前了一天回来。

其实有了大交通 + 酒店，青岛剩下的景点就不用做什么提前预约和规划了，绝大多数海边的景点都是免费的，如果要去啤酒博物馆，海洋公园，或者崂山，可能需要提前规划/预约一下。

但实测，这三天下来，每天 3w 步，也差不多刚刚好把 栈桥 —— 石老人 这一条滨海线路走一遍。

附上我三天的线路:

三天行程

day 01

青岛站下车以后，直接地铁 3 号线，汇泉广场站下车，步行 5min 就到酒店了。

来青岛以后看了一眼地铁线路图，第一感觉就是 —— 地铁修的真好，整个市南区的海岸线几乎都覆盖到了地铁 (2, 3 号线)，所以这三天我也没有打过车，出行全地铁^[1]就够了。

到酒店先吃了一顿 200 块的自助，在酒店 25 层的旋转餐厅 —— 这个餐厅居然真的会转，大概 90 分钟自转一圈，由于是附近最高（第二高？）的建筑，可以看到全部的海景和城景。

第一天很不巧，从中午开始以后，全是平流雾^[2] + 霾的天气，海边的天气真是非常多变，即使我出行的前一天晚上看天气还是 3 天晴天，到了当天就变成 雾 + 霾 + 风 + 雨。

所以拍出来的照片 be like:

从第一浴场走到栈桥，然后到天主教堂，最后从小鱼山下来回到酒店，其实体验有点一般，市内的景观都是人造的，而老城区的红瓦绿树在这种阴天下又毫无美感。

许多年轻人聚集在「网红墙」前拍照，凑近了看不过是两个路牌，所以当我导航到这里的时候，我甚至直接走过去了才发现原来已经走过了。

—— 所以很多时候不想去那些人文景点，总感觉有些符号营造的太刻意。

晚上的时候，从五四广场随便吃了点东西就往奥帆中心走，因为那里可以看到青岛新城区的灯光秀。

新城区的夜景真的很华丽，全是几十层的高楼，把整个海边染的五光十色。

然后回来以后到酒店楼下的青岛啤酒店，搞了一点青岛啤酒一厂和四厂的原浆和鲜啤：

都很好喝，口感和之前喝过的「泰山7天/28天」非常像，总之比罐装的水啤要好喝很多。

day 02

第二天的天气非常的好，于是拿上了我的 xs20 开始暴走模式。

整个白天基本都是在滨海绿道上徒步，文字不足以描述晴天大海的美，放图即可——

上午从第一浴场一直走到了小麦岛，然后下午先坐地铁回来走了一圈八大关，之后又重返小鱼山俯瞰了一下青岛老城，“红瓦绿树，碧海蓝天”，晴天的青岛真的很浪漫。

第一浴场的酒店看不到日落，于是就等太阳落下山以后拍了几张蓝调:

晚上，去吃了「前海沿」的海肠捞饭，其实吃不太出来海肠的味道，更多像是一种吃口感的东西，饭虽然很好吃，但是更多的味道来自于酱油、韭菜、肉沫。

day 03

第三天的天气和第一天如出一辙，都是雾霾阴天，并且已经有点疲惫了，前两天都是暴走模式，脚已经有点跟不上了，退完房以后背着书包从海之恋公园漫步到石老人浴场，走一会歇一会。

中午吃了「粥全粥到」的蛤蜊炒鸡和鲅鱼饺子，还可以吧，不过感觉不如黄焖鸡和金谷园的饺子。。

中午就已经抵达青岛站了，出来以后去了一个叫「团岛山」的公园，公园上开满了淡紫色的花，人特别特别少，即使离栈桥很近很近。

在这里坐了很久，感觉旅行的时候，我就喜欢挑这种清净小众的地方多停留一会，即使风景没有那么极致。

从山上下来以后又去了一趟栈桥，给我吓出密集恐惧症了。

碎碎念时间

• 前几天做攻略的时候看别人说，青岛是一个镶着金边的破抹布，感觉说的确实很有道理，虽然没怎么深度体验市内的人文，但是趁吃饭的时候去市北区转了转，感受是确实挺脏乱差的。

  • 不过也可以称之为「烟火气」吧，也许。

• 市南区的交通便利又混乱，地铁直通大多数地方，但是陆地上的机动车道大多是单行道，很堵，然后人行道上挤满了送外卖的电动车——因为并没有非机动车道。

• 和大连一样的，这里看不到共享单车，不过骑自行车的人还挺多的，没有特别起伏的地形。

• 总的来说，因为天气的原因，可能只体会到了 1 天完全体的青岛，但是能感受到这座城市对于旅游来说还是非常不错的，海岸线超级长，可以走好几天，也许会挑一个暖和一点的天气过来，感受一下崂山和黄岛区。

• 路线总结:

  • day 01: 第一海水浴场 → 青岛水族馆 → 鲁迅公园 → 琴屿路 → 小青岛公园 → 海军博物馆 → 太平路 → 栈桥 → 天主教堂 → 网红墙 → 小鱼山
  • day 02: 第一海水浴场 → 八大关 → 第二海水浴场 → 第三海水浴场 → 音乐广场 → 五四广场(五月的风) → 奥帆中心 → 燕岛山 → 情人坝 → 滨海绿道走完 → 小麦岛公园
  • day03: 小麦岛 → 海之恋公园 → 极地海洋公园 → 滨海绿道 → 石老人浴场

References

🖼️ 多图

day 0 - 启程

坐上 K684，开启去往大连的旅途。

这趟卧铺有很多好处：

• 北京-大连分别是始发和终点站，床上用品都换过了。
• 可以在第二天一早抵达大连。
• 工作日人超少（这节车厢中上铺都没有人，下铺也没满），一晚上都很安静。
• 大连站刚好在市中心

day 1 - 东港

酒店定在了中山广场，

早上 7 点到了酒店，直接就可以办入住了（赞一波亚朵）。

然后包放下以后就直接坐地铁来到了东港。

这一天还是端午节的最后一天，并且天气一般，预想到体验可能不会很好，不过实际逛下来还是比想象中的好不少。

几个景点的感受：

• 东港广场： 喷泉附近有很多的海鸥，用北京带来的面包（本来准备火车上当早餐的）喂了一波，感觉还挺有意思的，不过小心 🐦💩。
• 威尼斯水城： 白天没什么好逛的，就是一个小商业街的模式，听说晚上的灯光氛围还可以，不过后面也没有晚上来过。

回酒店吃了一个午饭歇了一会，下午直接打车到海之韵公园继续漫步。

海之韵公园从北门进，上来就是一段超级大上坡，差点没给人累死，在大太阳下走了快半小时才到山顶，不过从山上眺望大海的感觉还蛮好的。

往山下走，为了看一个网红景点「圣象天门」跟着一群大胆的游客翻了好几个护栏和挡板，到了以后发现不过如此，一大群人排队围着一个山洞拍照，虽然到达这里花了很大一番功夫，但是真正到了之后，我也懒得挤过去凑热闹了。

可能每个人对于旅行的理解都不一样，不过我是不太喜欢到了一个地方，就要打卡那些「出片」的网红景点，反倒是喜欢钻入无人的犄角旮旯去探索一下。

一路上发现了好多可爱小猫，最喜欢的是这只大橘和这俩狸花：

出了海之韵公园南门，就一直沿着滨海东路走啊走啊，一个下午走了快 30km，4 万步。自己走路有一个好处就是不必迁就他人，遇到想走的路和想看的东西，就直接走就完事了。

大连是丘陵地带，海边没有沙滩，只有断崖和礁石滩，这边整个滨海东路都是断崖，也是一种独特的风格。

随处可见这样的告示：

途中遇到可以拐下去的地方，无一例外都选择了下去看看，遇到了很多惊喜的景点。

许多地方就是沿着断崖修建的小路或者房子，左边是树林，右边就是一望无际的大海。

day 2 - 亲海栈道

第二天一早就打车来到了老虎滩-菱角湾。

假期过了，天气晴了，大海的颜色变成深邃的蓝，拍照非常好看。

大连的海边有非常多的本地钓鱼佬，都是轻装出行，一根钓竿一把小椅子，一坐就是大半天，给人一种非常 chill 的感觉。

一路上都是这种非常舒适的步行木栈道，基本覆盖了从海之韵公园出来一直到星海广场这一条几十公里长长的海岸线。

走到付家庄公园，远看是一个沙滩，近看原来是石子组成的。

快黄昏时走到了大连的标志性建筑「星海湾大桥」，这个 6.8km 的跨海大桥从各个角度看过去都很壮观。

日落时桥上还会亮起不同颜色的灯光，不过当时有点冷，就没在山顶逗留了，不然俯视角下的夜景应该会很好看。

day 3 - 一些城市景观

体验了一下大连的有轨电车，由于是工作日车上没什么人，车晃悠的不行、叮铃哐啷的很有意思。

大连城市的街道两旁见不到任何共享单车，不过倒是有一些共享的电动车，可能是因为城市规划的原因（没有非机动车道），并且丘陵地带很多陡峭的上下坡，确实不太适合骑单车。

晚上 8 点来到南山街，没有想象中热闹的街景，只有节日过后人们正在收拾残局。

而且大连的风真的很大，即使在城区里也能吹的人头秃，于是匆匆离开。

后记

写这篇 Blog 的时候这次旅行已经过去快 2 周了，不过一切景物还是历历在目。

旅行这种事情确实能极大的减缓时间流逝的感觉，让人重拾起一种控制时间与生活的信心。

滨海城市的旅行体验真的极好，有时间会再去威海、青岛这些地方看看。

很喜欢的一句话:

只有一个人旅行时，才听得到自己的声音。它会告诉你，这世界比自己想象中更宽阔。

毕业答辩结束，又因为还需要等着提交材料没法长途跋涉，想着天津离北京这么近又还没去过，索性去看看。

初印象：混乱街道与大碗饭菜

5月末，白天的天津，炎热难耐，走在大街上，似乎不存在斑马线和行人红绿灯。

好多好多的单行道和狭窄街道。下火车出了地铁左转，因为没有人行道，只能在逆行穿过一股酒味的涵洞。

第一顿当然尝一下天津菜，没想到分量巨大无比，一盆炒鸡估计炒了不止一只鸡。

两个饭量还不错的人吃了一个小时，最后菜和没动一样。

海河游船

晚上去天津站码头坐了海河游船，也是此次天津之行感觉最值回票价的体验。

出了天津站就是码头，长长的海河沿线几乎包含了所有天津有名的景点。

如果天津没有这条海河，也许我给的评价还不如我老家。

周围高楼林立，每个楼都闪着金光，有种轻奢感。

平平无奇的周内工作日，海河周围散步的人也是熙熙攘攘。

到了晚上 10 点多才逐渐安静下来，这时沿着河边散步几乎只剩下一个个卖酒的小摊贩。

心情还不错的时候，吹着晚风这么喝一杯还挺惬意。

白天的天津：炎热而无聊

白天走马观花的看了世纪钟广场、津湾广场、西开教堂、北安桥、意式风情街、瓷房子、五大道等等一系列建筑。

如果天气凉快一点，也许还有心情停下来欣赏一番，然而 30 度的艳阳天只能让我像特种兵打卡一样匆匆拍个照就走人。

体验一般，不过即使是凉快下来，感觉白天的天津相比晚上也差了不少意思。

相声：有点意思

下午的时候实在逛不下去了，干脆花 2 小时去听下相声。

直到开场的时候才陆续来了其他两桌人，不然直接包场了，那样还挺尬的。

第一次线下花这么长时间完整的听完一场相声，感觉还不错，主要空调还很凉快。

最后又在夜风中搭观光车溜达了一圈，感觉天津城区真的好小，已经有点腻了。

还是更喜欢山川湖海。

注意，本文不是翻译，只是针对自己觉得有用的一些地方的记录和总结；对于我自己觉得已经比较清楚的概念，就完全没有记录。其中最后的「最佳实践 Best Practice」部分个人感觉比较有用，强烈建议结合原版 PDF 的一些示例 demo 进行对比查看。

简单介绍：

「Prompt Engineering」是 Google 推出的提示词工程白皮书，一共 60 多页，原始版本可以在 https://www.kaggle.com/whitepaper-prompt-engineering 上获取到，或者直接 下载链接 (googledrive)。

1 - 采样控制

主要三个可配置项:

• Top-P
• Top-K
• Temperature (温度)

作用的先后顺序: Top-K -> Top-P -> Temperature

例子

假设我们有以下设置：

• top-k = 5
• top-p = 0.9
• temperature = 0.7

当模型预测下一个词时，可能给出了这样的概率分布：

• “的”: 0.3
• “是”: 0.25
• “在”: 0.2
• “了”: 0.1
• “有”: 0.05
• “和”: 0.03
• “人”: 0.02
• 其他词: 各小于0.01

应用步骤：

1. top-k=5筛选后，只保留前5个词：“的”、“是”、“在”、“了”、“有”
2. 计算这5个词的累积概率：0.3+0.25+0.2+0.1+0.05=0.9，正好等于top-p的阈值0.9，所以这5个词都被保留
3. 应用temperature=0.7，通常来说，温度与模型的“创造力”有关。但事实并非如此。温度只是调整单词的概率分布。其最终的宏观效果是，在较低的温度下，我们的模型更具确定性，而在较高的温度下，则不那么确定。(ref: 知乎: 大模型文本生成——解码策略（Top-k & Top-p & Temperature）)

极端情况

几种极端情况的 LLM 实现考虑:

• 温度设为 0 时，Top-K 和 Top-P 无关，概率最高的令牌被选为下一个预测令牌；温度极高（如 10 量级）时，温度无关，Top-K 和/或 Top-P 标准的令牌将被随机采样。
• Top-K 设为 1 时，温度和 Top-P 无关，仅概率最高的令牌被选；Top-K 设为词汇表大小时，所有非零概率令牌均满足标准，无令牌被筛选。
• Top-P 设为 0 或极小时，仅概率最高的令牌满足标准，温度和 Top-K 无关；Top-P 设为 1 时，所有非零概率令牌均满足标准，无令牌被筛选。

推荐配置

2 - Guide Prompt 分类

系统提示（System Prompting）、上下文提示（Contextual Prompting）和角色提示（Role Prompting）都是用于指导大型语言模型（LLMs）生成文本的技术，但它们关注的重点不同。尽管这些提示类型之间存在相当大的重叠（例如，一个提示可能同时为系统分配角色并提供上下文），但每种提示的主要目的略有不同。

以下是三种提示类型的核心区别和作用：

system prompt

1
2
3
4
5
6

Classify movie reviews as positive, neutral or negative. Only
return the label in uppercase.
Review: "Her" is a disturbing study revealing the direction
humanity is headed if AI is allowed to keep evolving,
unchecked. It's so disturbing I couldn't watch it.
Sentiment:

contextual prompt

1
2
3
4

Context: You are writing for a blog about retro 80's arcade
video games.
Suggest 3 topics to write an article about with a few lines of
description of what this article should contain.

role prompt

1
2
3
4
5
6
7

I want you to act as a travel guide. I will write to you
about my location and you will suggest 3 places to visit near
me. In some cases, I will also give you the type of places I
will visit.
My suggestion: "I am in Amsterdam and I want to visit
only museums."
Travel Suggestions:

3 - 示例个数: one-shot & few-shot

在为AI模型创建提示时，提供示例非常有帮助。示例可以帮助模型理解您的需求，尤其是在希望模型输出特定结构或模式时特别有用。

• One-shot 提示提供单个示例，因此得名one-shot，目的是让模型有一个可以模仿的示例来完成任务。
• Few-shot 提示则提供多个示例，向模型展示需要遵循的模式，增加模型遵循该模式的机会。Few-shot提示所需的示例数量取决于任务复杂性、示例质量以及所使用的generative AI (gen AI)模型的能力。一般建议至少使用三到五个示例，但对于复杂任务可能需要更多示例，或者由于模型输入长度限制可能需要更少。选择示例时，应确保示例与任务相关，具有多样性、高质量且编写良好，因为一个小错误就可能导致模型混淆并输出不符合预期的结果。此外，如果希望生成的输出能适应各种输入，包含edge cases（异常或意外输入）在示例中非常重要。

4 - Step-back Prompting (回退提示词)

Step-back prompting 是一种通过提示 LLM 先考虑与具体任务相关的一般性问题，然后将该问题的答案输入到后续的具体任务提示中来提升性能的技术。这种“step back”方法使 LLM 在尝试解决具体问题之前激活相关的背景知识和推理过程。通过考虑更广泛和基本的原则，LLM 能够生成更准确和有洞察力的回应。

Step-back prompting 鼓励 LLM 批判性思考并以新的和创造性的方式应用知识，通过利用 LLM 参数中的更多知识来改变执行任务的最终提示，而这些知识在直接提示 LLM 时可能不会被激活。它还可以通过关注一般原则而非具体细节来帮助减轻 LLM 回应中的偏见。

传统 prompt & step-back prompt 对比

传统 prompt:

1

Write a one paragraph storyline for a new level of a firstperson shooter video game that is challenging and engaging.

step-back prompt:

1. 首先询问:

1

Write a one paragraph storyline for a new level of a firstperson shooter video game that is challenging and engaging.

2. 之后基于 LLM 的回答，追加提问:

1
2
3

Based on popular first-person shooter action games, what are
5 fictional key settings that contribute to a challenging and
engaging level storyline in a first-person shooter video game?

5 - APE: Automatic Prompt Engineering (自动生成提示词)

编写提示（prompt）可能是一项复杂的任务。为了解决这个问题，可以采用Automatic Prompt Engineering (APE)方法。这种方法不仅减少了人工输入的需求，还能提升模型在各种任务中的表现。你可以让模型生成更多提示，对它们进行评估，可能的话修改好的提示，然后重复这个过程。

case:

1
2
3
4

We have a band merchandise t-shirt webshop, and to train a
chatbot we need various ways to order: "One Metallica t-shirt
size S". Generate 10 variants, with the same semantics but keep
the same meaning.

6 - Code Prompting

这节没什么特别出彩的，就是列举了几个 coding 的用法，不过可以参考一下 Gemini 在 coding 时是如何推荐配置 topk, topp 和 temperature 的

• Temperature：0.1

• Token Limit：1024

• Top-K：N/A

• Top-P：1

• writing code

1
2
3

Write a code snippet in Bash, which asks for a folder name.
Then it takes the contents of the folder and renames all the
files inside by prepending the name draft to the file name.

• explain code

1

Explain to me the below Bash code:

• translating code

1

Translate the below Bash code to a Python snippet.

• debug code

1
2
3
4
5
6
7
8

The below Python code gives an error:
Traceback (most recent call last):
File "/
Users/leeboonstra/Documents/test_folder/rename_files.py", line
7, in <module>
text = toUpperCase(prefix)
NameError: name 'toUpperCase' is not defined
Debug what's wrong and explain how I can improve the code.

7 - 最佳实践 Best Practices

这个很有价值，一些很容易想到和验证的概念，但是 Google 帮你总结出来了

7.1 - 提供示例 (Provide examples)

最重要的原则是在提示中提供示例（one shot/few shot）。这是高效的方法，因为它能作为强大的教学工具。这些示例展示了期望的输出或类似的响应，让模型从中学习并相应地调整其生成内容，提高准确性、风格和语调。

7.2 - 设计简洁明了的提示 (Design with Simplicity)

提示应该简洁、清晰，易于你和模型理解。如果对你来说已经令人困惑，对模型来说也可能令人困惑。尽量不要使用复杂的语言，不要提供不必要的信息。

示例改进：

1
2
3
4
5

改进前：
I am visiting New York right now, and I'd like to hear more about great locations. I am with two 3 year old kids. Where should we go during our vacation?

改进后：
Act as a travel guide for tourists. Describe great places to visit in New York Manhattan with a 3 year old.

尝试使用描述动作的动词，例如: Act, Analyze, Categorize, Classify, Contrast, Compare, Create, Describe, Define, Evaluate, Extract, Find, Generate, Identify, List, Measure, Organize, Parse, Pick, Predict, Provide, Rank, Recommend, Return, Retrieve, Rewrite, Select, Show, Sort, Summarize, Translate, Write.

7.3 - 明确指定输出要求 (Be Specific About Output)

要明确期望的输出内容。简洁的指令可能不足以引导LLM或过于笼统。在提示中提供具体细节（通过系统或上下文提示）可以帮助模型专注于相关内容，提高整体准确性。

推荐做法：

1

Generate a 3 paragraph blog post about the top 5 video game consoles. The blog post should be informative and engaging, and it should be written in a conversational style.

不推荐的做法:

1

Generate a blog post about video game consoles.

7.4 - 使用指令而非约束 (Use Instructions over Constraints)

• 指令提供了关于期望格式、风格或内容的明确指导，指导模型应该做什么或生成什么
• 约束是对响应的一系列限制或边界，限制模型不应该做什么或避免什么

研究表明，在提示中专注于积极指令比过度依赖约束更有效。这与人类偏好积极指令而非列出不应做的事项的方式一致。

指令直接传达期望的结果，而约束可能让模型猜测什么是允许的。指令在定义的边界内提供灵活性并鼓励创造力，而约束可能限制模型的潜力。此外，约束列表可能相互冲突。

约束在某些情况下仍然有价值，例如防止模型生成有害或有偏见的内容，或当需要严格的输出格式或风格时。

如果可能，使用积极指令：不要告诉模型不要做什么，而是告诉它应该做什么。这可以避免混淆并提高输出的准确性。

示例：

1
2
3
4
5

DO:
Generate a 1 paragraph blog post about the top 5 video game consoles. Only discuss the console, the company who made it, the year, and total sales.

DO NOT:
Generate a 1 paragraph blog post about the top 5 video game consoles. Do not list video game names.

7.5 - 控制最大token长度 (Control Max Token Length)

要控制生成的LLM响应的长度，你可以在配置中设置最大token限制，或在提示中明确要求特定长度。例如：

1

"Explain quantum physics in a tweet length message."

7.6 - 在 Prompt 中使用变量 (Use Variables in Prompts)

在提示中使用变量，可以针对不同输入而改变。例如，提供关于城市的事实的提示。与其在提示中硬编码城市名称，不如使用变量。变量可以通过避免重复自己来节省时间和精力。如果需要在多个提示中使用相同的信息，可以将其存储在变量中，然后在每个提示中引用该变量。在将提示集成到自己的应用程序中时，这非常有意义。

示例：

1
2
3
4
5

PROMPT: You are a travel guide. Tell me a fact about the city: {city}

VARIABLES: {city} = "Amsterdam"

OUTPUT: Amsterdam is a beautiful city full of canals, bridges, and narrow streets. It's a great place to visit for its rich history, culture, and nightlife.

7.7 - 实验不同的输入格式和写作风格 (Experiment with Input Formats)

不同的模型、模型配置、提示格式、词汇选择和提交方式可能产生不同的结果。因此，实验提示属性如风格、词汇选择和提示类型（零样本、少样本、系统提示）很重要。

例如，对于一个目标是 “生成关于革命性视频游戏机Sega Dreamcast的文本” 的 Prompt，其可以表述为问题、陈述或指令，产生不同的输出：

• 问题：Sega Dreamcast是什么，为什么它是如此革命性的游戏机？
• 陈述：Sega Dreamcast是世嘉于1999年发布的第六代视频游戏机。它…
• 指令：写一段描述Sega Dreamcast游戏机并解释为何它如此革命性的单段文字。

7.8 - 分类任务中混合类别 (Mix Classes in Few-shot)

一般来说，few-shot （少样本）示例的顺序不太重要。然而，在进行分类任务时，确保在few-shot示例中混合可能的响应类别。这是因为否则你可能会过度拟合到示例的特定顺序。通过混合可能的响应类别，你可以确保模型正在学习识别每个类别的关键特征，而不是简单地记住示例的顺序。这将导致在未见数据上更强健和可泛化的性能。

一个好的经验法则是从6个few-shot 示例开始，并从那里开始测试准确性。

7.9 - 适应模型更新 (Adapt to Model Updates)

跟踪模型架构变化、添加的数据和功能很重要。尝试更新的模型版本，并调整提示以更好地利用新的模型特性。

7.10 - 尝试不同的输出格式 (Experiment with Output Formats)

例如，对于非创造性任务，如提取、选择、解析、排序、排名或分类数据，尝试让输出以结构化格式如JSON或XML返回。

从提取数据的提示中返回JSON对象有一些好处。在真实应用中，我不需要手动创建JSON格式，可以直接以排序顺序返回数据（处理日期时间对象时非常方便），但最重要的是，通过提示要求JSON格式，它迫使模型创建结构并限制产生幻觉。

使用JSON输出的好处总结：

• 始终以相同风格返回
• 专注于你想要接收的数据
• 幻觉机会减少
• 使其关系感知
• 获得数据类型
• 可以排序

7.11 - 关于思维链(CoT)的最佳实践 (Chain of Thought Best Practices)

对于CoT Prompt，将答案放在推理之后是必需的，因为推理的生成会改变模型在预测最终答案时获得的tokens。

使用CoT和自我一致性时，你需要能够从提示中提取最终答案，与推理分开。

对于CoT Prompt，将temperature设置为0。

思维链提示基于贪婪解码，根据语言模型分配的最高概率预测序列中的下一个词。一般来说，使用推理来得出最终答案时，可能只有一个正确答案。因此，temperature始终应设置为0。

7.12 - 尝试与记录 (Document Prompt Attempts)

前面已经提到过，但我们再次强调：详细记录你的提示尝试，这样你可以随时了解哪些方法行之有效，哪些不行。

提示输出可能在不同模型、不同采样设置，甚至同一模型的不同版本之间有所不同。此外，即使对同一模型的相同提示，输出句子格式和词汇选择也可能存在细微差异。（例如，如前所述，如果两个tokens具有相同的预测概率，则可能随机打破平局。这可能影响后续预测的tokens。）

建议创建一个Google表格，使用模板记录：

• 提示名称和版本
• 目标（一句话解释这次尝试的目标）
• 使用的模型名称和版本
• Temperature值（0-1之间）
• Token限制
• Top-K和Top-P值
• 完整提示
• 输出（或多个输出）

还建议跟踪提示的版本（迭代），记录结果是否OK/NOT OK/SOMETIMES OK，以及反馈。如果有幸使用Vertex AI Studio，保存提示（使用与文档中相同的名称和版本），并在表格中跟踪保存的提示超链接。这样，你只需一次点击就可以重新运行提示。

在使用检索增强生成系统时，还应捕获影响插入到提示中的内容的RAG系统的特定方面，包括查询、块设置、块输出和其他信息。

一旦你觉得提示接近完美，将其带入项目代码库。在代码库中，将提示保存在与代码分开的文件中，这样更容易维护。最后，理想情况下，你的提示是一个可操作系统的一部分，作为提示工程师，你应该依靠自动化测试和评估程序来了解你的提示如何针对任务泛化。

提示工程是一个迭代过程。制作并测试不同的提示，分析并记录结果。根据模型的表现改进你的提示。继续实验直到达到期望的输出。当更改模型或模型配置时，回去继续实验先前使用的提示。

最近在看 vllm 的代码，cpu offloading 这部分它的实现还是比较简单的，这里简单记录一下。

由于大模型的参数量实在很大，所以如果想在单机上运行一般都需要跑量化蒸馏后的模型，但是有时又不想牺牲模型质量，于是CPU/SSD 卸载成为一种折衷方案，通过增加推理时间来降低内存需求。

vllm 也实现了一个简单的 cpu offload 的机制，可以通过 --cpu-offload-gb 启用。

• 官方文档: https://docs.vllm.ai/en/latest/getting_started/examples/basic.html#cpu-offload

这里发现他的实现还是比较简单的，主要就是通过这个 PR ，添加了一个 func 叫 maybe_offload_to_gpu:

• model_executor/models/utils.py#L487-L540

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

def maybe_offload_to_cpu(module: torch.nn.Module) -> torch.nn.Module:
    device = next(module.parameters()).device

    if device == torch.device("cpu"):
        return module

    global _CPU_OFFLOAD_MAX_BYTES, _CPU_OFFLOAD_BYTES
    if _CPU_OFFLOAD_BYTES >= _CPU_OFFLOAD_MAX_BYTES:
        return module

    pin_memory = is_pin_memory_available()

    # offload parameters to CPU
    # use pin_memory if possible, which helps cudagraph capture speed
    offloaded_parameters = False
    for p in module.parameters():
        if _CPU_OFFLOAD_BYTES >= _CPU_OFFLOAD_MAX_BYTES:
            # we use per-parameter offloading
            # one module might have some parameters offloaded and some not
            break

        # `torch.empty_like` does not support `pin_memory` argument
        cpu_data = torch.empty_strided(size=p.data.size(),
                                       stride=p.data.stride(),
                                       dtype=p.data.dtype,
                                       layout=p.data.layout,
                                       device='cpu',
                                       pin_memory=pin_memory)
        cpu_data.copy_(p.data)
        p.data = cpu_data
        _CPU_OFFLOAD_BYTES += p.data.numel() * p.data.element_size()
        offloaded_parameters = True

    if offloaded_parameters:
        original_forward = module.forward

        def forward(*args, **kwargs):
            module.forward = original_forward
            device_state = {
                # here we blindly call `to(device)`
                # if the parameter is already on the device, it will be a no-op
                k: v.to(device, non_blocking=True)
                for k, v in module.state_dict().items()
            }
            output = functional_call(module,
                                     device_state,
                                     args=args,
                                     kwargs=kwargs)
            module.forward = forward
            return output

        module.forward = forward

    return module

这个函数只有一个地方调用了：

• model_executor/models/utils.py#L556-L560

1
2
3
4
5

modules = torch.nn.ModuleList(
    [PPMissingLayer() for _ in range(start_layer)] + [
        maybe_offload_to_cpu(layer_fn(prefix=f"{prefix}.{idx}"))
        for idx in range(start_layer, end_layer)
    ] + [PPMissingLayer() for _ in range(end_layer, num_hidden_layers)])

cpu offload 的整个流程可以概括为:

1. 将传入的 cpu_offload_gb 读取为 _CPU_OFFLOAD_MAX_BYTES。
2. 然后在构建 Module 时对每个 Layer 里面的参数从前往后依次塞到 CPU 的 PIN_MEMORY 上，并累加参数大小 (_CPU_OFFLOAD_BYTES += p.data.numel() * p.data.element_size(), 即参数数量 x 字节大小) 到 _CPU_OFFLOAD_BYTES，直到超过用户配置的可 offload 大小。
3. 替换对应 Module 的 forward 函数，新的 forward 函数和原来的区别就是：在每次 forward 的时候，将 CPU 上的参数复制到 GPU 上，计算完后再释放

一些可能的理解难点

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

if offloaded_parameters:
    original_forward = module.forward

    def forward(*args, **kwargs):
        module.forward = original_forward
        device_state = {
            # here we blindly call `to(device)`
            # if the parameter is already on the device, it will be a no-op
            k: v.to(device, non_blocking=True)
            for k, v in module.state_dict().items()
        }
        output = functional_call(module,
                                 device_state,
                                 args=args,
                                 kwargs=kwargs)
        module.forward = forward
        return output

    module.forward = forward

这里的 forward 替换设计挺有意思：

1. （original_forward = module.forward）：保存模块原始的前向传播函数到变量 original_forward，为后续恢复原始实现做准备。

2. （在 forward 函数内的 module.forward = original_forward）：在自定义的 forward 函数内部首行，当函数被调用时，立即将模块的前向传播方法恢复为原始方法。这一步确保 functional_call 能够使用原始的前向传播逻辑，避免递归调用。

3. （在 forward 函数内末尾的 module.forward = forward）：前向传播完成后，再次将模块的前向传播方法设置回自定义的 forward 函数，确保下次调用时仍能触发这个包含参数加载逻辑的自定义函数。

4. （函数末尾的 module.forward = forward）：为了确保每次都能 hook 到 cpu -> gpu 这部分的逻辑 (参考原 PR 的解释：https://github.com/vllm-project/vllm/pull/6496/files#r1682069375)

这里的核心是使用 functional_call 配合临时的 device_state，实现参数从 CPU 到 GPU 的动态加载。初看可能会疑惑为什么没有将参数从 GPU 释放回 CPU 的逻辑，其实这是因为 device_state 是个局部变量，函数执行完毕后其引用的 GPU 张量会自动被 Python 的垃圾回收机制释放。而原始参数依然保存在 CPU 内存中，从而实现了内存优化的目的。

同时还有一个小知识点：

1. 对于 nn.Module, .cuda(), .cpu() 和 .to(device) 方法都是就地操作，因此可以直接 model.cuda()
2. 而对于 torch.Tensor , nn.Parameter 这些，.to(device), .cpu(), .gpu() 方法本质都是创建一个新的 Tensor，原始 Tensor 不变，因此也必须使用 a = b.cuda()

在试用了一众 “稍后读” 和 “剪藏” 软件后, 仍然找不到满意的软件。

总结了一下针对当前的「网页剪藏」软件，现在自己不满意的几个点：

1 - 快照使用「服务器采集」: cubox, pocket 等

这种方式的缺点就在于，很多内容平台，特别是国内的平台，都需要登录才能访问完整内容。

那么这样的采集方式受限就很大，服务器端采集无法携带用户的认证信息，因此往往只能获取到部分内容或者直接无法访问。

2 - 自带的「网页解析」或者「解析为 Markdown」: obsidian / upnote 等笔记软件的 clipper

网页结构和样式的多样性使得通用解析器很难完美处理所有情况，特别是对于代码块、表格、数学公式等特殊格式，解析质量往往不尽如人意。

3 - 仅能保存 URL 的「稍后读」: raindrop 等

内容的持久性在互联网上并不能得到保证，特别是：

• 一些平台会定期清理历史内容
• 某些文章可能因各种原因被删除或修改
• 网站本身可能关停或改版
• 付费内容可能从免费变为收费

对于一些时刻可能下架的敏感内容，或者经常变动的网站，url 可能过一阵子就看不了了。

我理想中的「网页剪藏」

1. 我希望功能不要过于复杂，例如各种各样的划线标注，笔记，阅读状态，都是我不需要的。
2. 我想让我的保存，查看能够尽可能的简单高效，不要打乱我目前浏览网页的进度 —— 也就是说不要在我保存的时候出现一个大表单让我填写，或者卡住等待插件处理和解析网页。
3. 我希望能永久保存内容，在任何时候我可以看到「我当初看到这个网页的样子」。
4. 我希望做到云存储，不希望作为一大堆散落的附件保存在本地。

于是我搭建了一个联动 SingleFile, dropbox, notion, 和 telegram bot 的 workflow 来满足我的需求。

我搭建的工作流

之所以说是工作流 Workflow，实际上就是将一大堆 API 串起来。

整体实现起来不难，把所有 API 写好，作为一个 notepad 喂给 cursor，基本上 10 分钟就完成了，然后接下来用了几个小时来完善整个流程。

以下是 Demo (youtube):

PS：demo 实际展示了 Telegram 的提示过程 + 服务端日志，实际上对于我而言只需要按一下「cmd + shift + s」 快捷键之后，剩下的一切都是服务端处理了。

PPS：演示的时候 DeepSeek 又卡了，还好加了一个备用的 API。。

简单来说这个工作流如下：

1. 利用 singlefile 保存单页 html 作为快照。
2. 通过 webdav 上传到服务端开始处理。
3. 服务端上传文件到 dropbox 并获取分享链接 (可以直接点击查看快照页面) 。
4. 服务端通过 deepseek / gpt 的 API 自动生成摘要和 tag。
5. 将所有的元数据上传到 Notion Database 进行保存。
6. Telegram 的 bot 全程通知进度，以及报告成功 / 失败的错误日志。

总体来说个人还是挺满意的，最近搞了不少自动化，这个算是折腾比较久的和比较好玩的，于是写出来分享下。

STT 全称 Speech-to-Text，即语音转文本。一般有两种常见的需求：一种是将实时语音转文本的识别（流式处理），一种是将录音文件转文本。本文主要记录后者的一些方案。

1 - 录音转文本的方案

自部署方案

目前最常见的模型是 OpenAI 的 Whisper 模型。

使用起来也非常简单，只需要两步：

1
2
3
4
5

# 安装
pip install openai-whisper

# 使用
whisper --model base --language zh --output-dir ./output ./input.m4a

目前一些其他的「自建」方案基本都是基于 OpenAI 的 whisper 模型: HuggingFace 的 Whisper 模型

这种自部署的优势就是安全，缺点是需要消耗本地算力，如果算力不足会比较慢，其次感觉 Whipser 对于纯英语识别来说比较好，但是对于中英文混杂的环境，效果还是比较差的。

API 方案

用几家大厂的 API 方案, 比如：

• OpenAI 的 Whisper API

目前价格是每分钟 $0.006：https://openai.com/api/pricing/

其实这个价格也不算便宜了，转一个 1 小时左右的文本就要 3 RMB 左右。

• Google 的 STT API

这个更贵，目前价格是每分钟 $0.016：https://cloud.google.com/speech-to-text/pricing

更多的一些厂商:

总之，API的方案确实很方便，但是价格其实都并不便宜。

于是最后我还是将眼光瞄向了国内的一些在线平台。

在线平台

主要试用了科大讯飞的讯飞听见，阿里的通义听悟和字节的飞书妙记。

用起来体验如下:

阿里：通义听悟

Link: https://tingwu.aliyun.com/

阿里通义听悟在中英混合文本识别方面表现最为出色，且提供充足的免费额度（赠送500小时, 除此之外每天签到都可以领取 10 小时）

然后功能方面做的也很好，包括内容摘要，发言人识别，文本替换，AI改写等比较好用的功能。

字节：飞书妙记

Link: https://www.feishu.cn/product/minutes

飞书妙记也还不错，每月提供300分钟免费额度，勉强也还够用。

但是如果额度一旦用完，价格就有点贵了，只能付费升级到「飞书 Plus」来用不限时。

另外界面做的也挺朴素的，功能不像阿里的那么丰富，但是比较简练，作为常用的会议记录的用途也足够了。

科大讯飞: 听见

每月仅提供20分钟免费额度，识别效果也相对一般，充值也很贵，39.8RMB/月。

性价比较低。

2 - MacOS 录音方案

作为录制会议或者演讲等用途，经常有一个需求就是想同时录制 麦克风 + 系统声音.

这里介绍一下我现在用的两种能获得录音音频的方式：

1 - 使用 Screenshot 录屏

录屏的话 MacOS 的 Screeshot（截屏）可以直接做到：

1. cmd + shift + 5 打开录屏，在选项中选择「麦克风」即可。
2. 录制结束后获得一个 .mov 视频文件。
3. 用 QuickTime Player 打开视频文件，在「文件」菜单中选择「导出为音频文件」，即可获得一个 .m4a 音频文件。

2 - 单纯录音

有时候我们不被允许录制屏幕，这时候只能通过单独录音的方式，而 MacOS 自带的 “QuickTime” 录音只能单独录制麦克风声音，这时候就需要用到其他手段。

BlackHole

一种方案是利用 BlackHole，BlackHole 作为一个虚拟音频设备，可以将 macOS 系统的音频输出捕获并重新路由，使其既能被录制软件录下又能通过扬声器播放出来。具体操作可以看：知乎：macOS使用BlackHole录制系统声音的同时输出声音

QuickRecorder

另一种就是通过安装其他应用的方式，一般用的最多的是 obs，但是 obs 太大了，搞起来比较复杂和麻烦。

于是我找到了一个使用起来还不错的很轻量的开源软件「QuickRecorder」：https://github.com/lihaoyun6/QuickRecorder

使用这个软件录制出来会生成一个 .qma 文件

qma 这种文件包格式可以容纳 2个音频文件，以及一个属性文件。

使用 QuickRecorder 内置的 QMA 播放器打开 .qma 可以同步播放系统声音和麦克风声音，并且可以独立调节音量（调节之后，音量属性会被记录在文件信息里，下次打开这个文件还是这套音量配置）。如果不需要分享的话，直接用 qma 格式保存在硬盘上就行了。如果需要发给别人，qma 播放器自带导出功能，可以将两个音频文件按照用户设定的音量比例混缩成一个普通的单轨音频文件 .mp3 / .m4a。ref

我今年从上半年开始就用了一个非常优秀的订阅管理工具 Wallos 来记录自己每个月的开销：

相比去年乱七八糟的 VPS 和各种有用没用的 APP 订阅，今年整体的开销算是精简了不少。

目前一年的费用算下来才 3800+，去年记得光是一年的 VPS 和科学上网订阅就不止这么多了。

目前我的订阅分类一共包含如下几块：

下面单独分享一下对一些服务的感受：

建站 + 下载

自从上次绿云服务器被黑，建站已经懒得折腾了，目前用的就是阿里云的轻量服务器，之前用了一个 3500 代金券券所以算下来 8 年的 VPS 才不到 500 块，算是薅了一下阿里的羊毛。

下载和热备份一直用的 HostHatch 的瑞典大盘鸡，稳定性不错，1C1G1T 一年才 20刀。

工具

Claude Pro

在下决心订阅 Claude Pro 之前，一直用的是 API 和合租面板的方式。

不过最近 OpenAI 的审查越来越严，模型时不时就降智，最关键的问题是还不知道它什么时候就降智了，最后就决定直接订阅 Claude Pro 了。

可能我是 Claude 刚出就注册了，加上 IP 一直很稳定，一个号从一而终用了一年多都没被封，还算幸运。

Claude 的质量是没话说的，Project 功能很给力，美中不足的是不能联网，目前需要联网查询的时候一般我就用 GPT 或者 Perplexity 的免费版代替了。

滴答清单

滴答清单一直是我心目中的 TOP 1 APP，目前已经持续用了 5 年多了。

作为一个 TBD 软件，各方面都很完美，我认为已经做到了极致。

书影音

微信读书一直在用 30 天挑战的方式 5 元续费一个月，还是很划算的，我认为是微信系列目前最良心的应用。

影视部分之前开过 MAX 和 Netflix，后面 NF 又是同户又是低价区封号的搞得很麻烦，就取消了，目前订阅了一个公费服 MisakaF，然后自己用 Google Drive + Emby 搭建了一个。

Spotify 明年不打算订阅了，应该就一直用 youtube music 了，感觉目前 ytm 的推荐做的已经很不错了。

其他

🪜

这个用的就是几个 top ✈️ 之一，一个月 20 多，配合 relay 策略用的自己的落地，感觉比各种转发、优化线路要稳定的多。

说实话自从从 mjj 圈退坑之后，反而在线路方面一直没出过问题，而在自己之前折腾的时候，时间金钱精力花了一堆不说，线路还天天出故障，不是商家跑路就是机器被打，要么就是线路故障、运营商 QOS。现在看来这些时间花的真的毫无必要，不知道为什么那时候一直乐在其中。

域名

两个 top 域名，一个 net 域名，平均下来一个月 15 元左右。

手机卡

一个 29 元的每个月 300 G流量的电信卡（还支持结转，基本每个月从来用不完）。

一个 8 元的联通保号套餐。

吃喝

闲鱼的 KFC 年卡，一个月只要 5 块，主要用来吃 6 折早餐，很划算。

京东 PLUS 会员，一年 60 吧。

其他乱七八糟的今年都没开。

总结

总的来说对自己目前的预算控制还是比较满意的，算是已经精简到最小化了。

明年会继续控制其他方面的支出，但是对 AI 工具这方面一直保持一个开放探索的态度，一个月花 20 刀左右大幅提升生产力，个人觉得还是非常可以接受的。

PS: 目前总结的这些只是订阅制的 APP，一次性开销的 APP 和服务等也买了很多，但是由于没有记录管理所以也懒得去翻了。

2024 总体来说是很闲的一年，也是一个看书和电影电视剧比较多的一年，因此记录以下今年看过的一些好东西。

评价和评分全是主观色彩，并且仅仅代表当时时刻短暂的心情和观点，写这篇博客的内容也仅仅是回顾一下内容，以及自己当时的想法和感受，纯属一乐。

读过的书

这一年基本没读过纸质书，基本所有的书籍阅读都来自「微信读书」，在微信读书上截止到 12 月 24 日一共读了 260 多小时，远超前几年的总和。

决定以自己在 neodb 的评分排出一个 TOP10：

1 - 怦然心动

作者：文德琳·范·德拉安南

译：陈常歌

之前很早的时候因为一些原因没有把电影看完，也记不清是为什么了。

重新一口气看完了整本书，觉得这不像是一个青春爱情故事，更像是一个讲述家庭和亲子关系的故事，看完觉得完全符合 9 分的高分评价。

我也开始在想，有些类型的作品真的书能比电影呈现出太多太多的细节。

2 - 绿毛水怪

王小波

没想到王小波也这么会写别离:

“我回想起来，她绝对温存，绝对可爱，生机勃勃，全无畏惧而且自信。我从她身上感到一种永存的精神，超过平庸生活里的一切。”

“我看了这些话发出一声长嚎，双手乱抓了一阵。我感到脑后一阵冰凉。我坐了很久，天黑下来，又亮起来。我机械地去吃饭，又机械地去干活，机械地回家来。我很孤独，真正的哀痛被我封闭起来了，我什么也不想。直到有一天下午大许推开我们的屋门，把夕阳和他长长的身影投进来。”

"我跪倒下来，用痉挛的手指抓住盒子，抚摸盒子。我在哭吗？没有声也没有泪，只有无穷的惨痛从粗重的喘气里呼出来，无穷无尽。“

3 - 观察的艺术

https://book.douban.com/subject/35807485/

一本值得反复观看的书，真的以很实用的阐述方式，为一成不变的日常人生提供了很多不同的观察角度。

之前也单独为这本书写了一个博客：日常的缝隙 —— 「观察的艺术」阅读笔记

4 - 寂静的巴黎

申赋渔

整本书在描述形形色色的人，不过前半本在描写身边的人，后半本在描述历史上的人，全篇行文透露出一种安静且悲凉的色彩，仿佛在看一部长长的纪录片。

5 - 马斯克传

沃尔特·艾萨克森

很长的一本传记，前前后后读了有两个多月才读完。

艾萨克森的传记写的真的很有水平。

有很多比较高深的概念他都可以用很简单易懂的方式阐述出来，包括在「乔布斯传」中呈现出来的一样。

6 - 强风吹拂

三浦紫苑

非常燃的一本书，还好是 HE 。

文笔非常细腻，尤其是翻译十分到位，有不少句子翻译的特别传神。

唯一美中不足的就是书中的数据提升实在是有点假，不过也可以理解是为提高文学性牺牲了一点真实性了。

7 - 撒哈拉的故事

三毛

“哭, 笑, 爱, 憎, 梦里梦外, 颠颠倒倒”

8 - 鱼不存在

露露·米勒

这本书是前几周听完孟岩的播客后去看的，一开始以为就是一本赞颂人类用坚韧意志对抗混乱的鸡汤书。

读到一半发现不是这样的，这本书在探讨一个非常宏大的概念。

关于宇宙，世界，生命。

关于变化和不变。

「每个人眼中都有一个世界，那个世界就存在于这个世界之中。」

9 - 金色梦乡

伊坂幸太郎

非常多的 callback，铺垫很到位，喜欢这种欲言又止的结尾。

10 - 你当像鸟飞往你的山

塔拉·韦斯特弗

远离那些喜怒无常并充满暴戾的控制欲的人。虽然没有经历过这些事情，但看完这本书算是能理解为什么有很多人接受着变态的家庭暴力却丝毫不反抗。

作者最后的决定非常的完美，那些持续发生的事情也印证了这个决断的正确性。

“从他们以及其他家人那里，我听说了山上正在上演的戏剧——受伤、暴力和来回变换的忠诚。但现在这些对我来说都成了遥远的传闻，他人的馈赠。我不知道分离是否是永久的，不知道是否有一天我将找到一条回家的路，但这种分离给我带来了平静。”

但是翻译总感觉有点怪，例如“我已觉察出我们是如何被别人给予我们的传统所塑造，而这个传统我们有意或无意地忽视了。我开始明白，我们为一种话语发声，这种话语的唯一目的是丧失人性和残酷地对待他人——因为培养这种话语更容易，因为保有权力总是让人感觉在前进。” 文中很多地方出现了这样不明所以的句子，理解起来颇为费劲。

看过的电影 / 纪录片

1 - 蒙古草原，天气晴

“母亲没有找到马，普洁也来不及长大”。

在影片的最后一分钟前我还觉得会是一个不太完美的 happy ending，普洁会如愿完成学业，成为一个翻译，或至少是一个文化人，结果刀来的如此之快。

比起普洁的意外，母亲的死我觉得更加令人感到惋惜，绝望甚至愤怒，严重骨折＋内出血的情况下居然能拖半个月最后还被医院拒之门外，这得忍受多么窒息的痛苦，不仅对母亲本人还是家人而言。

整体影片的拍摄手法异常的简单，就是一个人举着一个像素很低，没有防抖的相机，拍出任何一个人都可以拍出的画面，但就这种真实更把这超出三界之外的意境表达的淋漓尽致。

2 - 盲井

复杂的人性，质朴的黑暗。

3 - 大佛普拉斯

非常文艺的一部片子，虽然主线剧情比较薄弱，但是镜头，旁白和一些场景设计都非常给力, 金句频出。

这部电影的英文叫作「The Great Buddha」，Buddha 还是 Puta，即是有背景的人表面和内心的善与恶。

「我想现在虽然是太空时代，人类早就可以坐太空船去月球，但永远无法探索别人内心的宇宙。」

4 - 冰血暴 (1996)

也许是剧版想要表达的东西太多太深邃，我其实更喜欢电影精炼简洁的内核。

5 - 阳光普照

整个节奏和「大佛普拉斯」非常相似，特别喜欢这种叙事节奏，同时表达的内核也完全不输大佛普拉斯。

6 - 飞驰人生2

如果没看过「飞驰人生」我会给他3分, 另外的一分来自于情怀分, 过年就应该看这种情怀爽片。

7 - 网络谜踪2

第一次看这种桌面电影，真的很过瘾啊，相当有趣的拍摄手法，同时情节也相对来说很有张力。

8 - 疤面煞星

演技爆棚，say hello to my little friend！！

9 - 在西伯利亚森林中

整个片子的节奏说不出来的舒服，冰天雪地，旷野寂静。

故事也比较喜欢，自由永远是相对的。

很喜欢那句「你逃的比我还远」。

10 - 因果报应

由于提前看到了热评说是有反转的剧，所以强忍着前大半集的不适看玩的，电影的前 2/3 都是十分的"粗制滥造"，感觉角色完全没交代清楚，然后剧情也十分混乱。

最后的10分钟剧情强行把这部剧从不及格扳回到中高分，假如前半部分认真看了，即使没看懂（像我就完全分不清青年和老年的主角，片中的印度人长得实在太像了），最后也能理清楚是怎么一回事。

但是只能说前半部分可以加强的点太多了，即使是一部靠反转升华的剧，前面也可以交代的更清楚一些，又也许导演的意图就是让观众「前半部分云里雾里呢」。

看过的电视剧 / 综艺

1 - 黑镜 第一、二、三季

第一季

想象力太丰富了，没有直接的恐怖元素但是令人看到脊背发凉。

三集每一集单拿出来都是近乎满分的存在。有点当时看爱死机的感觉了，不过黑镜更偏现实主义一些，并且更长的篇幅也带来了更多的深度情节，特别喜欢。

第二季

本季第二集真的让人产生一种生理性的不适，但是也足以证明了它构思的成功，估计我这种不适还要持续好几天。。

第一集和第三集就感觉立意没有第一季那几集刚看的时候那种新奇感了，比如第一集关于未来科技和赛博爱人的讨论不如S01E03的 grain 带来的那种震撼，而第三集的 waldo 又不如 S01E01 的 pig fucker 和 S01E02 的男主沉沦的全过程那么讽刺。

当然，只是个人的一些比较（由于两季几乎就是一起看完的，所以每一集印象都很深刻），总体来说第二季还是非常优秀。

第三季

第三季变成了 6 集，但整体感觉总体的质量和前两季还是有些差距，不过还是有几集特别喜欢的。

2 - 喜剧之王·单口季 (2024)

付航真的太强了，每一次发挥都如此出色。而且是在已经完美的表演上不断拔高。
其他演员也很出色，听了一百多小时刘仁铖的不开玩笑的播客，第一次见到真人。还很喜欢于祥宇和黑灯。
总之是一个比预期高出不少的节目。

3 - 去他*的世界 第二季 (2019)

用了一下午＋一晚上看完了整个第二季，今年目前为止最佳的剧，如果说第一季是纯粹的离经叛道和义无反顾的走向悲剧，那么第二季则多了许多温情和精神拉扯；

英国佬的黑色幽默确实就是一种变态美学，如果生活变得不受控制，除了说「Oh fuck I’m going to die」还能做什么呢。

另外，和第一季同样优秀的BGM。

4 - 无耻之徒 (3,4,5,8季)

PS：由于看了一下打分，无耻之徒实在占比太多，每一季都太优秀了，于是把自己评分最高的 4 季整在一起。

评价就是：「三百六十五条线，条条线炸」。

心目中目前的 top1 美剧。

5 - 我的大叔

一直很讨厌看韩剧和日剧，因为总感觉演员和剧本过于刻意且造作，这部剧可以说是追完用时最长的一部剧了，前前后后大概看了4个多月吧，不过20集不到而已，最后还是给了8分的高分。

剧本非常细腻，但其中还是有不少我不得不跳过的扭捏且无法理解的剧本，但是每当我想要弃坑的时候总会出现一些打动我的情节，总体来说可以算是我第一部认认真真看完的日韩剧。

6 - 小谢尔顿 (3,5,6季)

电子榨菜类型的剧，这部剧前半部分和后半部分不太一样。

前半部分完全是看逗比和小演员们卖萌，而后半部分尤其是第五季开始，剧中的冲突开始多了起来，从家庭喜剧变成了家庭剧，但是整体同样优秀，每个人的人物形象都变得更加立体了。

7 - 我的三体 第四季

大制作，除了人物还是方块已经没什么mc的影子了。

太短了，原来就拍到执剑就完了，还以为会把第三部拍完呢。

8 - 亿万图谋

很不错的一部纪实类电影, 最后的 15 min 增加了些许悲凉, 小人物要想和大公司掰手腕真的太难了, 同时这两位主角让我想到了乔布斯和沃兹, 是不是每个成功(做出成功产品)的黑客身边都有一位懂技术的商业高手?

PS: 影片中的所有事件都在简单搜了搜, 在维基百科上查到了原型, 记录在: https://telegra.ph/2024-02-13-The-Billion-Dollar-Code-02-13

9 - 双城之战 第二季

如果整部剧结束在第六集伊莎开枪的那一刻, 那么10分我愿意给11分。

但是最后三集我只能说是一坨, 不知道编剧在想什么。

10 - 繁花

阳春白雪

Anthropic (Claude) 在 11 月 25 日推出了一个协议： MCP (Model Context Protocol)。^[1]

协议的目的是解决各类无法联网的 ChatBot 的信息孤岛问题。

比如 ChatGPT 在 ChatGPT Search 的加持下，可以做到搜索最新的网页信息并分析：

但是 Claude 在内的许多模型目前还不支持：

除此之外，许多时候我们希望访问一些自定义的数据源，比如本地的数据库等。

这些需求目前只能通过自己写代码 + 用 GPT 的 API 来进行操作。

MCP 的出现实际上就是用来解决这个问题：作为一个中间层，提供一个统一的协议和 SDK 来对接各类数据源。

目前 Claude 在 https://modelcontextprotocol.io/introduction 已经提供了完整开源的 python SDK 和 TypeScript SDK

这个玩意也是我最近琢磨 Claude Desktop APP 的配置的时候才发现的，目前支持 MCP 的 Client 在 这里 可以看到:

如果你开通了 Claude Pro 并且有 Claude Desktop，可以通过官网的这个 DEMO：https://modelcontextprotocol.io/quickstart 来实现一个获取天气和天气警报的联网查询功能。

实践：实现一个 Arxiv 论文搜索工具

我自己也通过简单修改了一下 quickstart ^[4]，利用 python sdk 来实现了一个符合自己需求的 Arxiv 论文获取工具。

完整的代码在：https://github.com/Lincest/mcp-papersearch

简单介绍一下具体的使用方式:

1 - 安装环境

uv 是一个 rust 编写的 python 包管理器，和 virtualenv 这些差不多，由于官网用的是 uv，于是就沿用一下。

1

curl -LsSf https://astral.sh/uv/install.sh | sh

clone 仓库：

1
2
3

git clone https://github.com/Lincest/mcp-papersearch.git

cd mcp-papersearch

安装依赖：

1

uv sync

2 - 配置 Claude

需要编辑 ~/Library/Application\ Support/Claude/claude_desktop_config.json

（windows路径在：$env:AppData\Claude\claude_desktop_config.json)

1

vim ~/Library/Application\ Support/Claude/claude_desktop_config.json

内容为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

{
  "globalShortcut": "",
  "mcpServers": {
        "papersearch": {
            "command": "/Users/XXXX/.local/bin/uv", # 改成你的 uv 路径
            "args": [
                "--directory",
                "/Users/XXX/code/mcp-papersearch", # 改成你的 clone 仓库的路径
                "run",
                "papersearch"
            ]
        }
    }
}

把上面的路径按注释内容改一下，删除注释，然后重新启动 Claude Desktop：

这时候会发现右下角出现了个锤子🔨：

就说明运行成功了。

3 - 测试

case 01: 搜索近期的论文

问 Claude 一个简单的问题，比如

搜索一下最近3天的 MoE Inference 相关论文

这时候会弹出一个窗口，就表示 Claude 识别到了应该调用我们的 papersearch 来搜索。

点击 Allow 后，发现他很智能的调用了两次，一次在3天内没找到后，又扩展范围到了30天来搜索：

case 02: 搜索指定的论文

比如我们要搜索 https://arxiv.org/abs/2308.12066 这篇论文，标题是「Pre-gated MoE: An Algorithm-System Co-Design for Fast and Scalable Mixture-of-Expert Inference」

提问：

搜索和总结 https://arxiv.org/abs/2308.12066

总结

目前的 case 写的还很潦草，大部分就是直接让 claude 自己生成了然后简单改一改。

以后用来接入一些 DB 估计会比较好用。

更多有趣的官方 demo

• https://modelcontextprotocol.io/examples#reference-implementations

这里提供了更多有趣的官方推荐的 MCP Tools 和用法，几个个人觉得比较有意思的：

1. 实现和 Github 的交互： https://github.com/modelcontextprotocol/servers/tree/main/src/github
2. 实现和 Obsidian 的交互：https://github.com/calclavia/mcp-obsidian
3. 获取 Web 内容：https://github.com/modelcontextprotocol/servers/tree/main/src/fetch

通过 Fetch 获取 web 信息

通过官方提供的 fetch, 不需要下载任何代码，仅仅需要配置:

1
2
3
4
5
6
7
8

"mcpServers": {
      "fetch": {
          "command": "uvx",
          "args": [
              "mcp-server-fetch"
          ]
      }
  }

就可以实现 web search 的功能了，例如查看北京天气：

Reference

Mac 上一直用的一台 G 口 Oracle 作为出口的代理来上网, 结果发现每次用 Oracle 的出口进行 pip 安装包时都特别慢, 速度大概 100KBps 不到, 换其他的出口就一点问题都没有, 之前尝试过换 DNS 也没啥用.

也测试过到 pypi.org 这个源的 ICMP, 也没发现什么问题.

结果今天仔细研究了一下, 发现 pip 的安装逻辑大概是这样的:

• pip 首先访问 pypi.org 获取包的元数据
• 然后会被重定向到 files.pythonhosted.org 这个 CDN 服务器下载实际的包文件
• files.pythonhosted.org 是 PyPI 的文件托管服务,用于存储和分发包文件

然后我尝试在 oracle 机器上 ping 一下 pythonhosted.org, 结果发现 ipv6 居然没有 CDN, 延迟高达 160MS:

而众所周知一个双栈机器 (同时启用 IPv4 协议栈和 IPv6 协议栈的机器) 默认是 ipv6 优先的, 可能是为了推广 IPV6 之类的考虑吧…

当然这种优先级是可以通过修改配置文件改变的, 本文就讲讲今天研究的两种常见方式

如何手动配置 IPV4 / IPV6 优先

1 - gai.conf

基本上所有 Linux 发行版都使用 /etc/gai.conf 来管理 getaddrinfo 的行为, 而所有需要域名解析的地方都需要用到 getaddrinfo , 因此修改这个配置文件就可以从根本上解决系统的 ipv4 / ipv6 优先级问题.

简而言之, 直接编辑 /etc/gai.conf, 取消注释或者添加这一行:

1

precedence ::ffff:0:0/96  100

即可设置成 ipv4 优先.

或者直接一行命令 sed 修改:

1

sed -i 's/#precedence ::ffff:0:0\/96  100/precedence ::ffff:0:0\/96  100/' /etc/gai.conf

1.1 - 这行配置做了什么

• precedence: 表示是在配置优先级
• 100: 数字越大, 优先级越高
• ::ffff:0:0/96: 这是一个特殊的 IPv6 地址前缀, 用于表示 IPv4-mapped IPv6 地址空间, 简而言之, 就是告诉系统, 当遇到同时支持 IPv4 和 IPv6 的地址时, IPV4 地址的优先级

例子:

1
2

precedence ::ffff:0:0/96  100    # IPv4-mapped IPv6 addresses
precedence ::/0            10     # 所有 IPv6 addresses

在这个配置中：

1. 当一个域名同时有 IPv4 和 IPv6 记录时
2. IPv4 地址会被映射成 IPv4-mapped IPv6 address（即 ::ffff:0:0/96 格式）
3. 由于其优先级 100 大于纯 IPv6 地址的优先级 10
4. 系统会优先使用 IPv4 地址进行连接

2 - 禁用 ipv6

出于某些原因我们可能完全不想要 ipv6, 这时可以直接彻底禁用网卡的 ipv6, 方式:

1
2
3
4
5
6
7
8
9
10

cat >> /etc/sysctl.conf << EOF
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1
EOF

来修改 /etc/sysctl.conf

然后通过 sysctl -p 来重新加载配置文件, 这时 ipv6 就已经被彻底禁用. (还原的话直接删除这几行或者把0, 1反过来就ok)

今天逛 linux.do 论坛的时候看到这样一个问题:

小李在纸上写了一个四位数A,把A的个位数字移到首位,得到另一个四位数 B,最后把A和B加起来得到和数C,并且C也是一个四位数。

已知A的各位数字之和是20,C的百位和十位数学分别是0和4。

那么C代表的四位数是?

正确答案应该是 8041.

刚好这几天 GPT 降智严重, 所以一直在对比 Claude, ChatGPT 和 Gemini Pro, 就用这个问题问了大概 7, 8 次各类模型, 看看都是如何回答的.

OpenAI GPT-4o

官网版本的 gpt4o

PS: 用的 IP 是 Oracle 的 IP, 实测 difficulty 值是 4 位数 (ref: https://linux.do/t/topic/261968)

问了 10 次左右, 大约 7 次可以通过正确的写出 python code 并运行得到正确结果.

另外的三次就是类似这样的无 code 回复, 答案也大概率就是错的.

平台反代的 GPT-4o

这个平台是之前一直合租的平台, 应该就是通过自己写了个镜像站来用多个 Pro 账号反代官网, 特征也很明显, 就是会用固定 IP 大量访问 GPT, 这一类的反代镜像站目前被 openai 限制的很严重, 我用的这个也因此停运了, 刚好在最后几天再通过这个问题测试一下.

1. 第一次, 直接没有通过程序求解, 并得出了错误的答案

2. 又尝试了几次, 勉强在写错五次程序后给出了正确结果

Claude 3.5 sonnet

同样的问题问了五次以上的 Claude 3.5 sonnet, 均通过正确的 JS 代码给出了答案和分析, 并且相比于 chatgpt, 还证明了答案的唯一性.

Gemini 1.5 和 Gemini-exp-1206

虽然 在 Chatbot Arena 上坐拥 rank1, 但是 Gemini 在这个问题的表现居然是三个模型里最烂的:

1. 直接问原始问题, 无论是否加 code execution 的选项, Gemini 系均不会给出代码和执行求解, 而是通过大量的文本分析试图找到答案, 并且 Gemini 对于中文的支持挺糟糕的, 如果不在 Prompt 中明确指定, 即使问题是中文也很有可能输出英文解答:

以下是模型的原始输出: (Gemini 1.5 pro 和 exp-1206 基本类似)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134

Here's how we can solve this problem step-by-step:

Understanding the Problem

We have a four-digit number, A.

Moving the last digit of A to the front creates a new four-digit number, B.

The sum of A and B is a four-digit number, C.

The sum of the digits in A is 20.

The hundreds digit of C is 0, and the tens digit of C is 4.

Let's use variables:

Let the digits of A be represented as a, b, c, and d, where a is the thousands digit, b is the hundreds digit, c is the tens digit, and d is the units digit.

So, A = 1000a + 100b + 10*c + d

And B = 1000d + 100a + 10*b + c

Formulating Equations

Sum of digits of A: a + b + c + d = 20

Structure of C: C = 1000*_ + 100*0 + 10*4 + _ (We don't know the thousands and units digits of C yet)

A + B = C:
(1000*a + 100*b + 10*c + d) + (1000*d + 100*a + 10*b + c) = C

Analyzing the Sum (A + B = C)

When we add A and B, let's consider the possible carry-overs:

Units column: d + c results in the units digit of C. There might be a carry-over to the tens column.

Tens column: c + b plus any carry-over from the units column results in 4 (the tens digit of C). There might be a carry-over to the hundreds column.

Hundreds column: b + a plus any carry-over from the tens column results in 0 (the hundreds digit of C). This means there must be a carry-over of 1 to the thousands column (since b + a cannot be negative).

Thousands column: a + d plus the carry-over of 1 from the hundreds column results in the thousands digit of C.

Solving the Equations

Hundreds column: Since b + a plus a carry-over results in 0, and we know there's a carry-over of 1 to the thousands column, we have:
b + a + 1 (carry-over) = 10
Therefore, a + b = 9

Tens column: We know c + b plus a possible carry-over from the units column results in 4. Let's consider two cases:

Case 1: No carry-over from the units column:
c + b = 4
Since a + b = 9, and a + b + c + d = 20, then d = 7.
But if d = 7, then in the units column, d + c (7 + c) would need to result in a number greater than or equal to 10 to have a carry-over. This would make c at least 3, and c + b would be greater than 4, contradicting our assumption of no carry-over. Therefore, this case is not possible.

Case 2: Carry-over of 1 from the units column:
c + b + 1 = 4
Therefore, c + b = 3

From equations a + b = 9 and c + b = 3, and knowing a + b + c + d = 20, we can deduce:
a = 9-b, c = 3-b and 9 + 3 - b + d = 20, then b + d = 8

Units column: Since there's a carry-over of 1 to the tens column, d + c must be greater than or equal to 10. Substituting c = 3-b, we get:
d + 3 - b >= 10
d - b >= 7

Combining d - b >= 7 and d + b = 8, we find that the only possible values are:
d = 8, b = 0

With d = 8 and b = 0, we can find the other values:
a = 9, c = 3

Calculating C:
A = 9038
B = 8903
C = A + B = 17941

However, the problem states that C is a four-digit number. This means our initial assumption that A is a four-digit number was incorrect. Let's adjust our approach.

Revised Approach: A as a Three-Digit Number

Let's assume A is a three-digit number (abc) and B becomes a four-digit number (bca) when the units digit is moved to the front.

A = 100a + 10b + c

B = 1000c + 100a + 10b

A + B = C

a + b + c = 20

C = 1000*_ + 100*0 + 10*4 + _

Analyzing the Sum (A + B = C) - Revised

Units column: c + b results in the units digit of C. There might be a carry-over.

Tens column: b + a plus any carry-over results in 4. There might be a carry-over.

Hundreds column: a + c plus any carry-over results in 0. There must be a carry-over of 1.

Thousands column: The carry-over of 1 is the thousands digit of C.

Solving the Equations - Revised

Hundreds column: a + c + 1 (carry-over) = 10, so a + c = 9.

Tens column:

Case 1: No carry-over from the units column: a + b = 4. But since a + b + c = 20, this would mean c = 16, which is not possible.

Case 2: Carry-over of 1 from the units column: a + b + 1 = 4, so a + b = 3.

Combining a + b = 3 and a + c = 9 with a + b + c = 20, we get:
3 + c = 20
Therefore c = 17, still not possible.

The issue is that if C is a 4 digit number, then A cannot be a 3 digit number, because the only way to have a carry of 1 into the thousands column is if A is a 4 digit number as well.

Let's try one more approach: a, b, c, d must not all be single digits

We know a+b = 9, c+b=3, and a+b+c+d=20. If b=0, then a=9, c=3, and d=8, which gives us C as 17941. This means that at least one of a, b, c, d must be greater than 9.

Since b is in both a+b=9 and c+b=3, we know that if b is a two-digit number, these equations cannot both be true. Therefore, b must be a single digit.

If c is a two digit number, then the addition of c+b in the tens column would need to be 4, but there is also a carry-over of 1 from the units column. This means that c+b=13, and if c=10, b=3, a=-1, d=8. This also doesn't work.

If d is a two-digit number, then when added to c, there must be a carry-over of 1. If d=10, then 10+c >= 10, which is true for any single-digit c. However, we know c=3-b, and if c is negative, then a must be greater than 9 to compensate, which we have already tested.

If c=0, then b=3, a=6, d=11. This gives us 6300+11, 360+11, and 6300+360+22 = 6682.

Answer
C represents the number 6682.

2. 在 Prompt 中加入「通过运行程序给出答案」后, 回答精简了很多, 并且也可以通过写出 python 程序并执行找到答案:

但是, 多问几次后, 发现并不会每次都成功:

总结

就这道题的测试结果而言:

1. Claude 3.5 sonnet 仍然是目前输出最快, 最稳定, 最准确的 coding 和 math 类模型.
2. OpenAI GPT 很明显有能力做到和 Claude 类似, 但是估计是对 IP 的要求过高, 导致输出很不稳定, 而且对于同一个 IP, 甚至会出现随机降智.
3. Gemini 虽然目前排名很高, 但是感觉还是名不副实…

并且令人感到愤怒的是，商家还对此做了隐瞒，不愿意承认是被入侵并泄露数据，而把责任归咎于是 RAID 出现故障。

经过这次事件，我再也不想去相信中小厂的公有云服务了。

强烈建议，在任何 VPS 部署服务时，做好 数据加密存储，并不在服务器上存储任何明文的 token 或密码。

以及，及时的备份数据。

事件经过

1 - 系统宕机和绿云工单回复

• 2024-10-21 16:24

我发现一台在线时长将近一年的绿云 10 周年 VPS 自动重启了。

当时没太在意，以为就是例行维护。

随后我发现我的一些需要写入数据库的服务变得不可用，比如 seafile 和 vaultwarden。

登录上服务器发现文件系统全部变成了 read-only。

于是我发了一个工单：

发工单后，我发现服务器直接宕机了，并且通过 SolusVM 面板无法进行重启。

• 2024-10-21 18:16

绿云客服回复，说是遇到了罕见的 RAID 故障。

当时我认为，这种便宜的机器也许就是 RAID0 吧，如果修不好可能数据就没了。

不过好在做了备份。

• 2024-10-22 17:29

经过了一天的时间，发邮件询问情况。

绿云客服回复，RAID 无法恢复，只能 rebuild。

补偿是 1 年时间，或者按照购入价格全额退款。

2 - 商家的隐瞒

• 2024-10-23 lowendtalk 网友发帖，披露 VPS 数据被入侵。

原贴地址：https://lowendtalk.com/discussion/198766/my-greencloud-vps-got-ransomwared-the-entire-mothership/p1

该网友进入了救援模式 (Rescue Mode)^[1]后，可以看到所有的文件都被修改成了 xxx@cock.li

我在进行相同操作的时候，确实也发现了，所有的文件都被 改名并加密，直接 google 搜索 junglesec，可以发现这是一个黑客组织，主要以勒索攻击（ransomware）而闻名。^[2]

究竟发生了什么

搜索一下关键字 junglesec, VPS, IPMI，就大概可以看懂是数据是如何被入侵的了。

IPMI（智能平台管理接口） 是一种集成在服务器主板上的系统管理固件，这种固件允许管理员在操作系统无法访问时仍能进行远程管理，例如重启系统、查看系统状态等。因此，IPMI 提供了对系统的深层次访问权限。

本次服务器攻击的步骤

1. 通过 IPMI 登录获取访问权限：

   • 攻击者首先寻找启用了 IPMI 的设备，特别是那些使用默认密码且未充分加固的 IPMI 接口。

   • 一旦攻击者登录成功，就可以通过 IPMI 远程控制服务器，即使系统的操作系统崩溃也能进行操作。

2. 重启系统进入单用户模式：

   • 攻击者利用 IPMI 的远程访问功能，将目标服务器重启到单用户模式（Single User Mode）。在这个模式下，系统只加载必要的服务，并为管理员提供 root 权限，而无需输入密码。
   • 攻击者在单用户模式下可以绕过所有用户账户的认证机制，直接获得系统的最高权限。

3. 下载并编译加密程序：

   • 获得 root 权限后，攻击者在系统中下载并编译一个名为 ccrypt 的加密程序，攻击者利用它来加密系统中的所有文件。

4. 发送勒索邮件

这并不是一个比较新鲜的攻击方式了，可以看到非常多的相关案例^[3][4]

我们应该做什么

在事件发生之后，我选择了退款 + 重新迁移数据到阿里云。

同时，由于之前过于相信商家 + 懒惰，很多备份的脚本和一些其他的定时任务，比如 vps 之间的 ssh 鉴权，比如许多上传和下载的 api key 和 token，我都明文保存在了 VPS 上。

因此，我重置了一些重要平台比如 google drive, onedrive, github, gitlab 的 auth token，同时清理了所有 vps 上的 authorized_keys。

还好目前部署的东西大多是玩具，这是一次很好的教训，之前用云服务的时候其实一直忽略了数据安全和隐私，觉得许多事情离我太遥远，然而当事情真正发生到自己身上时，再后悔就晚了。

一个很容易想到但是许多人压根不 care 的事情是，只要你的文件是明文存储的，那么 vps 厂商就可以读到你的明文文件。^[5]

因此，当 vps 宿主机出现被入侵时，你的文件也可以被其他人明文读取。

所以，最好的防护措施是：

1. 尽量只用大厂服务。
2. 敏感信息不上云，上云就做好端到端加密和及时的备份。
3. 不要在 vps 的一些 cronjob 中明文配置一些密码和token。
4. 真正重要的基础服务还是不要自建，或者采用更鲁棒的方式比如做 k3s 之类的集群，否则关键时候出问题，即使有数据备份恢复起来还是很麻烦。

相关概念

1 - rescue mode

救援模式（Rescue Mode）是虚拟专用服务器（VPS）提供的一种应急维护功能，允许用户在无法正常启动系统或发生重大问题时，进入一个最小化的操作环境进行排障和修复。它通常是一个轻量级的 Linux 环境，不依赖原有的操作系统，类似于单机版的安全模式或Live CD。

2 - junglesec

JungleSec 是一个黑客组织，主要以勒索攻击（ransomware）而闻名。该组织的活动在网络安全圈中引起了广泛关注，其主要手段是针对企业或个人的系统进行未授权访问，并通过加密文件或劫持网络基础设施实施勒索。

主要的攻击方式：

1. 勒索软件攻击：
   JungleSec 通常在侵入目标系统后，将关键文件加密，并要求受害者支付赎金（通常以比特币等加密货币支付），否则威胁删除或公开敏感数据。
2. 攻击向量：
   他们利用系统中的已知漏洞、弱密码、以及未充分配置的管理接口（如 IPMI，BMC）等来侵入系统。IPMI（Intelligent Platform Management Interface）是他们的主要目标之一，这是一种用于远程管理服务器的接口，如果未安全配置，就容易被攻击者利用。
3. 赎金要求：
   JungleSec 的攻击一般要求受害者支付一定金额的比特币或其他加密货币。如果不支付，受害者的数据将无法解密。

ref

本文是对这篇 博客 的一些补充和 python 代码实现

前缀和 (PrefixSum) 和扫描 (Scan)

在并行计算中，前缀和（prefix sum）被称为“扫描”（scan）主要是因为这个操作的本质涉及对一个序列中的元素进行累积或递推计算，类似于扫描或遍历序列。

其特点是，输出的每一个值有前缀依赖性，就是说每个输出依赖前面的所有输入。

1
2
3
4
5

# input:
[a0, a1, a2, a3, ..., an]

# output:
[a0, (a0+a1), (a0+a1+a2), ..., (a0+a1+a2+...+an)]

Blelloch 并行扫描算法

Blelloch 扫描算法（Blelloch scan algorithm）是一种高效并行实现前缀和（prefix sum）操作的算法，通常用于大规模并行计算中。

这个算法采用了一种基于二叉树的并行计算模式, 将传统的 O(n) 求前缀和的复杂度减少为 O(log(n))。

Blelloch 扫描算法由两个主要步骤组成：

1. 向上（Upsweep）阶段：
   • 该阶段是通过一棵隐含的二叉树自底向上构建累积和。
   • 在此过程中，每一个节点汇聚子节点的值。
   • 经过 log(n) 次迭代，最终根节点处存储了整个数组的总和。
2. 向下（Downsweep）阶段：
   • 在这个阶段，算法从树的根节点开始，自顶向下计算前缀和，同时传播累积和到子节点。
   • 在每一层中，左子节点继承父节点的值，而右子节点加上父节点的值。

具体可以参考这个图:

这里用一个 python 代码来展示每一步的具体过程:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

def blelloch_scan(arr):
    arr = list(arr)
    n = len(arr)

    print("Initial array:", arr)

    step = 1
    print("\nUpsweep Phase:")
    while step < n:
        for i in range(0, n, 2 * step):
            if i + step < n:
                arr[i + 2 * step - 1] += arr[i + step - 1]
        print(f"After step size {step}, array: {arr}")
        step *= 2

    arr[-1] = 0
    print("\nSetting root to 0, array:", arr)

    step = n // 2
    print("\nDownsweep Phase:")
    while step > 0:
        for i in range(0, n, 2 * step):
            if i + step < n:
                temp = arr[i + step - 1]
                arr[i + step - 1] = arr[i + 2 * step - 1]
                arr[i + 2 * step - 1] += temp
        print(f"After step size {step}, array: {arr}")
        step //= 2

    return arr

input_array = [1,2,0,1,2,0,1,2]
arr = blelloch_scan(input_array)
prefix_sum_array = [input_array[i] + arr[i] for i in range(len(input_array))]

print(f"\nFinal PrefixSum array: {prefix_sum_array}")

输出:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Initial array: [1, 2, 0, 1, 2, 0, 1, 2]

Upsweep Phase:
After step size 1, array: [1, 3, 0, 1, 2, 2, 1, 3]
After step size 2, array: [1, 3, 0, 4, 2, 2, 1, 5]
After step size 4, array: [1, 3, 0, 4, 2, 2, 1, 9]

Setting root to 0, array: [1, 3, 0, 4, 2, 2, 1, 0]

Downsweep Phase:
After step size 4, array: [1, 3, 0, 0, 2, 2, 1, 4]
After step size 2, array: [1, 0, 0, 3, 2, 4, 1, 6]
After step size 1, array: [0, 1, 3, 3, 4, 6, 6, 7]

Final PrefixSum array: [1, 3, 3, 4, 6, 6, 7, 9]

ref

• CUDA-扫描算法 (blog): https://ashburnlee.github.io/2020/02/20/CUDA-扫描算法/
• wikipedia - prefixsum: https://en.wikipedia.org/wiki/Prefix_sum

感觉方向键里进了什么东西, 然后就直接把 mac 键盘的方向键翘起来清理了一下内部, 然后就发现装不回去了…

由于之前也有过拆 mac 键盘的经验, 拆过很多次正方形按键 (字母, 数字键), 都是翘起来, 然后按回去就行了, 于是这次没有多想就直接把方向键也这么操作了, 然后发现怎么都按不回去.

最后参考了 b 站的这个视频: Macbook 剪刀键盘方向键键帽安装 才发现事情没有那么简单.

剪刀脚的方向键和 mac 其他的正方形的数字按键不同, 这玩意拆了键帽不把剪刀脚支架一起拆下来, 强行是 压不回去的.

由于大力按压, 键帽的左边的卡扣已经压断了, 只能上 PDD 新买一个键帽. (这玩意一个就是几十块.)

操作

最后记录一下 mac 上方向键的结构和安装步骤, 图片来源: 小红书

注意 Step7 这一步特别难操作, 建议用一个镊子或者别针之类的东西, 卡住支架的右侧, 然后把左边挂上去, 总之 切忌用蛮力!

总结

以后拆任何电子产品都得小心了, 尤其是那种做工比较细节的, 可能相似的部件设计却完全不同, 然后不提前看看结构大力出奇迹就悲剧了.

个人觉得这是一本值得反复观看的书，真的以很实用的阐述方式，为一成不变的日常人生提供了很多不同的观察角度。

许多时候，总是感觉一件事就这么发生了，然后产生了一些情绪影响，却没有去仔细想过，究竟是什么东西让我产生了这种感觉。这本书的一个很大的价值就是，用了一系列非常细节的情景描述 / 方法论，说明了一个简单的道理：

视觉、声音、气味、体感、时间、温觉，人的感觉远远不止五感，但一切都是值得仔细体验和观察的。

这本书其实给了我一些对于「应该或者不应该」做什么的指示，很多时候我觉得我的脑回路不被人理解，比如在某个地方干着与这个地方气质不相干的事情，但是这本书肯定了我的一些行为，告诉我「其实这么做也是另一种思路和角度」。

一些书摘

由于文笔有限，在此记录一些书中个人觉得很有价值和思考的文字。

生命中，你总是有各种各样逃避的借口，种种责任纷至沓来，让你无比疲惫，这些都会限制你人生的宽度。但人生的全部意义就在于，尽自己所能从外面的世界获取最多的东西。世间之事，全在用心。你的注意力就是你的生命力。它让你和他人产生联结，让你感到渴望。保持渴望，保持同他人的联结，在平凡的日常中寻找自己感兴趣的事，留意别人忽视的东西——这些技巧一般人很难做好，但却十分重要。

睡觉前，她会聚精会神地听，努力分辨出每一种噪声：远处的狗叫声，空调的嗡嗡声，一辆车驶过的声音。

有一次，我和妻子在一所当代艺术博物馆闲逛时，走进了一个小厅，里面除了两个大木箱，什么也没有。这两个箱子令我困惑，因为不确定里面是装满了等待拆箱的艺术品，还是它们本身就是艺术品。

如果你想看见过去没有留意到的东西，向上看，便是一个很棒的选择。对初学者来说，你只需要不时地把视线从手机上移开，抬起头向上看。朝着不在正前方、却在上方的事物，抬起你的眼睛。

你不必到世界的另一头，也能找到新的地方进行探索。翻翻地图，想想哪里是你完全不熟悉的地方，然后给自己安排一次愉快的漫步。

你不太可能发现世界历史遗迹和名胜古迹。你想要寻找、吸收和享受的，是更普通、更日常的细节——一个有创意的商店标志、一盘偏离正轨的棋局、一座随意而迷人的教堂、一辆停在路边的古董车、一个碰巧骑着独轮车的路人。

“步行、骑自行车或开车——走不同的路线，去往一个相同的目的地。”他说，“如果你每天都以同样的方式通勤，你就不会注意到任何事物。事实上，到达目的地几分钟后，你就已经对整个旅程毫无印象了。进入这种僵尸般的通勤状态，实际上是在偷走你自己的时间。而新的路线能使旅行更加活跃和有趣。

一些碎碎念

这些日子特别喜欢看 Links^[3] 的视频，最近看过的印象很深的一个视频就是冰岛徒步^[4]的这一段：

在这里 links 和小螃蟹遇到了一个徒步的法国小哥。

特别喜欢这一段对这个小哥的描述，想到了书中的一段话：

并不是在否认拍照和自拍这些行为，而是有些时候，也许我们真的过于追逐打卡式的游览和带着目的任务，而因此不断丧失观察力和专注力。

“世界是一座博物馆，”他说，“你就是讲解员。”

reference

人的心境也真是够滑稽的了。因为它会无可救药地被鸡毛蒜皮的日常生活所左右，却也能在风的感触与初夏气息的撩拨下心花怒放。人心是那么深奥，却也浅薄得不可思议。人之所以能活下去，也一定有这份浅薄的功劳吧。

——「旅行之木」

北京到秦皇岛是非常划算的出行计划之一，绿皮车票只要不到 50 元，现在正值淡季，各个旅游景点也都没有什么人，除了晚上的天气很冷之外，北戴河各方面都是相当完美。

总结一下旅行日志 + 在本文中详细把自己的行程安排记录下来。

准备工作

• 门票：可以用「北戴河全域旅游」小程序，基本上可以直接在里面购买所有景区的门票，而且比单独在景区公众号 / 线下购买要便宜，可以直接刷码进入，不需要身份证。
• 车票：建议买到北戴河站的火车，如果没有可以买秦皇岛站的，不过市区过来比较远（公交1h左右）。但是两个车站都有直达景区的公交车，淡季不怕没座位。
• 景区出行：北戴河区没有共享单车，有专门的景区自行车，基本每个景点门口都有。不过还是强烈建议租一个电动车，大约50元 / 天，可以骑100多km，秦皇岛比想象中的小很多，实测北戴河转三四圈 + 骑到海港区（市区）一个来回都绰绰有余。

行程安排概要

由于只有两天，我的计划就是直接逛完北戴河区 + 海港区，此外山海关太远，阿那亚太贵，就没有去。

• 第一天：联峰山 (15:00) - 老虎石 (17:00) - 环海公路 (18:00) - 秦皇小巷 (19:00)
• 第二天：鸽子窝 (5:00) - 碧螺塔 (9:00) - 海滨骑车 (10:30) - 秦皇小巷 (12:00) - 西港花园 (14:00) - 金梦海湾 (16:30)

1 - 联峰山

下午两点到的酒店，先是出发去老虎石转了一圈，感觉没有什么特别值得逛几个小时的景点，于是就去了附近的联峰山打算登高望远一下。

联峰山有好几个山峰，其中望海亭可以看到北戴河区全景 + 大海，爬上山顶大概只需要 20min 左右。

2 - 老虎石

老虎石是一个绝佳的欣赏日落的地方，可以提前查好当天的日落时间，然后提前 30min 左右爬上石头等着。

从整个太阳落下去到天呈现蓝粉色大概就 10min 左右的时间。

不知道为什么博客的图片压缩好像有问题，HDR 图片居然被压缩出这种环形波纹了。。

3 - 环海公路

这条路就是老虎石旁边 50 m 处的一个公路，实际能看到海的路段没有很长，就几百米的样子。

不过蓝调时刻这个路段真的很美。

4 - 夜市：秦皇小巷

夜市在刘庄和秦皇小巷纠结了一会，看刘庄夜市风评一般，就直接骑着小电驴来海港区的秦皇小巷了 (30min)，个人体验相当好，物价不算太高（和北京比起来），味道也很好。

于是第二天的午饭 + 晚饭也都是在秦皇小巷吃的，把几个比较火的小店都打卡了一遍。

5 - 鸽子窝

早上 5 点就起来去鸽子窝看日出了，由于酒店就定在鸽子窝旁边，走过去相当方便，同时鸽子窝这块也是距离海港区最近的，比较建议酒店定在这。

5 点的北戴河气温只有 8 度，我提前看了天气预报，带了一件毛衣过来，还是很冷。

老虎石看日落有一点远处的山和房子挡着，相比之下鸽子窝就是纯纯的正对一望无际的大海。

日出的速度比日落更快，能肉眼感觉到太阳一下就钻出来的感觉，大概全程也就几十秒的时间太阳就冒出来了。

6 - 碧螺塔

这里是北戴河一个人造味最浓的景区，也诞生了不少的网红打卡点，即使是淡季每个打卡点排队的人都很多。

晚上这里有演出，还有很多卖夜宵和啤酒的店，想必是相当热闹，不过白天都没开门。

票价也很贵，白天观光票就要 50，晚上好像要 180，不过如果要拍人像的话，这里确实挺值得来的。(在这里不拍人比拍人更难~)

7 - 西港花园

西港花园（开埠地）是秦皇岛老港口，后面废弃以后改造成了旅游景点，门票也是免费的。

个人非常喜欢这里的景色，相比碧螺塔那种人造景观，感觉这里的工业风更加真实且浪漫。

从大码头到海誓塔那一段路真的非常漂亮，左边是大海和许多航行的帆船、货轮，右边可以看到秦皇岛的整个城区海岸。

确实，这张图一点毛病没有，许多折腾软件尤其是笔记软件的朋友总会自嘲到：「笔记软件比笔记还多」，和各种器材党一样，许多人也将之视为一种爱好而不是真正有什么生产力需求。

我自诩不是那么的器材党吧，只是最近在折腾「日记」这个应用的时候遇到了不小的阻碍，而刚好日记又和笔记 app 存在大量的交集，于是又重新试了许许多多的日记 + 笔记软件，最终谨以此文总结一下这段时间的折腾。

Dayone：昂贵的价格，坑爹的同步

Dayone 可以说是目前来说综合评价最高的「日记」软件了，具体可以看这篇文章^[1] 中对各种「日记 app 」的对比。

我个人当时也是被其全平台的特质所吸引，由于我的手机是 android，而日常用的笔记本是 macos，之前一直在使用的「日记」方式是滴答清单，采用的是类似这样^[2] 的方式：

这样的方式有个问题就是当一天想法太多的时候总是存在着「一篇文章记不下」的情况，而且「N年日记」的方式虽然可以看到「那年今日」，但是如果想要更加丰富的面板，还是略逊了一筹。

并且滴答清单的「任务」管理的模式，在记录日记的时候如果不小心将该任务标记为完成，其就会复制当前的内容并创立下一个循环的任务，如果后续想有补充就还得找到明年今天的那个任务来追加内容。

总而言之，在持续该模式将近两年后，我还是决定找一个更加专业一些的日记软件。

于是眼光就瞄准了 Dayone。

除了全平台的优秀支持，Dayone 还提供了一些特色功能，例如自动记录「地点」，「天气」。这些顿时让每天的记录充满了烟火气。

于是我迫不及待的订阅了付费版。

但随着进一步的深度使用，两个月后我又放弃了 Dayone，理由如下：

1. 没有认真对待安卓平台，安卓和macos的同步坑的不行，我在实际使用中经常会出现一个 case：在安卓上写了一些内容，然后macos打开，发现该内容是白的（没有同步过来），但又由于 macos 打开了该笔记，导致 macos 的同步把安卓的同步覆盖了，这样辛苦写的内容就没有了。这也是我退订该 app 的核心原因。
2. web 版本会出现图片等信息丢失的情况，总之还是同步问题。
3. 高昂的售价 + 不可买断，国区一年要 200 RMB+，仅仅只用于日记这个价格确实太奢侈了，虽然土耳其区可以便宜很多，但是 google，steam 这些公司都这么打压土区了，apple 的低价区又能持续多久呢。

于是我想找一个能替代 Dayone 的，全平台同步的东西，目标也从一开始的日记软件逐渐放开到了一切便签/笔记软件。

在此之前，我主力的笔记软件一直是 obsidian + typora，功能已经调教到了近乎完美，但是就是移动端同步太费劲，对于「手机简单记录」这个功能的支持实在不够。

然后从弃用 Dayone 开始，我直接开始了长期的日记 + 便签 + 笔记软件的探索，以下记录我对这期间的一些软件的评价。

Google Keep：难过的中文搜索

Google Keep 作为一个便签软件，有着大厂背书加上不错的 UI 设计，个人一开始入手的时候还是挺喜欢的，但是用了没两天，问题又逐渐暴露出来：

1. 移动端不支持中文搜索（这个问题我看 play 上很早就有人提了，但是 Google 一直没管，完全想不通，作为一个顶级搜索引擎大厂，居然连自家的笔记软件都不做支持）。

2. Google 对于非核心应用的「黑历史」：一开始我也是从 为什么我不用Google Keep？ 开始看的，后续也逐渐了解到，原来 Google 都抛弃了那么多看起来「热门」但盈利不够的的项目：

   • 那些被 Google 放弃的项目: https://killedbygoogle.com/

   同样作为一个非盈利项目，难以不怀疑 Google 什么时候就会脑子一热就给停了。

3. 没有 Markdown 等一些基本编辑模式的支持，就仅仅只是纯文本 + 图片。

Journey & Diarium：能不能好好做 mac 端

这俩货都是自诩「全平台」的日记应用，单看移动端（尤其是 Android）确实不错，能平替甚至秒杀 dayone，但是当我下载这俩的 macos 桌面端时，我都被丑到不忍直视。。。

一些国产应用 - 一本日记，卡片日记等

在最初使用一本日记时，我还花 30 多买了高级会员，结果同上的，macos / web 版本设计的一塌糊涂，甚至连上传图片等功能都没有，其他例如天气 / 地点也是就给了个 input field 要你自己填。

其他的国产「日记」应用也是大差不差，要么就是没有 web / PC端，要么就是做的一坨狗屎，总之没有找到一个全平台都做的很好的东西。

一些目前用起来比较满意的 APP

上述都是一些吐槽的话，接下来说一下比较满意的 APP 和自己目前的 笔记/日记 workflow。

Notion: 好用的模板

Notion + 日记模板的方式可以达到比较好的「日记」效果，一个是 Notion 的数据库 + 自定义视图可以实现多种查看方式，再一个是 Notion 的多端同步和 app 已经相当好用了。

由于 Notion 的数据库实在太强大了，这里就不过多介绍如何设计，以免把思路局限住了。就说几个我觉得非常有用的针对「日记」的视图设计：

1 - 那年今日和那月今日效果

可以通过

1

formatDate((prop("日期")),"DD")==formatDate(now(),"DD")

的方式实现（假设「日期」是创建时期），那年今日改成 MM-DD 即可。

2 - 自动创建每日日记

直接创建一个模板然后配置「重复」即可。

Upnote：完美的「备忘录」平替

如果说 Google Keep 是一个蹩脚的 Apple 备忘录平替，那么 upnote^[5] 就是一个比较完美的备忘录平替，其不仅支持多平台 (ios + macos + windows + android + linux)，而且经实测不论是同步速度，还是对 Markdown 的完美支持，对比起备忘录都是有过之而无不及，强烈建议体验。

另外，upnote 采用本地优先的方式，打开速度非常快，并且可以 Markdown 导出想要的文档（包括图片，附件等）。

Obsidian：PC 端上的完美产品

只能用「近乎完美」来形容的笔记软件，需要花一定时间适应插件生态，一但接受了就爽的不行。

唯一的缺点就在于「多端同步」，并且我由于个人在读论文这些，大量的 pdf 塞进去以后 vault 变得非常大，同步到手机并不是什么好选择。

Typora：好用的 Markdown 编辑器

Typora 是大一的时候我接触 Markdown 第一次使用的产品，算是我接触到的最早的 Markdown 编辑器，一直到现在，我还是认为他是 Markdown 编辑的最佳产品。

可惜笔记不只有编辑，还有更多的刚需功能如分类、查找、链接，于是到现在 Typora 一般被我用来写博客、周报等一次性的文章。

reference

Follow 是 DIYgod 大佬开发的一个 「Next generation information browser」(下一代信息浏览器)，值得一提的是，这位大佬也是 RSSHUB 的作者。

这两个月刷 Twitter 的时候一直看到不断有人分享相关的产品体验，今天借着内测规模的扩大，总算拿到了邀请码可以好好体验这款产品。

不得不说确实对得起之前看到的对它的吹捧。

一开始我以为 Follow 就不过是类似 Inoreader，freshrss，miniflux 这一类的 rss 阅读聚合器罢了，但是实际体验下来发现其相比上述 APP，更出色的地方在于对「一切皆可 RSS」和「社交」这两个属性的出色集成。

下面就记录一些我觉得 Follow 非常出彩的地方。

1 - 简洁高效的搜索功能

直接在 Discover 页面即可通过搜索关键词来找到对应的 rss 订阅源，同时可以看到对应的 Follow 人数。

由于和 rsshub 的无缝集成，节约了很多 rss 转换和搜索的时间。

2 - 多样的信息表达形式

Follow 支持了对文章、社交post、图片、视频、音频等多种不同主题的展现形式。

例如你可以通过视频的方式订阅 bilibili：

通过图片的方式订阅沙雕墙 Telegram Channel：

通过音频的方式订阅播客：

而且无论是视频，音频，图片，文章，其内置的阅读器的 UI 都设计的相当之漂亮。

3 - 社交体验

虽然现在内测用户群还不多，但其展现出的社交属性已经令人眼前一亮。

你可以在 Follow 中认领 (claim) 你的内容，只需要修改 rss 加一行 description 即可。

然后其还有内置的虚拟货币，可以用来打赏（投币？）你喜欢的内容：

总结

除了上面几个亮点，感觉整个应用设计也特别在线，比如对快捷键的绑定，一些配置项等。

感觉是一个可玩性特别高的应用，虽然仅仅是内测 v0.0.1-alpha 版本就感觉已经完成度非常之高了，期待后续的进一步体验~

Reference

• https://github.com/RSSNext/Follow
• https://x.com/DIYgod
• https://sspai.com/post/91283

直到前几天想开发一些自己的 AI 工具，看了一下 Raycast Extension 的 AI API 文档，感觉用起来相当简单，配合 Raycast 不错的生态，于是就大手一挥开了1个月的 PRO。

然后花了几个小时深度体验了一下，总体来说感觉非常不错，于是写一篇博客记录一下。

Raycast Pro 有什么

以下是截至目前 (2024 年 8 月 22 日)，Raycast Pro 所有的全部功能。

售价是 8 美元一个月（年付） / 10美元一个月（月付），学生优惠可以做到五折，申请学生优惠也比较简单，有 edu 邮箱就行，实测申请秒发。

同时需要注意的是，如果需要一些高级语言模型 (GPT4, Claude 3 opus)，需要额外再加 8 美元。不过现在自从 GPT 4o-mini 免费后，感觉这个模型应对一些日常需求也够用，我就不再舍得多花 8 美元了。目前 pro 本身支持的模型如下：

感觉按 10 美元算，个人对这些功能评价如下：

• Raycast AI：价值 8 美元，与插件生态结合的相当完美。
• Cloud Sync：价值 1 美元，对于同时使用多台 mac 设备的人来说，能同步配置还是不错的，尤其是自定义 hotkey 特别多的情况下，不过感觉对大多数人不是刚需，毕竟没有人有那么多闲工夫同时用两台 mac，如果是更换设备的话直接用免费的 settings export / import 就够用了。(并且 Clipboard History 和自己本地的脚本 Script Command 无法同步)。
• Custom Themes：没啥用的感觉，就换个颜色，我是觉得默认的黑色就很帅。
• Unlimited Clipboard History：价值 1 美元吧（主要是其他东西感觉更无价值），这个有点强行收费的意思，毕竟占用的还是本地的存储，还没法同步。
• Scheduled Exports：可以定时导出配置，配置的导入导出本身是免费的，只是单纯加了个定时。
• Translator：Bob 更好用。
• Window Management：基本 rectangle 可以平替，功能没啥区别，rectangle 还可以直接拖拽调整。

所以总体来说，感觉 Raycast Pro 除了 AI 功能，其他感觉都是可有可无的，并没有对我来说必须付费的吸引力，但是换言之也说明了，Raycast 本体还是很良心的，免费版除了 AI 已经做到了基本完全体。

Raycast AI 的使用场景

1 - 与 placeholder 的完美结合

raycast 有个好处就是其随处可以呼出的方便，配合一些 placeholder 可以实现很不错的 AI Command：

例如这是一个官方自带的 「网站总结」 AI Command，最后一个「你的回答都应该使用中文」是我加的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

You are a skilled website summarizer. You write a summary of the provided webpage that includes all key details that you would share with a friend. Analyze the given website content and create a summary using the following format:
"""
## <concise title that captures the main theme of the website>

<one to two sentence summary that encapsulates the key information information>

### Key Takeaways

- <EXACTLY three bullet points with the key takeaways, keep the bullet points as short as possible>
"""

Strictly follow these rules:
- ALWAYS maintain the author's perspective and point of view throughout the summary
- Prioritize the most important, interesting, and unique facts for the reader
- Only include information explicitly stated in the website content
- Keep the summary concise, but ensure that all key information is included
- 你的回答都应该使用中文

Here's the website content:
{browser-tab}

Summary:

直接在浏览当前网页时打开 raycast，就可以总结当前网页的内容，而脚本中的 {browser-tab} 就是 raycast 自带的 placeholder，除了这个还有常用的：

• {selection}: 当前选中的内容
• {clipboard}: 当前剪切板的内容

具体更多的可以参考 https://manual.raycast.com/dynamic-placeholders

将一个 AI Command 绑定到某个快捷键，就可以实现一键总结/生成/翻译/转换等诸多常用功能。

2 - 自定义 Extension / Command 脚本

Raycast 本身的插件机制非常丰富，配置 API 文档 可以开发出许多贴合自己需求的好用的脚本。

这里以我自己昨天花 30min 写的一个 Extension 为例，该 Extension 的作用就是自动将剪切板内容总结并保存到 Telegram 我自己的收藏夹中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

import { AI, showHUD, Clipboard } from "@raycast/api";
import TelegramBot from 'node-telegram-bot-api';

const bot = new TelegramBot(token, { polling: false });
const prompt = "你的prompt"

export default async function command() {
  try {
    const { text, file, html } = await Clipboard.read();
    console.log(`get from clipboard: text = ${text} \n file = ${file} \n html = ${html}`);
    await showHUD("🖊️ Processing..");
    const answer = await AI.ask(prompt + text, {
      // model: AI.Model["OpenAI_GPT4o-mini"],
      model: AI.Model["OpenAI_GPT4o-mini"],
    });
    await bot.sendMessage(chatId, answer, {
      parse_mode: "Markdown"
    });
    await showHUD("✅ Done");
  } catch (error) {
    console.error(error);
    await showHUD("Failed.");
  }
}

非常的方便。

Reference

• https://developers.raycast.com/api-reference/ai
• https://github.com/raycast/script-commands
• https://manual.raycast.com/dynamic-placeholders

最近放假回家，准备秋招之余有一些闲功夫，又正好在帮家里更新一些软硬件设备，就把自己目前搭建 Emby 的技术栈做一些简单的记录和配置罗列。

1 - Emby 的 Docker 配置

我的所有自建基本能放在 docker-compose 中的就尽量用 docker compose 管理，emby 也不例外。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

version: "3"
services:
  emby:
    image: emby/embyserver:latest
    container_name: embyserver
    restart: always
    user: root
    volumes:
      - ./config:/config # Configuration directory
      - /theater/movie:/mnt/share1 # Media directory
      - /theater/tv:/mnt/share2 # Media directory
    ports:
      - 8096:8096 # HTTP port
      - 8920:8920 # HTTPS port

其中需要备份的目录就是 ./config 目录，而 /theater/movie 和 /theater/tv 用于挂载自己的影视盘，这里我选用的是 rclone 挂载 Google Drive / One Drive，具体配置和方案会在下面说明。

光是 Emby 本身的搭建不是很吃 CPU 和内存，不过建议至少 2C2G 的 VPS 起步吧，我自己搭建的这个占用情况（运行了半年没重启和停机后的状态）：

1
2

# docker stats --no-stream | grep emby
384f61138e22   embyserver                      0.03%     1.412GiB / 9.716GiB   14.53%    4.31GB / 498GB    2.74GB / 5.23GB   82

也就是大概需要 1.4G 左右的 MEM，仅供参考。

关于 Emby 服务器启动后的配置

这里不对具体的每一项配置做多的说明，只说个比较重要的：由于 VPS 没有 GPU 并且 CPU 一般很拉胯, 记得把服务端解码全关了。

2 - Rclone 挂载 Google Drive

要说国外挂载 Emby 最合适的网盘，目前比较合适的方案就是用 Google Drive 或者 One Drive，其他网盘的读写实测都受到了不同程度的限制，并且稳定性肯定也不如大厂（当然，也有可能还有很多更好更实惠的方案我没有探索出来）。

• One Drive 可以上闲鱼购买合租的 Office365 套餐，大概 20 左右 1 年，有 1T 的空间，感觉也是挺划算的。
• Google Drive 可以直接开土区的套餐，2T 大概在 100 RMB 左右（不过目前好像土区受到限制了，不知道未来是否会受影响）。

Google Drive 的 Plan

目前我用的 Plan 是土耳其 2TB 的套餐，目前资费是 500 土耳其里拉，换算成人民币也就是大概 100 块左右每年的样子。

Rclone 的配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

version: "3"
services:
  rclone:
    image: mumiehub/rclone-mount
    container_name: rclone
    user: root
    network_mode: host
    restart: always
    cap_add:
      - SYS_ADMIN
    devices:
      - /dev/fuse
    security_opt:
      - apparmor:unconfined
    volumes:
      - /root/.config/rclone:/root/.config/rclone
      - /theater:/mnt/mediaefs:shared
    environment:
      - RemotePath=gdtry:/
      - ConfigDir=/root/.config/rclone
      - ConfigName=rclone.conf
      - MountCommands=--use-mmap --umask 000 --default-permissions --no-check-certificate --allow-other --allow-non-empty --vfs-cache-mode full --buffer-size 256M --vfs-read-ahead 512M --vfs-read-chunk-size 32M --vfs-read-chunk-size-limit off --vfs-cache-max-size 30G --low-level-retries 200

rclone 的配置我也是用的 docker-compose，主要是为了方便日志管理和自动重启。

然后直接将宿主机的 rclone config 也就是 ~/.config/rclone 挂载到容器内部，这样就不需要容器内部再重新登录了。

这里的 Environment 部分添加了一些乱七八糟的 MountCommands 参数，也是网上搜索了一波后配的，自我感觉比较重要的是 --vfs-cache-mode full --vfs-cache-max-size 30G ，可以根据 VPS 的硬盘大小尽量扩大这个值，文件缓存到本地了自然就快了~。

3 - 反代服务器的配置

我的 emby 服务器本身是找了个大流量高性能的 US VPS (5C10G)，然后实际上一般这种性能的美西服务器都不会配备一个好的线路，这时候就需要进行一波反代。

反代的线路如何选择就各种各样了，我本身是为了方便家里观看，实际上如果是自己看的话完全可以用代理连接，就不用再套一层反代了。

反代的配置我也写的很简单，就是单纯用 caddy 代理一层 https，实测也有不错的效果。

1
2
3
4
5

https://<反代域名> {
  tls {$EMAIL}
  encode gzip zstd
  reverse_proxy <emby-ip>:8096
}

4 - PT 下载和上传

这部分就是涉及到如何从网上找资源，以及上传到 Google Drive。

这一部分内容只是我自己的极为简单的配置，仅仅为了满足我自己追剧的需要，不涉及刷 PT 这一系列的骚操作。

qbittorrent 配置

简单说一下我的 qbittorrent 的配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

version: "3"
services:
  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    network_mode: host
    environment:
      - PUID=0
      - PGID=0
      - TZ=Etc/UTC
      - WEBUI_PORT=8080
    volumes:
      - ./config:/config
      - ./downloads:/downloads
      - /resources:/resources
    restart: unless-stopped

上传到 Google Drive 的 Shell Script

我用写了个简单的 script 用于在 qbit 下载结束后快速将资源上传到 Google Drive 对应的目录，这里也记录一下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

uptv () {
local source_path="$1"
local destination="<google drive 目录>"
local filename=$(basename "$source_path")
echo "upload tv: $filename"
if [ -d "$source_path" ]
then
destination_path="$destination/$filename"
else
destination_path="$destination/"
fi
echo "source: $source_path --> destination: $destination_path"
rclone copy "$source_path" "$destination_path" -Pv
}

QB 自动删除脚本

一般在上传到 Google Drive 后，不能马上删除种子和文件。

需要在满足 PT 站的保种规则一段时间后，就可以删除种子了，我使用的是 autoremove-torrents 来做到自动清除，由于这个工具本身对于 qbittorrent 4.5.4+ 具有一些兼容性问题，我 fork 了一个并且把我的配置也记录在了其中：https://github.com/Lincest/autoremove-torrents/tree/master

安装：

1

cd && git clone https://github.com/lincest/autoremove-torrents.git && cd autoremove-torrents && python3 setup.py install

配置文件:

PS: 这个配置文件的主要是用来适配北洋园的规则，可以根据自己的需求自助修改。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

my_task:
  client: qbittorrent
  host: http://127.0.0.1:8080
  username: 
  password: 
  strategies:
    my_strategy:
      remove: ' 
        (size < 10 and seeding_time > 86400) or 
        (size > 10 and size < 20 and seeding_time > 172800) or 
        (size > 20 and size < 30 and seeding_time > 259200) or 
        (size > 30 and size < 40 and seeding_time > 345600) or 
        (size > 40 and size < 50 and seeding_time > 432000) or 
        seeding_time > 604800 or 
        ratio > 10 '
  delete_data: true

cronjob 配置:

1

*/15 * * * * /usr/local/bin/autoremove-torrents --conf=<配置目录>/autoremove-config.yml --log=/root/logs

5 - Emby 的客户端

整体可以参考 Misakaf 的 Wiki 来下载各个平台的安卓客户端，个人体验下来比较好用的：

• MacOS / IOS: infuse 和 vidhub
• Windows: 小秘的客户端, TG Channel
• Android: 小秘的客户端和 Yamby

这个学期老爸用了 5 年还是 6 年的笔记本终于不堪重负了，于是这个暑假想办法给家里配一台新电脑。

在 v2ex 提了一个问题：

• https://www.v2ex.com/t/1059438

之所以不再买笔记本而是选择 NUC / 迷你主机，是考虑到本身笔记本的性价比较低，以及我想利用一下之前笔记本的可重用配件比如内存条和SSD，而且手上有闲置出来的蓝牙鼠标和键盘，家里又有之前放假回去买的显示器；刚好都给利用上，还能节省一笔不小的开销，体验我个人感觉也会比笔记本好上很多。

由于家里父母的需求基本就是：看剧 + 少许 office + 浏览网页，思来想去看到零刻新出的 EQ13，感觉还是挺不错的，功耗很小、足够静音，以及自带电源，而且刚好 DDR4 和 M2 的 SSD 和手上的配对，准系统也只要不到 1000 RMB，于是直接果断下单。

到手体验

到手后第一感觉就是这货体积比我预想的还要小，就半个巴掌大：

拆开来看内部做的也挺精致的，而且还送一个磁吸的螺丝刀，基本两三分钟就把 SSD 和内存装上了：

接口

这台机器主要包含的接口就如下所示：

其中值得一提的是，虽然是双网口，不过每个都是 1 Gbps 而不是 2.5 Gbps的。

不过日常用倒是绰绰有余了。

装机过程

整个装机过程非常省心，因为他自带了一个系统安装盘（win11专业版），并且会帮你把所有驱动自动安装好，基本就是开箱即用的状态。

关于 win11 激活

本来打算直接在闲鱼上 10块钱 买一个激活码的，结果简单搜索一番后发现 github 直接有开源的激活脚本，而且使用起来相当方便：

• https://github.com/massgravel/Microsoft-Activation-Scripts

直接 powershell 运行：

1

irm https://get.activated.win | iex

即可完成 win11 的永久激活。

软件安装

由于自己的需求是给老爸看电影，所以除了office，爱奇艺，微信这些，就额外仅仅安装了如下几个软件：

emby

emby 参考 misakaf 的 doc 安装了 emby 的 windows 客户端：

之前给家里用的也是 emby，因为他们经常会看一些美剧，简单提一句目前我 emby 的搭建方案就是：

• GIA 反代 -> 美国 emby server -> 2TB Google Drive

虽然方案比较痤，但是几个人看个 4K 还是不在话下的。

rustdesk

• 官网：https://rustdesk.com/

据说 mini 主机问题可能会比较多，总而言之装个 rustdesk 以防万一，服务器自建在了阿里云香港，实测用起来很流畅~

ZeroTier

• 官网：https://www.zerotier.com/download/

顺手把 zerotier 的组网也弄好了，作用当然也是远程调试，算是 rustdesk 的 fallback 方案吧。

总结

晚上自己下了个 steam 玩了几个小时的 FTK，完全没有听到任何风扇声音，感觉日常这种影音和冲浪需求完全可以胜任了，感觉自己最后选了 N200 而不是 AMD 的 U 也是非常正确的一个选择。

整体来说成本不超过 1k 可以获得这种体验，个人还是相当满意的（前提是后续不会出什么幺蛾子问题）。

obsidian 已经用了快 2 年了, 现在笔记越来越臃肿, 今天花了几小时的时间好好的整理一下, 并记录一下整理的流程

1 - 将图片等附件全部移动到根目录下

最开始的时候考虑到笔记和其他 markdown 软件的兼容性，用的是 相对路径 + 每个文件夹建一个 /assets 来存放附件 的方案，但是现在看来，这一年我用其他编辑器打开 obsidian vault 进行编辑/查看的场景几乎为 0，反而每个 assets 在 tree 的显示下显得相当碍事 (a 开头还排在第一个)，因此直接全部更换为 简短路径 + 根目录创建一个附件文件夹的方式。

通过这样的方式，将附件全权交给 obsidian 管理。

2 - 清理未被引用的图片

安装这个插件: Clear Unused Images 即可

3 - 清理不再使用的 Folder

我这里采用的方式是:

1. 创建一个新的 Vault 专门存放需要归档的 folder
2. 将当前 assets 全部移动到新 vault
3. 用 Clear Unused Images 插件清理无用的附件

今天晚上回来闲着没事干，顺带给自己半年前开发来自己用的应用加了一个 history 的 feature，顺便在 blog 里记录一下。

这个项目的由来大概是我之前一直在寻找一个好用方便的、能在多平台分享文本的工具，而各个 pastebin 又没法支持一些简单的 markdown 编辑，并且感觉分享起来还是太麻烦了，于是当时看到 note.ms 这个应用感觉眼前一亮，就去搜了搜它的开源实现：minimalist-web-notepad。

当时 fork 下来添加了几个 feature，之后自己记录一些简单的备忘，需要多平台快速传播的文本，以及一些 markdown 编辑和代码分享等场景就直接用这个工具完成了，感觉个人还是挺满意的。

• Github: https://github.com/Lincest/web-note
• 体验地址: https://mmmm.tech

整体外观

Feature

基于 github workflow 的自动镜像构建

做了一个 github workflow，可以直接打包成一个镜像然后发布在 ghcr，直接通过 docker-compose.yml 进行部署即可：

1
2
3
4
5
6
7
8
9
10

version: "3"
services:
  web-note:
    image: ghcr.io/lincest/web-note:latest
    container_name: web-note
    restart: always
    ports:
     - "80:80"
    volumes:
     - ./data:/var/www/html/_tmp

然后文档都会以一个个纯文本的形式保存在 ./data 目录下, 比如 https://mmmm.tech/123 那么就会生成一个 ./data/123 的文件

简单的 markdown render

一些效果展示:

键盘流快捷键

基于个人编辑习惯弄了一些快捷键，比如：复制 Link，打开历史记录，保存（自动保存的间隔大概在1s左右，设置这个是为了缓解自己和一些人的 cmd/ctrl + s 综合征），markdown <-> 纯文本转换等。

同时也在页面的下方加了一些带有 emoji 点击的 button，目的是方便在微信分享这种自带 webview 没有 url 框场景下的使用：

mod：在 macOS 上是 command，在 Windows/Linux 上是 ctrl

• https://github.com/Lincest/web-note/wiki

CLI

可以利用 curl <url> 直接读取纯文本, 或者用 curl --data "xx" <url>上传文本, 例子:

背景: 实验室有一台 8 卡的服务器在学校管理的机房里面，机器无法连校园网，但是可以和校园网内其他服务器互联。

本文简单记录一下如何让这台服务器通过 Proxy 连接到另一台实验室的内网服务器，并进行上网的方式。

本文不对原理做过多阐述，仅仅是贴几个配置。

服务端 (可以联网)

搭建 Proxy Server

可以通过各种手段搭建 Proxy Server，我这里直接用 docker 简单弄了个 clash，并用 yacd 当面板，config:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

version: '3'

services:
  clash:
    image: dreamacro/clash
    container_name: clash
    volumes:
      - ./config.yaml:/root/.config/clash/config.yaml
      - ./ui:/ui # dashboard volume
    ports:
      - "7890:7890"
      - "9090:9090"
    restart: unless-stopped
    network_mode: bridge
  yacd:
    image: haishanh/yacd
    container_name: yacd
    ports:
      - "18080:80"
    restart: unless-stopped
    network_mode: bridge

至于 config.yaml 怎么配，那自然是不能在这里展开了。

客户端 (无法联网)

1 - shell proxy

1
2
3
4
5
6

export http_proxy="http://<proxy-ip>:7890"
export https_proxy=$http_proxy
export no_proxy="localhost,127.0.0.0/8,10.0.0.0/8" 
export HTTP_PROXY=$http_proxy
export HTTPS_PROXY=$https_proxy
export NO_PROXY=$no_proxy

将这个放在 ~/.bashrc / ~/.zshrc 等启动配置里即可，这个属于基操

2 - sudo proxy

上面的 shell proxy 作用域只有当前登录用户的 shell, 如果用 sudo apt install 等操作就没法走代理了，因此需要：

1

sudo visudo 

然后加上下面一行配置，表示将当前 shell 的这些环境变量传递到 sudo 中：

1

Defaults env_keep += "http_proxy https_proxy no_proxy HTTP_PROXY HTTPS_PROXY NO_PROXY" 

3 - systemd proxy (docker)

上面的配置无法让 docker pull 走代理，原因在 这篇博客: docker pull 卡住(代理问题) 的解决方案 也详细说过。

需要做的工作：

1
2

sudo mkdir -p /etc/systemd/system/docker.service.d 
sudo vim /etc/systemd/system/docker.service.d/proxy.conf 

1
2
3
4

[Service] 
Environment="HTTP_PROXY=http://<proxy-ip>:7890/" 
Environment="HTTPS_PROXY=http://<proxy-ip>:7890/" 
Environment="NO_PROXY=localhost,127.0.0.1"

最后重启docker：

1
2

sudo systemctl daemon-reload
sudo systemctl restart docker

4 - ssh proxyjump

上面的代理解决不了 ssh 的问题，因此对于 openssh 7.3 以下，可以：

1

vim ~/.ssh/config

然后配置类似的 ProxyCommand 方案:

1
2
3
4
5
6
7
8
9
10

Host proxyserver
  HostName xxx
  Port 22
  User xxx

Host target
  HostName xxx
  Port 22
  User xxx
  ProxyCommand ssh -W %h:%p proxyserver

如果是 openssh 7.3 以上, 直接:

1
2
3
4
5
6
7
8
9
10

Host proxyserver
  HostName xxx
  Port 22
  User xxx

Host target
  HostName xxx
  Port 22
  User xxx
  ProxyJump proxyserver

即可

本文介绍的内容主要涉及 OpenTelemetry^[1] 的 Instrumentation 概念，以及如何将已有的代码接入 OpenTelemetry 以获得可观测性。

1 - OpenTelemetry Instrumentation Startup

如果你想把你的一个项目接入 OpenTelemetry，肯定要接触一个概念：”Instrumentation”，这是一个少有的我感觉没什么准确的一个中文词汇能表达出的意思，OpenTelemetry 将其翻译成「仪表化」，但我感觉仍然不太恰当。

这个词实际上表达的是：

向应用程序中注入跟踪和监控代码的过程，目的是收集有关应用程序运行时性能和行为的监控数据 ^[2]

OpenTelemetry 对 Instrumentation 主要提供了两种方案：

• 一种是手动配置的方案，也叫 Manual Instrumentation，该方案需要侵入式的手动更改代码，同样的提供的可配置项也更多。
• 一种是自动配置的方案，也叫 Auto Instrumentation / Zero Code Instrumentation (doc)，该方案可以无须侵入性的修改代码，而是自动进行代码插桩和注入，实现方式根据语言而异，例如：
  • 在 Java 上利用 Java Agent 字节码修改技术 (https://github.com/open-telemetry/opentelemetry-java-instrumentation)
  • 在 Go 中利用 eBPF 技术 (https://github.com/open-telemetry/opentelemetry-go-instrumentation)
  • 在 .Net 中利用 monkey-patching 技术 (https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation)
  • 更多的 Auto Instrumentation 技术可以参考: https://github.com/orgs/open-telemetry/repositories?q=-instrumentation

2 - Java Agent

下文都以 Java 为例，介绍 Otel 如何利用 Java Agent 机制实现 Auto Instrumentation。该部分主要参考官网文档：Doc: Java Agent

本章首先介绍 Java Agent 机制。

2.1 - 什么是 Java Agent

Java代理是一种特殊类型的类，通过使用Java Instrumentation API ，它可以拦截运行在JVM上的应用程序，修改它们的字节码。 (注意：区别于 Otel Instrumentation，虽然用的是一个词，表达的也都是「代码注入」这个概念）

Java代理并不是一项新技术，相反，它们从Java 5开始就存在了。但是即使过了这么长时间，还是有许多开发者对这个概念鲜有接触。

通过 Java Agent，可以轻松实现如下几类应用场景：

• IDE 的调试功能，例如 Eclipse、IntelliJ IDEA；
• 热部署功能，例如 JRebel、XRebel、spring-loaded；
• 各种线上诊断工具，例如 Btrace、Greys，国内阿里的 Arthas；
• 各种性能分析工具，例如 Visual VM、JConsole 等；
• 全链路性能检测工具，例如 OpenTelemetry、Skywalking、Pinpoint 等。

2.2 - Java Agent 的运行机制

Java Agent 主要可以通过两种方式启动：Premain Agent 和 Agentmain，分别在 JVM 启动前和启动后加载 Agent，达到的都是动态修改字节码的效果：

• Premain Agent

Java Agent 在 Java 程序运行前：在Main方法执行之前，通过一个叫 premain方法来执行。

启动时需要在目标程序的启动参数中添加 -javaagent参数，Java Agent 内部通过注册 ClassFileTransformer ，这个转化器在 Java 程序 Main方法前加了一层拦截器。在类加载之前，完成对字节码修改。

1

java -javaagent:/path/to/<your-agent>.jar YourMain

其工作流程大致如下：^[4]

• Agentmain

该模式和 Premain 模式相似，主要区别在进行字节码增强前，拦截入口不同。一个叫Premain，一个叫Agentmain 。 运行时加载，当前 JVM 进程已经启动了。这时借助另一个 JVM 进程通信，调用 Attach API 再把 Agent 启动起来。后面的字节码修改和重加载的过程那就是一样的。

3 - Otel Java Auto Instrumentation

Otel Java Auto Instrumentation 主要通过 Java agent 机制实现。

Java Auto Instrumentation 实现都在 github: https://github.com/open-telemetry/opentelemetry-java-instrumentation/ 这个仓库中。

3.1 - 快速开始

可以参考 doc 快速在一个 java 项目中进行 instrumentation，只需要如下几步：

1. Download opentelemetry-javaagent.jar from Releases of the opentelemetry-java-instrumentation
2. 通过 java -javaagent:path/to/opentelemetry-javaagent.jar -Dotel.service.name=your-service-name -jar myapp.jar 启动你的 project app myapp.jar

通过这两步，就已经可以在这些 otel 支持的 library 上运行 opentelemetry 了，可以通过在环境变量或者 properties 中修改 这些配置 来进行更多自定义配置，包括但不限于：

• 数据导出配置：导出数据的目标类型,如 Jaeger、Zipkin、Prometheus等。
• 日志输出模式
• 采样策略
• 等等

下面通过一个我自己的示例来快速了解一下如何利用 Otel 提供的 @WithSpan 和 @SpanAttribute Annotation 进行 Auto Instrumentation 的 Tracing。^[6]

3.2 - Code 示例

首先创建一个 java 项目，并导入 opentelemetry-instrumentation-annotations 这个依赖，可以在 这里 查看 Maven 或者 Gradle 的导入方式。

这里以 gradle 为例，添加如下 dependencies 即可：

1

implementation("io.opentelemetry.instrumentation:opentelemetry-instrumentation-annotations:2.4.0")

全部的 build.gradle.kts:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

plugins {
    java
    id("com.github.johnrengelman.shadow") version "7.1.2"
}

group = "org.example"
version = "1.0"

repositories {
    mavenCentral()
}

dependencies {
    implementation("io.opentelemetry.instrumentation:opentelemetry-instrumentation-annotations:2.4.0")
}

tasks.withType<JavaCompile> {
    options.encoding = "UTF-8"
}

tasks.shadowJar {
    mergeServiceFiles()
    manifest {
        attributes(
            "Main-Class" to "org.example.Main"
        )
    }
}

tasks.build {
    dependsOn(tasks.shadowJar)
}

然后写一个简单的测试类：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

package org.example;

import io.opentelemetry.instrumentation.annotations.SpanAttribute;
import io.opentelemetry.instrumentation.annotations.WithSpan;

import java.util.logging.Logger;

public class Main {
    private static final Logger logger = Logger.getLogger(Main.class.getName());

    @WithSpan
    public static void main(String[] args) {
        sampleMethodA("test");
        sampleMethodB();
    }

    @WithSpan
    public static void sampleMethodA(@SpanAttribute String arg) {
        System.out.println("Sample method A, arg = " + arg);
        sampleMethodB();
    }

    @WithSpan
    public static void sampleMethodB() {
        System.out.println("Sample method B");
    }
}

使用 -Dotel.traces.exporter=logging-otlp 将输出指定为 otlp 的 json 格式（otlp 是 opentelemetry 定义的传输协议），通过 log 输出在控制台，然后把 logs 和 metrics 的 exporter 禁用后启动：

1

java -javaagent:opentelemetry-javaagent.jar -Dotel.traces.exporter=logging-otlp -Dotel.logs.exporter=none -Dotel.metrics.exporter=none -jar ./build/libs/otel-simple-demo-1.0-all.jar

也可以通过环境变量来启动：

1
2
3
4
5

JAVA_TOOL_OPTIONS='-javaagent:./opentelemetry-javaagent.jar' \
OTEL_TRACES_EXPORTER='logging-otlp' \
OTEL_METRICS_EXPORTER=none \
OTEL_LOGS_EXPORTER=none \
java -jar ./build/libs/otel-simple-demo-1.0-all.jar

输出如下:

1
2
3
4
5
6

Picked up JAVA_TOOL_OPTIONS: -javaagent:./opentelemetry-javaagent.jar
[otel.javaagent 2024-06-17 01:16:00:167 +0800] [main] INFO io.opentelemetry.javaagent.tooling.VersionLogger - opentelemetry-javaagent - version: 2.4.0
Sample method A, arg = test
Sample method B
Sample method B
[otel.javaagent 2024-06-17 01:16:06:098 +0800] [BatchSpanProcessor_WorkerThread-1] INFO io.opentelemetry.exporter.logging.otlp.OtlpJsonLoggingSpanExporter - {"resource":{"attributes":[{"key":"host.arch","value":{"stringValue":"aarch64"}},{"key":"host.name","value":{"stringValue":"sxz-mbp.local"}},{"key":"os.description","value":{"stringValue":"Mac OS X 14.4.1"}},{"key":"os.type","value":{"stringValue":"darwin"}},{"key":"process.command_line","value":{"stringValue":"/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/bin/java -javaagent:./opentelemetry-javaagent.jar -jar ./build/libs/otel-simple-demo-1.0-all.jar"}},{"key":"process.executable.path","value":{"stringValue":"/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/bin/java"}},{"key":"process.pid","value":{"intValue":"65608"}},{"key":"process.runtime.description","value":{"stringValue":"Azul Systems, Inc. OpenJDK 64-Bit Server VM 25.372-b07"}},{"key":"process.runtime.name","value":{"stringValue":"OpenJDK Runtime Environment"}},{"key":"process.runtime.version","value":{"stringValue":"1.8.0_372-b07"}},{"key":"service.instance.id","value":{"stringValue":"99dd9ca6-3d76-4aef-86ac-017e16881fbc"}},{"key":"service.name","value":{"stringValue":"otel-simple-demo-1.0-all"}},{"key":"telemetry.distro.name","value":{"stringValue":"opentelemetry-java-instrumentation"}},{"key":"telemetry.distro.version","value":{"stringValue":"2.4.0"}},{"key":"telemetry.sdk.language","value":{"stringValue":"java"}},{"key":"telemetry.sdk.name","value":{"stringValue":"opentelemetry"}},{"key":"telemetry.sdk.version","value":{"stringValue":"1.38.0"}}]},"scopeSpans":[{"scope":{"name":"io.opentelemetry.opentelemetry-instrumentation-annotations-1.16","version":"2.4.0-alpha","attributes":[]},"spans":[{"traceId":"641daaa0e701906be9ca743e4526f471","spanId":"9aed7d245875bdea","parentSpanId":"7159ba878669026b","name":"Main.sampleMethodB","kind":1,"startTimeUnixNano":"1718558166060339167","endTimeUnixNano":"1718558166062393375","attributes":[{"key":"code.namespace","value":{"stringValue":"org.example.Main"}},{"key":"thread.id","value":{"intValue":"1"}},{"key":"code.function","value":{"stringValue":"sampleMethodB"}},{"key":"thread.name","value":{"stringValue":"main"}}],"events":[],"links":[],"status":{},"flags":257},{"traceId":"641daaa0e701906be9ca743e4526f471","spanId":"7159ba878669026b","parentSpanId":"5316ba20f2a4144d","name":"Main.sampleMethodA","kind":1,"startTimeUnixNano":"1718558166060174750","endTimeUnixNano":"1718558166062439667","attributes":[{"key":"code.namespace","value":{"stringValue":"org.example.Main"}},{"key":"thread.id","value":{"intValue":"1"}},{"key":"code.function","value":{"stringValue":"sampleMethodA"}},{"key":"thread.name","value":{"stringValue":"main"}}],"events":[],"links":[],"status":{},"flags":257},{"traceId":"641daaa0e701906be9ca743e4526f471","spanId":"4eee1ecf0422c09e","parentSpanId":"5316ba20f2a4144d","name":"Main.sampleMethodB","kind":1,"startTimeUnixNano":"1718558166062502208","endTimeUnixNano":"1718558166062544292","attributes":[{"key":"code.namespace","value":{"stringValue":"org.example.Main"}},{"key":"thread.id","value":{"intValue":"1"}},{"key":"code.function","value":{"stringValue":"sampleMethodB"}},{"key":"thread.name","value":{"stringValue":"main"}}],"events":[],"links":[],"status":{},"flags":257},{"traceId":"641daaa0e701906be9ca743e4526f471","spanId":"5316ba20f2a4144d","name":"Main.main","kind":1,"startTimeUnixNano":"1718558166058000000","endTimeUnixNano":"1718558166062553750","attributes":[{"key":"code.namespace","value":{"stringValue":"org.example.Main"}},{"key":"thread.id","value":{"intValue":"1"}},{"key":"code.function","value":{"stringValue":"main"}},{"key":"thread.name","value":{"stringValue":"main"}}],"events":[],"links":[],"status":{},"flags":257}]}],"schemaUrl":"https://opentelemetry.io/schemas/1.24.0"}

3.3 - Span 的结构分析

输出的 json 实际上的结构可以在 trace.proto 中查看: https://github.com/open-telemetry/opentelemetry-proto/blob/v1.3.0/opentelemetry/proto/trace/v1/trace.proto

• 比如 main 方法对应的 span 对应包含如下信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

{
    "traceId": "641daaa0e701906be9ca743e4526f471",
    "spanId": "5316ba20f2a4144d",
    "name": "Main.main",
    "kind": 1,
    "startTimeUnixNano": "1718558166058000000",
    "endTimeUnixNano": "1718558166062553750",
    "attributes": [
        {
            "key": "code.namespace",
            "value": {
                "stringValue": "org.example.Main"
            }
        },
        {
            "key": "thread.id",
            "value": {
                "intValue": "1"
            }
        },
        {
            "key": "code.function",
            "value": {
                "stringValue": "main"
            }
        },
        {
            "key": "thread.name",
            "value": {
                "stringValue": "main"
            }
        }
    ],
    "events": [],
    "links": [],
    "status": {},
    "flags": 257
}

• 对于非 root span，还会额外包含一个 parentSpanId 的信息, 以 sampleMethodB 为例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

{
    "traceId": "641daaa0e701906be9ca743e4526f471",
    "spanId": "4eee1ecf0422c09e",
    "parentSpanId": "5316ba20f2a4144d",
    "name": "Main.sampleMethodB",
    "kind": 1,
    "startTimeUnixNano": "1718558166062502208",
    "endTimeUnixNano": "1718558166062544292",
    "attributes": [
        {
            "key": "code.namespace",
            "value": {
                "stringValue": "org.example.Main"
            }
        },
        {
            "key": "thread.id",
            "value": {
                "intValue": "1"
            }
        },
        {
            "key": "code.function",
            "value": {
                "stringValue": "sampleMethodB"
            }
        },
        {
            "key": "thread.name",
            "value": {
                "stringValue": "main"
            }
        }
    ],
    "events": [],
    "links": [],
    "status": {},
    "flags": 257
},

关于其中字段的详细解释可以参考：https://opentelemetry.io/docs/concepts/signals/traces/

除了在上一篇文章提到的 Tracing 通用的 spanId, traceId 这些通用的 Span Attributes 外, OpenTelemetry 还提供了两种新的称为 Span Events 和 Span Links 的东西:

• Span Events: 用于标记一个 Span 内部的一个关键事件, 例如:

1
2
3

span.addEvent("Init");
...
span.addEvent("End");

也可以在 events 中添加 Attributes:

1
2
3
4
5

Attributes eventAttributes = Attributes.of(
    AttributeKey.stringKey("key"), "value",
    AttributeKey.longKey("result"), 0L);

span.addEvent("End Computation", eventAttributes);

• Span Links: 用于标记一个 Span 与其他 Span 之间的关联关系，例如:

1
2
3
4
5
6

Span child = tracer.spanBuilder("childWithLink")
        .addLink(parentSpan1.getSpanContext())
        .addLink(parentSpan2.getSpanContext())
        .addLink(parentSpan3.getSpanContext())
        .addLink(remoteSpanContext)
    .startSpan();

这些 API 可以简单的在 Agent 的基础上使用，例如我们修改上面的示例代码:

1
2
3
4
5
6
7
8
9

@WithSpan
public static void main(String[] args) {
    Span currentSpan = Span.current();
    currentSpan.setAttribute("custom-attribute", "custom-attribute-value");
    currentSpan.addEvent("custom-event");
    currentSpan.addLink(currentSpan.getSpanContext());
    sampleMethodA("test");
    sampleMethodB();
}

然后重新运行，就可以得到如下的 payload：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

{
    "traceId": "f23dd7607ebec83961036bd1f5aadbfb",
    "spanId": "8f0e5a157098c520",
    "name": "Main.main",
    "kind": 1,
    "startTimeUnixNano": "1718608407274000000",
    "endTimeUnixNano": "1718608407319309792",
    "attributes": [
        {
            "key": "code.namespace",
            "value": {
                "stringValue": "org.example.Main"
            }
        },
        {
            "key": "thread.id",
            "value": {
                "intValue": "1"
            }
        },
        {
            "key": "code.function",
            "value": {
                "stringValue": "main"
            }
        },
        {
            "key": "custom-attribute",
            "value": {
                "stringValue": "custom-attribute-value"
            }
        },
        {
            "key": "thread.name",
            "value": {
                "stringValue": "main"
            }
        }
    ],
    "events": [
        {
            "timeUnixNano": "1718608407309075542",
            "name": "custom-event",
            "attributes": [

            ]
        }
    ],
    "links": [
        {
            "traceId": "f23dd7607ebec83961036bd1f5aadbfb",
            "spanId": "8f0e5a157098c520",
            "attributes": [

            ],
            "flags": 257
        }
    ],
    "status": {

    },
    "flags": 257
}

可以看到里面已经包含了刚才添加的自定义 attributes, events 和 links 信息。

Conclusion

这一章还处于比较浅的阶段，后面会再写写 otel 一些内部 code 结构的分析，以及如何通过 agent extensions 等机制来自定义 agent 行为等。

Reference

在 Amazon 已经实习了三个多月，很幸运没有被分配到做业务的活，想到实习的内容还是有一定价值的，值得我将其记录并进行一定的输出。

本来想着等实习结束后再进行总结，但是最近发生的一些事情让我意识到许多事情不要过分计划，有了想法就尽快 Demo 出来，哪怕只是一些零散的东西。

因此有了这篇博客，在总结输出的过程顺便让我理一理思绪。看心情可能会分为很多章，由于我做的内容仅仅只涉及到链路追踪（Tracing）部分，因此不对其他（Logging、Metrics）做过分详细的介绍。

由于我也是从 0 开始的小白，不保证内容的深刻程度。

• 在概念部分，我尽量引用别人的文字和图，辅以部分个人理解，以确保内容的可靠性。
• 在技术部分，我会更多的阐述一些 OpenTelemetry 的 SDK 实现和用途，以及个人对「为什么这么做」的一些浅薄的想法。

1 - 什么是可观测性 (Observability)

写著名「深入理解Java虚拟机」的周志明老师写过一本个人认为同样极其出色的书籍「凤凰架构」^[1]，在 可观测性 这一章有对这个概念非常棒的总结和解释，这里直接引用一下：

在学术界，虽然“可观测性”这个名词是近几年才从控制理论中借用的舶来概念，不过其内容实际在计算机科学中已有多年的实践积累。学术界一般会将可观测性分解为三个更具体方向进行研究，分别是：事件日志、链路追踪和聚合度量

• 日志（Logging）：日志的职责是记录离散事件，通过这些记录事后分析出程序的行为，譬如曾经调用过什么方法，曾经操作过哪些数据，等等。打印日志被认为是程序中最简单的工作之一，调试问题时常有人会说“当初这里记得打点日志就好了”，可见这就是一项举手之劳的任务。输出日志的确很容易，但收集和分析日志却可能会很复杂，面对成千上万的集群节点，面对迅速滚动的事件信息，面对数以 TB 计算的文本，传输与归集都并不简单。对大多数程序员来说，分析日志也许就是最常遇见也最有实践可行性的“大数据系统”了。

• 追踪（Tracing）：单体系统时代追踪的范畴基本只局限于栈追踪（Stack Tracing），调试程序时，在 IDE 打个断点，看到的 Call Stack 视图上的内容便是追踪；编写代码时，处理异常调用了 Exception::printStackTrace()方法，它输出的堆栈信息也是追踪。微服务时代，追踪就不只局限于调用栈了，一个外部请求需要内部若干服务的联动响应，这时候完整的调用轨迹将跨越多个服务，同时包括服务间的网络传输信息与各个服务内部的调用堆栈信息，因此，分布式系统中的追踪在国内常被称为“全链路追踪”（后文就直接称“链路追踪”了），许多资料中也称它为“分布式追踪”（Distributed Tracing）。追踪的主要目的是排查故障，如分析调用链的哪一部分、哪个方法出现错误或阻塞，输入输出是否符合预期，等等。

• 度量（Metrics）：度量是指对系统中某一类信息的统计聚合。譬如，证券市场的每一只股票都会定期公布财务报表，通过财报上的营收、净利、毛利、资产、负债等等一系列数据来体现过去一个财务周期中公司的经营状况，这便是一种信息聚合。Java 天生自带有一种基本的度量，就是由虚拟机直接提供的 JMX（Java Management eXtensions）度量，诸如内存大小、各分代的用量、峰值的线程数、垃圾收集的吞吐量、频率，等等都可以从 JMX 中获得。度量的主要目的是监控（Monitoring）和预警（Alert），如某些度量指标达到风险阈值时触发事件，以便自动处理或者提醒管理员介入。

2 - 链路追踪 (Distributed Tracing) 是如何进行的

在单体服务的时代，我们仅仅只需要跟踪代码的调用栈就可以获得清晰的调用图关系，以及出现异常时的 Stack Trace。

但在微服务时代，各类服务间可能形态各异（不同语言，不同框架），并通过不同的方式（RPC，HTTP，.etc）进行相互调用。于是如何追踪一次业务级别的服务调用相比单体服务的复杂程度就完全不是一个量级了。

因此我们不仅需要一个统一的「数据表示」来正确的表达这种追踪关系，而且需要一套大而全的「体系规范」来进行程序级别的实现。

Google 在 2010 年发布的这篇论文 Dapper：《Dapper : a Large-Scale Distributed Systems Tracing Infrastructure》^[2] 就奠定了之后十余年分布式链路追踪的数据表示的概念，其实抽象出来十分的简单，就是两个基本的概念：

1. Trace：一次业务级别的请求调用 (Client <-> Service A <-> Service B <-> … )
2. Span：
   • 可以是粗粒度的一个 Service 级别的 call
   • 也可以是细粒度的 Service 内部的函数调用 (Function A -> Function B -> …)

如何具体的规范化表示和收集这些信息，会在后面详细谈谈。

这里先看看一下在 UI 端，如何展示这些信息：

这里是以 Jaeger 为例，展示的一个 Trace Tree，其表示了一个请求/服务调用：

• 花费了多长的时间
• 与哪些内部组件/外部服务进行了交互
• 每个步骤中延迟是多少

可以稍微抽象化一些：

Talk is cheap，用伪代码可以这么表示：

1
2
3
4
5
6
7
8

function A() {
  B();
  E();
}
function B() {
  C();
  D();
}

这就是「分布式链路追踪」的基本概念，听起来很简单，因为系统的复杂性也确实不在这里。

3 - OpenTelemetry 下的链路追踪

就在前几周，在 v2ex 上看到一个有意思的问题：

“有人能解释一下 OpenTelemetry 这类遥测方案解决了什么问题，和自己写两个 API 把数据存进 MongoDB 有什么区别吗?"

在结果上，确实没有区别，如果是针对一个小组织的的内部服务，这么做完全可以，但是一但服务多了起来，就需要处理许多的规范化和兼容性问题。

例如，对于异构的服务（来自不同语言，不同平台，不同框架）：

1. Collect: 如何收集这些信息？格式是什么？
2. Export: 如何导出（发送）这些信息？
3. Protocol: 用什么协议导出这些信息?
4. Persistence: 信息应该存储在哪里？
5. UI: 如何统一的进行展示？

这也就是 OpenTelemetry 出现的原因，在 OpenTelemetry 出现之前，几乎市面上所有的追踪系统都是以 Dapper 的论文为原型发展出来的，基本上都算是同门师兄弟，功能上并没有太本质的差距，却又受制于实现细节，彼此互斥，很难搭配工作。譬如该怎样进行埋点、Span 上下文具体该有什么数据结构，怎样设计追踪系统与探针或者界面端的 API 接口，等等，都没有权威的规定。

OpenTelemetry （简称 Otel）的出现，除了统一 Tracing 规范，还一口气把可观测性全部大一统了。光是开箱即用的兼容了 Otel 的 Java Library（可以在 https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md 看到）就包含了绝大部分常用的热门框架。即使没有原生支持，也可以通过统一的协议和 SDK 来以较低的成本实现扩展和兼容。

为什么是 OpenTelemetry

为什么各个大厂愿意放弃自己实现的规范和技术架构，跑过来兼容 OpenTelemetry？其实 OpenTelemetry 的统一已经是大厂之间妥协后达成一致的结果，在 Otel 之前，主要有这两种 Tracing 规范标准：

• 在 2016 年，CNCF 技术委员会接受了 OpenTracing 作为基金会第三个项目。（第一个是Kubernetes，第二个是Prometheus）OpenTracing制定了一套平台无关、厂商无关的Trace协议，使得开发人员能够方便的添加或更换分布式追踪系统的实现。OpenTracing 规范公布后，几乎所有业界有名的追踪系统，譬如 Zipkin、Jaeger、SkyWalking (都是 github 20k+ star 的开源项目) 等都很快宣布支持 OpenTracing。
• 这时候大一统本来都要完成统一了，结果google并不认为这个东西是标准，所以推出了自己的 OpenCensus 规范。要是换一家公司来肯定都干不过 OpenTracing 了，但：
  • 这可是 Google，要知道最先就是 Google 提出了分布式 Tracing 这个概念。
  • OpenCensus 并不是单纯的规范制定，实现了Agent、Collector、SDK 等一系列工具链。
  • OpenCensus 又得到了微软的支持。

于是一段时间内都是两架马车并驾齐驱的形势。直到在2019年， 两者和解，共同发起了OpenTelemetry开源项目。最终目标是作为CNCF技术委员会可观测性的终极解决方案，大一统 Tracing，Metrics 和 Logging。^[4]

OpenTelemetry 提供了什么

目前 OpenTelemetry 的工作主要集中在如下部分：

• 适用于所有组件的规范 (specification)
• 定义遥测数据形状的标准协议 (protocol)
• 为常见遥测数据类型定义标准命名方案的语义约定 (semantic conventions)
• 定义如何生成遥测数据的 API
• 实现规范、API 和遥测数据导出的SDK
• 实现常见库和框架的仪表化的 Library Ecosystem
• 可自动生成遥测数据的 Auto Instrumentation 组件
• OpenTelemetry Collector：接收、处理和导出遥测数据的代理

同时，可以通过 官方的迁移指南 将 OpenTracing / OpenCensus 迁移到 OpenTelemetry。

Reference

结果现在离假期过去只有不到8小时，却看上去一事无成。

原因只是自己因为固执的想看懂别人 paper 里写的一个算法，并且自己实现一遍，但是因为一直调不出来，直接卡了一天半的时间，现在身心俱疲。

而自己现在慢慢跳出来后再次回看这件事情，发现十分的荒谬，因为这件事其实并不成为其他优先级更高的事的阻碍，而我花这么久时间只不过是在和自己较劲，也许这也是一种舒适圈惯性，只不过过程和结果都是痛苦的。

仔细回顾一下，并不是没有花精力和时间，只是由于一种心理习惯，做出了错误的选择。

于是昨天晚上躺在床上，想了半天自己为什么会屡屡做出这样再后来看来无比愚蠢的决策，于是诞生了此文，记录一些浅薄的思考。

心理免疫的 X 光片

”我们都对改变具有本能的抗拒“

这个名词最初是在 这篇文章 上看到的。

由凯根提出的”心理免疫的X光片“这一概念，生动形象地阐释了人类内心对于改变的本能抗拒；正如生理层面上人体拥有免疫系统来抵御外来入侵一般，我们的心理也有一套天生的防御机制。

当我们试图采取新的行为模式时，这套焦虑控制系统就会被触发，使我们感到不安全和焦虑。

我想称之为「舒适圈惯性」。

我发现在做不少事情的时候，总会因为一些小的沉没成本而放弃了更加合适的路径的选择。

一些也许不太恰当的例子：

1. 选择了一个架构，实现了一部分代码后发现架构不是特别合适，但是目前也勉强能做，于是就懒得改了，直到后面坑越堆越多。
2. 习惯了某个餐厅和进食习惯，即使后面发现这种习惯并不健康，或者周围出现了更多样化的选择，还是依旧一如既往的选择这种饮食习惯。

很多时候对于这些事件，我们不愿意去分析他的本质，我们把原因归结于自己的不愿意改变，实际上也许更深层次的原因是「我们的内心就是想要这个行为的结果」。

文章中提到了一个方法论，个人感觉挺有用的，也许能帮助想明白内心做出后悔选择的逻辑，因为很多时候我们做出选择的时候都在自己骗自己：

1. 做这件事情，希望达成的目标是什么
2. 正在做哪些和目标完全相反的行为
3. 这些与目标相反的行为有哪些隐含的好处或可以避免的损失
4. 内心是否存在一个重大（但很有可能是错误的）的假设，这个假设是什么？

文中提到的一个例子：

假设小明在一个互联网企业工作，近期正好赶上一个迭代紧密的项目，时间紧任务重，不得不996，这让小明很痛苦。

1. 小明希望达成的目标：
   • 不要996工作，能有更多的个人时间，看电影玩游戏，陪女朋友以平息她的怒气。
2. 小明正在做哪些跟目标完全相反的行为
   • 乖乖996，甚至007。
3. 这些与目标相反的行为有哪些隐含的好处或可以避免的损失
   • 小明的项目正在起步阶段，乖乖听老板的话，努力干活，勤奋向上，希望项目上线后可以休息一下。另一方面，这既是挑战也是机会，大家都想要抓住机会，而且如果我不这么干，老板把我开了呢？
4. 小明内心有一个重大的假设，这个假设是什么？
   • 如果小明不996，老板就会把他开掉。反过来小明如果996，就能获得老板认可。那么这个假设是否成立呢？我想读者朋友们如果有一定工作经验，应该不难下判断。

精神破窗效应

以一幢有少许破窗的建筑为例，如果那些窗没修理好，可能将会有破坏者破坏更多的窗户。最终他们甚至会闯入建筑内，如果发现无人居住，也许就在那里占领、定居或者纵火。又或想像一条人行道有些许纸屑，如果无人清理，不久后就会有更多垃圾，最终人们会视为理所当然地将垃圾顺手丢弃在地上。

破窗效应，或者叫「熵增定律」，无时无刻不在生活中发生。例如快速从整洁变成乱七八糟的状态的房间，例如椅子上越堆越多的脏衣服，例如软件开发中的屎山的形成过程。

而当自由可支配时间变少时，这种混乱会进一步加剧。

而一种很有趣的现象就是，当你主动减少或抑制了某几个系统的熵增过程，会促使你去减少其他系统的混乱程度，这似乎是一种正向的情绪传递的过程。

昨天晚上，我把攒了一周的衣服洗了一遍，然后把攒了一个月混乱不堪的笔记系统也整理了一遍，将桌面的线缆重新梳理了一下；在做完这几件事情后，可以明显感受到焦虑感减少了。

而另一种（于我而言）很无用的方法就是所谓的「心理暗示」。

例如，在前两天感到很焦虑的时候，我一直在翻阅相关的文章，然后看到这本书的前几章后，我当时差点没有一口老血吐出来：

并不是心理暗示无用，它也许能加速正向过程，前提是一切已经在正向发展的路上了。

其实任何禅修之道的效果都是个体化差异极大的，但万变不离其宗的是，当意识到当下的行为处于舒适圈惯性或失控的过程中，就需要停下来好好想一想了。

Reference

• 枫言枫语：每个人每天都只有24小时，希望我的选择真的是我的选择
• 评论尸：现代打工人如何获得幸福？
• https://zh.wikipedia.org/wiki/破窗效应
• https://sspai.com/post/81976

截止到 2024 年，以著名科学家的名字命名的 Nvidia GPU 微架构的演进历史如下：

• Tesla（尼古拉·特斯拉，Nikola Tesla）
• Fermi（恩里科·费米，Enrico Fermi）
• Kepler（约翰内斯·开普勒，Johannes Kepler）
• Maxwell（詹姆斯·克拉克·麦克斯韦，James Clerk Maxwell）
• Pascal（布莱兹·帕斯卡，Blaise Pascal）
• Volta（亚历山德罗·伏特，Alessandro Volta）
• Turing（艾伦·图灵，Alan Turing）
• Ampere（安德烈-玛丽·安培，André-Marie Ampère）
• Hopper（格蕾丝·霍普，Grace Hopper）
• Ada Lovelace（艾达·洛夫莱斯，Ada Lovelace）
• Blackwell (戴维·布莱克韦尔, David Harold Blackwell)

具体发布时间和代表型号总结:

整体演进的介绍

Fermi 架构 (2010)

Fermi 架构是 NVIDIA 第一个完整的 GPU 计算架构，它支持 ECC 和多任务 CUDA Core 处理，强化了 GPU 的计算能力和错误修正能力。Fermi 引入了多个图形处理簇（GPCs），每个包含多个流处理多处理器（SMs），这些都具备较高的并行处理能力和更好的散热效果。此外，它使用 40/28nm 工艺，搭载了高达 6 GB 的 GDDR5 内存。

Kepler 架构 (2012)

Kepler 架构通过优化 CUDA Core 的布局和性能，显著提高了 GPU 的能效比。此架构引入了动态并行技术，允许 GPU 在执行过程中动态调整并行任务的数量和类型，极大地提升了灵活性和计算效率。Kepler 也首次支持 GPU Direct 技术，使得多个 GPU 之间可以直接进行数据传输，避免通过 CPU 中转，减少延迟和增加带宽。

Maxwell 架构 (2014)

Maxwell 架构在前一代基础上进一步提高了性能和能效比，尤其是在图形处理上。它减少了每个处理块的 CUDA Core 数量，增加了更多的控制逻辑，使得 GPU 能够在同等功耗下提供更高的性能。此外，Maxwell 引入了第一代 DSR 技术和 MFAA 技术，提升了图形质量和渲染效率。

Pascal 架构 (2016)

Pascal 架构在 GPU 计算能力上有了质的飞跃，首次引入 HBM2 内存和 NVLink 技术，这些改进显著提高了带宽和支持的数据传输速率。此架构专为高性能计算和深度学习优化，提供了显著的性能提升。Pascal 同时支持多达 16 个 SM 和新的半精度浮点数（FP16）运算，为 AI 训练和推理提供加速。

Volta 架构 (2017)

Volta 架构引入了 Tensor Core，专门设计用于加速深度学习应用中的矩阵运算。它还提升了 NVLink 的带宽，并引入了新的 HBM2 内存技术。Volta 在 AI 计算和图形处理方面均有显著提升，GPU 架构进一步优化了内存使用和数据传输效率。

Turing 架构 (2018)

Turing 架构标志着 NVIDIA 在光线追踪技术上的重大突破，首次引入 RT Core，专门设计用于实时光线追踪。Turing 也改进了 Tensor Core，增强了 AI 推理能力。此外，它引入了新的 GDDR6 内存，提高了内存速度和带宽，为图形密集型应用和游戏提供了更高的性能。

Ampere 架构 (2020)

Ampere 架构进一步扩展了 Tensor Core 和 RT Core 的功能，提供了更强大的 AI 训练和推理能力以及更加逼真的图形渲染性能。它引入了第三代 Tensor Core，支持更多的数据类型和更高的计算效率，同时也推出了多实例 GPU（MIG）技术，允许单个 GPU 资源在多个用户间进行分割，提高了硬件的使用效率。

Hopper 架构 (2022)

Hopper 架构引入了第四代 Tensor Core 和多项创新技术，包括改进的 NVLink 和新的 HBM3 内存技术。它专为 AI 计算和高性能计算场景设计，提供了前所未有的计算速度和效率，同时支持更复杂的 AI 模型和算法。

Blackwell 架构 (2024)

Blackwell 架构是 NVIDIA 在 AI 和数据中心应用中的又一巨大飞跃，它引入了第五代 Tensor Core，支持新的数据类型和 AI 训练技术，提供了极高的计算效率和能效比。Blackwell 还优化了 GPU 内部的数据传输和处理机制，为处理大规模数据集和复杂的 AI 模型提供了强大的支持。

Reference

• NVIDIA GPU 架构梳理 - 知乎
• NVIDIA GPU架构回顾 - 知乎
• NVIDIA 技术和 GPU 架构 | NVIDIA CN
• AISystem/02Hardware/03GPUBase - GPU 架构回顾

上周刚刚吐槽过北京的天气一点道理都不讲，今天就碰到了难得一见的极端天气。

上午还艳阳高照，结果下午突然就8级大风 + 倾盆大雨。

晚上吃完饭去学校旁边的公园逛了逛，此时已经完全看不出一小时前是狂风大作了，一切又恢复了以往的样子，除了稍稍凉爽下来的气温。

公园里只有老人带着小孩玩耍，来过几次这边的公园，奇怪的是虽然在校园旁边，但是基本见不到学生，公园里的圆形平台正在搭建一个「大学生音乐节」的演出现场，不过也不知道什么时候开始。

Copilot Again，关于AI和编程的乐趣

申请了一周的 github student pack 总算审批下来了，其中最期待的就是 Copilot 了，在 vscode 上试用了一下，有了很大的进步，无论是操作方面还是模型方面；

看到了一篇文章：ChatGPT 正在杀死编程里的乐趣，虽然有点标题党，但最后一句总结确实挺到位的：

最后，虽然 ChatGPT 给了我一份质量可比肩（部分）人类的 Python 代码，但我并不认为它会在短时间内消灭编程，让程序员这个职业成为历史。里面的核心原因在于：“规划与设计”部分短期内无法由机器代劳。

但不会消灭编程，并不等同于 ChatGPT 不会改变人们的编程习惯。我认为它已经开始在调整人们从编程中获取乐趣的方式了——如果不是直接抹除的话。

不可否认的是，在我浅薄的程序经验里，编程中的两大部分快乐，一个是顶层设计的过程，另一个是 Coding 实现的过程。

而顶层设计的过程其实充满了变数，尤其是当需要与许多人沟通的时候；

真正 Coding 的过程，是一个可以获得「心流」状态的过程，在这个阶段，人将代码编程具体的实现，并进行不断的调试和修改以满足自己所期望的状态，没有第三方的介入，是全身心的投入。

但是 AI 的引入，我认为在一定程度上，将这一过程慢慢也变成了一个 沟通-讨论 的过程，你需要向 AI 说需求，AI 需要提供 solution，然后你再进行审核，修改；

如何适应这样的转变，是一个需要打磨的过程。

赛博折腾

优化手机首屏

折腾优化了一下手机的首屏内容，把一些常用的 App 修改了一下，不过总体来说没有太大的变化。