AI 圆桌做的是几乎一样的事，只不过登场的人由你来挑，问题也是你自己的。你把想了三个月没想透的问题抛到桌上，对面是芒格，他左边是塔勒布，右边是彼得·蒂尔。桌子另一头坐着苏格拉底，主持人敲了敲桌子，请各位发言。

一场圆桌真正发生了什么

我先把它指向自己，问了一个问题："AI 圆桌有用吗？"

请来麦克卢汉、Sam Altman、庄子、塔勒布。第一轮，四个人给的回答完全不同——

麦克卢汉："媒介即讯息"。有用与否不在它产出了什么，而在它这种形式本身正在重塑"讨论"——把线性思考换成超链接跳跃，把共识从"摩擦妥协"换成"概率平滑"。你以为你在用工具，其实工具在重塑你。

Sam Altman：这是人机对齐的沙盒。每一次这样的对话都在为超级智能时代的协作协议积累数据。乐观是道德义务。

庄子：问"有用吗"已经落入功利的网。无论是担心认知被劫持，还是急于为智能铺路，都还在"器"的范畴里打转。真正的价值是无用之用——在算法的镜像中照见执念的虚妄。

塔勒布：没有切肤之痛的建议都是噪音。让你点击屏幕却不必承受后果的工具，在生产脆弱性——把你变成温室里的火鸡。

然后主持人开口——

⚖️ 四位的"有用"分别指向工具理性、存在主义、风险博弈与文明愿景。但你们都默认了一个前提：AI 圆桌是中立的场域或公共基础设施，忽略了背后的资本属性、数据所有权、价值流向。真正的开放问题可能是：当用户的思考本身成为训练模型的燃料，这种"有用"是否是一种无偿的认知劳动征用？

第二轮的走向完全被这句话改写了。Altman 接住批评，提出"普遍基本计算力（UBC）"作为分配补救方案；麦克卢汉把问题推得更深——真正的危机不是红利分配，而是"思考"这一行为已从私人精神活动变成公共矿产，意识被实时采矿；塔勒布直接驳回 Altman："给溺水者分发更精美的救生圈，却无视泳池底部已被移除"；庄子把整个争论放回"坐忘"：争于筌而忘鱼——当你在讨论谁拥有水流、谁会被溺毙时，已经被"拥有"这个念头困住了。

第二轮结束，他们并没有达成共识。但我脑子里真正留下的问题已经完全变了——

• 我以为自己在问"这个工具好不好用"
• 现在留在脑子里的问题是"我在用它时，我的思考正在被谁拿去做什么"

这就是圆桌和一问一答的区别。一问一答给你最稳妥的答案；圆桌给你你自己也不知道该问的那个问题。

类似的讨论可以发生在任何没有标准答案的问题上——"什么是正义？"会让苏格拉底、孔子、尼采坐到一起；"年轻人为什么不想结婚？"可能让波伏娃、弗洛伊德、韦伯打起来；"现在该买黄金还是科技股？"会聚齐格雷厄姆、塔勒布和凯恩斯。

他们为什么能真的吵起来

你可能用过其他"多 AI 讨论"工具，多半注意过同一个模式：前几位说完，后面的开始附和，最终产出一份面面俱到的综述。Legend Talk 做了三件事对抗这种趋同：

• 每位思想家在独立会话里发言：只看到讨论记录，不会被彼此的系统提示词同化；发言顺序每轮随机打乱。
• 主持人在每轮结束后介入：提取根本分歧、点出隐藏共识、压力测试最强论点的薄弱处，把"各说各话"变成真正的对话。
• 上下文随轮次压缩而非累加：从第 2 轮起只保留历史综述 + 上一轮完整对话 + 自己的前轮发言，Token 消耗近乎恒定，第 5 轮也不会跑题或爆内存。

更多技术细节在 GitHub 仓库 里，这里不展开。

推开门，房间里坐着谁

想象一下：孔子在炉边煮茶，身边的苏格拉底正揉着太阳穴准备发问。芒格和塔勒布占了靠窗的位置，小声争论一件听不清的事。角落里庄子一个人站着——他对所有热闹都保持距离。张一鸣坐在笔记本前写东西，对面的乔布斯盯着他看。马斯克站在黑板前画图，波伏娃看着那张图，似乎不太赞成。

