千里之豪的格物垛

SynoSync｜让群晖与 iOS 之间的文件同步真正「现代化」

2026-05-07T12:30:19.000Z

更新：1.0.8 或者更新的版本已增加 WebDAV 协议支持，所以就算没有群晖 DSM 系统的 NAS 现在也可以使用 SynoSync 啦～

开发背景：关于安全感与掌控感

一直以来，基于 Markdown 纯文本的 Obsidian 文档库给了我极强的安全感与掌控感。

在我的工作流中，NAS 承担着文档库托管与同步的核心角色。群晖 Drive 在 Windows、Mac、Linux 乃至 Android 平台上的体验都堪称出色，唯独在 iOS 端，这种连贯性戛然而止。

困境：iOS 上的群晖 Drive，为何不够「现代化」？

在 iOS 生态下，群晖 Drive 的同步范围被严格限制在自身的沙盒文件夹内（应该是考虑到旧版本 iOS 兼容性）。这意味着 Obsidian 无法直接调用 Drive 的同步能力来读取文档库。对于追求「全平台一致体验」的开发者来说，这成了最难受的断层。

Obsidian 的多平台同步方案现状

如果你想自建 Obsidian 文档库同步，目前主流方案的优劣对比清晰可见：


方案	优点	缺点
官方 Sync 服务	集成度最高，支持最完美	订阅制费用随空间上涨；隐私完全托付于第三方
iCloud	苹果原生支持，全家桶体验好	仅限 Apple 生态；大库订阅费高；同步状态黑盒化
自托管 + 插件 (如 Remotely Save)	空间不受限，隐私高度可控	需维护内网穿透及 WebDAV 服务；配置门槛较高

如果你和我一样，希望文档库具备更安全的托管方式，Remotely Save + WebDAV 依然是目前的权宜之计。但要获得稳定的体验，通常还需折腾 HTTPS、内网穿透、DDNS 或 Cloudflare。

那么，难道就没有一种方案，能让我们直接复用 QuickConnect 那种「开箱即用」的穿透能力与内外网自动切换逻辑，在免去繁琐穿透配置的同时，实现真正的文档库自动同步到任何地方？

我的「万级」文件同步噩梦

我的 Obsidian 文档库包含 26,000+ 个文件，总体积接近 10GB。

在这种规模下，单纯依赖 Obsidian 的前台插件同步，体验会呈断崖式下降。更棘手的是，常规插件方案很难像群晖官方 App 那样，根据网络环境（局域网 vs 公网）自动且智能地切换连接地址。

为了解决这些切肤之痛，我开发了 SynoSync。它的目标非常明确：

彻底解决「群晖 + iOS」用户的文档库同步难题。

SynoSync 能为你做什么？

1. 多账号与多任务的灵活管理

支持配置多台 DSM： 完美适配拥有多套群晖环境的进阶用户。
支持多同步任务并行： 你可以针对不同的 App、不同的本地路径，创建多条上传、下载或双向同步任务，灵活构建你的同步方案。

2. 覆盖全场景的同步模式

前台同步： 实时可见的极速同步。
大批量初始化： 针对首次同步或超大文件夹优化的传输模式。
后台静默同步： 无需干预，在系统允许的范围内自动对齐差异。
快捷指令触发： 联动 iOS 自动化，解锁更多高效玩法。

3. 直观的状态追踪

Activity 报告： 每一个文件的流转都清晰可查。
小组件支持： 无需打开 App，在桌面即可实时观察同步进度。

一些坦诚的局限性……

在开发 SynoSync 的这一个多月里，最让我抓狂的莫过于 iOS 严苛的后台机制。

众所周知，iOS 采用了近乎「墓碑式」的后台管理。对于 SynoSync 这种需要频繁进行网络请求、文件比对及高强度读写的 App 来说，后台环境极其不友好。为了实现优雅的「静默同步」，我尝试了各种姿势去突破限制，但必须承认：它的后台效果依然无法达到 Android 或 PC 端的随心所欲。

特别是在面对我那 2.6 万个文件的「巨型库」时，iOS 的后台限制会导致同步耗时拉长。

因此，SynoSync 提供的最终解法是：

先通过「前台大批量同步」完成沉重的初始化任务，后续的日常增量更新，则交给「后台比对」去静默完成。

如果你发现 SynoSync 发出了后台同步失败的通知，也不用惊慌，这只是 iOS 后台切断了 App 的后台网络权限（为了省电），SynoSync 会在下一个 iOS 允许的时间窗口重新尝试同步的。

下载地址

App Store

iOS 应用：唯记，限免

2026-04-02T08:28:19.000Z

开发背景

上大学时，我是看着一堆独立开发者的故事毕业的，Kavin、Magabits、八爷等等，他们在我的心里留下了一个执念。

在具备了实力（系统学习了编程）和财力（工作后有钱购买 💻 Macbook Pro）之后，我也终于着手开发出了一款自己的 App：唯记

那可是 2020 年，AI 还无法使用，SwiftUI 的文档也散落在互联网的各个角落的时代。「唯记」开发出来后，我想着如果有人也想用，就象征性地付费给我一块钱，这样我们都有光明的未来🐶。

当前营收状况

但，既然只有很少人看得到这个帖子，我也就不嫌丢人了：实际上这三年来用户数量始终没有突破1000，好吧，甚至没有突破500。

错误当然在我，因为我也并没有真正把它当作一个正经的可以盈利的 App 在运作。截止到目前也就3～400人在使用。相对应的，我这几年的 App Store 开发者账号付费已经轻松超过 1k 了。

我必须承认我不是一个合格的独立开发者（本来也不是……）😭，这款 App 也过于平庸，我现在终于接受了它的平庸，但我仍旧还没接受自己的平庸，即使 Github 的废案仓库一个接着一个地建，我还在努力爬行，我知道现在早已不是一个独立开发者的黄金时代，但心里总是放不下那种执念。

如果你真的喜欢

咳咳，总而言之，既然我一直没打算靠唯记赚钱，那设置这一块钱的付费反而是画蛇添足，现在永久免费啦～

如果你真的真的喜欢唯记的话：

