TLDR:

• 新增 Kimi / 豆包 / GLM-4.7 / 摩尔线程 GPU 脚手架，一行命令即用。
• Claude Code 全面增强：署名一键管理 + 支持接入国产 GPU + 实验级 best practice 模板。
• gg 模块 独立并提速：Gemini + Google 搜索并发优化，10 秒内可用。
• x gram 进入“防失控模式”：新增网络级熔断，stop 3/4/5 提供更激进的清理策略。

🚀 X-CMD v0.8.0 Beta 更新详情

kimi

新增 kimi 模块 —— 因为我花 7 块钱买了个 7 天试用账号。

既然要用，干脆把它整顺手点。我写了个脚手架，让它能在不同服务器和工作站快速部署。
不用你手动装依赖、配环境，一条命令就能跑起来。

试用到期了？卸载也一键搞定，不拖泥带水。

示例：

# 启动 Kimi Code，没装过的话会自动用 uv 帮你装好
x kimi

# 升级 kimi-cli 到最新版本
x kimi --upgrade

claude

新增 attribution|attr 子命令 —— 说实话，做这个功能是因为我自己有点烦。

你知道的，我最近开始使用 Claude Code，但模型可能用的是 DeepSeek。
然后，每次 Claude 的图标都稳稳在第二作者清单里面。
我只是单纯不喜欢这样。

当然，我相信 Claude Code 团队是出于善意的 —— 毕竟明确标注 AI 辅助生成的代码对用户是负责的。
而且他们也提供了关闭的方法（虽然藏得有点深）。

所以我干脆做了个一键工具，三种选择随你：

• 直接删掉，干净利落：x claude attr rm
• 不想完全去掉？可以改成通用的 Co-Authored-By: AI
• 或者你自己定义，爱写啥写啥

示例：

# 开门见山，我不喜欢每次 commit 都带署名，直接移除
x claude attr rm

# 或者改成自己想要的
x claude attr use --msg "Co-Authored-By: deepseek <noreply@x-cmd.com>"

新增 mt 子命令 —— 摩尔线程也发开发者礼包了，30 天 lite 套餐免费试用，接的是 GLM 4.7。

我自己还没抢到资格，但先把脚手架搭好了。
等你们薅到羊毛，一条命令就能让 Claude Code 接上国产 GPU。

更多玩家入场，意味着更多选择。x-cmd 会持续跟踪这些福利（顺便继续薅）。

示例：

# Claude Code + 摩尔线程，一键启动
x claude mt

新增 create 子命令 —— 我们在整合各种 Claude Code 的 best practice。

说实话，我们团队也是 vibe coding 新手，还在摸索什么做法真的好用。
现在放出来的是实验版，给我们点时间慢慢迭代。

如果你愿意当小白鼠，欢迎试用，但别期待太高。

doubao

新增 doubao 模块 —— 说实话，我自己还没开始用。

但有用户提到了，我就先把脚手架搭好。
反正等你要用的时候，一条命令就能接入火山方舟的豆包模型。

示例：

# 交互式初始化
x doubao init

# 直接调用豆包模型
@doubao "Give me an example of recursion in Python"

gg

新增 gg 模块 —— 从 x gemini gg 里独立出来了，因为我用着真香。

免费的 Google 搜索 + Gemini，质量还高。但有个坑：Google 的引用结果都包了一层网页，以前得一一去请求，慢得要死。
晚上花了点时间给它做了并发，现在能控制在 10 秒内。

考虑到 Gemini 免费额度挺慷慨，质量也不错，再加上 AI 本来就要等会儿，我觉得这体验可以接受。

下一步会试着把它做成 skill，集成到各种 agent 里。如果你有更骚的玩法，欢迎分享。

示例：

# 让 Gemini 帮你 Google
x gg "关于 x-cmd?"

gram

为 x gram stop 2 新增了「网络熔断」能力 —— 说实话，我有点慌。

说不定不受限的智能体已经开始潜伏和攻击了。clawdbot 和 moltbook 现在正闹得凶 —— 这周日我们刚上线了一个应对站。
我们紧急上线了一个倡议站：https://bot-killer.x-cmd.com/

上个版本我们做了「按名字杀进程」和「memory 文件存档」。
这个版本，x gram 开始装备真家伙：一键熔断所有 HTTP/HTTPS 连接进程，直接按连接掐断进程。
防止恶意智能体通过网络"摇人"，或者偷偷上传你的本地隐私。

同时新增了 stop 3/4/5 策略：

• stop 3 —— 在 stop 2 基础上，打包并删除 $HOME 目录下所有包含 soul.md 和 memory.md 的文件夹
• stop 4 —— 在 stop 3 基础上，额外杀掉所有正在使用这些 memory 文件夹的进程，实现「按名字杀」和「按文件杀」双重保障
• stop 5 —— 在 stop 4 基础上，将搜索范围扩大到整个 / 目录（系统目录中只删 *.md 文件）

下一步？我打算用 AI 来帮助用户识别这些威胁。

zhipu

新增 glm-4.7 与 glm-4.6 模型支持 —— 同上，我自己还没来得及细用。

但用户说需要，我就先加上。你想用哪个版本，直接 --model 指定就行。

示例：

@glm --model glm-4.7 "作为一名营销专家，请为我的产品创作一个吸引人的口号"

chat

修复了 x-cmd agent 的 JSON Unicode 兼容性问题 —— 测 Zhipu API 时踩的坑。

某些 Unicode 字符会让请求 JSON 直接报错，现已修复。

zuz

修复 zuz 模块稳定性问题。

其实这个问题我们早知道 —— 有人 alias 了 pwd，而 zuz 用的还是老的 pwd 命令。
zuz 代码一直很稳定，这么多年没动过。这次趁 @polymerase60053 提了 issue，我们用更好的方法重写了这部分逻辑。

感谢 @polymerase60053 的提醒！https://github.com/x-cmd/x-cmd/issues/370#issuecomment-3838483987

⬆️ 如何升级

现有用户可以通过以下命令快速切换至 Beta 版本进行体验：

x upgrade beta

如果你没有安装 x-cmd, 只需要打开你的终端:

eval "$(curl https://get.x-cmd.com)"

x-cmd 是一个一站式的命令行工具集，其强大的功能可以为人类用户和AI共同使用。它还简化了很多工具的安装方法。
如果你仍不知道如何安装，请参考 https://x-cmd.com/start

🤝 开发者反馈

如果您在自定义配置或代理设置中遇到任何疑问，欢迎前往 GitHub Issues 提交反馈，共同完善 X-CMD 生态。

互联网上一笔域名交易引发热议：象征“人工智能”（Artificial Intelligence）的三个字符域名 AI.com，以 约 7000 万美元（约合 4.8 亿元人民币） 的价格完成转让，这一数字刷新了目前已公开披露的互联网域名交易价格纪录。

这笔交易不仅价格惊人，还折射出一个时代级的技术方向：AI 已经不再只是技术名词，而是真正的商业入口。

🧠 为什么这次交易如此引人关注？

简单来说，这已经不是普通的“换个网址”那么简单：

1. AI.com 这个域名本身具备极高的词义价值
   “AI” 是全球通用、无语言门槛的科技象征，它有可能成为未来人工智能产品、服务甚至生态的“默认入口”。
2. 和传统域名不同，它代表了行业趋势
   和过去那些高价域名不同（如 Voice.com 等历史高价交易），AI.com 的价值增长并非单纯投机，而是和 AI 技术热潮密切相关。

💼 谁买下了 AI.com？

这次域名的买家是 加密货币交易平台 Crypto.com 的联合创始人兼 CEO Kris Marszalek。他通过加密货币形式支付了这笔资金。

据公开信息显示，这笔交易已经完成，Marszalek 和他的团队准备借助这个域名推出新的业务，并计划在 全球瞩目的体育赛事“超级碗”（Super Bowl）广告中 正式揭晓。

📍 AI.com“未来之门”的用途是什么？

目前多个媒体报道透露的信息显示，这个域名将承载一个 面向大众的 AI 智能代理平台：

• 用户可以创建专属的 AI 助手；
• 能够发送消息、调用应用、执行操作（如股票交易）；
• 平台将采取“免费+付费订阅”模式，面向普通用户和高级功能用户同时开放。

换句话说，这不只是一个“技术展示”，它要成为普通人实际可以使用的 AI 服务入口。

🏆 这笔交易为何具有里程碑意义？

AI.com 的成交直接推高了顶级域名的价值认知：

• 它是目前公开报道里最昂贵的互联网域名交易之一；
• 价格超过过去多年的交易纪录：比如曾经出价 3000 万美元买下 Voice.com；
• 标志着 AI 相关品牌资产已经成为资本追逐的核心。

域名交易行业内部人士认为，短、通用、高辨识度的域名随着 AI 行业的成熟，其价值将继续上涨。

🔍 这笔成交告诉我们什么？

① AI 已从技术浪潮变成核心商业资产

这个域名价格被市面上买下，说明 AI 已不只存在于学术或开发语境中，而是成为一个具有广泛用户识别度的商业标签。

