优客李李

技术笔记：十年前的 Flask 网站静态化，搬到 Cloudflare 免费托管

Thu, 05 Nov 2026 00:00:00 +0000

这是一份给自己看的完整记录：以后再改这个站、或者把别的老站也这么搬，先读这篇。网站是很多年前帮一个实验室做的，下文只叫“这个站”，不写名字和域名。动手的是 Mac mini 上的 Claude Code，我负责拍板和点确认。

结论速览

项目	之前	之后
托管	AWS Lightsail 一台服务器，只跑这一个站	Cloudflare Workers 静态资源，免费
花费	半年 $35.65，月均 $5.94，一年约 $71	服务器费 0；只剩域名注册费
技术栈	Python 2.7 + Flask 0.12 + Apache，Ubuntu 16.04（2021 年就停止维护）	Python 3.12 + Flask 3 导出静态文件；后台只在本机跑
更新频率	一年改 2 次左右	不变，改完 `make publish` 半分钟上线
大文件	S3：研究页视频 + PyMOL 下载，26 个文件 362MB	视频进站点；17 个下载文件放 R2（免费额度 10GB）
时间	当年开发 2 个月，之后部署、更新数据、2.0 加后台写教程，一直有维护成本	静态化一天做完
代价	—	国内直连变慢（实测见后文），我接受了

这台服务器为了稳定，我没让它跑任何别的服务。一年改两次内容，每个月照交 6 美元。这笔钱早该省。

为什么能静态化

先把“动态”的部分列清楚，才知道能不能搬：

部分	原来怎么做	静态化后
6 个页面	Jinja 模板 + 查 SQLite 渲染	导出成 HTML
10 个研究子页	`/research/<名字>` 渲染对应模板	逐个导出
3 个 JSON 接口	`?selectedItem=…`、`?selectedTag=…`、`?tag=…` 查询字符串	改成路径参数，每个地址导出成一个 `.json` 文件
后台	Flask-Admin，Basic Auth，线上直接改	原样保留，只在本机运行
页面缓存	Flask-Cache，后台提交后清缓存	删掉

访客这边没有表单、登录、搜索，全是只读。这就够了。数据也小：论文 221 条、结构 105 个、成员 55 人，数据库 164KB，图片 39MB。

导出

没用 Frozen-Flask，自己写了 88 行的 freeze.py，用 Flask 的 test_client 逐个请求再写文件。原因：

想让 /people 写成 people.html，托管平台会自动把 /people 对应过去；Frozen-Flask 默认写成没有扩展名的文件。
带查询字符串的接口导不出来，得先改路由。

接口改法：

/current_structure?selectedItem=5GMK  →  /data/structure/5GMK.json
/orientation_tag?selectedTag=…        →  /data/orientation/0.json   （按页面上的顺序编号）
/current_event?tag=Fun Time           →  /data/event/fun-time.json

方向名里有空格和 β，不适合当文件名，所以用序号。前端两个 JS 文件各改一两处请求地址。

导出时顺便写两个托管平台认的文件：

