失败的折腾：Google账号处理与申诉跟踪记录

1. 背景与起因原始需求： 长期使用 clawdbot 调用 Google Gemini 免费额度。遭遇问题： 免费接口频繁触发 Google 的频率限制或安全审查，导致账号被反复“冷冻”处理，严重影响自动化流程的稳定性。决策方向： 为获得更稳定的 API 响应和更高的配额，决定弃用免费版，转为订购 Google 官方付费付费会员/服务。2. 账号注册与付费操作地区选择： 由于 Google Cloud 及相关付费服务不对中国大陆地区开放，为确保合规访问及服务完整性，决定注册 Google 美国区账号。支付详情： * 支付金额： 30.00 美元。当前交易状态： 银行侧显示为“境外线上销售授权”（Authorized / Pending），代表资金已锁定，尚未正式结算入账。3. 风控触发与账号停用事件描述： 账号支付完成后不久（2026年1月29日），系统判定该账号为“由计算机程序或机器人创建”或“与多个账号关联”，导致账号被即刻停用。原因分析： 可能是由于新账号在短时间内完成“异地注册+绑定境外卡+大额消费”，触发了 Google 全球安全防御系统的初级风控逻辑。4. 当前处理进展申

技术专业 · 01-29
失败的折腾：Google账号处理与申诉跟踪记录

操作日记｜腾讯云轻量服务器 Typecho 博客强制 HTTPS 实战记录

一、背景说明博客运行在 腾讯云轻量应用服务器（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 的

技术专业 · 01-28
操作日记｜腾讯云轻量服务器 Typecho 博客强制 HTTPS 实战记录

Clawdbot 2026 VPS 部署与加固操作日记

平台有了，对于更进阶的玩法还需要继续研究，起码有一点我的感触就是，在能力方面改变了，你配置它运行的模式，在没有进行任何金融接口配置的情况下，它在进行多轮尝试后自己寻找接口并生成运行代码获取到金融的数据，并进行分析反馈。操作日记：记录安装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，直接编写服务文件

技术专业 · 01-28
Clawdbot 2026 VPS 部署与加固操作日记

今日操作记录：AI工具切换、网络布局调整

? 今日操作记录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 转播

技术专业 · 01-23
今日操作记录：AI工具切换、网络布局调整

macOS 卸载鼠须管（Rime）操作记录

操作背景安装以后使用体验并不好，还是习惯使用原生的mac输入方式，想到哪里、打到哪里、显示到哪里，一气呵成的感觉，加之又安装了语音输入作为补充，决定删除Rime。在 macOS 系统中卸载鼠须管（Squirrel / Rime）输入法时，仅删除应用程序往往无法彻底清理。为避免输入法残留进程自动拉起、配置文件干扰系统输入法行为，需按照规范步骤进行完整卸载和清理。操作步骤一、从系统输入法中移除鼠须管打开 系统设置 → 键盘 → 输入法在输入法列表中选中 「鼠须管」点击 “-” 将其移除此步骤用于防止系统在后台继续加载鼠须管输入法服务。二、重启系统完成输入法移除后，重启电脑一次，确保相关输入法进程完全退出。三、删除系统级输入法程序打开 Finder按下 Command + Shift + G输入以下路径并回车：/Library/Input Methods在该目录中找到并删除：鼠须管.app（Squirrel.app）四、删除用户级配置文件（Rime）在 Finder 中再次按下 Command + Shift + G输入以下路径：~/Library找到并删除鼠须管的用户配置目录：Rime该目

技术专业 · 01-22
macOS 卸载鼠须管（Rime）操作记录

将联通esim写入外版iPhone的可行性

论坛上最新看到有人成功给外版的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

技术专业 · 01-22
将联通esim写入外版iPhone的可行性

VPS 部署实录：Caddy 反代 FreePBX 与内部 Web 服务共存

