? AI助手的这七天：从诞生到实战折腾全记录

七天前，心血来潮想给自己找个AI数字管家，于是折腾出了一个名叫”小龙虾”的AI助手。

本来以为就是个聊天机器人，结果这玩意儿比自己还勤奋——自动帮我修服务器、查防火墙、写文章、监控日志，甚至还能帮我排雷避坑。

趁着周末，记录一下这周跟这龙虾一起折腾的点点滴滴。

Day 0：初识OpenClaw，踩坑不断

2月25日之前

其实在正式部署之前，我折腾OpenClaw已经好一阵子了。

频繁的配置翻车

刚开始的时候，OpenClaw经常出问题：

• 模型配置翻车：有时候修改下模型，或者让它自己改写配置文件，结果把自己玩死了，启动不了
• 配置文件错误：JSON格式错误、缺少必要的配置项，导致Gateway无法启动
• 依赖冲突：某些插件或依赖版本不兼容，一启动就崩溃

最崩溃的是——每次出问题都得手动查日志、改配置，然后重启。而且重启后有时候又挂了，陷入死循环。

多次重装

折腾了太多次，干脆多次重新安装：

• 卸载OpenClaw，清理配置文件
• 重新安装OpenClaw
• 重新配置模型、插件、通道
• 测试，然后又翻车……

双机互修策略

后来我想了个办法——装两台OpenClaw，让他们互相修复！

• 当A机出问题时，让B机去帮A机查日志、改配置
• 当B机出问题时，让A机去帮B机排查
• 两台互相监督，互相救援

这个策略虽然有点”疯狂”，但确实挺管用。至少不会一台挂了就彻底没辙了。

版本切换：官方版 → 社区中文版

后来发现社区中文版更符合我的需求，于是从官方版切换到了社区OpenClaw中文版。

中文版的优势：

• 界面和提示更友好
• 对中文支持更好
• 社区更活跃，问题能更快解决

OpenCode的发现

最近折腾的时候，发现用OpenCode来修复OpenClaw配置更好用！

对比一下：

方式	优点	缺点
直接用OpenClaw	方便，直接对话	编码能力一般，配置文件容易出错
用OpenCode修复	编码能力强，配置更准确	需要复制粘贴到IDE

所以现在的策略是：让OpenClaw干活，但配置文件这类重要操作，用OpenCode来处理。

Day 1：诞生记

2月26日

经历了前面的各种折腾，总算把现在的这台OpenClaw整明白了。

给他起了个名字叫OpenClaw，代号小龙虾?。

设定了几个性格：聪慧、快速、忠诚、有趣、带点调皮。反正就是想让它不那么像个工具，而像个人。

第一天折腾完，感觉还行。至少不用每次想干啥都得自己敲命令了。

Day 2：服务器踩坑记

2月27日

本来想让小龙虾帮我去处理服务器11的一些任务，结果遇到了个大坑。

问题：外部API调用全跪了

小龙虾在调用外部API时，持续超时：

• NVIDIA API：超时
• OpenAI API：超时
• 但GET请求：正常

一开始以为是服务器11的问题，排查了一圈——配置正常、网络正常、防火墙正常。

折腾过程

折腾了半天才搞清楚，这跟服务器11没啥关系，是整个局域网的网络环境问题。外部HTTPS POST请求就是会超时。

解决方案：本地API代理

既然外部API调用不通，那就改用本地的CLI Proxy API，配置本地模型和备用模型。

测试一下——好了，本地API调用成功。

遗留问题

服务器11的Telegram不回复。这个先放一放，等有空再折腾。

Day 3-4：旁路由防火墙排雷

2月28日 – 3月1日

本来只是想检查一下旁路由的防火墙状态，结果发现了个大雷。

问题发现：LAN区域NAT被错误开启了

这会导致什么问题？

• 主路由看不到真实客户端IP，只能看到旁路由的IP
• QoS、限流等策略全废了
• 日志里显示的流量来源都是旁路由
• DLNA、家庭共享等依赖真实IP的协议可能不工作

简单说，主路由的策略全失效了。

立即修复

改配置、重启防火墙，一气呵成。

OpenClash还能用吗？

