U.U.UNIT

人人都该有一台 Mac Mini

如果只能给家里添一台电脑，我会选 Mac mini。它没有屏幕、没有键盘，一块银色的铝合金小方砧，往桌面一放，安静得仿佛不存在。但它是我家里唯一一台全年不关机的电脑——早报、电影、文件、量化、AI，全都靠它。这台机器的过人之处不在个头，而在它一直在。这篇文章不聊配置跑分，聊一台 Mac mini 到底能化身多少角色，以及我拿它实际在跑什么。角色一：常驻个人助理笔记本会合盖、云服务要订阅，只有一台始终开机的台式机才能做到"随叫随到"。Mac mini 最被低估的用法，就是当常驻助理。每天雷打不动的早报。早上 8:30，它自动聚合当天的天气、A 股/美股行情、黄金、影视上新、全网热榜，生成一份早报推到手机。人还没起床，信息已经排好队等着。所有"每天要做的小事"都能丢给它。链接收件箱定时扫描、追剧提醒并进早报、网盘待办自动同步。写成 cron 交给它，你只管偶尔翻一眼结果。 AI 助理 24 小时在线。我在 mini 上跑了一个 AI Agent（Hermes），挂着 Telegram 和微信，随时语音或文字下指令：查数据、发文件、生成图片、读文章。它不是"帮我定个闹钟"的 Siri，而是能真正调 API、跑脚本、改文件的干活型助理——下班路上微信说一句，家里的电脑已经开始干活。本地语音合成。配合 macOS TTS 或本地模型，整本电子书也能合成人声，音色稳定、不烧钱、断网照样听。一句话：别人给电脑打工，我给 Mac mini 派活。角色二：家庭数据中心 Mac mini 的本质，是一台带图形界面的低功耗服务器。文件中心：SMB 全屋共享，WebDAV 挂到手机和电视，再配一个 FileBrowser——浏览器就是客户端，任何设备零安装访问。媒体中心：配合 Plex 就是私人 Netflix。电影、剧集、音乐全库管理，自动刮削海报、匹配字幕，下载、转码、重命名一条龙。秒级文件搜索：家里的硬盘攒了几年，文件已到七百万级。用 fd 建索引 + SQLite FTS5，任何文件名 22 毫秒搜出结果，比 Spotlight 还快，还开了个网页版给全家用。角色三：开发沙盒想折腾自建服务，Mac mini 是最省心的沙盒。 Colima + Docker Compose：数据库、网盘工具、监控，docker compose up 一把梭，不污染宿主机。本地量化：A 股数据抓取、回测、持仓追踪，定时跑，盘后自动生成报告和情绪指数。本地 AI：本地大模型、图像生成、语音克隆，数据不出家门。我在这台 mini 上还挂了十几个内网小网站——任务看板、量化仪表盘、海报墙、文件书架，一个端口一个服务，妥妥的个人数据中心。 ...

夜航西飞：一个深夜歌单的选曲笔记

凌晨一点的高速公路上，车灯切开黑暗，仪表盘泛着冷蓝光。这时候你不能听太吵的，也不能听太安静的——太吵破坏夜的氛围，太安静让人犯困。你需要一种介于梦和清醒之间的声音。这就是我做《夜航西飞》这个歌单的起点。主题：从霓虹到月光 22 首歌，不是随机堆叠，而是一条情绪曲线——从城市的霓虹，逐渐驶向荒野的月光。前半段是发动机的轰鸣和路灯的残影，后半段是星空和沉默。整体横跨四个维度：Synthwave 的机械浪漫、Dream Pop 的模糊温暖、Ambient 的空旷辽远、Trip-Hop 的暗黑质感。它们共享同一种气质——夜行的、孤独的、但不悲伤的。选曲思路第一段：霓虹（1-8）歌单的开场是 Kavinsky 的 Nightcall。这首歌因为电影《Drive》封神，但它本身就是一个完整的夜间驾驶场景：失真的合成器、低沉的男声、那种"我刚从某个地方离开，正在往无人的方向开"的感觉。紧接着 Chromatics 的 Kill for Love 和 Night Drive——同一支乐队，两种速度。Kill for Love 是心跳节奏，Night Drive 是轮胎压过路面的节奏。 A Real Hero（College & Electric Youth）是这一段的情绪顶峰，合成器铺满整个声场，像城市灯火在挡风玻璃上碎成光斑。然后 Cigarettes After Sex 的 Apocalypse 把速度降下来——它的混响吉他像雾气一样弥漫，从霓虹过渡到更私密的空间。 Slowdive 的 Alison 和 Cocteau Twins 的 Heaven or Las Vegas 是 Dream Pop 的两块基石。Alison 是 1993 年的歌，但听起来像未来的记忆——吉他音墙厚而不重，人声漂浮在中间，像深夜电台里偶尔收到的一个信号。Heaven or Las Vegas 更明亮一些，Elizabeth Fraser 的声音本身就是一种光。 Massive Attack 的 Teardrop 收束这一段。它有一个史上最著名的鼓机 loop，但真正让你入迷的是 Elizabeth Fraser 的人声（对，又是她——从 Cocteau Twins 到 Massive Attack，她的声音贯穿了这条线）。这首歌属于 Trip-Hop，但放在深夜歌单里，它的功能是"着陆"——从霓虹的漂浮状态，落到一个更实的地面上。 ...

