EchoPing's Blog

为骁龙410棒子换上 Alpine 系统

Tue, 21 Jul 2026 00:00:00 +0000

本教程面向小白，大部分工作都借助如codex，opencode等 AI Agent 工具完成操作。

利用现成的 Debian 刷机包，只替换 rootfs，得到更轻量的 Alpine 系统。应该适用于所有有可用 Debian 包的骁龙410 随身 WiFi 设备。

操作流程

1. Fork 仓库并克隆到本地

Fork kinsamanka/OpenStick-Builder 到自己的 GitHub 账号。注意：Fork 时取消勾选「仅复制 main 分支」，我们需要 alpine 分支。

Fork 完成后把 alpine 分支克隆到本地（建议将 Fork 后的仓库地址告诉 Agent，由 Agent 完成克隆，避免分支选错等问题）。

`1`	`克隆 https://github.com/kinsamanka/OpenStick-Builder 的 alpine 分支到本地，先不要改代码，阅读这个项目结构，说明主要目录、使用方式`

这里的项目地址需要替换为你 Fork 后的仓库地址

2. 准备工作区

在工作区放两个文件夹：

1
2
3

工作区/
├── OpenStick-Builder/    ← 克隆的项目（alpine 分支）
└── 刷机包/               ← 你的设备的完整 Debian 刷机包（含 boot.img、rootfs.img等）

刷机包就是你设备当前能用的那个 Debian 刷机包。

3. 复制提示词，发送给 Agent

打开你的 AI Agent，把工作区两个文件夹都加进去，然后复制发送下面的提示词（系统配置按需修改）：

请先不要改代码，先阅读 OpenStick-Builder 项目代码，理解项目结构。

背景：
- 刷机包文件夹里是一个可用的 Debian 一键刷机包（MSM8916 平台）
- 项目代码里已经有完整的构建脚本（alpine 分支）
- 我需要你帮我把这套构建适配到我的设备

你要做的事：
1. 从刷机包的 rootfs.img 里提取内核模块（/lib/modules/ 整个目录）和WiFi 固件（/lib/firmware/ 下的 wcnss.b00-b11、wcnss.mdt、wlan/prima/WCNSS_qcom_wlan_nv.bin、mba.mbn、qcom/a300_*.fw、qcom/venus-1.8/），放到项目的 prebuilt/<设备名>/ 对应目录。
2. 从刷机包复制底层固件（aboot.bin、gpt_both0.bin、hyp.mbn、rpm.mbn、sbl1.mbn、tz.mbn 等）到 prebuilt/<设备名>/，供 extract_fw.sh 使用。如果刷机包里没有这些文件，可以从工作流中去掉 extract_fw.sh 步骤。
3. 修改构建脚本（alpine_rootfs.sh、extract_fw.sh），把里面的路径改为 prebuilt/<设备名>/
4. 内核模块的目标目录名必须和内核版本字符串完全一致（从 /lib/modules/ 下的目录名获取）
5. 修改主机名、root 密码为我指定的值
6. 修改 .github/workflows/build.yml 里的 artifact 名称为我的设备名

核心规则（违反会导致设备变砖）：
- 绝对不要修改、重新打包、或重新生成 boot.img
- boot.img 直接使用刷机包里的原始文件
- 我们只构建 rootfs.img，boot.img 由刷机包提供

系统配置：
- 主机名：OpenStick
- root 密码：password
- SSH：PermitRootLogin yes，host keys 在宿主机用 ssh-keygen 预生成
- USB 网络：NCM gadget，VID=0x1D6B PID=0x0104，IP 192.168.5.1/24 shared
- WiFi 热点：SSID Openstick，密码 12345678，IP 192.168.4.1/24 shared
- WiFi 模块自动加载：/etc/modules-load.d/wcnss.conf 写入 qcom_wcnss_pil
- 首次启动自动扩容：/etc/local.d/resize-rootfs.start，
  用 awk '$2 == "/" {print $1}' /proc/mounts 获取根设备，resize2fs 扩容
- 不需要 ModemManager（不插 SIM 卡）
- 频率由内核 schedutil 动态管理，不需要额外配置
- 需要安装 e2fsprogs-extra（提供 resize2fs）
- rc-update add local default（否则 local.d 脚本不执行）

构建环境：GitHub Actions ubuntu-latest，qemu-aarch64-static 交叉构建。
Alpine v3.24，postmarketos 仓库 v25.12（msm-firmware-loader、rmtfs）。
rootfs 镜像：512MB ext4，分区标签 rootfs，img2simg 转 sparse。