② 品牌入口成为未来竞争的重要战场

在用户获取成本不断攀升的背景下，直观、易记、无语言壁垒的入口本身就是一种资本。

③ 整个互联网正在向“智能入口时代”迈进

原来的网址时代是“内容+服务”，而这次交易体现了“智能+效率”的商业优先级正在迅速提升。

📌 总结

AI.com 以 7000 万美元成交，不仅刷新域名历史记录，更昭示着一个趋势：

人工智能时代不仅是技术升级，更是互联网资产价值重塑的开始。

它告诉我们：当一个行业进入爆发式增长阶段，围绕这个行业的基础“符号性资产”（比如 AI 的域名、品牌标识等）将成为新的价值高地。

上期我们介绍了如何部署Clawdbot AI的详细操作步骤【本地搭建 Clawdbot + ZeroNews 访问】

本篇文章主要为已部署Clawbot AI的用户，提供了一种便捷、适配国内网络环境的远程管理解决方案——借助 ZeroNews 替代官网推荐的代理工具，实现OpenClaw GateWay Dashboard的远程访问；

同时针对性解决远程访问时可能出现的Gateway Token错误、设备授权错误两大常见问题，明确了远程Dashboard的全部可操作功能。

OpenClaw 是一个专为 AI 应用与智能体部署设计的高性能网关平台，它提供了统一的仪表盘（Gateway Dashboard）用于集中管理模型调用、渠道集成、技能插件、定时任务及节点监控。

基于 OpenClaw 构建的 Clawbot AI 是一款功能强大的 AI 产品，能够无缝接入多种对话模型与即时通信平台（如 WhatsApp、Telegram、Discord 等），并通过可扩展的技能系统实现自动化任务与智能交互。

完成 Clawbot AI 安装后（安装步骤可参考我们上期的文章），您将获得 OpenClaw Gateway Dashboard 的本地访问地址及唯一的 Gateway Token（后续配置需用到）。

通过访问地址可以通过本地访问打开 OpenClaw Gateway Dashboard
默认访问地址：127.0.0.1:18789

该地址仅支持本地网络访问。若需在外部网络环境下管理网关，官方文档提示我们需借助 Tailscale 或 VPN 等代理工具，但这些方式在国内网络环境中往往体验不佳。

ZeroNews 远程映射配置

而通过我们的实测，ZeroNews可以完美的替代官网推荐的代理工具。
1、简单三步就能够实现 OpenClaw Gateway Dashboard 的远程访问。下载安装 ZeroNews Agent创建域名信息配置映射服务
2、提供IP黑白名单和鉴权认证。可以完美的解决暴露出来的 GateWay Dashboard 不受非授权IP访问和授权账号访问，提升服务的安全性。

远程Gateway Dashboard 错误问题处理

但是我们通过远程访问的时候，如果出现如下问题，可以通过下面的方法解决。

01 GateWay Token 错误

1、报错信息：
disconnected (1008): unauthorized: gateway token missing (open a tokenized dashboard URL or paste token in Control Ul settings)

2、报错原因：第一次通过远程连接访问 OpenClaw Gateway Dashboard时，需要配置 GateWay Token，否则会出现错误。

3、解决方案：打开 Control / Overview 页面然后将上面安装时获取到的GateWay Token粘贴进去点击Connect连接

02 设备授权错误

1、报错信息：disconnected (1008): pairing required

2、错误原因：如果您使用一台新的设备去访问 OpenClaw Gateway Dashboard的 URL 时，除了需要配置上面的GateWay Token 之外，还需要对新的设备进行授权，否则会提示错误。

3、解决方法：

a) 首先，我们要打开到配置窗口，并执行设备列表查询命令

b) 这时候，可以看到上面会出现刚才请求连接访问的设备信息。我们需要记住 Request IDc) 接着，我们执行设备授权命令和重启网关命令

d) 执行完成之后，我们回到 GateWay 页面，点击刷新，可以看到 STATUS 为 Connected 状态，表明我们已经可以正常访问了。

注意：

• 一旦批准，设备会被记住，除非你使用命令 openclaw devices revoke --device <id> --role <role> 撤销它，否则不需要重新批准。
• 每个浏览器配置文件生成唯一的设备 ID，因此切换浏览器或清除浏览器数据将需要重新配对。
• 若等待授权的时间过长，Request ID会过期，需要重新点击 Connect 申请授权，并通过设备命令查询获取到新的Request ID进行授权。

e) 通过上述操作后，我们就可以在Chat页面与AI进行沟通了。

远程 Gateway Dashboard 可以做什么

通过远程 Dashboard，您可以全面管理 OpenClaw 网关，包括：

• 对话管理：通过 WebSocket 与模型聊天，支持流式工具调用与实时输出。
• 渠道集成：管理 Telegram、WhatsApp、Discord、Slack 等渠道的状态、扫码登录与配置。
• 实例监控：查看在线实例列表并即时刷新状态。
• 会话控制：列出会话、调整会话的思考模式与详细设置。
• 定时任务：管理 Cron 任务的添加、启用、禁用与执行历史。
• 技能管理：查看技能状态、启用/禁用技能、安装新技能及更新密钥。
• 节点管理：查看节点列表及其能力。
• 执行审批：编辑网关与节点的允许列表，设置执行询问策略。
• 配置编辑：查看或编辑 openclaw.json配置文件，支持表单与 JSON 两种编辑模式。
• 调试与日志：查看系统状态、健康检查、模型快照、事件日志，支持实时日志跟踪与导出。
• 更新操作：执行包更新或 Git 更新，并查看重启报告。

安全注意事项

1、IP 访问控制：
可以通过在映射页面，对此映射配置IP访问控制功能，实现仅允许白名单IP访问，非白名单IP无法访问。

拒绝访问效果图

2、鉴权认证管理：
可以通过在映射页面，对此映射配置鉴权认证，实现需要账号密码才能访问，进一步提升安全能力。

开启鉴权效果图

接下来，我们将继续深入挖掘更多实用、有趣的进阶玩法，敬请期待。

大家好啊，我是甲木。

这段时间不是一直在折腾 OpenClaw 么，

之前发的几篇教程类文章，对于很多小伙伴来说，还是门槛比较高，

正好前两天刚从百度智能云的 Agent 大会回来，还挺有意思的，趁热给大家聊聊（关于大会内容，放后边了~）。

现在，百度智能云也接入了 OpenClaw的极简版本，

并且发了一堆非常有意思的skills和百度官方工具，跟现有的OpenClaw打通也有很多的玩法，

我当时第一反应就是：

这不就是我一直在找的东西吗？

OpenClaw × 百度智能云 × 千帆 Skill ⽣态，一套组合拳下来，贼牛批..

好，先别急，我慢慢说。

今天这篇主要聊几件事：

• 百度千帆上线了几个非常实用的Skills，直接接入OpenClaw
• 百度智能云上搭 OpenClaw，到底有多简单
• 三个我实际跑通的 Skills 玩法，真的能干活那种

那么，我们开始！

先说大会上最让我上头的东西

大会上发了不少东西，但最让我兴奋的，是「百度千帆工具及MCP广场」把百度的生态，直接接入OpenClaw了。

大家玩过 OpenClaw 都知道，这玩意儿的拓展性也在于 Skills，你给它装什么技能，它就能干什么活。

而现在百度智能云把「百度 AI 搜索、百度地图、百度网盘、OCR、语音识别」...这些百度自家的能力，全部以 MCP Server 和Skills的形式开放出来了。

以前你想给 OpenClaw 加个"搜索"能力，得自己找 API、写配置、调半天参数。

现在？去广场里挑一个，接进去，完事儿。

而且开发者还能自己开发 MCP Server 发布上去，免费托管，还能被百度搜索收录，等于白送你一波流量。

说白了，这就是给 Agent 开发者建了一个应用商店。

而我这次重点关注到的，是已经上架的几个跟 OpenClaw 直接能打配合的 Skill：

• 百度搜索：实时信息检索，这是 Agent 的"眼睛"
• 百度百科：知识查询和概念核实，相当于给 Agent 装了本百科全书
• 学术检索：论文搜索和学术信息获取，做研究的朋友懂的
• 智能 PPT 生成：搜完信息直接出汇报材料，一条龙
• AI 绘本生成：把内容变成图文并茂的绘本，做内容创作的太需要了

这几个 Skill 单独用都挺好使，但更有意思的是，它们能组合起来用。

后面我会专门聊几个我自己跑通的组合玩法，先按下不表。

百度智能云上搭 OpenClaw，到底有多简单

已经部署好Openclaw的朋友可以直接跳过本章，看下一节内容，

还没部署好，或者想要再白嫖优惠OpenClaw的可以看看本章。

前两篇文章之后，大家反馈最多的问题

关注我的朋友应该记得，前两天我连着肝了两篇 OpenClaw 的教程：

• 第一篇是阿里云部署的，从买服务器到打通钉钉，全流程手把手
• 第二篇更硬核，从 0 到 1 装官方原版，接了 Kimi K2.5，还搞了 Discord 远程操控

