DeppWang | 德普王修改

2026-03-22 23:30:29

我之前写过一篇如何使用 Obsidian 管理个人知识库，里面提到我的文章创建与编辑都在 Obsidian 中完成，然后通过脚本自动同步到 Hexo 博客。最近我又把这套流程扩展到了微信公众号——写完文章，打个标签，运行脚本，草稿就自动出现在公众号后台了，不用复制粘贴，不用手动排版。

为什么要做这个

我的文章都是在 Obsidian 里用 Markdown 写的，之前要发公众号，得先把 Markdown 复制到 mdnice 格式化，再复制到公众号后台，步骤有点多。

我之前发博客已经实现了自动化，就想着公众号也搞一套类似的流程。参考 markdown-to-wechat 写了个 obsidian-to-wechat 的脚本工具。

它做了什么

整个流程很简单：

1. 扫描 Obsidian 笔记目录，找到最近 3 天内修改过、且带有 Obsidian-to-Wechat-Tag 标签的文章
2. 将 Markdown 转换成微信公众号兼容的排版样式，标题、代码块、链接等都会自动美化
3. 自动下载文章中的图片，上传到微信素材库
4. 调用微信 API，创建公众号草稿，已有草稿会自动更新，不会重复创建

你只需要在公众号助手 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 机器没有升级，想保持 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 盘安装器降级后存在系统固件版本与操作系统加载程序版本不同的问题（系统设置->关于本机->系统报告->硬件概览->系统固件版本、操作系统加载程序版本），我发现我也有这样的问题：

• System Firmware Version: 13822.61.10
• OS Loader Version: 11881.140.96

可以通过 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 用量监控工具。

功能

• 5 小时窗口和每周额度的重置倒计时
• 每天已用的 Token 数量与对应费用，按模型（Opus / Haiku）分项显示
• 每天使用量占每周额度的百分比
• 历史使用记录（数据永久保存，展示最近 30 天）
• 每 30 分钟自动采集更新数据，每周额度重置后自动触发新周期
• 同时保持 5 小时会话窗口过期后自动触发新周期

两种使用形式

1、Menu Bar 应用

常驻在 macOS 顶部菜单栏，点一下就能看到当前用量，不用开终端。

2、终端脚本

也可以在终端直接运行脚本 python3 claude_usage.py。

原理

简单说下工具的数据来源。用量数据来自两个地方：

1. API 数据：通过读取 macOS 钥匙串中 Claude Code 的 OAuth Token，调用 Anthropic 的 Usage API 获取每周额度和 5 小时窗口的使用百分比
2. 本地数据：Claude Code 会在 ~/.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 对我来说，就是那个让「稍后阅读」不再等于「再也不读」的工具。

2025-12-08 11:40:01

在多台 Mac 间同步笔记或脚本可以使用 Git ，它能帮我们保留历史、解决冲突，但手动 git add/commit/push 容易忘。下面这套做法用 LaunchAgents 定时执行一个 Git 脚本，把指定仓库的修改自动提交并推送到 GitHub（或任意 Git 远端），既省事又留痕。

思路与准备

1. 一个可访问的 Git 仓库，例如 [email protected]:demo/notes-sync.git，本机已配置好 SSH Key 或 Token。
2. 仓库路径假设为 /Users/demo/Workspace/notes-sync，请替换成自己的目录。
3. 写一个自动提交脚本，再用 LaunchAgents 每隔几分钟调用一次。

编写自动提交脚本

新建脚本 /Users/demo/Workspace/git-auto-commit.sh：

#!/bin/zsh

REPO="/Users/demo/Workspace/notes-sync"
cd "$REPO" || exit 1

# 拉取远端，避免与他人改动冲突
git pull --rebase origin main

# 只在有变更时提交，避免空提交
if [[ -n "$(git status --porcelain)" ]]; then
  git add .
  git commit -m "auto-commit: $(date '+%Y-%m-%d %H:%M:%S')"
  git push origin main
fi

赋权：

chmod +x /Users/demo/Workspace/git-auto-commit.sh

配置 LaunchAgents 定时执行

在 ~/Library/LaunchAgents 新建 plist 文件 com.demo.git-auto-commit.plist：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.demo.git-auto-commit</string>

    <!-- 每 5 分钟执行一次 -->
    <key>StartInterval</key>
    <integer>300</integer>

    <key>ProgramArguments</key>
    <array>
        <string>/bin/zsh</string>
        <string>/Users/demo/Workspace/git-auto-commit.sh</string>
    </array>

    <!-- 日志便于排查 -->
    <key>StandardOutPath</key>
    <string>/Users/demo/Workspace/git-auto-commit.log</string>
    <key>StandardErrorPath</key>
    <string>/Users/demo/Workspace/git-auto-commit-error.log</string>
</dict>
</plist>

加载与调试：

launchctl load ~/Library/LaunchAgents/com.demo.git-auto-commit.plist
launchctl start com.demo.git-auto-commit       # 立刻跑一次
launchctl list | grep git-auto-commit          # 查看状态
tail -f /Users/demo/Workspace/git-auto-commit.log

如需停止或卸载：

launchctl stop com.demo.git-auto-commit
launchctl unload ~/Library/LaunchAgents/com.demo.git-auto-commit.plist

关键注意事项

• 认证方式：优先用 SSH Key，若用 Token 写在脚本里，记得用只读权限并限制作用域，或在 Keychain 保存环境变量再在脚本里读取。
• 分支一致性：脚本里固定 main（或 master），与远端分支保持一致；多人协作时保留 git pull --rebase 以减少冲突。
• 执行频率：StartInterval 300 秒适合笔记类场景；频率过高会增加推送次数，可按仓库活跃度调整。
• 忽略敏感文件：在 .gitignore 中排除缓存、日志、临时文件，避免不必要的提交。
• 错误兜底：查看 git-auto-commit-error.log，常见问题是网络不通、权限不足或本地/远端存在冲突。

这样配置后，Mac 会在后台定时把仓库的变更自动提交并推送，跨设备同步靠 Git 即可完成，同时保留完整历史记录。

2025-12-08 11:40:01

一、代码提交到部署分支，而导致在开发环境没有问题，而测试环境出了问题

代码直接在部署分支 dev 提交了，没在功能分支提交，在 dev 环境没有问题，功能分支合并到 test 分支部署时，丢失在 dev 分支提交的代码，出现问题

示例：test 环境出现单元测试问题，dev 环境没有这个问题，单元测试提交到了 dev 分支，导致 test 分支代码丢失

解决方式

使用规则保证正确性，而不让人来保证正确性，2 种方式解决：

• 本地仓库设置部署分支 dev 分支禁止 commit
• 远程仓库设置部署分支不能推送，只能通过 pr 的方式合并代码到部署分支

本地仓库设置 dev 分支禁止 commit

vim .git/hooks/pre-commit

#!/bin/bash

branch="$(git rev-parse --abbrev-ref HEAD)"

if [ "$branch" = "develop" ]; then
  echo "Direct commits to develop branch are not allowed!"
  echo "Please create a feature branch and submit a PR."
  exit 1
fi

chmod +x .git/hooks/pre-commit

二、手动部署后测试没有生效，结果发现是代码没有推送到远程分支

流程化：推送代码自动触发部署，就没有不推送代码就部署的问题