普通视图

发现新文章,点击刷新页面。
昨天以前LearnData 开源笔记

365开源计划:一次AI开发实验

2026年3月31日 08:00

进入 AI 时代之后,我有一个很强烈的感受:以前要折腾一整天的工作,现在可能两三个小时就做完了。

本职工作的效率提升了,时间反而多出来了。与其闲着,不如做点有用的事。

所以我启动了一个计划——365 开源计划:在一年内帮大家做 300+ 个实用工具,全部开源。

365 开源计划
365 开源计划

你说需求,我来开发

你在日常工作和生活中,有没有遇到过这样的时刻:

  • "要是有个工具能批量处理这些文件就好了"
  • "这个网站没有导出功能,好烦"
  • "每次都要手动操作一遍,能不能自动化"
  • "我想要一个简单的网页小工具,但找不到合适的"

现在你可以直接把需求告诉我。

👉 提交你的需求

不需要登录,不需要注册,打开链接写清楚你想要什么、在什么场景下用就行。我会从所有需求中筛选排期,用 AI 辅助开发,从开始做起 24 小时内交付。

做出来的工具全部开源,所有人都能用。

能做什么

  • 浏览器扩展:Chrome / Edge / Firefox 插件
  • 网页工具:在线转换、生成、可视化,打开就能用
  • Python 脚本:数据处理、文件批量操作、自动化
  • 油猴脚本:给现有网站加功能
  • 命令行工具:开发者向的效率工具

简单来说:做了就能用、不需要服务器一直跑着的工具。

手机 App、需要后端服务器的系统、需要数据库的完整应用暂时不做。

已经做出来的

| # | 项目 | 类型 | 说明 | |

第一次用 Mac mini:部署 OpenClaw 踩坑全记录

2026年3月30日 08:00

之前 OpenClaw 一直跑在云端,收到 Cloudflare 50 刀的月账单之后,我决定改为本地部署,年后入手了 Mac mini(16G + 256G)。因为我不指望用本地大模型,所以硬件配置方面没有太高要求。OpenClaw 除了 macOS,也支持 Linux 和 WSL2(不建议原生 Windows)。下面是我作为一个从来没用过 Mac mini 的人,在使用过程中碰到的各种坑,以及我觉得新入手 macOS、使用 OpenClaw 需要注意的一些点。

Mac mini 本地部署 OpenClaw 示意图
Mac mini 本地部署 OpenClaw 示意图

macOS 基础适应

如果你和我一样是 Windows 过来的,有几个差异先知道会少踩坑:

  • 软件安装:Mac 上装软件要么从 App Store,要么下载 .dmg 文件打开后把图标拖进 Applications 文件夹。命令行装软件用 Homebrew(相当于 Windows 的 winget/scoop),终端执行 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" 即可安装。
  • 终端:macOS 默认终端是 zsh(不是 bash),常用操作和 Linux 基本一致。
  • 鼠标滚轮:Mac 默认开启「自然滚动」,滚轮方向和 Windows 相反。不习惯的话,到「系统设置 > 鼠标」里关掉「自然滚动」。

系统基础设置

由于 Mac mini 通常会作为"Headless"(无显示器)服务器运行,第一步是确保它能持久在线并方便远程管理。

电源与休眠

进入「系统设置 > 能耗」,开启"显示器关闭时,防止自动进入睡眠"。同时建议在终端运行以下命令,确保断电恢复后自动开机:

sudo pmset -a autorestart 1

无感重启

如果这台 Mac mini 是专门拿来跑 OpenClaw 的独立设备,并且放在可信环境中,可以考虑开启自动登录(系统设置 > 用户与群组 > 自动登录)。这样系统重启后,OpenClaw 可以随开机启动项直接拉起,无需等待手动输入密码解锁文件系统。若这台机器还存放个人资料,或存在他人物理接触风险,就不要开启。

远程控制

在「系统设置 > 通用 > 共享」中,务必打开以下选项:

  • 屏幕共享:方便通过 VNC 客户端远程查看桌面。
  • 远程登录(SSH):方便从终端直接连入 Mac mini。
  • 文件共享(可选):如果你需要从其他设备访问 Mac mini 的文件,先在这里打开开关,具体的 SMB 配置见后文「局域网共享文件夹」章节。

查看 Mac mini 的 IP 地址:打开「系统设置 > 网络」,当前连接的网络下会显示 IP(或在终端执行 ifconfig | grep "inet " 查看)。建议在路由器里为 Mac mini 绑定固定 IP,避免重启后地址变化。

如果只是查看画面,可以使用 RealVNC Viewer,清晰度比较好。操作时不需要注册账号,直接连局域网 IP 即可。

安装 OpenClaw

OpenClaw 安装非常简单,只需要在终端依次执行以下命令:

sudo curl -fsSL https://openclaw.ai/install.sh | bash

openclaw onboard --install-daemon

其中,第二条命令用于安装并注册 OpenClaw 守护进程。这里使用 sudo 是为了避免缺少 Homebrew 等依赖导致安装失败。不过,新手最好先确认域名和安装脚本来源可信,再执行这类 curl | bash 命令。

账号与隐私安全

OpenClaw 拥有极高的系统权限(读写文件、操作浏览器、发消息等),建议只在非主力机上安装。

使用专属 Apple ID

如果你想让 OpenClaw 接管 iMessage 或系统日历,强烈建议注册并登录一个全新的 Apple ID,不要使用存放了个人隐私和重要备忘录的主力账号。把它当做一个真实的"助理账号"来对待。

权限放行

首次运行 OpenClaw 后,可以通过下面两个动作分别触发权限申请并点击允许:

  • 触发辅助功能权限:直接在对话里给 OpenClaw 一个最简单的桌面操作指令,例如“请把鼠标移动到屏幕中央”。
  • 触发文件访问权限:
open ~/.openclaw
macOS 隐私与安全性权限设置
macOS 隐私与安全性权限设置

然后在「系统设置 > 隐私与安全性」中,确认为 OpenClaw 运行的终端(或 Node 环境)授予完全磁盘访问权限辅助功能权限,否则它将无法跨应用执行本地自动化脚本。如果你平时是通过 iTerm、Warp 或 VS Code 内置终端启动 OpenClaw,需要授权的往往不是 Terminal.app,而是你实际使用的那个终端应用。

远程访问 WebUI

为了能在局域网内随时访问 OpenClaw 的 Web UI 控制台,可以编辑配置文件 ~/.openclaw/openclaw.json,参考以下配置(关闭了安全验证,仅适用于局域网环境):

{
  "gateway": {
    "port": 18789,
    "mode": "local",
    "bind": "lan",
    "controlUi": {
      "enabled": true,
      "allowInsecureAuth": true,
      "dangerouslyDisableDeviceAuth": true,
      "allowedOrigins": ["http://192.168.2.127:18789", "http://localhost:18789"]
    },
    "auth": {
      "mode": "token",
      "token": "你的自定义Token"
    }
  }
}

配置完成后,在局域网内访问 http://192.168.2.127:18789?token=你的Token 即可打开控制台。

注意:

  • 这套配置只建议用于受信任的家庭局域网,不要直接映射到公网。
  • allowInsecureAuthdangerouslyDisableDeviceAuth 都属于降低安全性的选项,只是为了换取局域网内访问方便。
  • 重启后 IP 可能变化,allowedOrigins 和访问地址都要跟着改(前面提到的固定 IP 绑定在这里也很重要)。
  • 如果你把 token 直接写在 URL 里,链接可能会留在浏览器历史记录中,最好只在自己的设备上使用。
OpenClaw WebUI 控制台
OpenClaw WebUI 控制台

更多配置参数请参考 openclaw.json 配置示例

不过我后来觉得 WebUI 不如直接远程桌面控制来得直观,所以更多时候还是用下面的方案。

局域网远程控制

如果你和我一样,需要从 Win11 主机控制 Mac mini,并且希望支持剪贴板双向传输,推荐使用 RustDesk

为什么选 RustDesk

RustDesk 是一个开源免费的远程桌面工具,体验非常好:

  • 完整支持剪贴板双向传输(文字粘贴没问题)
  • 延迟低,画质不错
  • 可以自建中继服务器,也可以用官方免费服务器
  • Mac 端和 Win 端都有客户端,直接安装即可

注意:macOS 上安装后需要授予"辅助功能"和"屏幕录制"权限。

RustDesk 远程桌面连接界面
RustDesk 远程桌面连接界面

键位映射设置

RustDesk 会自动识别你是 Win 控制 Mac 的场景,把 Win 快捷键"翻译"成 Mac 对应的操作。比如你按 Ctrl+C,它会自动翻译成 Cmd+C 发给 Mac,不需要自己记键位差异。

RustDesk 提供三种键位模式:

  • 传统模式:按什么发什么,不做任何转换。
  • 1:1 传输:按键原样传输,需手动勾选"交换 Control/Command"来适配。
  • 翻译模式(Beta):自动帮你做跨平台键位翻译,最智能。
RustDesk 键位映射设置
RustDesk 键位映射设置

推荐设置:

  1. 选择 翻译模式 Beta
  2. 勾选 "交换 Control 键和 Command 键"
  3. 其余选项不勾

如果 Ctrl+C/V 无法正常复制粘贴,可以尝试取消勾选"交换 Control 键和 Command 键"。

局域网共享文件夹

如果你需要在局域网内的其他设备上直接访问 Mac mini 的文件(比如 .openclaw 的配置目录),可以通过 macOS 的文件共享功能实现。

