无尘阁日记

两台 mac 电脑直接互传文本

Thu, 04 Jun 2026 14:49:07 +0800

你这个界面不能直接粘贴文本发送。Finder 里的“隔空投送”主要是用来发现设备、拖文件发送的，不是聊天框。

方法一：把文本变成 txt 文件再发

最稳。

打开 文本编辑
粘贴你的文本
保存成一个文件，比如：

临时文本.txt

回到你这个“隔空投送”窗口
把这个 txt 文件拖到对方 Mac 头像上

或者右键文件：

共享 → 隔空投送 → 选择另一台 Mac

方法二：从某些 App 里直接共享文本

比如你在 Safari、备忘录、文本编辑里选中一段文字：

选中文字 → 右键 → 共享 → 隔空投送

但这个不一定每个 App 都支持，所以不如 txt 文件稳定。

方法三：装 LocalSend，专门传文本

如果你经常两台 Mac 互发文字，建议用 LocalSend。

它可以直接发：

文字
文件
文件夹
图片

不需要登录账号，不走云端，同一个 Wi-Fi 下就行。

你现在最快的做法

直接这样：

文本编辑 → 粘贴内容 → 保存成 txt → 拖到隔空投送里发

一句话：AirDrop 不是微信聊天框，想发文本片段，最好先保存成 txt 文件再投送。

Windows 安装 DeepSeek-TUI 踩坑：不是 PATH 问题，是它改名了

Thu, 04 Jun 2026 14:44:00 +0800

这次踩的坑，表面看是 Windows 找不到命令，实际根因是：DeepSeek-TUI 已经改名为 CodeWhale 了。

我一开始按老教程安装：

npm install -g deepseek-tui --registry=https://registry.npmmirror.com

终端提示安装成功：

changed 1 package

看起来没问题。

但执行：

deepseek

却提示：

deepseek 不是内部或外部命令，也不是可运行的程序

于是第一反应就是：环境变量没配好。

一、第一层误判：以为是 PATH 没加

Windows 下 npm 全局命令一般会安装到这个目录：

C:\Users\Administrator\AppData\Roaming\npm

所以我先把这个路径加进系统环境变量。

PowerShell 临时加 PATH 的写法是：

$env:Path += ";C:\Users\Administrator\AppData\Roaming\npm"

注意，这里不能写成：

set PATH=%PATH%;%APPDATA%\npm

这个是 CMD 写法，不是 PowerShell 写法。

如果你在 PowerShell 里执行 CMD 的写法，就会报类似这样的错误：

无法加载模块 %APPDATA%\npm

所以这里第一个坑是：

PowerShell 用 $env:变量名，CMD 才用 %变量名%。

二、第二层排查：PATH 加好了，还是找不到

后来我专门写了一个脚本，把 npm 全局路径永久加入系统 Path。

脚本执行后显示：

已成功加入系统环境变量 Path:
C:\Users\Administrator\AppData\Roaming\npm

说明环境变量已经加成功了。

但是继续检测：

Get-Command deepseek
Get-Command deepseek-tui
Get-Command codewhale

结果还是：

未找到命令：deepseek
未找到命令：deepseek-tui
未找到命令：codewhale

这时候就可以判断了：

这已经不是 PATH 的问题了。

如果 PATH 有问题，脚本不会显示加入成功。

如果 PATH 已经成功，但命令还是找不到，那就说明 npm 安装的包本身没有生成对应的命令入口。

也就是说：

npm install -g deepseek-tui

虽然执行成功，但它未必还会生成 deepseek 这个命令。

三、真正原因：DeepSeek-TUI 改名成 CodeWhale

真正原因是：DeepSeek-TUI 项目已经改名为 CodeWhale。

以前老教程里写的是：

npm install -g deepseek-tui
deepseek

现在应该改成：

npm install -g codewhale
codewhale

旧的 deepseek-tui 包已经不适合作为新安装方式了。

所以这次的坑，不是 Node 没装好，不是 npm 镜像问题，也不是 Windows 环境变量一定没配好，而是教程过期了。

一句话：

老名字叫 deepseek-tui，新名字叫 codewhale。以后别再用 deepseek 启动，直接用 codewhale。

四、正确解决方式

直接执行：

npm uninstall -g deepseek-tui
npm install -g codewhale --registry=https://registry.npmmirror.com

安装完成后检查：

Get-Command codewhale
Get-Command codewhale-tui

再查看版本：

codewhale --version

最后启动：

codewhale

如果你想看 npm 到底把命令装到哪里，可以执行：

npm config get prefix

正常情况下会返回类似：

C:\Users\Administrator\AppData\Roaming\npm

然后看这个目录里有没有生成命令：

dir "C:\Users\Administrator\AppData\Roaming\npm" | findstr /i "codewhale deepseek"

如果这里能看到 codewhale.cmd，说明命令入口已经生成。

五、Windows 桌面执行脚本的小坑

如果脚本放在桌面，推荐这样进入桌面目录：

cd ([Environment]::GetFolderPath("Desktop"))

这个比手写路径更稳。

因为有些电脑的桌面可能不是：

C:\Users\Administrator\Desktop

而是 OneDrive 或其他目录。

进入桌面后执行：

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\fix-npm-path.ps1

这里的：

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

只是让当前 PowerShell 窗口临时允许执行脚本，不是永久关闭安全策略。

六、最终判断逻辑

遇到这种“安装成功，但命令找不到”的问题，不要一上来就反复重装。

按这个顺序排查：

1. 先看命令是否存在

Get-Command deepseek
Get-Command deepseek-tui
Get-Command codewhale

2. 再看 npm 全局目录

npm config get prefix

3. 再看目录里有没有命令文件

dir "C:\Users\Administrator\AppData\Roaming\npm" | findstr /i "codewhale deepseek"

4. 如果 PATH 没问题，但命令不存在

那就不是环境变量问题，而是包没有生成这个命令。

这次就是这个情况。

七、最终命令合集

最推荐直接用这一套：

npm uninstall -g deepseek-tui
npm install -g codewhale --registry=https://registry.npmmirror.com
Get-Command codewhale
codewhale --version
codewhale

如果仍然找不到，再检查：

npm config get prefix
dir "C:\Users\Administrator\AppData\Roaming\npm" | findstr /i "codewhale deepseek"

八、这次踩坑的核心结论

这次问题不是：

npm 没安装成功

也不完全是：

Windows PATH 没配好

而是：

DeepSeek-TUI 改名为 CodeWhale，旧命令 deepseek 已经过时

所以以后安装不要再按老教程写：

npm install -g deepseek-tui
deepseek

而是直接写：

npm install -g codewhale
codewhale

技术工具更新太快，很多时候最坑人的不是报错本身，而是教程已经过期了。

这次就是典型案例：
命令没错，环境也快配好了，结果项目名字变了。

什么是FDE工程师？

Sun, 31 May 2026 19:50:42 +0800

FDE 工程师是什么？

FDE = Forward Deployed Engineer，直译是：前线部署工程师 / 客户现场工程师。

更通俗地说：

不是坐在办公室只写产品代码的工程师，而是冲到客户真实业务现场，把 AI / 软件系统真正落地跑起来的人。

OpenAI 对 FDE 的描述是：负责和战略客户一起完成复杂的端到端模型部署，覆盖需求发现、技术范围定义、系统设计、构建和生产上线。(OpenAI)

它和普通工程师的区别

普通软件工程师更像是：

我负责把产品功能写好。

FDE 更像是：

我负责让客户的问题真的被解决，必要时我自己写代码、接系统、改流程、做上线、培训团队。

所以 FDE 其实是一个混合岗位：

角色	FDE 身上对应的能力
软件工程师	写代码、做集成、搭系统
解决方案架构师	设计技术方案
顾问	理解客户业务和痛点
项目经理	推动上线交付
产品经理	把客户反馈带回产品团队

为什么 AI 时代突然火了？

因为大模型不是装上就能用。

企业真正落地 AI，会遇到很多现实问题：

比如数据在哪、权限怎么控、怎么接 ERP/CRM/OA、怎么保证安全、怎么评估效果、怎么让业务团队真的用起来。

这时候光卖 API 不够，光讲方案也不够，需要一个既懂技术、又懂业务、还敢下场交付的人。

这就是 FDE。

Reuters 报道也把 FDE 称为当前 AI 领域非常热门的岗位之一，原因是它能把 AI 模型嵌入真实企业系统，解决“从试点到生产”的落地难题。(Reuters)

一句话理解

FDE 工程师 = 企业 AI 落地的“特种兵”。

不是纯程序员。

不是纯售前。

不是纯顾问。

而是：

带着技术武器，进入客户战场，直接把业务问题打穿的人。

适合什么人？

适合这类人：

懂代码，但不想只关在 IDE 里。

能和老板、业务负责人、技术团队都聊得明白。

喜欢解决真实复杂问题。

能接受不确定性、出差、客户现场、快速交付。

对 AI 应用、企业数字化、业务流程优化有兴趣。

对你最有价值的理解

你以后做企业 AI 智能体、AI 操作系统、AI 落地方案，其实最需要培养的就是 FDE 思维：

不只是“我会调模型”，而是“我能把模型接进企业业务流程，并让它产生可衡量的业务结果”。

这也是未来 AI 课程、AI 咨询、AI 交付里非常值钱的一类能力。

macOS 上 v2rayN 的 TUN 模式没生效，怎么排查和修复？

Sat, 30 May 2026 21:08:32 +0800

很多人以为：

只要 v2rayN 节点能连上，TUN 模式就一定生效。

其实不是。

节点能用，只代表代理核心本身通了。

TUN 能用，代表系统流量真的被接管了。

这两个不是一回事。

这次遇到的问题就是典型案例：

手动走 SOCKS5 代理可以访问 Google。

但是浏览器、终端、系统直连还是访问不了。

这说明什么？

说明代理链路本身是好的，但系统流量没有真正走进 TUN。

一、先看现象

诊断结果里有三个关键现象。

第一个：

127.0.0.1:10808 正在监听

说明本机 SOCKS5 代理端口已经起来了。

第二个：

curl --socks5-hostname 127.0.0.1:10808 https://www.google.com

可以返回：

HTTP/2 200

说明节点、代理核心、远程链路都是正常的。