App 本身的安装后占用是不超过15MB 的，应该足够轻量；
使用的是 iCloud 同步 Sqlite 数据库，绝对的隐私友好；
对苹果即将到来的 AI 支持应该是很好的（适配了 App Intent，方便 siri 调用）；
无内购、无广告、无账号绑定，现在也无需付费了，放心食用～
搭配 Quote/0 ，也很好玩哦～

下载地址

下载地址：‎V2RMB App - App Store

或者直接 App Store 搜索：v2rmb

为了解决 Openclaw 的 Token 恐怖消耗，我做了这些事……

2026-03-26T12:28:19.000Z

⚠️ Agent failed before reply: All models failed (17): github-copilot/claude-haiku-4.5: Provider github-copilot is in cooldown (all profiles unavailable) (rate_limit) | ……………………………… github-copilot/gpt-5: Provider github-copilot is in cooldown (all profiles unavailable) (rate_limit).

Logs: openclaw logs –follow

从 2 月给树莓派装上 Openclaw 开始，我的 Copilot Pro 订阅就被过度消耗了，自己平时写代码拼命去用也很难用完的 300 次 PR （高级模型请求次数），Openclaw 两天就可以用完，所以对这种消耗焦虑就一直萦绕在我心中。到了 3 月，我就尝试了些折腾方式来跟踪我的 Token（PR）用量。

使用低速率模型（Flash、 mini）

使用低速率模型的确可以给消耗打三折，但低速率模型也会带来模型降智，降智后好多任务需要我反复纠错，一来二去省掉的模型用量还是浪费了。

增加监控手段

Openclaw 有时候经常会不声不响地跑大半天，在我看不到的地方消耗大量的 Token 但没有产出任何有效的产物；有时候又会摆烂，跟聊天网页一样，我说一句，他后台跑10分钟就歇菜了，我还得频繁去打开网页问他状态，所以监控 Token 的消耗趋势可以得知 Openclaw 是否在后台正常的工作。

1、Quote/0 墨水屏监控

3、Android 小组件监控 ( HTTP 快捷指令 )

const payload = JSON.parse(response.body)
const usageItems = payload && payload.usageItems

let gross = 0

if (usageItems && usageItems.length) {
  for (let i = 0; i < usageItems.length; i++) {
    const item = usageItems[i]
    if (item && item.product === 'Copilot') {
      gross += Number(item.grossQuantity || 0)
    }
  }
}

// 计算百分比
const usagePercent = (gross / 300) * 100

// 使用 toFixed(1) 保留一位小数
const formattedPercent = usagePercent.toFixed(1)

setVariable("Copilot", 'Copilot: ' + formattedPercent + '%')

JavaScript

改用 Github Agent + Action

当你深入使用 Openclaw 了一段时间之后，你很快就会发现他的瓶颈，你让他做简单的事情，他可以很快帮你搞定，但你如果让他帮你开发项目，随着项目的功能复杂度上升、业务逻辑逐渐展开给大模型后，Openclaw 很快就开始失控了：它会反复在一个地方出错，或者改好了一个地方后又会在另一个地方出问题。这不仅仅消耗你大量 Token，还会消耗你大量时间和精力，反反复复好几次之后，你会像我一样萌生这样一个想法：我自己写都比让他改要强。

但好在 Openclaw 已经搅动了 Agent 的整个格局，现在其他家也已经在自动化 Agent 助手功能方面做了不小的升级，以我现在在用的 Github Copilot 的订阅为例，如果你是开发工程师，并且有一定的框架思维的话，你完全可以站在架构师的层面上（其实没有也行，问 AI 就好了），使用 Github 的 Agent + Action 实现不输于 Openclaw 的工程开发能力，这种方式会让整个工程在规模逐渐庞大之后仍旧保证基本可控，而且消耗的 Token 量要小非常多。

同样可以运行测试，甚至可以运行无头浏览器测试！！

当然了，Copilot 也有犯蠢的时候：

但相对于 Openclaw 项目复杂度上升后 Token 消耗也指数级上升，这种可控的消耗方式还是更容易让人（我）接受～

升级 Copilot Pro +

如果你已经开始用起来这个 Github Copilot，那么恭喜你，你已经使用 10 美元雇佣了一个能力超强的开发工程了，他任劳任怨，随叫随到，你可以一天分配给他 10 个开发任务，然后坐等他叫你验收就好了。

如果你还想继续扩大你的公司规模，可以升级 Github Copilot Pro +，39 刀，你就可以额外再雇佣 4 名能力非凡的开发工程师。

上海复旦五官科医院，2026 年全飞秒激光二代，手术分享

2026-02-04T17:28:19.000Z

我的眼部情况

超过 15 年戴眼镜的经历，受够了眼镜雾气、下雨躲雨、低头扶镜框、不戴眼镜啥也看不清等等各种不便
大概近视度数：左边 300 + 100 散光，右眼 350
2023 年做过一次检查，当时医生说我可能有青光眼，不适合做全飞秒，可以尝试准分子，我拒绝了
当时我还额外挂了专家号，专家说需要一年后复查，看下青光眼的可能性

2026 年 1 月 5 号，术前检查，耗时：整个下午

医院：上海复旦大学附属眼耳鼻喉科医院（宝庆路分院）
挂号：刘盛涛（那天下午只有他有号，其他医生的号都满了，哈哈）
过程：
1. 网上银行或者医院一楼挂号，可以在一楼缴费或者挂号处缴费
2. 到对应医生所在楼层（一般在 4、5 楼）进行就医签到
3. 签到后，在同楼层，找到服务台，领取必要的术前检查流程指导书，指导书会详细告诉你每一步需要做什么检查
4. 按照指示到不同的房间做各种检查，这个过程会持续超过 2～3 小时，其中包含但不限于：
- 角膜地形图
- 验光（精确查看近视程度、散光度数）
- 扩瞳，也叫散瞳，做完之后会有一点儿畏光，因为眼睛的瞳孔被用扩瞳药水强行散开，进光量无法控制，应该是为了方便医生检查眼内的各种细节
- 眼底检查（青光眼、眼部各种潜在病变）
  - 多说一句，排在我前边的哥们儿，查到这一项的时候，医生说他眼睛里有个小洞，需要赶紧用激光手术封上，否则会越来越大……显然，在封上之前，他没办法做激光手术，医生说做完修补手术后，如果一切正常，可以再考虑做激光手术。