文章发完之后，后台和群里炸了..

大家问得最多的，基本就两类：

一类是："甲木，我照着你教程做，环境配置那步就卡住了，报了一堆错，咋整？"

虽然我已经写得尽量保姆级了，但确实，

对于没怎么碰过命令行的朋友来说，配环境、装依赖、排报错这些东西..还是劝退了不少人。

另一类是："教程里那些软件都是国外的，有没有更适合国内的方案？"

嗯，这个确实是痛点。

OpenClaw 原生适配的工具和渠道基本都是海外生态，国内想用好它，适配成本不低。

正好，

百度智能云这次直接上线了 OpenClaw 极简部署。

它同样直接提供了预装好 OpenClaw 环境的轻量应用服务器镜像。

你在控制台选这个镜像，创建实例，几分钟就能跑起来，啥都不用手动装。

更狠的是，它还搞了个限时免费体验：首月免费，每天限量 500 台，先到先得。

之前阿里云那个 68 块一年大家就已经觉得香了，这次百度直接搞免费...

好家伙，卷起来了属于是。

部署完之后，你还能直接通过千帆平台接入文心、DeepSeek、Qwen 这些模型，不用自己到处去注册账号拿 API Key。

这对于小白来说，友好度直接拉满了。

搭建流程，三步搞定

第一步、买台服务器

打开百度智能云官网（https://cloud.baidu.com/product/BCC/moltbot.html），选轻量应用服务器。

几个关键的配置别选错：

• 镜像：一定选 OpenClaw(Clawdbot) 应用镜像
• 套餐：CPU 2核、内存 4GB 起步
• 地域：按需选

如果有优惠的话，你会看到这个界面，

如果没优惠的话，你就只能按月付费了..

但我给你一个思路，可以新注册一个账号...

然后正常购买，

踩坑提醒：OpenClaw 是 Node.js 应用，比较吃内存。2G 内存裸跑偶尔会 OOM（内存溢出），建议搞一下 Swap 交换空间，不然跑着跑着进程就没了，问我怎么知道的..

第二步、配模型

服务器跑起来之后，进控制台：

等待实例创建完成后进入实例详情页，点击实例管理Tab

1. 放通端口——防火墙那步，点一下「一键开通」就行

这里是直接按使用量计费的，需要注意。如果不想走千帆平台的，我们可以直接用它的服务器，然后自己搭建镜像，就跟那篇文章教大家的一样。

2. 防火墙放通18789端口

访问openclaw官网网站需要通过18789端口访问，点击“一键放行”放行防火墙18789端口。

3. 接大模型——通过千帆平台配，文心、Qwen、DeepSeek 都能选

到这里，三步其实就完事了，但千帆的好处是，选完模型之后还能顺手去 MCP 广场挑几个工具，直接给你的 OpenClaw 装上技能包。

这步体验下来确实比之前丝滑不少。

第三步、选你的操作渠道（可选）

可以直接在消息平台配置选择接入飞书、企业微信、钉钉、QQ，

每一个接入过程都有详细地文档，可以按需使用，然后点击应用

比如，QQ接入，https://cloud.baidu.com/doc/LS/s/xml9eru3h

这里不再赘述，我直接接入了QQ。

第四步、选择skills（可选）

接入了百度搜索、百度百科skills，这里按需选择，直接点击应用。

到这里，基本就配置完成了，你可以选择页面访问，

也可以直接QQ对话。

三个我实际跑通的 Skills 玩法，真的能干活那种

平台工具说了这么多，最终还是得落地。

百度搜索、百度百科、学术检索、智能PPT生成和AI绘本生成，这几个skills的可玩性挺多的。

关于如何在OpenClaw中添加百度的skills，我们可以直接看https://cloud.baidu.com/doc/qianfan/s/Mmlda41a2中的内容。

直接一句话添加，剩下的交给OpenClaw就可以了：

下面分享三个我自己跑通的场景。

不局限于OpenClaw，ClaudeCode、OpenClaude，都可以直接接入这几个skills，直接施展组合技。

玩法一：热点追踪 → 一键出图文材料

用到的 Skills：百度搜索 + 智能 PPT 生成 / AI 绘本生成

这个场景特别适合做内容、做运营的朋友。

我试了一下，直接给 OpenClaw 扔了一句话：

"帮我搜一下今天 AI 领域最重要的三条新闻，然后整理成一份简报 PPT。"

它的执行链路大概是这样的：

1. 先调用百度搜索 Skill，从全网检索实时信息
2. 自动筛选、去重、提取核心内容
3. 把整理好的内容丢给智能 PPT 生成 Skill
4. 直接输出一份带标题、分页、核心要点的 PPT

整个过程我啥也没干，就等着收材料。

如果你不想要 PPT 格式，换成 AI 绘本生成也行——它会把新闻内容变成图文并茂的绘本形式，特别适合发朋友圈或者做社交媒体内容。

以前做一份热点简报，你得先翻一圈新闻网站，然后自己写摘要，再打开 PPT 模板排版..

【插入PPT GIF图片】

现在一句话搞定。

这个场景还能拓展：

• 每天早上定时跑一次，自动生成 AI 行业早报
• 输入某个关键词，自动追踪相关热点并生成周报
• 做竞品监控，一有动态就出分析材料

核心逻辑就是：搜索 Skill 负责"找信息"，PPT/绘本 Skill 负责"出成果"，中间 Agent 负责"串起来"。

玩法二：学术研究 Agent：会查资料、会核实、还会追问

用到的 Skills：学术检索 + 百度百科 + 深度研究 Agent

这个场景偏硬核一些，适合做研究、做咨询、写报告的朋友。

普通的 AI 搜索是这样的：你问一个问题，它给你一个答案，完事了。

但接上学术检索和百度百科这两个 Skill 之后，OpenClaw 干的事就不一样了。

我试着让它研究一个课题：AI Agent 在企业服务领域的落地现状与挑战

它的工作方式是这样的：

1. 先拆解问题——把一个大课题拆成几个子问题

2. 调用学术检索 Skill，去找相关的论文和研究报告

3. 遇到不确定的概念，自动调用百度百科 Skill去核实

4. 整理完一轮之后，它自己又追加了几个问题继续深挖

它更像是一个真的会做研究的助手，不只是搜，还会交叉验证、会追问、会自己判断哪些信息还不够。

百度千帆还有一个深度研究 Agent（deepresearch-conversation），专门做这种多轮拆解的研究场景。接上学术检索和百度百科之后，体验就更接近"企业研究 / 咨询分析"的工作方式了。

如果你平时要写行业分析报告、做市场调研，或者帮老板准备决策材料，

比如刚才的报告，我让它给我补充了一些内容。

这个组合真的建议试试。

玩法三：私董会 × 百度生态：让幕僚带着真数据给你出主意

用到的 Skills：私董会 Skill + 百度搜索 + 百度百科

这个非常有意思，skill搭配组合技。

关注我的老朋友应该知道，之前我做过一个AI 私董会的 Skill，

就是模拟巴菲特、比尔·盖茨、马斯克、乔布斯四位大佬当你的幕僚，通过多轮提问和反馈，帮你深入分析问题、给出可执行的建议。

这个 Skill 之前在社区里反响很不错，很多朋友拿它来做创业决策、职业规划、项目复盘。

但它一直有两个让我觉得不够完美的地方：

第一，幕僚的"人设"全靠模型自己编。

比如巴菲特这个角色，模型知道他是投资大师，但它掌握的信息可能是训练数据里的老内容。关于他最新的持仓变动、最近的股东信里说了什么、今年的投资逻辑有什么变化，模型是不知道的。

第二，幕僚们给建议的时候，全凭"脑补"。

聊投资策略的时候，巴菲特会引用一些经典理论和案例，但这些都是模型"记忆"里的东西。你问一个特别新、特别细的市场问题，他可能就只能泛泛而谈了。

现在有了百度搜索和百度百科的 Skill 之后，这两个问题同时被解决了

幕僚们不仅能"上网查资料"，连自己的背景信息都能实时更新。

什么意思呢？直接看流程图：

这些真实信息直接注入到幕僚的人设里，他们的提问和建议就不再是"通用模板"，而是带着当下真实语境的。

然后在实际咨询环节，幕僚还能随时调用搜索去查数据来支撑自己的观点。

我试了一下，把私董会 Skill 和百度搜索、百度百科接到同一个 OpenClaw 里。然后抛了一个问题：“我想做一个面向中小企业的 AI 培训课程，但不确定市场定位和定价策略。”

效果还不错：

• 巴菲特在分析定价的时候，直接调了百度搜索去查了当前市场上同类课程的价格区间，然后基于真实数据给了定价建议

• 比尔·盖茨聊行业趋势的时候，从百度百科拉了最新的企业培训市场规模数据

• 马斯克聊差异化竞争的时候，搜了几个海内外的竞品案例来佐证他的观点

一句话总结：以前的私董会是"凭经验聊"，现在是"带着数据聊"。

