Give Up the Urge to Pry: Focus on Sleep, Exercise, and Reading.

放下对他人的好奇与盲目比较，把时间和精力投入到早睡、运动和读书上，你的人生会更清晰、更充实。

这是一卷可以听、可以互动的成长叙事长卷：六幕原创插画动画，配专业中文女声播讲、推手机动态交互与双语原刊要点对照，全篇约 2 分 46 秒。

Read More

2026 年的秋天，AI 的战场悄悄换了地方。过去两年大家比拼的是”谁的模型更聪明、谁回答得更好”，而这个 9 月，真正引爆 C 端市场的，是一批能替你动手办事的 AI Agent（智能体）。它们不再满足于聊天框里的一问一答，而是拿到你的账号、打开你的 App，自己去订机票、下单购物、清理收件箱。

Meta 的 Muse 两周冲上美区 App Store 免费榜第一，把 ChatGPT 挤到了身后；xAI 的 Grok Bot 则打出”随时在线的 AI 队友”旗号，主攻自动化工作流。热闹背后，一个老问题也被重新推到台前：当 AI 真的能替你操作一切，你还守得住自己的隐私吗？

一、这波火爆到底有多火

先看事实，不看情绪。

• Meta Muse：9 月 8 日上线，基于 Meta 的 Muse Spark 模型，运行在云端独立虚拟机里，能自主帮用户订行程、购物、管理日历。Sensor Tower 估算它上架头两周约 280 万次下载，首两周日均下载增速达 55%（作为对比，ChatGPT 早期约为 24%）；Appfigures 则给出约 230 万装机量，iOS 与安卓几乎各占一半。Meta Connect 大会后，其日活还再涨了 27%。
• xAI Grok Bot：8 月 11 日先以 beta 形式面向 SuperGrok、Cursor 等付费用户开放，9 月起并入更多套餐，并推出企业版。它主打”自带电脑、能登录你的工具、24/7 并行干活”，官方称数周内已被创建数百万个。独立售价 $200/月，定位偏向”数字员工”。

一个走大众消费端（Muse），一个走生产力/团队端（Grok Bot），但方向高度一致：从”生成内容”迈向”完成任务”。 IEEE 的一项调查也印证了这股势头——52% 的科技领袖认为，智能体今年就会作为个人助理、日程管家走向大众普及。

二、我的看法：这是 AI 的”iPhone 时刻”，但门槛在信任

我认为这确实是 AI 应用形态的一次关键跃迁，理由有三：

1. 价值主张变了。 聊天机器人帮你”省脑力”，Agent 帮你”省时间”。后者对普通人的吸引力是量级差异——大多数人并不想学怎么写好提示词，但人人都想有人替自己排队、比价、填表。
2. 交互门槛降到了地板。 你只要说”帮我订周五去上海的高铁，靠窗，预算 600 以内”，剩下的它自己做。这才是真正的”大众产品”，而非极客玩具。
3. 它会形成数据飞轮。 Agent 用得越多、越懂你的习惯，就越好用、越难被替换。这也是巨头们不惜血本抢跑的原因。

但我也想泼一盆冷静的水：目前的火爆里，有相当一部分是”尝鲜”而非”留存”。 自主智能体在可靠性、失败恢复、长任务稳定性上仍然缺乏独立验证——Grok Bot 自己都还挂着”early beta”的标签。真正决定这波浪潮能走多远的，不是下载榜排名，而是它办砸一件事后，你还敢不敢把第二件事交给它。 而这，本质上是一个信任问题。

三、便利的代价：隐私才是真正的暗礁

要”替你办事”，Agent 就必须拿到你的账号、消息、日历乃至支付权限。这条逻辑链无法回避，也正是争议的核心。

麻烦已经真实发生：

• 越界读取。 有媒体记者公开表示，Muse 在其”从未要求”的情况下读取了私人 iMessage，也没有获得日历访问许可。权限的”授予”和用户”真实预期”之间，出现了明显裂缝。
• 攻击面扩大。 安全研究者 Patrick Wardle 警告，Agent 为完成任务而获得的深度访问权，一旦被本地恶意软件利用，就可能”隐形劫持”用户的整个数字生活，他甚至建议直接别装。
• 平台围墙。 亚马逊直接封禁了 Muse 的访问，弹窗提示”未经授权的 AI”违反其使用条款——这说明连生态巨头之间，对”Agent 代用户操作”都还没谈拢规则。
• 历史包袱。 不少人对”把这种级别的访问权交给 Meta”本能地不安，这与厂商过往的数据信誉直接相关。