- 各种红色、白色的激光照射检查……
1. 所有检查做完之后，就可以拿着检查报告去找最初你挂号的医生去做诊断了，医生会告诉你，你适不适合做手术，以及什么时候可以做手术（预约手术时间）
2. 如果你决定要做手术，就直接上 6 楼，护士服务站会给你一个术前准备说明，还会跟你讲术前几天需要准备的

2026 年 1 月 13 号，手术前抽血，检查血常规、梅毒、艾滋等等（为了自己也是为了医生的安全）

因为是 1 月 14 号手术，如果在手术相同的医院抽血检查，只需要提前一天，而且抽完血直接就可以走，不用等报告，同医院的信息系统是相通的，如果不是在同一家医院抽血，就需要把其他医院的抽血报告在手术当天带到医院。

2026 年 1 月 14 号，手术

因为做完手术之后，眼睛有接近半小时几乎什么都看不到，就算能看到，重影也会非常严重，所以强烈建议带一个人陪同。

到场之后，直接到 6 楼签到，护士站会给你额头上标记，还会带一个手术信息手环
到自动缴费机去交费（2W+）
到 1 楼提前把后期要用的眼药水领了（主要作用：消炎、人工泪水）
等待手术叫号（根据情况而定，可能持续两个小时，所以该吃吃、该睡睡）
叫号后，把眼镜、外套等等内容全部给家属，到手术准备室门口
穿鞋套、手术服、坐在等待区
首先，会有一个护士过来确定你的身份和信息，以及你的手术内容、主刀医生
其次，会有一个护士过来帮你做眼部消毒，消完毒之后眼睛会有点儿难受，不好睁开，闭起来就好了，等待最终手术叫号
然后，会有一个护士过来叫你，带你去手术室（扶着你）
躺在手术床上，护士会再次确认你的身份、手术内容、主治医生信息
主治医师到场，让你躺在床（手术台）上，开始手术准备
护士会帮你滴眼药水（眼球表皮麻醉）
医生把眼皮撑放在你的右眼，把激光工具放在你眼睛上，你盯着激光的绿点，大概十秒钟左右，机器吸附到你的眼球（因为麻醉了，所以几乎不会有任何感觉），完成扫描、锁定、激光作业，完成后你的右眼会变成模糊的白色，这个时候什么也看不到（因为已经在角膜里切出来了一个镜片，中间有空隙，所以一片白），持续大概十几秒钟。
医生会立刻取出右眼眼撑，放到左眼，再重复刚刚右眼的步骤，这样之后，你两只眼都是白茫茫的一片了。这个过程也是持续大概十多秒钟
医生会立刻使用镊子，取出激光切割的左眼的多余角膜，取出后，立刻把眼撑切换到右边，继续取出右边的多余角膜，眼撑可以取出了。这个过程大概也就半分钟。
截止到目前为止，手术过程基本上就结束了，这个时候你基本上什么也看不清，世界非常的模糊，只能看到大概的轮廓，护士会协助你走到术后观察室，坐大概 5 分钟，这个过程中，护士会告诉你术后注意事项和用药注意事项（你大概记不住，但她给你的单子里什么都有写，拿着给当日陪同的家属就行）。然后会告诉你：觉得没什么异常就可以走了，因为你这个时候已经可以模糊的看清走廊的大概轮廓了，但是非常模糊，需要去找家属，然后坐下来休息一下。

没错，整个手术过程，从开始准备手术，到手术结束，一共就十几分钟。而真正的手术部分可能就短短一两分钟。

2026 年 1 月 14 号，手术后半小时

需要每隔 5 ～ 10 分钟滴一种眼药水，具体眼药水会有说明清单（手术后护士给你的那张），可以坐在医院的等候室把最近半小时的眼药水滴完，这个过程中，眼睛会从完全模糊，变成逐渐能够看到一定的内容了，只是有非常严重的重影。眼睛开始有点酸，但不怎么痛。

2026 年 1 月 14 号，手术后一到两小时

眼睛逐渐可以看到世界的一些原本的样貌了，会一点点怕强光，还有手机基本上看不清楚，重影非常严重，但是看远处的房子、树木、都能够看到了，只是有一定的重影，会有点儿激动，尤其是戴了眼镜超过 10 年以上的人，会有一种隐隐的解脱感。

2026 年 1 月 14 号，手术后半天

手机基本上可以看到，但是重影比较严重，看久了眼睛会累，看电视、看远处、都只是有一些重影，但已经基本上可以看清了。感觉效果已经非常好了。

手术后第一天，复查

到院后直接去 2 或者 5 楼签到，找到术后复查的机器做签到
签到后，在大厅找到测视力的医生做视力检查，我这个时候已经双眼 1.2 了
到 206 专用复查室检查眼部状况（角膜地形图等等吧，我不太专业）
带着检查的报告去找主刀医生复诊，医生说：非常棒，按照用药单正常用药即可。

手术后第一周

注意事项：

眼睛不能进水。

正常用眼（不要过度用眼），我就正常使用手机、电脑、看电视。

重影（炫光）仍旧存在，医生说需要大概一个月左右才会彻底消失。

早上起床后，尤其是被公司顶灯的强光照久了之后，重影会比较严重，暗光下视力正常。

你会：

虚空扶镜框多次

睁开眼睛就能看到清晰的世界，不用再去找眼镜了

努力克服摘眼镜羞耻，现在是另一种模样了

术后第二周

保持正常滴眼药水，此时炫光的情况渐渐少了很多，眼睛也可以正常进水了，除了要定时滴眼药水，基本上不影响正常生活了。

早上视力会有点儿差，不知道是不是我的个人体质问题，之前带眼镜的时候，眼睛早上视力也比较差，眼部视力到下午和晚上之后就正常了。