给 28 首老歌建 Apple Music 歌单：从 AppleScript 卡死到 web API 绕过

手头有一份《音乐天堂》老合辑《穿过骨头抚摸你》的 28 首歌单，想原样搬进 Apple Music。听起来是个小事：建个歌单、逐首加歌、搞定。结果这一路踩的坑，值得单独写一篇。第一回合：AppleScript 全线超时 macOS 上操作 Music.app 最正统的方式是 AppleScript： tell application "Music" to make new playlist with properties {name:"穿过骨头抚摸你"} 结果等来的是： execution error: Music got an error: AppleEvent timed out. (-1712) 不只是建歌单——get count of playlists、get name of every window，所有需要读写库的操作全部超时，而 GUI 完全正常：主页加载完整、账号已登录、还能正常播放。这是典型的"引擎活着、库通道死了"。排查：真凶是 AMPLibraryAgent 用 lsof 顺着打开的文件摸，发现 AMPLibraryAgent（Apple Music 云库引擎）正锁着 Library.musicdb，进程状态 sleeping、0% CPU，已经挂机 30+ 小时。它持有写锁不释放，Music.app 的任何库写入都在等它——等不到，就超时。试过的手段： # 1. 重启 Music.app killall Music && open -a Music # 2. 杀 AMPLibraryAgent（launchd 会自动拉起新的） kill 89124 # 3. 连辅助进程一起清 + 清缓存 killall -9 Music AMPLibraryAgent MediaLibraryService AMPArtworkAgent rm -rf ~/Library/Caches/com.apple.AMP* # 4. sudo 清系统级守护域 sudo launchctl kill -9 gui/$(id -u)/com.apple.AMPLibraryAgent 全都不解。新拉起的 AMPLibraryAgent 继续锁库，AppleScript 继续超时。Gemini 的建议也只是确认了这是 macOS 14/15 上 AMPLibraryAgent 与本地 SQLite 死锁的已知问题，常规 kill 无效是因为 IPC 通道没释放。 ...

FlareMo 上手体验：不买服务器，一个免费 Cloudflare 账号就把笔记系统跑起来了

写上一篇《自部署一个 Memos：FlareMo 上 Cloudflare Workers 全记录》时，重点全在踩坑和补丁上。这篇换个角度：FlareMo 到底是个什么东西、免费额度够不够用、日常用起来是什么体验、适合谁不适合谁。 FlareMo 是什么一句话：一个免费 Cloudflare 账号就能 24 小时跑在云端的个人笔记系统，Memos 兼容，应用层 Better Auth 登录，数据存 D1（5GB 数据库）+ R2（10GB 对象存储），代码和前端跑在一个 Worker 上。传统自部署长这样：一台 VPS、一个 Postgres、一堆 Docker 容器、每周要维护的备份脚本，还有硬盘坏了数据全没的风险。FlareMo 想回答的问题是：能不能只用一个免费 Cloudflare 账号，不买服务器、不装数据库、不写备份脚本，就拥有一个 24 小时在线、数据不会丢、能绑自定义域名、还能被各种工具调用的笔记系统？答案是能。整套东西跑在一个 Worker 上，你没有一个"服务器"要照看，只有一份代码和一个免费账号。免费额度到底够不够用很多人一听"免费"就觉得是玩具。实际上对个人笔记这种纯文本为主的场景，免费额度是溢出的： D1 5GB：一条笔记含标签时间戳索引开销算 2KB，能存约 250 万条，每天写 100 条能写 68 年 R2 10GB：约 5000-10000 张压缩图片，或者 80 小时语音备忘录；R2 出口流量不收费，分享图给别人不产生流量账单我的实际体感：写了大半年，数据库用量连零头都没到。免费额度不是"很快就会撞到的天花板"，而是"你大概率永远用不完"。为什么放 Cloudflare 比放 NAS 稳自部署还有一个常被低估的成本：数据的物理安全。NAS 数据在自家硬盘上，硬盘会坏、电源会跳、家里可能漏水被盗。FlareMo 的数据在 Cloudflare 企业级基础设施上持久化，自带冗余，你不用买第二块硬盘、不用写定时备份、不用关心 SMART 报警。另外它天然附带了一堆自部署很难凑齐的东西：全球边缘节点、免费 HTTPS + 自定义域名（我绑了 memo.uuunit.com，证书自动续）、不用 frp / Tailscale / 公网 IP 打洞、零运维——没有系统补丁、没有数据库升级、没有进程看门狗。 ...