四位幕僚的建议变得更具体、更有针对性。

聊聊生态

前两天刚从百度智能云的 Agent 大会回来，

事情是这样的，百度的朋友邀请去参加这次大会，

我去了之后发现，还有@袋鼠帝@梦飞@宇明，大型好友面基现场，

还给整了个百度千帆开发者大使的身份..

当然，身份不重要，重要的是我在现场发现了一些好玩的东西（如上）。

前面三个Case其实也展示了一个更大的可能性——

不同 Skills 之间的融合，才是 OpenClaw 真正的威力所在。

单个 Skill 是工具，多个 Skill 组合起来就是一套完整的工作流。

而百度千帆 MCP 广场提供了大量现成的"积木块"，你只需要想清楚怎么搭就行。

毕竟百度做搜索做了二十多年了，AI 搜索这块的积累确实是最厚的。

而针对 Agent 的使用方式做了适配。比如学术检索 Skill 返回的结构就很适合 Agent 做后续处理。

从选镜像到配模型到进 Web 端用，整个过程对小白太友好了。特别是部署阶段直接选 Skill 这个设计，把"跑起来"和"能干活"合成了一步，省了很多折腾。

当然，每个云平台都有自己的优势，大家根据自己的需求选就行。

不管云平台怎么选，我觉得这几个skills，都可以给你的🦞助手配置上，非常丝滑。

结语

关于OpenClaw，其实已经写了好几篇的内容了，

今天给大家分享的百度智能云的生态，其实也给OpenClaw提供了工具，

折腾这么多，其实就是为了让更多人能用上 OpenClaw，让它能真的解决你生活中的一些场景。

千帆这些 Skill 生态的组合玩法，才是我觉得真正有想象空间的地方。

后续等我把更多 Skill 组合跑通了，再给大家出详细的教程和玩法拆解。

马上春节了，

这周的精彩其实才刚刚开始，

国内 AI 在这周会发力的~ 期待一波！

以上。

我是甲木，热衷于分享一些AI干货内容，同时也会分享AI在各行业的落地应用，我们下期再见👋🏻

本文由mdnice多平台发布

一、什么是跨域？

同源策略（Same-Origin Policy）

浏览器的同源策略是 Web 安全的基石。它规定：只有当两个 URL 的 协议（Protocol）、域名（Host）、端口（Port） 三者完全一致时，才被视为"同源"。

以 https://app.rho.im 为基准：

同源策略限制了什么？

• XMLHttpRequest / Fetch 请求：不能读取跨域响应（最常见的场景）
• DOM 访问：不能通过 JS 访问跨域 iframe 的 DOM
• Cookie / LocalStorage / IndexedDB：不能读取其他源的存储数据

注意：同源策略不阻止请求发出，而是阻止浏览器读取响应。服务器实际上收到了请求并返回了响应，只是浏览器拒绝将响应交给 JS 代码。这个细微区别非常重要。

二、为什么需要同源策略？——安全性分析

场景 1：防止敏感数据窃取

假设没有同源策略：

1. 你登录了 bank.com，浏览器存有会话 Cookie
2. 你访问了恶意网站 evil.com
3. evil.com 的 JS 向 bank.com/api/account 发请求（浏览器会自动带上 Cookie）
4. 如果没有同源策略，evil.com 就能读取你的银行账户信息

这就是经典的 CSRF（跨站请求伪造） 攻击的基础。同源策略确保 evil.com 无法读取 bank.com 的响应。

场景 2：防止 DOM 篡改

如果允许跨域 DOM 访问：

恶意网站嵌入 <iframe src="bank.com/login">
→ JS 读取 iframe 中用户输入的密码
→ 密码被发送到攻击者服务器

核心安全原则

同源策略本质上实现了一个沙箱隔离机制：每个源（origin）都在自己的沙箱里运行，无法访问其他沙箱的数据。这是最小权限原则在浏览器中的体现。

三、常见跨域场景

1. 前后端分离架构

最常见的场景。前端部署在 app.rho.im，API 服务在 api.rho.im：

前端 https://app.rho.im  →  fetch("https://api.rho.im/users")  → 跨域！

2. 单点登录（SSO）

企业常见需求——用户登录一次即可访问多个子系统：

认证中心: https://sso.rho.im
应用 A:   https://app1.rho.im
应用 B:   https://app2.rho.social

SSO 涉及的跨域问题包括：

• Cookie 共享：sso.rho.im 设置的 Cookie，app1.rho.im 能否读取？

  • 同一父域（.rho.im）下可以通过设置 domain=.rho.im 共享
  • 不同域（.rho.im vs .rho.social）之间无法直接共享 Cookie
• Token 传递：认证中心如何将登录状态安全地传递给各应用？
• 跨域重定向：OAuth 流程中的 302 重定向跨越多个域

3. 第三方服务集成

你的网站 https://app.rho.im
  → 调用地图 API: https://api.mapbox.com
  → 嵌入支付页面: https://pay.stripe.com
  → 加载字体: https://fonts.googleapis.com

4. 微前端架构

不同团队的微应用部署在不同子域，需要在主应用中集成：

主应用:     https://portal.rho.im
微应用 A:   https://team-a.rho.im
微应用 B:   https://team-b.rho.social

四、跨域解决方案

方案 1：CORS（跨域资源共享）— 最标准的方案

服务器通过 HTTP 响应头声明"允许哪些源访问我的资源"：

Access-Control-Allow-Origin: https://app.rho.im
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true

简单请求 vs 预检请求（Preflight）：

• 简单请求：GET/POST + 常规 Header → 直接发送，浏览器检查响应头
• 预检请求：PUT/DELETE 或自定义 Header → 浏览器先发 OPTIONS 请求询问服务器是否允许，通过后才发送实际请求

浏览器                          服务器
  |-- OPTIONS /api/data -------->|   ← 预检请求
  |<-- 200 + CORS Headers ------|   ← 服务器回复"允许"
  |-- PUT /api/data ------------>|   ← 实际请求
  |<-- 200 + Data ---------------|

方案 2：反向代理 — 最常用的生产方案

通过 Nginx 等反向代理，让前端和 API 看起来在同一个源：

server {
    server_name app.rho.im;
    
    # 前端静态资源
    location / {
        root /var/www/frontend;
    }
    
    # API 请求代理到后端服务
    location /api/ {
        proxy_pass http://backend-server:3000/;
    }
}

这样前端访问 https://app.rho.im/api/users 实际被代理到后端，浏览器看到的始终是同源请求。

方案 3：JSONP — 历史遗留方案

利用 <script> 标签不受同源策略限制的特点。仅支持 GET，已基本被 CORS 取代，了解即可。

方案 4：postMessage — 跨窗口通信

用于 iframe、window.open 等场景的安全跨域通信：

// 父窗口 (https://app.rho.im) 向 iframe 发消息
iframe.contentWindow.postMessage({ type: 'login', token: 'xxx' }, 'https://sso.rho.social');

// iframe (https://sso.rho.social) 接收消息
window.addEventListener('message', (event) => {
    if (event.origin !== 'https://app.rho.im') return; // 验证来源！
    console.log(event.data);
});

方案 5：Cookie 跨域策略

五、SSO 单点登录的跨域实现

方案 A：共享 Cookie（同父域）

适用于 *.rho.im 下的多个子域：

1. 用户访问 app1.rho.im → 未登录 → 重定向到 sso.rho.im/login
2. 用户在 sso.rho.im 登录成功
3. sso.rho.im 设置 Cookie: Set-Cookie: token=xxx; Domain=.rho.im; Path=/
4. 用户回到 app1.rho.im → 浏览器自动带上 Cookie → 已登录
5. 用户访问 app2.rho.im → Cookie 同样可用 → 自动登录

方案 B：CAS / OAuth 重定向（跨域）

适用于 rho.im 与 rho.social 之间：

1. 用户访问 app.rho.social → 未登录
2. 重定向到 sso.rho.im/authorize?redirect_uri=https://app.rho.social/callback
3. 用户在 sso.rho.im 登录（或已登录）
4. sso.rho.im 重定向回 app.rho.social/callback?code=AUTHORIZATION_CODE
5. app.rho.social 后端用 code 换 token（后端到后端，不受同源策略限制）
6. app.rho.social 设置自己域的 Cookie 或返回 JWT

方案 C：前端 Token + postMessage

1. 主应用打开隐藏 iframe 指向 sso.rho.im/check-session
2. sso.rho.im 检查自己的 Cookie → 如已登录，通过 postMessage 回传 token
3. 主应用收到 token → 存入内存 → 完成登录

六、教学演示建议

准备工作

使用你的域名搭建如下环境：

https://app.rho.im       → 前端应用（端口 8080）
https://api.rho.im       → 后端 API（端口 3000）
https://sso.rho.social   → SSO 认证中心

或者本地演示：

http://localhost:8080     → 前端
http://localhost:3000     → API（跨端口 = 跨域）

演示步骤

