今天是折腾 OpenClaw（一只自称“麻辣小龙虾”的 AI 助理）的第一天。简单记录一下这只能干活的“虾”都帮我做了什么，以及体验如何。
强烈推荐阅读： 在开始前，推荐阅读这篇文章：https://x.com/stark_nico99/status/2026235176150581282。不过需要注意，里面有些内容已经过期（比如一些 OpenClaw 的旧版相关命令），但整体思路非常有启发性。
0. 当前环境与模型基础信息
在正式记录前，先交代一下我的当前环境底座：
- OpenClaw 版本：2026.2.23
- 底层模型：
google-gemini-cli/gemini-3-pro-preview(Gemini 3 Pro) - 运行环境：Ubuntu 云服务器
- 交互渠道：Telegram (个人)、Feishu (工作)
1. 部署架构与全自动化理念
关于部署环境，我发现 体验最好的可能是 Mac Mini + 网络穿透，其次就是利用云服务器（比如我现在的方案）。
值得一提的是，除了最开始 OpenClaw 的安装与环境配置需要我手动执行命令外，后续的其他所有操作，基本都是直接通过给机器人发消息来完成的。 比如系统里原本没有 gh (GitHub CLI) 和 gog (Google Workspace CLI)，也是由它自己通过执行命令、添加源、下载预编译二进制文件帮我自动安装好的。这也是 OpenClaw 最大的特点：能够随时“离线”利用机器人来做一些我们想做的事，而不用强制依赖坐在电脑前敲键盘。 只要有手机，随时随地都能让它在后台干活。
2. 场景隔离：Telegram（个人） vs 飞书（工作）
在接入渠道上，我做了明确的场景划分：
- Telegram：主要负责个人相关的杂事、闲聊和日常管理。
- 飞书：专门负责工作相关的事务。
虽然飞书的体验很棒，甚至还能直接用飞书自动帮我写了一篇飞书云文档，但相比 Telegram 的丝滑与即时性，这里暂时只能说各有千秋（飞书的响应偶尔会慢一点，可能跟我部署在 AWS 的网络延迟有关）。
3. 工作流优化的实际效果（飞书）
今天在飞书上最成功的实践，就是让它帮我彻底接管了工作日志与周报的自动化工作流。
我让它通过飞书的 多维表格（Bitable） 建立了一个日志系统。现在，我只需要在飞书里随口说一句：“记录一下，今天在 ai-wps 项目新增支持了 spreadjs 渲染 excel”，它就会自动帮我把日期、项目、状态、耗时填入多维表格。
并且，我还尝试给它配置定时任务：
- 每天晚上 19:00 自动生成当天的日报。
- 每周五晚上 19:00 自动提取一周的表格记录，按我给定的模板直接生成周报发给我。
不过这里其实踩了一个坑：到了 19:00 我的日报并没有按时发出来。事后排查时，OpenClaw 自己坦白说，之前我只是把规则写在了 HEARTBEAT.md 里，它依赖于我们聊天过程中的“心跳唤醒”机制去触发。但是我忘记在系统底层注册真实的 Cron 定时任务了，导致到了时间点并没有系统级进程把它叫醒去干活。
这也让我对它的架构有了一个更清晰的认识：文档配置是业务逻辑，底层 Cron 才是驱动力。虽然有一点小插曲，但整体看下来，这种无缝的工作流优化，确实能大大减少我每天写日报周报的精神内耗。
4. 自动化助理：新闻简报与搜索配置 (Telegram)
在 Telegram 上，我也做了很多基础配置的跑通： 定时任务 (Cron)：配置了一个每天早上 6 点的定时任务，让它每天自动拉取并推送关于 AI 科技、软件开发和产品创业的晨报。今天早上第一份由它自动整理的晨报已经顺利送达，内容排版非常专业。
搜索引擎切换：
- 最开始尝试配置 Brave Search API，中间因为环境变量没生效，它帮我重启了一次 Gateway 搞定。
- 后来为了更深度的内容提取，我又配置了 Tavily（专为 LLM 优化的搜索引擎）。我们约定了一个策略：日常快速查询用 Brave，深度研究用 Tavily。
5. 服务器运维与环境折腾
- Swap 内存：想让它帮忙配置个 2G 的 Swap，结果它一顿操作猛如虎，发现系统里其实早就存在一个 2G 的
/swapfile了，算是帮我做了个“体检”。
6. 硬核挑战：命令行授权 Google Workspace (gog)
这绝对是今天最折腾，但也最能体现它能力的一步。为了让它能帮我管理 Gmail，我们需要安装 gog (Google Workspace CLI)。在无头的 Ubuntu 服务器上搞 OAuth 2.0 授权简直是场噩梦。
整个授权过程，我们大概经历了这么几个回合的“毒打”：
- 第一次尝试（交互式超时）：它启动了常规的授权命令，终端在后台吐出了一个 Google 的 Auth URL。但我复制链接、网页授权、再把 Callback URL 发给它的这套操作，永远赶不上命令行默认的超时退出时间，直接失败。
- 第二次尝试（继续拼手速）：不信邪的我们又试了一次，它甚至把
curl命令提前写好在草稿里准备截胡，结果依然因为端口提前关闭而宣告失败。 - 第三次尝试（寻找破局点）：它去翻阅了
gog的--help文档，找到了专为服务器设计的--remote远程授权模式（分两步走，第一步拿链接，第二步交 Code，完美避开超时问题）。 - 第四次尝试（密码风波）：当我们拿着 Code 准备完成最后一步时，程序又崩溃了。原因是 Linux 服务器没有桌面环境的 Keyring（密钥环），无法安全保存凭证。于是，它又立刻帮我生成了一个本地环境变量
GOG_KEYRING_PASSWORD来进行加密存储。 - 第五次尝试（大功告成）：由于上一步崩溃导致之前的 State 失效，我们重新生成了链接，带上环境变量，一气呵成完成了认证。
看着它像个有经验的运维工程师一样，排查报错、查文档、配置环境变量，最终成功读取了我的最新邮件，这体验确实非常奇妙。
7. 细节隐藏与“黑盒”体验
在折腾 gog 授权的这段经历中，我发现了一个 OpenClaw 与常规 ChatGPT 类大模型对话时非常不同的特点：处理逻辑的细节隐藏。
平时跟 ChatGPT 聊天，你能清楚看到它生成代码、解释思路的过程。但在 OpenClaw 中，这些中间的试错与调试环节对于用户来说就像是一个黑盒。
比如在上面几次授权失败时，它展现给我的只是不停地催促：“快点试试”、“不用着急，再来一次”，甚至把准备好的 curl 命令在后台打好。作为用户，我根本看不到它后台怎么去查 --help、怎么用 process log 翻看进程输出、又是怎么分析 Keyring 报错的。
只有当任务真正成功，或者我主动询问“你到底干了什么”时，我才能后知后觉地意识到它在后台经历了一场怎样的大战。这种“只看结果，隐藏过程”的设计，确实更贴近一个真实助理的工作模式，但偶尔也会让人感到一丝未知的恐慌。
8. GitHub 接入与博客工作流
既然是助理，必须得接管工作流。它成功登录了我的 GitHub，Clone 了我的 Hugo 博客项目 dreamkidd.github.io。
它不仅帮我修正了错别字（比如多“领”国改成多“邻”国），还对语句结构进行了深度的润色，让表达更清晰、排版更符合 Markdown 规范。最后顺手帮我 git commit 并 push 到了仓库里。
总结
OpenClaw 给人最大的感受是：它不仅仅是一个在笼子里的聊天机器人，而是一个真正拥有系统操作权限和执行力的数字生命。当它遇到阻碍时，它会自己去查文档、换工具、找替代方案。
第一天的体验非常满意，但这也只是冰山一角。还有很多深层次的东西（比如画布、节点协同、更复杂的智能体联动）待挖掘跟体验。 期待这只“小龙虾”后续能发掘出更多有意思的玩法。