自部署一个 Memos：FlareMo 上 Cloudflare Workers 全记录

一直在用 Memos 记碎片想法，但官方 Server 要自建 VPS，维护成本不低。直到发现 FlareMo——一个把 Memos 完整跑在 Cloudflare Workers 上的开源项目，D1 存数据、R2 存附件、Vectorize 做语义搜索、Workers AI 做嵌入，全部免费额度内。部署地址 memo.uuunit.com，iOS 用 MoeMemos 客户端无缝接入。这趟从部署到客户端跑通踩了六个坑，值得记录。坑一：孤立仓库不能 pull，只能 reset 仓库是从 GitHub 上拿到的快照，本地只有一个根提交，和上游没有共同祖先。这意味着 git pull / git merge 必然冲突，升级的正确姿势是： git branch backup-v0.6-snapshot # 旧版快照分支 git fetch origin --tags git reset --hard v0.14.0 # 目标 release tag 但 reset 会把 wrangler.jsonc 一并覆盖——本地真实 D1 ID（da6ec409-...）和 FLAREMO_PUBLIC_URL 全丢。所以升级前先备份本地敏感文件，reset 后重新应用数据库 ID 和公网地址，再 commit 一次防止下次更新再丢。坑二：Vectorize 索引不会自动创建新版引入了语义搜索，上游 wrangler.jsonc 里声明了 Vectorize binding，但不会自动建索引——不手动创建，部署直接失败： unset CLOUDFLARE_API_TOKEN CF_API_TOKEN # 必须 unset，否则走 API token 模式不是 OAuth npx wrangler vectorize create flaremo-memos --dimensions=1024 --metric=cosine npx wrangler vectorize create flaremo-memories --dimensions=1024 --metric=cosine 维度必须和嵌入模型匹配（默认 qwen3-embedding-0.6b = 1024 维 cosine）。还有一个隐藏雷：Vectorize V2 的 returnMetadata 参数要求字符串枚举 "all" | "indexed" | "none"，上游代码传的是 V1 的布尔 false，语义搜索直接 500 Internal server error，要手动改成 "none"。 ...

拆解一支万宝龙：从笔帽浮雕到活塞上墨

最近做了个万宝龙笔的专题页，从官网和公众号收集资料，整理品牌历史、制笔工艺和各系列背景。这篇记录一下制作过程和要点。项目地址： http://camac-macmini.local/montblanc/ 项目概况项目数据内容万宝龙品牌历史 + 制笔工艺 + 8 个系列专题配图 15 张官网高清产品图 + 公众号细节图来源万宝龙官网 + 公众号文章部署本地 HTTP 服务内容结构品牌历史时间线从 1906 年柏林创立，到 1910 年「万宝龙」之名诞生、1913 年六角白星标志定型，再到 1924 年大班系列、1992 年大文豪系列，梳理了 120 年的品牌脉络。制笔工艺 10 步详解金料熔炼 → 笔尖冲压 → 手工打磨 → 铱粒焊接 → 开缝研磨 → 镌刻雕花 → 笔杆车削 → 活塞组装 → 总装调校 → 书写测试各系列背景大班：1924 年诞生，149 被称为「笔中王者」星际行者：太空舱笔帽 + 悬浮标志设计传承系列：1909 年首款 Rouge et Noir 复刻大文豪系列：1992 年海明威首发，至今 34 款斯托克：吸血鬼之父、《德古拉》背景法拉利联名：驱动理念 + 木纹设计罗密欧与朱丽叶：七夕企划双笔配色配图来源本次配图分两类： ...

《内观》电子书网页版是怎么做的

读《内观——葛印卡的解脱之道》时记了几百段读书笔记，一直想让这些内容能公开分享、随时随地读。于是把它做成了一个多页 HTML 电子书网页版。项目已收录 → 项目页：《内观》电子书网页版这个项目挺有代表性——一本书变成一个可交互的阅读站，中间踩了不少坑。这篇复盘完整记录做法。项目概况项目数据书籍《内观——葛印卡的解脱之道》（威廉·哈特）输出 28 页 HTML 静态站配图 657 张（AI 生成 + 压缩）金句音频 506 条（本地 TTS）书评 33 条（微信读书）域名 vip.uuunit.com 托管 Cloudflare Pages 总大小 175MB（含音频）全流程 1. 内容提取 & 结构化先解决源头问题：内容从哪来？ EPUB：本质是 zip 包，里面是 HTML 文件。用 Python 解压 → 正则去标签 → 纯文本 Obsidian 笔记：读书时已经按段拆分了 546 段，格式是 ### {章节}-{段号} {标题} 用正则 r'### ([\\d]+)-([\\d]+) (.*?) — (.+)' 把笔记解析成结构化 JSON，每章一个文件。 ...