第三个：

curl -I https://www.google.com

直接访问超时。

同时：

127.0.0.1:10809 Connection refused

说明 HTTP 代理端口没有起来。

这几个现象合起来，结论就很清楚：

代理核心没坏。

节点没坏。

真正的问题是：

系统流量没有被 TUN 接管。

二、什么是 TUN 模式？

普通代理模式，一般是这样的：

软件自己设置代理。

浏览器自己设置代理。

终端自己设置代理。

哪个软件设置了，哪个软件才走代理。

而 TUN 模式不一样。

TUN 模式会在系统里创建一个虚拟网卡，然后把系统流量导进这个虚拟网卡，再交给代理核心处理。

简单说：

普通代理是“软件自己走代理”。

TUN 模式是“系统帮所有流量走代理”。

所以 TUN 模式生效后，理论上你不用单独给浏览器、终端、npm、OpenClaw 配代理，它们也应该能自动走代理。

但前提是：

TUN 真的启动成功了。

路由真的被改了。

DNS 真的被接管了。

三、TUN 没生效的典型表现

如果你遇到下面这些情况，基本就可以怀疑 TUN 没生效。

1. SOCKS5 手动访问成功

比如：

curl -I --socks5-hostname 127.0.0.1:10808 https://www.google.com

能成功。

这说明节点本身没问题。

2. 直接访问失败

比如：

curl -I https://www.google.com

失败、超时、无法连接。

这说明系统流量没被接管。

3. 浏览器不设置代理就访问不了

如果浏览器只有在手动设置 SOCKS5 代理后才能访问，关掉代理就不行，也说明 TUN 没真正接管系统流量。

4. 没有新的 utun 网卡

macOS 上 TUN 通常会创建 utun 相关虚拟网卡。

可以用这个命令看：

ifconfig | grep -Ei "utun|sing|tun" -A 8

如果开了 TUN 之后完全看不到相关变化，大概率 TUN 根本没起来。

四、这次问题的根因判断

这次日志里，最关键的是：

SOCKS5 10808 成功
HTTP 10809 refused
直连 Google timeout

这说明：

v2rayN / xray / sing-box 代理核心至少有一部分是正常的。

因为 SOCKS5 已经能访问外网。

但系统流量没有自动走代理。

也就是说：

TUN 模式没有真正生效。

进一步看，还有一个问题：

HTTP 代理端口 10809 没有监听。

所以如果某些软件配置的是：

http://127.0.0.1:10809

也会直接失败。

这类失败不是节点失败，而是本机端口没开。

五、第一步：确认核心类型，优先用 sing-box

macOS 上使用 TUN，建议优先使用 sing-box core。

因为 TUN、路由接管、DNS 劫持这些能力，sing-box 更适合。

在 v2rayN 里检查：

设置
核心类型
切换为 sing-box

切换之后，重新选择节点。

然后重新开启 TUN。

不要一边用 xray，一边指望 TUN 一定能稳定接管所有系统流量。

六、第二步：彻底重启 v2rayN 和代理核心

有时候 TUN 开关点了，但核心没有正确重载。

这时候不要只点界面按钮。

直接把相关进程杀掉：

pkill -f v2rayN
pkill -f sing-box
pkill -f xray

然后重新打开 v2rayN。

重新选择节点。

重新开启 TUN。

如果 macOS 弹出管理员密码授权，一定要允许。

因为 TUN 需要创建虚拟网卡、修改系统路由，这不是普通权限能完成的。

七、第三步：确认 TUN 网卡是否创建成功

开启 TUN 后，执行：

ifconfig | grep -Ei "utun|sing|tun" -A 8

如果看到新的 utun 相关接口，说明 TUN 至少创建了虚拟网卡。

如果完全没有变化，说明 TUN 没创建成功。

这时候重点查：

v2rayN 是否有管理员权限。

sing-box 是否正常启动。

TUN 配置是否开启。

macOS 是否阻止了相关网络权限。

八、第四步：确认系统路由是否被接管

TUN 模式不是创建虚拟网卡就结束了。

还要把流量导过去。

继续执行：

netstat -rn -f inet | head -n 40

如果 TUN 生效，路由表里通常会出现和 utun 有关的路由。

如果没有任何路由变化，说明：

TUN 网卡可能起来了，但系统流量没走进去。

这时候重点查 v2rayN 的 TUN 配置。

九、第五步：检查 TUN 的关键配置

在 v2rayN 的 TUN 设置里，重点看这些选项：

Enable TUN：开启
Stack：mixed / system / gvisor，优先 mixed
Auto Route：开启
Strict Route：开启
Sniff：开启
DNS Hijack：开启

其中最关键的是：

Auto Route
DNS Hijack

Auto Route 负责让系统流量走 TUN。

DNS Hijack 负责把 DNS 查询也接管过来。

如果只开了 TUN，但没开 Auto Route，可能出现：

TUN 网卡存在，但流量没进去。

如果 DNS 没接管，可能出现：

IP 流量走了代理，但域名解析还是污染或失败。

十、第六步：检查 10808 和 10809 端口

执行：

lsof -nP -iTCP:10808 -sTCP:LISTEN || true
lsof -nP -iTCP:10809 -sTCP:LISTEN || true

正常情况下：

10808：SOCKS5 代理
10809：HTTP 代理

但不同客户端配置不一样。

如果只看到 10808，没有 10809，说明 HTTP 代理没有开。

这时候如果某些软件使用的是：

http://127.0.0.1:10809

就会失败。

可以临时改成 SOCKS5：

socks5h://127.0.0.1:10808

十一、第七步：用三条命令判断问题在哪

1. 测试直连

curl -I --connect-timeout 8 https://www.google.com

如果失败，说明当前系统默认链路不通。

2. 测试 SOCKS5

curl -I --socks5-hostname 127.0.0.1:10808 --connect-timeout 8 https://www.google.com

如果成功，说明节点和 SOCKS5 代理正常。

3. 测试 HTTP 代理

curl -I -x http://127.0.0.1:10809 --connect-timeout 8 https://www.google.com

如果失败并提示：

Connection refused

说明 10809 端口没有监听。

这时候不要怀疑节点。

应该去检查 HTTP 入站配置。

十二、完整排查脚本

可以直接复制执行：

echo "=== core process ==="
ps aux | grep -Ei "v2ray|v2rayn|xray|sing-box" | grep -v grep

echo "=== ports ==="
lsof -nP -iTCP:10808 -sTCP:LISTEN || true
lsof -nP -iTCP:10809 -sTCP:LISTEN || true

echo "=== tun interfaces ==="
ifconfig | grep -Ei "utun|sing|tun" -A 8

echo "=== route ==="
netstat -rn -f inet | head -n 40

echo "=== direct test ==="
curl -I --connect-timeout 8 https://www.google.com

echo "=== socks test ==="
curl -I --socks5-hostname 127.0.0.1:10808 --connect-timeout 8 https://www.google.com

echo "=== http proxy test ==="
curl -I -x http://127.0.0.1:10809 --connect-timeout 8 https://www.google.com

判断方法：

SOCKS 成功，直连失败，没有 utun：
TUN 没创建成功。

SOCKS 成功，直连失败，有 utun：
TUN 创建了，但路由或 DNS 没接管。

SOCKS 成功，HTTP 代理失败：
10809 没开，软件不要配置 http://127.0.0.1:10809。

SOCKS 失败：
节点、订阅、核心、远程链路有问题。

直连成功：
系统网络本身可以访问，不一定说明 TUN 生效。

十三、临时解决方案：先用 SOCKS5 接管系统代理

如果 TUN 一时修不好，可以先用系统代理顶上。

先确认网络服务名：

networksetup -listallnetworkservices

一般是：

Wi-Fi

然后执行：

networksetup -setwebproxystate "Wi-Fi" off
networksetup -setsecurewebproxystate "Wi-Fi" off
networksetup -setsocksfirewallproxy "Wi-Fi" 127.0.0.1 10808
networksetup -setsocksfirewallproxystate "Wi-Fi" on

然后测试：

curl -I https://www.google.com

如果能通，说明系统代理已经把流量导到 SOCKS5 了。

这不是 TUN，但可以先解决访问问题。

十四、恢复系统代理

如果后面不想走系统代理了，执行：

networksetup -setsocksfirewallproxystate "Wi-Fi" off
networksetup -setwebproxystate "Wi-Fi" off
networksetup -setsecurewebproxystate "Wi-Fi" off

然后再测试网络。

十五、最终修复路线

这类问题不要乱猜。

按这个顺序来：

1. 确认 SOCKS5 10808 是否可用。
2. 如果 SOCKS5 可用，说明节点没坏。
3. 检查 TUN 是否创建 utun 网卡。
4. 检查路由是否走 utun。
5. 检查 Auto Route 是否开启。
6. 检查 DNS Hijack 是否开启。
7. 检查 10809 HTTP 代理是否真的监听。
8. TUN 修不好时，先用 SOCKS5 系统代理临时解决。

这次问题最核心的一句话是：

节点没坏，v2rayN 也不是完全不能用。

真正的问题是：

TUN 没有把系统流量接管过来。

所以，不要一上来就重装。

先看端口。

再看 utun。

再看路由。

再看 DNS。

这样排查，才不会越修越乱。

用 chatgpt 的 session 代充值

Sat, 30 May 2026 19:38:45 +0800

问：

plus 充值，请先浏览器登录 https://chatgpt.com，之后打开 https://chatgpt.com/api/auth/session，点进去，把里面的内容全选复制给我即可这个的充值原理是啥？

答：

这种充值方式的原理，简单来说就是提取你账号的临时「通行证」（Access Token），让代充商家可以在不获取你账号密码的情况下，直接以你的身份进入系统完成支付。

核心原理拆解

获取会话凭证：你打开的那个链接，返回的是你当前登录状态的底层数据。在这堆数据中，最关键的一项叫做「accessToken」。这相当于你账号当前的一把临时钥匙。
规避风控拦截：ChatGPT 对支付环境的风控极其严格。如果商家直接用你的账号密码在他们的电脑（异地 IP）上登录，极大概率会触发 OpenAI 的安全警报，导致无法调出支付页面甚至直接封号。
伪造本人操作：商家拿到你复制的「accessToken」后，可以通过修改浏览器请求头等技术手段，把这把钥匙挂在他们自己的网络请求上。服务器一看到这把合法的钥匙，就会误以为是你在自己的设备上进行操作。
完成绑卡扣款：绕过风控后，商家就能顺利进入账单系统，绑定他们自己的虚拟信用卡完成扣款，从而让你的账号升级为 Plus。

