2026-04-20 23:29:39
现在智能手机基本是每个人不可缺少的设备了，也可以说是我们的外接器官。玩手机可能是我们一天花时间最多的事了。但我最近捋了一下手机的作用，发现真正离不开手机的功能其实很少，大部分使用时间都花在了锦上添花甚至不必要的功能上。你可以对照看看，你平时用手机最核心的功能是什么。
真正没有手机不行的功能，其实就那么几个。 扫码，现在不管是付款、登录、还是乘坐交通工具，都得扫码，电脑做不了，手表也做不了。拍照，虽然相机拍得更好，但随身带着随时能拍的一般还是手机。钱包，虽然有的手表也能付款，但很多场景还是得掏手机（转帐/红包/扫码）。导航，手表屏幕太小不行，电脑更不支持。还有电子身份证、电子驾照这些身份证明。以及 Okta 这种两步验证，只能用手机。你会发现，这些才是我们真正离不开手机的源头，但它们加起来一天可能也用不了几分钟。
通讯社交这块，手表理论上能做，但体验差太多。 如果你有一块独立蜂窝网络的手表，打电话、收短信、回微信其实都可以。但打字不方便，看长消息费劲，发朋友圈更不可能。手电筒 Apple Watch 倒是有，亮度跟手机比还是差一截。所以这块目前还是得靠手机，不过说实话，这些功能占的时间也不算多。
真正花时间的是那些「锦上添花」的功能。 查东西，如：搜索、看天气、查单词、查美食，电脑都能做，手机只是更随手。记东西（写入操作），如：提醒事项、备忘录、挂号、订场地，电脑一样能搞定。买东西，如：JD、淘宝，现在网页版也做得更好了，电脑下单也一样，只是操作没有手机顺手（有些购物平台比如拼多多、美团，只有 APP 没有网页版，只能用手机，如果用 Mac 可以用 iPhone Mirroring）。听英语、听音乐、看书、刷 RSS 等之类的主动输入，用电脑甚至更舒服。说白了，这些功能手机只是胜在「随时随地」，但如果你在电脑前，手机完全可以不碰。
但你回想一下，一天里手机使用时长最多的是什么？ 大概率是短视频、资讯推送和社交软件等这类的娱乐功能。这类功能的特点是你不需要主动想「我要干什么」，打开就有内容喂给你，刷着刷着半小时一小时就过去了。再加上手游，这几项基本构成了大部分人每天手机使用时长的主体。但说实话，这些对我们的生活并没有什么实际帮助，纯粹是被动消耗。
最后说说我降低手机使用时长的方法。 核心思路就是减少拿起手机的次数。工作时让手机不在旁边，眼不见心不烦。睡觉时不把手机带进卧室，避免睡前刷手机。把无意识会打开的 APP 隐藏掉，比如小红书、bilibili、抖音、快手、头条这些，不在首屏看到就少了打开的冲动。另外就是尽量实现手机功能让电脑也可以做，不强依赖手机：微信用新版电脑版可以不手机扫码直接登录；iPhone 电话设置同一 WiFi 下其它设备可以接打；短信设置同一 Apple ID 的设备可以接发；2FA 用 Mac 上 iCloud Passwords 的验证码功能。把这些高频操作都转移到电脑上之后，拿手机的次数明显少了很多。如果你使用 Apple 生态，还可以通过「iPhone Mirroring」在 Mac 中使用 iPhone，进一步降低拿起手机的次数。
对于我们大多数人来说，手机不是生产力工具，不能帮你赚钱，主要就是个娱乐和便利工具。想明白这点之后，我觉得下次换手机也不用花太多钱了，够用就行。
2026-04-11 22:12:46
最近给家里的 Mac 加了个新显示器，对比了几款产品，也做了点功课。显示器这东西参数一大堆，但真正影响日常体验的其实就那么几个点。先说结论，如果预算充足，又是 Mac 用户，直接上 Studio Display 就行，省心。以下内容更适合像我这样对预算不足（1000 元左右预算），对显示器要求也不很高的人。我最终买的是红米 A27U 4K 节能版，下面说说我在挑显示器时主要考虑的几个方面，以及为什么我没买看起来更好的 Type-C 版。
首先是 27 寸到底要不要上 4K。 这一条主要针对 Mac 用户。很多人会说「Mac 必须上 4K，不然字体发虚」，但其实没那么绝对，得看你准备用什么分辨率开 HiDPI。macOS 的 HiDPI 原理简单来说，就是用 2 倍的像素去渲染 1 倍的逻辑分辨率，所以要看字体锐不锐，关键是物理分辨率和逻辑分辨率的 2 倍是不是整数倍关系。如果你只用 1280 × 720 (HiDPI)，2K (2560 × 1440) 显示器就完全够了，因为正好是 2 倍完美缩放，字体比较锐利，这种情况下我测试 4K 切换到 1280 × 720 (HiDPI) 反而没优势，字体锐度还稍微差一点。但如果你想用 1920 × 1080 (HiDPI)、1600 × 900 (HiDPI) 或 1344 × 756 (HiDPI) 这种更大工作区的分辨率，就建议买 4K，像素密度足够，缩放出来的字体才会清楚。因为主要是我媳妇儿使用，她偏好工作区大一点，所以选了 4K。
其次是亮度，这一条是我之前踩过坑才特别强调的。 我以前买的这台 Lecoo 2K 显示器，最高亮度只有 250 nit，阳光照到屏幕上时，屏幕就看不清楚了，只能拉窗帘了。我的建议是至少 300 nit 起步。但标称亮度和实际体验不一定对得上，我这次买的红米 A27U 4K 节能版，官方标的 300 nit，实际用下来感觉跟标 400 nit 的 Type-C 版差不多。所以参数只是参考，实际体验还得看评测或者自己上手。
第三是旋转升降功能。 如果你有竖屏需求，比如竖着看代码、看长文档，那旋转基本是必须的，不然没法转。升降功能在日常使用中可以做一些微调，调到合适的高度，不过它的升降行程一般不够做站立办公。我自己偶尔会竖屏看代码/文档，所以选了带旋转升降的支架版本。
第四是 PBP（硬件分屏）功能有没有必要。 PBP（Picture by Picture）是硬件层面的分屏，可以让一个显示器同时显示两个信号源的画面。我的看法是，一个显示器要给多台电脑同时使用，PBP 才有意义，比如左半边接工作电脑，右半边接个人电脑。如果只是想让一台电脑分屏显示两个窗口，用一根线连上，再用 macOS 自带分屏，或者窗口管理工具（比如 Rectangle、Magnet）就完全能搞定，没必要为 PBP 多花钱，更没必要从一台电脑拉两根线接到 PBP 显示器上。
最后是要不要上 Type-C 接口，我对比了一下，最后没选 Type-C 版。 如果你的场景是一个显示器只连一台设备，Type-C 一线连确实很爽，一根线解决视频、供电、USB 扩展，非常方便，这种情况下值得上。但我家里是多台设备共用一个显示器的场景，Type-C 的优势就不明显了。我对比了红米 A27U Type-C 版和节能版，发现 Type-C 版有这几个劝退点：一是两者亮度实际差别不大，节能版标 300 nit，Type-C 版标 400 nit，但节能版的真实亮度我感觉已经接近 400 nit 了；二是 Type-C 不能单独只供电，当用 Type-C 和 DP 接口同时连接两台电脑时，两路信号都会生效，有一台电脑显示不出画面，只能通过设置镜像才能解决；三是 Type-C 版屏幕有点发黄、灰蒙蒙的感觉，我猜是硬件级防蓝光导致的，对比下来节能版的字体颜色明显更深，看着更舒服。综合下来，我最后选了红米 A27U 4K 节能版。
显示器这东西，真正决定体验的就是这几点：分辨率匹不匹配你的使用习惯、亮度够不够、支架好不好用、接口够不够用，参数表上那些花里胡哨的指标，很多时候远没有这几项基础的重要。但每个人对同一个显示器的偏好不同，想买哪款，建议直接买回来体验试用对比一下，像在 JD 买的话，很多显示器可 7 天无理由退货，上门取件还包邮，可以对比下了再留下最合适的。如果你像我一样预算有限又想挑台合适的显示器，希望这篇文章对你有帮助；有钱的话，还是直接 Studio Display 一步到位最省事。
2026-03-22 23:30:29
我之前写过一篇如何使用 Obsidian 管理个人知识库，里面提到我的文章创建与编辑都在 Obsidian 中完成，然后通过脚本自动同步到 Hexo 博客。最近我又把这套流程扩展到了微信公众号——写完文章，打个标签，运行脚本，草稿就自动出现在公众号后台了，不用复制粘贴，不用手动排版。
我的文章都是在 Obsidian 里用 Markdown 写的，之前要发公众号，得先把 Markdown 复制到 mdnice 格式化，再复制到公众号后台，步骤有点多。
我之前发博客已经实现了自动化，就想着公众号也搞一套类似的流程。参考 markdown-to-wechat 写了个 obsidian-to-wechat 的脚本工具。
整个流程很简单：
Obsidian-to-Wechat-Tag 标签的文章你只需要在公众号助手 APP 预览后点发送就行了。
在 Obsidian 笔记的第一行添加标签 Obsidian-to-Wechat-Tag，表示这篇文章需要发布到公众号。然后在公众号后台获取 AppID 和 AppSecret，配置好后运行脚本就行了。具体的安装和配置步骤可以看 GitHub 仓库的 README。
我现在的写作流程是这样的：在 Obsidian 里写完一篇文章，如果想发博客，就加上 Obsidian-to-HexoBlog-Tag 标签；想发公众号，就加上 Obsidian-to-Wechat-Tag 标签；两个都想发，就两个标签都加上。两套脚本互不干扰，各自处理各自的。
这样写作的时候就只需要专注内容本身，发布渠道通过标签来控制就行了。
公众号文章与博客内容可能有差异，比如嵌入的视频平台不同，发布前建议预览确认一下。
另外微信 API 调用需要 IP 白名单，如果你不是固定宽带 IP，可以在代理工具中设置 api.weixin.qq.com 走代理，这样对微信 API 来说始终是同一个 IP，再将这个 IP 加到公众号白名单就行了。
2026-03-08 21:46:38
做软件后端开发，MacBook 只能用 Pro，Air 胜任不了，不知道你是否还这么想，反正我原来一直是这么想的。最近准备买个 MacBook Pro 14 寸，但看后端同事买的 M2 16G+256G MacBook Air 使用都没有问题，就改变观念打算买 MacBook Air 了。其颜值与价格也有优势。买的 15 寸，15 寸重量与 14 寸 MacBook Pro 差不多，但屏幕更大，更适合移动使用。对我来说，Air 相比 Pro 最大的劣势是在室外使用上，最大亮度只有 500nit，太阳下可能有点看不清，还可能发烫。我觉得 Pro 更适合固定外连显示器使用、偶尔移动的场景，16 寸 MacBook Pro 有点太厚重了。
我买的 24G + 512G。我觉得这配置现在 Air 的性能做后端开发完全是够用的，毕竟原来公司配置的 8G + 256G 的 M1 MacBook Pro 也基本可以正常用，就是时不时得重启下电脑。另外我家里已经有了 Mac mini，高负载长时间运行的应用可以放 Mac mini 上跑，加上也配置了 NAS，24G + 512G 对我是够用了。感觉 512G 跟 24G 更搭，1T 得搭个 32G。
前两天 M5 MacBook Air 刚发布，其储存 512G 起步，相当于跟 M4 同配置相比，其起售价直接降了 1500，现同样配置在京东到手价格 M5 款只比 M4 款贵 300 块。但我还是选择了 M4 芯片。原因很简单，M4 芯片可以降级到 macOS Sequoia 15，而 M5 芯片是在 macOS Tahoe 26 后发布的，Apple 从硬件上限制了 M5 芯片只能安装 macOS Tahoe 26 及以后版本。
我不想使用 macOS Tahoe 26 原因也很简单，不喜欢透明玻璃 UI 用在我的生产力机器上，少了点专业感，更喜欢 macOS Sequoia 15 的扁平风格。加上其它 Mac 机器没有升级，后续如果使用「时间机器」/ 「迁移助理」迁移电脑数据时，macOS Tahoe 26 系统无法将所有数据直接全部备份迁移到使用 macOS Sequoia 15 的其它 Mac 上（15->26 可以）。也想保持 UI 统一，也避免可能升级后的隐藏问题。另外 macOS Tahoe 26 没有 Launchpad 了，改成了一个 App。。
但我当时也担心买的新 M4 MacBook Air 能不能降级，因为有教程说 Mac「不允许降级到比出厂版本更老的系统」。Apple 会在新系统正式发布后的新生产机器出厂预装最新系统，如果真是这样，那 2025/09/15 后生产的机器就都不能降级到 macOS Sequoia 15 了。我一度觉得只能去闲鱼淘别人 2025/09/15 前购买的二手了。
经过多方查询与咨询，我觉得「不允许降级到比出厂版本更老的系统」这句话有问题。我的理解是，只要 softwareupdate --list-full-installers 列出了 macOS Sequoia 15，就应该可以安装。为了验证，我找了一位 2026/01 购买、出厂系统就是 macOS Tahoe 26 的闲鱼卖家，让他跑了下这个命令，结果里有 macOS Sequoia 15。而我去 Apple 直营店测试 MacBook Pro M5 Pro 款，同样的命令结果就只有 macOS Tahoe 26。所以准确的说法应该是「Mac 不允许降级到比该型号硬件所支持的最早系统版本更老的版本」。
这是我新购买 M4 MacBook Air，其执行 softwareupdate --list-full-installers 结果（电脑生产日期是 2026）：
我根据官方教程和这个 YouTube 视频教程，使用 U 盘安装器成功降级到了 macOS Sequoia 15。
但还是遇到了 2 个小插曲：
1、使用 U 盘一直卡在 Copy 阶段，应该是 U 盘的问题，换成固态硬盘后就可以了。PS：可以使用固态硬盘分区来制作启动盘，不一定要用 U 盘。
2、提示「该宗卷无法降级」，抹除 Macintosh HD 后就可以了。
我看 V2EX 上说 macOS 使用 U 盘安装器降级后存在系统固件版本与操作系统加载程序版本不同的问题（系统设置->关于本机->系统报告->硬件概览->系统固件版本、操作系统加载程序版本），我发现我也有这样的问题：
可以通过 DFU 的方式降固件，但我没有做，目前使用没有发现有什么影响，也没有其那种「AlDente」失效的问题。我顺便使用了stop-tahoe-updatep 这个开源项目 让系统设置中不再显示 macOS Tahoe 26 升级提示。
降级后唯一让我有点不爽的是，菜单栏和刘海中间有个缝隙，有点不好看，macOS Tahoe 26 没有这个问题。
如果你没有像我一样的使用 macOS Sequoia 15 的需求，建议你还是买 MacBook Air M5 版本，其 GPU 还是升级了些。不着急的话可以双十一活动时买，我预估 M5 MacBook Air 15 寸京东到时 24G + 512G 到时应该 7700 左右可以买。
如果和我一样，还是想买 M4 版本，现在推荐京东购买，各个颜色都有。拼多多可以不折腾国补便宜 60，但有的颜色可能没货（拼多多买国行零售机应该问题不大）。如果不着急，可以蹲闲鱼二手捡漏。有一个闲鱼实用经验，看到合适的，先拍下，再沟通，不然容易被截胡。
我买的银色，个人认为银色最好看，就是扬声器改到铰链处了，键盘两边没有扬声器开孔，还有点看不习惯。最后，不得不说，MacBook Air 的颜值真高。
2026-03-07 16:31:24
不知道你使用 Claude Code（会员订阅）有没有这样的问题：官方只提供了一个模糊的进度条，不知道每天使用了多少 token，不知道对应的费用是多少，也不知道每天的使用占每周额度的比例，更没有历史记录功能；Weekly 与每 5 小时周期到期后还需要手动触发下一个周期。
为了解决这些问题，我用 Claude Code 开发了个 Claude Code 用量监控工具。
常驻在 macOS 顶部菜单栏，点一下就能看到当前用量，不用开终端。
也可以在终端直接运行脚本 python3 claude_usage.py。
简单说下工具的数据来源。用量数据来自两个地方：
~/.claude/projects/ 下记录每次对话的 JSONL 文件，工具扫描这些文件，按模型和日期汇总 Token 数量，再根据各模型的定价算出费用两个数据源互补：API 告诉你额度用了多少，本地数据告诉你钱花在了哪里。
Weekly 与每 5 小时周期到期后自动触发下一个周期依赖定时任务触发，电脑如果休眠了，定时任务就不会执行。所以如果你要使用这个功能，要么当前设备保持不休眠，要么用一台额外的设备来跑 Menu Bar 应用。
另外因为本地数据只能读取当前设备的 JSONL 文件，如果你在多台设备上使用 Claude Code，费用统计只会包含当前设备的部分。额度百分比不受影响，因为那是从 API 拿的，是账号级别的数据。
2026-02-10 12:43:05
长久以来，我一直在寻找一个称心的稍后阅读工具。从 Pocket 到 Raindrop，我都用过一段时间。Raindrop 存在一个矛盾的问题：它的数据永久保存功能需要付费，但如果只当收藏工具用，又有 MarkMark 等产品可替代；如果当稍后阅读工具用，付费倒也合理，可问题是——我不愿意打开它。
我甚至想过自己开发一个 AI 驱动的增强版 Raindrop，加上自动标签、智能推荐、小红书式浏览……需求是真实的，但自己造轮子不现实，一个人根本做不完。
直到我遇到了 Readwise Reader。
一个稍后阅读工具，如果你不愿意打开，那它保存再多内容也没有意义。Reader 是我第一个愿意主动打开的稍后阅读工具，原因有三个。
第一，阅读体验好。Raindrop 只有 List 视图，没有底部 Tab，打开它更像在翻一个收藏夹，而不是在用一个阅读工具。Reader 不一样，它的界面就是为阅读设计的，打开一篇文章，读起来舒服，让你愿意停留。
第二，操作逻辑顺。用 Raindrop 的时候，我自己建了一套标签体系来管理阅读状态：uninput（未读）、inputing（在读）、input（已读）。这套逻辑本身没问题，但每次都要手动打标签，操作起来有摩擦。而且 Raindrop 保存文章时，光标默认停在备注栏而不是标签，这些小细节堆起来，体验就差了。Reader 原生就有 Inbox（未读） → Later（在读）→ Archive（已读）的流转，和我在 Raindrop 里手动搭建的逻辑完全一致，但不需要自己建标签，拖一下或者点一下就完成状态切换。操作少了一步，使用意愿就多了一分。
第三，随机排序。打开稍后阅读工具，面对一长串收藏列表，常常不知道该读哪篇，然后就关掉了。Reader 有随机排序的功能，把收藏列表打乱，不用从头到尾按顺序挑。这个看似简单的功能，实际上解决了「打开后不知道读什么」的问题，大大降低了阅读的启动成本。
说完为什么愿意打开，再聊聊稍后阅读这件事本身。
我们喜欢探索新的、未知的内容，也喜欢有深度的文章。看到好内容，第一反应是「先存下来」，但存下来之后呢？大多数人的稍后阅读列表，最终变成了「再也不读」列表。稍后阅读的本质是一个输入流程：探索 → 阅读吸收 → 输出。它等于「未阅读 + 正在阅读」，终点是输出，越少越好。如果你的稍后阅读列表只增不减，说明流程出了问题。当列表被打乱，每次打开都能遇到不同的内容，稍后阅读就可以成为第一选择，不再无意识的是去找新的东西。
要让这个流程跑通，有一个前提：信息源要聚合在一处。我以前的状态是，文章放 Raindrop，视频留在各个平台，Twitter 的收藏内容放书签……信息分散在各处，想统一阅读根本不可能。Reader 把这些全部聚合到了一处，网页文章、RSS 订阅、Newsletter、Twitter、PDF、甚至视频，都可以在一个地方阅读和管理。只从这一处输入，阅读流程才能真正跑通。
稍后阅读解决的是「读」的问题，而永久保存解决的是「找」的问题。读过的内容，未来某天想引用、想回顾，能不能搜到？永久保存的终点是好查找，Reader 支持本地缓存和全文搜索，读过的东西不会消失。这也是稍后阅读的自然延伸——读完了，留下来，找得到。
最后聊聊 Reader 这个产品本身。
Reader 不只是一个稍后阅读工具，它的定位是聚合自定义信息输入流。你可以把它理解为稍后阅读 + RSS 阅读器 + Newsletter 收件箱，合在了一起。除了前面提到的阅读体验和状态流转，它还支持 Feed 订阅、Twitter 集成、YouTube 视频保存（带字幕文本）、阅读时高亮笔记，以及多设备同步。
顺带说一下，很多人会混淆 Readwise 和 Reader。简单来说，Readwise 是数据中枢，汇总你在各处的高亮笔记，统一管理、回顾和导出（比如同步到 Obsidian）；Reader 是阅读端，是你实际阅读的地方。在 Reader 里产生的高亮会自动同步回 Readwise。
Reader 目前的订阅费用是 $9.99/月（按年付），对比同类工具不算便宜，但如果你能一直愿意使用它，自己得到了提升，就划算。新用户有 1 个月免费试用，学生可以申请半价，邀请其他用户还能获赠 30 天（你通过我的邀请链接注册也可以额外获赠 30 天，就有 60 天)。建议先试用体验一下，两个月足够你判断它是否适合自己。
稍后阅读的终点不是收藏，而是输出。好的工具不是让你存更多，而是让你真正愿意打开、真正读完、真正用上。Reader 对我来说，就是那个让「稍后阅读」不再等于「再也不读」的工具。