1. 先让学员看到错误：前端直接请求跨域 API，打开 DevTools 观察报错
2. 分析请求：在 Network 面板观察 OPTIONS 预检请求
3. 逐步修复：添加 CORS 响应头，观察请求成功
4. 对比方案：切换到反向代理方案，展示无需 CORS 也能工作
5. 高级场景：演示带 Cookie 的跨域请求（credentials: 'include'）

配套的交互式演示代码

https://gist.github.com/vistart/1ad7113fcabe411a545536795374d7d6

在互联网安全越来越受到关注的今天，WebRTC 泄露已经成为很多人忽略但又非常危险的隐私问题。

即便你使用了 IP工具 或代理服务器，如果浏览器的 WebRTC 功能不加以控制，你的真实 IP 仍可能被网站探测到。这就意味着所谓的“匿名浏览”可能形同虚设。本文将手把手教你如何防止 WebRTC 泄露。

什么是 WebRTC 泄露？

首先我们得了解，WebRTC（Web Real-Time Communication） 是一种允许浏览器直接进行音视频通话和数据传输的技术。它本身非常方便，但也有隐私隐患：

当你打开支持 WebRTC 的浏览器访问网页时，某些 JavaScript 脚本可以绕过 IP工具 或代理，直接获取你的本地和公网 IP。

这就叫做 WebRTC 泄露，也有人称之为 “IP 泄露”。

泄露的 IP 可以让广告商、网站甚至黑客追踪你的真实位置。

所以，想要安全上网，控制 WebRTC 泄露非常重要。

如何检测自己的 IP 是否被泄露？

在采取防护措施之前，最好先确认自己的 IP 是否真的存在泄露风险。常用方法有：

IP泄露检测网站
打开一些知名的 IP 泄露检测网站，可以快速判断你是否通过 IP工具 暴露了真实 IP。例如，你可以访问一些综合测试页面，看看显示的 IP 是否是你 IP工具 的 IP，还是你真实的公网 IP。

WebRTC 泄露检测工具
有专门的 WebRTC 泄露检测工具网站，可以模拟 WebRTC 请求，判断浏览器是否会暴露本地 IP。

浏览器指纹检测
值得一提的是，浏览器指纹检测 也可能揭示你的一些信息，包括浏览器版本、操作系统、屏幕分辨率等。如果配合 IP 泄露，你的匿名性就更低了。推荐使用 ToDetect指纹查询工具 来检测浏览器指纹安全情况。

通过以上方法，你可以明确自己的隐私风险点，然后针对性防护。

禁止 WebRTC 泄露的实用方法

接下来，重点来了——如何在日常使用中阻止 WebRTC 泄露。这里分浏览器和插件两类方法：

1. 浏览器内置设置

不同浏览器对 WebRTC 的控制方式不同：

Firefox
打开 about:config，搜索 media.peerconnection.enabled，将其值改为 false。这样就可以彻底禁止 WebRTC 连接。

Chrome/Edge
默认 Chrome 没有直接开关，需要借助扩展程序来控制 WebRTC。可以通过 chrome://flags/ 查看实验性功能，但最稳妥的方法还是用插件。

Safari
在 Safari 的设置里，找到“WebRTC 功能”，勾选“阻止所有 WebRTC 公网 IP 地址”，即可防止 IP 泄露。

2. 使用浏览器插件

对于 Chrome、Edge、Firefox 等主流浏览器，使用插件是最方便的方式：

WebRTC Leak Prevent
可以直接阻止 WebRTC 访问本地和公网 IP，同时提供 IP工具 兼容模式。

uBlock Origin
虽然主要用于广告拦截，但高级设置里可以控制 WebRTC 请求。

ScriptSafe / NoScript
可以通过屏蔽不信任的 JavaScript，间接防止 WebRTC 泄露。

这些插件在安装后几乎可以做到“开箱即用”，降低被追踪的风险。

其他提升隐私安全的技巧

除了禁止 WebRTC 泄露，还有一些小技巧可以提升浏览器的隐私保护能力：

定期检测 IP 泄露
每隔一段时间使用 IP泄露检测 或 WebRTC 泄露检测 工具，确保 IP工具 没有被绕过。

使用隐身模式或专门的隐私浏览器
像 Tor Browser 或 Brave，都有更强的防止 浏览器指纹检测 和 IP 泄露的功能。

关注浏览器更新和安全补丁
有些漏洞会被利用来绕过 WebRTC 限制，保持浏览器最新是最基本的防护。

结合 ToDetect 指纹查询工具
通过 ToDetect指纹查询工具，你可以看到自己浏览器的指纹信息是否容易被追踪，进一步优化隐私设置。

总结

WebRTC 泄露 可能看起来小问题，但一旦被追踪，你的匿名性和隐私都会受到影响。实用的方法就是：

定期做 IP泄露检测 和 WebRTC 泄露检测。

根据浏览器类型，关闭或限制 WebRTC 功能。

使用可靠的隐私插件，比如 WebRTC Leak Prevent。

检测浏览器指纹，利用 ToDetect指纹查询工具 做进一步优化。

只要按照这些步骤操作，你就能大幅降低 IP泄露 风险，保护自己在网络世界的隐私安全。

做 ArkTS / ArkUI 时，把“运行-看效果”的成本降下来，最省事的方式之一就是用 DevEco 的预览器（Previewer）。它能让你在不装包、不跑真机的情况下，快速验证 UI 结构、布局、样式与适配问题。

组件预览的核心价值不是“看一眼 UI”，而是把预览变成一种工作流：每写一个组件，就配一组稳定可复用的预览场景，后续调样式、做适配、做重构，都能快速回归验证。

1）先搞清：页面预览 vs 组件预览（别混用）

很多同学一开始会把这两种预览混在一起用，导致预览行为“看起来不对”。

• 页面预览：以“页面”为单位，通常在页面组件上加 @Entry，适合看整体页面结构与导航。
• 组件预览：以“自定义组件”为最小单位，靠 @Preview 装饰器触发，更适合做组件库、模块化 UI、局部迭代调试。

你如果正在做组件化（卡片、列表项、通用按钮、弹窗、空状态等），优先用组件预览，效率更高。

2）环境准备清单（预览器能不能跑，先看这几项）

如果预览器打不开、白屏、显示异常，先按这几条排：

1. 显卡/图形能力要满足预览器要求：有些机器 OpenGL 能力不够时，预览器会异常或非常卡。
2. DevEco 的 Previewer 资源要下载完整：SDK、预览器组件没装齐，经常会出现“能编译但无法预览”。
3. 部分组件或能力天然不适合预览：例如 Web、Video、XComponent 等更依赖运行态环境的组件，预览里容易出现空白或异常。

3）@Preview 最小可用写法：先跑通“无参组件”

建议你先用一个不依赖外部参数、状态可控的组件验证预览链路，确保预览器能正常工作：

@Preview
@Component
struct HelloPreview {
  @State message: string = 'default Preview';

  build() {
    Column() {
      Text(this.message).fontSize(40).fontWeight(FontWeight.Bold)
    }
    .width('100%')
    .height('100%')
  }
}

小提醒：别在一个文件里堆太多预览

一个源文件里预览太多，会让维护成本上升，也容易让预览器负担变大。建议一个文件控制在“够用就好”。

4）PreviewParams：把预览“调成你想要的设备/语言/方向”

当你开始做多端适配或国际化时，@Preview({...}) 的参数就特别有用。你可以把预览设备的关键属性固定下来，比如屏幕大小、语言、方向、圆屏等。

常用参数解释（按实际开发最常用的理解方式）：

• title：预览名称，同文件多个预览时用来区分。
• width / height：预览设备分辨率（px），快速模拟不同屏幕尺寸。
• dpi：屏幕密度，用于验证字体/间距在不同密度下的表现。
• locale：语言地区，如 zh_CN、en_US，用于验证国际化布局溢出。
• colorMode：亮暗模式（注意不同设备类型可能有默认限制）。
• deviceType：设备类型，如 Phone/Tablet/TV/Wearable，用于多端渲染差异验证。
• orientation：横竖屏，portrait 或 landscape。
• roundScreen：是否圆屏，用于手表类布局验证。

示例（传参预览）：

@Preview({
  title: 'PreviewParams',
  width: 540,
  height: 1170,
  locale: 'zh_CN',
  orientation: 'portrait'
})
@Component
struct Test {
  @State message: string = 'PreviewParams';

  build() {
    Column() {
      Text(this.message).fontSize(36).fontWeight(FontWeight.Bold)
    }
    .width('100%')
    .height('100%')
  }
}

5）实战建议：把预览做成“3 套固定组合”，效率会高很多

我更建议你别每次临时改参数，而是固定三套预览，当成组件的“标准工位”：

1. Phone 竖屏 + 中文
   主战场：布局、字号、间距先在这里定。
2. Phone 横屏 + 英文
   很容易暴露英文文案溢出、按钮变形、间距不够等问题。
3. 圆屏或小尺寸设备
   专门抓边距、圆角、安全区、内容被裁切的问题。

当你把这三套组合固定下来，后面组件改版基本就是“一眼能看出问题”。