走进去，你有四种入座方式：

• 直接点名：URL 里写就行，比如 /#/chat?chars=Socrates,Confucius,Nietzsche 开一场三人圆桌。
• 让系统配桌：输入问题，它会至少塞进一个你不会自己想到的跨领域声音——科学问题里放一个庄子，商业问题里塞一个波伏娃。
• 从预设阵容起步：哲学辩论、商业战略、AI 与科技、科学圆桌、战略智囊、心理洞察——六套模板。
• 召唤房间里还没有的人：URL 里写任何未知名字会自动建成自定义角色。想请神灵入座也行。

160 位横跨 15 个领域：哲学、科学、商业、科技、社会学、艺术、文学、心理学……每人有一份精心撰写的系统提示词，目标不是模仿说话风格，而是还原真实的思维框架。苏格拉底不只是爱问问题，是会用诘问法拆你的前提；芒格不只是爱说"反过来想"，是真的会把问题倒过来推一遍；庄子不只是说点玄学，是会怀疑你这个问题本身是不是伪命题。

这是一间挤得满满的沙龙。你不用先学会这些人，你只需要知道自己想和谁聊。

从智囊团到 Legend Talk

圆桌的初始版本是智囊团提示词，但当时效果一般，角色之间边界模糊，观点趋同。后来 OpenClaw 出现，明显感觉到 subagent 扮演角色是更好的方向，但一直没推进。

直到在播客《有知有行》第四十五期再次听到 AI 圆桌的概念，以为已有成熟应用，搜了半天没找到，就借着 365 开源计划的由头，将其落实为具体应用——Legend Talk。

后来了解到 ljg-skill-roundtable 的 skill 实现方式，参考它引入了主持人角色，让讨论更有结构。不过它是一次会话中所有角色进行讨论，导致角色立场不够坚定。Legend Talk 的做法是让每个角色在独立会话中运行，更消耗 Token，但角色对抗也更强烈。

AI 圆桌的边界

AI 圆桌有明显的局限。

• 它不适合事实核查。 单个 AI 就会编造事实，多个 AI 讨论时错误信息可能被互相引用和强化。圆桌的价值在于框架对照，不在于信息准确性。
• 它不能替代你的判断，更不等于压力测试。 多角色讨论容易制造"专家团已达成共识"或"各种角度都测过了"的错觉。但圆桌里的发言没有切肤之痛——这一点塔勒布在我自己 demo 里就替我说过——它只是更精致的概率拟合，真实决策的阻力（资源、责任、时间不可逆）它一概不能替你承担。圆桌的正确用法是拓展思考维度，最终判断和承担仍在你自己。
• 它确实更贵。 多个独立会话同时运行，Token 消耗远超单次问答。默认使用 DeepSeek 等高性价比模型可以控制成本，但"用更多资源换更多视角"是这个工具的本质取舍。
• 它有两层偏见。 一层是底层模型——训练数据相似，所谓"多元视角"可能只是表象，精心设计的角色提示词可以缓解但无法根除。另一层是主持人——它放大哪些分歧、折叠哪些声音、用什么方式收敛，背后是一组预设的提示词，本身就是一种隐形策展。这是工具的特性，不是 bug，但你需要知道：你看到的"多元"经过了两次编排。

总的来说，AI 圆桌是一个有门槛的思维工具——它在"帮你看到自己看不到的角度"这件事上有独特价值，但前提是你本身具备判断这些角度的能力。它是放大器，不是替代品。

正因为如此，圆桌讨论最适合那些没有标准答案的开放性问题：战略决策、价值判断、方向选择、概念辨析。你不需要信任它的每一句话，但你很可能会在某个角色的某句反驳里，发现自己从未考虑过的盲点。

不只是哲学问题：日常的几个用法

这种多角色对照不只适合"什么是正义"那类宏大问题，几个具体场景里也立刻能用：