潜在的安全与隐私风险

隐私完全暴露：这把临时钥匙的权限非常高。在它失效之前，商家不仅能帮你充值，理论上也可以读取、浏览甚至导出你的所有历史对话记录。
信用卡连带封号：第三方代充通常使用的是批量生成的虚拟信用卡。如果这张卡存在风险（比如拒付、灰产来源），OpenAI 的支付网关在后续清算时一旦发现异常，会直接封禁使用了该卡的账号。

如果你已经通过这种方式完成了充值，建议立刻前往 ChatGPT 的设置（Settings）中，找到安全相关选项并点击「Log out of all devices」（登出所有设备）。这个操作可以强制让你之前提取的「accessToken」立即失效，从而阻断商家继续访问你账号的可能。

Mac M1 上 v2rayN 提示“中国大陆证书问题访问不了”：一次真实排障复盘

Sat, 30 May 2026 19:27:23 +0800

一、问题背景

在 Mac M1 / Apple Silicon 设备上安装 v2rayN 后，用户反馈访问部分网站失败，v2rayN 提示类似：

中国大陆有证书问题，访问不了。

很多人第一反应会认为是“证书坏了”“系统证书不对”“网站证书异常”。但从实际排查过程看，这类问题不一定真是证书问题。

这次案例的真实原因是：

v2rayN 主程序启动了
xray / sing-box 核心也启动了
但 macOS 系统代理没有启用
而且实际代理端口不是默认的 10809 / 10808
同时 DNS 解析也存在异常

所以最终表现出来像是 TLS / SSL / 证书问题，但底层真正的问题是：

系统流量没有进入 v2rayN 代理，而是在直连；直连时 DNS 又解析异常，导致 TLS 握手超时。

二、先看现象：为什么看起来像“证书问题”？

执行检测脚本时，直连访问 https://www.google.com 出现了：

SSL connection timeout
curl: (28) SSL connection timeout

这句话非常关键。

它不是：

SSL certificate problem
certificate verify failed
unable to get local issuer certificate

如果是上面这类报错，才更像是系统证书链、根证书、目标证书或者中间人证书问题。

但本次是：

SSL connection timeout

这说明连接已经到了 TLS 握手阶段，但握手一直没有完成，最后超时。

通俗说就是：

不是证书校验失败，而是连到一个不正常的目标之后，TLS 握手卡住了。

三、第一处异常：DNS 解析不正常

检测结果里，www.google.com 被解析成了：

157.240.7.20

这个结果明显不正常。

157.240.x.x 更像 Meta / Facebook 相关 IP 段，不应该是 Google 常规解析结果。

同时 curl 里还出现了：

IPv6: 2001::1
IPv4: 157.240.7.20

这说明当前网络环境下 DNS 解析有较大概率存在以下情况之一：

1. DNS 污染
2. 路由器 / 热点 DNS 异常
3. 上游 DNS 不可靠
4. 网络链路对特定域名做了错误解析

DNS 解析错了之后，浏览器或者 curl 就会连到错误的 IP。连到错误 IP 后，TLS 握手自然容易失败、卡住、超时。

所以这里的第一条判断是：

直连链路不可靠，DNS 已经异常。

四、第二处异常：v2rayN 默认代理端口没有监听

检测脚本默认测试了两个常见端口：

HTTP 代理端口：10809
SOCKS5 代理端口：10808

但是检测结果显示：

127.0.0.1:10809 没有监听
127.0.0.1:10808 没有监听

随后通过 curl 测试代理访问：

curl -Iv -x http://127.0.0.1:10809 https://www.google.com

Connection refused
Failed to connect to 127.0.0.1 port 10809

再测 SOCKS5：

curl -Iv --socks5-hostname 127.0.0.1:10808 https://www.google.com

同样返回：

Connection refused
Failed to connect to 127.0.0.1 port 10808

Connection refused 的含义非常直接：

这个端口上没有程序在接收连接。

也就是说，不是节点不通，也不是远端服务器拒绝，而是本机 127.0.0.1:10809 / 127.0.0.1:10808 这两个代理端口根本没开。

五、第三处异常：v2rayN 核心其实启动了，但监听的是另一个端口

继续检查进程：

ps aux | grep -Ei "v2ray|v2rayn|xray|sing-box|mihomo|clash" | grep -v grep

可以看到：

v2rayN 主程序已启动
sing-box 已启动
xray 已启动

这说明 v2rayN 不是完全没运行。

再看监听端口：

lsof -nP -iTCP -sTCP:LISTEN | grep -Ei "108|789|2017|2080|9090|v2ray|xray|sing|clash|mihomo"

发现实际监听的是：

xray TCP 127.0.0.1:59022 (LISTEN)

这一步直接把问题定位清楚了：

你以为代理端口是 10809 / 10808
但真实监听端口是 59022

所以之前拿 10809 / 10808 测代理，当然会失败。

六、第四处异常：macOS 系统代理没有启用

继续检查 macOS 系统代理：

networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi
networksetup -getsocksfirewallproxy Wi-Fi

结果显示：

Enabled: No
Server: 127.0.0.1
Port: 15236

Enabled: No
Server: 127.0.0.1
Port: 15236

Enabled: No
Server: 127.0.0.1
Port: 15235

这里有两个关键信息。

第一，Enabled: No：

系统代理没有启用

第二，系统记录的旧端口是：

15235 / 15236

但实际 xray 监听的是：

这说明系统代理配置和 v2rayN 当前实际监听端口完全错位。

最终状态就是：

v2rayN 核心在跑
但 macOS 系统流量没有走它
浏览器 / curl / 系统请求仍然在直连
直连 DNS 又异常
于是表现为 SSL / TLS / 证书类错误

一句话概括：

代理核心在旁边跑着，但系统流量没有进代理通道。

七、正确排查命令清单

1. 查看 v2rayN / xray / sing-box 是否运行

ps aux | grep -Ei "v2ray|v2rayn|xray|sing-box|mihomo|clash" | grep -v grep

如果没有任何输出，说明 v2rayN 或核心没起来。

如果能看到：

v2rayN
xray
sing-box

说明主程序和核心至少已经启动。

2. 查看本机实际监听端口

lsof -nP -iTCP -sTCP:LISTEN | grep -Ei "108|789|2017|2080|9090|v2ray|xray|sing|clash|mihomo"

重点看类似：

127.0.0.1:59022 (LISTEN)

这个端口才是当前真实代理端口。

不要死盯 10809 / 10808，因为 v2rayN 可能会动态生成或使用其他端口。

3. 测试这个端口是 HTTP 代理还是 SOCKS5 代理

假设实际监听端口是 59022，先测 HTTP：

curl -Iv -x http://127.0.0.1:59022 --connect-timeout 10 --max-time 20 https://www.google.com -o /dev/null

再测 SOCKS5：

curl -Iv --socks5-hostname 127.0.0.1:59022 --connect-timeout 10 --max-time 20 https://www.google.com -o /dev/null

判断规则：

HTTP 那条成功：59022 是 HTTP 代理端口
SOCKS5 那条成功：59022 是 SOCKS5 代理端口
两条都失败：核心配置、节点、端口类型或入站配置可能有问题

4. 查看 macOS 系统代理状态

networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi
networksetup -getsocksfirewallproxy Wi-Fi

如果你不是用 Wi-Fi，可以先查看网络服务名称：

networksetup -listallnetworkservices

常见结果：

USB 10/100/1000 LAN
Wi-Fi
iPhone USB
Thunderbolt Bridge

如果当前网络是 Wi-Fi，就继续用 Wi-Fi。

八、修复方法一：在 v2rayN 里开启系统代理

最推荐先用图形界面操作。

打开 v2rayN，找到类似选项：

设置系统代理
自动配置系统代理
开启系统代理
Set system proxy
System Proxy

开启后，再执行：

networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi
networksetup -getsocksfirewallproxy Wi-Fi

看到：

Enabled: Yes

才说明系统代理真的打开了。

如果仍然是：

Enabled: No

那说明 v2rayN 没有成功写入 macOS 系统代理配置。

九、修复方法二：手动设置 macOS 系统代理

如果确认 59022 是 SOCKS5 代理端口，可以执行：

sudo networksetup -setsocksfirewallproxy Wi-Fi 127.0.0.1 59022
sudo networksetup -setsocksfirewallproxystate Wi-Fi on

验证：

networksetup -getsocksfirewallproxy Wi-Fi

正常应该显示：

Enabled: Yes
Server: 127.0.0.1
Port: 59022

如果确认 59022 是 HTTP 代理端口，可以执行：

sudo networksetup -setwebproxy Wi-Fi 127.0.0.1 59022
sudo networksetup -setsecurewebproxy Wi-Fi 127.0.0.1 59022

sudo networksetup -setwebproxystate Wi-Fi on
sudo networksetup -setsecurewebproxystate Wi-Fi on

验证：

networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi

正常应该显示：

Enabled: Yes
Server: 127.0.0.1
Port: 59022

十、修复方法三：处理 DNS 异常

本次日志里 DNS 也明显不正常，所以建议把 DNS 改成更稳定的公共 DNS。

执行：

sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 8.8.8.8

然后清理 DNS 缓存：

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

重新测试：

dig www.google.com

如果 DNS 结果仍然异常，说明当前网络链路本身可能存在 DNS 污染或拦截。这时候更要先保证系统代理真正生效。

十一、如何判断已经修好？

1. 系统代理启用

networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi
networksetup -getsocksfirewallproxy Wi-Fi

至少对应协议要看到：

Enabled: Yes
Server: 127.0.0.1
Port: 正确端口

2. 代理端口有监听

lsof -nP -iTCP -sTCP:LISTEN | grep -Ei "v2ray|xray|sing|59022|108|789"

要看到类似：

127.0.0.1:59022 (LISTEN)

3. 通过代理访问成功

HTTP 代理测试：

