转载自 L 站项目地址：HongShi2333/jmcomic-next代码来源于 Dedicatus546/jm-mobile，感谢原作者开源。这是一个禁漫天堂的第三方 Android 客户端，基于现有开源项目二次开发而来。先说动机。官方客户端体验差，不稳定，界面也谈不上好看……第三方客户端要么臃肿，要么功能不全。加上懒得开代理，索性自己动手。配好 Android 开发环境，把好久没碰的 Codex 翻出来，clone 一个现成项目开始改，改着改着就成了现在这个版本。主要改动有以下几点：系统兼容性下放至 Android 6，32 位和 64 位均支持。原因很朴素，手头正好有一台 Android 6 的设备。界面统一迁移至 Material 3。设计语言完整，视觉上比原版好看不少。优化了缓存逻辑，并新增导出 PDF 功能。PDF 导出这个需求来自真实用户反馈，算是正经的用户驱动开发。加入了 unlimitedai。没什么特别的，跟着学的。打包体积目前在 4MB 出头，性能占用不高，日常使用下表现还算满意。已发布三个版本，但前两个版本的源码因磁盘清理已丢失，仓库目前维护的是 1.1.3 版本。如果发现问题或有功能建议，欢迎直接提 issue，或在评论区说。提建议的佬友会被收录进 README 末尾的特别鸣谢名单。
Codex 用久了，会开始觉得额度不够用。跑到一半提示 5 小时配额见底，代码摊在那里，只能等恢复。后来才搞清楚一件事：同一个账号下，ChatGPT 和 Codex 的额度是分开计的。Plus 或 Pro 订阅里，两条线是独立计数器，一个烧完了，另一个还满着。也就是说，为这个订阅付的钱，可能有半个池子一直没花出去。问题只剩一个：怎么让 ChatGPT 去干 Codex 那种活——读本地项目的代码、改文件、跑检查？CodexPro 是什么CodexPro 是一个开源工具，6 月 16 日发布，我写这篇的时候已经 300+ star。它做的事一句话说清：通过 ChatGPT 官方的 Developer Mode 和 MCP 接口，让 ChatGPT 网页版直接读、改、搜索本地项目文件夹的文件，还能跑检查命令、看 git 改动。它不是破解，也不是绕限额的黑科技。它用的全是官方接口，没碰任何限额机制，也变不出额外额度。它做的只是把已经买好的 ChatGPT 额度，用到原本只有 Codex 能干的本地活上。有一个容易搞反的地方：不是在 Codex 对话框里选 ChatGPT 模型。而是反过来——在 ChatGPT 网页里，把本地项目接进去，把 Codex 那套"读项目、改文件、看改动"的能力借给 ChatGPT。前置条件ChatGPT Plus 或 Pro 账号，且账号能看到 Apps 和 Developer Mode（免费账号、Go 账号暂不支持）Node 20 及以上版本一个能让 ChatGPT 访问到本机的公网通道（第一次用选自动配的 Cloudflare 临时通道就行）接入流程第一步：安装npm install -g codexpro第二步：在项目目录里跑 setupcd /path/to/your/project codexpro setupsetup 会依次问几个问题：项目路径：默认就是当前目录，直接 Enter 确认。本地端口：默认 8787，没有端口冲突就不用改。模式：三个选项，第一次用选 agent。它让 ChatGPT 能读文件、搜文件、改文件，也能在安全范围内跑检查命令。handoff 模式更保守，只让 ChatGPT 出计划，真正动手交给本地的 Codex 或 OpenCode。pro 是备用方案，适合某些模型没法直接调用工具时把项目上下文打包出去。公网通道：四个选项，第一次选 quick，走临时 Cloudflare 通道，自动生成一个 HTTPS 地址。缺点是每次重启 CodexPro 进程或断网后地址可能变，需要回 ChatGPT 里更新 Server URL。有自己域名和 Cloudflare 配置的可以选 stable，有 ngrok 账号的选 ngrok，local 只适合本机 MCP 客户端。Auth token：直接按默认。token 会自动打进 Server URL 里，ChatGPT 连接时不需要再配 OAuth。保存配置：选 yes，下次从同一个项目启动不用再答一遍。是否立即启动：选 yes。setup 跑完会显示 CodexPro ready。有一个容易踩的坑：真正要填进 ChatGPT 的 Server URL 不会直接显示在终端里，它已经自动复制到剪贴板了。直接去 ChatGPT 粘贴就行。如果剪贴板被覆盖，在 CodexPro 终端界面按 c 重新复制。第三步：在 ChatGPT 里接上打开 ChatGPT 网页版，进设置 → 应用 → 高级设置，开启 Developer Mode。然后创建 App，名字随便填，连接方式选服务器 URL，把剪贴板里的地址粘进去。身份验证这里选 No Authentication（未授权）。CodexPro 不走 OAuth，token 已经在 URL 里了，选 OAuth 反而连不上。创建后 ChatGPT 会弹授权确认页，这一步就是在让 ChatGPT 伸手进指定的本地项目。确认后回到对话页，点输入框旁边的加号，在更多里能看到这个应用。接上以后，界面会出现项目卡片：当前工作区路径、写入范围、bash 安全模式、工具数量、git 改动、项目树。这个画面出现，说明 ChatGPT 已经通过 CodexPro 看到了本地项目。值不值得装如果 Codex 是主力工具、额度经常见底，同时有 ChatGPT Plus 或 Pro，这个工具值得装一下。它等于把订阅里一直闲置的那半个额度池接到了本地项目上，不需要多付一分钱。
AI摘要 本文介绍如何利用Cloudflare免费AI大模型，通过OpenAI兼容格式为Typecho插件实现文章翻译：获取Account ID和API Token，配置接口地址，推荐使用@cf/zai-org/glm-4.7-flash模型，并解决常见问题。 此内容根据文章生成，仅用于文章内容的解释与总结 写博客的人，迟早会遇到一个很现实的问题：中文文章写得好好的，海外读者看不懂；想做英文版，人工翻译太磨人；接第三方翻译接口，又怕账单一不小心起飞。这也是很多 Typecho 用户折腾文章翻译插件的原因。像 我的SmartTranslate 插件，思路其实很舒服：在后台把文章翻译好，译文存进字段里，前台读者需要英文就切英文，需要中文就看原文。页面不用每次打开都实时翻译，API Key 也不会暴露在前端，体验上稳很多。问题卡在另一头：翻译接口到底用谁？OpenAI 当然能用，可很多个人站、技术博客、轻量项目，没必要一上来就把预算砸进去。Cloudflare Workers AI 这时候就挺香，它提供免费额度，还支持类似 OpenAI 的调用方式。对已经适配 OpenAI 接口的插件来说，改动往往没想象中那么大。这篇就不绕弯子，直接讲清楚三件事：从 Cloudflare 官方页面拿到 Account ID；创建 Workers AI 可用的 API Token；用 OpenAI 兼容格式测试 Cloudflare 免费 AI 大模型，并选一个更适合翻译场景的模型。为什么从“翻译”这个场景切进去翻译这件事特别适合拿来测试大模型接口。原因很简单，结果好不好，肉眼就能看出来。你把一句中文技术描述丢进去，模型给出英文，通不通顺、术语准不准、有没有乱加意思，一眼就能判断。比如 Typecho 插件介绍、主题说明、部署教程、开源项目文档，这些内容最怕机器翻得像说明书残片。句子没错，但味道不对，读者读两段就跑了。所以这类文章翻译，我更建议用 OpenAI 兼容的大语言模型来处理，而不是只会逐句硬翻的接口。大模型能理解上下文，它知道“插件后台”“自定义字段”“前端切换”这些词放在技术文章里该怎么说。这也是 Cloudflare Workers AI 有意思的地方：它不是只给你一个翻译 API，而是给你一批大模型。你可以拿它做翻译，也可以继续拿它做摘要、标题、SEO 描述、标签生成。对博客插件来说，一套接口能干不少事。你要准备的东西别准备太多，真的就这几样：名称用来干嘛在哪里拿Cloudflare 账号进入控制台，开 Workers AICloudflare 官网注册Account ID拼接 API 地址Workers AI 的 REST API 页面API Token调用接口时鉴权Workers AI 页面一键创建模型 ID告诉 Cloudflare 调哪个模型Workers AI Models 文档OpenAI 兼容 Base URL给插件或代码填写接口地址https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai/v1注意，Cloudflare 这里用的是 API Token，不是你账号密码，也不是全局 API Key。别把 Cloudflare 账号密码填到插件里，那个太危险了。从 Cloudflare 官方页面拿 Account ID打开 Cloudflare 控制台，登录之后，在左侧菜单里找到 Workers & Pages，再进入 Workers AI。Cloudflare 官方的 REST API 入门页面给的流程很直接：进入 Workers AI 页面，点击 Use REST API，这个页面会把你需要的 Account ID 和创建 API Token 的入口放在一起。进入 Workers AI 后，找到 REST API。点进去之后，页面会出现 获取帐户 ID 。把里面的 Account ID 复制出来，先放到记事本里。它长得大概像这样：ACCOUNT_ID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx这串东西不是密钥，但也别随便公开。创建 Workers AI API Token同一个 REST API 页面里，找到 创建 Workers AI API令牌。点进去之后，Cloudflare 会给你预填好一套权限。正常情况下，用这个模板创建就够了。流程是这样：点击 创建 Workers AI API令牌；确认生成后立刻复制保存。API Token 只适合放在服务端、插件后台配置、环境变量里，别写到前端 JS，别塞进公开 GitHub 仓库。创建成功后，页面会显示一串 Token。立刻复制，建议保存成下面这种格式：CLOUDFLARE_ACCOUNT_ID=你的AccountID CLOUDFLARE_API_TOKEN=你的APIToken先用 REST API 测一下账号能不能跑拿到 Account ID 和 API Token 后，别急着往 Typecho 插件里填。先用终端测一下，能跑通再说。把下面命令里的 {ACCOUNT_ID} 和 {API_TOKEN} 换成你自己的。curl https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai/run/@cf/meta/llama-3.1-8b-instruct-fp8 \ -X POST \ -H "Authorization: Bearer {API_TOKEN}" \ -H "Content-Type: application/json" \ -d '{ "messages": [ { "role": "system", "content": "你是一个专业翻译助手，只输出英文译文，不解释。" }, { "role": "user", "content": "请把这句话翻译成英文：这款 Typecho 插件可以在后台生成文章英文译文，并在前台切换显示。" } ] }'如果成功，会看到类似这样的返回：{ "result": { "response": "This Typecho plugin can generate English translations of articles in the backend and switch between versions on the frontend." }, "success": true, "errors": [], "messages": [] }这里你重点看两个地方：success 是不是 true；result.response 里有没有正常译文。再用 OpenAI 兼容格式测试很多插件支持的是 OpenAI 接口。它们不是直接请求 /ai/run/模型名，而是请求这种地址：/v1/chat/completionsCloudflare Workers AI 支持 OpenAI 兼容端点，文本生成走 /v1/chat/completions，所以你只需要把 OpenAI 的 Base URL 换成 Cloudflare 的地址。Cloudflare 的 OpenAI 兼容 Base URL 是：https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai/v1完整测试命令如下：curl --request POST \ --url https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai/v1/chat/completions \ --header "Authorization: Bearer {API_TOKEN}" \ --header "Content-Type: application/json" \ --data '{ "model": "@cf/meta/llama-3.1-8b-instruct-fp8", "messages": [ { "role": "system", "content": "你是一个专业的中英翻译助手。请保留技术术语，不要添加解释，只输出英文译文。" }, { "role": "user", "content": "Cloudflare Workers AI 可以通过 OpenAI 兼容格式调用，这样很多现成插件只需要改 Base URL 和模型名称。" } ], "temperature": 0.2, "max_tokens": 800 }'成功后，返回结构会更像 OpenAI：{ "id": "chatcmpl-xxx", "object": "chat.completion", "choices": [ { "index": 0, "message": { "role": "assistant", "content": "Cloudflare Workers AI can be called through an OpenAI-compatible format, so many existing plugins only need to change the Base URL and model name." }, "finish_reason": "stop" } ] }插件一般会读取：choices[0].message.content只要这个字段有译文，OpenAI 兼容接口就算打通了。填到 Typecho 翻译插件里该怎么写不同插件后台字段名字可能不完全一样，但思路差不多。你只要认准这几项：插件配置项应该填写API 地址 / Base URLhttps://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai/v1API KeyCloudflare 创建的 API Token模型名称 / Model@cf/zai-org/glm-4.7-flash接口类型OpenAI / OpenAI Compatible / Chat Completions温度 temperature0.6 左右最大输出 max_tokens看文章长度，短文 800，长文 2000 起步别把 /chat/completions 重复填进去。有些插件让你填的是 Base URL，这时填：https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai/v1有些插件让你填的是完整请求地址，才填：https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai/v1/chat/completions这个地方很容易填错。填错后一般会出现 404、接口不存在、解析失败之类的问题。下图是使用我的翻译插件的示例推荐的翻译提示词翻译文章别只丢一句“翻译成英文”。这样出来的东西不稳定，有时它会解释，有时它会补内容，有时它会把代码块也乱改。可以用下面这个 system prompt：你是一个专业的中英技术文章翻译助手。 请将用户提供的中文内容翻译成自然、准确、适合技术博客阅读的英文。 保留 Markdown 格式、代码块、链接、图片标记、表格结构和专有名词。 不要添加解释，不要输出原文，不要总结，只输出英文译文。 如果遇到不常见技术词，请保留准确表达。哪个模型性价比最高这是重点，别一上来就选最大模型。Cloudflare Workers AI 的模型定价会按模型变化。以当前官方定价表来看，常见几个模型大概是这样：模型适合场景输入价格输出价格我的建议@cf/zai-org/glm-4.7-flashOpenAI 兼容接口、文章翻译、长文处理、多语言内容$0.06 / 百万 token$0.40 / 百万 token主推，便宜、上下文长，翻译和技术文章处理都舒服@cf/meta/llama-3.1-8b-instruct-fp8OpenAI 兼容接口、文章翻译、摘要$0.152 / 百万 token$0.287 / 百万 token也能用，输出便宜些，但输入价比 GLM 高@cf/meta/llama-3.1-8b-instruct通用文本生成、翻译$0.282 / 百万 token$0.827 / 百万 token老方案能跑，但价格不香，而且官方已列入弃用名单@cf/meta/llama-3.1-8b-instruct-awq便宜文本生成$0.123 / 百万 token$0.266 / 百万 token旧项目临时可用，新项目不建议押它@cf/meta/m2m100-1.2b专门翻译$0.342 / 百万 token$0.342 / 百万 token翻译模型本身不错，但它不是标准 chat completions 插件最顺手的选择如果你的目标是：Typecho 插件里直接用 OpenAI 格式调用 Cloudflare AI 大模型做文章翻译，我建议默认选：@cf/zai-org/glm-4.7-flash它的优势比较实在：支持 OpenAI 兼容调用，插件适配省事；价格比普通 kimi2.6 低不少；上下文窗口更适合处理长一点的文章段落；翻译技术文章时，比小模型更稳，不容易把术语翻飞。如果你只想做一个单独的“翻译 API”，不要求 OpenAI 兼容格式，那可以考虑：@cf/meta/m2m100-1.2b它是专门的多语言翻译模型，请求参数是这样的：curl https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai/run/@cf/meta/m2m100-1.2b \ -X POST \ -H "Authorization: Bearer {API_TOKEN}" \ -H "Content-Type: application/json" \ -d '{ "text": "This Typecho plugin can generate English translations in the backend.", "source_lang": "english", "target_lang": "chinese" }'它更像传统翻译接口，简单直接。但很多 OpenAI 插件默认不会按 text/source_lang/target_lang 这种格式发请求，所以你要么改插件代码，要么在中间套一层 Worker 做转接。免费额度到底够不够用Cloudflare Workers AI 免费额度按神经元计算。官方当前写法是每天 10,000 神经元 免费额度，超出后需要 Workers 付费计划。很多人看到 神经元 会懵，其实你可以先粗暴理解成token。博客翻译的用量一般没那么吓人。比如你不是每天翻译几百篇文章，只是写完文章后点一下“生成英文译文”，大概率够用。真正要注意的是批量翻译。假设你站里有 500 篇旧文章，一次性全点生成，肯定容易撞额度。更稳的办法是：每次只处理 10 到 20 篇；长文章按段落翻译，失败了只重试那一段；已经生成过译文的文章不要重复请求；常见报错怎么处理401 Unauthorized大概率是 API Token 错了。检查这几个点：Token 有没有复制完整；Authorization 前面是不是 Bearer；Token 有没有被你多复制了空格；自定义 Token 有没有 Workers AI 权限。正确写法是：Authorization: Bearer 你的API_TOKEN404 Not Found多半是地址填错了。OpenAI 兼容 Base URL 是：https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai/v1完整 chat completions 地址是：https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai/v1/chat/completions别把 {ACCOUNT_ID} 原样留下，也别漏掉 /accounts/。模型不存在模型名必须完整，包括前面的 @cf/。正确：@cf/meta/llama-3.1-8b-instruct-fp8错误：llama-3.1-8b-instruct-fp8少了 @cf/meta/，Cloudflare 找不到。插件返回空白接口可能成功了，但插件没解析到字段。你需要确认插件读取的是：choices[0].message.content如果插件原来只兼容某些返回格式，可能要看一下插件代码里解析响应的地方。文章发布前的小检查配置好后，别急着发。拿一篇短文测一轮。建议按这个顺序看：中文标题有没有被翻得太硬；代码块有没有被改；链接有没有丢；图片 Markdown 有没有保留；Typecho、Cloudflare、Workers AI、API Token 这些词有没有乱翻；前台切换中英文时，页面布局有没有炸。翻译功能的价值不在“生成一下就完事”，而是让读者真的能读。尤其技术文章，术语和代码一乱，可信度会掉得很快。参考资料Cloudflare Workers AI REST API 官方文档：https://developers.cloudflare.com/workers-ai/get-started/rest-api/Cloudflare Workers AI OpenAI 兼容接口文档：https://developers.cloudflare.com/workers-ai/configuration/open-ai-compatibility/Cloudflare Workers AI 定价文档：https://developers.cloudflare.com/workers-ai/platform/pricing/Cloudflare @cf/meta/llama-3.1-8b-instruct-fp8 模型文档：https://developers.cloudflare.com/workers-ai/models/llama-3.1-8b-instruct-fp8/Cloudflare @cf/meta/m2m100-1.2b 翻译模型文档：https://developers.cloudflare.com/workers-ai/models/m2m100-1.2b/结尾翻译插件真正好用的地方，不是让博客看起来“支持国际化”四个字，而是让文章多一条被读到的路。Cloudflare Workers AI 这套方案的舒服点就在这：不用自己买服务器，不用折腾 GPU，也不用把插件大改一遍。拿到 Account ID，创建 API Token，换成 OpenAI 兼容 Base URL，再选一个合适的模型，文章翻译这条线基本就能跑起来。
自托管朋友圈 Ech0 安装教程与使用体验
AI摘要 Ech0是一款开源自托管个人微网志平台，支持Markdown写作、评论、RSS订阅及多种安装方式（Docker、脚本、Kubernetes等）。部署简单，界面简洁卡片式设计，响应快速，适合搭建私有或半公开的时间线，记录生活、分享灵感，不被商业平台干扰。 此内容根据文章生成，仅用于文章内容的解释与总结 随着网络社交平台愈发商业化和算法化，越来越多人希望拥有一个不受干扰的私人朋友圈，既能随时记录灵感，又能分享心情。Ech0正是这样的轻量级工具，它是一款开源的自托管个人微网志平台，可以在自己的服务器上搭建属于你的一片小天地。它强调简洁、私有和可掌控性，既支持 RSS 订阅及评论，又不会演变成臃肿的社交网络。适合谁使用？想搭建个人公开或半公开的时间线，用自己的域名管理日常随笔、链接和图片。希望保留数据所有权，又需要 RSS 输出和可选的评论互动。渴望一个可分享但不会沦为庞大社交网络的个人空间，比如仅与亲友分享日常、在互联网上发泄情绪或记录成长。不建议用 Ech0 搭建双向知识库、团队协作文档或纯私密记事应用。这些场景更适合使用 Obsidian、Notion 等工具。功能特色Ech0的设计追求轻量高效，但功能相当全面：轻量架构：体积小巧，对服务器资源需求低，官方提供完整二进制和 Docker 镜像，部署快捷。Markdown 写作体验：内置基于 markdown-it 的编辑器，支持插件扩展和实时预览。标签与卡片系统：提供标签管理和丰富的媒体卡片，可为链接、GitHub 项目等生成预览卡片。视频解析和文件管理：可嵌入 B 站、YouTube 视频，内置文件上传与浏览功能。评论与社交互动：内建评论系统，支持点赞和分享，为轻量级社交提供支撑。安全与授权：支持 OAuth2/OIDC 登录、无密码 Passkey 登录、权限管理和开放 API。多端体验：响应式设计，支持桌面和移动设备，具备 PWA 安装能力，内置主题和暗色模式。完全开源：采用 AGPL-3.0 许可证，无追踪、无订阅、无 SaaS 依赖。安装部署官方文档建议优先使用Docker，其次是 Docker Compose、安装脚本 (systemd)、Helm 或二进制方式。使用 Docker (推荐)Docker 是最简单的部署方式，只需一条命令即可启动：docker run -d \ --name echo \ -p 6277:6277 \ -v /opt/echo/data:/app/data \ -e JWT_SECRET="请替换为随机密钥" \ sn0wl1n/ech0:latest执行完成后可在浏览器中访问http://服务器IP:6277，首次注册的帐号将成为系统管理员（Owner）。请务必替换JWT\_SECRET环境变量，并确保挂载的数据目录/opt/echo/data有正确的读写权限。使用 Docker Compose如果偏好通过docker compose管理服务，首先在任意目录创建docker-compose.yml，写入示例内容：services: ech0: image: sn0wl1n/ech0:latest container_name: echo ports: - "6277:6277" volumes: - ./data:/app/data environment: JWT_SECRET: 请改为随机的密钥 restart: unless-stopped在该目录下执行：docker compose up -d如系统的命令仍为docker-compose，则使用docker-compose up -d即可。使用安装脚本 (systemd)项目提供了安装脚本，可通过curl下载并执行：curl -fsSL "https://raw.githubusercontent.com/lin-snow/Ech0/deploy/install-echo.sh" -o install-echo.shsudo bash install-echo.sh脚本会使用systemd安装并管理服务，需要 root 权限。若需要自定义安装目录，可使用bash echo.sh install /your/path/ech0指定路径。使用 Helm 安装（Kubernetes）如果希望在 K8s 集群中部署，可使用官方提供的 Helm Chart。推荐使用在线仓库安装：helm repo add ech0 https://lin-snow.github.io/Ech0 helm repo update helm install echo ech0/echo可通过--create-namespace指定命名空间，也可更改 release 名称。例如：helm install my-echo ech0/echo --namespace my-namespace --create-namespaceJWT\_SECRET等配置项可以在values.yaml或使用--set参数指定。若需要从本地源码安装，可克隆仓库后在charts/echo目录执行helm install。使用二进制在 GitHub Releases 页面可下载针对不同平台的压缩包，解压后运行二进制即可：./echo serve官方提供的构建包括 Linux/amd64、Linux/arm64、Linux/armv7 以及 Windows/amd64 等多种架构。初次使用与配置系统首次启动后需要完成一些基础配置：注册第一个帐号 —— 第一个注册用户即为Owner，拥有管理权限，可以发布和管理内容。设置服务地址 —— 在系统设置中填写完整的站点URL（包含协议），方便头像存储、第三方 Connect 功能正常工作。根据需要开启评论、对象存储、单点登录等 —— 详细配置请查阅文档中的其他指南。若普通用户无法发帖，可能是其权限不足，需由 Owner 在后台授予发布权限或调整站点的权限策略。环境变量与进阶配置除了JWT\_SECRET外，Ech0 还支持通过环境变量自定义数据目录、端口号、对象存储配置等。更多参数可参考仓库中的README.zh.md或文档docs/目录。关于时区的说明：系统内部时间以服务器时间为准，用户界面根据设置展示本地时间。生产环境建议不要暴露调试接口；确保将数据目录与镜像分离备份；如果需要自定义端口，在后台创建反向代理（如Nginx/Caddy）并绑定公开仓库证书。使用体验简述实际搭建 Ech0 之后，你会发现它带来的体验既简洁又顺滑。安装过程非常迅速，无论是单条 Docker 命令还是 docker-compose 文件，都能在几分钟内跑起服务。首次登录后的后台界面采用简洁的卡片式设计，没有复杂的菜单，常用功能一目了然。编辑器支持实时 Markdown 预览，写作时所见即所得，添加标签和插入图片都很顺手。个人时间线以瀑布流呈现，响应速度快，加载大图或视频也没有明显卡顿。移动端访问时页面会自适应屏幕尺寸，触控体验与桌面版一致。评论与互动功能开启后，访客可以留言或点赞，后台提供了简单的审核运营工具，不会占用过多精力。主题与暗色模式可以在设置中切换，对于喜欢简约风格的人来说默认主题已经足够清爽。如果想要更多自定义，可以编写自己的 CSS 或利用开放 API 扩展功能。总体而言，Ech0 的上手成本很低，配置方式清晰，用起来顺手，不会因为功能过多而分散注意力。它满足了“写完即分享”的需求，既适合作为私密树洞，也适合做公开的微博客；在自托管环境下运行稳定，适合长期使用。结语Ech0用最简洁的方式帮你搭建个人微网志，它既支持 Markdown 写作、标签、评论，也提供了完善的权限和安全机制。对于希望在网上拥有一片不受干扰的小天地的人来说，这是一个非常理想的选择——将域名与服务器掌握在自己手中，可以随意记录生活点滴、分享灵感或发泄心情，而不会被商业平台推送和干扰所打扰。
这个 GitHub 项目有点实用：软著材料自动生成，开发者少熬几个大夜
AI摘要 GitHub 项目 `chinese-copyright-application-skill` 能自动生成软件著作权申请材料，包括申请表、源代码文档、用户手册和设计说明书。该工具通过分析项目代码和 README，极大简化了开发者整理材料的重复劳动，尤其在源代码文档格式化和内容提取方面效率显著。虽然生成内容需人工核对，但该项目为独立开发者和小团队提供了高效的解决方案。 此内容根据文章生成，仅用于文章内容的解释与总结 做过软件著作权申请的人，应该都懂那种烦。项目都写完了，功能也跑通了，结果真正卡住你的，不是代码，不是上线，而是一堆软著申请材料。申请表要填，说明书要写，源代码要整理，格式还不能乱。尤其是源代码文档，前 30 页、后 30 页，每页行数还得看着规整，稍微哪个地方不对，后面就可能被退回来重弄。这种事说难吧，也没有多难；说简单吧，真能把人磨到没脾气。你要一页一页复制代码，还要删掉无关内容，调页眉页脚，改行距，检查页码。弄到半夜，Word 卡一下，人也跟着卡住。更离谱的是，忙活两三天，最后发现格式有问题，那一下真是血压直接上来了。前阵子我看到一个开源项目，名字叫 chinese-copyright-application-skill，作者是 @na57。这个项目挺对开发者胃口，它专门解决软著申请材料整理这件烦事。它不是那种随便拼几段文本的小脚本，而是围绕软著申请流程做的一套工具。你把代码项目交给它，它会去分析项目结构，识别项目类型，再生成软著申请常用的几份材料。正常情况下，几分钟就能出一个基础版本，后面你再检查、补信息、微调格式就行。这东西最有价值的地方，其实不是“AI”两个字，而是它把重复劳动砍掉了。比如申请表里那些基础信息，软件名称、版本号、开发完成日期、技术特点、功能介绍，工具可以根据项目内容先整理出来。著作权人信息这种涉及个人或公司资料的地方，还是得自己填，毕竟这玩意不能乱写。源代码文档就更省事了。以前最痛苦的就是凑前后 60 页代码，手工复制很容易乱，还容易把没用的文件也塞进去。这个工具会扫描项目文件，尽量挑核心代码，过滤掉注释、空行和一些不重要内容，再按软著材料常见格式整理出来。代码太多的时候，它会自动截取前后部分，不用你自己在一堆文件里翻半天。用户手册也能生成。它会结合项目类型、README 内容，把软件介绍、功能说明、运行环境、操作步骤这些内容拼起来。如果你的 README 本来写得比较完整，那生成出来的用户手册就会顺很多，基本属于拿来改改就能用。设计说明书这块也挺有用。很多开发者会写代码，但真让他写软件架构、模块说明、接口设计，就开始头疼。这个项目会根据代码结构生成一版技术说明，虽然不能保证完全贴合你的真实业务细节，但至少不会让你盯着空白文档发呆。用法也不复杂。喜欢命令行的话，直接克隆项目：git clone https://github.com/na57/chinese-copyright-application-skill.git cd chinese-copyright-application-skill接着运行脚本：python3 scripts/generate_copyright_docs.py <你的项目路径> [输出目录]比如你的项目在 ~/projects/my-app，想直接生成软著材料，可以这样写：python3 scripts/generate_copyright_docs.py ~/projects/my-app想输出到桌面某个文件夹，也可以加路径：python3 scripts/generate_copyright_docs.py ~/projects/my-app ~/Desktop/软著材料跑完以后，一般会生成几份 Markdown 文件，像申请表、源代码文档、用户手册、设计说明书这些都会有。打开之后就能继续编辑，也可以转成 Word 或 PDF。这里别偷懒，生成完一定要自己看一遍。软件名称、权利人信息、版本号、完成日期、发表状态，这些地方不能瞎填。工具能帮你省时间，但不能替你确认法律层面的信息。如果你平时用 Trae IDE，也可以把这个 Skill 导进去用。导入之后，直接让它帮你生成软著材料，它会根据项目情况给你整理文档，还能让你确认软件名称、版本号这些关键信息。对不爱敲命令的人来说，这种方式更顺手一点。导入方式也简单，在 Trae 的技能管理里选择导入本地 Skill，选中项目里的 SKILL.md 文件，重启一下 IDE，就能开始用了。但有个现实问题得说清楚：工具生成效果好不好，跟你的项目本身有关系。README 很关键。很多项目 README 写得特别随意，只有一句项目说明，甚至啥都没有。那工具能提取的信息就少，生成出来的用户手册肯定也干巴巴。你要是提前把项目介绍、功能模块、运行方式、环境依赖写清楚，生成质量会明显好不少。目录结构也别太野。主要代码放在 src、lib、app 这种常见目录里，它识别起来会更稳。要是测试文件、临时代码、打包产物全混一块，工具也许能跑，但文档质量就不一定好看了。生成出来的是 Markdown，提交前通常还要转成 Word 或 PDF。想省事可以用 Pandoc：pandoc 软件著作权登记申请表.md -o 申请表.docx源代码文档建议转 PDF，格式更稳一点。软著材料这种东西，有时候不是内容不行，而是格式小问题把人折腾死，所以提交前最好把页眉、页脚、页码、行距都检查一遍。这个项目比较适合独立开发者、小团队，还有经常交付项目的外包团队。独立开发者做了小程序、插件、管理系统、SaaS 工具，想申请软著保护一下，但又不想花几天整理材料，用它先跑一版就很舒服。小团队项目多、人少，软著材料如果都靠人工做，真的很吃人力。现在先让工具生成基础版，再由负责人检查修改，效率会高很多。外包团队也能用。客户临时要软著材料的时候，不至于从零开始凑文档，至少能先把申请材料框架搭出来。当然，它不是包过神器，也不是闭眼提交工具。软著申请还是要以实际要求为准，生成文档更像一个质量不错的初稿。尤其涉及权利归属、软件名称、开发时间这些内容，必须自己核对，别图省事。这个项目开源，采用 MIT 协议，想改也方便。如果你常用 Go、Rust、Java，或者公司内部项目结构比较固定，也可以自己扩展一下解析逻辑，让它更贴合自己的项目。仓库地址：https://github.com/na57/chinese-copyright-application-skill说到底，软著申请材料这活儿不高级，但很耗人。以前开发者要把时间浪费在复制代码、调格式、凑说明书上，现在有工具能先把脏活干掉，确实值得试。
我为什么会关注 Ant Browser：指纹浏览器终于有了一个开源选择
AI摘要 Ant Browser 是一个开源的指纹浏览器，为多账号运营者提供了一个免费的解决方案。它允许用户为不同账号创建独立的浏览器环境，配置代理、内核等，并支持代理池和导入 Clash 配置。该工具适合账号量不大、预算敏感且愿意自行配置的用户，但对于需要团队协作和成熟服务的用户，商业指纹浏览器仍是更优选择。 此内容根据文章生成，仅用于文章内容的解释与总结 废话不多说，项目地址：https://github.com/black-ant/Ant-Browser指纹浏览器到底是干嘛的？简单说，指纹浏览器就是给不同账号准备不同的浏览器环境。百科上对“浏览器指纹”的解释，大意是：网站可以通过浏览器暴露出来的配置和设置信息来识别一个浏览器。你不用把它想得太复杂，它有点像浏览器的“身份证”。比如系统、浏览器版本、屏幕分辨率、字体、语言、时区、插件、Canvas、WebGL 这些东西，拼在一起，就可能让平台判断：这几个账号是不是都从同一个环境里出来的。所以多账号运营的人才会用指纹浏览器。不是为了玄学，也不是为了装高级，很多时候就是为了少串号、少互相影响。一个账号一个环境，一个环境配一个代理，管理起来会规整很多。我为什么会注意到 Ant Browser因为商业指纹浏览器确实不便宜。AdsPower、Multilogin、BitBrowser 这类工具，成熟是成熟，省心也是真的省心。但如果你只是个人卖家，手里就十几个、几十个账号，还没开始赚钱，先把工具年费交出去，心里多少会有点不舒服。Ant Browser 吸引我的地方，不是它有多完美，而是它把“多账号环境管理”这件事做得更轻了。你可以把它理解成一个本地的账号环境管理器：给每个账号建一个浏览器实例，每个实例单独配置代理、内核、标签和备注。平时要打开哪个账号，就启动对应实例，不用来回切浏览器配置，也不用手动清缓存、换代理。对账号量不大的用户来说，这个思路是够用的。它比较顺手的地方我最喜欢的是它支持代理池，还能导入 Clash 配置。很多人本来就有 Clash 订阅，或者手上已经维护了一批代理节点。最烦的事情是什么？换个工具，又要一个个复制地址、端口、账号、密码。Ant Browser 支持把代理统一放进代理池，再分配给不同实例，这一点很接地气。另外，它的数据主要放本地。这点对我这种不太喜欢把所有配置都丢到云端的人来说，比较加分。实例信息、代理配置、浏览器环境这些东西，能放自己电脑里就放自己电脑里。至少以后备份、迁移、排查问题，心里知道东西在哪。还有一个小细节是实例管理。新建、启动、停止、克隆、删除这些基础操作都有。账号多一点的话，可以按标签、分组、状态、代理去筛选。功能听起来不花哨，但这种工具最重要的不是花哨，是别乱。但别把它当成商业工具平替这里也泼点冷水。Ant Browser 更像是一个开源项目，不是那种买完就有人手把手教你的商业 SaaS。它现在适合愿意自己折腾一点的人。比如你愿意自己导入代理、自己准备内核、自己先拿几个测试账号跑一下，再决定要不要正式用。如果你需要团队协作、权限管理、云端同步、客服兜底、批量自动化流程都非常成熟，那商业工具还是更省事。还有一点也要注意：GitHub README 里写到，仓库目前暂未附带独立 LICENSE 文件。所以如果只是自己用、学习、测试，问题不大；但如果你想拿去二开、商用，最好先等作者补充许可证，或者自己确认清楚。适合谁用？我觉得比较适合三类人。第一类是跨境电商小卖家。比如你有几个亚马逊、Shopee、Lazada 店铺，想把每个店铺的登录环境分开，不想一开始就上很贵的商业工具。第二类是社媒运营。比如 Facebook、Instagram、TikTok 账号比较多，但还没到几百个账号那种规模，用它先把环境和代理管理起来。第三类是开发者和测试人员。有时候只是想同时保留多个登录状态，或者测试不同环境下的页面表现，没必要专门买一套商业指纹浏览器。如果你的实例数量在 70 个以内，我觉得它值得试一下。超过这个量，就先别急，先把规则确认清楚。第一次用，我建议这样来别一上来就把所有账号搬进去。先建一两个测试实例，导入你现有的 Clash 配置，给实例绑定一个代理，然后打开 IP 检测、指纹检测网站看一下效果。稳定跑几天，再慢慢迁移其他账号。如果你平时账号比较多，建议一开始就把命名、标签、分组做好。比如按平台分：Amazon、Shopee、TikTok；或者按地区分：US、UK、SG。前期懒一下，后面实例多了会很痛苦。我的看法Ant Browser 不是那种“装上就万事大吉”的工具。它更像是给个人用户和小团队留了一个选择：不想一开始就交高额年费，又确实需要多账号隔离，那可以先从它试起。它的定位我觉得很清楚：70 个实例以内，预算敏感，愿意自己折腾一点，可以试。如果你账号量很大，或者业务已经稳定赚钱了，商业工具的稳定性和服务可能更值得买。但对刚起步的人来说，能先省下工具钱，把钱花在代理、素材、选品、投放测试上，也挺现实。最后还是那句话：工具只是工具，别把它当万能护身符。多账号运营该遵守的平台规则还是要遵守，账号能不能长期跑下去，最后看的还是运营方式本身。参考Ant Browser GitHub：https://github.com/black-ant/Ant-Browser“浏览器指纹”的解释参考《中国大百科全书》第三版网络版
AI摘要 `tgautodown` 是一款基于 Telegram MTProto 的自动下载工具，可监听指定频道或群组，自动下载视频、音乐、图片、文档、磁力链和笔记至本地。它支持 Web 登录，并提供任务暂停、继续和删除功能。通过 Docker Compose 部署，可将资源按类型分类保存，适合作为私人 Telegram 资源归档器。 此内容根据文章生成，仅用于文章内容的解释与总结 tgautodown 是一个基于 Telegram MTProto 的自动下载工具。它不依赖 Bot API，也不需要单独部署 bot-api-server，登录自己的 Telegram 账号后，就可以监听指定频道或群，把收到的视频、音乐、图片、文档、磁力链和笔记自动保存到本地目录。比较适合的使用场景是：自己建一个私有频道，把需要保存的资源转发进去，然后让 tgautodown 自动下载和分类归档。主要功能支持下载视频、音乐、图片、文档。支持保存文本笔记。支持磁力链接下载。支持获取 Telegram 文件原文件名。支持 Web 页面登录 Telegram。登录成功后，Web 页面展示正在下载任务的进度，不展示 AppHash、手机号等隐私信息。每个下载任务会分配一个临时 UID，可在 Telegram 中暂停、继续或删除任务。Docker Compose 支持 ARM64 和 AMD64 架构。频道参数怎么填启动参数里的 -names 或 Docker 环境变量 TG_CHANNEL 用来配置监听来源。公开频道或公开群填写用户名即可，例如：my_public_channel私有频道或私有群填写邀请链接里的 +hash。例如邀请链接是：https://t.me/+AjbQIYhiKlhhNzMx那么配置为：+AjbQIYhiKlhhNzMx注意：这里不是频道 ID。当前版本不支持直接填写频道 ID。如果账号尚未加入这个私有频道，程序会尝试通过邀请链接自动加入。更稳妥的方式是先用 Telegram 官方客户端登录同一个账号，手动加入频道或群，然后再启动程序。Docker Compose 启动先把项目拉到服务器上：git clone https://github.com/Suk-ldev/tgautodown.git cd tgautodown项目里已经提供了 docker-compose.yml，先打开它：nano docker-compose.yml你主要需要改这几处：environment: TG_CHANNEL: "+AjbQIYhiKlhhNzMx" TG_PROXY: "socks5://192.168.31.2:7891" TG_F2A: "" TG_RETRYCNT: "10" ports: - "2020:2020" volumes: - "/mnt/sda1/download:/app/download" - "/mnt/sda1/data:/app/data"说明一下：TG_CHANNEL 是监听来源。公开频道填用户名，私有频道填邀请链接里的 +hash。TG_PROXY 是 socks5 代理。如果服务器能直接访问 Telegram，就改成 ""。TG_F2A 是 Telegram 两步验证密码。没有开启两步验证就留空。TG_RETRYCNT 是下载失败后的重试次数，一般保持 10。ports 左边是宿主机端口，右边是容器端口。默认访问 http://服务器IP:2020。volumes 左边是服务器目录，右边是容器目录。通常只改左边，例如改成自己的硬盘挂载目录。完整示例：services: tgautodown: image: tgautodown:${TARGETARCH:-arm64} build: context: . dockerfile: Dockerfile args: TARGETOS: linux TARGETARCH: ${TARGETARCH:-arm64} platform: linux/${TARGETARCH:-arm64} container_name: tgautodown restart: unless-stopped environment: TG_CHANNEL: "+AjbQIYhiKlhhNzMx" TG_PROXY: "" TG_F2A: "" TG_RETRYCNT: "10" ports: - "2020:2020" volumes: - "/root/download:/app/download" - "/root/data:/app/data"保存后启动：docker compose up -d --buildARM64 机器可以直接构建：docker compose up -d --build如果是 AMD64：TARGETARCH=amd64 docker compose up -d --build强制重新构建镜像：docker compose down --rmi local docker compose build --no-cache --pull docker compose up -d --force-recreate首次登录容器启动后，打开：http://服务器IP:2020输入 Telegram API 的 App ID、App Hash 和手机号，等待验证码，然后在页面中提交验证码。登录成功后，页面会进入下载进度视图。Telegram API ID 和 App Hash 可以在这里申请：https://core.telegram.org/api/obtaining_api_id下载目录资源会按类型保存：videos 视频 music 音乐 documents 文档 photos 图片 bt 磁力链 note 文本笔记如果 Docker 中把 /app/download 映射到了宿主机目录，例如 /mnt/sda1/download，那么最终文件会出现在宿主机的对应分类目录里。暂停、继续和删除下载任务开始后，程序会在 Telegram 中回复类似这样的提示：正在下载视频: example.mp4 - UID: 100 - 文件大小: 1.20GB - 消息ID: 123 - 暂停请输入: 暂停 100 - 删除正在下载视频请输入: 删除 100 - 继续请输入: 继续 100之后可以在监听频道或群里发送：暂停 100 继续 100 删除 100UID 是临时的，下载完成、失败或删除后会释放。关于 FLOOD_WAIT如果日志里出现：FLOOD_WAIT (2452)意思是 Telegram 限制了这个账号继续请求，需要等待括号中的秒数。比如 2452 秒大约是 40 分 52 秒。遇到这种情况不要反复重启容器，也不要频繁尝试同一个邀请链接。等限制时间过去后再启动，或者先用 Telegram 官方客户端手动加入频道，再让程序监听。查看日志docker compose logs -f --tail=100 tgautodown如果看到 ready，说明 Telegram 账号已经登录成功。如果看到 private channel 或 public channel，说明频道已经被识别并开始监听。小结tgautodown 更像一个私人 Telegram 资源归档器：把资源转发到固定频道，它负责下载、分类和保存。配合 Docker 部署到 NAS、软路由或 ARM 小主机上，基本可以做到长期后台运行。
这个写小说的 Skill，本质是在帮模型“别失忆”
AI摘要 该中文小说 Skill 通过每章生成摘要并将其作为下一章的上下文，解决了 AI 模型在长篇写作中“失忆”的问题。这种朴素但有效的方法，让模型能够记住人物设定、剧情发展和未填坑点，从而避免了前后矛盾，使写作过程更连贯。虽然生成内容可能套路化且节奏偏慢，但它能帮助模型“写得下去”，而非“写得多好看”。 此内容根据文章生成，仅用于文章内容的解释与总结 最近在 skills.sh 上看到一个有点意思的东西：https://skills.sh/penglonghuang/chinese-novelist-skill/chinese-novelist名字挺直白的，就是写中文小说用的 Skill。一开始我其实没太当回事，这类“AI 写小说”的东西已经见太多了，基本都有个共同问题：写着写着就崩。为什么会崩如果你自己用过模型写长一点的东西，大概都踩过这个坑：人物写着写着性格变了配角名字对不上前面埋的东西后面忘了写到后面像换了个作者说白了就是：上下文一长，模型记不住。你只能不停提醒它：“这个人是谁”“刚刚发生了什么”。挺烦的。这个 Skill 干了件很朴素但有用的事它没有搞什么特别复杂的东西，就做了一件事：每写一章，顺手做个摘要，然后带着摘要继续写下一章。就这么简单。但效果还挺明显的。你可以把它理解成：模型还是那个模型，只是旁边多了个一直在记笔记的编辑这个“编辑”会帮你记：人物设定已经发生的剧情哪些坑还没填然后下一章继续喂回去。用起来也很直接基本流程就是：把 Skill 丢到 AI软件 的 skills 目录或者把链接发给他让他自己安装启动回答几个问题一般就是选：写什么题材主角是啥人性格大概怎样冲突是什么写多少章选完之后，它就自己开始往下写了。不是一次性吐一整篇，是一章一章来。和“直接让 AI 写”的区别如果你之前是直接丢一句“帮我写个小说”，那这个 Skill 的差别主要在两点：第一，它是分章写的。第二，它在章和章之间会“记笔记”。这两个点加起来，就让东西至少不会那么容易崩。效果怎么说如果你指望它写出什么很惊艳的东西，那还是算了。但如果只是想：写得顺一点别前后打架能完整写完它是有用的。问题也很明显：情节还是比较套路节奏偏慢不太有那种抓人的点也就是说，它解决的是“写得下去”，不是“写得多好看”。有点像什么我觉得更像是把写小说这件事，稍微“工程化”了一点。不是靠模型一口气硬写，而是：分步骤留记录一点点往下推进挺土的方法，但有效。更实际一点的用法如果真的想用它干点正经事，可能更靠谱的方式是：自己先把大方向想清楚把关键设定喂进去让它去写初稿再自己改纯放给 AI 写，最后大概率就是能看，但不太想看第二章。总的来说这个 Skill 没有多神，但它解决了一个很现实的问题：模型写长东西会“失忆”它的办法也很简单：别指望它记住，让它每一步都记下来。就这么回事。
用免费容器跑节点：Xboard-Node + ClawCloud Run 实战教程
AI摘要 本文介绍了如何利用 Xboard-Node 和免费容器平台 ClawCloud Run 搭建节点。Xboard-Node 实现了节点的容器化，使其能在任何支持 Docker 的环境中运行。ClawCloud Run 提供每月 5 美元的免费额度，可用于部署 Xboard-Node 容器。教程详细说明了注册、配置容器、修改面板参数以及验证节点上线的过程，并提示免费额度主要消耗在流量上，建议作为备用节点使用。 此内容根据文章生成，仅用于文章内容的解释与总结 前段时间，XBoard 作者发布了一个新项目：https://github.com/cedar2025/Xboard-Node这个项目表面上只是一个新的节点后端，但实际上解决了一个很关键的问题——让节点程序可以稳定运行在 Docker 容器中。如果你之前用过 V2bX 或类似方案，应该都有体感：节点基本都依赖宿主机环境，在容器里跑起来要么折腾，要么不稳定。这也导致节点部署一直和 VPS 强绑定。而 Xboard-Node 的出现，本质上是把节点彻底“容器化”了。节点不再依赖具体机器，而是变成了一个可以随处运行的服务。这件事带来的变化，其实不只是部署方便，而是思路上的变化。既然节点可以用 Docker 运行，那么理论上，任何提供容器运行环境的地方，都可以拿来当节点用。于是，一个很自然的方向就出现了：用免费容器平台来跑节点。一、为什么这件事是可行的先把逻辑拆清楚：Xboard-Node：提供“可容器化的节点程序”容器平台：提供“运行环境 + 公网出口”两者组合之后：节点 = 一个可以随时部署的容器实例这意味着：不再依赖 VPS可以随时创建 / 销毁可以分散部署也就有了“低成本备用节点”的可能。二、ClawCloud Run 简单说明这里用的是 ClawCloud Run。可以把它理解为一个支持 Docker 的在线运行环境：可以直接部署容器镜像提供每月5美刀免费额度IP属于国内厂商阿里云（稳定性高）对节点来说，这已经足够。三、整体结构整个方案结构如下：Xboard 面板 ↓Xboard-Node（Docker） ↓ClawCloud Run（运行环境）流程也比较简单：面板创建节点获取 node\_id / api\_key容器平台部署节点填入参数上线四、注册ClawCloud Run1. 注册目前，只要你的GitHub账号注册超过 180 天，通过 GitHub 注册即可享受每月 5 美元的免费额度，无需任何信用卡或其他认证。注册点击右上角get started去注册账号这里给大家看下翻译的图片，就是说不管用哪种注册都有5美金首月，但你要是想要持续使用，必须绑定一个超过180天的Github账号，其实这个并不难，只要前几年玩过互联网基本都有，没有闲鱼可以找找有没有卖的这里我图方便直接选Github登录，注册完成后选择skip直接跳过新手教程，接下来来到最重要的一步2. 查看免费额度点右上角头像，点击Plan主要是看有没有5美刀的Monthly Gift，如果没有显示，请在 Account Setting 中检查是否绑定了 GitHub 账号，或者 GitHub 账号是否超过 180 天。五、部署步骤1. 面板准备在 Xboard 后台创建节点，获取：API 地址API Key（系统设置中）Node ID（自定义节点ID）这里建议使用Hysteria2，不知道我操作问题还是什么，稳定的anytls没法使用，只能用hy2了服务器名称指示(SNI)和节点地址与连接端口先随便填，等会需要改服务端口必须是84432. 创建容器服务在 ClawCloud Run中找到App Lachunpad点开它，点击Create a app自己取个名，然后Image输入ghcr.io/cedar2025/xboard-node配置默认，把public access打开，左边端口改为8443，右边改成udp协议来到最关键一步，设置Environment Variables，点击右侧AddapiKey= nodeID= apiHost=再点击Add确认配置，最后确认无误点击右上角Deploy Application3. 更改面板配置把这个public address复制下来，如我的是udp://udp.us-east-1.clawcloudrun.com:39088那么我的服务器名称指示(SNI)和节点地址与连接端口就分别是udp.us-east-1.clawcloudrun.com，udp.us-east-1.clawcloudrun.com和39088，填写完毕后先别关闭，点击高级设置，在tls选项卡中选择自签名证书然后填写和你节点地址一样的链接，点击save4. 验证是否上线去clawcloudrun中restart一下容器，然后刷新你的订阅url，查看是否有你的节点出现查看延迟是否正常，能测出延迟基本就算成功了，打开vpn，访问ip.sb或ping0.cc等查看ip的网站看到是美国阿里云的ip就说明成功连接clawcloudrun的机器了，当然ip是随机的，如果不满意就restart容器，不过防失联还能有啥要求呢六、免费额度与流量说明ClawCloud Run 并不是“免费机器”，而是：按资源使用扣费的免费额度模式消耗来源主要包括：CPU 使用时间内存占用时间网络流量其中最关键的是：流量消耗最大实际可用流量根据使用经验：每月大约在 10GB 左右量级具体数值会有波动，不建议卡死。使用建议建议搭配以下策略：只作为备用节点不长期跑高流量控制用户数量或限速
AI摘要 SmartTranslate 是一款 Typecho 插件，用于后台批量生成文章英文翻译，并将结果存储在自定义字段中。该插件支持 OpenAI 兼容接口，允许手动编辑译文，并优先在 Handsome 主题下使用。相比前台实时翻译，此方案访问更稳定，不影响用户体验，适合中文博客兼顾英文访客的场景。 此内容根据文章生成，仅用于文章内容的解释与总结 如果你平时主要用中文写博客，但又希望英文访客能看懂文章内容，那么 SmartTranslate 这类“后台预生成英文翻译”的方案，会比前台实时调用 AI 更适合长期使用。这个插件是基于 Typecho 做的一个文章翻译增强插件，核心思路很简单：原始中文文章保持不变后台批量生成英文翻译英文结果写入 Typecho 自定义字段前台直接读取英文内容用户可在主题设置面板里切换显示英文目前这套方案主要在 Handsome 主题 下使用和调试，其他主题暂未测试。插件特点SmartTranslate` 目前的主要功能包括：支持通过 OpenAI 兼容接口生成英文翻译支持后台批量生成文章英文内容支持把翻译结果保存到 Typecho 自定义字段支持手动编辑英文标题和英文正文前台不实时请求 AI，访问更稳定可接入 Handsome 主题右侧小齿轮设置面板适合“中文原文 + 英文展示”的博客场景和前台实时翻译相比，这种方式的优势很明显：不容易卡页面不影响访客阅读不暴露 API Key译文可人工修订更适合正式博客环境适用场景这个插件更适合下面这类博客：主要写中文技术文章想兼顾英文访客阅读不想维护一篇文章两份内容希望翻译结果可以后续人工修改使用 Typecho 搭建个人博客当前主题为 Handsome需要说明的是：当前版本主要适配 Handsome 主题，其他主题暂未做完整兼容测试。如果你不是 Handsome 用户，建议先在测试环境自行验证。工作原理插件当前采用的是“后台生成，前台读取”的思路。完整流程如下：在后台配置翻译接口后台批量生成文章英文翻译插件把英文标题和英文正文写入 Typecho 字段前台根据访客环境或手动开关决定是否显示英文如果需要，还可以继续手动编辑译文也就是说，前台本身不负责“翻译”，只负责“展示已经生成好的英文内容”。翻译结果存储方式插件不会修改原始文章正文，而是把英文内容保存到 Typecho 自定义字段中。当前使用的字段名是：smart_translate_en_title smart_translate_en_body含义如下：smart\_translate\_en\_title：英文标题smart\_translate\_en\_body：英文正文 HTML这样做的好处是：原始文章不受影响Typecho 原生结构兼容性更好方便手动编辑和备份以后也更方便扩展其他语言安装方式把插件目录上传到：/usr/plugins/SmartTranslate/然后进入 Typecho 后台，在插件列表中启用它。插件配置教程启用后，先进入插件设置页，配置翻译接口参数。1. 启用插件先确认插件已开启。如果你刚修改过代码或接口参数，建议重新保存一次配置。2. API Key填写你的接口密钥3. Provider URL填写兼容 OpenAI 的接口地址，例如：https://api.openai.com插件会自动兼容常见写法。4. Model填写你要使用的模型，例如：gpt-4o-mini如果你使用的是第三方兼容服务，也可以填该服务支持的模型名。5. 请求超时如果文章较长，建议把请求超时设置得宽松一些。推荐值：60如果你的接口响应较慢，可以适当调高。6. 调试日志测试阶段建议开启，便于排查：接口超时返回为空模型名称不支持翻译未写入字段等功能稳定后再关闭。使用方法1. 后台批量生成英文翻译进入插件后台管理页后，可以对文章执行批量英文翻译生成。插件会读取文章原文，生成英文标题和英文正文，并保存到对应字段中。2. 编辑已生成的英文内容如果你希望对翻译做人工润色，可以点击文章标题或文章 CID，进入翻译编辑页。在这里你可以修改：英文标题英文正文修改后保存即可，前台读取的就是你最终保存的版本。3. 前台显示英文内容当前台检测到英文环境，或者用户手动开启英文显示时，插件会优先读取字段中的英文内容并展示。如果某篇文章还没有生成英文翻译，则前台仍然显示中文原文，不影响正常访问。Handsome 主题适配说明这套插件目前主要面向 Handsome 主题 使用。目前适配内容主要包括：接入右侧小齿轮设置面板在主题设置面板中放置英文显示开关支持文章页与列表页的英文内容切换尽量兼容 Handsome 的前端交互方式但仍需说明：目前仅确认 Handsome 主题适用，其他主题未测试。如果你使用的是其他 Typecho 主题，可能会遇到下面这些情况：设置面板无法正常挂载文章标题选择器不匹配列表页英文标题不显示PJAX 逻辑不兼容所以非 Handsome 用户建议优先自行测试。为什么选择“后台预生成”而不是“前台实时翻译”一开始更容易想到的方案，通常是访客打开页面时直接调用 AI 翻译。但这种方式在博客场景下问题很多：首次访问容易卡页面滚动和交互可能受影响PJAX 场景容易出现切换异常接口超时会直接影响阅读体验成本不可控所以当前版本选择了更稳妥的方式：后台生成字段存储前台只读这更适合技术博客、个人站点和长期维护。当前版本说明目前这套插件更适合这样使用：用中文写文章后台统一生成英文版需要时再手动修正文案前台给英文访客展示英文内容它不是完整的多语言博客系统，而是一个更偏“英文展示增强”的方案。后续可扩展方向如果后面继续完善，可以考虑增加这些功能：1. 支持更多语言例如：日文韩文法文2. 增加翻译状态标记例如：未生成已生成已人工修订3. 原文更新后提醒重新翻译如果中文原文修改过，可以提示重新生成英文内容。4. 多语言 SEO 支持例如：hreflang独立英文路由英文页面 meta 信息文件下载[hide]下载[/hide]