看近处时间长了有点儿吃力，比如手机、捣鼓手工之类的东西等等，看久了眼睛会有点儿累，看不清，看远处一会儿可以缓解。

术后第三周（最新时间线 2026-02-04）

眼药水已经滴完了，也停了，没有干眼症、没有飞蚊症、视力仍旧是早上会比较差，到了下午会好很多，考虑到做手术之前眼睛状态也是这样，所以应该跟手术没关系，单纯是眼睛自己的状态如此。

做了第 20 天的复查，左眼仍旧 1.2，右眼视力来到了 1.5 ，我最开始以为是我的左眼视力下降了，没想到是右眼视力变得更好了。

平时也可以正常揉眼睛了（轻轻地），复查的时候医生也没说有任何问题，所以我这次手术大概率算成功啦～？

后记

如果你要做全飞秒激光手术，一定记得在手术前记录你眼睛的各种状态，方便在术后做对比，方可知道哪些是眼睛本来就有的症状，哪些是手术后出现的症状。

以上就是我做眼部全飞秒二代的全部过程了，后期如果有任何其他状况，我会继续更新。

手中设备的巨大变动，以及从 iPad mini 7 换到红米 K Pad 的感受

2025-12-14T22:55:38.000Z

10 月份到 11 月份期间，我手里的各种设备经历了较大变化，在此记录。

卖掉了手里的很多设备

1、Google Pixel 5 草绿色 🤖

买入理由：原生安卓、可以刷非常多第三方系统、轻、小、手感好，我需要安装一些 iOS 平台没有的第三方 App

买入价格：¥1000

卖出价格：¥520

持有时间：超过一年半

卖出理由：定位跟主力机 iPhone 冲突，屏幕不够大（相比较下边换购的安卓平板），电池容量小，电池健康82%，作为备用机也要两天一充。

2、iPad mini 7 256GB 星光色🫆

买入理由：需要性能强劲的小平板玩游戏、看视频

买入价格：¥3599

卖出价格：¥2550

持有时间：大半年

卖出理由：指纹识别经常失灵，经常需要手动输入密码，指尖稍微有点儿汗就识别不了！而且生态跟 iPhone 重合，在卖出了 Pixel 5 之后，手里没有设备用来安装 Android 软件，为后续购买安卓平板埋下伏笔。

3、汉密尔顿（Hamilton）墨菲 38 mm 全自动机械手表

买入理由：星际穿越🛰️

买入价格：¥5500

卖出价格：¥4000

持有时间：超过一年半

卖出理由：不伺候了，上弦效率差、日误差接近 15 秒、三天不戴就不走了、戴一周时差超过一分钟、需要反复上弦和反复调时间、只能看时间、机械表热情退烧了。

4、iPhone 5 16GB

买入理由：iOS 6 很精致，很超前，补偿当年没买过这款设备的遗憾。

买入价格：¥150

卖出价格：¥50

持有时间：超过两年

卖出理由：玩腻了。没有最新的软件生态支撑，这就是一个 MP4 + 诺基亚功能机，况且没有 4G 网络的支持也让它完全无法胜任带出门的重任。最最最主要的：我手里主力机 iPhone 13 mini 跟他体积也差不多。

买入了新的设备

设备买买卖卖，这一波设备置换基本上没花钱，但给到的情绪价值却实打实的高。感谢雷总，尤其感谢搞定了小米手环 NFC 的那位技术人员，还要感谢拓竹，让我可以在如此价格体验世界一流的 3D 打印。

1、红米 K Pad 12GB + 256 GB 流金白

购入价格：¥2650

购入理由：尺寸与 mini 7 类似，只有一个摄像头（简洁），支持人脸识别（但是 2D 人脸），卖掉了 iPad mini 7 和 Pixel 5 之后，一个安卓平板就可以同时替代这两款产品，它既可以方便地看视频、玩游戏，也可以安装非常多只有安卓平台才有的第三方软件，如果你稍微懂一些技术，相信我，这款平板肯定要比 iPad mini 强

推荐体验：🌟🌟🌟🌟🌟

备注说明：如果选择白色以外的颜色的话，价格可以便宜400以上，但没办法，俺就是喜欢白色，而且红米的白色背板质感非常高级，至少拿在手上不比 iPad mini 差。以及，现在流金白好像都买不到了，哈哈哈哈哈，庆幸我下单早～

2、小米手环 10 NFC 版 💳

购入价格：¥288

购入理由：冬天手腕上不想戴卡西欧的小银块，太冷了，而且太大体积了，本来就是抱着试一试的心态买的 NFC 版，没想到给我最多惊喜的也是这个 NFC，我小区的门禁卡、公司的电梯卡、公司机房的门禁卡，全部都可以被这个 NFC 版本所替代，真的是太强了！！！对了，他甚至可以看时间！！！而且这东西正常续航两周一充（14天以上），开了超级省电模式（仅开启计步、NFC、时间）之后，续航起码奔着一个月甚至两个月去了！！！

推荐体验：🌟🌟🌟🌟🌟🌟🌟🌟🌟🌟

多说一句：相比较之前戴过的 Apple Watch S5、全自动机械表-墨菲38 这类需要频繁 “人去伺候它” 的设备，我更喜欢像小米手环 10 NFC 这类解决问题而且不用过多维护的设备，更何况，200 多的价格，心率、血氧、运动、睡眠检测都可以用，还要啥自行车？

3、拓竹 P2SC 🖨️

购入价格：¥4266

购入理由：~~卖出墨菲38之后剩下的钱太多了~~ 自己倒腾的一些 DIY 设备需要外壳，反复去找打印农场快递来回时间太久了。

推荐体验：🌟🌟🌟🌟

多说一句：在上海这种寸土寸金的地方，我住在公租房里，家里还有两只经常认为电线是老鼠尾巴所以经常咬线的猫咪的情况下，想要放置一款噪音大、需要干燥环境的打印机还是有些挑战的，所以暂时给 4 颗星，是评给自己的贫穷😭；另外，学习了 Fusion 360 之后，我才知道原来建一个模型原来可以如此简单～

自己设计并打印的模型（给超市墨水屏设备更换 5V 电池盒、新的外壳和可插拔支架）：