RustDesk 远程桌面在无头模式下可以正常使用,但它内置的文件传输功能在没有外接显示器时不太稳定(社区和 GitHub issue 中有大量相关反馈,暂无完美解决方案)。因此跨设备传文件推荐使用 macOS 自带的 SMB 共享。

开启文件共享

  1. 打开「系统设置」,进入「通用 > 共享」。
  2. 找到"文件共享"选项,打开开关。
  3. 点击右侧的 ⓘ 图标,在弹出窗口中点击"共享文件夹"列表下方的 + 号,添加你要共享的文件夹。

如果在弹窗中看不到 .openclaw 这类隐藏目录,先在 Finder 中按 Cmd+Shift+. 显示隐藏文件,然后拖入该目录。

设置访问权限

添加文件夹后,在右侧的"用户"列表中调整权限:读与写。

开启 SMB(Windows 兼容)

macOS 文件共享默认使用 AFP 协议,Windows 无法识别,还需要开启 SMB:

  1. 在"文件共享"信息窗口中,点击「选项...」。
  2. 勾选"使用 SMB 来共享文件和文件夹"。
  3. 在下方的"Windows 文件共享"列表中,勾选你的用户账户(需要输入 Mac 开机密码)。
  4. 点击「完成」。

从 Windows 访问共享文件夹

在 Windows 资源管理器的地址栏输入 \\Mac mini的IP地址(例如 \\192.168.2.127),回车后输入 Mac 的用户名和密码即可访问共享文件夹。

总结

作为一个用了十几年 Windows 的人,第一次折腾 Mac mini 确实到处碰壁。但配置完之后回头看,其实就那么几步:系统设好无头模式、装好远程控制、权限放行、文件共享打通——之后就是一台 24 小时在线的 AI 助理主机,日常通过局域网远程管理就行了。

为什么 aria2 下不动的文件,浏览器就可以?我写了个扩展来解决这个问题

2026年3月27日 08:00

你有没有遇到过这种情况:一个文件在浏览器里点击就能下载,但把链接丢到下载工具、aria2、wget 或 curl 里就 403 了?

最近想在 NHK 网站上下载一批 PDF,丢给 aria2 直接被拒,加了 User-Agent 也不行。但浏览器打开链接,秒下。

原因很简单:浏览器发请求时会自动带上 Cookie、User-Agent、Referer 等一堆 Headers,而外部下载器发的是"裸请求"。现在越来越多的网站(尤其是需要登录的站点)会校验这些信息,裸请求直接被拦。

现有的方案都不太好用

我试了几种常见的解决办法:

给 aria2 手动加 Headers——理论上可以,但需要从浏览器开发者工具里一个个复制 Cookie、UA、Referer,遇到带 token 的链接还会过期,操作很繁琐。

浏览器转发扩展(比如把下载任务从浏览器发到 aria2 RPC)——这些扩展能转发 Headers,但只能拦截你在浏览器里点击的下载,不能批量粘贴一堆 URL 进去。

市面上的批量下载扩展——看了一圈,要么收费,要么权限要一大堆,要么下载时并不走浏览器原生通道——又绕回了丢 Cookie 的老问题,要么项目早就没人维护了。

回到问题本质

想明白一件事:既然浏览器下载没问题,那就让浏览器自己来下载。

Chrome 允许扩展调用浏览器自身的下载能力,效果等同于你在地址栏输入链接按回车——Cookie、UA、Referer 全部自动携带,不需要你手动配置任何东西。

基于这个思路,我做了 Native Batch Downloader

怎么用

  1. 点击工具栏图标,打开弹窗
  2. 粘贴 URL(一行一个)
  3. 设置并发数和下载间隔
  4. 点"开始下载"

就这么简单。下载进度、成功/失败统计、实时日志都在弹窗里显示。

Native Batch Downloader 使用界面
Native Batch Downloader 使用界面

实测批量下载 66 个 PDF 文件(最大 120MB),全部正常完成。

几个你可能关心的问题

支持什么文件类型? 不限。PDF、图片、视频、压缩包、可执行文件,只要 URL 是直链就行。

并发数多少合适? 默认 10。但浏览器对同一个网站有并发连接数限制,所以下载同一个站点的文件时,设再高也不会更快。跨站下载时高并发才有意义。

需要登录的网站能用吗? 能,只要你在浏览器里已经登录了。扩展走的就是浏览器自己的请求通道,登录态天然携带。

URL 必须是直链吗? 是的。如果一个网站是点按钮后 JS 动态生成临时下载地址的(比如网盘的"点击下载"),你需要想办法拿到实际的文件 URL。这个扩展不负责解析页面。

权限要了哪些? 只需要"下载"权限,不会读取你的浏览记录、网页内容或其他隐私数据。无第三方依赖,支持 18 种语言,代码完全开源可审查。

适用场景

  • 批量下载需要登录态的资源(论文库、内部系统、会员站点)
  • 批量下载反爬站点的文件(检查 UA/Referer 的站点)
  • 从文本列表批量下载任意直链文件
  • 替代 aria2 在带认证场景下的批量下载需求

不适用的场景

  • 需要从网页上自动提取链接(这个扩展只接受你手动提供的 URL 列表)
  • 网盘等需要点击按钮才能获取真实下载地址的场景
  • 需要断点续传的超大文件(chrome.downloads 本身支持续传,但扩展层面没做额外处理)

用了 Coding Plan 还没开 Think?你可能浪费了一半的钱

2026年3月24日 08:00

一篇关于 OpenClaw 思考模式的使用指南,附高性价比 Coding Plan 方案推荐

很多朋友买了 Coding Plan,把模型接上 OpenClaw 就开始干活了。但如果你没有开启 Think(思考模式),那你用的大模型其实只发挥了"快速应答"的水平——相当于买了一台高配电脑,却一直在用省电模式。

今天这篇文章,我把 Think 模式的作用、档位选择、成本控制一次讲清楚。

一、Think 模式到底是什么?

简单来说,大模型默认的工作方式是"看到问题→直接输出答案",类似于人类的直觉反应。而 Think 模式(也叫深度思考、推理模式)会让模型在给出答案之前,先进行一轮内部推理:拆解问题、验证逻辑、排除错误路径,然后再输出结果。

这就像考试时两种答题方式的区别:

  • 不开 Think:看完题目直接写答案,速度快,但容易犯低级错误
  • 开了 Think:先在草稿纸上推演一遍,确认思路没问题再落笔

对于日常闲聊、简单问答,不开 Think 完全没问题。但一旦涉及代码生成、逻辑推理、多步骤任务规划这类复杂场景,Think 模式的质量提升是肉眼可见的。根据实际使用体验,国内模型开启深度思考后,对话任务的完成质量基本能达到 95% 以上。

二、OpenClaw 的 Think 档位怎么选?

OpenClaw 提供了非常灵活的思考级别设置,从完全关闭到最高档一共有这些选项:

| 档位 | 说明 | 适用场景 | |

LearnData 进阶:让 AI 和脚本接管博客维护

2026年3月5日 08:00

有段时间,我几乎每发完一篇文章,都会在几天后发现新的小问题。 有时是 description 忘了写,有时是写了但长度不合适;有时是标题太长,搜索结果里显示得别别扭扭;读书笔记那边更烦,明明文章已经写完,还得去 _sidebar.md 里补链接。忙起来漏掉一两处,过几天回头看,才会想起“这篇怎么又没配好?”

最开始我还觉得这只是小事。直到 LearnData 的内容涨到 200 多篇,我才意识到,这些小事根本不是小事。它们重复、机械、分散,却会持续打断人,逼着你把本该用来写内容的时间,花在一遍遍检查和返工上。

然后我给自己定了个原则:凡是重复到让我烦的事情,就不该再用手做。于是我写了 3 个脚本,再配合 AI,把博客维护里最琐碎的一部分接管掉:构建时自动生成 llms.txt,批量审计全站 SEO,把问题整理成 JSON 报告交给 AI 修复,读书笔记写完还能一键更新侧边栏。

第一次完整跑通,只花了二十分钟。之后我终于可以把精力放回内容本身,而不是那些没完没了的维护杂活上。

本文是 LearnData 系列的第三篇。第一篇介绍了把博客变为知识库的理念,第二篇分享了笔记搜索、本地定位等进阶技巧。这一篇继续往前走,解决的是另一个更现实的问题:当文章和笔记越来越多,如何把重复、机械、容易遗漏的维护工作自动化。

我先补上了 llms.txt 这块空白

最先让我觉得该补上的,是 llms.txt

一如搜索引擎依赖 robots.txt,AI 也需要对应的引导文本。llms.txt 用 Markdown 格式列出站点所有页面的标题、描述和链接,让大语言模型能快速理解站点结构。

它的格式非常简单:

# LearnData 开源笔记

> 开源工具、效率方法、心理学探索的自我提升笔记

## Pages