curl -Iv -x http://127.0.0.1:59022 https://www.google.com -o /dev/null

或者 SOCKS5 测试：

curl -Iv --socks5-hostname 127.0.0.1:59022 https://www.google.com -o /dev/null

如果看到：

HTTP/2 200
HTTP/1.1 200

或者没有 TLS 超时报错，说明代理链路基本正常。

十二、这类问题的排查模型

以后遇到 v2rayN、Clash、sing-box、xray 类似问题，不要一上来就重装。

按这个顺序排：

第一步：程序是否启动
第二步：核心是否启动
第三步：本地端口是否监听
第四步：系统代理是否开启
第五步：系统代理端口是否和实际监听端口一致
第六步：DNS 是否异常
第七步：通过代理 curl 是否成功
第八步：再考虑证书问题

很多所谓“证书问题”，本质并不是证书坏了，而是：

DNS 解析错了
系统代理没开
端口配错了
代理核心没监听
系统流量没走代理

十三、本次案例最终结论

本次问题不是典型证书问题。

真实原因是：

1. v2rayN 主程序已启动；
2. xray / sing-box 核心也已启动；
3. 但默认检测端口 10809 / 10808 没有监听；
4. 实际监听端口是 127.0.0.1:59022；
5. macOS 系统代理处于 Disabled；
6. 系统代理记录的端口还是旧的 15235 / 15236；
7. 当前 DNS 解析也异常；
8. 所以浏览器和 curl 仍然直连，导致 TLS 握手超时；
9. 最终表现成类似“证书问题”。

一句话总结：

v2rayN 不是没运行，而是系统流量没有接入它；修复重点不是重装证书，而是确认本地监听端口、开启系统代理，并修正 DNS。

OpenClaw 报错：Managed Codex app-server binary was not found 的根因与修复方法

Thu, 28 May 2026 20:56:57 +0800

OpenClaw 报错：Managed Codex app-server binary was not found 的根因与修复方法

一、问题现象

在 OpenClaw 使用 Codex 嵌入式代理时，出现如下报错：

Embedded agent failed before reply:
Managed Codex app-server binary was not found for @openai/codex.
Reinstall or update OpenClaw, or run pnpm install in a source checkout.
Set plugins.entries.codex.config.appServer.command or OPENCLAW_CODEX_APP_SERVER_BIN to use a custom Codex binary.

这个错误的直观表现是：

OpenClaw 已经收到了任务，也已经尝试启动 Codex 嵌入式代理，但在真正回复之前，Codex app-server 启动失败了。

换句话说，这不是模型回答质量问题，也不是 prompt 问题，而是 OpenClaw 在调用 Codex 本地服务时，找不到应该启动的 Codex app-server 可执行文件。

二、第一层理解：这个错误到底是什么意思？

这句话的核心是：

Managed Codex app-server binary was not found

意思是：

OpenClaw 的 Codex 插件默认会尝试使用它自己管理的 Codex app-server binary，也就是所谓的 managed binary。

但当前环境里，这个 managed binary 没找到。

所以 OpenClaw 给了三个方向：

Reinstall or update OpenClaw

重新安装或更新 OpenClaw。

run pnpm install in a source checkout

如果你是源码安装 OpenClaw，那么进入源码目录执行 pnpm install。

Set plugins.entries.codex.config.appServer.command or OPENCLAW_CODEX_APP_SERVER_BIN

手动指定 Codex app-server 的启动文件。

前两个办法适合普通安装缺失、源码依赖缺失的问题；但如果你反复重装仍然不行，就说明真正的问题不在 OpenClaw 主程序本身，而在 OpenClaw 找 Codex app-server 的路径逻辑上。

三、为什么重装 OpenClaw 也没用？

这类问题最容易误判成“OpenClaw 没装好”。

但实际排查下来，重装很多次仍然报错，通常说明：

OpenClaw 主程序是好的，Codex 也可能已经安装成功了。

真正坏的是：

OpenClaw 没有找到正确的 Codex app-server binary。

尤其在 Windows 环境里，经常会出现这种情况：

你已经通过 npm 安装了 @openai/codex，系统里也有 codex.cmd，但是 OpenClaw 的 Codex 插件默认并不会直接使用你 PATH 里的 codex.cmd。

它可能仍然去找自己插件目录里的 managed binary。

一旦这个 managed binary 没生成、没下载、没缓存成功、路径解析失败，或者 OpenClaw 当前版本在 Windows 上没有正确找到它，就会一直报：

Managed Codex app-server binary was not found

所以继续重装 OpenClaw 很可能只是重复覆盖主程序，而没有解决 Codex app-server binary 的真实路径问题。

四、错误排查过程

1. 第一反应：更新 OpenClaw

最先尝试的是：

openclaw update
openclaw doctor --non-interactive --fix
openclaw gateway restart

这个方向是合理的，因为如果只是 OpenClaw 安装不完整，更新和 doctor 修复可能解决。

但如果重装、更新、doctor 都无效，就要换思路。

2. 第二步：检查旧配置是否覆盖

然后排查 openclaw.json 里是否有旧的 Codex 配置，尤其是：

"appServer": {
  "command": "..."
}

如果这里写错路径，OpenClaw 会按错误路径启动 Codex。

所以之前尝试过删除：

plugins.entries.codex.config.appServer

并清理环境变量：

[Environment]::SetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_BIN", $null, "User")
[Environment]::SetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_ARGS", $null, "User")
[Environment]::SetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_MODE", $null, "User")

这个方向也没错，因为旧配置确实可能覆盖默认行为。

但你的场景里，这一步仍然没有解决。

这就说明问题不是“旧配置乱指”，而是 OpenClaw 默认 managed binary 本身找不到。

3. 第三步：确认 Codex CLI 是否独立可用

最终切入点是：

不要再让 OpenClaw 自己猜 Codex 在哪里，而是先确认系统里的 Codex CLI 是否能独立运行。

执行：

codex.cmd app-server --help

如果这条命令可以正常输出帮助信息，说明 @openai/codex 本身没坏。

也就是说：

Codex 能跑，OpenClaw 找不到它。

这个判断非常关键。

它把问题从“Codex 没装好”改成了“OpenClaw 没有找到正确的 Codex 启动文件”。

4. 第四步：找到 codex.cmd 的真实路径

执行：

(Get-Command codex.cmd).Source

一般会输出类似：

C:\Users\你的用户名\AppData\Roaming\npm\codex.cmd

这个路径才是 Windows 下 npm 全局安装生成的 Codex 命令入口。

只要 codex.cmd app-server --help 能跑，这个路径就可以作为 OpenClaw 的 Codex app-server 启动入口。

五、最终解决办法：显式指定 OPENCLAW_CODEX_APP_SERVER_BIN

最终解决命令是：

[Environment]::SetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_BIN", (Get-Command codex.cmd).Source, "User")

这条命令的意思是：

把系统里的 codex.cmd 路径写入用户级环境变量：

OPENCLAW_CODEX_APP_SERVER_BIN

OpenClaw 启动 Codex app-server 时，不再只依赖 managed binary，而是直接使用这个明确指定的 Codex 可执行文件。

然后确认一下：

[Environment]::GetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_BIN", "User")

如果能看到类似：

C:\Users\你的用户名\AppData\Roaming\npm\codex.cmd

说明环境变量写入成功。

接着关闭当前 PowerShell，重新打开一个新的 PowerShell。

注意：这一步非常重要。
环境变量写入之后，旧 PowerShell 窗口不一定立刻生效。

然后重启 OpenClaw gateway：

openclaw gateway stop

openclaw gateway start

或者：

openclaw gateway restart

最后检查状态：

openclaw gateway status

六、完整修复命令汇总

1. 安装或重装 Codex CLI

npm install -g @openai/codex

2. 测试 Codex app-server 是否能独立运行

codex.cmd app-server --help

如果能输出帮助信息，说明 Codex 本身可用。

3. 查看 codex.cmd 路径

(Get-Command codex.cmd).Source

4. 写入 OpenClaw Codex app-server 路径

[Environment]::SetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_BIN", (Get-Command codex.cmd).Source, "User")

5. 检查环境变量是否写入成功

[Environment]::GetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_BIN", "User")

6. 关闭 PowerShell，重新打开

这一步不要省略。

7. 重启 OpenClaw gateway

openclaw gateway stop

openclaw gateway start

或者：

openclaw gateway restart

8. 查看状态

openclaw gateway status

七、为什么这个办法有效？

因为这个错误的本质不是 OpenClaw 没装好，而是：

OpenClaw 的 Codex 插件默认要找 managed Codex app-server binary，但它没有找到。

而我们通过：

OPENCLAW_CODEX_APP_SERVER_BIN

直接告诉 OpenClaw：

不要猜了，就用这个 codex.cmd 来启动 app-server。

这相当于绕过了 OpenClaw 默认的 managed binary 查找逻辑，直接指定了一个已经验证可用的 Codex 启动入口。

这也是为什么前面重装 OpenClaw、清理配置、删除 appServer 配置都不一定有效，而最后这一步能解决。

八、这类问题的标准判断流程

以后再遇到类似报错，可以按这个顺序判断：

第一层：看错误关键词

如果看到：

Managed Codex app-server binary was not found

先判断为：

OpenClaw 找不到 Codex app-server binary。

不要先怀疑 prompt，也不要先怀疑模型。

第二层：确认 Codex 是否独立可用

执行：

codex.cmd app-server --help

如果这条命令失败，说明 Codex CLI 本身没装好。

如果这条命令成功，说明 Codex 没坏，是 OpenClaw 找不到它。

第三层：显式指定 Codex 路径

执行：

[Environment]::SetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_BIN", (Get-Command codex.cmd).Source, "User")

然后重启 PowerShell 和 gateway。

第四层：检查 OpenClaw 配置

如果仍然失败，再检查：

openclaw.json

重点看有没有：

"appServer": {
  "command": "..."
}

如果有错误路径，删除或者修正。

九、经验总结

这次问题最大的坑在于：

错误提示里第一句就说：

Reinstall or update OpenClaw

所以人很容易陷入“反复重装”的循环。

但实际上，重装只能解决 OpenClaw 主程序或托管 binary 安装不完整的问题。