安卓平板必装软件

以下链接皆为直链，部份可能需要更优质（🪜）的国际网络才能访问！！！

B站第三方客户端：
- PiliPlus（我认为 Android Pad 适配最好）
- PiliPala（平板适配不如前者，但也很不错了）
Yotube 第三方客户端：NewPipe
Mihon：Komga 安卓第三方（最强）看漫画客户端
Animeko：Bangumi + Bilibili，你可以理解成使用网络公开（盗版）资源的看番客户端，当然，阉割更少，可以看弹幕！！！
Aves：简单纯粹的安卓第三方相册
RSS 工具：
- Feed Me：RSS 工具届的老大哥，支持批量图片预缓存，对图片较大的订阅源异常友好。我从 Android 5 一直用到 Android 16
- Read You：RSS新秀，仿照 iOS 端的重磅RSS 工具 Reeder 开发，界面现代且简洁
Anx Reader：纯粹的 txt 阅读器，这不一定是最好的，但是我最近找到的最纯粹的

我还缺什么安卓平台的应用

管理 PDF（按照文件夹分类）的阅读应用
推特（X）第三方客户端

如果你有什么好的推荐，评论区见～

借助捷径，不写代码也能玩转 Quote/0 墨水屏

2025-11-13T11:00:00.000Z

少数派首发（少数派网站同名作者：千里之豪）

墨水屏一直是我非常偏爱的产品形态：低功耗、不依赖背光，同时具备可刷新特性，几乎天生就是为信息看板而设计的。遗憾的是，我并非硬件工程师出身，始终没能亲手做出一块完全符合自己需求的墨水屏。

几年前，我购买了两块超市电子价签，并在好奇心的驱动下，逆向分析出它们的蓝牙通信协议，由此写下了《抓包解协议，代码造布局：电子墨水价签改造 NAS 监控屏小记》。

也正因如此，当 Quote/0 出现时，我格外期待。它在官方丰富模板之外，还提供了更灵活的数据更新方式，可以直接通过苹果的捷径（Shortcuts）进行扩展，让墨水屏的玩法不再局限于预设场景。

如何驱动 Quote/0 更新

要在日常中使用 Quote/0，主要依赖以下三点：

对捷径 App 的基本操作（Shortcuts）
官方或第三方 App 对 Siri Intent 的支持
Quote/0 的设备码和 API Key

通过这些条件，就能构建出灵活的自动化更新方案。下面以几个场景为例。

场景一：日程提醒

捷径 + 日历 App + Quote/0 文字 API

苹果自带的日历应用可以与捷径配合，获取即将到来的日程信息，再通过 Quote/0 展示在墨水屏上。

iOS 日历日程安排，在 Shortcuts 里用来请求更新 Quote/0

效果示例：

场景二：节假日查询

捷径 + 休息日 App + Quote/0 文字 API

「休息日」是一款提供节假日信息查询的 App，全面支持 Siri Intent。通过配置捷径触发流程，可以快速获取节假日安排并同步到 Quote/0。

休息日模板 - 复制上一个配置 - 休息日提供的 Siri Intent

示例效果：

场景三：生日 / 纪念日提醒

捷径 + 唯记 App + Quote/0 文字 API

「唯记」是一款专注于生日和纪念日提醒的 App，同样支持 Siri Intent 调用。借助捷径，你可以灵活获取倒数日信息并投放到墨水屏。

效果示例：

自动化轮播

在捷径 App 中切换到底部的「自动化」标签，点击右上角「添加」，选择「特定时间」后，绑定之前配置好的快捷指令。接着，可以根据需求设置不同时间段展示的不同信息。

这样一来，Quote/0 就能与手机信息保持同步，实现自动摘要与定时轮播，让它真正成为一个动态更新的桌面信息小组件。

iOS 捷径自动化配置

进阶玩法：图片 API

文字展示并不是终点。Quote/0 更强大的能力在于 图片 API 更新。在 Node.js 环境下，可以使用虚拟 Canvas （无需借助浏览器或客户端）动态生成画布，并输出图片，再推送到墨水屏，实现更丰富的视觉效果。

例如下图的黄金走势图：

相关示例代码已更新至 GitHub 仓库，供参考与拓展。

写在最后

Quote/0 的出现，让墨水屏的使用方式变得前所未有的灵活。通过捷径、Siri Intent 和 API 的结合，每个人都可以根据自身需求，快速定制出独一无二的应用场景。

当然，这种玩法也高度依赖应用开发者对 Siri Intent 的适配，如果没有适配，就只能走写代码这条老路了，但借助 AI 大模型，现在好像也不是不可逾越的高墙了，勇敢的少年啊，赶紧去尝试吧～

用刚学的 PCB 知识做一个优雅的树莓派风扇控制板

2025-10-16T19:52:19.000Z

首先我不是EE（电子电路工程师），所以对电路一窍不通，但人就是这样，越菜越爱玩。所以如果你是EE的话，不要被我的电路图蠢到（不要骂我）。

我的家里就好几个树莓派，一些是我大学的时候做小任务的低功耗服务器用，另外一些是工作的时候，自己测试一些硬件用，跑一些边缘服务之类的。

树莓派旧风扇长期通电运行报废

我大学期间给树莓派 3B 配备的风扇在通电时间超过三年之后还是在最近寿终正寝了（作为一个4块钱的风扇而言，已经很抗造了），于是我就在想，为什么不做一个根据 CPU 温度动态控制风扇转速的模块，来延长风扇的寿命呢？说干就干。

众所周知，树莓派最新的 5B 系列已经有了成熟的风扇控制接口了。

图片来自：树莓派官网

网络上风扇开关电路简单明确，但不够优雅简洁

但我手里的好几个 3B 和 4B 这两个系列都没有呀，我也想要一个更加优雅的、模块化的接口，而不是临时的像这种：

基础原理图，来自 shumeipai.nxez.com

图片来自：CSDN 用户 luzze_123

图片来自：CSDN 用户 qq_40251961

PCB 速成，嘉立创启动！

但我不会画电路板，更不了解各种电子电路相关的知识，只好去折磨 AI 了 😄。

