{ "version": "https://jsonfeed.org/version/1.1", "title": "LearnData 开源笔记", "home_page_url": "https://newzone.top/", "feed_url": "https://newzone.top/feed.json", "description": "开源工具、效率方法、心理学探索的自我提升笔记，记录并输出一切能让自己提升的知识。", "favicon": "https://newzone.top/favicon.ico", "items": [ { "title": "LearnData 进阶：让 AI 和脚本接管博客维护", "url": "https://newzone.top/posts/2026-03-05-learndata-scripts-llm-seo.html", "id": "https://newzone.top/posts/2026-03-05-learndata-scripts-llm-seo.html", "summary": "写了 200 多篇文章后，我发现最耗时间的不是写作，而是 description、SEO 和侧边栏这些重复维护。本文分享我如何用 3 个脚本和 AI 接管这些杂活。", "content_html": "
\n

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

\n
\n

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

\n
\n

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

\n

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

\n

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

\n
\n

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

\n

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

\n

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

\n

它的格式非常简单：

\n
# LearnData 开源笔记\n\n> 开源工具、效率方法、心理学探索的自我提升笔记\n\n## Pages\n\n- [Rclone 远端图床本地化管理方案](https://newzone.top/_posts/...) - 利用 Rclone 建立自动化工作流...\n- [吃掉那只青蛙](https://newzone.top/reading/#/0_效率与习惯/吃掉那只青蛙) - 核心是每天先完成重要的工作...
\n

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

\n

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

\n

然后是最烦人的 SEO 检查

\n

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

\n

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

\n

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

\n

运行 pnpm seo:audit，它会扫描全站 Markdown 文件，对每篇文章按规则打分（满分 100）：

\n

| 检查项 | 扣分 |\n|

\n", "image": "https://img.newzone.top/20260305170946517.png?imageMogr2/format/webp", "date_published": "2026-03-05T00:00:00.000Z", "date_modified": "2026-03-10T13:12:53.000Z", "authors": [], "tags": [ "建站开发" ] }, { "title": "OpenClaw 实测：Cloudflare Worker 部署教程与避坑指南", "url": "https://newzone.top/posts/2026-02-06-openclaw.html", "id": "https://newzone.top/posts/2026-02-06-openclaw.html", "summary": "详解 OpenClaw 基于 Cloudflare Workers 的低成本部署全流程，涵盖 Access 鉴权、R2 存储配置与常见避坑指南，帮你判断现阶段是否值得入场。", "content_html": "
\n

注意

\n

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

\n
\n

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

\n
\n

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

\n

方案选择：Cloudflare Workers

\n

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

\n

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

\n

部署流程详解

\n

1. 一键部署 Moltworker

\n

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

\n
\n

重要

\n

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

\n
\n
\n

2. 等待构建

\n

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

\n
\n

3. 配置 Access（Zero Trust）

\n

访问网页界面需要配置 CF_ACCESS_AUD 和 CF_ACCESS_TEAM_DOMAIN 两个变量。

\n
    \n
  1. \n

    创建应用：进入 Zero Trust → Access → Applications，添加一个 Self-hosted 应用。\n

    \n
    2. \n
  2. \n

    设置域名：

    \n\n
    3. \n
  3. \n

    配置策略：系统通常会自动创建 moltbot-sandbox - Production 策略，默认通过邮箱验证码登录。

    \n
    4. \n
  4. \n

    获取变量：

    \n\n
    5. \n
\n

4. 配置 R2 对象存储

\n

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

\n\n

操作步骤：

\n
    \n
  1. \n

    获取 Account ID：在 Cloudflare 侧边栏进入 R2 → Overview，右侧 Account Details 中即可找到 CF_ACCOUNT_ID。\n

    \n
    2. \n
  2. \n

    创建 API 令牌：点击 Manage R2 API Tokens → Create API Token。

    \n
    3. \n
  3. \n

    设置权限：权限选择 Object Read & Write，建议通过 Specific Bucket 限制在 moltbot-data，避免过大授权范围。\n

    \n
    4. \n
  4. \n

    保存密钥：创建成功后，立即记录 Access Key ID 和 Secret Access Key。\n

    \n
    5. \n
\n
\n

警告

\n

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

\n
\n

5. 注入变量并重新部署

\n

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

\n
\n

访问与管理

\n

部署完成后，通过以下地址访问 Worker：

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

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

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

基础使用

\n

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

\n

查看或切换模型：

\n
/model minimax/MiniMax-M2.1
\n

设置开机自启模型（防止 Worker 重启后被重置）：

\n
set model minimax/MiniMax-M2.1
\n

远程终端连接：

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

避坑指南

\n

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

\n\n

结论：现在值得入场吗？

\n

折腾了一圈 Cloudflare Workers 之后，我的判断是：

\n

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

\n

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

\n

Cloudflare Workers + OpenClaw 适合以下场景：

\n\n

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

\n", "image": "https://img.newzone.top/20260206140242721.png?imageMogr2/format/webp", "date_published": "2026-02-06T00:00:00.000Z", "date_modified": "2026-03-05T23:42:21.000Z", "authors": [], "tags": [ "AI" ] }, { "title": "AI 绘画实战指南 Vol.2：Stable Diffusion 进阶插件", "url": "https://newzone.top/posts/2026-01-19-stable-diffusion-advanced.html", "id": "https://newzone.top/posts/2026-01-19-stable-diffusion-advanced.html", "summary": "无论是 Civitai 模型管理，还是 ControlNet 精准控图、AnimateDiff 视频生成及 InstantID 换脸实战，深度拆解 Stable Diffusion 进阶技巧，助你掌握 AI 绘画核心工作流。", "content_html": "

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

\n

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

\n

本文重点解决三个问题：

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

模型管理：Civitai 与 LoRA

\n

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

\n

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

\n

大模型（Checkpoints / Base Models）

\n

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

\n\n

微调模型（LoRA）

\n

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

\n\n

VAE（Variational Autoencoder）

\n

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

\n\n

可通过 Settings → User interface → Quicksettings list 添加 sd_vae，以便在顶部栏快速切换。

\n
\n

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

\n
\n", "date_published": "2026-01-19T00:00:00.000Z", "date_modified": "2026-03-05T01:47:52.000Z", "authors": [], "tags": [ "AI" ] }, { "title": "AI 绘画实战指南 Vol.3：ComfyUI 节点式工作流", "url": "https://newzone.top/posts/2026-01-28-comfyui.html", "id": "https://newzone.top/posts/2026-01-28-comfyui.html", "summary": "相较于 Stable Diffusion WebUI，ComfyUI 凭借低显存占用与高度可定制的节点式工作流，已成进阶首选。演示安装流程，并介绍如何利用 ModelScope 国内加速下载模型。", "content_html": "

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

\n
\n

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

\n

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

\n
\n

正确的使用姿势：是“加载”，不是“构建”

\n

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

\n

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

\n

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

\n
\n

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

\n

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

\n
\n

部署与配置

\n

1. 核心程序

\n

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

\n

2. 启动策略

\n

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

\n\n

3. 模型下载加速

\n

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

\n\n

4. 必备插件：ComfyUI Manager

\n

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

\n\n

进阶配置

\n

避免闪退：设置虚拟内存

\n

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

\n

推荐设置：初始大小与最大值均设为 32768（32GB） 或更高。

\n

操作路径：

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

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

\n
\n

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

\n

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

\n\n

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

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

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

\n
\n

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

\n\n

本地部署 vs 云端算力

\n

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

\n

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

\n
\n

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

\n", "image": "https://img.newzone.top/20260127183530405.png?imageMogr2/format/webp", "date_published": "2026-01-28T00:00:00.000Z", "date_modified": "2026-03-04T08:15:48.000Z", "authors": [], "tags": [ "AI" ] }, { "title": "Rclone 远端图床本地化管理方案：以七牛云为例", "url": "https://newzone.top/posts/2026-01-25-rclone-remote-image-management.html", "id": "https://newzone.top/posts/2026-01-25-rclone-remote-image-management.html", "summary": "如何摆脱远端图床的”黑盒”困境？利用 Rclone + 本地压缩建立”下行 → 优化 → 上行”自动化工作流，适用于七牛云、AWS S3、阿里云 OSS 等各类对象存储。", "content_html": "

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

\n\n
\n

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

\n

方案总览

\n\n

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

\n

第一步：部署 Rclone

\n

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

\n

1. 获取程序

\n

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

\n

2. 解压

\n

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

\n

3. 配置环境变量

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

4. 验证

\n

启动 PowerShell 或 CMD，执行：

\n
rclone --version
\n

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

\n
\n

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

\n
\n

第二步：建立连接

\n

前置准备信息：

\n\n

配置流程

\n
    \n
  1. \n

    执行配置命令：

    \n
    rclone config
    \n
    2. \n
  2. \n

    输入 n 新建远程连接（New remote）。

    \n
    3. \n
  3. \n

    name：命名连接，例如 qiniu。

    \n
    4. \n
  4. \n

    Storage：选择 S3（Amazon S3 Compliant Storage）。

    \n
    5. \n
  5. \n

    provider：选择 Qiniu（Qiniu Object Storage）。

    \n
    6. \n
  6. \n

    access_key_id：输入 AK。

    \n
    7. \n
  7. \n

    secret_access_key：输入 SK。

    \n
    8. \n
  8. \n

    region：留空回车。

    \n
    9. \n
  9. \n

    endpoint：根据区域填写对应的接口地址（Endpoint）：

    \n

    | 区域 | Endpoint |\n| :

    \n
    10. \n
\n", "image": "https://img.newzone.top/2026-01-24-19-37-25.png?imageMogr2/format/webp", "date_published": "2026-01-25T00:00:00.000Z", "date_modified": "2026-03-04T08:15:48.000Z", "authors": [], "tags": [ "技术分享" ] }, { "title": "密码管理器折腾记：从 KeePass 到 Bitwarden 的对比与回归", "url": "https://newzone.top/posts/2026-01-24-keepass-vs-bitwarden.html", "id": "https://newzone.top/posts/2026-01-24-keepass-vs-bitwarden.html", "summary": "密码管理器怎么选？本文记录从 KeePass 迁移至 Bitwarden 后又重返 KeePass 的全过程，深度解析两者的优劣差异，帮你找到适合的密码管理方案。", "content_html": "

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

\n
\n

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

\n

为什么会想用 Bitwarden

\n

同步省心

\n

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

\n

自带安全检查

\n

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

\n
\"密码健康检查\"
密码健康检查
\n

现代化的一致体验

\n

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

\n
\n

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

\n

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

\n

排序逻辑僵化

\n

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

\n

数据库管理受限

\n

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

\n

自托管的稳定性隐忧

\n

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

\n
\n

结论：回归 KeePass

\n

折腾一圈之后，两者优劣已十分清晰：

\n

| 维度 | Bitwarden | KeePass |\n| :

\n", "image": "https://img.newzone.top/2026-01-24-20-34-00.png?imageMogr2/format/webp", "date_published": "2026-01-24T00:00:00.000Z", "date_modified": "2026-02-12T02:00:50.000Z", "authors": [], "tags": [ "效率工具" ] }, { "title": "不用 Steam Link，Moonlight + Sunshine 打造低延迟家庭云游戏", "url": "https://newzone.top/apps/tutorials/steam.html", "id": "https://newzone.top/apps/tutorials/steam.html", "summary": "想在客厅电视畅玩电脑游戏？详解 Moonlight + Sunshine 串流方案，无需昂贵设备，利用局域网实现低延迟、高画质 PC 投屏，从零搭建家庭云游戏中心。", "content_html": "
\n

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

\n
\n
\n

前言：什么是 Moonlight + Sunshine？

\n

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

\n

安装与连接

\n

电脑端（被控端）

\n

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

\n

电视/手机端（控制端）

\n

安装 Moonlight。

\n

配对

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

核心设置：分辨率与画质

\n

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

\n

这里有三种方法，推荐程度依次递增：

\n

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

\n

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

\n
    \n
  1. 打开电视上的 Moonlight。
    2. \n
  2. 找到已配对的主机，点击设置图标（齿轮）。
    3. \n
  3. 进入 Streaming Settings：\n\n
    4. \n
\n

方法二：使用虚拟显示器

\n

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

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

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

\n

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

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

常见问题与优化建议

\n\n

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

\n

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

\n

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

\n

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

\n

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

\n", "image": "https://img.newzone.top/2026-01-23-20-06-54.png?imageMogr2/format/webp", "date_published": "2026-01-23T00:00:00.000Z", "date_modified": "2026-03-04T08:15:48.000Z", "authors": [], "tags": [ "效率工具" ] }, { "title": "Notion 很好用，但它的开机启动真的是个灾难", "url": "https://newzone.top/posts/2026-01-22-notion-startup-error.html", "id": "https://newzone.top/posts/2026-01-22-notion-startup-error.html", "summary": "Notion 开机自动启动且卡死白屏？本文详解为何软件内设置无效，并提供通过任务管理器彻底禁止 Notion 开机自启的终极解决方案，解决白屏困扰。", "content_html": "

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

\n

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

\n

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

\n
\n

一、形同虚设的启动选项

\n

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

\n
\n

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

\n

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

\n

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

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

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

\n

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

\n

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

\n

1. 创建脚本

\n

新建一个文本文档，填入以下代码，并将文件后缀名修改为 .bat（例如 NotionDelay.bat）：

\n
@echo off\n:: 等待 60 秒，确保网络连接就绪\ntimeout /t 60 /nobreak\n:: 启动 Notion（请根据实际安装路径调整）\nstart \"\" \"%LOCALAPPDATA%\\Programs\\Notion\\Notion.exe\"\nexit
\n
\n

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

\n
\n

2. 配置自启

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

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

\n", "image": "https://img.newzone.top/2026-01-24-23-21-11.png?imageMogr2/format/webp", "date_published": "2026-01-22T00:00:00.000Z", "date_modified": "2026-01-24T15:45:15.000Z", "authors": [], "tags": [ "效率工具" ] }, { "title": "手机网页如何抓包？用 USB 连接电脑实现真机调试", "url": "https://newzone.top/posts/2026-01-20-mobile-web-debug.html", "id": "https://newzone.top/posts/2026-01-20-mobile-web-debug.html", "summary": "手机浏览器没有 Network 面板？通过 USB 连接电脑，用 Chrome DevTools 直接查看真机请求。本文详解 Android 和 iPhone 的调试步骤，以及常见连接问题的解决方案。", "content_html": "

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

\n

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

\n
\n

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

\n

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

\n

Android + Chrome DevTools

\n

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

\n

手机端设置

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

连接与调试

\n
    \n
  1. \n

    用数据线连接手机和电脑

    \n
    2. \n
  2. \n

    手机端切换 USB 模式为「传输文件（MTP）」或「传输照片（PTP）」

    \n
    3. \n
  3. \n

    电脑端打开 Chrome，地址栏输入：

    \n
    chrome://inspect/#devices
    \n
    4. \n
  4. \n

    勾选 Discover USB devices，等待设备出现

    \n
    5. \n
  5. \n

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

    \n
    6. \n
\n
\"DevTools
DevTools Network 面板
\n

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

\n
\"Chrome
Chrome Inspect 界面
\n

iPhone + Safari Web Inspector

\n

适用于 iPhone + Mac 电脑（Windows 暂不支持）。

\n

iPhone 设置

\n
    \n
  1. 进入设置 → Safari → 高级
    2. \n
  2. 开启「网页检查器（Web Inspector）」
    3. \n
\n

Mac 设置

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

Safari 连接与调试

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

常见问题排查

\n

Chrome Inspect 看不到设备

\n

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

\n

| 问题 | 解决方法 |\n|

\n", "image": "https://img.newzone.top/2026-01-24-23-20-05.png?imageMogr2/format/webp", "date_published": "2026-01-20T00:00:00.000Z", "date_modified": "2026-03-05T01:47:52.000Z", "authors": [], "tags": [ "效率工具" ] }, { "title": "Ant Design v6：zeroRuntime 使用与踩坑总结", "url": "https://newzone.top/posts/2025-12-31-ant-design-v6-zeroruntime.html", "id": "https://newzone.top/posts/2025-12-31-ant-design-v6-zeroruntime.html", "summary": "总结升级 Ant Design v6 后使用 zeroRuntime 解决 Docusaurus 站点 CLS 问题的实践经验，深入分析样式构建原理、配置陷阱及性能取舍，助你避开静态化样式的那些坑。", "content_html": "

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

\n

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

\n
\n

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

\n

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

\n

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

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

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

\n\n

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

\n\n

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

\n

zeroRuntime 的设计原理

\n

zeroRuntime 的核心目标非常明确：

\n
\n

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

\n
\n

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

\n

具体表现为：

\n

构建阶段

\n\n

运行阶段

\n\n

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

\n
\n

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

\n
\n

zeroRuntime 下的能力边界（能做 / 不能做）

\n

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

\n

✅ 可以做的事情

\n\n

❌ 不能做的事情

\n\n

一句话总结：

\n
\n

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

\n
\n

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

\n

cssVar.key 必须完全一致

\n

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

\n
cssVar: {\n  key: \"aishort\";\n}
\n

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

\n

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

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

如果不一致：

\n\n

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

\n
\n

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

\n
\n\n

多主题：理论可行，工程上不值得

\n

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

\n

结论非常明确：

\n
\n

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

\n
\n

主要问题包括：

\n\n

最终结论是：

\n
\n

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

\n
\n

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

\n

ConfigProvider 的现实限制

\n

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

\n

但在 zeroRuntime 模式下：

\n\n

这意味着：

\n\n

本质上，这是一次明确的取舍：

\n
\n

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

\n
\n

总结

\n

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

\n

它确实解决了：

\n\n

但代价同样明确：

\n\n

如果你的项目：

\n\n

那么 zeroRuntime 是值得使用的方案。

\n

但如果你需要：

\n\n

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

\n", "image": "https://img.newzone.top/2026-01-24-23-42-54.png?imageMogr2/format/webp", "date_published": "2025-12-31T00:00:00.000Z", "date_modified": "2026-01-24T15:45:15.000Z", "authors": [], "tags": [ "建站开发" ] } ] }