如果问题是 Windows 下 Codex binary 路径解析失败，或者 OpenClaw 没有使用 npm 全局安装的 codex.cmd，那么重装多少遍都可能没用。

真正有效的判断是：

codex.cmd app-server --help

只要这条命令能跑，就说明 Codex 在系统里是好的。

接下来要做的不是重装，而是把它的路径明确告诉 OpenClaw：

[Environment]::SetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_BIN", (Get-Command codex.cmd).Source, "User")

最终一句话：

这个问题不是 Codex 不存在，而是 OpenClaw 没找到正确的 Codex app-server 启动入口。

解决方法也很简单：

先确认 codex.cmd 能跑，再用 OPENCLAW_CODEX_APP_SERVER_BIN 显式指定它。

华为甩出"韬定律",最先疼的为什么是 ASML,而不是台积电?

Mon, 25 May 2026 18:15:34 +0800

华为甩出"韬定律",最先疼的为什么是 ASML,而不是台积电?

2026年5月25日,上海。何庭波在 IEEE 国际电路与系统研讨会上,正式抛出了"韬(τ)定律"。

新闻标题写得很燃:中国第一次在半导体领域提出产业级指导原则,剑指1.4纳米,麒麟2026今秋首发。

但燃归燃,有一个问题被淹没在欢呼声里没人认真答:这套东西真正砸中的,到底是谁?

很多人下意识觉得是台积电——你看,华为绕开了先进制程,这不就是打台积电的脸吗?

恰恰相反。我把账算了一遍,结论是:短期里真正被这根刺扎到的是 ASML,而台积电反而和华为撞了同一个方向。

要把这话说清楚,得先花三分钟,把"韬定律"翻译成人话。

一、先别管 τ 长什么样,它就干了一件事:换了个考核指标

过去六十年,芯片行业进步只靠一招——把晶体管做小。

这就是摩尔定律的本质:同样的钱,晶体管数量每一两年翻一倍。能翻倍,是因为做小之后又快又便宜。

问题是,7纳米以后,这招不灵了。

物理上,晶体管小到一定程度,再小已经快不起来了,反而是晶体管之间那些"连线"的电阻电容拖了后腿。经济上,一颗最先进芯片光设计费就过10亿美元,做小一颗晶体管的成本不降反升。

华为的处境比别人更早撞墙,因为它根本买不到最先进的光刻机。逼到墙角,反而逼出一个更根本的问题:我们到底该缩小什么?

韬定律给的答案是:别盯着"把晶体管做多小"了,改盯"信号跑完一段路要花多少时间"。

这个时间,就是 τ。

听着玄,其实道理特别朴素:做小晶体管,无非也是为了让信号跑得更快、跑的路更短。既然最终图的是"快",那就直接把"快"当成考核指标,而不是把"小"当指标。

这一步换得很聪明。因为"做小"这条路被光刻机卡死了,但"让信号跑得快"还有别的办法。

最关键的办法,叫逻辑折叠(LogicFolding)。

一句话:**以前芯片是平房,所有电路摊在一个平面上,连线越拉越长;现在把它改成盖楼,把电路竖着叠成两层、未来更多层,楼上楼下用极细的"管线"连起来。**连线一下子短了一大截,信号跑得快了,同样的工艺、不用更先进的光刻,频率和密度都能往上提。

麒麟2026实测:晶体管密度从155一步跳到238(单位 MTr/mm²),频率重回3.1GHz,能效提升41%。这个密度跳幅,过去得靠三年的工艺微缩才能做到。

这就是全部故事的技术内核。听懂了这个,下面才好谈冲击。

二、ASML:营收没掉一分钱,但被扎中了最敏感的那根神经

先说结论:这事对 ASML 今年的财报,影响几乎是零;但对它赖以估值的那套"信仰",是一根扎进去拔不出来的刺。

ASML 是干嘛的?全世界唯一能造 EUV 光刻机的公司,7纳米以下没有任何替代品。一台普通 EUV 卖约1.8亿欧元,新一代 High-NA 一台3.8亿欧元起,客户还得排队抢。

它整个商业模式建立在一句话上:只要行业还想往更先进的制程走,就必须找我买更贵的机器。 2026年它的营收指引是340亿到390亿欧元,EUV 是绝对主力,在手订单几百亿,这是一台还在加速的印钞机。

那韬定律威胁到这台印钞机了吗?

直接威胁——没有。

第一,华为本来就买不到 ASML 最先进的机器,它的营收盘子里早就没算华为这块。事实上今年一季度,中国占 ASML 系统销售的比例已经从去年四季度的36%掉到约19%,而且掉的主要是利润较低的旧机型。华为这条路走不走,ASML 的现金流都照样滚。

第二,逻辑折叠靠的是"叠楼层",叠楼层要用的是键合、刻蚀、对准这些设备,反而不太吃最先进的光刻。所以从设备账面看,这甚至是把蛋糕从光刻挪向了别的环节。

那刺在哪?

刺在叙事上。

ASML 之所以能享受高估值(它的市销率是行业平均的两倍多),靠的不只是订单,而是一个深入人心的信念:想要更强的芯片,就只有华山一条路——买我的光刻机往更先进的制程走。

韬定律第一次由一家有量产规模的公司,系统性地、还带着381颗芯片数据,公开喊出另一句话:"先进性能,不必永远待在光刻的最前沿。封装、堆叠、互连,现在也能拿到过去只有先进制程才有的战略分量。"

这句话本身比麒麟那点密度数据,杀伤力大得多。

它不会让 ASML 今年少卖一台机器,但它在动摇一个长期共识:光刻 ≠ 进步的唯一入口。一旦这个共识开始松动,资本市场给 ASML 那份"独家通路"的估值溢价,逻辑上就该打个折。

所以 ASML 的疼,是慢性的、估值层面的疼,不是急性的、营收层面的疼。但对一家靠"信仰"撑起高估值的公司来说,信仰被人公开质疑,本身就是事件。

三、台积电:看着像被打脸,其实是撞了个满怀

这才是最反直觉的地方。

直觉上,华为"绕开先进制程"=打台积电的脸。错。

真相是:华为这次喊的方向,台积电早就在闷头干了,而且干得比谁都猛。

不信你看台积电2026年在干什么:

全年资本开支520亿到560亿美元,其中10%到20%专门砸在先进封装上,先进封装收入占比正从2025年的约8%往10%以上爬。
CoWoS 产能往130万片/月翻番扩张,SoIC(把芯片竖着叠成一个系统)被它自己定为"核心产能驱动力"。
它对2026年的官方定调是:"3D硅时代"——竖着叠和横着拼,和用什么光刻一样重要。 行业里那句话说得更直白:瓶颈已经从"算得快不快"变成"芯片之间说话快不快"。

把台积电这套话和华为的韬定律放一起读——System-as-One-Chip、把封装当系统、用垂直堆叠缩短连线、3D折叠——你会发现两家说的几乎是同一件事。

所以华为不是在反对台积电,是和台积电同时押注了同一条赛道。

那区别在哪?区别在驱动力,这点很要命:

台积电是"最先进制程 + 最先进封装",双轮驱动,从容选择;华为是"成熟制程 + 激进封装",单轮求生,被逼上路。

台积电是手里既有2纳米、又有 CoWoS,封装是它锦上添花的第二条增长腿;华为是先进制程这条腿被打断了,只能靠封装这条腿单脚跳。

这就决定了短期内华为撼不动台积电的护城河:

NVIDIA 一家就锁了台积电2026年六成以上的 CoWoS 产能,AMD 抢11%,生态被钉死;
台积电能做5.5倍光罩尺寸、良率98%的巨型封装,这是工程积累,不是一篇论文能追上的;
全球最赚钱的 AI 芯片,设计、制造、封装一条龙都在它这里。

但是,长期看,台积电该警惕的恰恰是它自己证明的那个趋势。

如果"系统和封装"的权重持续上升、"纯制程"的权重持续下降——而这正是台积电自己在反复强调的方向——那么台积电过去靠"我有全世界最先进制程"收取的那份超额溢价,就会被稀释。当成熟制程加上聪明的封装也能打到够用的性能时,愿意为最尖端那一两个纳米付天价的客户,会变少。

护城河不会消失,但护城河的形状会变:从"我有最小的晶体管",变成"我有最强的系统集成能力"。这对台积电不是灭顶之灾,却是一次需要主动转身的提醒。而华为,正是在帮全行业把这个转身的时刻往前提。

四、泼盆冷水:哪些是真功夫,哪些是话术

文章写到这,得把吹的和实的分开,不然就成了通稿。评论区有句话很扎眼——"等效1.4nm是虚的,新定律是营销的"。这话刻薄,但不全错。

把账摊开说:

第一,"等效1.4纳米"是密度等效,不是制程等效。 华为是用"叠楼层"把单位面积的晶体管数量堆到了1.4纳米工艺的水平,不等于它造出了1.4纳米的晶体管。这两件事差着十万八千里,前者靠封装,后者靠光刻。混着说,就容易让人以为制裁被破解了——并没有。

第二,韬定律更像是"给已有实践起了个名字"。 Chiplet、先进封装、超节点、系统级协同,这些东西业界做了好几年了,台积电、英特尔都在做。华为的贡献是把它们用"时间常数 τ"这根线串成了一套统一叙事,并第一个把它升格成"定律"。这里面有真的方法论价值,但升格成"定律"这个动作,本身就是一次话语权的抢夺,营销成分不必讳言。

第三,真正难的坑,华为自己也承认还没填上: 多层晶圆键合在一起,不同批次的工艺误差会被放大;EDA 设计工具还没有真正能处理三维堆叠的;良率、能耗都是硬骨头。论文里这些都老老实实写了——这是它专业的一面,也说明这是张十年的路线图,不是已经兑现的战报。

第四,也是最该承认的:这是被制裁逼出来的换赛道,不是从容的战略选择。 但被逼出来的路,不一定是坏路。当年正是因为做小晶体管这条路对华为关死了,它才被迫去想"除了做小,还能缩小什么"。约束有时候反而能逼出真正的原创。

五、那这事到底重要在哪

剥掉营销,剥掉民族情绪,这件事最硬的内核只有一个词:定义权。