Hugo 部署 Cloudflare 的踩坑记录

最近把 Hugo 博客部署到 Cloudflare Pages，看着简单，结果踩了一堆坑。记录一下，给后面的人省点时间。坑一：主题文件别手写一开始图省事，手动推了个简化版 PaperMod 主题到仓库。结果功能不全、CSS 缺失、搜索用不了。正确做法：构建时直接拉官方主题，别自己维护一份。 git clone --depth 1 https://github.com/adityatelange/hugo-PaperMod.git themes/PaperMod 坑二：HUGO_VERSION 必须和主题匹配 PaperMod 要求 Hugo >= 0.146.0，但 Cloudflare 默认可能是老版本。解决：在 Cloudflare Pages 环境变量里指定版本。 HUGO_VERSION = 0.146.0 坑三：TOML 语法别用 YAML 的写法 minify: 这种冒号写法是 YAML 的，TOML 要用 [minify] 表头。Cloudflare 用的是标准 TOML 解析器，一个字符错就整个构建失败。 [minify] disableXML = true 坑四：代码块要标注语言 Markdown 代码块如果不标注语言，Hugo 可能渲染异常。目录结构这种用 text： project/ |-- file1.py +-- file2.py 坑五：域名要加到 Pages 白名单光在 DNS 配 CNAME 不够，Pages 项目本身也要把域名加进去，否则不响应请求。坑六：构建日志看不到 Cloudflare Pages 的构建日志 API 不开放，只能网页上看。构建失败时，把日志贴出来就能定位。 ...

一份 Markdown 三套皮肤

痛点每次写网页报告，样式和内容糊在一起。改个颜色要重新生成全文，换风格等于重写。更烦的是，内容写在一个专有编辑器里，换个工具就迁移不了。解决方案：拆两层内容层只管写什么——Markdown 文件，带 YAML 头信息。样式层只管长什么样——独立的 HTML 模板，用 {{变量}} 占位符接收内容。中间一个渲染脚本串起来，输入 MD 选模板，输出成品 HTML。具体实现目录结构 ~/.hermes/ |-- scripts/ | +-- render_page.py |-- templates/ |-- default.html |-- dark.html +-- magazine.html 模板文件是独立 HTML，用 {{title}}、{{content}}、{{toc}} 等占位符接收内容。想加新模板？写一个 HTML 丢进 templates/ 就行，脚本自动识别。使用方法 python3 ~/.hermes/scripts/render_page.py 文章.md python3 ~/.hermes/scripts/render_page.py 文章.md -t dark python3 ~/.hermes/scripts/render_page.py 文章.md -t magazine 文章格式每篇文章开头加 YAML 头信息： --- title: 标题 date: 2026-08-06 description: 一句话描述 --- 正文内容... 配合 Obsidian 使用设置软链接 ln -s ~/Documents/Obsidian/Blog /path/to/hugo/content/posts 写作流程在 Obsidian 里写文章，存到 Blog/ 文件夹用标准 Markdown，不要用 [[双向链接]] 图片用 ![alt](path) 语法保存后 Hugo 自动就能读到发布流程 hugo git add . && git commit -m "新文章" && git push Cloudflare Pages 自动构建上线。 ...

Mac mini 远程控制 Sidecar 的三种方案

把 iPad 当 Mac 的第二块屏幕，Sidecar 是苹果官方方案。但如果你用的是 Mac mini（没有自己的屏幕），远程 SSH 进去想控制 Sidecar 就没那么简单了。折腾了一圈，最后能用的一共三套方案。三种方案对比方案原理响应速度可靠性 SidecarLauncher (主力) 调用 Apple 私有 SidecarCore.framework 框架 ~1s ✅ 极高 Hammerspoon AX (备选) 遍历系统设置界面 AX 元素，模拟点击 ~3s ✅ 高 computer_use (备选) 通过 cua-driver 在后台操作 UI ~5s ✅ 中方案一：SidecarLauncher（推荐）用 Swift 直接调用 Apple 的私有框架，不需要任何 GUI 交互，秒级响应，有线优先自动走无线。 sidecar status # 查看连接状态 sidecar on # 连接（有线优先） sidecar off # 断开 sidecar devices # 列出可用设备已封装成 shell 函数加到 ~/.zshrc： ...