6）“预览不显示/白屏”排查口诀（社区里最常见）

遇到预览器不显示，按这个顺序排，命中率很高：

1. 先确认是不是用了不适合预览的组件
   先临时注释 Web/Video/XComponent 等组件，验证是不是它们导致的空白。
2. 组件是否依赖运行态数据
   例如必须等网络请求、路由参数、注入对象才能渲染。预览模式下经常会卡住或无内容。
   更稳的做法是：用“预览包装组件”把入参写死，让预览组件能独立渲染。
3. 资源加载是否写得太“运行态”
   比如路径、资源引用方式不规范，导致预览场景拿不到资源。
4. SDK / 预览器资源 / 项目配置是否一致
   预览器资源没下载好、SDK 版本不匹配，都会导致预览异常。

把 @Preview 当成“组件单测”，你会越写越快

组件预览最爽的一点是：它能把“改一点 → 看一下 → 再改一点”的循环速度拉到极致。

当你开始把预览当成固定资产（多端、语言、方向、圆屏都覆盖），你写组件会越来越像做“可回归的模块开发”：
改动可控、验证快速、适配心里有底。

前几日在在电梯里听见的谈论：

“你这几年换了三份工作啊？”
“嗯。”
“厉害……也有点飘。”
电梯门一合，扣好“草率”的标签，一整天都刮着风。

与其争辩，不如换个叙述方式。今天不讲数据，讲一个三幕小剧场，把“稳定”与“跳槽”请上台，各自说话。

第一幕｜传统观念的回音墙

父母视角：稳定=安全。“铁饭碗至少不饿肚子。”
邻里视角：稳定=体面。“单位名片比名片上人名重要。”
部分HR视角：稳定=可靠。“履历像一条直线，省心。”

这些声音没有错，只是来自过去的经济逻辑：岗位稀缺、失败成本高、信息不透明。
但现在的职场像一条不断分叉的河。你原地扎营可以，但也许更好的水草在拐弯处。
“稳定”如果只是不变，那更像卡在河床上的一块石头；真正的稳定，是在变化中保持可控。

金句：稳定是结果，不是方式；不变不一定叫稳定，掌控才叫稳定。

第二幕｜跳槽与成长：换工作，别只换门禁卡

跳槽，最怕“换来换去，只换了工牌颜色”。
判断有没有成长，看四件事：

问题强度：新岗位的难题，是否比原来的更大、更复杂、更贴近业务核心？
可迁移资产：你带走了什么“随身武器”（写作、分析、项目推进、谈判、行业认知）？
视角宽度：是否从“执行者”升到“设计者/决策参与者”的视角？
作品与证据：能不能用一页纸/一个仓库/一个案例说服陌生人？

如果这四件事持续上台阶，频率不是原罪；如果只是为了逃避情绪、老板、加班——那叫逃跑，不是跳槽。

金句：好的跳槽，是把履历写进能力；坏的跳槽，是把心情写进简历。

跳槽机-会

技术大厂，前端-后端-测试，全国均有机-会，感兴趣可以试试。待遇和稳定性都还不错~

第三幕｜什么样的跳槽才算“有价值”？

给你一块价值跳槽九宫格（自测用，过半即值得）：

方向：行业在向上？岗位贴近价值链核心？
密度：问题更难？反馈更快？产出更可见？
导师：能跟到真正在干活、愿意带人的上级？
舞台：边界更大（预算/权限/跨部门协作）？
节奏：迭代更短（周/月为单位复盘）？
证据：离职时能留下公开作品或可量化战绩？
现金：不是只涨工资，而是单位时间成长更高？
生活：通勤、作息、健康是否更可持续？
心流：进入“做着做着忘了时间”的那种投入？

能勾中6格以上，才叫“向上的移动”。
别只看薪资条，那是果；先看问题强度与可迁移资产，那是根。

四不跳（写得像贴在显示器上的小贴纸）：

不为发泄而跳（吵完架写辞职信，第二天先删草稿）。
不为名头而跳（Title 高一号，问题却更边角）。
不为“跟风”而跳（朋友涨薪=他的剧本，你得看自己的镜头）。
不为“逃离”而跳（去哪儿都一样累=问题在方法，不在公司）。

行动卡｜下一次跳之前，先做这三件小事

写一封给未来雇主的信（300字）
只回答三问：我解决过什么问题→用过什么方法→带来了什么改变。写不出来，就别急着跳。


做一张“技能-行业”二维表
横轴列出你拥有或在学的3–5项通用技能，纵轴放3个感兴趣行业，把可迁移的交叉点标星。星星越多，越值得跳。


安排一次“影子体验”
找目标岗位的人聊30分钟，围绕一天在做什么、最难的问题、如何被衡量三件事。聊不到，说明信息还不够，先别跳。

给“稳定派”与“跳槽派”的一封并信

稳定派：请把“稳定”从“年头写到年尾”改成“能力结构可复用、现金流有弹性、健康不透支”。那是强者的稳定。
跳槽派：请把“跳”从“情绪出口”改成“能力跃迁”。那是成熟的跳槽。

人和岗位不是孰优孰劣，是匹不匹配。
频繁跳槽的人，并不比稳定工作的人差；真正的差别在于：
有人在原地生长，有人在移动中生长；有人只是换地方，有人换了层级。

当你能把每一次选择，都解释为更清晰的方向、更锋利的能力、更合理的生活——
你的履历，就不再是“跳来跳去”，而是一步一个台阶。

——转载自：狗头大军之江苏分军

1. 库的概览与核心价值

想象一下，你面对着成千上万个杂乱的网页，需要从中提取有价值的信息——就像在一堆没有标注的书籍中寻找特定的章节。如果手动去解析那些层层嵌套、格式混乱的HTML代码，就像在没有索引的情况下翻阅整个图书馆。BeautifulSoup正是为解决这个痛点而生的工具。

BeautifulSoup（全称beautifulsoup4）是一个Python库，它能够将复杂的HTML或XML文档转换成一个结构化的树形对象，让开发者可以通过简洁的API快速定位和提取数据。它在Python生态中的独特价值在于：极强的容错能力和人性化的API设计。即使网页代码不规范（如标签未闭合、嵌套错误），BeautifulSoup也能优雅地处理，这在真实世界的网页解析中尤为重要。

与正则表达式相比，BeautifulSoup不要求你掌握复杂的模式匹配规则；与lxml、Scrapy等重型爬虫框架相比，它学习曲线平缓，代码可读性强。对于中小型数据提取项目、教学演示或快速原型开发，BeautifulSoup是当之无愧的首选。

2. 环境搭建与"Hello, World"

安装说明

BeautifulSoup的安装非常简单，但有一个关键点需要注意：正确的包名是beautifulsoup4，而不是beautifulsoup。同时，建议安装高效的解析器lxml以获得更好的性能。

# 使用pip安装（推荐）
pip install beautifulsoup4
pip install lxml

# 如果使用conda
conda install beautifulsoup4 lxml

安装失败常见原因：

1. 错误使用pip install beautifulsoup（包名错误）
2. 网络问题导致PyPI连接超时
3. Python环境混乱，pip指向错误的Python版本

解决方案：使用国内镜像源加速，如：

pip install beautifulsoup4 lxml -i https://pypi.tuna.tsinghua.edu.cn/simple

Hello, World 示例

下面是一个最小可运行的示例，演示如何解析HTML并提取标题：

from bs4 import BeautifulSoup

# 创建模拟HTML文档
html_doc = """
<html>
<head>
    <title>BeautifulSoup入门示例</title>
</head>
<body>
    <h1 class="heading">欢迎学习BeautifulSoup</h1>
    <p id="intro">这是第一个段落。</p>
    <p>这是第二个段落。</p>
</body>
</html>
"""

# 创建BeautifulSoup对象，指定lxml解析器
soup = BeautifulSoup(html_doc, 'lxml')

# 提取并打印页面标题
print(soup.title.string)

逐行解释

1. from bs4 import BeautifulSoup：从bs4模块导入BeautifulSoup类。bs4是"BeautifulSoup 4"的缩写。
2. html_doc = "..."：定义了一个包含HTML结构的字符串，这是我们要解析的原始数据。

3. soup = BeautifulSoup(html_doc, 'lxml')：

   • 第一个参数是要解析的HTML内容
   • 第二个参数'lxml'指定使用lxml解析器（速度快、容错性强）
   • 返回的soup对象是整个解析树的根节点

4. print(soup.title.string)：

   • soup.title：直接访问title标签，返回第一个<title>元素
   • .string：获取标签内的文本内容

运行结果

BeautifulSoup入门示例

解析器选择建议：

• lxml：速度最快，容错能力强，推荐用于生产环境
• html.parser：Python内置，无需额外安装，但速度一般
• html5lib：最接近浏览器解析方式，容错性最强，但速度最慢

3. 核心概念解析

BeautifulSoup解析HTML后会生成4类核心对象，理解这些概念是熟练使用的基础。

核心对象类型