过去六十年,芯片行业的游戏规则是别人定的——摩尔定律、登纳德缩放,优化什么、朝哪缩,标准在西方手里,ASML 和台积电是这套规则下最大的两个受益者:一个垄断了通往规则前沿的唯一入口,一个垄断了在规则前沿的最佳制造。

韬定律真正的动作,不是技术上掀桌子,而是第一次有一家中国公司站出来说:这个游戏,也可以按另一套指标来打,而且我有381颗芯片证明它能打。

所以,给三方各留一句话:

对 ASML: 你今年的钱一分不少,但有人开始公开质疑"你是唯一的路"了。慢性的、估值层面的隐忧,从今天开始计时。
对台积电: 别紧张,他和你押的是同一个方向;但也别松懈,他在帮全行业把"制程不再是唯一"这件事提前坐实,而你过去最值钱的恰恰是制程领先。
对华为自己: 把"密度等效"老老实实说成密度等效,把十年路线图老老实实当十年走。这套东西真正的价值,不在今秋那颗麒麟,而在它有没有本事,真的把一套中国人定义的标准,变成全行业愿意跟的标准。

几何时代的句号还没真正画上,但有人已经开始在旁边,另起了一行。

数据来源:华为官网(huawei.com)韬定律发布稿、ISCAS 2026 演讲及 ChinaXiv 预印本;ASML 2026 Q1 财报及全年指引;台积电 2026 资本开支与先进封装路线图(TSMC Tech Symposium 2026、TrendForce、SemiEngineering 等公开报道)。本文为独立分析,技术数据以华为官方口径为准。

OpenClaw browser --browser-profile 深度解析：这不是“打开浏览器”，而是给 AI 配一套可控的网页操作工作台

Sun, 24 May 2026 18:02:59 +0800

OpenClaw `browser --browser-profile` 深度解析：这不是“打开浏览器”，而是给 AI 配一套可控的网页操作工作台

一、先给结论

openclaw browser --browser-profile 解决的不是“能不能打开网页”的问题，而是解决：

AI 用哪个浏览器身份、哪个登录环境、哪个隔离空间、哪个远程浏览器、哪个任务现场去干活。

一句话说清楚：

--browser-profile 就是给 OpenClaw 的浏览器工具指定一个“浏览器工作身份”。

这个身份可以是：

profile	含义	适合场景
`openclaw`	OpenClaw 自己管理的独立浏览器环境	最推荐，安全、隔离、不污染个人浏览器
`user`	接管你当前真实 Chrome 登录环境	需要用你已登录账号时，比如 X、Google Docs、后台系统
自定义 profile，如 `work`	单独创建一个工作浏览器环境	多任务、多账号、多客户隔离
`remote`	连接远程 CDP 浏览器	服务器、容器、远程浏览器自动化

官方文档里说得很明确：OpenClaw 可以运行一个专门的 Chrome / Brave / Edge / Chromium profile，由 agent 控制，并且这个 profile 与个人浏览器隔离；默认的 openclaw profile 不会碰你的个人浏览器。(OpenClaw)

所以，这个功能的价值非常大。

它让 OpenClaw 从“会聊天的龙虾”，变成“能看网页、点网页、填表、截图、导出 PDF、验证结果的业务执行助手”。

二、`openclaw browser` 本质上是什么？

1. 它是 OpenClaw 给 AI 准备的“浏览器控制面”

官方 CLI 文档对 openclaw browser 的定义是：管理 OpenClaw 的浏览器控制面，并执行浏览器动作，包括生命周期、profiles、tabs、快照、截图、导航、输入、状态模拟和调试等。(OpenClaw)

通俗说，它不是普通浏览器命令，而是一套让 AI 可以操作浏览器的控制系统。

它能做这些事情：

能力	作用
start	启动浏览器
stop	停止浏览器
status	查看状态
doctor	检查浏览器控制是否正常
open	打开网页
tabs	查看标签页
snapshot	读取页面结构
screenshot	截图
pdf	导出页面 PDF
click/type/select/drag	模拟点击、输入、选择、拖拽

官方文档里也列出 OpenClaw browser 能提供确定性的 tab 控制、agent 点击/输入/拖拽/选择、页面快照、截图和 PDF 等能力。(OpenClaw)

2. 它解决的是 AI 的“眼睛”和“手”的问题

普通聊天模型只能靠你发文字。

但 OpenClaw browser 让 agent 可以：

自己打开网页；
自己看页面；
自己点按钮；
自己填输入框；
自己切 tab；
自己截图；
自己导出 PDF；
自己验证网页变化。

这就相当于给 AI 装上了：

眼睛：看网页内容。
手：操作网页界面。
记忆现场：保留登录状态、cookie、tab、历史访问环境。

这也是 OpenClaw 和普通对话机器人的关键分界线。

三、`--browser-profile` 到底是什么？

1. 它不是“浏览器标签页”，而是“浏览器身份”

很多人会误解：

我新开一个 tab，是不是就是新 profile？

不是。

tab 只是同一个浏览器环境里的一个页面。

profile 是更大的概念，它包括：

cookie；
登录状态；
本地缓存；
浏览器数据目录；
页面权限；
自动化连接方式；
CDP 控制端口；
是否 headless；
是否接管已有浏览器；
是否连接远程浏览器。

官方 CLI 文档把 profiles 定义为“named browser routing configs”，也就是命名的浏览器路由配置。实际使用中，openclaw 会启动或连接到 OpenClaw 管理的独立 Chrome 实例；user 会通过 Chrome DevTools MCP 控制用户已有的登录 Chrome；自定义 CDP profile 可以指向本地或远程 CDP endpoint。(OpenClaw)

所以：

openclaw browser --browser-profile openclaw open https://example.com

意思不是“随便打开一个网页”。

它的完整含义是：

让 OpenClaw 使用名为 openclaw 的浏览器工作环境，打开这个网页。

2. `--browser-profile` 的价值是“明确指定任务现场”

比如你有三个任务：

任务 A：用学生咨询系统后台整理记录
任务 B：用企业微信后台查客户消息
任务 C：用 Google 搜索资料做行业研究

如果都混在一个浏览器里，很容易出问题：

登录状态串了；
tab 太多乱了；
AI 点错页面；
一个任务关闭了另一个任务的页面；
用错账号；
把客户 A 的后台当成客户 B；
自动化过程中误操作你的个人浏览器。

--browser-profile 就是为了解决这些问题。

你可以这样分：

openclaw browser --browser-profile openclaw open https://google.com
openclaw browser --browser-profile work open https://company-backend.example.com
openclaw browser --browser-profile student open https://student-system.example.com

每个 profile 是一个相对独立的浏览器工作区。

四、默认 profile：`openclaw`

1. `openclaw` 是最推荐的新手默认方案

官方文档说，openclaw profile 是一个独立的、agent-only 的浏览器；它不触碰你的个人浏览器 profile，agent 可以在这个安全通道里打开 tab、读取页面、点击和输入。(OpenClaw)

也就是说，默认最稳的用法就是：

openclaw browser --browser-profile openclaw doctor
openclaw browser --browser-profile openclaw status
openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw open https://example.com
openclaw browser --browser-profile openclaw snapshot

这个 profile 适合：

公开网页研究；
行业资料搜集；
竞品页面分析；
自动截图；
网页转 PDF；
测试网页功能；
不需要你个人账号登录的任务；
给 agent 一个干净环境干活。

2. 它的核心好处：不污染你的个人浏览器

你个人 Chrome 里可能有：

微信网页版；
Gmail；
飞书；
企业后台；
支付宝；
ChatGPT；
各种客户系统；
各种自动登录 cookie。

如果让 AI 直接在你的个人浏览器里乱点，风险很高。

所以 openclaw profile 的意义是：

先给 AI 一个隔离浏览器，让它在可控空间里工作。

这就是“安全车道”。

官方文档也特别提醒：这个 browser 不是你的日常主浏览器，而是 agent automation 和 verification 的安全、隔离表面。(OpenClaw)

五、特殊 profile：`user`

1. `user` 是用来接管你真实 Chrome 登录环境的

user profile 的含义是：

让 OpenClaw 连接你当前真实登录的 Chrome 会话。

官方文档说明，内置的 user profile 会通过 Chrome MCP 附加到你的真实已登录 Chrome session。(OpenClaw)

它适合这种情况：

网站必须登录；
登录过程复杂；
验证码很多；
自动登录容易被风控；
你已经在 Chrome 里登录好了；
agent 只是需要帮你读页面、点按钮、整理内容。

比如：

openclaw browser --browser-profile user tabs

或者：

openclaw browser --browser-profile user open https://docs.google.com

2. 什么时候用 `user`？

典型场景：

场景	为什么要用 `user`
Google Docs	你已经登录 Google 账号
X / Twitter	自动登录容易触发风控
企业后台	需要真实账号权限
飞书管理后台	需要企业登录状态
微信公众平台	扫码登录，不适合给模型账号密码
支付类后台	必须人工确认
客户系统	登录流程复杂，cookie 已在本机

官方登录文档也建议：当网站需要登录时，应该在 host browser profile 里手动登录，不要把凭据交给模型；自动化登录容易触发反机器人机制甚至锁号。(OpenClaw)

这句话非常重要。

AI 可以帮你操作页面，但账号密码、验证码、二次验证，最好还是你自己处理。

六、为什么不建议一上来就用 `user`？

因为 user 虽然方便，但风险也更高。

1. 它接的是你的真实浏览器

你的真实浏览器里面有大量敏感环境：

已登录后台；
邮箱；
私人账号；
企业账号；
客户资料；
财务系统；
表单提交权限；
删除权限；
发布权限。

如果 agent prompt 被网页里的恶意内容影响，或者你给了过宽权限，就可能出现误操作。

所以我的建议是：

能用 openclaw，先用 openclaw；必须用登录态，再用 user。

2. `user` 也有功能限制

官方故障排查文档提到，user / existing-session profiles 保留当前 Chrome MCP 的限制，例如 ref-driven actions、单文件上传 hooks、没有 dialog timeout overrides、没有 wait --load networkidle、没有 responsebody、PDF export、download interception 或 batch actions。(OpenClaw)

通俗说：

user 适合接管真实登录状态，但不是所有自动化能力都像 managed browser 那么完整。