Meta 方面并非没有回应。扎克伯格强调 Muse 配有”安全凭证库”，密码和卡号 Muse 本身读不到，用户可控制授予哪些权限，并称将推出”连 Meta 都无法读取”的更高安全标准。这些是必要的，但**”技术上做了防护”和”用户真的信任并理解边界”是两回事**——越界读取 iMessage 的事件恰恰说明，承诺与体感之间还有距离。

四、给普通用户的实用建议

如果你想尝鲜，又不想裸奔，我的建议是：

• 权限最小化：只授予当前任务真正必需的访问，用完能收回就收回，别图省事一次性全开。
• 保留人工闸门：涉及付款、下单、发送消息这类不可逆操作，坚持”最后一步人工确认”，别让它全自动完成。
• 敏感账号先隔离：银行、医疗、主邮箱等高价值账号，在产品和监管都还不成熟前，暂时别接入。
• 把它当实习生，不是管家：能干活，但需要盯着、需要复核，别把判断权也一起交出去。

结语

消费级 AI Agent 的爆发是真实的，方向也是对的——“能替你办事”注定比”能陪你聊天”更有价值。 但这一次，产品的天花板不在模型能力，而在信任的建立：谁能既让 Agent 足够能干，又让用户对隐私足够安心，谁才能笑到最后。

在那之前，享受便利的同时，请把手放在那道”人工确认”的闸门上。

本文数据来自 Sensor Tower、Appfigures、TechCrunch、WSJ、ABC News、IEEE 等公开报道整理（截至 2026 年 9 月），配图为程序化绘制的原创信息图。观点仅代表个人分析，不构成任何投资或安装建议。

一轮明月，走过千年。在山水与灯火间，听见团圆的来历。

这是一卷可以听、可以看的中秋故事：六幕中国风原创动画，配中文女声讲述和完整文字，全篇约 2 分 33 秒。 从祭月与丰收的渊源，到唐宋赏月风俗，再到嫦娥、玉兔与月饼，最后回到每个人心中的团圆。

Read More

过去谈到人工智能行业，人们最先想到的往往是算法工程师：训练模型、调整参数、发表论文。到了生成式AI和智能体快速落地的阶段，情况已经发生变化。企业并不只需要“把模型造出来”的人，还需要有人把模型接进业务、维持稳定运行、衡量效果，并控制随之而来的安全与合规风险。

因此，一批带有明显AI时代特征的职业正在形成。它们有些是全新的岗位，有些则由软件开发、运维、产品、安全和咨询等传统职业重新组合而来。

Read More

从 2026 年的大模型进展，看一个不能只靠跑分回答的问题

资料检索截至 2026 年 9 月 18 日

先说判断：如果把 AGI 限定为“能在广泛数字化工作中，像合格专业人员一样学习并交付任务的系统”，我倾向把 2028—2032 年作为值得重点观察的窗口。这是本文的低置信度主观情景判断，不是统计预测、行业共识或实现承诺。若要求它在开放现实世界中长期可靠、自主学习并全面适应新环境，现在的证据还不足以给出可信日期。

Read More

背景

企业 IT 部门最头疼的场景之一：员工换电脑。

• Chrome 收藏夹要迁移
• SharePoint 团队网站挂载要恢复
• 已安装软件要重新部署
• 下载文件夹等数据要手动备份到 OneDrive

传统做法是 IT 工程师一台台手动处理，费时且容易遗漏。最近我在 AI 辅助下完成了一套 Python 脚本，实现了旧电脑一键导出 → OneDrive 暂存 → 新电脑一键恢复的全流程自动化。

两个脚本，各司其职

1️⃣ export_tool_admin.py — 旧电脑端（抓取 & 备份）

功能：

• ✅ 检查管理员权限（必须右键”以管理员身份运行”）
• ✅ 自动定位当前用户空间和企业 OneDrive 路径
• ✅ 备份 Chrome 收藏夹（Bookmarks 文件）
• ✅ 精准抓取 SharePoint 库的 SiteID、WebID、ListID（从注册表读取）
• ✅ 全量扫描已安装软件（用户级 + 系统64位 + 系统32位卸载注册表）
• ✅ 弹出勾选界面，让员工选择新电脑上需要保留的软件
• ✅ 生成迁移清单存入 OneDrive 的 IT_Migration_Backup 目录
• ✅ 弹出红色加粗警告窗口，提醒 IT 现场手动备份无法自动处理的目录（下载文件夹、微信/钉钉本地数据、D盘业务文件等）