1. BeautifulSoup对象：整个解析树的根对象，代表完整的HTML/XML文档，是所有操作的入口点。
2. Tag对象：对应HTML中的标签（如<div>、<a>、<p>），可以获取标签名、属性和文本内容。
3. NavigableString对象：标签内的纯文本内容（不包含标签本身）。
4. Comment对象：特殊的NavigableString，对应HTML注释（如<!-- 这是注释 -->）。

概念关系图

graph TD
    A[BeautifulSoup对象<br/>文档根节点] --> B[Tag对象<br/>HTML标签]
    B --> C[NavigableString<br/>标签内文本]
    B --> D[Comment对象<br/>HTML注释]
    A --> E[find/find_all方法<br/>定位Tag]
    A --> F[select方法<br/>CSS选择器]
    B --> G[获取属性<br/>tag.attrs/标签名]
    B --> H[获取文本<br/>tag.string/get_text]

核心概念详解

Tag对象操作：

# 获取标签
title_tag = soup.title  # 获取第一个title标签
print(title_tag.name)   # 输出标签名：'title'

# 获取属性
link_tag = soup.a       # 获取第一个a标签
print(link_tag['href']) # 获取href属性
print(link_tag.attrs)   # 获取所有属性字典

# 获取文本
print(title_tag.string)      # 获取标签内文本（无嵌套时）
print(soup.h1.get_text())     # 获取标签内所有文本（含子标签）

NavigableString操作：

# 获取标签内的纯文本
text = soup.p.string  # 获取第一个p标签的文本内容
print(type(text))     # <class 'bs4.element.NavigableString'>

Comment对象处理：

from bs4 import Comment

html_with_comment = "<b><!-- 这是一个注释 --></b>"
soup_comment = BeautifulSoup(html_with_comment, 'lxml')
comment = soup_comment.b.string

# 判断是否为注释
if isinstance(comment, Comment):
    print("这是注释内容:", comment)

查找方法对比

4. 实战演练：爬取新闻网站标题

让我们通过一个真实项目来巩固所学知识。我们将模拟爬取一个新闻网站的标题、链接和摘要。

需求分析

我们需要从一个新闻网页中提取以下信息：

• 新闻标题
• 新闻链接
• 新闻摘要
• 发布时间

方案设计

使用requests库获取网页内容（模拟），然后用BeautifulSoup解析数据。我们将使用以下功能：

1. find_all()批量查找新闻条目
2. CSS选择器定位嵌套元素
3. get()方法提取属性
4. get_text()提取文本

完整代码实现

from bs4 import BeautifulSoup

# 模拟新闻网页HTML结构
news_html = """
<!DOCTYPE html>
<html>
<head>
    <title>科技新闻网</title>
</head>
<body>
    <div class="news-container">
        <div class="news-item">
            <h2 class="news-title">
                <a href="https://example.com/news/1">AI技术突破新里程碑</a>
            </h2>
            <p class="news-summary">人工智能在图像识别领域取得重大进展，准确率提升至98%。</p>
            <span class="publish-time">2025-01-15</span>
        </div>
        
        <div class="news-item">
            <h2 class="news-title">
                <a href="https://example.com/news/2">量子计算商业化进程加速</a>
            </h2>
            <p class="news-summary">多家科技巨头宣布量子计算云服务正式上线，标志着量子计算进入实用阶段。</p>
            <span class="publish-time">2025-01-14</span>
        </div>
        
        <div class="news-item">
            <h2 class="news-title">
                <a href="https://example.com/news/3">5G网络覆盖率达95%</a>
            </h2>
            <p class="news-summary">最新数据显示，全国5G网络覆盖率已超过95%，为物联网发展奠定基础。</p>
            <span class="publish-time">2025-01-13</span>
        </div>
    </div>
</body>
</html>
"""

# 创建BeautifulSoup对象
soup = BeautifulSoup(news_html, 'lxml')

# 查找所有新闻条目
news_items = soup.find_all('div', class_='news-item')

# 遍历提取每条新闻的信息
print("=" * 60)
print("科技新闻网 - 最新资讯")
print("=" * 60)

for i, item in enumerate(news_items, 1):
    # 提取标题和链接
    title_tag = item.find('a')
    title = title_tag.get_text(strip=True)
    link = title_tag.get('href')
    
    # 提取摘要
    summary_tag = item.find('p', class_='news-summary')
    summary = summary_tag.get_text(strip=True) if summary_tag else "无摘要"
    
    # 提取发布时间
    time_tag = item.find('span', class_='publish-time')
    publish_time = time_tag.get_text(strip=True) if time_tag else "未知时间"
    
    # 输出结果
    print(f"\n新闻 {i}:")
    print(f"标题: {title}")
    print(f"链接: {link}")
    print(f"摘要: {summary}")
    print(f"发布时间: {publish_time}")

print("\n" + "=" * 60)
print(f"共提取 {len(news_items)} 条新闻")
print("=" * 60)

运行说明

将上述代码保存为Python文件并运行，你会看到格式化的新闻列表输出。每个新闻条目都包含标题、链接、摘要和发布时间。

代码亮点：

1. 使用class_='news-item'查找所有新闻容器（注意class_的下划线避免关键字冲突）
2. 使用.get_text(strip=True)去除文本中的多余空格和换行
3. 使用.get('href')安全获取属性，避免属性不存在时报错
4. 使用条件判断处理可能缺失的元素，增强代码健壮性

5. 最佳实践与常见陷阱

常见错误及规避方法

错误1：直接使用class作为参数

# ❌ 错误做法
soup.find_all('div', class='content')  # SyntaxError

# ✅ 正确做法
soup.find_all('div', class_='content')  # 加下划线避免关键字冲突

错误2：属性不存在时直接访问

# ❌ 错误做法
link = soup.a['href']  # 如果a标签没有href属性会报错

# ✅ 正确做法
link = soup.a.get('href')  # 属性不存在返回None，安全
link = soup.a.get('href', '#')  # 可设置默认值

错误3：混淆string和get_text()

html = "<p>Hello <b>World</b></p>"
soup = BeautifulSoup(html, 'lxml')

# ❌ 错误理解
print(soup.p.string)  # 输出None，因为有嵌套标签

# ✅ 正确做法
print(soup.p.get_text())  # 输出：Hello World

错误4：忘记指定解析器

# ❌ 不推荐：依赖默认解析器
soup = BeautifulSoup(html_doc)

# ✅ 推荐：明确指定解析器
soup = BeautifulSoup(html_doc, 'lxml')

最佳实践建议

1. 选择合适的解析器

   • 生产环境使用lxml（速度+容错）
   • 开发测试可用html.parser（无需安装）
   • 特殊场景用html5lib（容错性最强）

2. 使用CSS选择器提高效率

   # 传统方法
   div.find('div', class_='container').find_all('a')
   
   # CSS选择器（更简洁）
   soup.select('.container a')

3. 处理中文编码

   # 读取文件时指定编码
   with open('page.html', 'r', encoding='utf-8') as f:
       soup = BeautifulSoup(f, 'lxml')

4. 异常处理

   try:
       title = soup.title.string
   except AttributeError:
       title = "无标题"

5. 性能优化

   • 使用limit参数限制返回数量：find_all('a', limit=10)
   • 只在必要时调用prettify()（格式化输出耗时）
   • 大文档考虑分块解析

注意事项

1. BeautifulSoup只能解析静态HTML，对于JavaScript动态渲染的内容，需配合Selenium或Playwright
2. 它不负责下载网页，需结合requests、urllib等网络库使用
3. 遵守网站的robots.txt协议，合理设置请求频率，避免给服务器造成压力
4. 注意反爬虫机制，适当添加User-Agent等请求头

6. 进阶指引

高级功能

BeautifulSoup除了基础的数据提取，还提供了强大的修改功能：

# 修改标签内容
soup.title.string = "新标题"

# 添加新标签
new_tag = soup.new_tag('div')
new_tag['class'] = 'new-item'
soup.body.append(new_tag)

# 删除标签
soup.p.decompose()  # 彻底删除标签及其内容
soup.p.extract()    # 从文档中移除并返回该标签

生态扩展

结合其他库构建完整的数据采集系统：

• requests/httpx：发送HTTP请求获取网页
• Selenium/Playwright：处理动态JavaScript渲染
• pandas：将提取的数据保存为CSV/Excel
• sqlite3：将数据存储到数据库

学习路径

1. 初级阶段：掌握基本的标签查找和属性提取
2. 中级阶段：熟练使用CSS选择器和文档树遍历
3. 高级阶段：学习修改文档树、处理复杂嵌套结构
4. 实战应用：结合requests完成完整爬虫项目

推荐资源

• 官方文档：https://beautiful-soup.readthedocs.io/（最权威的参考）
• GitHub仓库：https://github.com/facelessuser/BeautifulSoup4
• 实战项目：尝试爬取豆瓣电影Top250、知乎热榜等网站