但其实每个人都是有一定的电路基础的，正负极、开关。所以我选择了更加速成的方式：
【保姆级】二十分钟零基础PCB绘制打样一条龙教程（立创EDA专业版）

只需要按照这个视频教程，你就可以在半小时左右学会最基础的 PCB 板的绘制技巧，我也是顺利地完成了第一版绘制

第一版电路图

如果你是比较懂电路的话，你肯定已经看到问题所在了，没错，我把三极管放在了 5V 正极了，导致板子到手后风扇的转速非常慢，有时候甚至转不起来，即使已经通过 GPIO 把电路导通了，风扇还是不转或者转的非常慢，我就不瞎分析了，放出 AI 的分析：

把 8050 放在正极（高侧）当“开关”用了 —— 8050 是 NPN 晶体管，做高侧开关时它会工作在发射跟随（emitter-follower）模式，发射极电压 ≈ 基极电压 − 0.7V。GPIO 给的是 3.3V，发射极最多 ~2.6V，风扇的电源是 5V → 风扇只拿到 ~2.6V，自然转得很慢。

我理解下来就是：三极管放正极会对电压电流有较大损耗，导致风扇工作所需功率不足。

第二版电路图

于是重新去嘉立创领券，重新打板，重新焊接电路，重新测试，可以了！！！

再配合 Python 脚本，和亿点点配置，一个全自动的风扇控制模块就做好了！

安装效果图

模块大小示意（对比 Type-C 接口）

总花销：

买电子元器件（S8050、排针、排母）：9元
电烙铁基础套装（松香、焊锡丝、锡棉，支架）36.9元

然而这一趟折腾下来，我发现花销已经足够我买好多小风扇了，好在电烙铁可以反复使用，电子元器件也只消耗了一小部份，以后折腾其他东西也能用～

解除 GPIO 14 的串口占用，用来当做开关信号

当前这个模块占地较小，但也有代价，它使用的是GPIO 14进行电路开关控制，GPIO 14 在树莓派上原本是被串口通信功能占用，如果你跟我一样不使用串口功能，可以这样关闭掉：
sudo raspi-config

Interface Options → Serial Port

Would you like a login shell to be accessible over serial? → No
Would you like the serial port hardware to be enabled? → No

完成后退出并选择 Finish，允许它重启。

重启后：

sudo vim /boot/firmware/config.txt

确认或添加以下内容（顺序重要）：

# 禁用蓝牙，释放 UART
dtoverlay=disable-bt

# 确保主 UART 关闭
enable_uart=0

1	sudo systemctl disable hciuart.service

1	sudo systemctl mask hciuart.service

1	sudo reboot

验证 GPIO 14 状态：

pinctrl get 14

应显示：

1	GPIO 14: level=0 func=INPUT

（或类似 function INPUT），没有出现 ALT0 / TXD0 / RXD0。

此时即可用作普通 GPIO。

如果你需要串口功能，则可以使用另一种方案代替

这是另一个版本，它不占用串口功能，使用 GPIO 4 进行开关控制，最终组件也会相对应长一些

风扇控制脚本

Python 脚本：

import RPi.GPIO as GPIO
import time
import signal
import sys

# 控制风扇的GPIO（BCM编号）
FAN_GPIO = 14

# 温度阈值（摄氏度）
HIGH_TEMP = 45.0  # 高于此温度开启风扇
LOW_TEMP = 42.0   # 低于此温度关闭风扇

# 检查间隔（秒）
CHECK_INTERVAL = 5

# 设置GPIO模式
GPIO.setmode(GPIO.BCM)
GPIO.setup(FAN_GPIO, GPIO.OUT)

# 初始状态关闭风扇
GPIO.output(FAN_GPIO, GPIO.HIGH)
fan_status = False

# 获取CPU温度的函数
def get_cpu_temperature():
    try:
        with open('/sys/class/thermal/thermal_zone0/temp', 'r') as f:
            temp = float(f.read()) / 1000.0
        return temp
    except Exception as e:
        print(f"无法读取CPU温度: {e}")
        return None

# 控制风扇的函数
def control_fan(temperature):
    global fan_status

    if temperature >= HIGH_TEMP and not fan_status:
        GPIO.output(FAN_GPIO, GPIO.HIGH)  # 开启风扇
        fan_status = True
        print(f"温度: {temperature}°C - 风扇开启")
    elif temperature <= LOW_TEMP and fan_status:
        GPIO.output(FAN_GPIO, GPIO.LOW)  # 关闭风扇
        fan_status = False
        print(f"温度: {temperature}°C - 风扇关闭")
    else:
        status = "开启" if fan_status else "关闭"
        print(f"温度: {temperature}°C - 风扇保持{status}")

# 优雅退出处理
def signal_handler(sig, frame):
    print("\n正在关闭程序...")
    GPIO.output(FAN_GPIO, GPIO.LOW)  # 确保风扇关闭
    GPIO.cleanup()  # 清理GPIO资源
    print("风扇已关闭，程序退出")
    sys.exit(0)

# 注册信号处理
signal.signal(signal.SIGINT, signal_handler)
signal.signal(signal.SIGTERM, signal_handler)

# 主循环
print("开始监控CPU温度并控制风扇...")
print(f"温度阈值: 高于{HIGH_TEMP}°C开启, 低于{LOW_TEMP}°C关闭")
print("按 Ctrl+C 退出程序")

try:
    while True:
        temperature = get_cpu_temperature()
        if temperature is not None:
            control_fan(temperature)
        time.sleep(CHECK_INTERVAL)
except KeyboardInterrupt:
    signal_handler(None, None)
except Exception as e:
    print(f"程序运行出错: {e}")
    GPIO.output(FAN_GPIO, GPIO.LOW)
    GPIO.cleanup()

Python

自动化服务配置

[Unit]

Description=Fan control Service

After=network.target

[Service]

Type=simple

WorkingDirectory= # 这里替换成python脚本所在目录

ExecStart=/usr/bin/python3 # 这里替换成python脚本的绝对路径

Restart=always

RestartSec=10

StandardOutput=syslog