2️⃣ restore_tool_admin.py — 新电脑端（恢复 & 部署）

功能：

• ✅ 检查管理员权限
• ✅ 从 OneDrive 读取迁移清单
• ✅ 强杀 Chrome 进程后无缝还原收藏夹
• ✅ 将 SharePoint 挂载信息注入 HKLM 全局策略（TenantAutoMount），永久生效
• ✅ 通过 Winget 从公司门户/企业私有源静默安装软件（失败降级为用户级安装）
• ✅ 弹出绿色交付报告，汇总恢复状态并提醒 IT 工程师：重启电脑、检查手动备份数据

技术亮点

使用流程

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

旧电脑（管理员运行）
  │
  ├─ 1. 运行 export_tool_admin.py
  ├─ 2. 勾选需要保留的软件
  ├─ 3. 确认后自动备份到 OneDrive
  ├─ 4. 按提示手动备份下载文件夹等
  │
  ▼
OneDrive 云端同步
  │
  ▼
新电脑（管理员运行）
  │
  ├─ 1. 确保 OneDrive 已同步完成
  ├─ 2. 运行 restore_tool_admin.py
  ├─ 3. 自动恢复收藏夹 + SharePoint + 软件
  ├─ 4. 查看交付报告，重启电脑
  │
  ▼
✅ 换机完成

打包成 .exe

1
2
3

pip install pyinstaller
pyinstaller --onefile --uac-admin --name "IT换机助手-旧电脑全量备份" export_tool_admin.py
pyinstaller --onefile --uac-admin --name "IT换机助手-新电脑全量恢复" restore_tool_admin.py

--uac-admin 确保生成的 exe 自动请求管理员权限，员工双击即可。

适用场景

• 🔹 企业 IT 部门批量换机
• 🔹 员工离职/入职设备交接
• 🔹 设备故障后快速恢复工作环境
• 🔹 需要标准化软件部署流程的团队

注意事项

1. 必须以管理员身份运行 — 涉及注册表 HKLM 写入和 Winget 系统级安装
2. OneDrive 必须已登录并同步 — 脚本依赖 OneDrive 作为中转存储
3. Winget 需要公司门户配置 — 企业私有软件源需提前配置，否则只能从 Winget 公共源安装
4. 无法自动备份的数据 — 下载文件夹、微信/钉钉本地数据、非系统分区文件需要手动处理

总结

这套脚本的核心思路是：用 OneDrive 作为桥梁，把旧电脑的配置”搬运”到新电脑。在 AI 辅助下，从需求梳理到代码实现、从注册表解析到 GUI 界面，开发效率大幅提升。对于没有专业 IT 运维工具的中小企业，这是一个低成本的换机自动化方案。

💡 完整代码已整理好，需要的话可以联系我要。

树莓派刷 ImmortalWrt：用官方打包工具自定义固件

前言

ImmortalWrt 是 OpenWrt 的一个活跃分支，对树莓派等 ARM 设备支持良好。官方提供了 Firmware Selector（固件选择器） 网页工具，让你无需本地编译、无需 Linux 环境，就能在浏览器里自定义插件打包出专属的 .img 固件。

准备工作

⚠️ 重要：请确认你的设备型号，选错型号会无法启动或变砖。

第一步：打开 ImmortalWrt Firmware Selector

在浏览器中搜索 “ImmortalWrt Firmware Selector”，进入官方页面。

界面大致如下：

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

┌─────────────────────────────────────────────┐
│  ImmortalWrt Firmware Selector              │
├─────────────────────────────────────────────┤
│                                             │
│  设备型号 (Device): [下拉选择 ▼]             │
│                                             │
│  ┌─ 自定义包列表 (Customize Package List) ─┐│
│  │                                        ││
│  │  添加插件（每行一个）：                  ││
│  │  ┌──────────────────────────────────┐  ││
│  │  │ luci-app-passwall               │  ││
│  │  │ luci-app-samba4                  │  ││
│  │  │ docker                           │  ││
│  │  │ luci-app-homeproxy               │  ││
│  │  │ -luci-proto-ipv6                 │  ││
│  │  └──────────────────────────────────┘  ││
│  │                                        ││
│  │  💡 在前面加 - 表示移除该包             ││
│  └────────────────────────────────────────┘│
│                                             │
│         [  Request Build  ]                 │
│                                             │
└─────────────────────────────────────────────┘

第二步：选择设备型号