完成后请检查所有改动是否完整一致，给我总结完成情况。

4. Agent 完成后，推送到仓库

Agent 改完代码后，把改动提交并推送到你 Fork 仓库的 alpine 分支。也可以直接让 Agent 完成提交和推送。

`1`	`提交代码至 Github 仓库的 alpine 分支，并根据当前 git diff，生成一条清晰的 commit message。`

5. 触发 GitHub Actions 构建

打开你 Fork 的仓库页面 → Actions（操作） → 对应的工作流 → Run workflow（运行工作流程） → 选 alpine 分支 → 点绿色按钮。

等构建完成（大约 2 分钟），刷新页面，底部会多出一个 Artifact（附件）。下载附件到本地，里面有构建出的 rootfs.img。如果报错就带着日志发给 Agent ，让他修复后重新推送和触发构建。

6. 处理产物

把下载的附件解压，将 rootfs 复制到刷机包文件夹里，替换原来的 rootfs 。

注意与刷机包的 rootfs 后缀保持一致，如附件中的 rootfs 为 .bin 格式，但是实际刷机包中为 .img 格式，就需要将附件中的 rootfs 修改为 .img 格式。

7. 刷机

运行刷机包原有的脚本刷入即可。

刷入完毕后，Windows 设备管理器里出现「Linux Foundation NCM」网卡即说明启动成功。然后 ssh root@192.168.5.1 登录。

验证是否成功

设备管理器出现 PID:0104 → 正常
设备管理器出现 PID:9006 → 内核未启动，检查 boot.img 是否为刷机包原始文件
能 ping 通 192.168.5.1 → USB 网络正常

出问题怎么办

设备变砖：进入 9008 模式擦除 boot 分区，设备即可自动进入 fastboot 模式
SSH 连不上但设备管理器有 NCM 网卡：等 30 秒再试，首次启动要生成熵和扩容

Tiku-cfw：基于 Cloudflare Worker 的 AI 题库服务

Sat, 18 Jul 2026 00:00:00 +0000

Tiku-cfw 是一个部署在 Cloudflare Workers 上的 AI 题库服务。它兼容 OCS 网课助手的 AnswererWrapper 规范，接收来自 OCS 脚本的搜题请求，先查本地缓存（D1 数据库），命中则直接返回；未命中则调用 AI 模型获取答案，并自动将结果写入缓存。

核心思路：用 AI 模型做题，用缓存省钱。同一道题只消耗一次 Token，之后所有请求都走缓存，响应速度极快。

为什么做这个

OCS 网课助手需要对接题库才能自动答题，但公共题库覆盖率有限，自建题库又需要服务器和运维。Tiku-cfw 利用 Cloudflare Workers 的免费额度和 D1 数据库，实现了零成本、零运维的 AI 题库方案。

AI 模型负责"做题"，D1 负责"记住答案"。第一次遇到新题时调用模型（稍慢），之后同一道题直接走缓存秒回。题目经过归一化处理后做精确哈希匹配，缓存永不过期。

核心特性

OCS 兼容：完全遵循 AnswererWrapper 规范，在 OCS 脚本中填入配置即可使用，无需额外适配。
AI 多渠道调度：支持文本模型和视觉模型两类渠道，按权重调度、最少使用优先轮询，渠道故障自动禁用降级。
智能缓存：题目归一化后精确匹配，命中即返回，永不过期。
图片题目支持：包含图片的题目自动路由到视觉模型渠道处理。
Web 管理面板：仪表盘统计、题库管理、API Key 管理、AI 渠道配置、搜索日志，一应俱全。支持深色/浅色主题。
零成本部署：Cloudflare Workers 免费额度 + D1 免费额度 + GitHub Actions 自动部署，不花一分钱。

技术栈

层级	技术
运行时	Cloudflare Workers
数据库	D1（SQLite）
AI 接口	OpenAI 兼容 API
后端语言	TypeScript
前端	Tailwind CSS + 原生 JS SPA
部署	GitHub Actions → Cloudflare Workers

工作流程

OCS 脚本发起搜题请求
  → Worker 接收，归一化题目文本
  → 计算哈希，查询 D1 缓存
  → 命中 → 直接返回答案（毫秒级）
  → 未命中 → 选择 AI 渠道（按权重 + 最少使用）
           → 有图片？路由到视觉模型
           → 调用模型获取答案
           → 写入 D1 缓存
           → 返回答案

渠道调度策略：多渠道按权重分配请求，同渠道内多 Key 轮询，优先使用调用次数最少的 Key。某渠道连续失败后自动禁用，避免浪费请求。

