Moreality修改

2026-06-21 13:10:00

这几天 VPS 圈子里，哪吒监控（Nezha）基本被刷屏了。

有人说 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

2026-04-19 15:39:57

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

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… 以后旅行可能还是会优先考虑山川湖海）

2026-04-06 00:00:00

• 24年9月，刚结束秋招，去秦皇岛待了 2 天。

• 25年6月，毕业，去大连待了 3 天。

• 26年4月，又一个人去青岛待了 3 天，不过这次没有什么 milestone，就是单纯想看海了。

准备

• 酒店: 是在招行上订的海景房，叫「汇泉王朝大饭店」(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

2025-06-10 08:50:32

day 0 - 启程

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

这趟卧铺有很多好处：

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

day 1 - 东港

酒店定在了中山广场，

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

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

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

几个景点的感受：

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

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

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

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

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

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

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

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

随处可见这样的告示：

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

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

day 2 - 亲海栈道

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

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

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

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

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

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

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

day 3 - 一些城市景观

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

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

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

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

后记

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

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

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

很喜欢的一句话:

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

2025-05-29 19:35:05

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

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

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

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

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

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

海河游船

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

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

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

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

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

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

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

白天的天津：炎热而无聊

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

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

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

相声：有点意思

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

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

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

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

还是更喜欢山川湖海。

2025-04-21 22:45:28

前言

注意，本文不是翻译，只是针对自己觉得有用的一些地方的记录和总结；对于我自己觉得已经比较清楚的概念，就完全没有记录。其中最后的「最佳实践 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系统的特定方面，包括查询、块设置、块输出和其他信息。

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

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