所以，如果你只是做网页分析、截图、转 PDF、公开资料抓取，openclaw 更合适。

如果你必须依赖真实登录状态，再用 user。

七、自定义 profile：`work`、`student`、`client-a`

1. 自定义 profile 解决“多任务隔离”

你可以创建多个 profile。

官方 CLI 文档给了类似命令：

openclaw browser profiles
openclaw browser create-profile --name work --color "#FF5A36"
openclaw browser create-profile --name chrome-live --driver existing-session
openclaw browser create-profile --name remote --cdp-url https://browser-host.example.com
openclaw browser delete-profile --name work

文档也说明，可以通过 --browser-profile work 使用指定 profile。(OpenClaw)

这就非常适合你这种场景。

比如你要同时跑：

学生咨询系统；
微信公众号素材采集；
行业报告资料搜集；
客户后台经营数据查看；
AI 课程后台管理。

你可以这样设计：

openclaw browser create-profile --name student
openclaw browser create-profile --name report
openclaw browser create-profile --name client-a
openclaw browser create-profile --name client-b

使用时：

openclaw browser --browser-profile student open https://student-system.example.com
openclaw browser --browser-profile report open https://www.google.com
openclaw browser --browser-profile client-a open https://backend-a.example.com
openclaw browser --browser-profile client-b open https://backend-b.example.com

这样就不会乱。

2. 自定义 profile 的管理价值

对你这种经常做企业 AI 落地、课程演示、客户咨询的人来说，自定义 profile 的价值不只是技术隔离，而是业务管理。

可以按这些方式命名：

命名方式	示例	适合场景
按客户	`client-jurui`、`client-zhongqiyunlian`	客户后台、资料、系统隔离
按任务	`report`、`wechat-crawl`、`ppt-data`	不同任务互不干扰
按角色	`teacher`、`student`、`admin`	多角色系统测试
按账号	`x-main`、`x-alt`	社媒多账号
按环境	`dev`、`test`、`prod`	系统测试/后台验证

这就像你给 AI 配了多个“办公桌”。

每张桌子上只放这一类任务需要的资料、登录状态和页面。

八、远程 CDP profile：把浏览器放到服务器或容器里

1. 什么是 CDP？

CDP 是 Chrome DevTools Protocol，简单理解就是：

Chrome 提供的一套远程控制接口。

OpenClaw 可以通过 CDP 控制本地或远程浏览器。

官方文档里说，自定义 CDP profile 可以指向本地或远程 CDP endpoint；远程 CDP profiles 支持 http://、https://、ws://、wss://。 (OpenClaw)

比如：

openclaw browser create-profile --name remote --cdp-url https://browser-host.example.com
openclaw browser --browser-profile remote open https://example.com

2. 远程 profile 适合什么场景？

适合这些情况：

场景	价值
Linux 服务器没图形界面	用 headless browser 跑
WSL 控制 Windows 浏览器困难	改为远程 CDP
多任务长期运行	不占本机浏览器
企业统一部署	每个 agent 连指定远程 browser
自动化采集	放服务器上跑，不影响本机
演示环境	提前准备一个干净远程浏览器

尤其是你之前折腾过 Windows、WSL、微信、GUI 自动化，这个思路很重要：

凡是本机 GUI 控制不稳定的地方，可以考虑把浏览器自动化搬到可控的 CDP 环境。

九、它到底解决了哪些痛点？

痛点一：AI 操作网页容易污染个人浏览器

没有 profile 时，AI 可能直接操作你的真实浏览器。

这很危险。

有了 openclaw profile，AI 默认在独立环境里操作，不碰你的私人浏览器。官方文档也强调，openclaw 是隔离的 agent-only browser，不是日常主浏览器。(OpenClaw)

解决结果：

AI 有地方干活，但不会乱动你的私人账号。

痛点二：多个任务抢同一个浏览器现场

比如一个任务在查资料，一个任务在登录后台，一个任务在测试表单。

如果都在同一个浏览器 profile 里，会出现：

tab 混乱；
页面焦点抢来抢去；
AI 点错 tab；
登录态串台；
下载文件混在一起；
截图截错页面。

用不同 profile，可以把任务现场分开。

解决结果：

一个任务一个浏览器工作区，互不干扰。

痛点三：登录网站不能把账号密码交给模型

很多后台必须登录，但你不能把密码给模型。

官方登录文档也明确建议，登录应由用户在 host browser profile 里手动完成，不要把凭据交给模型，因为自动登录容易触发反机器人机制并锁定账号。(OpenClaw)

解决结果：

人负责登录和授权，AI 负责登录后的页面操作。

这就是合理分工。

痛点四：AI 只会“搜索”，不会“验证页面结果”

传统 web_search 只能拿搜索结果。

但真实业务里很多信息在网页交互后才出现：

点开菜单；
登录后台；
切换筛选条件；
翻页；
下载表格；
截图留证；
导出 PDF；
填写表单后验证提交结果。

官方工具总览里也把 browser 归为“Operate a browser session”，也就是当 agent 需要操作浏览器会话时使用。(OpenClaw)

解决结果：

OpenClaw 不只是查网页，而是能像人一样操作网页流程。

痛点五：演示和交付需要可复现现场

你做课程、直播、企业内训的时候，最怕演示翻车：

浏览器历史记录太乱；
账号没登录；
tab 太多；
页面缓存异常；
弹窗干扰；
AI 操作错页面。

如果提前准备一个 demo profile：

openclaw browser create-profile --name demo
openclaw browser --browser-profile demo open https://your-demo-page.example.com

你就可以把演示环境固定下来。

解决结果：

每次演示都从同一个干净现场开始，稳定性高很多。

十、哪些场景最适合用 `--browser-profile`？

场景一：行业研究和报告资料搜集

比如你让 OpenClaw 帮你研究：

新能源汽车后市场；
女士内衣 OEM/ODM；
假发行业；
稀土磁材；
AI 智能体工具。

可以用：

openclaw browser --browser-profile report open https://www.google.com

让它做：

搜索关键词；
打开报告页面；
截图；
保存 PDF；
记录来源；
对比不同网页信息；
把网页证据转成报告素材。

这类任务建议用 openclaw 或 report，不建议用 user。

场景二：企业后台操作

比如：

飞书管理后台；
微信公众平台；
CRM；
项目管理系统；
教务系统；
数据看板；
客户系统。

这类网站通常需要登录。

建议：

先用 user 或专门 profile 手动登录；
再让 agent 操作页面；
高风险按钮必须人工确认。

示例：

openclaw browser --browser-profile user tabs
openclaw browser --browser-profile user open https://example-admin.com

但要注意，user 适合真实登录态，但也意味着权限更大，要设置好 agent 行为边界。

场景三：网页自动化测试

你有 Laravel / Yii / 小程序后台 / AI dashboard 之类项目时，可以让 OpenClaw 帮你做：

打开本地页面；
输入表单；
点击提交；
检查提示；
截图；
回归测试；
生成 bug 记录。

示例：

openclaw browser --browser-profile test open http://localhost:3000
openclaw browser --browser-profile test snapshot

这类任务建议用独立 test profile，避免干扰其他工作。

场景四：多账号运营

比如你有：

一个主公众号；
一个课程号；
一个测试号；
一个客户号。

不要混在一个浏览器里。

可以这样：

openclaw browser create-profile --name wechat-main
openclaw browser create-profile --name wechat-course
openclaw browser create-profile --name wechat-client-a

每个 profile 登录不同账号。

这样 agent 执行任务时不会串号。

场景五：课程演示 / 直播演示

比如你要演示：

“AI 如何自动打开网页、查资料、截图、整理为报告。”

可以专门建：

openclaw browser create-profile --name demo
openclaw browser --browser-profile demo start

演示前准备好：

干净浏览器；
必要登录态；
固定书签；
固定页面；
无关 tab 清空。

这样直播时不容易翻车。

场景六：远程服务器自动化

如果你希望某些任务长期跑：

定时打开网页检查更新；
生成网页截图；
保存页面 PDF；
检查后台状态；
监控某个页面变化。

可以创建远程 CDP profile：

openclaw browser create-profile --name remote --cdp-url https://browser-host.example.com
openclaw browser --browser-profile remote open https://example.com

这类适合更工程化的 OpenClaw 自动化。

十一、常用命令清单

1. 查看已有 profiles

openclaw browser profiles

2. 启动默认独立浏览器

openclaw browser --browser-profile openclaw start

3. 查看状态

openclaw browser --browser-profile openclaw status

4. 做基础检查

openclaw browser --browser-profile openclaw doctor

更深检查：

openclaw browser --browser-profile openclaw doctor --deep

官方文档说明，doctor --deep 会增加 live snapshot probe，适合在基础 CDP readiness 正常后证明当前 tab 可以被检查。(OpenClaw)

5. 打开网页

openclaw browser --browser-profile openclaw open https://example.com

6. 查看 tabs

openclaw browser --browser-profile openclaw tabs

7. 读取页面快照

openclaw browser --browser-profile openclaw snapshot

8. 新建工作 profile

openclaw browser create-profile --name work --color "#FF5A36"

9. 使用工作 profile

openclaw browser --browser-profile work open https://example.com

10. 创建已有 Chrome 会话 profile

openclaw browser create-profile --name chrome-live --driver existing-session

11. 创建远程 CDP profile

openclaw browser create-profile --name remote --cdp-url https://browser-host.example.com

12. 删除 profile

openclaw browser delete-profile --name work

官方文档也说明，profile 删除时，本地数据目录会被移动到垃圾桶；本地 openclaw profiles 会自动分配 CDP 端口 / URL，通常只有远程 CDP 才需要手动设置。(OpenClaw)

十二、配置层面要注意什么？

1. 如果 `openclaw browser` 命令不存在

可能是 browser 插件没有启用。

官方文档说明，如果 openclaw browser 是 unknown command，要检查 ~/.openclaw/openclaw.json 里的 plugins.allow；当使用限制性插件 allowlist 时，需要显式加入 browser，除非已经有 root browser 配置块。(OpenClaw)

可以加：

{
  "plugins": {
    "allow": ["telegram", "browser"]
  }
}

如果你不是 Telegram，而是飞书、微信，就把对应 channel 换成自己的。

比如：