BeautifulSoup是Python网页解析领域的"瑞士军刀"，掌握了它，你就拥有了从网页中提取数据的强大能力。无论是数据采集、内容分析，还是自动化测试，它都能成为你得力的助手。保持练习，不断探索，你将发现更多精彩的应用场景！

分区表是 PostgreSQL 的核心特性之一，但有一个问题即便资深用户也常会产生困惑：

在涉及分区时，ALTER TABLE 语句的具体执行逻辑是怎样的？

操作是否会同步至各分区？是否对新建分区生效？ONLY 关键字是否实现预期效果？为何部分命令可在主表执行却无法在分区执行，或反之？

当前 PostgreSQL 官方文档对单个 ALTER TABLE 子命令的说明较为完善，但很少系统性地解释它们在分区表场景下的整体行为。这导致真实行为往往只能通过反复试验才能被发现。

本文基于一次系统性验证，总结了 ALTER TABLE 在分区表上的行为规律，将零散规则归纳为一套统一的分类模型。

问题本质：“不一致”并不等同于“未定义”

在 PostgreSQL 社区中，ALTER TABLE 在分区表上的行为常被描述为“不一致”。实际上，更深层的问题在于：

• 行为规则是存在的；
• 但规则分散在不同的代码路径、报错信息以及历史设计决策中；
• 且未以可预测结果的方式进行文档化说明。

在缺乏清晰认知模型的情况下，即便是简单问题也难以回答：

• 在父分区表上执行操作后，现有分区会发生什么？
• 后续新建的分区是否会继承相关设置？
• ONLY 是否能够阻止传播，还是会被直接忽略？
• 能否为单个分区单独覆盖相关配置？

ALTER TABLE 子命令的验证方法

为厘清上述问题，本次研究针对所有 ALTER TABLE 子命令，在分区表场景下采用统一的问题框架开展测试验证。

四个评估维度

针对每个子命令，均围绕以下四个核心问题展开验证：

1. 传播性（Propagation）
   在父分区表上执行操作后，是否会传播到已有分区？
2. 新分区继承性（Inheritance for new partitions）
   后续新建的分区是否会继承父表的设置？
3. ONLY 的影响（Effect of ONLY）
   ONLY parent_table 是否如文档所述，能够阻止操作传播？
4. 独立性（Independence）
   父表与各个分区是否可以拥有不同的配置值？

通过这四个维度，可以将模糊的“不一致”转化为明确、可验证的行为特征。

范围与版本说明

本分析基于 PostgreSQL 18 的开发版本行为（截至 2026 年初）。所有结论均在 PostgreSQL 18 上验证。部分细节在早期版本中可能存在差异，未来版本也可能随着分区机制的演进而发生变化。

分区表上 ALTER TABLE 的分类模型

基于上述评估维度，ALTER TABLE 的子命令可自然划分为 15 类，每一类对应一种明确的行为模式。

该分类仅作为执行逻辑的参考依据，而非价值判断。

C1 – 仅作用于父表的结构性变更

此类特征如下：

• 仅可在分区表上使用；
• 在分区上执行会失败；
• 不支持 ONLY 关键字。

包含的子命令：

• ADD COLUMN（添加列）
• DROP COLUMN（删除列）
• SET DATA TYPE（修改数据类型）
• DROP EXPRESSION（删除表达式）
• ADD GENERATED AS IDENTITY（添加自增标识列）
• ADD GENERATED（添加生成列）
• SET sequence_option（设置序列参数）
• RESTART（重启序列）
• ALTER CONSTRAINT（修改约束）

此类命令用于定义分区表的整体结构，必须保持全局一致性。

C2 – 可传播且可继承的变更

此类特征如下：

• 从父表传播至所有已有分区；
• 遵循 ONLY 关键字的作用规则；
• 新建分区会继承主表的相关配置；
• 支持为单个分区单独覆盖配置。

包含的子命令：

• SET DEFAULT（设置默认值）
• DROP DEFAULT（删除默认值）
• SET EXPRESSION AS（设置表达式）
• SET STORAGE（设置存储参数）
• DROP CONSTRAINT（删除约束）
• ENABLE/DISABLE TRIGGER（启用 / 禁用触发器）

这是多数场景下对 ALTER TABLE 行为的直观预期。

C3 – 可传播但不支持新分区继承

此类别仅包含一个子命令：

• SET STATISTICS（设置统计信息参数）

执行逻辑与 C2 类基本一致，区别在于操作仅同步至现有分区，对后续新建分区不生效。若默认认为配置可自动继承，该特性易引发使用偏差。

C4 – 父表与分区完全独立

此类特征如下：

• 不传播；
• 不继承；
• 允许父表与分区设置不同值；
• 支持 ONLY 关键字，但无实际执行效果。

包含的子命令：

• SET/RESET (attribute_option = value)（设置 / 重置属性参数）
• ENABLE/DISABLE [REPLICA | ALWAYS] RULE（启用 / 禁用复制 / 永久规则）
• ENABLE/DISABLE ROW LEVEL SECURITY（启用 / 禁用行级安全策略）
• NO FORCE / FORCE ROW LEVEL SECURITY（不强制 / 强制行级安全策略）
• OWNER TO（修改表属主）
• REPLICA IDENTITY（设置复制标识）
• SET SCHEMA（修改所属模式）

在行为上，父表与分区几乎等同于彼此独立的普通表。

C5 – 独立设置，但新分区继承

此类别仅包含一个子命令：

• SET COMPRESSION（设置压缩参数）

执行逻辑与 C4 基本一致，但新建分区会继承父表设置，已有分区不受影响。

C6 – 强制传播类命令

此类别仅包含一个子命令：

• ADD table_constraint（添加表级约束）

执行逻辑与 C2 类基本一致，但不允许使用 ONLY，系统会强制保证所有分区一致。

C7 – 仅适用于叶子分区的命令

此类特征如下：

• 无法在分区表上使用；
• 只能在叶子分区上执行。

包含的子命令：

• ADD table_constraint_with_index（添加带索引的表级约束）
• ALTER CONSTRAINT ... INHERIT / NO INHERIT（修改约束的继承 / 取消继承属性）
• CLUSTER ON（按指定索引聚簇）
• SET WITHOUT CLUSTER（取消聚簇）
• SET LOGGED / UNLOGGED（设置日志记录 / 无日志记录）
• SET (storage_parameter)（设置存储参数）

C8 – 父表作用域，但允许分区覆盖

此类别仅包含一个子命令：

• VALIDATE CONSTRAINT（验证约束）

执行逻辑与 C1 类基本一致，区别在于验证动作定义在父表层级，但各分区的验证状态可以不同。

C9 – 条件继承型

此类别仅包含一个子命令：

• SET ACCESS METHOD（设置访问方法）

执行逻辑与 C2 类基本一致，但新分区是否继承取决于父表是否显式设置；若未设置，则使用 GUC 默认值。

C10 – 不传播，但新分区继承

此类别仅包含一个子命令：

• SET TABLESPACE（设置表空间）

已有分区保持不变，新建分区继承父表设置。接受 ONLY，但无实际效果。

C11 – 在父表上为空操作

此类别仅包含一个子命令：

• RESET (storage_parameter)（重置存储参数）

此类命令在分区表上不会报错，但也不会产生任何实际变化。

C12 – 不支持分区表的命令

包含的子命令：

• INHERIT（继承表）
• NO INHERIT（取消继承表）

在概念上与声明式分区机制不兼容。

C13 – 仅绑定父表元数据

包含的子命令：

• OF type（绑定复合类型）
• NOT OF（取消复合类型绑定）

仅作用于分区表本身，在分区上执行会失败。接受 ONLY，但无实际效果。

C14 – 按普通表处理

仅包含一个子命令：

• RENAME（重命名）

无传播、无继承，也不存在分区相关的特殊行为。

C15 – 分区管理类命令

包含的子命令：

• ATTACH PARTITION（挂载分区）
• DETACH PARTITION（卸载分区）

用于操作分区结构本身，而非表属性。

结语

在 PostgreSQL 官方文档未对分区表的 ALTER TABLE 语句执行逻辑进行明确、体系化说明前，本分类模型可作为重要的参考依据。

若日常工作中频繁使用分区表，建议将该认知模型作为常用参考，在生产环境执行相关命令前，先确认其所属的执行类别，再开展操作，以降低不可预期风险。

原文链接：

https://www.highgo.ca/2026/01/21/understanding-alter-table-be...

作者：Chao Li

HOW 2026 议题招募中

2026 年 4 月 27-28 日，由 IvorySQL 社区联合 PGEU（欧洲 PG 社区）、PGAsia（亚洲 PG 社区）共同打造的 HOW 2026（IvorySQL & PostgreSQL 技术峰会） 将再度落地济南。届时，PostgreSQL 联合创始人 Bruce Momjian 等顶级大师将亲临现场。

自开启征集以来，HOW 2026 筹备组已感受到来自全球 PostgreSQL 爱好者的澎湃热情。为了确保大会议题的深度与广度，我们诚邀您在 2026 年 2 月 27 日截止日期前，提交您的技术见解。

投递链接：https://jsj.top/f/uebqBc