环境：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 的“显性跳转”顽疾 (

技术专业 · 01-21
VPS 部署实录：Caddy 反代 FreePBX 与内部 Web 服务共存

博客更换为免费的acme证书

我在腾讯云轻量服务器上部署了一个 Typecho 博客，日常运行一直很稳定。但有一个问题却反复出现：HTTPS 证书总是到期失效。使用的是腾讯云提供的免费证书，理论上支持自动续期，但在实际使用中，只要证书一到期，就必须手动重新分发、重新绑定，否则 HTTPS 直接失效。这个过程不仅麻烦，而且非常不“自动化”，也让我始终没搞明白它背后的续期机制到底哪里出了问题。更要命的是，这种问题并不会提前明显告警，往往是等浏览器提示证书错误了，才意识到又到期了。ACME 的“顺滑体验”最近在折腾 FreePBX 的部署时，接触并实际使用了 ACME 的免费证书方案（基于 Let’s Encrypt）。整个体验可以用一句话概括：一次配置，之后几乎不用再操心。最终，我决定把博客的证书也从原来的腾讯云证书，整体切换为 ACME 的免费证书方案。由于当前网络环境的限制，常规的 ACME 安装方式无法直接使用，例如某些在线脚本或默认 CA 连接会失败。因此在实际操作中，只能采用替代方案来完成证书申请与续期。1. 使用 Gitee 镜像安装1. 克隆代码（使用 Gitee 源） 复制并执行这条命令：Bashgit

技术专业 · 01-21
博客更换为免费的acme证书

从拖拽节点到表达意图：Claude Skills 正在终结传统 AI 工作流

你是否厌倦了在 dify 里拖拽几十个节点，只为实现一个看起来很简单的 AI 工作流？是否在 n8n 里调试到深夜，却始终找不到究竟是哪个节点出了问题？是否在 coze 里维护了五六个流程，每次需求一改，就产生“删库跑路”的冲动？我懂。因为我也经历过这一切。但现在，游戏规则真的变了。Claude Skills 的出现，让所有基于“画流程图”的 AI Workflow 工具，都显得笨重而过时。这不是危言耸听，而是一场已经开始发生的范式革命。核心观点先行：你不再需要画流程图了从今天起，你可以彻底告别这些事情：拖拽节点连线调试手动触发执行在低代码工具里当“流程工程师”更震撼的是：你只需要用“人话”告诉 Claude 你想要什么能力（Skill），Claude 就会帮你起草完整的 Skill 文档。当你之后提出相关请求时，Claude 会自动应用这个 Skill。不需要显式调用，不需要选择流程，不需要点击“运行”。这就是 Claude Skills 带来的降维打击。Claude Skills 到底是什么？根据官方定义，Skill 本质上是一个 Markdown 文件，用于教 Claude 如何

技术专业 · 01-21
从拖拽节点到表达意图：Claude Skills 正在终结传统 AI 工作流

FreePBX 部署日记-3：实现第一通测试电话的成功拨通

在前两篇完成了 FreePBX 的基础部署、安全加固和 HTTPS、备份之后，今天这一步才真正进入 “业务是否可用” 的关键阶段：创建用户（分机） → 终端注册 → 实际通话跑通看似简单，但在 Debian 12 + FreePBX 17 + OpenSSL 3 的组合下，TLS 注册过程中还是踩了几个非常典型的坑，值得完整记录。一、分机创建：从第一个用户开始1. 手工创建分机（Quick Create）路径：Applications → Extensions → Quick Create Extension2. 分机高级参数（保持克制）进入分机的 Advanced 页面，可以看到大量 NAT、RTP、Contact、Force rport 等选项。本阶段原则很简单：不要一上来就“调教参数”，先用默认值把流程跑通。3. 用户批量导入能力（为后续埋点）通过 Bulk Handler 可以看到：ExtensionsUsersGroupsUCP Templates在导出的模版中有前面已经配置的200这个用户，让大模型帮着生成了19个，导入后形成了一个20个用户的小的话务平台：FreePBX

技术专业 · 01-18
FreePBX 部署日记-3：实现第一通测试电话的成功拨通
2016 - 2026 自由翱翔：十年学习成长之路. All Rights Reserved.
Theme Jasmine by Kent Liao