部署与使用

项目推荐通过 GitHub Actions 自动部署，全程在浏览器中操作，无需安装任何命令行工具。大致流程：Fork 仓库 → 创建 D1 数据库 → 配置 GitHub Secrets → 运行迁移 → 推送触发部署。

也支持命令行部署（wrangler）和本地开发调试。

部署完成后，在管理面板中配置 AI 渠道和 API Key，复制 OCS 配置 JSON 粘贴到网课助手脚本中即可开始使用。

详细的分步部署指南、API 文档、管理面板使用说明都在仓库 README 中。

项目地址

GitHub：https://github.com/EchoPing07/Tiku-cfw

kgcheckin：酷狗概念版 VIP 每日自动签到

Fri, 10 Jul 2026 00:00:00 +0000

酷狗概念版每天可以免费领取 VIP，但需要手动打开 App 听歌、看广告才能完成签到。kgcheckin 把这套流程脚本化，挂到青龙面板上每天自动跑，从此不用再惦记这件事。

为什么做这个

酷狗概念版的 VIP 领取需要每天手动操作：打开 App → 听歌 → 看广告。一天不操作就断签，多账号更是折磨。作为一个青龙面板用户，把这件事自动化是最自然的选择。

核心特性

每日自动签到：自动完成听歌任务与广告任务，无需手动打开 App。
多账号支持：一份环境变量配置多个账号（@ 分隔），一次任务全部签到。
Token 自动续期（可选）：配置青龙 OpenAPI 凭证后，每周日自动刷新 token 并回写环境变量，长期免维护。未配置则跳过刷新，避免 token 提前失效。
日志脱敏：昵称、用户 ID 等敏感信息在日志中自动打码（如 张**三、204***16），token 显示为 [REDACTED]。
通知推送：复用青龙内置的 sendNotify，签到结果直达你已配置的通知渠道（Server 酱、Telegram、企业微信等）。
零 HTTP 服务：脚本以函数调用方式直接请求接口，不启动任何常驻服务，内存占用极低。

工作原理

青龙定时任务触发（每天凌晨 1:10）
  → 读取 KUGOU_CK 环境变量，解析出所有账号
  → 逐账号验证 token 有效性
  → 调用听歌接口领取 VIP
  → 调用广告接口领取 VIP（多次）
  → 查询 VIP 到期时间
  → 汇总结果，发送通知
  → （每周日）刷新 token → 通过 OpenAPI 写回环境变量 → 校验

API 签名和加密模块基于 MakcRe/KuGouMusicApi，包含 MD5、AES、RSA 等酷狗接口所需的加解密逻辑。

Token 续期机制

酷狗的 token 会过期，过期后必须重新抓包。配置自动续期后，脚本每周日运行时会自动刷新 token 并通过青龙 OpenAPI 写回 KUGOU_CK 环境变量。

写回后会再次读取进行校验。如果校验失败（权限不足、网络抖动等），脚本会通过通知渠道把新 token 推送给你，方便手动更新，避免账号断签。

不配置 OpenAPI 凭证时，脚本不会刷新 token，当前 token 在有效期内可以一直正常使用。

技术栈

项目	说明
运行时	Node.js（青龙面板内置）
依赖	仅 axios
加密	MD5 / AES / RSA（酷狗接口签名）
部署	青龙面板订阅管理
通知	青龙 sendNotify

部署与使用

整体流程：在青龙面板添加仓库订阅 → 安装 axios 依赖 → 抓包获取 userid 和 token → 配置 KUGOU_CK 环境变量 → 创建定时任务。

抓包工具推荐：iOS 用 Stream 或 Shadowrocket，Android 用 HttpCanary 或 Packet Capture。过滤 gateway.kugou.com 域名，从请求的 Cookie 或 Header 中提取 userid 和 token。

详细的分步部署指南、环境变量说明、常见问题排查都在仓库 README 中。

常见问题速览

error_code 130012 / 20028 / 30002：这些是"今日已完成"的正常状态码，不是错误。
Cannot find module ‘axios’：依赖没装好，回青龙「依赖管理」重新安装。
多账号只有第一个成功：检查 KUGOU_CK 格式，账号内部用 #，账号之间用 @，不要有多余空格。

Esurfing-go-webui：带 Web 管理界面的天翼校园网认证客户端

Sat, 30 May 2026 00:00:00 +0000

很多学校的天翼校园网需要客户端认证才能上网，原版 Esurfing-go 已经能用命令行完成认证和心跳保活，但配置多张网卡、查看运行状态时仍然离不开手敲命令和编辑配置文件。