StandardError=syslog

SyslogIdentifier=fan-control

# 环境变量（如果需要）

Environment=PYTHONUNBUFFERED=1

[Install]

WantedBy=multi-user.target

Makefile

把上边这个脚本保存到

/etc/systemd/system/fan-control.service

然后依次执行:

重新加载服务文件

sudo systemctl daemon-reload

启动风扇控制脚本服务

sudo systemctl start fan-control.service

检查运行状态

sudo systemctl status fan-control.service

设置服务开机自启动

sudo systemctl enable fan-control.service

如果发现服务启动异常，可以通过这个命令来查看异常原因

sudo journalctl -u fan-control.service -n 50

效果

Oct 16 13:23:42 raspberrypi fan-control[2004]: 温度: 44.008°C - 风扇保持关闭
Oct 16 13:23:47 raspberrypi fan-control[2004]: 温度: 44.546°C - 风扇保持关闭
Oct 16 13:23:52 raspberrypi fan-control[2004]: 温度: 45.084°C - 风扇开启
Oct 16 13:23:57 raspberrypi fan-control[2004]: 温度: 45.084°C - 风扇保持开启
Oct 16 13:24:02 raspberrypi fan-control[2004]: 温度: 44.008°C - 风扇保持开启
Oct 16 13:24:07 raspberrypi fan-control[2004]: 温度: 43.47°C - 风扇保持开启
Oct 16 13:24:12 raspberrypi fan-control[2004]: 温度: 43.47°C - 风扇保持开启
Oct 16 13:24:17 raspberrypi fan-control[2004]: 温度: 42.932°C - 风扇保持开启
Oct 16 13:24:22 raspberrypi fan-control[2004]: 温度: 41.856°C - 风扇关闭
Oct 16 13:24:27 raspberrypi fan-control[2004]: 温度: 41.856°C - 风扇保持关闭
Oct 16 13:24:32 raspberrypi fan-control[2004]: 温度: 41.856°C - 风扇保持关闭
Oct 16 13:24:37 raspberrypi fan-control[2004]: 温度: 41.318°C - 风扇保持关闭

备注

嘉立创领券链接，感谢嘉立创！😄
我跑通了这个PCB验证，也写完了这篇文章后，才发现很久之前（2021年）就有其他人做过：可以参考「夸克之书」的文章，哎，早点儿看到就能少走很多弯路了。

Google Pixel 5 更换 Lineage OS

2025-08-28T17:28:19.000Z

当过社畜的都知道，以季度为施工周期的项目，进入 8、9 月份基本上到了项目的加速或是冲刺期，所以整个 8 月份都在赶项目进度；

外包项目倒是也接触了好几个，但都停留在了技术咨询阶段，0 入账；

尝试用 Raspberry Pi 4B 和 Qwen3 0.6B 模型进行 Edge Ai + 自动联网分析的应用开发，用 Python 做出来之后发现效果略差于手机上的 App ，又是无功而返的三个晚上；

8 月就这么碌碌无为地溜了过去，整个人感觉好像什么都没做，那就刷个机吧！

我的备用 Android 手机是 Pixel 5，官方已经永久停止系统支持了，当前的系统最新版本停留在 Android 14.

但我看到了 Android 15 有非常吸引人的优化系统系能的更新（ page size 16 kb），所以就特想升级，由于之前使用过 Lineage OS，所以就打开了它的官网，果然支持，直接刷入～

Lineage OS for Pixel 5

刷入后发现了很多原生系统不支持的特性，太惊喜了！

官方支持的 16kb 分页，App 打开效率提升
电池健康度检测
充电控制（最大充到多少）
状态栏展示网速（老传统了，其实没啥可说的，但原生没有）

还得是 Pixel，官方不支持社区也会支持。

我感觉下一个版本的 Lineage OS （Android 16）理论上来说也能支持，

感谢 Lineage OS 。

期待一波～

在上海公租房：一名租客的首次居委会体验

2025-07-05T22:28:19.000Z

⚠️ 无图警告 ⚠️

背景：新居的烦恼

刚搬进上海某社区的公租房🏠不久，我就和邻居们遇到了两个棘手问题：

电梯故障频发🛗： 三个月内报修四次！在一梯四户的高层单元楼里，这简直是灾难。高峰期拥堵不堪。
停车位严重短缺🅿️： 小区地下车库有上千车位，但划给公租房租客的仅有约80个。更糟的是，大量车位被锁死或遭占用，租客停车难上加难。

线上群聊沟通无效后，有邻居拨打了 12345 市民热线☎️投诉。很快啊，街道办就在两天后组织召开了这次居委会会议。

会议进行时

时间调整⏰： 最初通知是周三下午两点半，立刻在公租房群被集体“Diss”——工作日上班时间谁有空？最终会议改到了晚上 7:30。
地点： XXX小区街道办会议室
参会方：
- 政府代表：工商局XX老师、住建局XX老师、网格员、区XX书记
- 管理方：物业公司经理（2位）、公租房管家XX
- 租户代表：公租房租客代表（2人）、普通公租房租客（8人）
- 会议记录员（1人）

议题一：电梯困局🛗

问题核心： 电梯频繁显示“Out of Service”，迫使所有人挤用另一部电梯，在20+层、每层8户、仅2部电梯的情况下，高峰期完全瘫痪。

物业分析故障原因：

垃圾堵门🗑️： 乘客遗留的垃圾被踢到门缝，遮挡光栅，导致电梯无法关门，触发保护机制停运。（监控曾拍到保洁🧹阿姨将垃圾扫入门缝！）
快递堵门📦： 快递员用小推车或快递故意挡住电梯门，以便一趟送完所有楼层。
设备替换件故障🔧： 硬件老化或损坏。

可见，人为因素（有意或无意）是主因。

讨论与解决方案：

垃圾堵门🗑️： 物业已通知保洁🧹部门重点清扫电梯门缝区域，杜绝垃圾堆积。→ 此方案获一致好评👍。
快递堵门📦： 物业提议在一楼设置快递柜和外卖柜🥡，让居民自取，减少电梯占用。
- 遭遇强烈反对👎： 住户认为这反而会增加大家下楼取件的次数，加剧电梯🛗使用负担。提议作罢。
设备故障🔧： 住户建议增加预防性检修频次，避免故障后才更换配件。→ 电梯维保🔧部门采纳。