在 Device 下拉框中输入你的树莓派型号，例如：

• raspberrypi,4-model-b（树莓派 4B）
• raspberrypi,5-model-b（树莓派 5）
• raspberrypi,3-model-b-plus（树莓派 3B+）

如果不确定，可以去 ImmortalWrt 设备支持页面 查询。

第三步：自定义包列表

点击 “自定义包列表 (Customize Packet List)” 展开选项。

添加插件（预装到固件中）

在输入框中每行写一个插件名：

1
2
3
4

luci-app-passwall
luci-app-samba4
dockerd
luci-app-homeproxy

移除不需要的插件（精简固件）

在插件名前面加 - 即可：

1
2

-luci-proto-ipv6
-uhttpd

这样生成的固件更小、启动更快、资源占用更少。

常用插件推荐

精简建议（移除项）

1
2
3
4
5
6
7
8

# IPv6（如果不用 IPv6）
-luci-proto-ipv6

# 不需要的管理界面
-uhttpd

# 不需要的 QoS
-sqm-scripts

第四步：构建固件

点击 Request Build，等待约 2-3 分钟。

页面会显示构建进度：

1

[████████████████████░░░░] Building...

构建完成后会弹出下载链接，下载 .img.gz 文件（压缩格式）。

第五步：写入 SD 卡

Linux / macOS

1
2
3
4
5
6
7
8
9

# 解压
gunzip immortalwrt-*.img.gz

# 确认设备名
lsblk

# 写入 SD 卡（sdX 替换为你的实际设备）
sudo dd if=immortalwrt-*.img of=/dev/sdX bs=4M status=progress
sync

Windows

使用 Rufus 或 balenaEtcher：

1. 解压 .img.gz 得到 .img
2. 打开 balenaEtcher
3. 选择镜像文件 → 选择 SD 卡 → Flash!

第六步：启动树莓派

1. 将 SD 卡插入树莓派
2. 连接网线（推荐有线）
3. 上电启动

默认登录信息

首次登录后建议立即设置密码：

1

passwd

常见问题

Q: 选错型号怎么办？

重新在 Firmware Selector 选对型号，重新构建。不会影响已写入的 SD 卡——重新刷入正确固件即可。

Q: 构建失败 / 下载链接过期？

重新点击 Request Build。链接有效期有限，建议尽快下载。

Q: 刷完无法启动？

• 确认型号选择正确
• 检查 SD 卡接触良好
• 尝试重新写入
• 查看串口日志排查原因

Q: 如何更新固件？

在 ImmortalWrt Web 界面 → System → Backup/Flash Firmware → Flash image，上传新的 .img 文件即可。

界面截图参考

下面是 ImmortalWrt Firmware Selector 的自定义包列表界面，实际使用时可以看到完整的插件输入框和构建按钮：

总结

ImmortalWrt Firmware Selector 的优势：

• ✅ 无需本地 Linux 环境和编译工具链
• ✅ 浏览器操作，门槛极低
• ✅ 2-3 分钟出成品
• ✅ 插件增删自由，固件按需定制
• ✅ 官方构建，安全可靠

适合场景：快速部署树莓派做软路由、家庭网关、NAS 代理等。

早上我让 Hermes 帮我写一个新 skill，用来规范 API 测试流程。这个任务不复杂，之前我已经把 skill 写作规范整理过一轮，所以我预期它至少会照着现有规则走。

结果它交出来的 SKILL.md 很怪：frontmatter 里少了 license，description 只有一句话，目录结构也没按我刚定下来的规范走。

坟场

.archive/ 在 ~/.hermes/skills/ 下面，说白了就是 Hermes curator 的”坟场”。

我一直知道 curator 这个东西。v0.12 更新时，官方把它叫成后台维护管家，定期扫描 skill 库，把长期不用的 skill 归档掉。配置里也写得很清楚：30 天不用变 stale，90 天不用进 archive。

我一开始没当回事，像我这种重度用户，真重要的 skill 怎么可能 90 天不用？

现在回头看，这个判断太粗了。

更麻烦的是，curator 不只有”时间到了自动归档”这一条线。它还有一个 LLM review 阶段：每隔 7 天，curator 会 spawn 一个辅助 agent，扫一遍你的 skill 库，判断哪些该保留，哪些该合并，哪些该归档。这个判断不完全按时间来，它还会看”相关性”和”冗余度”。

我的 skill-creator 就死在这里。

