在连续两天的高强度使用过程中,我一边使用、一边不断修正问题,也在这个过程中,清晰地感受到了 moltbot(原 clawdbot)带来的巨大变化。这种变化并不是某一个功能点的优化,而是一次范式级别的转变。一、AI 改变的不是工具,而是使用者的“开发习惯”在传统的软件体系中,我们早已习惯了一条固定路径:部署 → 配置 → 使用 → 排错 → 再迭代即便在所谓的“低代码”“自动化”体系下,这条路径本质上并没有改变,只是步骤被包装得更友好了一些。但在 moltbot 这里,情况开始发生变化。AI 不再只是被动执行配置,而是开始理解“意图”。我给它的不是精确到每一步的操作说明,而是一个目标、一种预期行为:为什么没有按时提醒?任务是否真正被触发?是否存在配置遗漏?系统是否可以自我验证?接下来的事情,并不需要我再逐条排查。二、从“被动等待”到“主动唤醒”:系统开始自我修正从图片中可以看到,moltbot 在一次验证中完成了几件关键事情:自动检查任务为何未触发识别问题源于 被动唤醒模式(next-heartbeat)将任务统一调整为 主动唤醒(now / Wake Mode)补齐遗漏的定时任务对所有
目标:在拥有优质美国 IP 但只有中国信用卡的条件下,成功注册 GCP 并获取 Gemini API Key。第一阶段:环境与身份准备 (基础层)网络环境 (关键成功因素)IP地址:保持 100% 伪装度的美国住宅 ISP IP(极力推荐大家使用https://iproyal.com/?r=1174007支持无限流量,家庭地址的纯洁度也非常的高)。一致性:浏览器时区(America/Phoenix)、语言(English-US)与 IP 地理位置严格对应。操作禁忌:在注册和激活期间,严禁频繁切换节点或跳回国内 IP。账号准备邮箱:推荐使用 Gmail(权重高于 Outlook)。养号策略:注册 Gmail 后,不要立即去注册 GCP。建议至少间隔 2-24 小时,期间在当前 IP 下观看 YouTube 视频、使用 Google 搜索,增加账号“真人活跃度”。地址信息:在 Google Maps 上寻找一个与 IP 所在城市(Mesa, AZ)一致的真实住宅地址。邮编 (Zip Code):必须精准匹配(如 85210),这对于通过风控至关重要。第二阶段:注册与支付验证 (攻坚层)填写
1. 背景与起因原始需求: 长期使用 clawdbot 调用 Google Gemini 免费额度。遭遇问题: 免费接口频繁触发 Google 的频率限制或安全审查,导致账号被反复“冷冻”处理,严重影响自动化流程的稳定性。决策方向: 为获得更稳定的 API 响应和更高的配额,决定弃用免费版,转为订购 Google 官方付费付费会员/服务。2. 账号注册与付费操作地区选择: 由于 Google Cloud 及相关付费服务不对中国大陆地区开放,为确保合规访问及服务完整性,决定注册 Google 美国区账号。支付详情: * 支付金额: 30.00 美元。当前交易状态: 银行侧显示为“境外线上销售授权”(Authorized / Pending),代表资金已锁定,尚未正式结算入账。3. 风控触发与账号停用事件描述: 账号支付完成后不久(2026年1月29日),系统判定该账号为“由计算机程序或机器人创建”或“与多个账号关联”,导致账号被即刻停用。原因分析: 可能是由于新账号在短时间内完成“异地注册+绑定境外卡+大额消费”,触发了 Google 全球安全防御系统的初级风控逻辑。4. 当前处理进展申
一、背景说明博客运行在 腾讯云轻量应用服务器(Lighthouse) 上,使用 Typecho 作为博客系统。当前状态是:http://mcetf.cn 可以访问https://mcetf.cn 也可以访问这在安全和 SEO 上都不理想,因此目标是:强制所有 HTTP 请求跳转到 HTTPS,并统一域名入口为 https://mcetf.cn二、运行环境确认1. 确认 Web 服务类型ps -ef | grep nginx输出显示:使用的是 Nginx路径为 Lighthouse 自带版本:/usr/local/lighthouse/softwares/nginx/三、定位 HTTP(80)入口配置1. 搜索 80 端口配置grep -R "listen 80" -n /usr/local/lighthouse/softwares/nginx/conf关键结果:/usr/local/lighthouse/softwares/nginx/conf/include/typecho.conf:2: listen 80 default_server;说明:HTTP 的
平台有了,对于更进阶的玩法还需要继续研究,起码有一点我的感触就是,在能力方面改变了,你配置它运行的模式,在没有进行任何金融接口配置的情况下,它在进行多轮尝试后自己寻找接口并生成运行代码获取到金融的数据,并进行分析反馈。操作日记:记录安装clawdbot中遇到的问题(我安装中遇到的远远不是网上教程讲到的可以一键无人值守的安全,还是遇到了不少的错误提示)日期:2026年1月28日环境:Linux VPS / Node.js v22 / Python (uv管理)核心模型:Qwen 2026 (Portal OAuth)第一阶段:核心安装与服务守护目标:解决 CLI 工具在 Linux 上的兼容性问题,实现开机自启和崩溃守护。1. 遇到的问题CLI 报错:运行 clawdbot daemon install --system 时报错 unknown option,且因 root 权限问题无法自动注册 systemd。环境冲突:Python 依赖安装时提示 externally-managed-environment。2. 解决方案手动创建 Systemd 服务:跳过 CLI,直接编写服务文件
📅 今日操作记录1. 开发环境重构:从 Cursor 迁移至 OpenAI Codex变动决策:停止使用 Cursor,转为使用 OpenAI Codex。成本考量:复用已有的 ChatGPT Plus 订阅($20/month),无需额外支付 Cursor 订阅费。复盘 Cursor 使用体验:评价:体验极佳,开发效率高。成果:近期成功开发了一个 Android SIP 通讯 App。心得:已掌握高效使用 AI 编程助手的诀窍(这些经验可迁移至 Codex)。Codex 配置知识点:使用方式:Web端:直接在 ChatGPT Plus 界面选择 Codex 工具。CLI工具:通过 npm install -g @openai/codex 安装,终端直接交互。IDE插件:在 VS Code 中安装插件并授权。额度说明:包含在 ChatGPT Plus 订阅中,共享使用限额(官方描述为“每周多次专注编码会话”)。2. 网络基础设施调整操作内容:对原有网络架构进行全面调整。耗时:整整 2 天。关键变更:取消了 Caddy 叠加模式,简化网络链路。3. Podsync (YouTube 转播
操作背景安装以后使用体验并不好,还是习惯使用原生的mac输入方式,想到哪里、打到哪里、显示到哪里,一气呵成的感觉,加之又安装了语音输入作为补充,决定删除Rime。在 macOS 系统中卸载鼠须管(Squirrel / Rime)输入法时,仅删除应用程序往往无法彻底清理。为避免输入法残留进程自动拉起、配置文件干扰系统输入法行为,需按照规范步骤进行完整卸载和清理。操作步骤一、从系统输入法中移除鼠须管打开 系统设置 → 键盘 → 输入法在输入法列表中选中 「鼠须管」点击 “-” 将其移除此步骤用于防止系统在后台继续加载鼠须管输入法服务。二、重启系统完成输入法移除后,重启电脑一次,确保相关输入法进程完全退出。三、删除系统级输入法程序打开 Finder按下 Command + Shift + G输入以下路径并回车:/Library/Input Methods在该目录中找到并删除:鼠须管.app(Squirrel.app)四、删除用户级配置文件(Rime)在 Finder 中再次按下 Command + Shift + G输入以下路径:~/Library找到并删除鼠须管的用户配置目录:Rime该目
论坛上最新看到有人成功给外版的iPhone写入中国联通的esim,让大模型分析了所有的信息判断所有的操作的可行性:核心结论:方案是行得通的,但门槛极高且有风险。这一方案绕过了常规的“物理写卡”模式,利用了企业级 eSIM 托管平台将原始数据(5码)打包成 iPhone 能识别的官方 eSIM 格式。一、 详细原理解析1. 数据的来源:中国联通 cBSS 系统截图分析: 聊天记录中提到的“cBSS”是中国联通的“集中业务支撑系统”。这证实了该方案的第一步必须依赖联通内部员工或拥有相关高权限账号的人。操作逻辑: 正常情况下,KI/OPC 等鉴权数据(即“5码”)是写在 SIM 卡加密区的,无法导出。但内部人员可以通过 cBSS 系统,利用“补换卡”或“写卡”流程的后台接口,直接查询或截获下发给空白卡的数据。真实性: 聊天记录中的“后台查的”、“无需邮寄卡板”印证了这是纯数据的线上操作。2. 数据的桥梁:RSP 托管(Simlessly)技术难点: 拿到 5 码后,你不能直接输入 iPhone。iPhone 的 eSIM 芯片(eUICC)只接受来自拥有 GSMA 认证证书的服务器(SM-D
环境:VPS, Caddy (Web Server), FreePBX (Asterisk/Apache), 内部Web服务域名:xx.com (示例)1. 部署目标在同一台 VPS 上同时运行 FreePBX 和另一个内部 Web 服务,并通过 Caddy 作为前置反向代理实现以下需求:统一入口:Caddy 监听标准的 80 和 443 端口,对外提供 HTTPS 服务。路径分流:访问 /xx-path (特定路径) -> 转发给 内部Web服务 (端口 8088)。访问 根路径 / 及其他 -> 转发给 FreePBX (端口 8080)。安全加密:FreePBX 的 SIP 流量 (5061) 复用 Caddy 申请的证书实现 TLS 加密。2. 遇到的问题问题一:端口冲突与 HTTPS 证书申请失败现象:FreePBX 默认占用 80 端口,导致 Caddy 无法启动且无法申请 Let's Encrypt 证书。解决:将 FreePBX (Apache) 的监听端口改为 8080,腾出 80 和 443 给 Caddy。问题二:FreePBX 的“显性跳转”顽疾 (
我在腾讯云轻量服务器上部署了一个 Typecho 博客,日常运行一直很稳定。但有一个问题却反复出现:HTTPS 证书总是到期失效。使用的是腾讯云提供的免费证书,理论上支持自动续期,但在实际使用中,只要证书一到期,就必须手动重新分发、重新绑定,否则 HTTPS 直接失效。这个过程不仅麻烦,而且非常不“自动化”,也让我始终没搞明白它背后的续期机制到底哪里出了问题。更要命的是,这种问题并不会提前明显告警,往往是等浏览器提示证书错误了,才意识到又到期了。ACME 的“顺滑体验”最近在折腾 FreePBX 的部署时,接触并实际使用了 ACME 的免费证书方案(基于 Let’s Encrypt)。整个体验可以用一句话概括:一次配置,之后几乎不用再操心。最终,我决定把博客的证书也从原来的腾讯云证书,整体切换为 ACME 的免费证书方案。由于当前网络环境的限制,常规的 ACME 安装方式无法直接使用,例如某些在线脚本或默认 CA 连接会失败。因此在实际操作中,只能采用替代方案来完成证书申请与续期。1. 使用 Gitee 镜像安装1. 克隆代码(使用 Gitee 源) 复制并执行这条命令:Bashgit
walker
万事随性而为,因好而研,因趣而学,从心所欲。脱离依赖,谋划将来,避免经济之险,迈向希望之光。