- [Rclone 远端图床本地化管理方案](https://newzone.top/_posts/...) - 利用 Rclone 建立自动化工作流...
- [吃掉那只青蛙](https://newzone.top/reading/#/0_效率与习惯/吃掉那只青蛙) - 核心是每天先完成重要的工作...

但几百篇文章总不能手写吧。于是我写了 llms-txt.js,在每次构建时自动扫描所有 Markdown 文件,从 frontmatter 提取标题和描述(没有 frontmatter 的读书笔记则从 H1 和正文首段提取),生成完整索引。

这个脚本已集成在构建命令中,pnpm docs:build 完成后会自动在 dist/ 目录生成 llms.txt,随站点一起部署。站点信息从 VuePress 配置文件自动读取,零配置。

然后是最烦人的 SEO 检查

真正最烦的,还是 SEO 元数据检查。

手动检查有多痛苦?打开一篇文章,看 title 是不是太长,description 是不是在 120-160 字符之间,有没有用「本文介绍了……」这种搜索引擎不喜欢的模板化开头。一篇看下来只要一分钟,几百篇就是好几个小时,而且下次新增文章后还得再来一遍。

我需要的是一个脚本,跑一次就能告诉我哪些文件有问题、问题是什么、该怎么改。于是有了 seo-audit.js

运行 pnpm seo:audit,它会扫描全站 Markdown 文件,对每篇文章按规则打分(满分 100):

| 检查项 | 扣分 | |

OpenClaw 实测:Cloudflare Worker 部署教程与避坑指南

2026年2月6日 08:00

注意

即使是低频使用,我在一个月后也收到了 Cloudflare 50 美元的账单。如果你也打算用 Workers 方案,请务必关注用量和计费。

OpenClaw 是一个开源的 AI 自动化框架,可以通过聊天指令驱动 Agent 完成浏览器操作、文件读写、邮件收发等任务——相当于给你配了一个 7×24 在线的数字助理。最近一个月,我不断被它的消息轰炸,似乎无所不能。于是决定亲手部署一套,看看它到底能帮我做什么。

本文记录的是基于 Cloudflare Workers 的部署方案,适合想低成本尝鲜、不想折腾本地环境的用户。

方案选择:Cloudflare Workers

使用 cloudflare/moltworker 可以将 OpenClaw 托管在 Cloudflare Workers 上,无需自备服务器。

此方案需订阅 Cloudflare Workers Paid 计划(5 美元/月)。需要注意,这只是起步价,高频使用会产生额外费用(详见 GitHub 讨论:What's the cost running it 24/7 for a month)。作为一个 24 小时在线的 AI 服务,每月 5 美元的起步成本尚可接受,但务必留意实际用量。

部署流程详解

1. 一键部署 Moltworker

点击 cf 一键部署 开始初始化。

重要

务必修改并妥善保存 MOLTBOT_GATEWAY_TOKEN,这是后续进入管理后台的唯一凭证。

2. 等待构建

部署过程约需十分钟,期间可点击「继续处理项目」跳过等待页面。

3. 配置 Access(Zero Trust)

访问网页界面需要配置 CF_ACCESS_AUDCF_ACCESS_TEAM_DOMAIN 两个变量。

  1. 创建应用:进入 Zero Trust → Access → Applications,添加一个 Self-hosted 应用。

  2. 设置域名

    • 子域默认为 moltbot-sandbox
    • 域名可使用 Cloudflare 分配的 Worker 域名或自定义域名。
    • Session Duration 建议设长一些,避免频繁登录。
  3. 配置策略:系统通常会自动创建 moltbot-sandbox - Production 策略,默认通过邮箱验证码登录。

  4. 获取变量

    • CF_ACCESS_AUD:保存应用后,点击右侧「⋮」编辑,在应用程序受众(AUD)标签页找到 Application Audience (AUD)。
    • CF_ACCESS_TEAM_DOMAIN:进入 Zero Trust → Settings,获取团队域名 xxxxxx.cloudflareaccess.com

4. 配置 R2 对象存储

OpenClaw 需要 R2 存储运行状态,需配置以下三个变量:

  • CF_ACCOUNT_ID
  • R2_ACCESS_KEY_ID
  • R2_SECRET_ACCESS_KEY

操作步骤

  1. 获取 Account ID:在 Cloudflare 侧边栏进入 R2 → Overview,右侧 Account Details 中即可找到 CF_ACCOUNT_ID

  2. 创建 API 令牌:点击 Manage R2 API Tokens → Create API Token。

  3. 设置权限:权限选择 Object Read & Write,建议通过 Specific Bucket 限制在 moltbot-data,避免过大授权范围。

  4. 保存密钥:创建成功后,立即记录 Access Key ID 和 Secret Access Key。

警告

修改 Token 时请务必核对变量名称。如果不慎修改了 Build Token,会导致 Worker 构建失败。

5. 注入变量并重新部署

回到 Workers → Settings → Variables and Secrets,填入上述 5 个变量后,点击 Deploy 重新部署。

访问与管理

部署完成后,通过以下地址访问 Worker:

https://moltbot-sandbox.xxxxxxxx.workers.dev?token=MOLTBOT_GATEWAY_TOKEN

通过 Cloudflare Access 邮箱验证后,即可进入管理后台并接受 Pairing Requests:

https://moltbot-sandbox.xxxxxxxx.workers.dev/_admin/

基础使用

部署完成后,通过聊天指令与 Bot 交互。常用操作如下:

查看或切换模型

/model minimax/MiniMax-M2.1

设置开机自启模型(防止 Worker 重启后被重置):

set model minimax/MiniMax-M2.1

远程终端连接

openclaw gateway login --url https://moltbot-sandbox.xxxxxxxx.workers.dev
clawdbot configure --section skills

避坑指南

在实际测试中,我踩了不少坑,总结如下:

  • 模型配置易报错:国内 AI 服务商通常区分国内与海外端点。在 Cloudflare Workers 环境下,通过配置文件修改默认模型极易报错。最稳妥的方案是通过 set model 开机命令强制指定,而非依赖配置文件或后台 UI。
  • 费用不透明:Workers Paid 计划虽然起步 5 美元/月,但请求数、CPU 时间、R2 存储均会产生额外费用。建议在 Cloudflare Dashboard 设置用量告警,避免月底惊喜账单。
  • Access 配置易遗漏:如果部署后访问页面返回 403 或无限重定向,大概率是 CF_ACCESS_AUDCF_ACCESS_TEAM_DOMAIN 填写有误,优先排查这两个变量。
  • 功能受限:Workers 方案不支持浏览器自动化等依赖 GUI 的高级功能,只能执行纯文本交互类任务。如果需要完整功能,需要部署到本地机器。

结论:现在值得入场吗?

折腾了一圈 Cloudflare Workers 之后,我的判断是:

OpenClaw 目前还不是一个能「即刻提升效率」的工具。

现阶段,它更像是一个为 AI 自动化搭建的系统底座,而非开箱即用的产品。如果你没有明确的、可标准化的长流程需求,OpenClaw 带来的只会是维护成本,而非生产力红利。

Cloudflare Workers + OpenClaw 适合以下场景:

  • 未体验过 Agent 自动化,想以最低成本试手。
  • 已有 Cloudflare 付费订阅,资源闲置可复用。
  • 只需要纯文本交互(模型对话、邮件处理等),不涉及浏览器操作。

但如果你期望它「部署完就自动干活」,或者需要浏览器自动化等完整功能,Workers 方案会让你感到落差——这时候应该考虑本地部署方案。

AI 绘画实战指南 Vol.3:ComfyUI 节点式工作流

2026年1月28日 08:00

ComfyUI 是目前最具扩展性的全平台 AI 绘画与视频生成工具。与其说它是一款软件,不如说这是一套以“节点流”(Node-based Workflow)为核心的可视化创作系统。在这里,模型、采样、控制与后处理不再是黑盒中的参数,而是可拆解、可组合、可复用的逻辑模块。

相比强调“开箱即用”的 WebUI,ComfyUI 的核心优势在于效率与硬件包容性。其内置的显存—内存交换机制(Smart Memory Management),能动态加载模型权重,将暂时闲置的数据卸载至内存。这种“以时间换空间”的策略,让 4GB 显存的老旧设备也能运行 SDXL 甚至 FLUX 等大模型,极大地降低了高画质生成的硬件门槛。

此外,ComfyUI 拥有极活跃的扩展生态。不仅兼容最新的扩散模型、SVD 视频生成与各类 ControlNet 控制节点,还能无缝接入 OpenAI、Gemini 等云端 API。本地算力不足时,可以通过节点将任务分发至云端,实现“混合算力”工作流。简言之,ComfyUI 不做预设,而是提供构建流水线的能力。

正确的使用姿势:是“加载”,不是“构建”

很多新手被满屏的连线劝退,误以为必须精通原理才能使用。这是最大的误解。

ComfyUI 的生态充满了现成的高质量工作流。作为创作者,首要任务是使用,而非制造

在官方界面中,点击「模板」,你就能获得一套标准的 Text to Image 流程。填入提示词,点击运行即可生成。

当需要进阶功能时,直接去 Civitai 下载大家分享的 JSON 工作流文件,拖入窗口,使用 ComfyUI Manager 补全缺失节点,即可直接运行。

别被连线吓倒。连线是留给“开发者”的;对于“使用者”,ComfyUI 往往比 WebUI 更简单——因为它所见即所得,逻辑一目了然。

部署与配置

1. 核心程序

ComfyUI 支持 Windows、Linux、macOS。Windows 用户请直接下载 官方便携版 (Portable Standalone)。解压即用,自带独立 Python 环境,无需配置复杂的系统依赖。

2. 启动策略

解压后会看到多个启动脚本,请按需选择:

  • run_nvidia_gpu.bat:适合绝大多数 N 卡用户。
  • run_nvidia_gpu_fast_fp16_accumulation.bat:如果你是 20/30/40 系显卡,这个脚本开启了 FP16 半精度累积计算,能显著提升速度并降低显存占用。(质量略降)
  • run_cpu.bat:仅用 CPU 运行,速度较慢。

3. 模型下载加速

国内直连 HuggingFace 速度较慢,推荐利用 ModelScope (魔搭社区) 镜像。

  • 技巧:将模型链接中的 huggingface.co 替换为 modelscope.cn/models,即可享受满速下载。

4. 必备插件:ComfyUI Manager

这是 ComfyUI 的“应用商店”,支持在界面内搜索、安装自定义节点,并能一键补全工作流缺失的插件。

  • 安装:进入 ComfyUI/custom_nodes 目录,打开终端(CMD),运行:

    git clone https://github.com/ltdrdata/ComfyUI-Manager.git
  • 使用:重启后菜单栏会出现 Manager 按钮,点击 「Install Missing Custom Nodes」 即可自动识别并安装当前工作流缺少的组件。

进阶配置

避免闪退:设置虚拟内存

在生成高分辨率图像或视频时,物理内存极易枯竭导致闪退。强烈建议手动设置 Windows 虚拟内存。

推荐设置:初始大小与最大值均设为 32768(32GB) 或更高。

操作路径

  1. Win + R 输入 sysdm.cpl 打开系统属性。
  2. 进入 「高级」 -> 「性能」 设置 -> 「高级」 -> 「虚拟内存」 更改。
  3. 取消“自动管理”,选中 C 盘(或 SSD 所在盘),选择 「自定义大小」,填入数值并点击“设置”确认。

设置完成后建议重启一次(或至少重启 ComfyUI),避免旧的内存策略仍在生效。

API 调用准备:开启监听 + 导出工作流

ComfyUI 自带 HTTP API。只要程序正常启动,你就已经“开启”了 API。

  • 本机访问:默认地址是 http://127.0.0.1:8188

  • 局域网访问(可选):启动时加上 --listen 0.0.0.0,例如:

    python main.py --listen 0.0.0.0 --port 8188

    如果你用的是 Windows 便携版,思路相同:在对应的 run_*.bat 启动命令后追加 --listen 0.0.0.0 即可。

    建议仅在可信内网使用,并配合防火墙限制来源;不要把 8188 端口直接暴露到公网。

API 调用的关键,是拿到“API 格式”的工作流 JSON(比普通保存更干净,不含界面坐标等元数据)。

  1. 打开你的 ComfyUI 网页界面。
  2. 点击设置图标(齿轮),勾选 "Enable Dev mode Options"(启用开发者模式选项)。
  3. 回到主界面,你会发现菜单栏多了一个按钮:"Save (API Format)"
  4. 点击它,保存下来的文件通常命名为 workflow_api.json

注意: 这个 JSON 文件与普通的 Save 文件不同,它只包含节点 ID (class_type) 和输入参数 (inputs),没有界面坐标信息。

拿到 workflow_api.json 后,就可以基于 http://127.0.0.1:8188 通过以下端点提交任务与查询结果:

  • POST /prompt:发送工作流任务到队列。
  • GET /history/{prompt_id}:获取任务执行结果。
  • GET /view:获取生成的图片文件。
  • WebSocket /ws:用于实时监听生成进度和获取执行状态。

本地部署 vs 云端算力

尽管 ComfyUI 优化出色,但流畅运行 SVD 等视频模型仍需 12GB 以上显存。

对于高阶创作,不必执着于本地硬件。目前云端算力成本已大幅下降,将 ComfyUI 部署在云端(如 AutoDL、阿里云等)往往是更理性的选择——显存不再是瓶颈,生成效率可提升数倍。

ComfyUI 的核心价值不在于你拥有多少显卡,而在于掌握“工作流逻辑”。 一旦理解了节点间的流转关系,无论在本地 4090 还是云端 A100,你都能构建出独一无二的创作流水线。

AI 绘画实战指南 Vol.2:Stable Diffusion 进阶插件

2026年1月19日 08:00

成功部署 Stable Diffusion(参考 《AI 绘画实战指南 Vol.1》)后,真正的挑战在于如何从“随机抽卡”转向“可控创作”。这取决于三点:理解模型差异、掌握插件控制、建立稳定的工作流。

模型与插件构成了 Stable Diffusion 的核心生态。

本文重点解决三个问题:

  1. 模型获取与管理。
  2. WebUI 原生潜能挖掘。
  3. 关键插件的高效应用。

模型管理:Civitai 与 LoRA

Civitai(C 站) 汇集了全球主流的 Stable Diffusion 模型,涵盖二次元、写实、人像、插画及概念设计等多个方向。

下载模型后,需将其存入 WebUI 指定目录方可生效。

大模型(Checkpoints / Base Models)

决定画面的整体风格与基础能力。

  • 格式.safetensors / .ckpt
  • 体积:2 GB – 6 GB
  • 路径models/Stable-diffusion
  • 提示:切换模型时,建议同步调整提示词结构、采样器与 CFG 值,避免沿用旧参数导致效果不佳。

微调模型(LoRA)

在不改变大模型基底的前提下,注入特定人物、画风、服饰或概念(如机甲、水墨风)。

  • 格式.safetensors
  • 体积:10 MB – 300 MB
  • 路径models/Lora
  • 用法:在提示词中调用,如 <lora:mecha_style:0.8>

VAE(Variational Autoencoder)

相当于“调色滤镜与解码器”,用于修正色彩饱和度与灰度问题。

  • 路径models/VAE

可通过 SettingsUser interfaceQuicksettings list 添加 sd_vae,以便在顶部栏快速切换。

提示:Docker 版部署路径通常位于 data 目录下,如 stable-diffusion-webui-docker/data/StableDiffusion,需据实调整。

Rclone 远端图床本地化管理方案:以七牛云为例

2026年1月25日 08:00

早年我将大量博客配图托管于七牛云,但当时并没有在本地对图片进行统一压缩。虽云端支持图片处理,但长期积累仍面临两个问题:

  • 部分图片原始分辨率和体积过大,即使经过云端处理,存储空间占用和流量成本依然偏高。
  • 历史图片太多,云端管理并不友好。

为此,我采用了一种更通用、可控的方案:「云端下行同步 → 本地批量压缩 → 上行覆盖同步」。此举既能压缩历史存量,又能建立一套可自由管理的图床库。

方案总览

  • 核心组件:Rclone(支持 S3 协议)
  • 处理方式:本地批量压缩(无损 / 视觉无损)
  • 同步逻辑
    1. 全量下载(云端 → 本地)
    2. 本地处理(压缩)
    3. 增量覆盖(本地 → 云端)

七牛云兼容 AWS S3 协议,可直接通过 Rclone 的 S3 Provider 访问,无需额外插件。

第一步:部署 Rclone

Rclone 是单文件命令行工具,无须安装,配置环境变量即可使用。

1. 获取程序

访问 Rclone 官网下载页,下载适用于 Windows 的 Intel/AMD - 64 Bit 压缩包。

2. 解压

将解压后的文件置于固定目录,例如 C:\rclone\,确保该目录下包含 rclone.exe

3. 配置环境变量

  1. Win 键,搜索「环境变量」,进入「编辑系统环境变量」。
  2. 点击「环境变量」,在「系统变量」列表中找到 Path
  3. 新建条目:C:\rclone\

4. 验证

启动 PowerShell 或 CMD,执行:

rclone --version

输出版本号即表示配置成功。

注意:日常使用建议避免以管理员权限运行 PowerShell,以免权限冲突导致 Rclone 异常。

第二步:建立连接

前置准备信息:

  • 七牛云 Access Key(AK)
  • Secret Key(SK)
  • 存储桶(Bucket)所属区域(如华东、华北等)

配置流程

  1. 执行配置命令:

    rclone config
  2. 输入 n 新建远程连接(New remote)。

  3. name:命名连接,例如 qiniu

  4. Storage:选择 S3(Amazon S3 Compliant Storage)。

  5. provider:选择 Qiniu(Qiniu Object Storage)。

  6. access_key_id:输入 AK。

  7. secret_access_key:输入 SK。

  8. region:留空回车。

  9. endpoint:根据区域填写对应的接口地址(Endpoint):

    | 区域 | Endpoint | | :

密码管理器折腾记:从 KeePass 到 Bitwarden 的对比与回归

2026年1月24日 08:00

从 LastPass 换到 KeePass 已经 5 年。作为一款老牌工具,KeePass 的优势有目共睹:开源免费、本地数据库存储、极高的定制自由度。然而,其痛点也不少:数据库需要自己同步,浏览器扩展更新停滞,自动填充也不稳定。

于是我尝试将密码管理方案迁移至 Bitwarden,并选择通过自托管 Vaultwarden 来替代官方订阅服务。Vaultwarden 是一个由社区维护的轻量级服务端实现,不仅兼容 Bitwarden 核心协议,更能完美适配官方客户端。其资源占用极低,可以部署于 NAS 或树莓派。彼时的我认为,这似乎是在“同步便利性”与“数据掌控权”之间找到的一个完美平衡点。

为什么会想用 Bitwarden

同步省心

与 1Password、LastPass 等主流方案一致,Bitwarden 采用标准的「服务端 + 客户端」架构。所有凭据由云端(或自托管服务端)统一分发,实现了真正的实时多端同步。相比 KeePass 须时刻惦记“修改后同步数据库文件”的繁琐,Bitwarden 彻底抹平了这一认知负担。

自带安全检查

Bitwarden 内置了完善的密码健康度分析、弱密码预警及泄露检测功能。它将分散的账户风险通过仪表盘集中呈现,方便用户及时处置潜在隐患。

密码健康检查
密码健康检查

现代化的一致体验

无论是在浏览器扩展、桌面端还是移动 App,Bitwarden 都保持了高度统一的 UI 设计与交互逻辑。相较于 KeePass 浓重的“极客工具感”,Bitwarden 的操作路径更为清晰直观,即便是非技术用户也能迅速上手。

深入使用后的“水土不服”

尽管纸面参数看似无懈可击,但在高频使用的真实场景中,一系列体验落差开始显现。

排序逻辑僵化

Bitwarden 的条目与文件夹强制依赖名称(A-Z)排序,完全缺失了 KeePass 中灵活的“自由拖拽排序”功能。若想将高频账号置顶,或按照个人习惯组织列表顺序,只能通过极其笨拙的重命名方式变相实现。

数据库管理受限

Bitwarden 的安全策略相对固化,例如对主密码复杂度的强制校验及繁琐的修改流程。相比之下,KeePass 赋予了用户对数据库加密算法、迭代次数及密钥文件组合的完全控制权,这种“丰俭由人”的开放性是 Bitwarden 难以企及的。

自托管的稳定性隐忧

选择自托管 Vaultwarden,就意味着你得自己抗下服务器运维的苦活。相比之下,KeePass 搭配坚果云、OneDrive 等成熟的 WebDAV 服务,稳定性反而更有保障。毕竟个人的 NAS 或服务器难免遇到断电、断网或者硬盘故障。

结论:回归 KeePass

折腾一圈之后,两者优劣已十分清晰:

| 维度 | Bitwarden | KeePass | | :

不用 Steam Link,Moonlight + Sunshine 打造低延迟家庭云游戏

2026年1月23日 08:00

帮你在客厅的大电视上,以极低的延迟畅玩书房高配电脑里的 3A 大作。

前言:什么是 Moonlight + Sunshine?

简单来说,就是把电脑(被控端)的画面实时传输到电视/手机/平板(控制端),并把手柄/键鼠的操作回传给电脑。相比 Steam Link,这套方案延迟更低、画质更好,支持 HDR 和 120Hz,是目前体验最好的局域网串流方案。

安装与连接

电脑端(被控端)

安装 Sunshine。安装完成后,Sunshine 会自动在后台运行。

电视/手机端(控制端)

安装 Moonlight

配对

  1. 确保电脑和电视连接在同一个局域网(强烈建议使用 5G WiFi 或有线连接)。
  2. 在电视上打开 Moonlight,应该能自动搜索到你的电脑(显示为一个电脑图标)。
  3. 点击连接,电视上会显示一个 PIN 码。
  4. 在电脑上打开 Sunshine 管理界面(浏览器访问 https://localhost:47990),输入这个 PIN 码完成配对。

核心设置:分辨率与画质

很多新手遇到的最大问题是:电脑显示器是 1080P,电视是 4K,怎么让游戏在电视上以 4K 运行?

这里有三种方法,推荐程度依次递增:

方法一:通过 Moonlight 客户端设置

这是最简单的方法,Moonlight 会告诉 Sunshine "我想要什么分辨率的画面"。

  1. 打开电视上的 Moonlight。
  2. 找到已配对的主机,点击设置图标(齿轮)。
  3. 进入 Streaming Settings:
    • Resolution(分辨率):设置为 4K (3840x2160)1080p
    • Framerate(帧率):推荐 60 FPS(更稳定)或 120 FPS(更流畅,需网络支持)。
    • Bitrate(码率):
      • 1080P 建议:15 - 30 Mbps
      • 4K 建议:40 - 80 Mbps
    • Video Codec:首选 HEVC (H.265),画质更好带宽占用更低。

方法二:使用虚拟显示器

如果你想让电视拥有完美的 4K HDR 体验,而不受物理显示器限制,安装 Sunshine 虚拟显示器驱动是最佳选择。

  1. 打开 Sunshine 管理页面,进入 Configuration -> General
  2. 找到 "Sunshine Virtual Display Driver",点击 Instal 按钮自动下载并安装。
  3. 安装后,Sunshine 启动串流时会自动创建一个虚拟显示器。
  4. 你可以在 Windows 显示设置里,单独为这个虚拟显示器设置 4K 分辨率和 HDR。

方法三:修改 Sunshine 默认分辨率

在 Sunshine 后台手动指定分辨率。

  1. 打开 Sunshine 管理界面 (localhost:47990) -> Configuration。
  2. 找到 Desktop Resolution Presets。
  3. 将 Desktop 模式的分辨率改为你期望的数值。

常见问题与优化建议

  • 网络连接:串流对网络稳定性要求极高。
    • 有线连接 > 5G WiFi > 2.4G WiFi(绝对不要用 2.4G)。
    • 如果电视只有百兆网口,建议通过 USB 3.0 转千兆网卡扩展,或者使用高素质的 WiFi 6。
  • 关于黑屏:如果连接后黑屏但有声音,通常是分辨率设置冲突或 HDCP 问题,尝试使用方法二的虚拟显示器可以解决大部分问题。
  • 手柄支持:Moonlight 完美支持 Xbox 手柄、PS4/5 手柄震动透传。建议将手柄连接到电视/电视盒子上。

实际体验:Wi-Fi 的局限性

虽然理论上 5G Wi-Fi 带宽足够,但在我的实际测试中,无线连接的稳定性依然是最大瓶颈。

测试环境 1:同一房间,距离路由器约 3 米,使用 5G Wi-Fi。 结果:依然存在间歇性卡顿,即使我尝试降低分辨率和帧率,流畅度也没有达到完美预期。

测试环境 2:书房与客厅隔着两堵承重墙。 结果:卡顿明显,基本无法正常游玩。

结论: 虽然 Sunshine + Moonlight 方案上限很高,但对网络环境(尤其是延迟抖动)非常敏感。如果希望获得“如本地般丝滑”的体验,有线连接 依然是不可替代的终极解决方案。如果条件受限必须用 WiFi,请做好心理预期,或者尝试升级到更高端的 WiFi 7 路由器并独占频段。

Notion 很好用,但它的开机启动真的是个灾难

2026年1月22日 08:00

Notion 是一款非常优秀的工具,管理着我所有的 Mermaid 流程图。但在 Windows 平台上,其开机启动体验堪称灾难级别。

许多用户开机后都会遇到 Notion 自动启动却一片空白的现象。无论归咎于网络波动还是程序响应延迟,这种「死机般」的体验都极度影响使用好感。

对此,最彻底的解决思路只有一条:完全禁用 Notion 原生自启,转为通过脚本手动延时启动

一、形同虚设的启动选项

许多用户试图在 Notion 设置中关闭“开机启动”,却往往徒劳无功。事实上,该选项并未直接展示在设置面板中,而是隐藏在任务栏托盘图标的右键菜单里,名为「登录电脑时打开 Notion」。

更令人沮丧的是,这个开关存在明显缺陷——即便用户取消了勾选,重启电脑后它往往会自动复原。这一点在 Reddit 上已被大量用户证实。

二、终极方案:任务管理器强制禁用

既然软件内部的软开关失效,就必须通过 Windows 系统层级进行硬性管制。

  1. 打开任务管理器(快捷键 Ctrl + Shift + Esc)。
  2. 切换至「启动应用」选项卡。
  3. 定位到 Notion。
  4. 右键点击并选择「禁用」。

此操作能从系统底层切断 Notion 的自启权限,彻底根除白屏困扰。

三、进阶方案:脚本延时启动

禁用自启虽然解决了白屏,但也意味着每次开机都需要手动打开软件。若通过脚本实现延时启动,则可兼顾“自动化”与“稳定性”——让 Notion 在系统和网络完全就绪后再运行。

1. 创建脚本

新建一个文本文档,填入以下代码,并将文件后缀名修改为 .bat(例如 NotionDelay.bat):

@echo off
:: 等待 60 秒,确保网络连接就绪
timeout /t 60 /nobreak
:: 启动 Notion(请根据实际安装路径调整)
start "" "%LOCALAPPDATA%\Programs\Notion\Notion.exe"
exit

提示:如果不确定 Notion 的具体安装路径,可在桌面 Notion 图标上点击 右键 -> 属性 -> 目标 进行查看。

2. 配置自启

  1. Win + R 打开运行窗口。
  2. 输入 shell:startup 并回车,系统将打开「启动」文件夹。
  3. 将制作好的 .bat 文件(或其快捷方式)放入该文件夹内。

配置完成后,脚本将在每次开机时自动运行并等待 60 秒。待系统负载稳定、网络畅通后,脚本才会唤起 Notion,从而确保软件界面极速加载,彻底告别白屏。

手机网页如何抓包?用 USB 连接电脑实现真机调试

2026年1月20日 08:00

在排查用户反馈的“功能异常”时,很多时候问题并非出在工具本身,而是网络环境的差异所致。

PC 端的网络往往充满了变数:公司内网策略、代理软件、Hosts 修改、DNS 污染等等。这些因素都可能导致请求失败,而在开发者自己的电脑上却难以复现。

为了排除这些干扰,我通常会选择使用手机(蜂窝数据)来进行测试。这是一个相对“纯净”、独立的网络环境。但随之而来的痛点是:手机浏览器虽然环境纯净,却缺乏 PC 浏览器那样强大的 Network 面板,无法直观看到具体的请求细节和报错信息。

本文介绍一种我常用的方案:让手机走纯净的网络环境,通过 USB 连接电脑,在 PC 端的 DevTools 中查看手机上的网络请求

Android + Chrome DevTools

适用于 Android 手机 + Windows / Mac 电脑。

手机端设置

  1. 进入设置 → 关于手机,连续点击「版本号」7 次,开启开发者模式
  2. 返回设置,进入开发者选项,启用「USB 调试」

连接与调试

  1. 用数据线连接手机和电脑

  2. 手机端切换 USB 模式为「传输文件(MTP)」或「传输照片(PTP)

  3. 电脑端打开 Chrome,地址栏输入:

    chrome://inspect/#devices
  4. 勾选 Discover USB devices,等待设备出现

  5. 在手机 Chrome 打开目标页面,电脑端点击 Inspect

DevTools Network 面板
DevTools Network 面板

现在你可以在 DevTools 的 Network 标签页中,实时查看手机发出的所有请求。

Chrome Inspect 界面
Chrome Inspect 界面

iPhone + Safari Web Inspector

适用于 iPhone + Mac 电脑(Windows 暂不支持)。

iPhone 设置

  1. 进入设置 → Safari → 高级
  2. 开启「网页检查器(Web Inspector)」

Mac 设置

  1. 打开 Safari,进入设置 → 高级
  2. 勾选「在菜单栏中显示"开发"菜单」

Safari 连接与调试

  1. 用数据线连接 iPhone 和 Mac
  2. 在 iPhone Safari 中打开目标页面
  3. Mac Safari 菜单栏点击开发 → [你的 iPhone 名称]
  4. 选择当前正在浏览的网页,即可打开 Web Inspector 查看 Network

常见问题排查

Chrome Inspect 看不到设备

USB 调试是物理连接行为,与网络无关。如果设备未显示,按以下顺序排查:

| 问题 | 解决方法 | |

Ant Design v6:zeroRuntime 使用与踩坑总结

2025年12月31日 08:00

React 19 与 Ant Design v6 升级完成后,我明显感觉到页面 CLS(累积布局偏移)性能变差。首屏渲染时样式出现闪烁,组件尺寸直至 JS 执行完毕才最终稳定。这种情况在 Docusaurus 等静态站点中尤为严重。

一开始我尝试通过 CSS 强制锁定组件宽高(min-width / min-height)缓解偏移,但这牺牲了代码的可维护性。为此,我开始尝试 Ant Design 官方提供的 zeroRuntime 方案。

本文记录了我在使用 Ant Design zeroRuntime 过程中遇到的核心问题、踩过的坑,以及最终为什么选择了 「只使用 CSS + 单一主题」 这一方案。

问题根因:Ant Design 的 CSS 并不是完整样式

在排查过程中,我发现了一个关键事实:

antd/dist/antd.css 中大量使用 var(--ant-*)
但这些 CSS 变量并不存在于任何静态 CSS 文件中

原因在于 Ant Design v6 的样式机制:

  • Ant Design v6 默认使用 CSS-in-JS
  • --ant-* 这类 CSS 变量是:
    • 由 JS 在运行时动态注入
    • 而非静态 CSS 中提前定义

对于 Docusaurus 这类预渲染的静态 HTML 来说:

  • 首屏只包含 HTML 结构
  • CSS 变量尚未注入
  • 等 JS 执行完成后样式才完整
  • 因此不可避免地产生 CLS 和样式闪烁

即使已经引入了 antd/dist/antd.css, 只要 CSS 变量依赖运行时注入,首屏 HTML 本身仍然“感知不到完整样式”

zeroRuntime 的设计原理

zeroRuntime 的核心目标非常明确:

在构建阶段生成完整样式,而不是依赖运行时 CSS-in-JS 注入

官方文档对此的描述是: zeroRuntime 会在构建时,根据配置生成一份完整、可直接使用的 CSS 文件

具体表现为:

构建阶段

  • 通过 genAntdCss.mjs(或类似脚本)
  • 基于指定的 theme、token 配置
  • 生成一份完整、静态 CSS

运行阶段

  • 不再生成或注入样式

  • 组件默认假设:

    所有样式已经存在于页面中

这直接带来一个非常重要的结论:

使用 zeroRuntime 后,所有样式相关配置必须在构建期确定

zeroRuntime 下的能力边界(能做 / 不能做)

这是使用 zeroRuntime 必须接受的现实边界。

✅ 可以做的事情

  • 在生成脚本中配置全局 theme
  • 构建阶段生成一套固定主题的 CSS
  • 使用 ConfigProvider 设置 locale(不影响样式)

❌ 不能做的事情

  • 在组件中通过 ConfigProvider 动态设置 theme
  • 使用 theme.useToken()
  • 运行时切换主题色、componentSize 等样式相关 token

一句话总结:

zeroRuntime = 样式在构建期“完全写死”,JS 不再参与样式生成

这并不是限制,而是 zeroRuntime 的设计前提。

cssVar.key 必须完全一致

在启用 zeroRuntime 时,有一个非常容易忽略、但影响极大的配置点:

cssVar: {
  key: "aishort";
}

这个 key 的作用是: 作为 Ant Design CSS 变量的命名空间标识。

⚠️ 必须保证以下两处完全一致:

  1. 生成 CSS 的脚本配置中
  2. 应用主题时使用的配置中

如果不一致:

  • 构建出来的 CSS 变量无法被组件正确命中
  • zeroRuntime 实际上是“未生效”的
  • 页面刷新时会出现:
    • 字体大小闪烁
    • 组件样式先错后对

一个非常简单的判断方法:

刷新页面是否出现样式闪动?

  • 有 → zeroRuntime 没有真正生效
  • 没有 → 样式已经完全静态化

多主题:理论可行,工程上不值得

我曾尝试过生成 浅色 + 深色两套 CSS,并在运行时进行切换。

结论非常明确:

复杂度极高,不值得投入。

主要问题包括:

  • 多套 CSS 同时存在时:

    • 后加载的主题会覆盖前者
  • 即使切换主题:

    • 实际生效的仍然是权重更高的那套变量
  • 为了解决变量覆盖问题:

    • 需要大量人为拆分、加权、隔离
  • 可维护性和可预测性急剧下降

最终结论是:

zeroRuntime 并不适合运行时多主题切换

因此目前站点仅保留 单一深色主题,不再提供主题切换能力。

ConfigProvider 的现实限制

Ant Design v6 提供了大量基于 ConfigProvidertheme.useToken 的定制能力。

但在 zeroRuntime 模式下:

  • 这些能力几乎全部不可用
  • 官方文档中也明确指出:
    • zeroRuntime 仅适用于 构建期确定样式的场景

这意味着:

  • 原本基于 Ant Design 统一主题系统的设计
  • 需要回退到:
    • 写死样式
    • 预编码 token
    • 构建期生成 CSS

本质上,这是一次明确的取舍:

用灵活性,换取首屏性能和样式稳定性

总结

zeroRuntime 并不是一个“无脑开启就能提升体验”的方案,它更像是一个 为静态站点和性能极致优化而设计的工程取舍

它确实解决了:

  • CLS 问题
  • 首屏样式闪烁
  • 运行时样式注入带来的不确定性

但代价同样明确:

  • 主题必须在构建期确定
  • 动态主题能力几乎全部失效
  • 多主题的工程复杂度呈指数级上升

如果你的项目:

  • 是静态站点(如 Docusaurus)
  • 主题风格长期稳定
  • 更看重首屏性能和视觉一致性

那么 zeroRuntime 是值得使用的方案

但如果你需要:

  • 运行时动态主题
  • 高度可配置的设计系统

那么就必须接受 CSS-in-JS 带来的运行时成本, 或者等待 Ant Design 在未来提供更成熟的解决路径。

007 | AI热潮带来的变化

2025年11月16日 08:00

5月底的赛里木湖,稍微下了点雨,上山后什么都看不见

文章

除了内存,AI 也在导致硬盘涨价

https://www.tomshardware.com/pc-components/hdds/ai-triggers-hard-drive-shortage-amidst-dram-squeeze-enterprise-hard-drives-on-backorder-by-2-years-as-hyperscalers-switch-to-qlc-ssds

人工智能的快速发展导致了数据中心的建设急剧增加,远远超出了制造商的生产能力。这种情况不仅导致了内存条的价格飙升,还引发了硬盘供应短缺,特别是企业级硬盘的交货时间已经延长到了两年。为了避免这种延迟,许多超大规模计算服务提供商(hyperscalers)开始转向使用 QLC NAND-based SSDs,以保持成本并实现足够的耐用性。然而,QLC NAND 的需求激增导致了全球 SSD 价格上涨的趋势,预计 QLC NAND 将在 2027 年初超过 TLC 成为主流存储技术。

AI 需求上涨不仅仅是内存受影响,还先导致机械硬盘短缺,然后转向 QLC 固态硬盘。

巴基斯坦报纸误将AI提示词与文章一同刊出

https://x.com/omar_quraishi/status/1988518627859951986

If you want, I can also create an even snappier “front-page style” version with punchy one-line stats and a bold, info-graphic-ready layout

006 | 笔记的价值

2025年11月7日 08:00

拍摄于11月的绍兴东湖。说是湖,但面积其实很小,1个小时就逛完了

文章

从机构记忆看笔记的重要性

https://timharford.com/2025/05/the-value-of-institutional-memory/

组织可能会忘记过去的经验教训,导致类似的错误重新发生,如大众汽车的排放测试欺骗事件和航天飞机爆炸事件。

AI 会把我们的知识不断压缩,让我们直接问它就可以了。但从机构记忆的价值可知。除非AI给出的已经是最终方案,我们依然不断记录自己的笔记和解决方案。

链式思维的大型语言模型并不具备推理能力

研究人员强调,当前的大型语言模型在生成 “流畅的无意义”(fluent nonsense)内容时,可能会创造出一种误导性的可靠感,这并不代表真正的推理能力。

目前的 AI 是随机生成,它只能对结果靠训练资料作出筛选。

新尝试

老硬盘的用处

为旧电脑清灰时发现一块 浦科特 M6S 128GB, 借助 2.5 寸转 3.5 寸硬盘盒,插入 NAS 做缓存盘了,提高了 Docker 容器的随机读写速度。

桌面麦克风新方案

最初我用的是桌面电容麦克风(心形指向),收音音质很好,但必须离嘴巴非常近(约5~30厘米)才能听清楚,而且放在桌面上也很占位置。我大部分时间只是用它进行语音输入,这种“录音棚级”的音质其实完全没有必要。

因此,我开始考虑使用收音距离更远的麦克风,比如会议用的全向麦克风(音质会比较嘈杂)。

在这个过程中,我突然想到自己有一个很便宜的摄像头,它自带麦克风。于是我试着用它进行语音输入。结果发现,它虽然录音音质很差,但在语音输入时识别准确、能清楚听懂我的话,对我来说已经足够了。

加快周刊更新

周刊已经更新了一段时间,因为我总想着写一篇“大文章”或长文,结果反而导致输出变少了。

所以接下来一周,我打算把之前的一些文章——无论是半成品还是尚未完善的——尽量整理并发布出来,用这一周的时间来解决这个问题。

之后,周刊也会全面恢复正常更新。有时可能只会分享一些小内容,但重要的是不能中断更新。

三年半的新机为何比 11 年老机更卡?一次散热与维护全记录

2025年9月29日 08:00

电脑变“卡”,很多时候并不是性能不够,而是散热与维护问题。本文记录了我对一台用了三年半的新机进行的排查:从软件优化、清灰、更换硅脂,到水冷报废、改用风冷,再到风扇调节与硬件升级。最后整理出一份维护计划和配置建议,供大家参考。

当电脑开始出现:开机变慢、应用响应迟缓、风扇噪音增大,甚至系统不稳定,原因通常有两个:

  1. 散热效率下降 → 硬件降频;
  2. 硬件性能不足 → 难以满足新应用需求。

我家里有两台台式机:

  • 2014 年老机:Win10 系统,已用 11 年,依然运行流畅;
  • 2022 年新机:i7-12700KF + RTX 3080Ti + 64GB,当时算高配。

没想到,用了三年半后,新机竟然开始“卡顿”。于是我开始了一次彻底的散热与维护排查,以下是全过程记录。

工具诊断:先确认方向

动手之前,先用工具排查:

  • LatencyMon:检测系统延迟,用于排查日常使用中的卡顿问题。
  • HWMonitor:监控关键硬件的传感器数据,如温度、电压和风扇转速。
  • Process Explorer:深入分析进程信息,找出在系统响应缓慢时资源占用过高的程序。在 CPU 占用图中,绿色代表用户进程,红色则代表系统核心或驱动程序。

👉 建议的排查顺序:

  1. 先看是否是软件进程异常;
  2. 若软件正常,再重点检查散热和温度。

例如,我曾因开启 ManicTime 的屏幕截图功能,导致切换应用时出现短暂卡顿,关闭后问题立刻消失。此外,另一个可能原因是电源。我也是在一次突然断电黑屏后才察觉到这一点,而这通常难以及时判断。

硬件维护:散热是关键

清灰:第一步必做

散热问题往往来自灰尘。它会堵塞进气口、覆盖鳍片,导致温度升高、风扇狂转、最终触发降频。

清洁前准备

  1. 彻底断电:关机,关闭电源供应器(PSU)背后的开关,并拔掉电源线。
  2. 选择通风环境:最好在室外或阳台,避免灰尘在室内弥漫。
  3. 防静电:在接触任何内部组件前,务必触摸机箱的金属部分以释放身体静电。

清洁步骤

  1. 拆卸侧板:打开机箱,暴露内部组件。
  2. 清洁防尘网:找到并取下机箱的防尘网(通常位于前面板、顶部和PSU下方),用水或刷子彻底清洁。
  3. 吹灰:推荐使用压缩空气罐,短促、有力地喷射,并始终保持罐体直立,以防液态推进剂喷出。(我这次用了530精密电器清洁剂,后发现有些人说可能有硅油残留。为安全起见,建议用压缩空气。)
  4. 清洁风扇:在对CPU、显卡、机箱和PSU风扇进行吹灰时,必须用手指或棉签轻轻固定住扇叶,防止其因气流过快旋转而损坏轴承。对于附着牢固的灰尘,可以用棉签蘸取少量高纯度(>90%)异丙醇进行擦拭。
  5. 清洁散热鳍片:将气流对准CPU和显卡散热器的金属鳍片,吹走积聚在内部的灰尘。

SSD 散热:小投入,立竿见影

我的 SSD 待机温度常年 60℃+。加装被动散热片后,降至 40–50℃,卡顿现象有所缓解。安装时注意:SSD 上的原厂贴纸可能是保修凭证,可自行选择是否移除。

👉 建议:SSD 长期高温会影响寿命,几十元的散热片立竿见影。

CPU 导热硅脂:3–5 年就要换

导热硅脂填充在 CPU 顶盖与散热器底座之间,保证热量高效传导。几年后会逐渐干涸、硬化,导致 CPU 温度升高。

更换步骤:

  1. 拆卸CPU散热器:首先断开CPU风扇的电源线,然后根据散热器的固定方式(卡扣或螺丝)将其从主板上取下。由于旧硅脂可能有粘性,轻轻旋转一下散热器有助于分离。
  2. 清理旧硅脂:使用无绒布(如咖啡滤纸)或超细纤维布,蘸取适量异丙醇,彻底擦拭CPU顶盖和散热器底座上的所有旧硅脂。
  3. 涂抹新硅脂:将一粒米或豌豆大小的新硅脂挤在CPU中央即可。无需手动涂抹,散热器的压力会自动将其均匀压开,形成一个薄而均匀的导热层。
  4. 重新安装散热器:将散热器垂直、平稳地放回CPU上,避免滑动。然后以对角线顺序分次拧紧螺丝,以确保压力均匀分布。

⚠️ 不要用消毒湿巾或低浓度酒精,避免水分残留损伤硬件。

我更换硅脂后,开机温度直飙到 100℃。排查发现,并不是涂抹问题,而是水冷散热器老化。

一体水冷报废 → 换风冷更安心

一体式水冷散热器寿命通常只有 3–5 年。随着时间推移,可能会出现以下问题:

  • 冷却液损耗:虽然是密封系统,但仍有极少量冷却液会随时间蒸发,可能影响散热性能。
  • 水泵故障:这是最常见的故障点。如果系统过热且您在iCUE等监控软件中看到水泵转速(RPM)为0,或听到水泵发出异常噪音,则可能意味着水泵已经损坏。
  • 气泡问题:如果您听到水冷头或管道内有明显的“咕噜”或冒泡声,说明冷却循环内混入了空气。您可以尝试轻轻前后倾斜机箱,或将水泵转速设为最高运行一小时,以帮助将气泡排出水泵,聚集到冷排顶部。

我这套水冷用了三年半,性能已明显衰退,更换硅脂时甚至彻底坏掉。于是换上 200 元的双塔风冷,CPU 温度降至 30–50℃,比之前低了 20℃。

对比来看:

  • 老机的风冷 → 11 年依然坚挺;
  • 新机的水冷 → 3 年半报废。

👉 建议:能用风冷就别折腾水冷。

风道检查

更换风冷后,我在机箱顶部加装了两个 140mm 风扇。用 AIDA64 监控后发现:新风道是“负压”(出风大于进风)。虽然排热效率可能稍高,但容易从各处缝隙吸入灰尘。理想状态是略微正压,以兼顾散热与防尘。如果你搞不清风道怎么算,可以把传感数据都丢给AI分析。

于是我在 BIOS/UEFI 中调整了前置进风风扇的转速。操作流程是:开机时按特定键(通常是Del)进入BIOS设置,可以找到如“QFan Control”(华硕)、“Hardware Monitor”(微星)或“Smart Fan”(技嘉)等选项。在这里,您可以为CPU和机箱风扇选择预设模式(如静音、标准、性能),或根据温度手动设定风扇转速曲线。

调节时,注意记录主板接口与风扇的对应关系,便于后期调整。比如我的风扇布局如下:

进气:前 2(#3、#4)
CPU 风冷:双塔,从前吹后 (#2)
排气:上 2(#1)、后 1(#5)
GPU:自带 3 风扇

显卡风扇控制

与机箱风扇不同,显卡风扇需要专门的软件来进行控制。

  • 通用第三方工具:MSI Afterburner 是广受欢迎的显卡超频和监控工具,它兼容NVIDIA和AMD的绝大多数显卡。用户可以通过其“风扇”设置选项,启用自定义的自动风扇控制,并拖动节点来设定一条与GPU温度相对应的风扇转速曲线。
  • 品牌专用软件:
    • 华硕(ASUS):提供GPU Tweak III软件,用于调整显卡参数,包括风扇控制、超频和电压调整。
    • AMD:Adrenalin Edition 驱动套件中内建了“性能调优”工具,允许用户直接控制显存频率、核心频率以及风扇速度。
    • NVIDIA:也提供官方工具,允许用户动态调整风扇速度,并可设置基于温度的自动控制。

原本还计划顺便给显卡更换硅脂,但考虑到(手残)风险太大就放弃了。好在显卡平时温度维持在 60℃ 左右,属于正常范围。

电源:最容易被忽视的隐患

电源问题对电脑的影响远比想象中严重,但又很难直接诊断。当电源老化或供电不稳时,可能出现以下症状:

  • 电压波动:导致 CPU/GPU 降频保护,表现为不规则的卡顿或掉帧;
  • 突然断电/黑屏:高负载时电源供电不足,系统直接关机;
  • 啸叫/异响:电源内部元器件老化,发出高频噪音。

排查与处理建议:

  1. 直接接墙插:电源线应插入墙壁插座,而非排插,以减少电压损耗和静电干扰。
  2. 善用保修:台式机电源通常有 5–10 年的质保。我这台电源在使用三年半后,进入冬天经常需要彻底断电放静电才能开机。联系店家后成功更换了新的电源。第一台换来的存在啸叫问题,再次申请更换后,第二台才恢复正常。
  3. 更换全套模组线:如果更换电源,建议一并换掉所有模组线(显卡供电线、主板 24pin、CPU 8pin、SATA 线等),避免老化线材带来的接触不良。

我这次卡顿的根本原因很可能就是电源。换新后,系统稳定性明显改善,再也没有出现过无故黑屏或随机卡顿。

⚠️ 电源故障不像温度问题那样有明确数据可看,排查时容易被忽略。如果前面的散热、软件都没问题,电源值得重点怀疑。

软件优化:MSI Utility V3

MSI Utility V3 是一款第三方开发的小工具,通过启用 Message Signal Interrupt (MSI) 模式,优化 Windows 的中断处理,避免传统线基中断容易因共享 IRQ 产生冲突而出现的高延迟(DPC/ISR 延迟)、随机卡顿。

十年内的电脑基本都支持 MSI Utility V3,我个人体验效果明显。AMD 显卡默认开启 MSI,NVIDIA 需手动切换。

使用方法:

  1. 下载 Msi-Utility-v3
  2. 以管理员身份运行 MSI_util_v3.exe
  3. 找到显卡(如 "NVIDIA GeForce RTX xxxx") → 勾选 “MSI” → 优先级设为 High
  4. 点击右上角 "Apply",重启电脑生效

推荐设置:显卡/声卡/网卡设为 High,NVMe 控制器设为 Normal。

硬件升级:低成本提升

SSD 升级

把系统盘从机械硬盘迁移到固态硬盘(SSD),提升最明显:开机时间大幅缩短、系统响应变快。

实现迁移主要有两种途径:

  • 克隆:使用专用软件将旧硬盘的内容完整复制到新SSD上。这种方法保留了所有数据和设置,非常便捷,但有时也会将旧系统中的潜在问题一并带过来。
  • 全新安装:在新SSD上全新安装Windows,然后重新安装应用程序并迁移个人数据。虽然步骤较多,但能保证最佳的性能和稳定性。

内存升级

内存不足时,系统会频繁调用虚拟内存(硬盘空间),造成明显卡顿。但在如今的大多数场景下,这个瓶颈已经不常见。对 Win11 用户来说,32GB 已经足够覆盖日常使用。我自己的 64GB 内存,常年占用不到 40%。

如果你要升级内存,要注意以下几点:

  • 检查兼容性:确定主板支持的 DDR 类型、最大容量与频率。
  • 双通道更优:例如 2×8GB 比单条 16GB 性能好。安装时需将内存条插入主板上指定的配对插槽中。
  • 频率设置:部分内存需在 BIOS 启用扩展内存预设(XMP)才能跑满标称频率。例如,DDR5-6000 内存条一般默认仅以4800MHz的频率运行。

总结与维护计划

调整后,整机表现明显改善:

  • CPU 温度 ↓ 20℃
  • SSD 温度 ↓ 15℃
  • LatencyMon 测试一整天无异常

长期维护表

| 频率 | 任务 | | :

Cloudflare WARP教程:轻松获取海外纯净IP

2025年8月12日 08:00

在注册海外账户或申请 API(如 Telegram 的 api_id/api_hash)时,如果出现莫名的「ERROR」,很可能是平台将你识别为 “VPN/数据中心”流量,从而触发了风控。 此时,可以使用 Cloudflare WARP 获取更像“家用宽带”的出口 IP,从而提升通过率。

重要提示 Cloudflare WARP 不是“科学上网”工具,免费版的带宽和可用性一般,不建议作为常用 VPN。 它更适合在访问风控严格的网站时临时使用,完成操作后及时关闭。

Cloudflare WARP 是什么?

Cloudflare WARP 基于 WireGuard 协议工作,让你的网络流量经过 Cloudflare 节点中转,获得更“干净”、更接近普通家庭网络的出口 IP。 在 Windows、macOS、Android、iOS 等平台都可以一键连接,使用体验接近普通 VPN,但更适合解决特定的风控问题。

解决 Telegram API 申请 ERROR 的步骤

  1. 下载并安装 WARP 客户端:前往 https://one.one.one.one 下载并安装 Cloudflare 1.1.1.1(WARP) 客户端。

  2. 切换到 WARP 模式:打开应用,将模式切换为 WARP,然后点击连接按钮。

  3. 申请 Telegram API:使用浏览器的无痕/隐私模式访问 https://my.telegram.org/apps,登录账户并申请 api_id 与 api_hash。

  4. 遇到 ERROR 时切换出口 IP:如果仍提示 ERROR,可在 WARP 客户端点击“断开/重新连接”,更换出口 IP 后再刷新页面重试。

小贴士 同一账号在短时间内多次失败可能触发额外风控,建议等待几小时后再尝试。

如何检查 IP 质量

使用 ipdata 查询当前 IP 信息,重点查看 TRUST SCORE

  • 分数高 → 更可能顺利通过平台风控
  • 分数低/标记为高风险 → 可能仍会被拒绝
得分样例,这个 IP 属于高危,大概率无法通过
得分样例,这个 IP 属于高危,大概率无法通过

005 | 减少 AI 带来的焦虑

2025年8月8日 08:00

封面图片拍摄于今年六月的新疆禾木。到了那,我才发现天能有多蓝,中午可以清晰的看见月亮。

文章

人工智能承诺提高效率,但它却让我们工作得更辛苦

https://afterburnout.co/p/ai-promised-to-make-us-more-efficient

人工智能工具本应释放我们的时间,但它们增加了我们的认知负荷,降低了我们的工作效率。 这种模式在各项研究中是一致的:人工智能工具创造了一种效率的错觉,同时经常使系统更努力地工作,而不是更智能。个人开发人员感觉更快,但团队交付速度更慢。人们报告说节省了时间,但组织发现协调成本增加。 即使生产力确实提高了,“在相同的时间内完成两倍的工作”——不是减少工作,只是在相同的时间里塞进更多的工作。我们不应该试图在相同的时间内做更多的工作;我们不应该以提高时间效率为目标,这样我们就不必每周工作 60+ 小时。

我们是不是过于追求效率,反而导致自己的生活失衡了?

人工智能并没有让工作效率提高 10 倍

https://colton.dev/blog/curing-your-ai-10x-engineer-imposter-syndrome/

10 倍的生产力意味着十倍的结果,而不是十倍的代码行。这意味着您过去在一个季度内发货,现在只需一周半即可发货。这些数字应该会让最真实的人工智能信徒停下来。传统上需要 3 个月的工作中的产品构思、故事点协商、错误修复、代码审查、等待部署、测试和 QA 的数量现在在 7 个工作日内完成?为此,这些瓶颈中的每一个都必须提高 10 倍的生产力。 LLM 产生的东西通常是损坏的、产生幻觉的或低于代码库标准的。这些错误的频率随着代码库的大小而增加。发生这种情况时,您必须重新提示,这可能会立即解决问题,或者可能会浪费大量时间。或者你可以自己进去修复代码。但随后你又回到了区区 1 倍的工程师身份,如果你已经习惯了 vibe 编码而忘记了如何编码 ,也许会更糟。

这篇文章戳破了 AI 生产力论的面具。如果你有相同的纠结,值得细读。

缺乏意图是导致阅读LLM生成的文本令人疲惫的原因

https://lambdaland.org/posts/2025-08-04_artifical_inanity/

我假设作者选择他们所用的词是有原因的,并且每个句子都是为了传达作者希望我理解的东西。 LLM 或类似生成文本时,此模式将失败。当我以为自己正在阅读真实的文本时,阅读草率的文本是令人筋疲力尽的:由于我对幻觉或无关紧要的事物没有警惕,所以每一个看似不合时宜的短语都会让我想知道为什么这个短语会在那里 ,以及我错过了什么 ,而实际上,这样的问题是格式不正确的:那只是一个偶然创作的短语, 听起来不错,但实际上根本没有太多意图。 缺乏意图是阅读人工智能如此令人反感的原因。在我们需要关心和关注的一切背后,都需要有一个人类的意图——人类的意志和人类的关怀。

我习惯用 AI 来修改文章的语法,但总会删掉其中一半的内容。除了废话过多外,更重要的是,我们往往忘了 AI 的生成原理是随机拼接。随机生成的内容,你会喜欢看?

应用

Gemini 创建个人插图故事书

http://gemini.google.com/gem/storybook

只需描述您能想象到的任何故事,Gemini 就会生成一本 10 页的插画书。英文支持语音阅读。可以用来给儿童讲故事,帮将简笔画、照片变成故事书。

❌
❌