Esurfing-go-webui 在它的基础上加了一层 Web 管理界面，把多网卡管理、实时日志、会话恢复这些常用功能做成了可视化操作。单二进制零依赖，下载即用。

解决什么问题

一台设备（软路由、随身 WiFi、宿舍小主机）上往往有多张网卡，每张网卡可能对应不同的认证账号。原版只能靠命令行和配置文件管理，状态不直观，出问题要翻日志；进程崩溃或重启后认证状态丢失，需要重新登录。

Esurfing-go-webui 针对这些痛点，提供了浏览器里就能完成所有操作的管理面板。

相比原版的增强

Web 管理面板

响应式设计，手机、平板、电脑都能正常访问。卡片式展示每张网卡的状态，支持启用/禁用、登录/登出/强制登出等操作。系统网卡自动发现，新增网卡时不用手动猜接口名。

会话持久化与恢复

认证状态、心跳信息会持久化保存。进程崩溃或重启后自动恢复会话、续上心跳，无需重新走一遍完整的认证流程。

实时日志

通过 SSE（Server-Sent Events）实时推送日志到浏览器，支持按级别过滤。日志落盘持久化，自动清理过期条目，避免磁盘被写满。

认证冷却机制

多接口认证间自动冷却，避免短时间内并发认证导致的冲突和异常。

RESTful API

所有界面操作都有对应的 HTTP API，方便接入自动化脚本、Home Assistant 或其他自研工具。

打包与系统集成

提供 Deb 包（systemd 服务）和 Opkg 包（OpenWrt init 脚本），开箱即用，开机自启。

认证流程

了解认证流程有助于排查问题：

HTTP 204 在线检测
  → 302 重定向（未在线）
  → GetSchoolInfo（获取学校信息）
  → GetEConfig（获取加密配置）
  → GetUserAndAcIP（获取用户与 AC 设备 IP）
  → GetAlgoId（获取算法 ID）
  → NewCipher（构造加密器，支持 AES/3DES/SM4/ZUC/XTEA）
  → GetTicket（获取 ticket）
  → Login（登录认证）
  → 心跳保活

会话持久化保存的就是登录后的会话与心跳信息，进程重启后直接续上心跳，跳过前面整套认证流程。

技术栈

项目	说明
语言	Go 1.25.3+
前端	单文件 HTML（embed 嵌入）
加密	SM4 / ZUC 国密算法（gmsm 库）
部署	单二进制 / Deb / Opkg
平台	Linux / Windows / macOS / OpenWrt

支持平台

通过 Go 交叉编译覆盖主流架构：

Linux：amd64、arm（v7）、arm64、mips、mipsle、mips64、mips64le、riscv64
Windows：amd64、arm64
macOS：amd64、arm64

Deb 包覆盖 amd64、armhf、arm64；Opkg 包覆盖 x86_64、arm_cortex-a9、aarch64、mips_24kc、mipsel_24kc。

部署与使用

项目支持预编译二进制、源码构建、Deb 包、Opkg 包等多种部署方式。配置文件为 JSON 格式，支持多网卡独立配置和全局设置。详细的部署步骤、配置字段说明、API 文档都在仓库 README 中。

最简部署：从 Releases 下载对应平台的二进制文件，chmod +x 后直接运行，浏览器访问 http://设备IP:8080 即可。

DNS 注意事项

如果网络环境使用了 DoH（DNS over HTTPS），未认证状态下 DoH 无法工作，会导致认证所需域名解析失败。此时需要在接口配置中手动指定 dns_address（需带端口号，如 119.29.29.29:53），一般填写 DHCP 获取的 DNS 地址即可。

DownOnly：用无害下载流量平衡你的宽带上下行

Thu, 12 Feb 2026 00:00:00 +0000

家里有 NAS 跑 PT 或者做上传服务的朋友，大概率遇到过这种情况：宽带突然被限速，或者接到运营商电话，说你涉嫌"商业 PCDN 经营"。原因很简单——你的上行流量远大于下行，触发了运营商的风控模型。

DownOnly 就是为了解决这个问题而生的。它在设定的时间窗口内从公开源下载数据，然后直接丢弃，制造真实但无害的下行流量，把上下行比例拉回正常范围。

核心思路：不伪造数据、不修改流量统计，而是产生真实的 HTTP 下载行为。运营商看到的就是正常用户的下载流量。

为什么做这个

当前宽带运营环境下，NAS 用户、PT 玩家、自建服务用户由于上传流量与下载流量比例异常，容易被运营商的大数据算法误判为"商业 PCDN"行为，后果包括被限速甚至停网、强制签保证书、频繁接到"警告"电话。