_redirects   /index → /，以及一个旧栏目地址跳到新栏目
_headers     /static/* 缓存 1 天；/data/* 缓存 10 分钟

_headers 是上线后补的：Workers 静态资源默认 max-age=0, must-revalidate，浏览器每张图都要回去问一次有没有更新，结构页几十张缩略图就是几十个来回。旧服务器是缓存 12 小时。

Python 2 → 3

代码量不大（不算数据约 700 行），但几处会静默出错：

问题	表现	改法
`zip()` 在 Python 3 返回迭代器	模板遍历一次就空了；`json.dumps` 序列化失败	包一层 `list()`
`r.encode('utf-8')`	方向名变成 `b'…'` 写进页面	删掉
`flask.json.dumps(…, cls=…)`	Flask 2.3 起忽略 `cls`，自定义编码器不生效，报 `Category is not JSON serializable`	改用标准库 `json`
SQLAlchemy 2 的单列查询返回 `Row`	不是 tuple，编码器不认	`[list(r) for r in rows]`
自定义编码器用 `dir(obj)` 扫字段	SQLAlchemy 2 多出 `registry` 等属性	改成只取 `mapper.column_attrs`
`__unicode__` 里写着 `self.name`，但模型没有 `name`	Python 2 时没被调用到；Flask-Admin 在 Python 3 会调用 `__str__`	改成真实字段
Flask-Admin 2 只剩 Bootstrap 4	24 个自定义后台模板里用的 `label label-info`、`well` 失效	换成 `badge`、`card`
全局一个 session，本地开发服务器是多线程的	偶发错乱	`scoped_session` + `teardown_appcontext` 里 `remove()`
数据库路径写死 `/home/<用户>/…`	换机器就找不到	改成相对项目目录

还翻出一个老 bug，是我当年埋的。结构页第 4 个标签名里有希腊字母，标签文字经过 HTML 解码（β → β），而传给接口的名字列表没解码，两边对不上。原来靠服务端写死了一个兜底才显示出来。静态化后兜底没了，问题就暴露了。改成解码后再比较。

验收：和线上逐行对比

改之前先把线上站存了一份快照：7 个页面、12 个研究子页、112 个 JSON 接口（每个结构一个）。导出后逐个对比：

19 个页面去掉空白后逐行一致；
112 个 JSON 内容一致（忽略原来编码器多吐出来的值为 null 的关联字段）；
无头浏览器点一遍：结构页 4 个标签加起来 23+36+18+28=105 个结构，和数据库条数一致；点开详情有图有字；实验室活动 3 个标签正常；
手机 375、平板 768、桌面 1400 三种宽度截图，列表页和线上像素级一致。

后台在临时副本上测，正式数据没碰：15 个栏目新建、编辑、删除；结构图上传后主图裁成 500×500、自动生成 100×100 缩略图；删记录连文件带缩略图一起删；媒体文件上传删除；再用真实浏览器点一遍新建论文的表单（年份是 select2 下拉框），存进去、前台论文页能看到。

部署：Workers 静态资源

本来打算用 Cloudflare Pages。新版 wrangler（4.157）跑 pages project create 时，会转去建一个 Worker，没给静态目录就直接失败。Pages 已经并进 Workers，现在推荐的是 Workers 静态资源，免费额度一样，_redirects、_headers、404 页都支持。

{
  "name": "<worker 名>",
  "compatibility_date": "2026-11-01",
  "routes": [{ "pattern": "<域名>", "custom_domain": true }],
  "workers_dev": false,
  "preview_urls": false,
  "assets": {
    "directory": "./build",
    "html_handling": "auto-trailing-slash",
    "not_found_handling": "404-page"
  }
}

API Token 需要的权限（第一个下拉框先选 Zone 还是 Account，选错了就找不到后面的项）：

范围	权限	用途
Account	Workers Scripts · Edit	部署
Account	Workers R2 Storage · Edit	建桶、传文件、绑域名
Zone（只选这几个域名）	DNS · Edit	改记录（注意不是 DNS Settings）
Zone	Workers Routes · Edit	绑自定义域名
Zone	Dynamic URL Redirects · Edit	跳转规则

Token 只有 Pages 权限时，wrangler 读不到账户 ID，要手动给 CLOUDFLARE_ACCOUNT_ID。

日常用 Makefile 包起来：

make admin     # 本机打开后台改内容
make publish   # 导出 → 部署 → 把数据库和图片提交并推到 GitHub

publish 里加自动提交，是因为内容（数据库、图片）也在仓库里。之前要手动提交，忘了的话 GitHub 上的“备份”其实是旧的。我肯定会忘。

S3 搬到 R2

S3 上的视频和下载文件开着防盗链：只放行 Referer 是本站 https 的请求。所以直接 curl 是 403，带上 Referer 就能下，不需要 AWS 密钥：

curl -H "Referer: https://<域名>/" -o 文件 "https://s3.<区域>.amazonaws.com/<桶>/<路径>"

9 个视频（1.5–4.7MB）直接放进站点。文件名里的 + 改成 _，免得 URL 里有歧义。
17 个 PyMOL 文件（最大 47MB，超过 Workers 静态资源单文件 25MB 的上限）放 R2，绑子域名 files.<域名>。上传用 wrangler r2 object put --remote，传完逐个下载算 SHA-256，和 S3 原件一致。

绑完自定义域名，前一分钟有几个文件返回 403，等边缘节点同步后就好了。

域名

换 nameserver

Cloudflare 里 Add a site → Connect a domain，自动导入 DNS 记录。导入后先把指向旧服务器的记录改成灰色云朵（DNS only）：旧服务器自己做 http→https 跳转，Cloudflare 有的 SSL 模式用 http 回源，两边叠在一起可能无限跳转。改成灰色，切换前网站照旧由旧服务器提供。

坑：每个域名分到的 nameserver 不一定是同一对。我在 GoDaddy 批量给两个域名填了同一对，其中一个一直 pending，查 API 才发现它分到的是另一对。

切换

删掉主域名的 A 记录，紧接着用 API 绑 Worker 自定义域名（证书自动签）。还缓存着旧记录的访客继续去旧服务器，旧服务器还开着，所以没有中断。

只做跳转的域名：根记录指向占位地址 192.0.2.1 并开代理，再加一条 301 规则，请求在 Cloudflare 边缘就被跳走，不回源。规则里的目标地址：

保留路径：target_url.expression = concat("https://<主域名>", http.request.uri.path)
固定地址：target_url.value = "https://…"     ← 写成 expression 会报 Filter parsing error

注册商

同一个 .com，GoDaddy 续费 $22.99/年，Cloudflare 按成本价 $11.17/年（11 月 1 日刚从 $10.46 涨上来），每年差 $11.82，差不多一半。转入要先在 Cloudflare 上 active，再在 GoDaddy 解锁、拿授权码；转入时付 1 年，加在原到期日后面，不浪费。转移完成前别改注册人信息，会被锁 60 天。

国内访问

这是唯一变差的地方。2026-11-05 下午，同一条家庭宽带，直连各请求一个 2KB 的 logo：

	成功	平均耗时
Cloudflare 免费版	17/20，3 次超时	4–8 秒
旧服务器（AWS 美国俄亥俄）	10/10	0.9 秒

拆开看，建立 TCP 连接 0.27 秒，和 AWS 差不多；慢在之后时不时卡 3–5 秒，像丢包重传。海外访问反过来会更快。我看完数据，决定接受。不回滚。要国内快，只能备案走国内 CDN。

另外 *.workers.dev 在国内整个被封：DNS 解析出错误地址，连真实 IP 也会在 TLS 握手时被重置。测试地址只能挂代理看；绑自己的域名后不受影响。这个测试地址后来也关了（workers_dev: false）。

顺手：博客图床收回仓库

2020 年写过一篇用用 Amazon S3 + uPic 搭图床。那个桶里 44 张图，博客引用了 39 张，一共 3.3MB。我早忘了当年的 key 和 secret。好在图本来就是公开的，直接下载就行，不需要密钥。放进仓库 img/markdown-img/，10 篇文章和关于页的链接改成站内路径。后来的文章本来就直接把图放 /img/。

想看桶里全部文件但没有密钥时，用 AWS 控制台右上角的 CloudShell，它用当前登录身份：

aws s3 ls s3://<桶> --recursive --summarize | tail -3

让 AI 动手时的分寸

我被 Claude Code 的安全检查拦下过两次：删正式域名的 DNS 记录、把 R2 桶公开到子域名。它拦得对，这两步都对外、不好撤。我看过它列出的改动清单和回滚办法后，回一句“确认”它才执行。还有一次它想借另一把 Token 去查账户 ID，也被拦了：那把 Token 是给别的服务续证书用的，不该挪用。

踩坑记录

zsh 里 URL 带 ? 不加引号会被当通配符，命令直接报 no matches found。
zsh 不会按空格拆变量，set -- $r 拿不到多个参数，校验脚本因此全判“异常”。
本机经代理访问 Cloudflare 每个请求要 1–2 秒，无头浏览器连看几个带视频的页面后，下一个页面会卡住超时；交互测试要单开页面。
Workers 静态资源单文件上限 25MB。
页面引用的 Google Analytics 是 2023 年就停止收数据的旧版 UA 代码，还拖慢加载，删了。

还没做的

观察一两周后删 S3 桶、关旧服务器；然后清掉指向旧服务器的测试子域名记录和仓库里的 deploy/ 目录。
晚高峰的国内速度没测，估计只会更差。
另外 10 个防御性注册的 .com 还在 GoDaddy，到期前再决定转不转。

Mac mini 家庭服务器：一句话搭好一个工作台，项目已开源

Sat, 31 Oct 2026 00:00:00 +0000

家庭服务器，听起来很极客，好像是程序员专属的玩具；但在大模型爆发的时代，它其实适用于每一个家庭。因为我们部署、管理和维护等代码工作，正是当今大模型最擅长的事之一。我把自己踩过的坑做成了一个开源项目，让 AI 一句话就能搭好一个工作台。　

我家这台是 Mac mini。我在买 Mac mini 之前其实考虑了很久——我已经有一台 mbp 了，多一台电脑，我能用得过来吗？但买了之后，我发现是越用越爽。因为一台家庭服务器的核心是7x24不间断运行。这就意味着你随时想用什么服务，它都会随时给你回应。而且随着时间的推移，自动化服务自然会越来越丰富——这是个不断跟随自己成长的设备，是一种资产。这是它目前的样子：

上面一共 10 个服务。Mac mini 上 7 个：电影库、本地视频生成、配音、本地大模型、写这个公众号用的工作台、投资记账、字幕；旁边的 NAS 和树莓派上还有 3 个：群晖后台、n8n 和 Home Assistant。

家庭服务器是什么

说白了，就是家里一台 24 小时开着的电脑，上面跑着你自己的常驻服务。

家庭服务器能干的事包括且不限于：

用途	常见的服务	能帮你做什么
影音	Jellyfin	下好的电影自动配海报，电视、投影仪、手机都能看
相册	Immich	手机照片自动备份，能按人脸、地点、以图搜图
密码	Vaultwarden	全家的密码库，Bitwarden 的各种客户端都能连
广告过滤	AdGuard Home	全家设备一起去广告
自动化	n8n、Home Assistant	定时抓资讯发到手机；坐久了桌子自己升起来
AI	Ollama 等	本地跑大模型，聊天、生成都不出这台机器

还有一些服务不需要后台，但其实也非常适合部署。比如我现在用得最多的，是 Paseo。它是 Claude Code、Codex 这类编码 Agent 的控制台：Agent 常驻在 Mac mini 上跑，我随时随地都能连上去看进度、接着下指令，电脑启动的会话，手机能继续，反之亦然——彻底解除了多设备会话同步问题。现在 AI 能在多台设备之间长期稳定地干活，靠的就是它。它的好处，下期详细讲。

家庭服务器用什么机器好？我的看法是：

Mac mini 最合适。功耗低、安静、长期开机没问题，Apple 芯片还能跑本地 AI。
NAS 适合放数据。服务装太多，它会吃力。
树莓派适合跑一两个轻量的，比如 Home Assistant。
闲置的 Linux 电脑也可以，算次选。

服务一多，麻烦就来了

我遇到的是这 4 个麻烦：

地址记不住。每个服务一个端口，8096 是电影，8190 是视频生成，8123 是智能家居……10 个，根本记不住，每次都要翻笔记。
浏览器报“不安全”。家里的服务默认是 http，有的功能（比如录音、复制）在不安全的页面上还用不了。
想在外面用，又怕暴露。在路由器上开端口最简单，但等于把家门开在公网上，扫端口的机器人一天到晚都在找这种门。
挂了不知道。哪个服务停了，往往是要用的时候才发现。

工作台：一个入口管理所有服务

我的解法是给这些常驻服务做一个工作台。它其实就 4 件事：

每个服务一个名字：jellyfin.你的域名.com、ha.你的域名.com，不用再记端口。
正规证书：浏览器有小锁，自动续期。
只有你能打开：别人就算知道地址，也连不上。
一个仪表盘：每个服务在不在线，机器的 CPU、内存、磁盘、温度，一眼看完；每天再自动体检一次。

维护起来也简单。所有服务写在一份清单里，加服务就是加一行，域名、证书、卡片、体检都跟着自动更新。

在外面访问的几种办法

“只有你能打开”，局域网肯定没问题，关键要看从外面怎么连回家。常见的有这几种：

方式	怎么连	谁能访问	要注意
公网 IP + 端口转发	路由器开端口，DDNS 跟着 IP 变	全世界	很多家宽没有公网 IP；暴露在公网，安全全靠服务自己
内网穿透（frp、花生壳等）	借一台中转服务器	默认全世界	速度看中转；多数要付费
Cloudflare Tunnel	家里主动连 Cloudflare	全世界，可以加登录	国内访问不稳定；不适合传视频
Tailscale / ZeroTier	你的设备组成一个虚拟局域网	只有你登录的设备	每台设备要装一个 App

如果服务只给自己和家人用，我推荐最后一种。我用的是 Tailscale，个人免费版目前能加 6 个用户，设备数量不限。在家时它自动走局域网直连，出门在外也能连回来。远程桌面也靠它搞定了。

我的推荐：一个只有你能打开的专属网址

在 Tailscale 上再加一个自己的域名，就是一套很舒服的方案：

环节	用什么	花费
域名	任意注册商买的域名，DNS 交给 Cloudflare 管	非`.com` 的域名巨便宜
解析	一条泛解析，指向服务器的 Tailscale 地址	免费
证书	Let’s Encrypt，用 DNS 验证	免费
入口	Caddy，按域名把请求转给各个服务	免费
连接	Tailscale	个人免费

效果是：我打开 mini.uulili.com 就是工作台，点进去每个服务都有自己的地址和SSL小锁。这个域名公开解析，但解析到的是 Tailscale 里的地址，不在我 Tailscale 网络里的设备，想连也连不上。

homelab-desk：让 AI 一句话搭好

工作台项目叫 homelab-desk，已经在 GitHub 开源，MIT 协议：

GitHub 项目地址

https://github.com/shisaq/homelab-desk

它做这几件事：

部署总览：读你的服务清单，生成 Caddy 配置、申请证书、只放行 Tailscale、装成开机自启的后台服务。可以重复执行，改了清单再跑一次就行。
实时仪表盘：每个服务在不在线、响应多快、近 1 小时的记录；机器的 CPU（每颗核都有）、内存构成和压力、磁盘、网络，装了插件还有温度、GPU、UPS。
选风格：4 套主题，每套都有深浅两种，样子见下一节。
推荐服务：内置一份目录，影音、相册、密码、广告过滤、自动化、AI、下载、阅读等，共 30 项。每项写清适合谁、怎么装、放到反向代理后面要注意什么。
每天体检：检查每个服务和证书剩余天数，可以接到自己的通知渠道。

上面我踩过的坑，项目里都处理掉了。比如监听 443 的限制，它会改成按来源只放行 Tailscale；在线检测放在服务器上做，避开浏览器的跨域误判；Home Assistant 这类要额外配置的服务，目录里直接写明。

顺手做了不同的风格

工作台总共 4 套主题：玻璃、苹果的液态玻璃、简洁、终端，每套都有深浅两种，页面右上角随手切。

怎么用

把项目克隆下来，把里面的 skill 链接给 Claude Code 或 Codex，然后对它说一句：

对 Claude Code 或 Codex 说

帮我用 homelab-desk 搭一个家庭服务器工作台

它会检查前置条件，带你在 Cloudflare 建 Token、建 DNS 记录，部署，最后验收。以后想加服务，也是一句话：

以后加服务

把 Immich 加进来

不想用 AI 的，也可以手动跑 init、doctor、dns、deploy 4 条命令。

为什么不做成 Docker？Mac 上的 Docker 跑在虚拟机里，拿不到 Tailscale 地址，也读不到宿主机的温度和 GPU。项目本身只有 Caddy、一个 Python 小服务和一个静态页面，原生跑更简单。你的服务装在哪都行，装在 Docker 里的也一样，项目只认“地址:端口”。

市面上的 Homepage、Homarr、Dashy 管的是导航页面，Uptime Kuma 管监控。homelab-desk 管的是从零到能用的整条链路。已经在用它们的，也可以把它们当成一个服务加进来。

适合谁

已经有一台常开的 Mac，上面跑着几个服务：直接用。
用 Linux 的小伙伴：适配代码已经写好，但还没在真机上验证过，欢迎测试反馈。
还没有服务器的：可以先从上面那张表里挑一两个你想要的服务，一台 Mac mini 就能跑起来。
想把服务公开给朋友、不装 Tailscale 直接用浏览器打开的：这个项目不负责这件事。那需要一台公网服务器和用户管理，安全问题就够你喝一壶的了。

前置条件是 3 样：一个托管在 Cloudflare 的域名，装好并登录的 Tailscale，以及 Claude Code 或 Codex（手动部署则不需要）。

总结一下：家庭服务器的价值在那些服务，工作台让你管得过来。项目地址再放一次，求个星星：

GitHub 项目地址

https://github.com/shisaq/homelab-desk

用的时候遇到问题，欢迎留言或者在 GitHub 上提。衷心希望你的负债少少，资产多多。

博客版补充

工作台上的几个服务，博客里有单独的实测：

本地大模型：小钢炮 Mac mini 跑 27B，最快 35 token/s
本地视频生成（H3 Studio）：Mac mini 跑 AI 视频：内存占多少，生成要多久？
配音（TTS 调音台）：技术笔记：Mac mini 本地微调 Qwen3-TTS 声音

本文首发于微信公众号「像素李的AI笔记」：原文链接。博客版保留了文中的外链，和公众号版不同的地方都标了“博客版”。

技术笔记：Mac mini 本地微调 Qwen3-TTS 声音

Thu, 29 Oct 2026 00:00:00 +0000

这是一份给自己看的完整记录：以后再训练新的声音、或者在新对话里接着改，先读这篇。代码都在 qwen3-tts-console（网页在根目录，训练流程在 finetune/）。文中两个被训练的人称为说话人 A、B。

结论速览

项目	数值
机器	Mac mini，M5 Pro，64GB；GPU 最多能用 51.8GB（81%）
起因	10 秒参考音频的零样本复刻，音色和口音不像本人
素材	A：6 段视频约 24 分钟 + 1 段 23 分钟对话；B：13 段视频约 42 分钟 + 同一段对话
自动处理	约 90 分钟素材，十几分钟切完、转写完、筛完人
人工复核后	A 165 段 / 18.0 分钟；B 361 段 / 38.9 分钟（复核用时约 1.5 小时）
训练（1.7B，10 轮）	A 17 分钟，B 37 分钟，内存峰值约 39–41GB
声纹相似度	A：0.72 → 0.84；B：0.57 → 0.82（零样本 → 最好的一轮）
错字率	所有版本都低于 1%
上线	A 用第 8 轮，B 用第 10 轮；生成 5 秒语音约 2 秒，加载 0.5 秒，每个模型约 3GB
低内存	0.6B 冻结 20 层：峰值 10.6GB，相似度 0.83，推算 16GB 机器能跑

整体结构

视频 ─(先自己提取音频)─▶ wav
  ─ prep_data.py   FunASR 转写 + 切 2–10 秒 + CAM++ 筛人      （.venv：torch + funasr）
  ─ review.py      网页复核：听、改字、保留/丢弃              （同上）
  ─ build_train.py Qwen3-TTS-Tokenizer-12Hz 编码成语音 token  （.venv-train：qwen-tts + torch）
  ─ sft.py         在 Base 模型上微调，存成 custom_voice 检查点（同上，MPS）
  ─ gen_samples.py 每一轮转成 MLX 8bit，和零样本一起生成样音   （网页的 venv：mlx-audio）
  ─ score_samples.py 相似度、错字率、语速；对比页靠耳朵挑       （.venv）
  ─ ttsd 的 tuned_voices 配置 ─▶ 网页“我的音色”里出现

3 个 Python 环境是故意分开的：FunASR、qwen-tts、mlx-audio 各自钉了不同版本的依赖，混在一起容易打架。测试过的版本：funasr 1.4.16、modelscope 1.40.2、qwen-tts 0.1.1、torch 2.14.1；mlx-audio 用网页 requirements.txt 里钉的提交。

网页本身（ttsd）是一个 Python 单文件服务，用 launchd 常驻、Caddy 反代，模型用 mlx-audio 跑 8bit 量化版，空闲 10 分钟自动卸载。

数据准备

转写：FunASR，不是 Whisper

AutoModel(model="paraformer-zh", vad_model="fsmn-vad", punc_model="ct-punc", spk_model="cam++")：

Paraformer-zh：中文识别准，给每个字的时间戳。1.8 分钟音频转写 12 秒。英文单词经常拼错（Gartner → garten），以英文为主的片段直接丢弃（字母数多于汉字）。
fsmn-vad / ct-punc：断句和加标点。
CAM++：声纹。实测同一个人的片段 0.72–0.75，不同人 0.08–0.36，两个人的参考录音之间 0.31。阈值：≥ 0.55 保留，0.45–0.55 待定，更低丢弃。主持人、插话、对话里的另一方都靠它去掉。

一个 FunASR 1.4.16 的 bug：sentence_info 把每个标点放晚一个字（“开发者。大家好，很高兴”变成“开发者大。家好很，高兴”），按它切片段会在词中间断开。完整文本 text 和逐字时间戳 timestamp 是对的，所以自己重切：按 [A-Za-z']+|标点|单个汉字 分词，词数和时间戳数一一对应（实测完全对得上），遇到标点断句，说话人标签取时间上重叠最多的 sentence_info 段。

切片规则

同一说话人、间隔 ≤ 0.5 秒的句子合并成 2–10 秒的片段；够 4 秒且遇到句号就提前断开。
前后各留 0.08 / 0.15 秒，但不越过相邻句子的中点。
有声部分响度统一到 -20 dBFS，峰值不超过 -1 dBFS。
噪声底取整段音频 50ms 帧能量的 10% 分位，下限 -90 dB（合成或降噪过的音频会出现数字静音，不设下限信噪比会显示成 150 多）。
同一事件的两个剪辑版本会有重复句子：文本相似度 > 0.8 且来自不同文件的，保留信噪比高的那段。
自动标记：英文、语气词（呃嗯额）、重复/口误、连串中文数字，复核时优先看。
英文术语统一大小写（ai → AI、gpt → GPT），产品名的误识别放进配置的 terms。

人工复核

改动写进 edits.json（按片段 id），重跑数据准备不会丢。A 的 198 段里改了 55 段文字（29 段错别字、19 段英文词、7 段只动标点），丢掉 33 段。B 的 469 段改了 109 段、丢掉 108 段，用时约 1.5 小时。我的感受是自动识别已经很准，只有少数断句不对。

训练脚本：官方 sft_12hz.py 的 4 处问题

先用没训练过的 Base 模型在真实片段上算损失：设置正确时损失应该很低，因为预训练模型本来就能预测真实语音。第一次冒烟测试损失 7.5，接近瞎猜（词表 3072，均匀分布约 8.0），才去对照推理代码排查：

设置	talker 初始损失	子模型初始损失
官方脚本	11.9	9.1
标签只错位一次	7.9	–
再加 `text_projection`	1.2	–
子模型用上一帧隐藏状态、损失不再错位	–	5.4

标签错位两次（QwenLM/Qwen3-TTS#179）：talker 的 HF 损失内部会错位一次，脚本又手动 [:, 1:]。模型学成预测隔一帧的 token，症状是越训语速越快。改法：输入和标签都不切片，让损失函数自己错位。
漏了 text_projection：推理时所有文字向量（角色标记、tts_pad/bos/eos、正文）都先过 talker.text_projection，训练脚本直接用了 text_embedding 的输出。维度都是 2048，不报错，模型一直在学推理时见不到的输入。
子模型也错位两次：forward_sub_talker_finetune 返回的 logits 已经和 codec_ids[:, 1:] 对齐，内置损失又错一位；而且推理时 code predictor 拿到的是“预测出这一帧的那个位置”（t−1）的隐藏状态。改法：hidden[:, :-1][codec_mask[:, 1:]] 配 codec_ids[:, 1:][codec_mask[:, 1:]]，自己算不错位的交叉熵。
bf16 存权重：学习率 2e-6 时，AdamW 每步的更新量小于 bf16 能表示的精度，大部分被舍入掉。改成 fp32 存权重、bf16 autocast 计算。

其他设置：学习率 2e-6，5% 预热 + 余弦衰减，batch 2 × 梯度累积 4，梯度裁剪 1.0；说话人向量取 64 个训练片段声纹的平均（比单条参考录音稳），写进 codec_embedding 的第 3000 行；检查点按 bf16 保存，tts_model_type 改成 custom_voice，spk_id 只有这一个人。

训练数据用的是不带语言标签的前缀（nothink），所以生成时语言要用 auto，指定 chinese 会切到模型没见过的前缀。Base 模型从没学过指令，微调出来的声音不支持语气描述。

内存：第一次跑进了交换

全量训练 1.6B 参数（文字嵌入层也训练）时占 44GB，第 2 轮存检查点时额外复制一份权重，系统开始用交换内存，每步从 1.2 秒变成 15 秒。改了 3 处：

冻结文字嵌入层：3.11 亿参数、15 万个词元，18 分钟录音只用得到几百个。省约 4GB，也少一点过拟合（细节见下一节）。
存检查点时逐个张量先搬到 CPU 再转 bf16，存完 torch.mps.empty_cache()。
冻结的参数改存 bf16（不更新，不需要 fp32）。

之后 1.7B 全量稳定在 37–41GB，每步 1.2 秒。

冻结文字嵌入层，有没有隐患

冻结不是去掉这一层：它照常参与计算，只是训练时不更新，保持 Base 模型原来的值。

它管什么。 talker.model.text_embedding 是一张 151936 × 2048 的查找表，每个词元一行，只回答“这是哪个字”。后面决定“这个人怎么念”的部分都在训练：

部分	形状 / 规模	训练时
`text_embedding`（认字）	151936 × 2048，3.11 亿参数	冻结
`text_projection`（把文字向量翻译给说话模型）	两层 2048 × 2048	训练
talker 28 层（怎么念、语调、节奏）	约 14 亿参数	训练
`codec_embedding`（声音编码、说话人向量所在）	3072 × 2048	训练
code predictor（每帧后 15 层声音编码）	约 1.7 亿参数	训练
speaker encoder（只用来算说话人向量）	–	冻结

为什么数据少时冻结反而更稳。 不冻结的话，嵌入层每步只有训练文本里出现过的那几百行拿到梯度（AdamW 对梯度为 0 的行几乎不动），训练完“见过的字”和“没见过的字”在模型眼里慢慢变得不一致：换一句新话，可能有的字像他、有的字不像。冻结后 15 万个词元保持原样、彼此一致。

精度没有损失。 Base 模型发布的权重本来就是 bf16（text_embedding 和 text_projection 都是），冻结部分用 bf16 存，和原始权重逐位相同；保存检查点时本来也存 bf16。

真正的局限。 冻结的嵌入层不能给一个词“换身份”。如果某个词他的读法很特别（产品名的固定念法、方言里某个字的读音），只能靠后面 28 层按上下文去学；多数情况够用，但如果训练后某个词还是固定念错：

先在稿子里换写法：同音字、拆开、加空格，最省事；
数据多了（一两个小时）再训练时加 --train_text_embedding，多占约 4GB。新语言、新方言也属于这种情况。

证据的边界。 支持“认字没受损”的：微调后所有版本在训练集外的句子上错字率都低于 1%，包括 AI Agent、RPA 这类英文词，相似度也正常提升。没做过的：冻结和不冻结的严格对照。两个上线的音色都是冻结后训练的，不冻结的版本只跑过 1 轮（内存爆了），所以“两者效果一样”没有直接数据。要确认的话：同一份数据、batch 1 打开文字嵌入层训练 6 轮，对比相似度、错字率，再专门听几个专有名词。

怎么判断像不像

Qwen 自带的声纹编码器不能用来评估：零样本复刻和参考录音的相似度 0.991，可另一个男声也有 0.974。8bit 和 bf16 的复刻都是 0.991（我听也没区别，所以线上留 8bit）。
用 CAM++，比对本人 40 个真实片段的平均声纹，不是单条参考录音。
训练集外的 5 句话 × 2 个随机种子，每个版本 10 条样音；另外看转写错字率和语速（真人约 5 字/秒，语速明显变快就是错位问题）。
分数是和训练录音比的，录音环境（麦克风、房间）也可能被学进去，最后靠耳朵挑。对比页把同一句话的各个版本放在一起。

结果

训练 2 轮就有大部分提升；之后基本持平。
训练误差到第 10 轮降到 0.1–0.2，开始背答案：A 的第 10 轮分数回落，个别样音有一声咔哒。所以每 2 轮存一版。
A 的第 8、10 轮又各加测 8 句 × 3 个种子：0.815 对 0.827，打平。最后都是我听种子 11 那一组挑的：A 用第 8 轮，B 用第 10 轮，另一轮留作备用。

低内存方案

训练 6 轮效果就够用了。同样 A 的 18 分钟录音，batch 1 × 累积 8，在 64GB 机器上实测：

模型 · 设置	峰值	用时	相似度
1.7B 默认（batch 2，10 轮训练的第 6 轮）	约 39GB	约 10 分钟	0.842
1.7B 冻结 20 层	18.2GB	7 分钟	0.804
1.7B 冻结 24 层	15.6GB	6 分钟	0.785
1.7B 冻结 26 层	13.6GB	5.5 分钟	0.789
0.6B 不冻结	16.1GB	7 分钟	0.808
0.6B 冻结 14 层	11.9GB	5 分钟	0.827
0.6B 冻结 20 层	10.6GB	5 分钟	0.829

只改 batch 1 几乎不省（35.6 → 33.3GB），内存大头是被训练参数的权重、梯度和 Adam 状态（fp32 每参数 16 字节）。

macOS 不会把全部内存给 GPU：这台 torch.mps.recommended_max_memory() 是 51.8GB（81%）。按同比例推算（偏乐观，小机器比例可能更低，芯片也更慢；都没实测）：

机器	GPU 约可用	推荐	还剩
64GB	52GB	1.7B 默认	约 13GB
48GB	39GB	1.7B 冻结 20 层（默认正好贴着上限）	约 21GB
32GB	26GB	1.7B 冻结 20 层	约 8GB
24GB	19GB	0.6B 冻结 14 层	约 7GB
16GB	13GB	0.6B 冻结 20 层	约 2GB

0.6B 冻结一部分层，分数反而比 0.6B 全量高一点；每组只有 10 条样音，±0.02 以内算误差，0.6B 也还没用耳朵对比过。

部署

# 选好的一轮转成 MLX 8bit，放进模型目录
python -m mlx_audio.convert --hf-path <ckpt>/epoch-8 --mlx-path ~/Models/qwen3-tts/tuned/<id>-e8-8bit -q --q-bits 8

~/.config/ttsd/config.json：

"tuned_voices": {
  "<id>": {"name": "显示名·微调", "model": "tuned/<id>-e8-8bit", "speaker": "<id>", "gender": "m", "lang": "zh"}
}

speaker 必须和训练时的 --speaker_name 一致。改完 launchctl kickstart -k gui/$(id -u)/<label> 重启，再用 API 建一个临时稿件生成一句验证，删掉稿件。

ttsd 的改动：音色 id 是 tuned:<id>，每个微调音色单独占一个模型槽；生成时语言固定 auto、不传语气；网页里归到“我的音色”，选中时语气框变灰。

踩坑记录

Safari 点播放没声音、下载正常：网页用 Web Audio 播放，服务端和代码都没问题，重启 Safari 就好了。播放失败目前不提示，以后可以加一个报错。
ttsd 的 safe_id 只认十六进制：微调音色 id（如英文名）会被判无效，音色不出现。改成“必须是配置里已有的 key”，新加的单元测试抓到的。
说话人 key 要用英文：它会变成模型里的 speaker id 和目录名。开源版强制 ASCII。
HF 下载卡在最后一步：文件已经下完（大小对得上），卡在校验改名。临时文件名里就是 sha256，自己算一遍对上了再 mv 到位。
pkill -f 误杀：杀下载进程时的匹配串，也出现在另一个等待下载的后台命令里，把它一起杀了。按 PID 杀更稳。
zsh 不按空格拆变量：set -- $var 在 zsh 里不拆分，循环参数要写开或用数组。
mlx-audio 会读 sys.argv：自己的脚本用命令行传模型路径，被它当成了模型名。改成写在脚本里。
MPS 上声纹编码器的 dtype：模型是 bf16 时，mel 输入要转成同样的 dtype。
截图脱敏：截图前在页面里用 JS 改名、删掉真人内容；复核页用系统音色合成的演示数据重跑一遍再截。Playwright 渲染图表时，font-family 里的双引号会截断 HTML 的 style="…"，字体就变回默认衬线体。

复现

最短路径（2026-10-29 加的 run.sh / deploy.py，视频文件可以直接放进素材文件夹，非 wav 的用 ffmpeg 解码）：

cd finetune && cp voiceprep.example.json voiceprep.json   # 填好后
./run.sh prep                 # 切片 + 转写 + 筛人，完成后打开复核页
./run.sh train alice          # 编码 → 训练 → 样音 → 打分；小内存加 --epochs 6 --batch_size 1 --grad_accum 8 --freeze_layers 20
./run.sh review               # /compare/alice 挑一轮
./run.sh deploy alice 8 --name "显示名" --gender m --restart <ttsd 的 launchd label>

deploy 会把模型复制进控制台的 models_dir/tuned/，备份后改 tuned_voices（speaker id 从检查点里读），可选重启。逐步手动跑：

cd finetune
cp voiceprep.example.json voiceprep.json      # 说话人、参考录音和文字稿、素材目录
.venv/bin/python prep_data.py
.venv/bin/python review.py                    # 127.0.0.1:18410，无登录，只在本机开；远程用 ssh -L
.venv-train/bin/python build_train.py alice
.venv-train/bin/python sft.py --train_jsonl <work>/alice/train_with_codes.jsonl --speaker_name alice \
    --output_dir <work>/alice/ckpt --epochs 10 --save_epochs 2,4,6,8,10
#   小内存：--batch_size 1 --grad_accum 8 --freeze_layers 20 [--init_model_path Qwen/Qwen3-TTS-12Hz-0.6B-Base]
../.venv/bin/python gen_samples.py alice
.venv/bin/python score_samples.py alice       # 然后打开 /compare/alice 听

还没验证的

16GB / 24GB / 32GB 机器上的真实内存和速度（都是按 64GB 的峰值和 81% 推算的）。
0.6B 微调版的听感；网页目前默认按 1.7B 的预设/克隆模型加载，0.6B 微调版能转换、能生成，但没上线。
更多数据（几小时）能不能继续提高；10 秒以内的片段占比对口音的影响。

Mac mini 内存买多大？M6、M5 Pro 选购这篇就够了

Tue, 20 Oct 2026 00:00:00 +0000

选购 Mac mini 的关键是什么？CPU 已经同级别碾压了，存储空间后期还可以自己加；但内存是焊死在主板上的，而内存的大小跟它作为服务器的用途息息相关。

买小了，以后想跑的模型放不下，只能换机器。买大了，妥妥的杀鸡用牛刀。而不同的配置，差价就有上万元。如果你也想买一台，内存买多大、芯片怎么选、大概要花多少钱？

下面先给不同用途的推荐配置，完整的配置表和价格表放在文末。

先看推荐

只当家里的服务器，不跑大模型：16GB。M6 16+512 8,499 元，甚至 M4 二手 3,000–4,000 元。
想试试本地模型：M6 32GB，9,999 元起。27B 能跑但很慢；MoE 模型快，写文章够用，但整体质量不及稠密模型。
想把 27B 当日常用，聊长对话：M5 Pro 48GB，19,749 元。
还要同时挂别的服务，或者以后想试更大的模型：M5 Pro 64GB，20,499 元起。
2 万上下，更看重速度：Mac Studio 起步款 19,999 元，比 mini 64GB 还便宜，但内存只有 36GB。预算到 2.7 万，Studio 64GB 比 mini 64GB 更值。

用途确定后，硬盘选 512GB 就够，256GB 实在太小。更大的容量不必一步到位，省下的钱后面自己加外置硬盘，或者找专业机构改造内置硬盘。

本地模型我就拿现在最火的 Qwen3.8-27B 举例了，引擎是 oMLX。我这台是 M5 Pro 64GB，余量最充足，模型在不同设置下实际占多少内存，都能测出来。其他档位我没有真机，是拿实测的内存峰值去算的；M6 的速度用的是公开的实测数据。

本地模型内存占用参考

27B 4-bit（Q4）短对话：峰值 17.2GB
27B Q4 聊到 160K 上下文：峰值约 38GB
27B 8-bit（Q8）短对话：峰值 29.0GB

这只是模型这一个进程。macOS 自己、浏览器、后台服务也要占内存。所以要拿总内存减掉模型峰值，看剩下的够不够其他程序日常使用。

内存不够时，Mac 会把一部分内容挪到硬盘上（swap），程序不会马上崩。看着能跑。但我不把这算“能用”。频繁 swap，服务器就不稳定了。

个人本地服务器最佳选项：16GB

16GB 内存的机器不要考虑本地大模型。它的定位很清晰：本地服务器。

我这台长期挂着 Hermes（AI 助手，16GB 上就只用云端模型）、Jellyfin（家里的影音库）、Syncthing（几台设备之间同步文件），16GB 跑这些没压力。

其他适合长期挂着的还有这些：

Time Machine：家里其他 Mac 自动备份到这台。系统自带，在共享设置里把一个文件夹设成备份目的地就行。备份吃硬盘，一般外接一块容量充足的盘。
AdGuard Home：在 DNS 这一层拦广告和追踪域名，路由器指过来，全家设备都生效。它只按域名拦，不是所有广告都能去掉。
FreshRSS：自己的 RSS 阅读器，手机和电脑共用一份已读状态。
Paperless-ngx：合同、发票、说明书扫进去，自动 OCR，以后按字就能搜到原件。一次导入一大堆旧文件时，OCR 会有峰值。

FreshRSS 和 Paperless-ngx 一般用 Docker 跑，要多开一个 Linux 虚拟机。Docker Desktop 默认给它的内存上限是主机的一半，16GB 机器就是 8GB。所以一项一项加，OCR、视频转码这种有峰值的活错开时间。

这一档芯片不重要。M6 16GB 的带宽是 153GB/s，比 24GB、32GB 款的 170GB/s 还低一点，但当服务器用不到这个差别。二手 M4 也够。

既然舍去了本地大模型，这个档位适合思路清晰，锁定云端大模型的玩家。既有云端顶级大模型加持，又有7x24随时响应的个人服务器，还能省下一大笔钱。

值得一提的是，虽然 M6 起步款比 M4 当年的 4,499 元贵了 2,500 元，但这颗 2 纳米的芯片是实打实的厉害。

本地模型：M6 32GB

先算内存。27B Q4 短对话峰值 17.2GB，32GB 还剩 14.8GB。放得下。聊到 160K 要约 38GB，已经超过总内存，上下文只能收短（推算）。

再看速度。模型每输出一个 token，大致都要把权重从内存里读一遍，所以输出速度跟内存带宽关系很大。M6 是 170GB/s，M5 Pro 是 307GB/s，差了 1.8 倍。

M6 我没有真机，查了别人的实测，都是 32GB 款跑 Qwen3.8-27B 4-bit：

一位德国网友在 GitHub 公开的测试（LM Studio，GGUF 格式）：写英文、德文段落每秒 11–12 个 token，写代码 17.5 个
一个视频评测（直接用 MLX）：每秒 8–9 个

我这台写 300 字是每秒 25.9 个。引擎、格式都不一样，不能严格对比，但差距在 2 倍以上，比带宽差得还多。M6 只有 12 核 GPU，我这台是 20 核，可能也有关系（我猜）。

按每秒 10 个左右的速度，偶尔问几句可以，当日常主力偏慢。所以 27B 在 M6 32GB 上仅限于能跑。日常使用基本劝退。

想在 M6 上跑得快，可以换 MoE 模型。MoE 总参数大，但每输出一个 token 只用其中一小部分，要读的权重少，对带宽要求就低得多。

拿 Qwen3.6-35B-A3B 的 4-bit 版来说。M6 32GB 上有两份别人的实测；我这台也用 oMLX 跑了同一个模型的 4-bit 版，提示词类型和参数照着 GitHub 那份测试来：

短输入（德语、英语、代码、JSON）：M6 每秒 63–69 个 token，我这台约 110 个，是 M6 的 1.6–1.7 倍
读入约 2 万 token 的资料后：M6 每秒输出 58.5 个，我这台 80.4 个；读入速度 M6 每秒 1,215 个，我这台 2,176 个

带宽差 1.8 倍，短输入的速度差跟它很接近。

本机内存测试如下：

短输入：峰值约 21.5GB
读入 2 万 token：约 23.7GB
读入 6.5 万 token：约 24.7GB
读入 13 万 token：约 27.0GB

全程没用 swap。MoE 读长资料，内存涨得很慢。拿 32GB 去减（推算）：短输入剩约 10GB，2 万 token 剩约 8GB，13 万 token 只剩 5GB。日本那位用户报的是 19.7GB，比我测的低一些，可能是统计口径不同。

所以 M6 32GB 跑 MoE 4-bit，长资料也读得进去，剩 8–10GB 给系统，开开浏览器、日常办公可以。但模型只能开这一个，再挂 Docker、影音库这类服务可能就得错开用了。

当然 MoE 也有代价。在我这台 mini 上，它每秒约 110 个 token，是 27B 的 3–4 倍；可 35B-A3B 每个 token 只激活约 3B 参数，质量会比 27B 差一些。我就怕它一直输出低质量的内容，擦屁股的工作更不好做。所以我日常还是用 27B。如果你更追求速度，Mac 系统还是首选 MoE 吧。

还有一个选项是 M5 Pro 24GB，12,999 元。芯片虽然更快，可内存比 M6 32GB 还少 8GB，27B Q4 短对话剩 6.8GB，再开几个程序就吃紧了。只看本地模型，这一档有点尴尬。

天天用 27B：M5 Pro 48GB 起

如果天天用本地大模型，免不了聊长对话、丢长资料进去。这时内存要按 160K 算：

48GB：聊到 160K 剩约 10GB 给系统和其他程序，能跑，不算宽裕
64GB：剩约 26GB（本机实测峰值）

M5 Pro 各档带宽都是 307GB/s，48GB 款的输出速度应该接近我这台：回“你好”每秒 35.8 token，写 300 字每秒 25.9 token（48GB 是推算）。

想跑 MoE 4-bit 也宽裕：读入 13 万 token 峰值约 27GB，48GB 还剩 21GB。

同时挂别的服务：64GB

这是我这台的配置：M5 Pro，18 核 CPU / 20 核 GPU，64GB 内存。它同时挂着 Hermes、Jellyfin 和本地视频生成 MiniMax H3。

我给模型进程设了 48GB 的上限，剩下 16GB 留给系统和其他服务。就算这样，模型和 H3 也不能同时跑。模型约 38GB，H3 约 22GB，合计约 60GB，留给系统的余量太少。我实测过，只能错开用。

所以 64GB 也不是什么都能一起开。错开用，都放得下。

我为什么买 64GB？买一台就打算用很久，而内存无法改。

苹果生态在 AI 上发展得很快，很多本地模型，生文字、生图、生视频、生声音，方向都是在保证质量的基础上尽量压缩体积。内存越大，越能有入场券。另外它还要跑日常任务，我不希望频繁出现内存爆满、swap 的情况，否则服务器就不稳定，不能被称作服务器了。

2 万上下：Mac mini 还是 Mac Studio

到了 2 万这个价位，Mac Studio 跟 Mac mini 是一个价了：

Mac mini M5 Pro 48GB+1TB：19,749 元，带宽 307GB/s
Mac Studio M5 Max 36GB+512GB：19,999 元，带宽 460GB/s
Mac mini M5 Pro 64GB+512GB：20,499 元，带宽 307GB/s

Studio 起步款比 mini 64GB 还便宜 500 元。它是拿 Max 芯片换掉了一部分内存：带宽高 1.5 倍，内存只有 36GB。跑 27B Q4 短对话剩 18.8GB，速度应该会比我这台快；但聊到 160K 要约 38GB，放不下。所以天天聊长对话，还是 mini 48GB、64GB 合适；主要是短问短答，又想快一点，Studio 起步款更划算。

预算再往上，差别就更明显了：

Mac mini M5 Pro 64GB+1TB：22,749 元，带宽 307GB/s
Mac mini M5 Pro 64GB+2TB：27,999 元，带宽 307GB/s
Mac Studio M5 Max 64GB+512GB：27,499 元，40 核 GPU，带宽 614GB/s
Mac Studio M5 Max 128GB+512GB：39,499 元，带宽 614GB/s

同样 64GB+512GB，Studio 比 mini 贵 7,000 元，换来 2 倍带宽和更好的散热。跟 mini 64+2TB 比，便宜 500 元，带宽是 2 倍，只是硬盘小了 1.5TB。硬盘可以外接，带宽加不了。预算到了 2.7 万，又主要为了本地模型，Studio 64GB 更值。

现在想想，如果不考虑体积，或许 128GB 的 Studio 也是更好的选择，散热更好，空间更足。苹果自己的芯片也在往前走，我猜愿意再等等的话，后面的芯片大概率更适合本地模型。只是这些都是等待成本。人生百年，等来等去，不如早买早享受。

当然我的现状其实不止是用本地大模型，云端模型总是更香的。除非你清醒地认为本地模型足以胜任你的本地工作，否则最好还是不要妄想买了 Mac mini 后，从此就能离开云端模型。

硬盘：够用就行，后面外接

硬盘不像内存，可以后面加。用途定了，内置盘选够用的就行。

跑本地模型要留空间。只当服务器的话，512GB 就够，影音、备份放外置盘。256GB 实在太小，系统就能吃掉一大块。如果买的是 256GB，我建议直接改造内置硬盘，内置盘比外置盘稳定。改造要找专业机构，可能会影响官方保修。我觉得还是直接 512GB 保险一些。

官网加硬盘的价格不低：M6 32GB 从 256GB 加到 1TB 多 3,750 元，M5 Pro 64GB 从 1TB 加到 2TB 多 5,250 元。这笔钱可以先省下来，后面按需要买外置硬盘。我这台选 2TB，是因为我日常工作上要备份大量视频。只跑模型、当服务器，其实用不着 2TB。

配置表和价格表

价格是 2026 年 10 月的国行官网价，没算双十一活动。M4 官网已经不卖，写的是闲鱼二手价。

这台 Mac mini 之前的实测：

《小钢炮 Mac mini 跑 27B，最快 35 token/s》：本地大模型怎么配、跑多快
《Mac mini 跑 AI 视频：内存占多少，生成要多久？》：本地跑 MiniMax H3 生成视频
《两台电脑持久同步文件，不占我的 iCloud 空间》：16GB 那一档提到的 Syncthing

手上有 M6 32GB、M5 Pro 48GB 或 Mac Studio 的小伙伴，欢迎在评论区留下你的实测速度。还想让我拿这台 mini 测点什么，也欢迎留言。希望对你有帮助。

来源：

我这台的数据：Mac mini M5 Pro 64GB 实测，oMLX 跑 Qwen3.8-27B，见上一篇《小钢炮 Mac mini 跑 27B，最快 35 token/s》
Mac mini、Mac Studio 带宽和配置：apple.com.cn/mac-mini/specs、apple.com.cn/mac-studio/specs
M6 32GB 跑 27B（LM Studio，GGUF）：github.com/HDZucht/Mac-Mini-M6-LLM-benchmarks
M6 32GB 跑 27B（MLX，视频评测）：youtube.com/watch?v=7ugFOo8e8H4
M6 32GB 跑 MoE：github.com/HDZucht/Mac-Mini-M6-LLM-benchmarks、note.com/corestudio/n/n583c1b00f8ef
M5 Pro 跑 MoE 4-bit：我这台用 oMLX 0.7.0 实测，模型 mlx-community/Qwen3.6-35B-A3B-4bit（2026 年 10 月 20 日）
M6 2 纳米、6,999 元起：2026 年 8 月 25 日发布会报道（IT之家、新浪科技）；M4 Mac mini 国行 4,499 元起：2024 年发售价（IT之家）
16GB 服务器上的服务：Docker、AdGuard Home、FreshRSS、Paperless-ngx 官方文档

本文首发于微信公众号「像素李的AI笔记」：原文链接。博客版保留了文中的外链，和公众号版不同的地方都标了“博客版”。

小钢炮 Mac mini 跑 27B，最快 35 token/s

Sat, 17 Oct 2026 00:00:00 +0000

用云端 AI 久了，有件事一直让我分神：额度。5 小时有一个上限，一周还有一个上限，干到一半提示用完，只能等。挺烦的。网络不好的时候也会卡住。还有一些问题，我不太想发到云端，但也没别的办法。

所以这次我在家里的 Mac mini 上把本地大模型认真跑了一遍。图的就两点：token 自由，想用多少用多少；免审查，少被拒绝。

前后测了三天。能用，而且能 7×24 小时开着。对话聊到 13 万 token，回一句还是 3–4 秒。云端额度用完了，它自动顶上。

下面是怎么配、不同设置差在哪，还有如果你也想买一台，内存该怎么选。

我的机器和用法

Mac mini，M5 Pro，20 核 GPU，64GB 内存，2TB 硬盘。它平时是家里的服务器，还跑着 AI 助手、影音库和视频生成，模型不能把内存全占了。所以我给模型进程设了 48GB 的上限，超了就停。

模型用的是 Qwen3.8-27B，一个 270 亿参数的模型。引擎试了 oMLX 和 MTPLX 两个，最后留下 oMLX。

跑起来到底多快

日常用的感受是这样：

场景	等多久
已经聊了 13 万 token，再问一句	3–4 秒开始回答
聊到 21 万 token	4–7 秒
一次丢进去 1 万多字的新资料	几十秒到一分多钟
输出速度	每秒 20–27 个 token，短回答最快到 35.8

写这篇的时候，我又打开 oMLX 自带的网页对话测了一下。回一句“你好”，输出每秒 35.8 个 token，这是我见过最快的一次；让它写 300 字左右的介绍，每秒 25.9 个 token，从发出到写完一共 10.2 秒。

整个过程内存最高约 38GB，没有用到 swap。服务重启以后，之前的对话缓存还在，接着聊不用重新读。

这个速度能日常用。前提是开了一个设置：前缀缓存。

最关键的设置：前缀缓存

不开缓存的时候，你每问一句，模型都要把整段历史从头读一遍。聊到 6 万 token，每句要等 2–3 分钟。我第一轮测试测的是“一次读入 26 万 token 要多久”，结果是首字等了 18 分钟，差点得出“本地长对话没法用”的结论。

开了缓存，它只读新增的那部分。3–4 秒就是这么来的。

缓存比换量化、开加速都重要。这是我这次最大的收获。缓存我放在 SSD 上，上限 100GB，大约能存四五个聊满的长对话。

不同设置差在哪

4-bit 就够了

模型可以压成不同精度，位数越低越省内存。我拿 4-bit（Q4）和 8-bit（Q8）做了 63 道题的对比：

	结构化题	代码	内存峰值（短对话）
Q8	30/42	8/8	29.0GB
Q4	34/42	7/8	17.2GB

Q4 不比 Q8 差。代码少对了一题，工具调用两边都是 3/3。一次读入 26 万 token 时，Q4 每秒读 237 个 token，峰值 36.1GB；Q8 每秒 160 个，峰值 45.4GB。oMLX 对 4-bit 有专门的加速，所以 Q4 又快又省。我又让 Q4 连续跑了两小时，13 道题全对，内存一直稳在 36GB。

免审查版：能力一样，收益没测出来

免审查版和官方版我都压成了 Q4，同一套题，得分几乎一样，速度也一样（每秒 16.61 和 16.70 个 token）。

但我准备的几道敏感题，两个版本都正常回答了，免审查到底多帮了多少，这次没测出来。按模型作者的说明，它是“减少拒答”，不是“完全不拒答”，开思考模式时仍有约 8.7% 会拒绝。

MoE 模型：快，但吃内存

还试了一个 35B 的 MoE 模型，它每次只用到 3B 参数，所以快：短对话每秒输出 56 个 token，是上面配置的 3–4 倍。但 8-bit 版光权重就占 35GB 左右，峰值到了 47GB，长对话不稳定。在 64GB 上，我把它淘汰了。

照着抄的配置

引擎用 oMLX 0.7.0，模型是 Qwen3.8-27B 免审查版 4-bit。下面这些，左边是设置，右边是在 oMLX 里怎么写：

项目	设置	在 oMLX 里
前缀缓存	开，放 SSD，上限 100GB	启动参数 `--paged-ssd-cache-dir`、`--paged-ssd-cache-max-size 100GB`
MTP 加速	开	模型设置 `mtp_enabled: true`
思考模式	关	`enable_thinking: false`
上下文窗口	160K	`max_context_window: 163840`
内存上限	48GB	启动参数 `--memory-guard-gb 48`
同时处理	1 个请求	启动参数 `--max-concurrent-requests 1`
空闲卸载	30 分钟	`ttl_seconds: 1800`，下次约 4 秒重新载入

两个要注意的地方：

MTP 要先导入。 这个 4-bit 模型的 MTP 权重放在单独的文件里，oMLX 默认读不到，要用 oMLX 自带的导入功能（import_mtplx_sidecar）整理一遍。它会直接改模型目录，先用 cp -cR 复制一份。值得折腾：聊到 13 万 token 时，输出从每秒 10.6 个 token 提到 26 个。

4-bit 有专门的读入加速（oQ A8），大约快 1.4 倍，我是开着的。Q6、Q8 用不上。

这几个我试过，不建议开：

KV 缓存量化：读入和输出都慢了 2–3 倍。
ANE 预填充：反而慢了 30%，还多吃 16GB 内存，而且会顶掉上面的 oQ A8。
内存热缓存：直接把内存撑爆。
256K 窗口：能跑完，但贴着 48GB 的上限，没有余量。

我还把它接进了 AI 助手 Hermes，当作备用模型：云端限流、额度用完或者断网时，自动切到本地。代价是每开一个新对话，第一句要多等 20 秒左右，因为助手每次都要带上一大段说明，大约 1.4 万 token。之后就快了。

从哪儿用它

同一个模型，我从四个地方用。oMLX 同时提供 OpenAI 和 Anthropic 两种格式的接口，所以常见的工具都能接上。快慢差别不在模型，在于每次请求要先读多少固定内容：

入口	新对话第一句	适合做什么
oMLX 自带的网页对话	约 1.4 秒	纯聊天、写东西、不想上云的问题
Hermes（在微信、飞书里用）	约 20 秒	日常助手；云端不可用时自动切过来
Claude Code	约 35 秒	简单的编码，不想让代码离开机器时
Codex	约 54 秒	同上

同一个对话聊下去，各个入口都会命中缓存，差距就小了。不过说实话，27B 的 4-bit 模型做多文件的编码明显不如云端模型，我只拿它做简单的活。

笔记本上用也方便。我用 Tailscale 把它转到自己的设备上，只有我的设备能连，出门也能用。

能不能一直开着

能。但有几件事要知道。

耗电：推理的时候比空闲多耗 50–60W，峰值约 80W。模型闲着时几乎不额外耗电，30 分钟没用还会自动卸载。我平时大部分时间在打字，按每天累计推理一两个小时算，一年多用几十度电。

温度：芯片 1–2 分钟升到 75–77°C 后就不涨了，没有温控警告，也没降频。

硬盘：写入主要来自缓存，每 1000 token 新内容约写 140MB。很重度地用，一天约 28GB，一年 10TB 左右。主流 2TB 固态的标称写入寿命一般在几百 TB 以上，用十年问题不大。

不能和别的大任务一起跑：我这台还跑视频生成，峰值约 22GB，加上模型的 38GB 就超了，只能错开用。

如果你想买，内存怎么选

我只测了 64GB 这一台。下面除了 64GB，都是按实测的内存峰值推算的，只能当参考，买之前最好再看看同配置的实测。

内存	我的判断
64GB	实测：27B 4-bit、160K 长对话、同时跑其他服务都没问题，只是不能和视频生成这类大任务同时跑
48GB	推测：27B 4-bit 能跑，短对话峰值只要 17GB；但长对话到 160K 时模型峰值约 38GB，再给系统留余量就紧了，上下文可能要收短
32GB	推测：27B 4-bit 短对话可以试，长对话空间不多，也很难再同时跑别的服务；更现实的是换小一点的模型
24GB 及以下	推测：27B 这一档不太现实，建议直接选小模型

关于新出的 M6 Mac mini：苹果公布的配置最高 32GB 内存，所以按上面的推算，只能落在 32GB 这一档。新芯片快多少、引擎有没有为它优化，现在都没有实测，我不给结论。

我的取舍是：跑本地大模型，内存比芯片档位重要。芯片决定快慢，内存决定能不能跑、能聊多长。硬盘也别太小，缓存和模型都要占地方。

如果你主要用云端，偶尔想要个不限量、不出机器的备用，一台大内存的 Mac mini 现在已经能做到。希望这些数字对你选配置有帮助。

本文首发于微信公众号「像素李的AI笔记」，可在公众号内搜索阅读。博客版保留了文中的外链，和公众号版不同的地方都标了“博客版”。

Mac mini 跑 AI 视频：内存占多少，生成要多久？

Fri, 09 Oct 2026 00:00:00 +0000

如果准备买一台 Mac mini 跑本地 AI，内存选多少，估计是最纠结的地方。尤其是视频模型，光下载就上百 GB，很容易觉得机器也得配上百 GB 内存。

我在家里的 M5 Pro 64GB 上跑了一轮 MiniMax-H3。短片测试的内存峰值大多在 18.5–22GB，9 秒那次是 25.6GB；推荐参数生成约 2 秒的竖屏视频，要等 3 分钟左右。

所以，64GB 不是这次短片测试全部用得上的内存。但选配置也不能只照着 22GB 这个数买，系统、其他软件和 GPU 可用的内存还得一起算。下面把我实际跑过的结果列出来，给还没买机器的人一个参考。

用的是 Redis 作者 antirez 写的 h3.c，纯 C + Metal。文生视频、首尾帧和参考图都能用，还能一起生成声音。

先放两段生成效果：

（博客版：上面换成了带声音的原视频，公众号版放的是无声 GIF。）店员那段的“欢迎光临”说对了，不过也不是每次都这么顺利，下面说。

内存：64GB 用不满，小内存也不能直接照着买

Mac mini，M5 Pro，20 核 GPU，64GB 内存，2TB 硬盘。平时还跑着其他服务，测试的时候没停。你可能也想问：只是跑这个模型，需要买到 64GB 吗？

先看记录：

测试	记录的内存峰值
约 2 秒的短片，不同加速参数	18.5–22GB
9 秒竖屏视频	25.6GB

这些是生成过程记录的峰值，不是整台机器连系统和其他服务一起的总占用。这批测试没有用到 swap，64GB 确实有不少余量。在服务启动之前，余量在93%左右，跑服务的时候，余量仍可以保持在60%左右。

下载的模型体积和运行内存不是一个数。 h3.c 会分阶段加载不同部分；我这台 M5 跑的路径还会在加载时转成 int8。134GiB 的权重放在硬盘上，不代表同时要吃掉 134GiB 内存。

不过，还有个数要看：程序识别到这台机器的 GPU 推荐工作集是 51.8GiB。它表示 Metal 建议 GPU 同时使用的内存规模，不是模型已经占了 51.8GiB，也不是超过它就一定不能运行。Mac 用的是统一内存，但不能把包装上的 64GB 全当成 GPU 可以随意占满的空间。

这也是我没有直接写“24GB 就够”的原因。短片峰值已经在 18.5–22GB，9 秒那次到了 25.6GB；系统和后台程序还没算进去。换成小内存机器，原来这套参数还有没有余量，要重新验证。

如果现在让我为这套用法选内存，我会这样考虑：

内存配置	按这次测试怎么考虑	有没有实测
24GB	短片峰值已接近整机内存，9 秒那次超过它；不能照搬这套参数，得另测省内存方案	没有
48GB	比这批峰值有更多余量，主要做短镜头、同时运行的程序不多，值得考虑	没有，是根据本机记录推测
64GB	我还常驻其他服务，这批测试没有用到 swap，用起来比较省心	有，就是本文这台

原报告里对 48GB 的估算，是假设 GPU 工作集约为内存的八成，大约有 38GB。这个比例只是估算，不能当成每台机器固定的配额；买到其他配置，仍要看程序实际识别的数。我也没有把 48GB 跑过一遍，所以这里说的是“值得考虑”，不是保证它和 64GB 一样快。

小内存还有一条路，但要用时间换空间。 h3.c 的 --ssd-streaming 会一边计算，一边从 SSD 读取主模型的后续部分。作者在 M5 Max 上记录的主模型张量存储降到了约 2.0–2.1GiB；注意，这不是整个程序只用 2GB，文本编码、视频解码、系统和其他缓冲区仍然要内存。

作者的测试里，两种画幅的一轮主模型计算分别慢了 26% 和 84%，比较的是同一套 BF16 路径。它不能直接换算成“24GB 的 Mac mini 总共要等几分钟”，也不能套到我这里的 int8 测试上。这次我没有测流式加载，所以先不给这个答案。

所以，64GB 的价值在于留余量，不能仅凭这几段短片说它是刚需。如果主要跑 H3 短镜头，我会先考虑 48GB；如果还想同时跑其他模型和服务，就更愿意留到 64GB。24GB 得先验证省内存方案，再决定能不能接受它的速度。

那现在讨论很多的 M6 Mac mini 呢？ 苹果公布的配置最高是 32GB 统一内存，选不了前面说的 48GB 或 64GB。对照这次 18.5–22GB 的短片峰值，32GB 看起来有尝试的空间；但 9 秒已经到 25.6GB，还要给系统和其他程序留位置，不能只看“32 比 25.6 大”就判断一定能跑。有 m6 的小伙伴，欢迎在评论区留下你的测试结果。

还有软件适配这件事。截至这篇更新时，h3.c 的公开说明仍主要围绕 M3 Max、M5 Max 做优化，尚未列出 M6 的专门优化和实测结果。我这里用的也是针对 M5 的加速路径，不能因为 M6 更新，就把本机约三分钟的成绩直接套过去。

所以，如果主要为了 H3 买 M6，我会先等它的适配情况和同配置实测；如果还要做别的事，H3 只是偶尔玩玩，那可以继续把它放在候选里。我没有 M6，暂时不给它编一个预计耗时。

内存放得下之后，接下来才是每天用不用得下去：生成一段视频，要等多久？

生成速度：短镜头够用，长片要等

下面都是这台机器的实际记录，竖屏 576×1024，推荐画质：

请求时长	总耗时
2 秒	2 分 40 秒
3 秒	3 分 35 秒
5 秒	7 分 24 秒
9 秒	17 分 20 秒

程序会把帧数往上凑，所以实际视频会比请求的时长略长。时间从开始跑算到输出文件，加载模型、生成和解码都算进去了。

2 秒和 3 秒的可以接受，做一个短镜头够用。再往上，等的时间就长了。我最初用两个数据点估算，觉得 9 秒大概要 12 分钟，结果跑了 17 分钟。15 秒没测，平时也用不到那么长的。

本文用的 h3.c 版本是 8974cc0，测试时间是 9 月底到 10 月上旬。

硬盘也得算进去

Hugging Face 上整个仓库有 464GiB，但事实上不需要完全下载到本地。h3.c 用不到根目录的那套权重。

文生视频和首尾帧需要 FL2VA，134GiB；参考图需要 Ref2VA，也是 134GiB。我后来对了一下文件，发现两边的文本编码器、VAE 等文件完全一样，只有视频主模型不同。用 APFS 克隆复用相同文件，再下 62GiB 就够了。

文生和参考图两套都要的话，按这次的复用方式，模型本身约占 196GiB。这个数还没算系统、软件、输入素材和生成文件。只跑文生视频可以先下 134GiB 那套，不需要一开始就把所有功能装齐。

国内下载可以用 ModelScope 上 MiniMax 官方的同名仓库，我这边实测 73MB/s，134GiB 半小时下完。

机器能跑，效果又是另一回事。前面的 GIF 是成功的结果，下面这几次失败更能说明实际用起来要注意什么。

台词要按格式写

第一次写提示词，我把台词混在一段描述里，结果人物说出来的是含糊的、像日语又不是日语的音节。

后来照着格式，把台词单独放进去：

<d>[Chinese] 欢迎光临！</d>

再标上说话人 (S1)，这才正常。

我还专门对比了程序直接拼提示词和让 AI 扩写。面包店这个场景里，程序拼的也能说对，描述用中文、英文都行。AI 写了一大段，反而在开头多了一行字幕。所以现在默认直接由程序组装，需要更细的镜头描述才开 AI 扩写。

真人也试了一下，“国庆快乐”说成了“国供快乐”。动画店员那段没问题，不代表真人台词也稳，这个还得继续测。

参考图模式

如果你用过 minimax h3，就知道它有3种模式：文生视频、图生视频、首尾帧视频。

文生视频和首尾帧大家都理解；但图生视频需要的是参考图。而参考图要怎么给，描述要怎么写，还是需要一些技巧的。

我给了人物图和雪地松林，想让女孩走进树林介绍环境。素材是这几张：

结果有时开头还是面包店，有时全程都是人物图里的纯色背景，松林根本没用上。

后来加了一句：人物图只取人物，背景不出现。同样四组组合，不加这句有两次失败，加上之后四次都对了。

动作也一样。“慢慢走进树林，介绍环境”，测了 6 次都没得到画面和台词一起正确的结果。改成“从左边走进来，停下来，介绍这个地方”，4 次都对了。

每张图是什么，也要写清楚。我这组测试用具体的英文名词加一句特征比较稳，中文定义和笼统的 person、place 都不太行。

这些测试用的是同一套素材、两个种子，每种写法就试了几次，别把这里的成功率当成保证。要自己试的话，人物图尽量用干净背景，场景图里也别放抢眼的人或动物，先出草稿看效果。

自制 WebUI 已开源

我把它包成了一个服务，网页、命令行、微信和飞书对话共用一个任务队列。

网页里填描述、台词，选画幅和画质就能提交。参考图每张填用途、它是什么、有什么特征，程序会拼好格式。有场景图时，就自动加上前面那句“其他图只取主体，不要背景”。

现在在对话里说“图里的女孩挥手说欢迎光临，3 秒”，附上图，生成完就能收到视频。空闲一小时会自动关服务。

这套网页和队列整理后开源了，叫 h3-studio (求星星)：

https://github.com/shisaq/h3-studio 翻译、AI 扩写、聊天推送都是可选插件。视频生成在本机跑；选了云端翻译或 Codex 扩写，对应的文字、图片还是会发出去。想全程本地就选本机翻译，不开扩写。

目前我会继续用它做 2–5 秒的短镜头，让插画动起来，或者先试试一个想法。长视频等得久，台词也没稳定到可以不检查。

如果你还没买 Mac mini，可以先对照这些结果想想自己的用途：主要生成两三秒素材，还是要经常出长视频；只跑 H3，还是同时跑别的模型和服务。前者对我来说已经能用，后者要把等待时间和资源余量多算一些。

我测的是 M5 Pro 64GB，不能把这里的速度直接套到其他芯片或内存配置上。这篇能提供的是这台机器实际做出来的东西、占用和耗时。买的时候除了内存，也别漏掉硬盘：模型下载不小，生成的视频也会继续占硬盘。

总结

本地模型肯定没有云端模型能力强，minimax当然也不例外，跟即梦这样的模型没法比。而且为了跑本地模型，一台丐版的 Mac mini 肯定也是不够的。但它胜在2方面：1，再也不用为了积分或者token消耗而担心；2，隐私性强。

本文只是我自己的测试和分享，希望能给你带来一些参考价值。欢迎大家在下方留言讨论。

本文首发于微信公众号「像素李的AI笔记」：原文链接。博客版保留了文中的外链，和公众号版不同的地方都标了“博客版”。

LogicPro智能速度自动匹配不标准的录制素材

Sun, 12 Jul 2026 00:00:00 +0000

在 Logic Pro 中，要让软件的网格和节拍完全跟随你录制的那首非标准节奏（自由节奏/没有打节拍器）的歌，最核心的思路是让软件去适应你的音频（让网格变轨跟随音频），而不是把你的音频强行拉直。

最快捷、最智能的解决方法是使用 Logic Pro 的智能速度（Smart Tempo）功能，它可以可以自动分析音频中的重拍，并自动生成一条起伏的速度轨道来匹配你的录音。如果需要更精准的手动微调，可以使用节拍映射（Beat Mapping）。以下是具体的操作步骤：

导入音频：将您录好的音频文件拖入 Logic Pro 的空白音轨中。
修剪开头：将音频前段多余的空白部分剪掉，并把音频的起始点对齐到网格的起始位置（例如小节 1 的第 1 拍）。
设置跟随模式：双击该音频区域打开编辑器，点击 Smart Tempo 选项卡，点击 Analyze（分析）。

适应速度：在顶部 LCD 速度显示区域（或 Smart Tempo 项目设置中），将项目速度模式（Project Tempo Mode）从“Keep”更改为 Adapt（适应）。

应用至项目：右键点击音频区域，选择 Tempo -> Apply Region Tempo to Project Tempo（应用区域速度至项目速度）。Logic 将自动分析您的录音，建立专属的的速度轨道（Tempo Map）。

打开节拍器听一下，此时节拍器的速度会随着您的录音忽快忽慢，完美贴合。

给空调做一个“会睡觉”的定时器：Home Assistant + HomeKit 实战与踩坑全记录

Wed, 03 Jun 2026 00:00:00 +0000

夏天到了，晚上吹着空调睡觉，最怕两件事：一是吹一整宿，早上冻得鼻子发酸、电表也跑得欢；二是想定时关，可我家这台空调本身没有定时关机功能。

厂商的小程序里其实是有定时的——但你想想那个画面：人都躺平了，还得摸黑解锁手机、打开小程序、等它连上云、点进去设定时……困意全没了。我想要的是躺在床上，对着 Apple Home 或 Siri 拨一下，就告诉它“X 小时后关”，然后安心闭眼。

这篇文章记录我把这个“会睡觉的定时器”做出来的完整过程。它最终很简单，但中间撞了好几堵看不见的墙——而那些墙，恰恰是这篇东西最有价值的部分。如果你也在折腾 Home Assistant 接空调，这些坑能帮你少走两个晚上的弯路。

先看最终成果

在 Apple Home 里，多了一个叫「天窗空调定时」的滑块控件。

躺床上拖一下：拖到 30% = 3 小时后关，25% = 2.5 小时，0.5 小时一档；
想取消：拖回 0 / 关掉它；
还有一道保底：万一我设完忘了、或者压根没设就睡着了，到了 23:00 它会自己判断——空调还开着就再给 3 小时，凌晨自动关；
只管卧室那一台，白天开空调完全不受影响，绝不会无缘无故把你白天的空调关掉。

整条链路是这样的：

Apple Home / Siri
      ↓  拖滑块 / 语音
HomeKit 桥（Home Assistant 自带）
      ↓
fan.skylight_ac_timer   ← 一个“风扇壳”滑块（别急，下面解释为什么是风扇）
      ↓  百分比 ÷ 10 = 小时
input_number.skylight_ac_hours   ← 真正存“几小时”的地方
      ↓
timer.skylight_ac_manual   ← 倒计时
      ↓  到点
climate.turn_off → 卧室空调（本地局域网控制）

看着平平无奇对吧？但“为什么偏偏是一个风扇”“为什么不直接用空调自己的定时”——这两个问题背后，是整整一晚的探案。

需求先拆清楚

动手前我把脑子里的模糊愿望拆成了五条硬指标，这一步特别重要，能帮你判断每个方案“到底行不行”：

手动、任意时长：今晚想 2 小时，明晚可能 3 小时，得能自己定。
保底兜底：人是会忘事的。啥都没设就睡着了，也得有个安全网把它关掉。
只针对一间卧室：家里两台空调，另一台不许碰。
白天不误伤：白天开空调是正常使用，定时逻辑绝不能在白天把它关了。
躺着能操作：最好就在 Apple Home / Siri 里，不用再开第三个 App。

带着这五条，我们出发。

第一道弯：Home App 自己能定时吗？

最自然的想法：Apple Home 不是能做自动化吗，直接设个“X 小时后关”不就行了？

不行。 Apple Home 的自动化触发器只有那么几种（时间、配件状态、有人到家/离开、传感器），它没有“倒计时 / 延时 X 小时”这种原生控件。你能做的只有“每天固定几点关”——可我的时长每天不一样，固定时间直接出局。

iOS 的「快捷指令」里倒是有“等待”动作，但手机上的“等待”跑在你手机上，锁屏久了就断——拿来扛 2 小时极不靠谱。

结论：真正的倒计时得交给一台一直醒着的机器。我家正好有一台树莓派跑着 Home Assistant（HA），它就是干这个的最佳人选。于是问题变成：HA 怎么控这台空调、又怎么把控件递回 Apple Home。

第二道弯（探案时间）：空调自己不就有定时吗？

这是我钻进去最久、也最长见识的一段。

我家这台是华凌（美的体系），在 HA 里通过 midea_ac_lan 这个本地局域网集成接入——也就是说 HA 直接在内网跟空调对话，不走云。那么，小程序里那个“定时关机”，到底是云端在帮我倒计时，还是空调自己在数？

我一度想当然地说“云端”。但转念一想不对：厂商要是给千千万万台空调在云上各跑一个倒计时，这成本和逻辑都说不通。倒计时几乎一定是写进空调本机、由它固件自己数的，小程序只是把“N 分钟后关”这条指令下发下去而已。

如果是这样，那这条本地指令能不能我自己发？我把 midea-local 库的代码扒开看了。空调的设置命令是协议里的 0x40 包，我直接去读它构造命令体的那段：

# midealocal/devices/ac/message.py · MessageGeneralSet._body
return bytearray([
    power | prompt_tone,
    mode | target_temperature,
    fan_speed,
    0x00,   # ← 这几个写死的 0x00……
    0x00,   # ← 正是 Midea 协议里 on-timer / off-timer 的槽位
    0x00,
    swing_mode,
    ...
])

真相大白：协议槽位就在那儿（那几个 0x00 正是定时字节），但这个本地库根本没去填它。再去翻状态回包的解析（XC0MessageBody），它读了三十来个字段——温度、模式、睡眠、防冻……唯独不读 timer。全库唯一的 timer 只是子协议里的一个布尔“能力标志”，不是时长。

所以结论很清醒：

我的直觉对了——空调固件确实支持本地定时，不是云端逻辑；
但这个开源本地集成没把这功能接出来；
想用，就得魔改这个库（改命令编码、加可写实体），代价是每次更新被覆盖、还得为你这具体型号把字节编码试准；
而且最关键：就算接通了，HomeKit 那头照样没有“时长控件”可用，UI 问题一点没解决。

💡 给同路人的提醒：遇到“某功能 App 能用、集成里没有”，先去读集成/底层库的源码，往往能在十分钟内判断“是没接出来”还是“协议不支持”。这一步省下的是你瞎试的好几个晚上。

于是我果断收手：别碰库。倒计时放 HA 自己做就好——一个 timer 助手足够稳，连重启都能续上（restore: true）。“倒计时跑在哪”其实根本不影响体验，真正没解决的是下一关。

第三道弯（翻车现场）：HomeKit 的三道墙

需求第 5 条是“躺着在 Home 里操作”。我想要一个像调空调温度那样、能 +/- 连续拨的控件，一眼看到“几小时”。听起来不难吧？Apple 用三堵墙教我做人。

第一堵：HomeKit 没有“数字 / 时长滑块”。 我翻了 HA 的 HomeKit 桥源码，它支持的控件类型就这些：fans / lights / covers / humidifiers / thermostats / locks / switches / sensors…——没有 number。你的 input_number 根本递不过去。

第二堵：能连续滑的，只有两种单位。 翻下来，Apple 原生 Home 里能渲染成“连续滑块/表盘”的就两类：

控件	来源	显示单位
灯亮度 / 风扇转速 / 窗帘 / 加湿器	百分比特征	锁死 %
恒温器	温度特征	锁死 °

单位是协议特征写死的，Apple 不让你把 ° 改成“小时”。（第三方 HomeKit App 如 Eve 能显示自定义单位，但用苹果原生 Home 就这两种。）

那……恒温器至少数字是真的啊！我设 2.5，它就显示 2.5，只是旁边带个 °，能忍。于是我真的用 generic_thermostat 造了个假恒温器，把“温度”当“小时”，范围声明成 0–8、步进 0.5。

第三堵，也是压垮这个方案的那根稻草：Apple Home 给恒温器目标温度设了一个 ~7° 的硬地板。 我在 HA 里明明写了 min_temp: 0，可手机上那个表盘只能拨 7.0 / 7.5 / 8.0 三档——0 到 7 全被 Apple 吞了。总不能让人“最少定 7 小时”吧？这个方案当场报废。

🧱 一句话记住：在 Apple 原生 Home 里，想要全程连续的控件，要么接受“显示是 %”，要么接受“恒温器最低 7°”。鱼与熊掌，real-number 和 full-range 不可兼得。

最终方案：用一个“风扇”收尾

撞完三堵墙，路反而清楚了：既然“显示真实小时数”做不到，那就退一步选全程不卡的百分比滑块，把“是 %”这个瑕疵用一个好记的映射抹平。

我选了风扇（也可以用灯，风扇胜在能设“档数”、好对齐）：

设 speed_count: 20，于是滑块有 20 档，每档 5% = 0.5 小时，最高 100% = 10 小时，拖动时会卡档，半小时精度轻松对准；
映射做成最好心算的：百分比 ÷ 10 = 小时。30% → 3 小时，25% → 2.5 小时；
这个“风扇”其实是个空壳，真正存小时数的是背后的 input_number，风扇只是它递给 HomeKit 的外衣。

整套配置如下，HA 用户可以直接抄（我用 packages 的方式把一整块功能塞进一个文件，方便整体回滚）。你只需要把那个真·空调实体 climate.197912093838856_climate 换成你自己的，其余照搬即可。

# packages/skylight_ac_timer.yaml
# 卧室空调·睡眠定时关
#   Apple Home 里一个“风扇壳滑块” fan.skylight_ac_timer：
#   百分比 ÷ 10 = 小时（30%→3h，25%→2.5h），20 档、每档 0.5h、最高 10h，拖到 0 / 关闭 = 取消。
#   背后 input_number.skylight_ac_hours 存小时数；倒计时到点关空调并复位 0。
#   保底：23:00 判断一次，空调还开着且没设定时 → 起 3 小时（→02:00 关）。白天开空调不进此逻辑。

input_number:
  skylight_ac_hours:
    name: 卧室空调定时小时数
    min: 0
    max: 10
    step: 0.5
    mode: slider
    icon: mdi:timer-outline

timer:
  skylight_ac_manual:
    name: 卧室空调手动倒计时
    duration: "02:00:00"
    restore: true
  skylight_ac_fallback:
    name: 卧室空调保底倒计时
    duration: "03:00:00"
    restore: true

# ⚠️ 用新版 template 语法（旧 `fan: platform: template` 将在 2026.6 移除）
template:
  - fan:
      - name: 卧室空调定时
        default_entity_id: fan.skylight_ac_timer   # 锁住英文 entity_id，HomeKit 桥引用更稳
        state: "{{ 'on' if (states('input_number.skylight_ac_hours') | float(0) > 0) else 'off' }}"
        percentage: "{{ (states('input_number.skylight_ac_hours') | float(0) * 10) | int }}"
        speed_count: 20
        turn_on:
          - choose:
              - conditions:
                  - condition: template
                    value_template: "{{ states('input_number.skylight_ac_hours') | float(0) < 0.5 }}"
                sequence:
                  - action: input_number.set_value
                    target: { entity_id: input_number.skylight_ac_hours }
                    data: { value: 2 }   # 直接点“开”不拖滑块 = 默认 2 小时
                  - action: timer.start
                    target: { entity_id: timer.skylight_ac_manual }
                    data: { duration: "02:00:00" }
        turn_off:
          - action: input_number.set_value
            target: { entity_id: input_number.skylight_ac_hours }
            data: { value: 0 }
          - action: timer.cancel
            target: { entity_id: timer.skylight_ac_manual }
        set_percentage:
          - variables:
              hrs: "{{ ((percentage | float(0) / 10) * 2) | round(0) / 2 }}"  # 折到最近的 0.5
          - action: input_number.set_value
            target: { entity_id: input_number.skylight_ac_hours }
            data: { value: "{{ hrs }}" }
          - choose:
              - conditions:
                  - condition: template
                    value_template: "{{ hrs >= 0.5 }}"
                sequence:
                  - action: timer.start
                    target: { entity_id: timer.skylight_ac_manual }
                    data:
                      duration: >
                        {% set s = (hrs * 3600) | int %}
                        {{ '%02d:%02d:00' % (s // 3600, (s % 3600) // 60) }}
            default:
              - action: timer.cancel
                target: { entity_id: timer.skylight_ac_manual }

automation:
  # 倒计时到点：关空调 + 复位小时数到 0
  - id: skylight_ac_manual_finish
    alias: 卧室空调·倒计时到→关机并复位
    trigger:
      - platform: event
        event_type: timer.finished
        event_data: { entity_id: timer.skylight_ac_manual }
    action:
      - service: climate.turn_off
        target: { entity_id: climate.197912093838856_climate }   # ← 换成你的空调
      - service: input_number.set_value
        target: { entity_id: input_number.skylight_ac_hours }
        data: { value: 0 }

  # 保底：23:00 定点判断
  - id: skylight_ac_fallback_check_2300
    alias: 卧室空调·23点判断→若开着且没设定时则起3小时保底
    trigger:
      - platform: time
        at: "23:00:00"
    condition:
      - condition: template
        value_template: >
          {{ states('climate.197912093838856_climate') not in ['off','unavailable','unknown'] }}
      - condition: state
        entity_id: timer.skylight_ac_manual
        state: idle
    action:
      - service: timer.start
        target: { entity_id: timer.skylight_ac_fallback }
        data: { duration: "03:00:00" }

  - id: skylight_ac_fallback_disarm
    alias: 卧室空调·关机→取消保底
    trigger:
      - platform: state
        entity_id: climate.197912093838856_climate
        to: "off"
    action:
      - service: timer.cancel
        target: { entity_id: timer.skylight_ac_fallback }

  - id: skylight_ac_fallback_finish
    alias: 卧室空调·保底3小时到→关机
    trigger:
      - platform: event
        event_type: timer.finished
        event_data: { entity_id: timer.skylight_ac_fallback }
    action:
      - service: climate.turn_off
        target: { entity_id: climate.197912093838856_climate }

几个设计点，值得单独说说

为什么不直接让风扇存小时数，要多一个 input_number？ 因为模板风扇本身是“无状态”的外壳，它的百分比需要一个真实的地方存。input_number 就是那个“单一事实来源”：风扇读它显示、写它生效，倒计时到点把它清零，整条逻辑就闭环了，也不怕重启丢值。

保底为什么是“23:00 判断一次”，而不是“开机就起 3 小时”？ 这正是需求第 4 条（白天不误伤）的关键。如果做成“一开机就 arm 3 小时”，那你白天开空调，3 小时后也会被自动关——这不是我们要的。改成只在 23:00 这个点判断一次：那时候空调还开着、又没设手动定时，才认为“这人是开着空调睡了”，给它兜底。白天的空调，从头到尾不进这套逻辑。

（小取舍：如果你 23:00 之后才进卧室开空调，那一晚保底不生效——这种情况手动拖一下滑块即可。我作息规律，基本卡得上，就接受了这个边界。）

手动定时优先于保底。 23:00 判断时有一条 timer.skylight_ac_manual == idle 的条件：只要你已经拖了滑块（手动倒计时在跑），保底就不插手；它俩还能自然叠加——手动更短会先关，关机那一刻又会触发“取消保底”，不会重复。

怎么把这个控件递进 Apple Home

HA 自带一个 HomeKit 桥集成，能把指定实体暴露成 Apple Home 里的配件。把上面的 fan.skylight_ac_timer 加进去就行：

设置 → 设备与服务 → 找到 HomeKit Bridge → 配置 → 在“要包含的实体”里勾上 fan.skylight_ac_timer → 保存。

稍等片刻，Apple Home 里就会冒出一个「卧室空调定时」的风扇配件。是的，图标是个风扇——这是我们为了“全程连续滑块”付出的代价，你就当它是“把热气吹走的倒计时”好了 🌬️。拖它、或者对 Siri 说“把卧室空调定时设成 30%”，3 小时后空调自己就睡了。

临门一脚的小坑：旧版模板语法要迁移

做完没几天，HA 后台弹了个“修复”提示：旧的 fan: platform: template 写法将在 2026.6 移除，让我迁到新版 template: → fan: 语法。

好在 HA 的修复向导会直接生成迁移好的新配置，照着替换就行。上面那份完整配置我已经是迁移后的新语法了，你直接抄不会再碰到这个提醒。这里也顺手记一条经验：

🔧 定期看一眼 HA 的“修复（Repairs）”面板。很多弃用都会提前一两个版本预警，并附带自动生成的新配置——趁早处理，别等升级当天炸给你看。

踩坑速查表

把这一晚的弯路浓缩成一张表，方便你对号入座：

坑	真相	对策
Home App 想直接定时	没有原生“延时/倒计时”控件	倒计时交给常醒的 HA（`timer` 助手）
想用空调自带定时	固件支持，但本地集成没把它接出来（命令字节写死 0）	别魔改库，HA 自己做倒计时即可
想要数字滑块	HomeKit 桥没有 `number` 类型	借“风扇/灯”的百分比壳
想用恒温器显示真实小时	Apple Home 把目标温度卡在 ~7° 地板	放弃“真实数字”，用 % 滑块 + 好记映射
百分比不直观	单位改不了	选 `÷10` 这种心算友好的映射 + `speed_count` 卡档
旧模板语法弃用	2026.6 移除 `fan: platform: template`	用 Repairs 向导迁到新版 `template:`

写在最后

绕了一大圈，最后落地的东西特别朴素：躺床上拖一下滑块，空调就会在我设定的时间安静睡去；哪怕我先睡了，也有一道 23 点的安全网替我兜着。 一个不起眼的小工具，却实实在在地把“起夜关空调”这件小事从我的生活里抹掉了。

我很喜欢这种折腾。它表面是在跟空调较劲，本质是在跟那些“看不见的限制”打交道——Apple 的地板、协议里写死的零、即将被移除的旧语法。每撞一堵墙，你对这套系统的理解就厚一分。而最有意思的部分，往往不是最终那段能抄的配置，而是“为什么偏偏是一个风扇”背后的那一整晚。

愿你也能给自己的生活，装上一两个这样“会睡觉”的小开关。

—— 给你的生活加点阳光 ☀️

当 AI 把窗外的鸟认成树懒：一台树莓派的观鸟相机调教记

Wed, 03 Jun 2026 00:00:00 +0000

我家住4楼，窗外面常有鸟来落脚。有时只是停几秒，有时会在栏杆之间来回跳。我从小喜欢看动物世界，现在家里的娃也集成了这个基因。我们都想知道这些鸟什么时候来、来了几次。

于是我翻出一套吃灰很久的 Google AIY Vision Kit：树莓派 Zero，加一块 Vision Bonnet，再接一颗树莓派摄像头。它是 2017 年那波「纸盒子 AI 套件」里的视觉版，板上有一颗视觉处理芯片，可以在本地跑图像分类。

目标很简单：平时低功耗盯着窗外，有东西落到指定区域就自动录 10 秒视频；我打开浏览器时，能看到实时画面、最近识别结果和录像列表。

现在它长这样：

这套东西现在能做到：

有活物落到窗台区域时，自动录一段 10 秒 1080p 视频；
只保留最近 30 段录像，旧的自动删除；
网页上有实时画面、当前识别状态、最近事件和录像列表；
识别日志会保留最近 1000 条，重启后也不会丢；
录像页可以直接预览，也可以下载；
所有推理都在本地完成，不依赖云服务。

下面这只灰喜鹊，就是它自己抓到的。

硬件不新，但刚好够用

这套硬件很老：

Raspberry Pi Zero，性能非常弱；
Google AIY Vision Bonnet，负责跑视觉模型；
一颗树莓派摄像头，贴着窗玻璃看外面；
系统还是 2017 年前后的老镜像。

Google 当年给 Vision Kit 准备过几类模型。官方介绍里提到过 MobileNets 物体识别、表情识别、人/猫/狗检测等 demo；AIY 模型页面里也能看到 Vision Kit 支持的模型类型。我的镜像里真正能稳定跑起来的，是一个基于 MobileNet 的 ImageNet 1000 类通用分类模型。

我本来想用更适合自然观察的 iNaturalist 数据集相关模型，毕竟它面向真实世界的动植物照片。可惜这块老镜像和老 Bonnet 的工具链太旧，折腾到最后还是回到通用分类模型。

这也决定了后面的故事：老模型不太会认鸟——但也是这个特性，让后面的识别结果更好玩了。

先让相机省着干活

一块 Pi Zero 同时做直播、录像和 AI 推理，很容易把自己拖死。我的做法是把任务拆开：

空闲时：
  只跑一路 640x360 的低码率 H.264，用运动矢量判断 ROI 有没有动

有动静：
  抓一帧 1080p 原图
  裁出窗台/落脚区
  丢给 Vision Bonnet 跑分类

判定需要录像：
  独占摄像头录 10 秒 1080p
  ffmpeg 封装成 mp4
  回到空闲检测

有人打开网页：
  临时开一路 384x216 MJPEG 预览
  没人看就关掉

检测和预览是两条路。网页上的直播画面很糊，但真正喂给模型的是 1080p 原图裁出来的局部。这点很重要，因为我一开始也以为问题出在直播画质太差。

核心检测逻辑大概是这样：

camera.capture(buf, format='jpeg', use_video_port=True, splitter_port=0)
crop = Image.open(buf).crop(ROI)
classes = image_classification.get_classes(inf.run(crop), max_num_objects=5)

网页只是观察窗口，不参与判断。判断用的是裁剪后的落脚区。

它真的把鸟认成了树懒

最有意思的部分来啦。

我一开始用的是很直觉的规则：如果模型输出里出现鸟类词，比如 junco、sparrow、magpie，而且置信度超过阈值，就录像。

实际效果很差。后来我把日志拉出来看，发现空场景和有鸟时的标签非常有规律：

场景	模型常见 top 判断
空栏杆	`handrail`、`bannister`、`worm fence`
玻璃/纱窗/反光	`mosquito net`、`window screen`
有鸟落脚	`capuchin`、`langur`、`squirrel monkey`、`hog`、`orangutan`

也就是说，它经常把鸟认成猴子、猪、猩猩——在北京4楼的窗外，如果真的出现了这些动物，那绝对是在做白日梦，哈哈。

但如果我换个问法：「这还是不是空栏杆？」它反而很稳定。

于是判断逻辑改成了这样：

STRUCTURE_WORDS = {
    'bannister', 'handrail', 'fence', 'window', 'screen',
    'mosquito', 'net', 'grille', 'picket', 'pole'
}

def is_structure(label):
    return bool(tokens(label) & STRUCTURE_WORDS)

occupied = top_score >= floor and not is_structure(top_label)

if bird_word_hit or occupied:
    record_clip()

这就是整套系统真正的转折点。它不需要认出「这是一只灰喜鹊」。它只要发现「这块区域不再像平时那根空栏杆」，我就录下来。

这听起来有点歪，但很实用。漏拍是永久损失，误录最多就是我翻录像时跳过一段。对观鸟相机来说，我愿意偏向多录。

把 AI 的判断摆到网页上

之前我调得很痛苦，是因为只能看日志。后来我把实时状态和历史记录都接到网页上，调参就舒服多了。

这是我先让 AI 生成的一版视觉概念图，用来确定控制台的方向：暗色、画面优先、状态集中在右侧。

最终页面没有照搬概念图里的假数据和装饰，只保留了信息结构：直播画面在左侧，右侧是当前状态、置信度、时段策略、快速入口和最近事件。

实时状态分三类：

绿色「鸟」：模型真的在候选里报出了鸟类词；
黄色「活物?」：模型没报鸟，但 top 标签不像空栏杆；
灰色「无鸟」：还是栏杆、纱窗、反光这类空场景。

旧版页面更朴素，但已经能看出这个思路：

日志页是另一块关键拼图。它每 2 秒刷新一次，把最近识别事件列出来。后来我又把日志从内存环形队列改成了磁盘上的 JSONL 文件，最多保留 1000 条。这样服务重启后，调参上下文还在。

录像页：先能看，再能下载

最开始的录像页只是一个文件名列表。后来我把它改成了卡片式录像库：每个视频可以直接预览，下面显示时间、识别摘要和下载按钮。

录像只保留最近 30 个。每次新录像封装完成后，程序会按修改时间删除更旧的文件；服务启动时也会清理一次。所以重启不会影响这个上限。

分时段调灵敏度

鸟不是均匀出现的。清晨和黄昏更活跃，夜里基本是噪声。所以我给它做了一个简单的时段档位：

PROFILES = {
    'dawn':  (0.08, 5,  '清晨高发'),
    'dusk':  (0.08, 5,  '黄昏高发'),
    'day':   (0.12, 8,  '日间常规'),
    'night': (0.22, 15, '夜间保守'),
}

清晨和黄昏门槛低一点，冷却时间短一点；夜里门槛高一点，免得风吹窗帘、玻璃反光都触发录像。这个策略很土，但很符合真实使用。

如果你也想做一个

这套方案不一定要 AIY Vision Kit。任何「树莓派 + 摄像头 + 一个能跑分类或检测的模型」都能复刻。差别只是推理放在本地，还是丢给别的设备或云端。

我觉得关键不是模型有多强，而是这几条：

先确定一个固定 ROI。不要全画面找目标，只盯喂食器、栏杆、窝口这种小区域。
空闲时用廉价运动检测，不要一直跑模型。
有动静再抓高清图，裁 ROI，跑分类。
不要急着问「是不是鸟」。先收集空场景会被识别成什么，再把规则改成「还像不像空场景」。
把模型输出显示出来。网页、日志、JSON 都行，别盲调。
录像和直播分开。预览可以糊，录像要清楚。
给存储设上限。我的录像是 30 个，日志是 1000 条。

现在这套程序就是一个 Python 文件加一个常驻服务，没有数据库，没有云端账号，也没有复杂前端。它不聪明，但每天早上能告诉我：昨晚窗外有没有来过什么东西。

它依然会把鸟叫成树懒 sloth。我家娃的英语比我好，一下就反应过来了；我还得让她帮我翻译一下才反应过来~

但总之，识别到活物，通常都是好消息。

优客李李，给你的生活加点阳光~

把乐歌 E2 升降桌改造成智能家居：ESP32 + ESPHome + Home Assistant 实战

Sun, 31 May 2026 00:00:00 +0000

最近我把家里的乐歌 E2 升降桌接入了 Home Assistant，并进一步暴露到 Apple Home 里。最后的效果是：在 Home App 里点一下“sit”或“stand”，桌子就会自动去到坐姿或站姿记忆高度。

这件事一开始看起来像是“找两根线上下短接一下”的简单小活，实际折腾下来才发现，乐歌这类桌子的手控器接口并不是传统按键短接，而是一套跑在 RJ45 线里的 UART 串口协议。

这篇文章记录完整过程：怎么识别引脚、怎么确认协议、怎么用 ESP32 + ESPHome 接入 Home Assistant，以及最后如何解决供电和 HomeKit 控制。

最终成果

硬件上，桌子的原手控面板仍然保留，ESP32 只是并联接入手控接口的串口线。

软件上，现在有这样一条链路：

Apple Home / Siri
        ↓
Home Assistant
        ↓
ESPHome API
        ↓
ESP32 UART
        ↓
乐歌 E2 升降桌控制器

最终可用能力：

Home Assistant 中有两个按钮：sit 和 stand
Apple Home 中也可以控制这两个动作
ESP32 不需要额外 USB 电源，直接由桌子 RJ45 接口中的 5V 供电
原桌子手控器不受影响，仍然可以正常按实体按钮

硬件清单

这次用到的东西不少，我第一次接触了单片机：

乐歌 E2 升降桌
ESP32-WROOM-32 开发板，30Pin，Type-C 口
RJ45 转 8Pin 免焊接线端子
杜邦线若干
万用表
一台树莓派，运行 Docker 版 Home Assistant

因为我不会焊接，所以整个方案尽量围绕“免焊、可拆、可回滚”来做。所有连接都是杜邦线加螺丝端子。

第一阶段：确认它不是普通按键

我最开始的直觉是：升降桌手控器上有上升、下降、1、2、3、4 记忆位，那 RJ45 里面也许就是几根按键线，按下某个按钮就是某根线接地。

结果不是。

用 ESP32 的 UART 调试后发现，桌子在静止时也会持续广播数据。波特率测试下来，9600 最稳定。

静止时能看到类似这样的帧：

9B:04:11:7C:C3:9D
9B:07:12:00:00:00:B8:94:9D

桌子移动时，数据会明显变化，例如：

7F:FD:06:F2:65:9D
7F:87:3F:80:86:9D
06:06:7F:F9:36:9D

这一步非常关键。它说明：手控器接口不是简单按键短接，而是 UART 串口通信。

RJ45 引脚测量

RJ45 水晶头方向按下面这个姿势看：

金属触点朝上
卡扣朝下
线朝远离自己

我测到的结果：

pin1：约 5.11V
pin2：GND
pin3：约 4.1V
pin4：约 4.2V
其它脚约 0V

后续验证下来：

pin1 可以给 ESP32 的 VIN 供电
pin2 是 GND
pin3 / pin4 是 UART TX/RX

这里有一个风险点：ESP32 的 GPIO 严格来说不是 5V tolerant，而这里 UART 线测出来有 4V 多。我的实际测试能工作，但长期更严谨的方案应该在桌子 TX 到 ESP32 RX 之间加电平转换或分压。当前版本先按最小改动完成。

ESP32 接线

ESP32 这边使用：

GPIO16 / D16
GPIO17 / D17
GND
VIN

最终接线：

RJ45 pin1  +5V   -> ESP32 VIN
RJ45 pin2  GND   -> ESP32 GND
RJ45 TX          -> ESP32 RX / GPIO16
RJ45 RX          -> ESP32 TX / GPIO17

注意：ESP32 的 TX 要接桌子 RX，ESP32 的 RX 要接桌子 TX。如果收不到数据，就先交换 TX/RX。

另外，桌子的 5V 要接 ESP32 的 VIN，不要接 3V3。VIN 是 5V 输入，会经过板载稳压芯片变成 ESP32 使用的 3.3V；3V3 是板上已经稳压后的 3.3V 电源脚，把 5V 接上去很可能烧板。

测试桌子 5V 供电时，我先拔掉了电脑 USB，只让桌子的 pin1 -> VIN、pin2 -> GND 给 ESP32 上电。确认它能稳定上线后，再接回 TX/RX 测试 sit 和 stand。

ESPHome 配置

最终 ESPHome 配置非常短：

esphome:
  name: desk

esp32:
  board: esp32dev
  framework:
    type: arduino

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

logger:
  baud_rate: 0

api:

ota:
  platform: esphome

uart:
  id: desk_uart
  baud_rate: 9600
  tx_pin: GPIO17
  rx_pin: GPIO16

button:
  - platform: template
    name: "sit"
    id: sit
    on_press:
      - uart.write:
          id: desk_uart
          data: [0x9b, 0x06, 0x02, 0x04, 0x00, 0xac, 0xa3, 0x9d]

  - platform: template
    name: "stand"
    id: stand
    on_press:
      - uart.write:
          id: desk_uart
          data: [0x9b, 0x06, 0x02, 0x08, 0x00, 0xac, 0xa6, 0x9d]

这里一开始我用的是 switch，后来改成了 button。原因很简单：坐姿和站姿不是“开关状态”，而是“执行一次命令”。如果用开关，Home Assistant 会误以为它有持续的 on/off 状态；但实际上点完 stand 并不代表桌子一定已经到位，也无法知道中途是否被手控器打断。

所以现阶段最准确的模型是：

sit：发送一次坐姿记忆位命令
stand：发送一次站姿记忆位命令

等以后解析出高度帧，再考虑升级成 sensor + number + select，甚至做成类似窗帘的 cover 模型。

当前状态读取

后来我又继续做了一轮状态读取测试。目标不是继续深度逆向整套协议，而是先解决一个实际问题：Home Assistant 至少要知道桌子现在大概是坐姿、站姿，还是正在移动。

静止时，桌子会持续发这样的帧：

9B:04:11:7C:C3:9D
9B:07:12:00:00:00:B8:94:9D

但这两种静止帧本身不能区分坐姿和站姿。也就是说，如果 ESP32 刚刚冷启动，而桌子没有发生过任何动作，单靠这两条空闲数据无法判断桌子当前到底在什么高度。

真正有用的是坐站切换过程中的帧。测试下来，目前可以用下面几类信号做判断：

9B:04:15:BF:C2:9D              # 桌子正在移动
9B:07:12:07:CF:...:...:9D      # 坐姿预设相关状态
9B:07:12:06:06:...:...:9D      # 站姿预设相关状态

所以现在 ESPHome 里多了几个状态实体：

text_sensor.desk_posture       # sitting / standing / unknown
binary_sensor.desk_sitting
binary_sensor.desk_standing
binary_sensor.desk_moving

这里没有把坐姿和站姿做成一个 switch。原因是它并不是真正的开关：物理面板也可以改变桌子状态，中途还可能被打断。更准确的设计是保留 sit / stand 两个按钮，再单独暴露只读状态。

实际测试结果如下：

stand -> sit:
初始 standing
按 sit 后 moving=true
约 21 秒后 moving=false
最终 sitting=true, standing=false, posture=sitting

sit -> stand:
初始 sitting
按 stand 后 moving=true
约 21 秒后 moving=false
最终 sitting=false, standing=true, posture=standing

另外，我还测试了直接按桌子物理面板的 1 键。桌子回到坐姿后，Home Assistant 也同步读到了：

sitting=true
standing=false
moving=false
posture=sitting

这说明 ESP32 现在不是只知道“自己发出的命令”，而是真的在旁路监听桌子的 UART 通信。无论是 Home Assistant 触发，还是手按物理面板，只要桌子完成一次坐站切换，状态都能被更新回来。

当前限制也很清楚：冷启动后的第一次静止状态可能只能恢复上一次记录，不一定代表真实高度。但只要之后发生一次坐站动作，状态就会重新变得可信。对我现在的用法来说，这已经够用了。

Home Assistant 接入

Home Assistant 是新装在树莓派上的 Docker 版，地址类似：

http://192.168.31.123:8123

ESPHome 节点刷好后，Home Assistant 自动发现了 desk。添加 ESPHome integration 后，就能看到两个实体：

button.desk_sit
button.desk_stand

我还在路由器里给 ESP32 做了 DHCP 静态绑定，这样每次断电重连后，IP 不会漂移，Home Assistant 连接更稳定。

接入 Apple Home

要把 Home Assistant 里的实体暴露到 Apple Home，使用的是 Home Assistant 的 HomeKit Bridge。

路径：

Settings -> Devices & services -> Add Integration -> HomeKit Bridge

创建 HomeKit Bridge 时，只选择暴露桌子相关实体：

button.desk_sit
button.desk_stand

然后 Home Assistant 会给出 HomeKit 配对二维码或 PIN。打开 iPhone 的 Home App，添加配件，扫码或输入 PIN 即可。

Docker 版 Home Assistant 如果遇到 HomeKit 找不到 Bridge，通常和网络模式、mDNS 广播有关。最省心的方式是让 Home Assistant 容器使用 host network，让它和局域网设备处在同一网络广播环境中。

供电：从电脑 USB 到桌子 5V

一开始 ESP32 是电脑 USB-C 供电，只接了：

RJ45 GND -> ESP32 GND
RJ45 TX/RX -> ESP32 RX/TX

这叫“监听模式”，比较安全，但不适合长期使用：桌子下面还要吊一根 USB 电源线，非常不优雅。

后来确认 RJ45 pin1 是约 5.11V 后，我把它接到了 ESP32 的 VIN。测试结果稳定，不需要外接 USB 电源。

这里的注意事项：

5V 接 VIN，不要接 3V3
GND 接真正的 GND
测试时不要同时接电脑 USB 和桌子 5V
用万用表电压档测 pin1 到 pin2，不要用电流档直接短接测量

我还犯过一个小错误：曾经把 GND 接到了旁边的 D13。好在当前固件没有使用 D13，实际没有造成影响。但这个错误提醒我，最后一定要把线固定好，不能让杜邦线长期处于受力和晃动状态。

现在还不完美的地方

功能上已经可用了，但外观还比较工程样机：一根粗 RJ45 线、几根杜邦线、一块裸露 ESP32 板子吊在桌子下面。

后续准备做一个小盒子，把 RJ45 端子和 ESP32 收进去：

使用小 ABS 项目盒
换短款柔软扁平 RJ45 线
ESP32 和端子用双面胶或固定座固定
线入口做应力释放，避免外部拉扯直接作用到螺丝端子
整个盒子用魔术贴固定在桌板底部

目标是最后只看到一个小盒子和一根短线，而不是一团实验线。

这次折腾的收获

这次最大的收获不是“让桌子能被手机控制”，而是把一个原本封闭的普通家具有条理地拆成了几个可理解的问题：

它的接口是不是电源和按键？
如果不是按键，它在说什么协议？
怎么只监听，不冒险干扰原控制器？
怎么发最小命令完成坐姿/站姿？
怎么让 Home Assistant 和 Apple Home 认为它是一个正常智能家居设备？
怎么把临时 USB 供电改成桌子内部供电？

最后答案很简洁：

乐歌 E2 RJ45 手控接口
  -> UART 9600
  -> ESP32 + ESPHome
  -> Home Assistant
  -> HomeKit Bridge
  -> Apple Home

现在这张桌子终于不只是“电动升降桌”，而是家里智能家居系统的一部分了。

下一步：把桌子变成真正的健康提醒

现在的桌子已经可以被 Home Assistant 和 Apple Home 控制，但它本质上还是“手动触发”：我想坐下或站起来时，点一下按钮。

下一步我想把它做成一个更主动的健康工作流：结合传感器和番茄钟，让桌子在合适的时机自动提醒甚至强制切换坐站状态。

初步设想是：

用传感器判断我是否真的在桌前，比如人体存在传感器、椅子压力传感器，或者电脑是否处于活跃状态
用 Home Assistant 做番茄钟逻辑：工作 25 分钟后自动切到 stand
站立 5 分钟后再允许切回 sit
如果传感器判断我不在桌前，就不触发升降，避免空桌子自己动
后续如果能解析出桌子的高度数据，再加入“已经在站姿就不重复执行”的判断

这一版的关键不再是“能不能控制桌子”，而是“什么时候应该控制”。智能家居真正有用的地方，往往不是把手机变成遥控器，而是让设备根据场景自己做对的事。

实战续集：把番茄钟真的做出来了

上面是设想，后来我把它完整落地了。最终效果是：

我在桌前工作满 30 分钟，桌子自动切换坐 / 站姿势（节律就是“每 30 分钟换一次姿势”，换姿势后的前 5 分钟当作“换脑子”）
我离开桌子，番茄钟自动暂停，桌子不会对着空座位自己升降
离开超过 10 分钟（比如午饭）回来，自动重开一轮，回到坐姿重新计时
录歌、开 LogicPro、开会时，我进一个 macOS 专注模式，桌子整体冻结
晚上 23:00 到次日 07:00 硬冻结，任何原因都不动，免得半夜被动作惊到
全程 Mac 上不挂任何 GUI 程序，纯后台

这一版折腾下来，真正花时间的不是“写自动化”，而是踩平台环境的坑。下面把架构、判断逻辑和三个硬核坑都记下来。

怎么判断“我在不在桌前”

这是整件事的输入信号。我比较过几条路：

ping / 在线探测：只能判断“开机在线”，区分不了“在用”和“合盖睡眠”，不行。
HA Companion App：装一个官方 macOS App 就能上报 Active 状态，最省事。但它是个常驻 GUI 程序，而且默认上报一大堆信息（前台 App、摄像头、位置……）。我想要无感，不行。
最终方案：读 macOS 自带的 HIDIdleTime（距离上次键鼠操作的纳秒数），后台脚本定时上报给 HA。这是唯一能真正反映“键鼠有没有在动”的信号。

ioreg -c IOHIDSystem | awk '/HIDIdleTime/ {print int($NF/1000000000)}'

整体架构与数据流

最终链路长这样（后面会解释为什么中间要绕一道 webhook）：

Mac launchd（每 20 秒）
  └─ /usr/bin/curl ──HTTP──▶ HA Webhook（接收 idle 秒数）
                                └─ 自动化 mqtt.publish ─▶ mosquitto（topic: mac/desk/idle）
                                      └─ MQTT sensor（expire_after 90s）
                                            └─ binary_sensor.mac_at_desk（idle < 180s）
                                                  └─ should_run（在桌前 且 未专注 且 非夜间）
                                                        └─ timer（30 分钟）
                                                              └─ 到点 ─▶ button.desk_sit / desk_stand

mosquitto 用 Docker 跑在树莓派上，关掉匿名、开账号密码和 ACL。HA 用 ha 账号连它。

判断逻辑：把“该不该动”拆成可独立验证的布尔量

我没有把逻辑堆成一坨，而是拆成几个一眼能测真值的中间量：

1. 在不在桌前

# binary_sensor.mac_at_desk
state: >
  {% set v = states('sensor.mac_idle_seconds') %}
  {{ v not in ['unknown','unavailable','none', None] and (v | int(99999) < 180) }}

注意 MQTT sensor 上挂了 expire_after: 90：Mac 睡眠 / 合盖后 launchd 不再上报，90 秒内收不到数据，传感器自动失活 → at_desk 变 off → 桌子默认不动。这是个“失联即安全”的兜底。

2. 番茄钟该不该运行（三个闸门合一）

# binary_sensor.desk_pomodoro_should_run
state: >
  {% set t = now() %}
  {% set night = t.hour >= 23 or t.hour < 7 %}
  {{ is_state('binary_sensor.mac_at_desk','on')
     and is_state('input_boolean.desk_pause_focus','off')
     and not night }}

计时器只在 should_run 为 on 时走；离桌 / 专注 / 夜间任一成立，立刻 timer.pause。

3. 回来是“续上”还是“重开一轮”（这里藏着一个我后来才发现的坑）

这是体验上最关键的一条。短暂离开（上厕所、倒水）希望接着原进度；长时间离开（午饭）希望重新开始。我用“离开时长”统一区分：

# 触发器：HA 启动 + should_run 任意 → on（关键：别只写 from: "off"）
# 条件：should_run 为 on，且 timer 当前不是 active（避免重复启动）
away_secs: >
  {% if trigger.platform == 'state' and trigger.from_state
        and trigger.from_state.state == 'off' and trigger.to_state %}
    {{ (trigger.to_state.last_changed - trigger.from_state.last_changed).total_seconds() }}
  {% else %}
    99999
  {% endif %}
# away_secs < 600 且 timer 处于 paused → timer.start（续上）
# 否则 → 起 30 分钟（开新一轮，从当前姿势开始，不强制移动桌子）

这一条同时覆盖了午饭、夜间结束、长时间录制结束等所有“离开很久”的情况，不用各写一遍。

⚠️ 别学我最初的写法：我第一版的触发器只写了 from: "off" → to: "on"，埋了个雷。每次 Home Assistant 一重启，should_run 是从 unknown → on，并不匹配 off→on，于是启动自动化根本不触发——番茄钟就一直停在 idle，桌子再也不会动；而整套又没有“开机即启”的兜底，等于只要重启过一次就废了（我清理配置连着重启了十来次，才发现它早就不转了）。

修法：把触发器放宽成「任意 → on」并补上「HA 启动（platform: homeassistant, event: start）」，再用「timer 不是 active」这个条件兜住重复启动；away_secs 只在真正的 off→on 时才计算，其余（开机、unknown→on）一律当作开新一轮。“只认某一种状态跳变”是 HA 自动化里最常见的坑之一——一定要把重启 / 冷启动时的 unknown 也算进去。

4. 到点换姿势

# timer.finished 时
# 当前是坐姿 → 按 stand；否则 → 按 sit

补一条后来加的小改进：计时的本质其实是“当前姿势已经保持了多久”。所以不只“到点自动翻”会重置——你自己手动起坐切了姿势，30 分钟也从落位那一刻重新算，免得出现“刚站起来没几分钟又被翻回坐”的别扭。实现上就是监听桌子落到坐 / 站任一姿势、且 should_run 为 on 时，timer.start 30 分钟即可。

因为夜间 should_run 恒为 off、计时器被暂停，永远不会触发 finished，所以 23:00–07:00 的硬冻结是天然成立的，不需要额外拦截。

5. 录歌 / 开会怎么暂停

没有去逐个识别“LogicPro 在不在前台”“摄像头是否在用”这种又多又脆的条件，而是用一个 macOS 专注模式当总开关：用「快捷指令」建两条个人自动化，专注模式打开 / 关闭时各 curl 一个 HA Webhook，HA 翻转 input_boolean.desk_pause_focus。单一真相来源，干净。

三个把我卡住的坑（这次最值钱的部分）

坑一：macOS 26 的“本地网络隐私”按二进制授权

我一开始让 Mac 端脚本直接用 mosquitto_pub 把数据发给树莓派上的 broker。手动在终端跑——成功；交给 launchd 后台跑——runs 在涨、退出码 0，但 broker 一条都收不到。

换成 Python 直连，报错变清晰了：[Errno 65] No route to host。但同一个 launchd 上下文里，curl 访问树莓派却返回 200。

结论：macOS 26 的本地网络隐私是按可执行文件授权的。终端里手动跑，进程继承了终端 App 的“本地网络”授权；launchd 拉起的无头进程是独立身份，没有这个授权，于是 Homebrew 的 python3 / mosquitto_pub 访问局域网被静默拒绝。而 /usr/bin/curl 是苹果系统签名的二进制，被放行。

诊断的关键一步，是在同一个 launchd 脚本里同时试 curl 和直连 MQTT：

launchd 上下文：curl_to_pi=200      ← 网络是通的
launchd 上下文：mosquitto/python 失败 ← 只有三方二进制被拦

解法：让被放行的 curl 来跨局域网这一跳。Mac 不再直连 broker，而是 curl 一个 HA Webhook，由 HA 内部再 mqtt.publish。这样既绕开了本地网络隐私，又保住了 broker、最小权限账号和 expire_after 安全网。

坑二：mosquitto_pub 在 launchd 下报 “Bad file descriptor”

其实就是坑一的“劣质报错”——socket 被本地网络隐私拒绝后，mosquitto 的网络循环踩到坏 fd，报成 Error: Bad file descriptor，把人往 stdin/fd 的方向带偏。换 Python 看到 No route to host 才认清真相。

坑三：中文 name 生成拼音 entity_id，跨实体引用全断

HA 里 MQTT / 模板实体的 entity_id 是由 name 做 slug 生成的。我图省事给传感器起了中文名 Mac 空闲秒数，HA 把它转成了拼音：

sensor.mac_kong_xian_miao_shu
binary_sensor.mac_zai_zhuo_qian

而我模板里引用的是英文 sensor.mac_idle_seconds —— 永远取不到值，at_desk 恒为 off。现象很迷惑：数据明明在面板上跳，传感器却一直 off。

（input_boolean / timer 不受影响，它们的 entity_id 取自配置里的键名，不是 name。）

教训：会被别的模板 / 自动化引用的技术实体，name 一律用英文，让 entity_id 干净可预测；中文留给 friendly name 是不安全的，它会进到 id 里。

附带还有个小坑：ioreg | awk '… exit}' 里 awk 命中即停，会给上游 ioreg 发 SIGPIPE，叠加脚本的 set -e -o pipefail，会让脚本拿到 idle 后“静默早退”，根本执行不到上报。把 awk 的提前 exit 去掉就好。

一点收获

这次最大的体会有两条。

一是把复杂判断拆成一串可独立灌值验证的布尔量：在桌前 / 未专注 / 非夜间，每一层都能单独 curl 一个值进去、再去数据库里读真值确认，排错时不至于面对一个黑盒。

二是跨平台自动化的魔鬼全在环境细节里，不在主逻辑：本地网络隐私按二进制授权、slug 的中文转拼音规则——这些东西配置语法上完全正确，却让整条链路静默失效。先把“每一跳到底通没通”验证清楚，比对着 YAML 反复读要快得多。

优客李李

技术笔记：十年前的 Flask 网站静态化，搬到 Cloudflare 免费托管

结论速览

为什么能静态化

导出

Python 2 → 3

验收：和线上逐行对比

部署：Workers 静态资源

S3 搬到 R2

域名

换 nameserver

切换

注册商

国内访问

顺手：博客图床收回仓库

让 AI 动手时的分寸

踩坑记录

还没做的

Mac mini 家庭服务器：一句话搭好一个工作台，项目已开源

家庭服务器是什么

服务一多，麻烦就来了

工作台：一个入口管理所有服务

在外面访问的几种办法

我的推荐：一个只有你能打开的专属网址

homelab-desk：让 AI 一句话搭好

顺手做了不同的风格

怎么用

适合谁

博客版补充

技术笔记：Mac mini 本地微调 Qwen3-TTS 声音

结论速览

整体结构

数据准备

转写：FunASR，不是 Whisper

切片规则

人工复核

训练脚本：官方 sft_12hz.py 的 4 处问题

内存：第一次跑进了交换

冻结文字嵌入层，有没有隐患

怎么判断像不像

结果

低内存方案

部署

踩坑记录

复现

还没验证的

Mac mini 内存买多大？M6、M5 Pro 选购这篇就够了

先看推荐

本地模型内存占用参考

个人本地服务器最佳选项：16GB

本地模型：M6 32GB

天天用 27B：M5 Pro 48GB 起

同时挂别的服务：64GB

2 万上下：Mac mini 还是 Mac Studio

硬盘：够用就行，后面外接

配置表和价格表

小钢炮 Mac mini 跑 27B，最快 35 token/s

我的机器和用法

跑起来到底多快

最关键的设置：前缀缓存

不同设置差在哪

4-bit 就够了

免审查版：能力一样，收益没测出来

MoE 模型：快，但吃内存

照着抄的配置

从哪儿用它

能不能一直开着

如果你想买，内存怎么选

Mac mini 跑 AI 视频：内存占多少，生成要多久？

内存：64GB 用不满，小内存也不能直接照着买

生成速度：短镜头够用，长片要等

推荐档和草稿档

硬盘也得算进去

台词要按格式写

参考图模式

自制 WebUI 已开源

总结

LogicPro智能速度自动匹配不标准的录制素材

给空调做一个“会睡觉”的定时器：Home Assistant + HomeKit 实战与踩坑全记录

先看最终成果