{
  "plugins": {
    "allow": ["browser", "feishu", "openclaw-weixin"]
  }
}

2. 如果 agent 看不到 browser 工具

官方文档提醒：tools.profile: "coding" 包含 web_search 和 web_fetch，但不包含完整 browser tool；如果 agent 或 sub-agent 要用 browser automation，需要在工具策略里显式加 browser。(OpenClaw)

示例：

{
  "tools": {
    "profile": "coding",
    "alsoAllow": ["browser"]
  }
}

单个 agent 可以这样：

{
  "agents": {
    "list": [
      {
        "id": "main",
        "tools": {
          "alsoAllow": ["browser"]
        }
      }
    ]
  }
}

这点很关键。

很多人以为模型不行，其实是工具没给它。

十三、容易踩的坑

坑一：以为新 tab 就是新 session

不是。

新 tab 只是页面分开。

真正隔离至少有三层：

隔离层	解决什么
新 tab	页面分开
新 browser profile	登录状态、cookie、缓存、任务现场分开
新 OpenClaw session	对话上下文、任务记忆分开

所以你要另跑一个任务，最稳的是：

新 OpenClaw session + 新 browser profile。

坑二：用 `user` 但 Chrome 没开 tab

官方故障排查文档说，如果出现 No Chrome tabs found for profile="user"，说明你在使用 existing-session / Chrome MCP profile，OpenClaw 能看到本地 Chrome，但没有可附加的 open tab。修复方式是用 managed browser，或者确保本地 Chrome 至少有一个打开的 tab，再用 --browser-profile user。(OpenClaw)

命令：

openclaw browser --browser-profile openclaw start

或者先手动打开 Chrome 一个标签页，再：

openclaw browser --browser-profile user tabs

坑三：服务器环境没有图形界面

官方 CLI 文档提到，在没有 DISPLAY 或 WAYLAND_DISPLAY 的 Linux host 上，本地 managed profiles 会自动 headless 运行，除非显式关闭 headless。(OpenClaw)

所以 Linux 服务器上看不到浏览器窗口，不一定是错误。

它可能是在 headless 模式运行。

坑四：browser 插件没启用

命令不存在、agent 说 browser unavailable，多半是插件、工具策略或配置 allowlist 问题。

先查：

openclaw browser --help

再查配置：

cat ~/.openclaw/openclaw.json

重点看：

{
  "plugins": {
    "allow": ["browser"]
  }
}

以及：

{
  "tools": {
    "alsoAllow": ["browser"]
  }
}

十四、给你的最佳实践：按任务类型设计 profile

1. 日常研究

openclaw browser create-profile --name research
openclaw browser --browser-profile research open https://www.google.com

适合：

行业研究；
资料搜集；
报告截图；
页面 PDF 留证。

2. 客户项目

openclaw browser create-profile --name client-jurui
openclaw browser create-profile --name client-zhongqi

适合：

不同客户系统隔离；
不同资料来源隔离；
不同登录态隔离。

3. 课程演示

openclaw browser create-profile --name demo

适合：

直播；
线下课；
企业内训；
AI 工作流演示。

4. 后台系统测试

openclaw browser create-profile --name test
openclaw browser --browser-profile test open http://localhost:3000

适合：

本地开发；
表单测试；
页面截图；
bug 复现。

5. 真实登录账号

openclaw browser --browser-profile user tabs

适合：

你已经登录的 Chrome；
需要人工扫码/二次验证；
不能把账号密码交给模型的系统。

但记住：

真实账号场景，要让 AI 少做高风险动作。发布、删除、付款、提交审批、修改权限，一律人工确认。

十五、最推荐的工作流

第一步：先用独立 profile

openclaw browser --browser-profile openclaw doctor
openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw open https://example.com

第二步：需要分任务时，新建 profile

openclaw browser create-profile --name report
openclaw browser create-profile --name demo
openclaw browser create-profile --name client-a

第三步：需要登录态时，人工登录

openclaw browser --browser-profile client-a open https://client-backend.example.com

你手动登录。

然后再让 OpenClaw 操作。

第四步：需要真实 Chrome 登录态时，再用 `user`

openclaw browser --browser-profile user tabs

第五步：任务结束后清理

openclaw browser --browser-profile report stop

不再需要的 profile：

openclaw browser delete-profile --name old-task

十六、它和 session 的关系

这个地方最容易混。

browser profile 管浏览器环境

它管的是：

tab；
cookie；
登录态；
浏览器缓存；
浏览器数据目录；
CDP 连接；
是否接管真实 Chrome；
是否远程控制浏览器。

OpenClaw session 管对话上下文

它管的是：

你前面说过什么；
agent 记住了什么；
当前任务目标；
任务上下文；
历史消息。

所以：

新 browser profile ≠ 新 OpenClaw session
新 OpenClaw session ≠ 新 browser profile

真正不冲突的做法：

一个新任务 = 一个新 OpenClaw session + 一个明确 browser profile

比如：

session: 学生咨询建议任务
browser profile: student

session: 行业报告资料搜集任务
browser profile: report

session: 课程演示任务
browser profile: demo

这样才稳。

十七、一句话讲透

openclaw browser --browser-profile 的本质，是把浏览器从“你的私人操作界面”，变成“AI 可控、可隔离、可复现、可分工的任务现场”。

它解决的核心痛点是：

AI 要操作网页，但不能乱动你的私人浏览器；AI 要使用登录态，但不能拿你的密码；AI 要同时跑多个任务，但不能互相串台；AI 要做真实业务，但必须有可控的浏览器工作区。

所以，对你这种重度使用 OpenClaw、Codex、Claude Code、opencode、deepseek-tui、Hermes 的人来说，--browser-profile 不是一个小参数。

它是 OpenClaw 从“聊天助理”走向“业务执行智能体”的关键开关。

最实用的一句话：

公开网页用 openclaw，多任务用自定义 profile，必须真实登录才用 user，长期自动化用 remote CDP。

我让小龙虾帮我写一个 mac 应用，实时翻译屏幕上我选中的英文

Sun, 24 May 2026 17:51:29 +0800

我问：

我现在要做一个在我本机运行的捕捉屏幕上英文并连接大模型的应用，这个提供配置入口即可，让我能够实时看到：“简单英语”（通常指基本英语 (Basic English)）的发明人是英国语言学家和哲学家查尔斯·凯·奥格登 (Charles Kay Ogden)

这种英语的翻译，让我秒懂。并且能够自动写入到 obsidian 中间去。如果同样的单词或者句子多次选中，那就在 obsidian 里记录下选中的时间，并显示选中次数，以此来反应我学习的进度。

你现规划下怎么做。

小龙虾答：

规划：ScreenEn → 秒懂英文 + Obsidian 学习追踪

核心流程

选中英文 → 快捷键触发 → 剪贴板捕获 → LLM 翻译 → 浮窗秒懂展示 → 自动写入 Obsidian

五个模块

1. 文本捕获（Capture）

全局快捷键触发（默认 Cmd+Shift+T，可配置）
触发后模拟 Cmd+C，读取剪贴板内容
备选方案：macOS Accessibility API 直接读取选中文字（更优雅但跨应用兼容性差，先用剪贴板方案）

2. LLM 翻译（Translate）

可配置项：API Endpoint、API Key、Model Name、自定义 Prompt
默认 Prompt 方向：不是逐字翻译，而是用最直觉的中文让用户秒懂
短词→给释义+一句话场景理解
长句→给中文意译+关键结构拆解

3. 浮窗展示（Overlay）

macOS 原生浮动窗口，置顶显示在屏幕右下角或光标附近
翻译结果停留 5-8 秒自动消失（可配置），鼠标悬停可保持
之前的结果可通过 menubar 图标历史记录回看

4. Obsidian 写入（Vault Writer）

每个单词/短语/句子对应 vault 里一个 markdown 文件
文件名：英文原文的 slug 形式（如 ubiquitous.md）
首次：创建文件，写入释义、简单理解、选中时间
重复选中：追加时间戳，更新计数，不覆盖已有内容

Obsidian 文件结构示例：

vault/ScreenEn/
  ubiquitous.md
  it-is-what-it-is.md
  _dashboard.md        ← 学习进度总览

单个文件内容：

---
text: "ubiquitous"
type: word
count: 5
first_seen: 2026-05-24T10:30:00+08:00
last_seen: 2026-05-24T17:45:00+08:00
---# ubiquitous## 秒懂到处都有，无处不在## 场景理解形容某个东西太常见了，到处都能碰到## 学习记录- 2026-05-24 10:30 — 第1次- 2026-05-24 11:15 — 第2次- 2026-05-24 17:45 — 第5次

5. 配置界面（Config UI）

macOS menubar 常驻图标，点击弹出配置面板
配置项：

LLM API Endpoint / Key / Model
翻译 Prompt 模板
Obsidian Vault 路径
快捷键
浮窗显示时长
最小捕获长度（避免误触发）

技术选型

层	选择	理由
语言	Python 3	你 Mac 上直接跑，配置灵活，LLM 调用方便
Menubar + 浮窗	rumps + PyObjC	原生 macOS menubar 应用，浮窗用 NSWindow
全局快捷键	pynput 或 PyObjC CGEvent	跨应用全局监听
LLM 调用	httpx	支持流式，OpenAI 兼容接口
Obsidian 写入	标准文件 I/O	Obsidian 就读 markdown，直接写文件
配置存储	YAML 文件	人工可读可改

目录结构

screenen/
  app.py              ← 入口，menubar 应用
  capture.py          ← 快捷键监听 + 剪贴板读取
  translator.py       ← LLM 调用 + Prompt 管理
  overlay.py          ← 浮窗展示
  vault.py            ← Obsidian 文件读写 + 计数追踪
  config.py           ← 配置加载/保存
  config.yaml         ← 默认配置
  requirements.txt

启动方式

python screenen/app.py# menubar 出现图标，后台监听快捷键，随时可用

需要你确认的点：

Obsidian vault 路径 — 你 vault 在哪个目录？
LLM — 你想接哪个？OpenAI 兼容接口？还是本地模型？
浮窗位置 — 右下角固定，还是跟光标走？
要不要 dashboard — Obsidian 里放一个 _dashboard.md 汇总高频词、学习趋势？