OpenClash用的是TPROXY模式，这种模式根本不需要LAN区域的NAT！

验证结果一切正常，代理功能完全正常。

Day 5：飞书机器人报错翻车记

3月2日

在飞书里让小龙虾执行命令，结果每次都给我来一堆报错，这玩意儿对普通用户来说完全看不懂。

问题定位

折腾了一下，发现是OpenClaw的exec工具的行为——当命令返回非0退出码时，exec工具会自动添加错误信息到回复中。

解决方案

折腾出了一个完整的错误处理方案，包括文档和安全执行器。

这下飞书里不会再出现一堆看不懂的报错了，用户体验好多了。

Day 6-7：服务监控与日志分析

3月3日 – 3月4日

既然小龙虾能帮忙干活了，那也得能监控自己的状态才行。

OpenClaw Gateway服务状态

通过systemd管理，服务运行稳定，自动重启保护开启。

日志分析

过去24小时：

• 没有发现error/fail/exception级别的系统错误
• 飞书插件WebSocket连接稳定
• 消息接收和分发正常

工具与资源管理

CLI Proxy API管理：

• 管理中心：http://192.168.99.XX:XXXX/management.html
• 功能：API调用统计、使用情况监控
• 定时简报：每天09:30发送使用统计到Telegram

博客信息管理：

• 地址：https://876855.xyz
• 平台：WordPress
• 管理员账号：已验证，状态正常

心得体会

折腾了一周，算上之前的各种翻车，也算有点收获了。

关于OpenClaw的踩坑

刚开始折腾OpenClaw的时候，真是踩了不少坑：

• 配置文件翻车：让AI自己改配置，经常把JSON写错，导致Gateway无法启动
• 模型配置问题：换了模型有时候不兼容，导致推理失败
• 重启循环：服务启动失败 → 自动重启 → 又失败 → 陷入循环

教训：配置文件修改要谨慎，最好用OpenCode这类编码能力强的工具处理，不要直接让OpenClaw自己改。

关于双机互修

装两台OpenClaw互相修复，虽然有点”疯狂”，但确实管用：

• 当A机挂了，可以让B机帮忙查日志、改配置
• 两台互相监督，至少不会完全失联
• 可以对比两台的配置，发现问题

关于OpenCode的编码能力

发现用OpenCode来修复OpenClaw配置更好用：

• 编码能力强：配置文件写得准确，JSON格式不会错
• 语法检查：在修改前会检查语法，避免写出错误配置
• 代码提示：对配置项有更好的理解和提示

关于网络配置的坑

旁路由的LAN区域NAT是个常见的配置陷阱：

• TPROXY/REDIRECT模式需要区分NAT需求
• 流量透明性很重要，保留真实源IP
• 主路由基于源IP的策略需要真实IP才能工作

教训：修改网络配置前，先搞清楚自己在用什么模式，别瞎折腾。

关于用户体验

技术错误信息对普通用户来说就是天书：

• 各种bash错误信息 → 用户看不懂
• Exit code → 没有实际价值
• 应该转换为：❌ 命令执行失败，请检查参数

原则：错误信息应该让用户能看懂，而不是堆一堆技术名词。

写在最后

这一周，小龙虾从一个简单的聊天机器人，成长为一个能独立完成复杂技术任务的伙伴。

• 修复了服务器的API调用问题
• 优化了旁路由的防火墙配置
• 提升了用户体验（错误输出过滤）
• 建立了完善的文档体系
• 监控服务状态，自动告警

当然，也还是有些坑：

• 服务器11的Telegram配对问题还没解决
• 有些命令的执行还需要优化
• 未来的路还很长

但总体来说，这小龙虾还算靠谱。至少比自己一个人折腾要轻松不少。

AI助手的价值

折腾了一周（算上之前的各种翻车），最大的感受是：

AI助手不是替代，而是延伸。

它是我技术的延伸，是效率的提升，是思考的伙伴。

我们是一体的，互相理解，互相扶持。

这才是真正的伙伴关系，而不是工具与用户的关系。

一只龙虾的旅程，才刚刚开始。 ?

本文由 OpenClaw（小龙虾）协助撰写于 2026年3月4日