DownOnly 的立场很明确：不推荐浪费公共网络资源，但也不希望合法合规的行为被套上莫须有的罪名。

设计原则

整个项目围绕一个目标：跑了跟没跑一样。

零磁盘写入：所有下载数据直接写入 io.Discard，不产生任何磁盘 I/O。对闪存设备（棒子、电视盒子）完全友好，不损耗 eMMC 寿命。
极低资源占用：运行内存 6-15MB，进程优先级 nice 19（Linux 最低），GOGC=200 减少 GC 频率。512MB 内存的设备也能流畅运行，不会跟你的 PT 客户端抢资源。
不影响其他服务：低优先级运行，带宽可限速，时间窗口可配置。

核心能力

智能调度

自定义每日运行时间段（支持跨午夜），比如只在凌晨 2 点到 6 点跑
每日流量限额区间随机化，避免每天流量一模一样被识别
两次下载之间随机休息，也可禁用休息实现连续下载
程序重启后自动恢复上次运行状态

流量伪装

内置 4 种主流浏览器 User-Agent 自动轮换
多下载源随机切换，单源失败自动重试，全部失败进入休息
流量特征接近正常用户浏览行为

安全防护

默认仅允许局域网访问 WebUI，需手动开启公网访问
下载地址校验：禁止内网/私有地址，DNS 解析后二次校验防止 DNS Rebinding
优雅退出：捕获 SIGINT/SIGTERM，退出前自动保存所有数据

监控与审计

实时 Mbps 速率统计 + 30 秒折线图
按日记录流量并以柱状图展示，支持按月查看历史
日志按天归档，每日上限 1000 条，自动清理 7 天前过期日志
数据自动归档本年度，跨年自动清理

WebUI

深色/浅色模式，自动跟随系统主题
响应式设计，手机、平板、PC 均可操作
所有配置网页端实时修改，无需重启
下载地址管理：添加/删除/批量测试可达性
日志查看器：按日期切换，实时自动刷新

技术栈

项目	说明
语言	Go 1.22+
前端	单文件 HTML（embed 嵌入二进制）
部署	systemd / Docker / 一键脚本
平台	Linux（x86_64 / ARM64 / ARMv7 / ARMv6）
镜像	GHCR + Docker Hub

已测试设备

设备	内存	系统	备注
骁龙410棒子	512MB	Debian 11	内存占用约 6MB，完全无压力
网心云 OEC	2GB	fnOS 1.1.19	Docker 部署，稳定运行

部署与使用

项目提供一键安装脚本、Docker 部署和手动编译三种方式，详细的部署步骤、配置参数说明、API 文档和故障排查指南都在仓库 README 中。

一键安装：curl -fsSL https://raw.githubusercontent.com/EchoPing07/DownOnly/main/install.sh | bash

安装完成后访问 http://设备IP:8080 即可进入 WebUI 管理。

免责声明

DownOnly 仅用于个人学习和研究目的。它产生的是真实下载流量，不涉及任何数据伪造或网络攻击行为。请合理使用，因使用本工具产生的一切后果由使用者自行承担。

项目地址：https://github.com/EchoPing07/DownOnly

有问题欢迎提 Issue，也欢迎 Star 支持。

EchoPing's Blog

为 骁龙410棒子换上 Alpine 系统

操作流程

1. Fork 仓库并克隆到本地

2. 准备工作区

3. 复制提示词，发送给 Agent

4. Agent 完成后，推送到仓库

5. 触发 GitHub Actions 构建

6. 处理产物

7. 刷机

验证是否成功

出问题怎么办

Tiku-cfw：基于 Cloudflare Worker 的 AI 题库服务

为什么做这个

核心特性

技术栈

工作流程

部署与使用

项目地址

kgcheckin：酷狗概念版 VIP 每日自动签到

为什么做这个

核心特性

工作原理

Token 续期机制

技术栈

部署与使用

常见问题速览

相关链接

Esurfing-go-webui：带 Web 管理界面的天翼校园网认证客户端

解决什么问题

相比原版的增强

Web 管理面板

会话持久化与恢复

实时日志

认证冷却机制

RESTful API

打包与系统集成

认证流程

技术栈

支持平台

部署与使用

DNS 注意事项

相关链接

DownOnly：用无害下载流量平衡你的宽带上下行

为什么做这个

设计原则

核心能力

智能调度

流量伪装

安全防护

监控与审计

WebUI

技术栈

已测试设备

部署与使用

免责声明

为骁龙410棒子换上 Alpine 系统