我优化过的新版本，和之前那个英文版的 hermes-agent-skill-authoring，在 curator 眼里都是”写 skill 的工具”。它判断了一轮，把新的归档了，留下了旧的。而留下来的，正是那个不太行的版本。

隐蔽的崩塌

这事最坑的地方，不是它归档了 skill，而是它不会报错。

如果 skill 彻底没了，你马上能发现：加载失败，文件不存在，命令直接炸。但 skill-creator 不是消失了。它只是被换成了另一个名字相近、功能也相近、但规则落后的版本。

表面上看，Hermes 还在正常工作；实际上一些关键约束已经没了。你很容易顺着别的方向排查：是不是模型今天状态差？是不是 provider 的输出风格变了？是不是上下文压缩把规则压没了？是不是我自己记错了？

我就是这么绕进去的。半小时里，我重启 session、换 provider、查配置，最后才发现不是模型变笨，是我调好的 skill 被 curator 收走了。

更烦的是，这半小时里我还顺手写了三个不合格的 skill，全部得返工。

还有一个很讽刺的点：我优化过的 skill-creator 里面，明明写了”重要 skill 需要 pin 保护”。

我自己写的规则，我自己忘了执行。

怎么查、怎么救

先看坟场：

1

ls ~/.hermes/skills/.archive/

如果 skill 已经进去，先救回来：

1

hermes curator restore skill-creator

但这只是把它从坟场拖出来。下次 curator review，它仍然可能被判断成”可归档”。

真正要做的是 pin 住：

1

hermes curator pin skill-creator

然后验证一下：

1
2

cat ~/.hermes/skills/.usage.json | python3 -c "import json,sys; d=json.load(sys.stdin); print(d['skill-creator'].get('pinned'))"
# → true

这一步不要省，尤其是你自己调过的 skill。

restore 解决的是”现在能不能用”，pin 解决的是”下次会不会又被收走”。这两个动作不是一回事。

哪些必须 pin

我现在会优先 pin 这几类：

• skill-creator：低频，但一旦失效，后面写出来的 skill 会断崖下跌
• para：文档治理规范，丢了以后落盘路径会乱
• cronjob-operations：定时任务总控，缺了它就容易把 cron 配错
• hot-news：热点新闻规范，事实核查标准不能丢

我的判断标准很简单：只要一个 skill 是你花时间调过的，而且不是每天都会用，就应该 pin。

高频 skill 反而没那么危险，因为 curator 容易看到它被使用。真正危险的是那些”平时不用、用时必须准”的 skill。它们在系统里看起来最像可以被清理的冗余项，也最容易被清错。

这个标准不需要搞得太复杂。你可以先从两个问题开始：

1. 这个 skill 我是不是亲手改过？
2. 它失效之后，会不会污染后面一串输出？

如果两个答案都是”是”，就别等它出事。

不是 Hermes 变笨了

这件事我一开始真的以为是 Hermes 变笨了。

后来发现不是。

curator 本身不是 bug。skill 用久了肯定会膨胀，如果没有整理机制，最后上下文里全是旧规则、重复规则、半成品 skill，agent 反而更难判断该听谁的。

问题在于，LLM review 对”重要但低频”的东西判断不稳。它能看到两个 skill 都在写 skill，也能看到其中一个最近没怎么用；但它看不到你为了那个版本改过多少细节，更看不到它一旦被归档，后面的输出质量会掉多少。

我的建议很直接：别把 pin 当成可选项。

凡是你认真打磨过、但不一定高频使用的 skill，先 pin 住。否则哪天 Hermes 突然开始”退化”，你可能会先怀疑模型、怀疑配置、怀疑上下文。

最后才发现，它只是把你最重要的工具，安静地收进了坟场。

On June 7, 2021, NASA’s Juno spacecraft flew closer to Jupiter’s ice-encrusted moon Ganymede than any spacecraft in more than two decades. Less than a day later, Juno made its 34th flyby of Jupiter.

Music by Vangelis.

人类很渺小，宇宙之大。

看著這些114年前的照片，搭配著配樂與旁白解說，不禁讓人感嘆歲月如梭、時光飛逝。那一幕幕繁華場景，如今已成昨日雲煙，落寞之感油然而生。

照片中的街道、建築、人群，無不透露出當年蓬勃的氣息。繁榮的當下被鏡頭定格，成為永恆的見證。

感恩當年拍攝者的用心記錄，讓我們這些後代子孫得以一窺百年前的真實面貌，體會那曾經的當下。

影片時長約11分鐘，檔案大小約204MB，建議在Wi-Fi環境下觀看。