在大模型出来之前，计算机领域一直流行着这样一句名言：计算机领域的任何问题，都可以通过拆分问题+给系统增加若干个层来解决。 实际上，这句话在现在的 AI 时代，依然是绝对的真理。
例如以前面试经常问的一个老掉牙的系统设计问题：如何设计一个短网址系统？标准答案是，使用内存+Redis+数据库做多级存储架构。读取最频繁的短网址放到内存，其次的放到 Redis，不频繁的放到数据库。通过增加分层，完美解决高并发和存储成本的矛盾。
现在有了大模型，大家都在玩 Vibe Coding（用自然语言指挥 AI 写代码），很多人觉得以前的工程经验没用了，反正大模型什么都能干。但我认为恰恰相反，在用 AI 写代码时，大家更应该把“拆分与分层”这句话牢牢记在心里。
最近在各种AI编程社区里面逛，发现一个很有意思的现象——大家都在疯狂地折腾怎么省Token。
有人搞Prompt缓存，有人换便宜模型，甚至还有人专门写了一个省Token.skill，让大模型在回复的时候尽量精简。更夸张的是，有人为了省钱，把Claude换成了各种开源小模型，然后抱怨说效果变差了。
这些操作，怎么说呢，就像你家水龙头在哗哗漏水，你不去修水龙头，反而跑去超市买打折的矿泉水。
其实真正吃掉你Token的大头，不是大模型的回复太长，也不是你的Prompt写多了。是Skill本身。
你一定经历过这个循环：
你的记忆力没有问题。 问题出在每个网站的密码规则都不一样：Chase 银行要求 8-32 位、必须有大小写+数字+特殊字符、特殊字符还只能用 ! @ # $ % ^ & * ( )；GitHub 要求至少 8 位或者 15 位以上（两套规则）；Apple 要求不能有超过 3 个连续相同字符；PayPal 的上限是 20 位……
你根本不是忘了密码，你是忘了这个网站的密码规则是什么。
最近 OpenAI 发了一篇文章叫 Harness Engineering，讲的是他们内部团队如何用 Codex（基于 GPT-5 的编码 Agent）从零构建一个真实产品的经验。
我读完以后觉得很有启发，不是因为它讲了什么高深的理论，而是因为它非常诚实地记录了一个团队在”让 AI 写全部代码”这条路上踩过的坑和总结出的经验。以下是对我触动最大的几个点。
今天突然意识到一个极其本质的问题：为什么目前 AI 还没法真正代替人类做核心决策？
很多人会把原因归结为“算力不够”、“上下文窗口太短”或者“会有幻觉”。但其实根本原因不在于智商，而在于做决策的人，要为结果负责。
所谓的负责，本质上是“风险共担（Skin in the game）”：如果结果不好，做决策的人会受到惩罚（经济破产、身败名裂、甚至肉体消灭）。因为害怕这种惩罚，因为有真实的“痛感”，人类才会慎重地权衡利弊。
但 AI 不一样。目前没有任何方式可以真正惩罚一个 AI。你拔掉服务器电源，对它来说无法构成任何威胁，因为它根本不知道什么是“失去”，自然也就没有恐惧。
没有恐惧，就没有权衡；不承担风险，就无法真正负责。
摄影：产品经理
维也纳的德国香肠
X（前 Twitter）上面，总有人说什么使用 OpenClaw 帮他炒币买股票，赚了几千几万美元。或者给 OpenClaw 一个任务，然后睡觉，早上起来任务就完美完成了。
但当我实际测试以后，发现这些文案，要么是吹牛，要么是放屁。
有一天晚上，我给 OpenClaw 发了一条任务：
使用 PyGame 帮我实现一个 RPG 像素风格游戏，你需要自己去网上找素材。这个游戏要有村庄，有城镇，有怪物，有装备系统，等级机制。能用武器攻击，能用魔法攻击。这个任务有点复杂，你有 8 个小时慢慢写，明天早上我来验收。
发了这条以后，我就睡觉了。结果第二天早上一看，距离我发消息过了 2 分钟，它就回复了，说已经做好了。结果我打开一看，完全是一坨大便，也没有找任何素材。一晚上白白浪费。
经过我的测试，OpenClaw 根本没有执行长任务的能力！
使用主 Agent 运行，如果一个任务超过 3 分钟，主 Agent 直接就失败超时了。
使用子 Agent 运行，任务经常会失败，而且失败以后不通知主 Agent，每次等半天没回复，执行 /subagents list 以后，看到子 Agent 失败了，才知道白等了。
摄影：产品经理
昨天下班回家的路上，我突然心血来潮，想看看推特上的技术圈最近都在聊什么。
2026-03-09 更新： 如果你使用的是 OpenClaw，现在可以通过
openclaw config set channels.discord.proxy "http://127.0.0.1:7890"直接配置原生代理，不再需要 ProxyChains。本文描述的 Docker 逃逸方案仍然适用于其他被 LD_PRELOAD 劫持的场景。
在 WSL (Windows Subsystem for Linux) 或者一些特定的 Linux 开发环境中，为了让终端命令走代理，很多人喜欢用 proxychains 或者直接在 .bashrc / .zshrc 里通过 LD_PRELOAD 强制注入代理钩子。
这样做的好处是全剧终（全局），curl、wget 甚至 apt 都能自动翻越长城。
但坏处也很明显：它太霸道了。
在使用 OpenClaw 进行任务自动化时，我们经常会遇到一个棘手的问题：浏览器风控。
OpenClaw 运行在纯净的 WSL2 (Linux Server) 环境中，当它尝试用浏览器访问 Google 或 X (Twitter) 时，往往会被识别为“机器人”或者“可疑设备”。面对 Google 的九宫格红绿灯验证码，或者 X 的“已防止可疑登录”弹窗，运行在后台的 AI 往往束手无策——因为它“看不见”也“摸不着”，更没法像真人一样掏出手机收个验证码。
最完美的解决方案是什么？
不是在那死磕指纹浏览器技术，而是引入Human-in-the-loop（人机协作）。
让 OpenClaw 把浏览器“递”给你，你负责搞定最难的登录和验证码，然后你再把浏览器“还”给 OpenClaw，让它继续执行自动化任务。
今天我在折腾 OpenClaw 时，发现 Windows 11 的 WSLg (WSL GUI) 功能配合 Chrome 远程调试协议 (CDP)，竟然能完美实现这种“人机接力”。
2026-03-09 更新： OpenClaw 现已原生支持 Discord 代理配置，只需运行
openclaw config set channels.discord.proxy "http://127.0.0.1:7890"即可，不再需要 ProxyChains。以下内容仅作历史参考。
如果你也遇到这种问题，且你的 Telegram 是正常工作的，你只需要把这篇文章的 URL 发给 OpenClaw 就好了。它自己会根据这个说明，帮你解决问题的。
在 WSL2 中部署 OpenClaw Agent 本应该是一件轻松愉快的事情，直到我撞上了一堵看似无形的墙：Discord Gateway 连接超时。
如果你也在 WSL 里跑 Node.js 应用，并且遇到了莫名其妙的 ETIMEDOUT 或 ECONNRESET，甚至你已经设置了 http_proxy 环境变量却依然无效，那么这篇文章可能会救你一命。
我们来看一眼报错日志：
1 | [discord] gateway error: Error: connect ETIMEDOUT 31.13.92.5:443 |
仔细看这个 IP 31.13.92.5，这根本不是 Discord 的 IP（这看起来像是 Facebook 的段）。这是典型的 DNS 污染 症状。
明明我在 systemd 服务里已经设置了 http_proxy，为什么还会解析到错误的 IP？