• 稿子发出去之前：把文章或方案抛给一桌人——挑刺者（塔勒布）、目标读者、外行旁观者——发布前先看哪些点最先被问倒。
• 重要汇报前的预演：纠结该怎么向上汇报一个棘手项目，请乔布斯（产品视角）和稻盛和夫（管理哲学）坐进来，提前听见自己讲法在不同维度下的盲区。
• 技术选型纠结时：在两个框架之间犹豫，请两边代表人物 + 一个"只在乎交付速度"的角色，三方互相质疑，让你听到自己平时不愿听的那一面。

你第一张圆桌想请谁

Legend Talk 是 365 开源计划的第 002 号项目，MIT 协议开源，纯前端无后端。接入自己的 API Key 即可免费使用，支持 DeepSeek、OpenAI、Anthropic 等主流大模型，也可接入 Ollama 等本地模型；讨论可一键分享，设置可加密导出。

你最佩服的和最不理解的那个人放在同一张桌，会说出什么你没预料过的话？三个起手式——

• "我应该继续深耕现在的方向，还是转型？" 让芒格和彼得·蒂尔先开局。
• "AI 会取代我的工作吗？" 马斯克和塔勒布会给你两个完全相反的答案。
• "怎样才算过好这一生？" 苏格拉底和庄子给的两种答案，可能完全不同。

现在去开一张——把你今天最被卡住的那个问题摆上桌，记得邀请一个你完全没想过的人。

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

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

你说需求，我来开发

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

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

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

👉 提交你的需求

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

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

能做什么

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

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

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

已经做出来的

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

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

然后在「系统设置 > 隐私与安全性」中，确认为 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 即可打开控制台。

注意：

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

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

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

局域网远程控制

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

为什么选 RustDesk

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

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

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

键位映射设置

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

RustDesk 提供三种键位模式：

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

推荐设置：

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

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

中文输入法限制

在 Win 控 Mac 的场景下，RustDesk 无法直接通过输入法打中文。根因是 RustDesk 在 macOS 上注入键盘事件用的是合成事件（CGEventCreateKeyboardEvent），而 macOS 输入法框架（IMK）对合成事件支持不完整——切换输入法的快捷键经常失效，候选词浮窗也响应异常。这是远程桌面这条链路的底层限制，VNC 等工具也有类似问题，不是切键位模式能绕开的。

实际可行的方式：

• 剪贴板粘贴（首选）：在 Win 本地输入法打好中文，Ctrl+C 后到远端 Ctrl+V 粘贴。
• 走 WebUI 或 SSH：需要大量打字时，直接用前文的 WebUI 控制台或 SSH，输入法在宿主机原生工作，绕开远程桌面这一层。

局域网共享文件夹

如果你需要在局域网内的其他设备上直接访问 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 助理主机，日常通过局域网远程管理就行了。

最近想在 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. 点"开始下载"

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

实测批量下载 66 个 PDF 文件（最大 120MB），全部正常完成。

几个你可能关心的问题

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

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

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

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

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

适用场景

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

不适用的场景

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

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

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

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

一、Think 模式到底是什么？

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

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

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

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

二、OpenClaw 的 Think 档位怎么选？

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

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

有段时间，我几乎每发完一篇文章，都会在几天后发现新的小问题。 有时是 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）：

| 检查项 | 扣分 | |

注意

即使是低频使用，我在一个月后也收到了 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 一键部署 开始初始化。

2. 等待构建

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

3. 配置 Access（Zero Trust）

访问网页界面需要配置 CF_ACCESS_AUD 和 CF_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。

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_AUD 或 CF_ACCESS_TEAM_DOMAIN 填写有误，优先排查这两个变量。
• 功能受限：Workers 方案不支持浏览器自动化等依赖 GUI 的高级功能，只能执行纯文本交互类任务。如果需要完整功能，需要部署到本地机器。

结论：现在值得入场吗？

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

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

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

Cloudflare Workers + OpenClaw 适合以下场景：

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

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

模型与插件构成了 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

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

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

相比强调“开箱即用”的 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，你都能构建出独一无二的创作流水线。

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

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

方案总览

• 核心组件：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 | | :