议题二：停车位争夺战🅿️

这是小区的“老大难”问题。

现状：

小区规划车位超1600个，租客固定车位仅约80个，其余属业主和开发商。
即使这80个“专属”车位，也常被业主或临时车占用！
更甚者，开发商为逼迫业主购买车位，锁死🔒了大量包含租客车位的临时区域，导致办了长期停车证的租客也无位可停。

会议交锋与决议：

居委会强硬指令📢： 责令物业一周内解决问题，必须确保政策规定数量的车位切实留给公租房租客。“到期不拆锁🔒，住建局将强拆💥！”
物业经理的“难题”（与态度）： 一位经理提出（带着被多位在场租客形容为“幸灾乐祸😏”的表情）：“负一层租客车位只有20个，负二层的又离你们单元楼太远，怎么安排呢？”
书记的机智回应💡： “能申请上公租房的租客，智商比我们这些人都高！这个问题不用你操心，你只管拆锁🔒！”
租客提议（获认可✅）：
1. 采用车牌登记制📝，租客提交私家车信息。
2. 通过公平抽签🎲分配80个固定车位。
3. 物业根据抽签结果，将车牌号与车位绑定，严格管理，防止占用。

感想：被看见的租客

在上海工作多年，这是我第一次作为租客感受到如此切实的尊重，说实话，有点受宠若惊。

以往租住合租公寓或二房东的房子，我们既无时间也无渠道接触居委会（疫情😷封控时期除外）。这次能直接反馈问题，并看到问题被认真对待、推动解决，感觉非常棒✨。

至少在这一刻，我想感谢公租房制度。它让我第一次在大城市里，真切地体会到自己是一个手握议事权利、能参与社区事务的公民🗳️。

如果租房环境都能有这样一套机制来保障租客的合法权益，那么，一直租房下去，又有何不可呢？

“They’re not paying me enough to care”（转载）.md

2025-07-05T20:28:19.000Z

This is an understandable sentiment. As jobs push people to be automatons and often offer little in the way of respect, it’s easy to quietly quit.
But perhaps, they’re not paying you enough to not care.

Spending your days, day after day, not caring is a tragedy.

They might not deserve your focus and effort, but you do.

DeepL 翻译：
“他们付给我的钱不够我关心”

这种情绪是可以理解的。因为工作会把人逼得像机器一样，而且往往不会给人什么尊重，所以很容易悄悄辞职。

但也许，他们付给你的薪水不足以让你不在乎。

日复一日地漠不关心是一种悲剧。

他们可能不值得你关注和努力，但你值得。

本文来自于博友 Luozx 在本博客《有些工作不值得投入太多》文章中的评论推荐，转载自 seths.blog ，原文链接。

千里之豪的格物垛

SynoSync｜让群晖与 iOS 之间的文件同步真正「现代化」

开发背景：关于安全感与掌控感

困境：iOS 上的群晖 Drive，为何不够「现代化」？

Obsidian 的多平台同步方案现状

我的「万级」文件同步噩梦

SynoSync 能为你做什么？

1. 多账号与多任务的灵活管理

2. 覆盖全场景的同步模式

3. 直观的状态追踪

一些坦诚的局限性……

下载地址

iOS 应用：唯记，限免

开发背景

当前营收状况

如果你真的喜欢

下载地址

为了解决 Openclaw 的 Token 恐怖消耗，我做了这些事……

使用低速率模型（Flash、 mini）

增加监控手段

1、Quote/0 墨水屏监控

2、iOS 小组件监控 （Http Widget）

3、Android 小组件监控 ( HTTP 快捷指令 )

改用 Github Agent + Action

升级 Copilot Pro +

上海复旦五官科医院，2026 年全飞秒激光二代，手术分享

我的眼部情况

2026 年 1 月 5 号，术前检查，耗时：整个下午

2026 年 1 月 13 号，手术前抽血，检查血常规、梅毒、艾滋等等（为了自己也是为了医生的安全）

2026 年 1 月 14 号，手术

2026 年 1 月 14 号，手术后半小时

2026 年 1 月 14 号，手术后一到两小时

2026 年 1 月 14 号，手术后半天

手术后第一天，复查

手术后第一周

注意事项：

你会：

术后第二周

术后第三周（最新时间线 2026-02-04）

后记

手中设备的巨大变动，以及从 iPad mini 7 换到红米 K Pad 的感受

卖掉了手里的很多设备

1、Google Pixel 5 草绿色 🤖

2、iPad mini 7 256GB 星光色🫆

3、汉密尔顿（Hamilton）墨菲 38 mm 全自动机械手表

4、iPhone 5 16GB

买入了新的设备

1、红米 K Pad 12GB + 256 GB 流金白

2、小米手环 10 NFC 版 💳

3、拓竹 P2SC 🖨️

安卓平板必装软件

我还缺什么安卓平台的应用

借助捷径，不写代码也能玩转 Quote/0 墨水屏

如何驱动 Quote/0 更新

场景一：日程提醒

场景二：节假日查询

场景三：生日 / 纪念日提醒

自动化轮播

进阶玩法：图片 API

写在最后

用刚学的 PCB 知识做一个优雅的树莓派风扇控制板

树莓派旧风扇长期通电运行报废

网络上风扇开关电路简单明确，但不够优雅简洁

PCB 速成，嘉立创启动！

第一版电路图

第二版电路图

解除 GPIO 14 的串口占用，用来当做开关信号

如果你需要串口功能，则可以使用另一种方案代替

风扇控制脚本

自动化服务配置

效果

备注

Google Pixel 5 更换 Lineage OS

在上海公租房：一名租客的首次居委会体验

背景：新居的烦恼

会议进行时

议题一：电梯困局🛗

议题二：停车位争夺战🅿️

感想：被看见的租客

“They’re not paying me enough to care”（转载）.md

2、iOS 小组件监控（Http Widget）