日记记录

背景与痛点 Chrome 插件审核遇到了一个非常头疼的问题：我的后端 API 和业务网站统一部署在国内的一台服务器上。因为某些原因，这台服务器的 IP 被海外阻断了。这就导致 Google 官方的审核员在审核插件时，根本无法请求到后端数据，核心功能判定不可用，审核直接被拒。 摆在我面前的有几个选择： 海外重新部署一套：太折腾，数据难以同步，两边维护代码极其痛苦。 常规反向代理：买一台香港服务器，装 Nginx、配置 SSL，再通过各种内网穿透工具把国内的 80 端口映射出去。但这会带来一个致命问题：国内这边的业务还要正常服务国内用户，国内本地的 SSL 和强制 HTTPS 绝不能关。如果在香港再套一层 SSL，会导致无限的 301 重定向 死循环。 为了实现单边维护、完美兼容国内用户、且让香港中转站极致省资源，我摸索出了一套基于 Gost V3 + KCP 协议的无面板极简透传架构。 终极架构思路 抛弃复杂的七层 HTTP 反代，直接做纯粹的四层 TCP 数据流透传。让香港的服务器变成一个“没有任何感情的数据管道”。 Google 审核员 -> 香港 VPS 公网 443 端口 (由 Gost 直接接管) -> UDP KCP 加密隧道 -> 国内本地 Gost -> 国内 Nginx 443 端口 (本地处理 SSL 解密) 这套架构的三大核心优势： 去 Nginx 化，极致省资源：香港服务器不需要装宝塔，不需要装 Nginx，只要有个 Docker 环境就行。买最便宜的 1核 512M 纯净系统 VPS 即可，内存占用不到 30MB。 原汁原味的 SSL 握手：香港只负责搬运加密的数据包，所有的 SSL 证书解密、多域名 Host 路由识别，全部在国内服务器 Nginx 本地完成。国内用户直接访问，海外用户通过隧道访问国内，两者体验完全一致。 抗 QoS 阻断：跨境 TCP 长连接很容易被运营商阻断（表现为 timeout 或连不上），我们将隧道的底层通信协议换成了基于 UDP 的 KCP 协议，抗丢包能力极强，速度起飞。 避坑指南：为什么不选 Gost V2 的 RTCP？ 在最初的尝试中，我使用的是 Gost V2（ginuerzh/gost），试图通过 rtcp（反向 TCP）让国内去“控制”香港开启 443 端口。但这带来了无数的坑： 端口冲突：如果国内端用了 host 网络模式，rtcp 指令很容易让 Gost 误以为要在国内本地监听 443，直接和宝塔 Nginx 撞车报错 address already in use。 协议限制：服务端和客户端的 rtcp 监听指令如果不匹配，外网访问就会报 Connection refused 或者内部路由报 missing address。 内网穿透隔离：如果不使用 host 模式改用 bridge 桥接网络，Gost 容器又会被宿主机（宝塔）的防火墙拦截，报 dial tcp 172.17.0.1:443: i/o timeout。 最终的解法是：全面拥抱 Gost V3（gogost/gost），并将两边角色对调，改用正向 Relay 隧道！ 完整落地教程 第一步：国内（源站）配置为服务端 国内的 Gost 负责开门接客，拿到数据后直接敲本地 127.0.0.1:443 的门。因为没有了抢占端口的问题，直接使用 network_mode: "host"，完美绕过本地 Docker 桥接网卡的防火墙拦截。 第二步：香港（中转站）配置为客户端 买一台海外纯净 VPS，装好 Docker。这台机器上的 Gost 负责霸占公网 443，然后无脑往隧道里塞数据。 第三步：启动与解析 最后，去你的域名注册商那里，把 Chrome 插件使用的域名，解析到香港服务器的 IP上。 总结 通过这一套折腾，业务代码一行没改，国内的服务器依旧是唯一的“真神”。海外流量走香港 UDP 隧道，国内流量直连。Chrome 审核员也能正常访问插件了，完美通关！...

该项目，完全本地运行，无需联网依赖。 本项目使用 Hugging Face Transformers 的 CLAP（`laion/clap-htsat-fused`）对音频进行多维分析，目标是： - 对一批待打分歌曲生成可排序的综合评分与标签，筛选更适合做 AI MV 推广的曲目 - 对歌曲进行提示词反推，辅助音乐制作/复刻方向的定位 - 统一导出 Excel 报表，便于快速浏览、筛选与运营决策 功能概览 - AI综合好听评分（0~100）：基于音频-文本相似度的加权评分 - 曲风识别：输出“最可能曲风”并给出曲风 Top3 候选 - 反推创作提示词：从提示词库中匹配最相近的一条，便于复刻创作 - AI MV 推广筛选（更偏运营/投放）：输出声学特征、AI MV 推广适配评分、情绪/视觉风格/平台 Top3 与剪辑建议 - Python：建议 3.10+（项目当前在 3.13 环境下运行过） 报表字段说明（核心） - 歌曲名称：源文件名 - AI综合好听评分：0~100 的综合评分 - AI MV推广适配评分：0~100，偏向节奏清晰、能量稳定、易卡点的曲目 - 精细化识别曲风：Top1 曲风标签 - 曲风Top3：Top3 曲风候选（用于降低单标签误判） - 情绪氛围Top3：用于 MV 视觉/文案定位 - MV视觉风格Top3：用于 AI MV 画面风格选择 - 推荐平台Top3：用于投放与分发渠道参考 - 剪辑建议：基于节奏与能量的剪辑策略提示 - 主调/BPM/节奏强度/能量均值/能量波动/亮度均值/时长秒：用于更细粒度的制作与运营筛选 - AI同款音乐复刻创作提示词：反推提示词（从提示词库匹配而来） 部分代码： import os import sys import torch import librosa import numpy as np import pandas as pd from transformers import ClapModel, ClapProcessor # ===================== 0. 终端编码兼容（Windows 控制台 GBK/CP936） ===================== def configure_console_output(): """ 配置标准输出/错误输出的编码容错策略，避免 Windows 控制台（如 GBK/CP936） 在打印包含特殊符号/表情字符时触发 UnicodeEncodeError。 """ for stream in (sys.stdout, sys.stderr): try: if hasattr(stream, "reconfigure"): stream.reconfigure(errors="replace") except Exception: pass configure_console_output() # ===================== 1. 设备自动选择 ===================== device = "cuda" if torch.cuda.is_available() else "cpu" print("当前运行设备：", device) # ===================== 2. 加载本地CLAP模型（全程离线） ===================== model_name = "laion/clap-htsat-fused" processor = ClapProcessor.from_pretrained(model_name) model = ClapModel.from_pretrained(model_name).to(device) model.eval()...

当AI成为创作主力，普通人也能轻松拥有属于自己的原创音乐专辑。今天，我的第四张全AI独立创作音乐专辑正式登陆网易云音乐，从灵感落地、提示词打磨、旋律编曲、歌曲生成，全程由豆包+Suno协作完成，无任何人工作曲、编曲、演唱参与，真正实现100%AI原生音乐创作。 这不是简单的AI拼接，也不是翻唱改编，而是从0到1的完整专辑创作。接下来，我把「豆包生成提示词→Suno生成完整歌曲→网易云上线专辑」的全流程毫无保留分享，帮每个热爱音乐的人，用AI圆一张专辑的梦。 一、豆包×Suno，打通AI音乐全链路 在尝试多款AI创作工具后，我确定了豆包+Suno的最优组合，两者分工明确，完美衔接创作全流程： 豆包：担任AI音乐策划师+提示词工程师，负责梳理创作灵感、定制Suno精准提示词、撰写专辑歌词、规划专辑风格与曲目结构，把模糊的情绪想法，转化为音乐AI能精准识别的专业指令。 Suno：担任AI音乐制作人，一键将文字提示词转化为带旋律、编曲、人声的完整歌曲，无需乐理基础、无需乐器设备、无需录音棚，快速产出可上线的成品音乐。 二者配合，实现想法→文字→音乐→专辑的全自动化创作，让音乐创作不再被技术门槛阻挡。 二、第一步：豆包加持，把灵感变成Suno可用的提示词 很多人用Suno生成音乐效果不佳，核心问题是提示词过于笼统，AI无法精准理解创作需求。而我的解决方案，是全程交给豆包，只需要简单描述需求，就能获得可直接复制使用的专业提示词。 1. 给豆包的核心创作指令 我仅用极简需求，就能让豆包输出专辑级创作方案，指令参考： 你是专业AI音乐提示词工程师，擅长为Suno生成高质量可直接使用的创作提示词。请围绕我的专辑创作需求，输出专辑名称、7首歌曲歌单、每首完整风格控制、适配SunoV5.5的精准提示词，明确歌曲风格、情绪、BPM、人声类型、乐器配置，要求风格统一、结构清晰，可直接用于整张专辑创作。 2. 豆包输出的标准化创作内容 豆包会一次性完成全套专辑规划，每首歌都包含完整信息： • 歌曲名称：贴合专辑主题，有记忆点 • 歌词内容：精准的标签控制 • 风格定位：流行/治愈/电子/民谣等精准划分 • 核心参数：BPM数值、人声类型、编曲乐器配置 Suno直用提示词：英文提示词，包含旋律、编曲、音效等细节，复制即可用 3. 批量生成专辑，效率拉满 只需要告诉豆包专辑主题、歌曲数量、整体风格，它就能自动生成一整套专辑内容，无需逐首构思，我只需要筛选确认，5分钟就能完成专辑前期所有文字创作。 三、第二步：Suno一键生成，从提示词到完整歌曲 这一步全程零门槛，哪怕不懂任何音乐知识，也能轻松做出专业歌曲，我的操作流程简单可复制： 1. 登录Suno平台，进入Custom自定义创作模式 2. 粘贴豆包生成的完整歌词 3. 粘贴豆包定制的精准提示词 4. 选择人声性别 5. 点击生成，等待1分钟左右，即可获得完整歌曲 生成的歌曲包含完整的Intro、主歌、副歌、桥段、Outro结构，编曲层次丰富，人声自然有情感，支持直接下载wav格式，完全满足音乐平台上线标准。我整张专辑的所有歌曲，均通过这个流程快速生成，全程不超过30分钟。 四、第三步：从AI歌曲到网易云专辑，完整上线流程 生成所有歌曲后，我按照以下步骤，快速完成专辑整理与网易云上传： 1. 确定专辑信息：敲定专辑名称、封面（可通过AI生成）、曲目排序、专辑简介 2. 整理歌曲文件：统一音频格式、编辑歌曲信息、排版歌词文本 3. 网易云音乐人后台上传：上传音频文件、填写歌曲与专辑信息、提交审核 4. 审核通过上线：等待平台审核完成，专辑正式上架，可生成专属专辑链接 从歌曲生成到专辑上线，全程不超过1小时，彻底颠覆传统专辑制作的漫长周期与高昂成本。 五、AI创作的专辑，到底有多接近真人创作？ 实测盲听测试中，大部分人无法分辨这是AI生成的音乐。专辑中的歌曲旋律流畅有记忆点，有情感有故事，编曲层次分明，完全具备原创音乐的质感与听感。 对我而言，AI早已不是娱乐工具，而是靠谱的创作伙伴，它让音乐回归表达本身，让每个有想法、有情绪的人，都能把内心的故事唱成歌。 六、打破门槛：AI让每个人都能做自己的专辑 曾经，制作一张专辑需要作词、作曲、编曲、录音、混音、乐手、棚时等无数环节，成本高、门槛高，普通人几乎无法触及。 而现在，AI把这一切简化到零门槛： ❌ 不需要会乐器 ❌ 不需要懂乐理 ❌ 不需要专业设备 ❌ 不需要高额资金 你只需要有想表达的情绪、想讲述的故事，借助豆包+Suno，就能轻松完成属于自己的原创专辑。这也是我创作AI专辑的意义——让音乐创作，成为每个人都能拥有的权利。 七、我的第四张AI原创专辑，正式上线网易云 目前，这张由豆包策划+Suno生成的全AI独立创作专辑，已在网易云音乐正式上线。 每一首曲目都是AI独立完成编曲，没有任何人工干预。这是AI时代，送给每个热爱创作的普通人的礼物。 成本：豆包免费；suno我用的官方版本，月付10美金大约可以创作500首。 《Ocean of Solitude》专辑介绍： 专辑介绍： 这是一张关于“深海”的现代纯音乐OST。它不是对海洋的记录，而是对内心孤独的隐喻。整张专辑利用合成器音色，结合实地录音般的空灵鲸鸣，构建了一个与世隔绝的声学空间。在这里，现代工业乐器与原始的自然声音完美融合。 灵感故事： 在这个世界上，每个人都是一座孤岛，而深海，是孤独最极致的具象化。 故事的主角是一个在现实世界中感到失语的灵魂，在一个风暴过后的夜晚，他走向大海，任由自己沉入深渊。随着下潜深度的增加，光线消失，声音变得扭曲而遥远。 穿过洋流的叹息和深渊凝视，主角经历了灵魂的震荡与重压，最终在归于虚无中，化作深海的一部分。他不再孤独，因为他已经成为了这片寂静蓝海本身。这张专辑，就是他下沉过程中听到的声音——凄凉、空洞，却又美得令人心碎。 专辑试听：...

基于 Node.js 的智能翻译服务，通过接入阿里百炼大模型 API 提供高质量的在线文本翻译能力。 变更与信息 2026-03-31 翻译服务全面重构 后端重构 ：废弃了旧的翻译工作流与连接方式，全面迁移至阿里百炼 API (DashScope)。 新增 /api/translate POST 路由，接收规范化的 JSON 参数 { q, s, d }。 服务端自动构建大模型 Prompt 进行高精度翻译，只返回翻译结果。 前端重构 ： 采用现代化设计风格（类似 DeepL / Google Translate）完全重写了 public/index.html 和 public/style.css。 实现了左右/上下分栏响应式布局，支持源语言和目标语言的快速切换。 添加了一键复制、字符统计、防抖输入自动翻译等提升用户体验的交互功能。 语言支持更新： 提取并格式化了最新的支持语言列表（共计 190+ 种语言），包含准确的 ISO-639 代码。 前端通过 languages.js 动态渲染下拉选项，不再硬编码语言列表。 技术栈 后端：Node.js, Express, Axios 前端：原生 HTML/CSS/JavaScript (无框架，极致轻量) 大模型 API：阿里百炼 (DashScope) qwen-plus-latest...

前端的皮目前没有换，依旧沿用了上一版的设计，但这个版本把后端的Maccms整个剔除了，采用完全独立的采集程序+后端API。 我只能说：时代变了，大人们！ Maccms作为一款开源的CMS来说，诸多方面都非常优秀，但是核心代码存在加密，半夜偷偷跳广告，仍然成为了很多的人心中的痛。 看过诸多开源项目最后都不了了之或各种投毒事件后，我觉得开源变了，使用人的心也变了。 本项目不开源也不售卖，仅自用。 🏗️ 架构理念 NMcms：现代化微服务架构 前后端完全分离，独立部署 支持容器化部署和弹性扩容 采用最新的设计模式和最佳实践 支持DevOps和CI/CD流程 🛠️ 技术栈对比 NMcms技术栈： 后端：Python 3.11 + Node.js 18+（双引擎驱动） 前端：原生JavaScript ES6+ + CSS3 + HTML5 数据库：MySQL 8.0 + Redis 7.0 部署：Docker + Nginx + PM2 没有任何开源或出售源代码的计划。 时代变了，你应该让AI给你写，本项目从0到1，端到端完全由AI完成。 播放器基于西瓜播放器二次开发的P2P服务，所以播放更快。...

After wrapping up a side project to create a proxy service for WordPress's mShots screenshot API, I realized I never documented the journey. This post serves as that missing blog entry – a look back at the why, the how, and the lessons learned from building a tool to serve website thumbnails reliably. The Problem: Unreliable Thumbnail Generation The core issue was straightforward: relying directly on WordPress.com's public mShots API for generating website screenshots in my applications was becoming inconsistent. The service, while powerful, is primarily intended for WordPress.com itself and its official plugins. For third-party or high-volume use, requests could be throttled, fail silently, or return mixed content errors when served over HTTPS. I needed a reliable middle layer – a proxy. This proxy would handle requests from my application, manage communication with the mShots API, implement caching to respect rate limits, and serve the images securely. The goal was to abstract away the volatility and provide a consistent interface for my projects. Architecting the Solution The architecture drew inspiration from the original mShots service structure, which is split into a request-handling PHP class and a Node.js processing service. My proxy simplified this into a single-service model focused on…...

之前一直用的这个项目来中转docker镜像到阿里云，然后再给国内的服务器使用，后来发现github有点拉，而且github到阿里云经常失败。 我们恰好有一台CN2的香港杜甫，运行着团队项目使用的Gitea，本来就有Act runner，然后就想着这样管理起来方便点。 就稍微修改了一下docker.yaml，让它可以在gitea中使用。 name: Docker​on: workflow_dispatch: push:   branches: [ main ]​​env: ALIYUN_REGISTRY: "$ secrets.ALIYUN_REGISTRY || vars.ALIYUN_REGISTRY " ALIYUN_NAME_SPACE: "$ secrets.ALIYUN_NAME_SPACE || vars.ALIYUN_NAME_SPACE " ALIYUN_REGISTRY_USER: "$ secrets.ALIYUN_REGISTRY_USER || vars.ALIYUN_REGISTRY_USER " ALIYUN_REGISTRY_PASSWORD: "$ secrets.ALIYUN_REGISTRY_PASSWORD || vars.ALIYUN_REGISTRY_PASSWORD " DOCKER_HOST: "unix:///run/docker.sock"​jobs:​ build:   name: Pull   runs-on: ubuntu-22.04   steps:   - name: Before freeing up disk space     run: |       echo "Before freeing up disk space"       echo "=============================================================================="       df -hT       echo "=============================================================================="​    # 增加可用磁盘空间   - name: Maximize build space (Gitea-safe)     run: |       echo "Prune Docker to free space (no sudo)"       docker system df || true       docker builder prune -af || true       docker system prune -af || true​   - name: Free up disk space complete     run: |       echo "Free up disk space complete"       echo "=============================================================================="       df -hT       echo "=============================================================================="​   - name: Ensure Docker CLI     run: |       if command -v docker >/dev/null 2>&1; then         docker -v      …...

从0到1去做一个cms是有点麻烦的，但是可以围绕MacCms为后端打造一个新的程序，使用CMS的官方接口获取数据，从根源上避免了主题和程序的挂马或暗跳的问题。 而且支持自定义播放器，可以从官方接口获取到的数据都可以使用。 市面上的moonTV和一些其他的产品都是针对资源站的，资源站现在会封IP，请求访问量大很不友好，但是他们的程序在对接CMS的时候都没法切换CMS的播放组。 折腾了半天，最后自己写了个…… 静态的，使用的nodejs。 你现在可以购买这份完整的代码，没有加密的，支持二次开发。 你会得到一份不会跳广告的干净前端+包含81667条数据的Maccms MYSQL数据库 或适配自己的Maccms 联系方式 Telegram 1888元 谢绝议价。内容数据截止时间为2026年3月17日。 目前已经丢弃maccms，使用自研服务。 国内贩子转手倒卖情况泛滥，所以后续没有开源，也不会开源。...

项目缘起 最近在处理网站时，遇到一个棘手的问题：大量依赖的外部 CSS/JS 资源（如字体图标库、统计脚本、公共 CDN 的库文件）经常因为防盗链策略或 CDN 节点不稳定导致加载失败。最糟糕的是，有些资源链接直接失效了，影响了线上业务的稳定性。 于是有了这个想法：为什么不把这些外部资源永久缓存到自己的服务器上？ 既能避免防盗链限制，又能确保资源长期可用。这就是 Asset Cache Server 诞生的初衷。 核心功能设计 这个项目是一个轻量的 Node.js 服务，实现了几个关键特性： 1. 智能 URL 映射与目录保留 我们没有简单地把所有文件堆在一个文件夹，而是按原始 URL 的目录层级保存。比如 https://cdn.example.com/lib/v1/jquery.min.js 会完整保存在 ./cache/lib/v1/jquery.min.js。这样做的好处是： 结构清晰，便于手动管理 避免不同站点的同名文件冲突 符合开发者直觉，找文件时一目了然 2. TXT/JSON 批量抓取 在根目录放置一个包含 URLs 列表的 TXT/JSON 文件，服务会自动读取并批量下载。每行一个 URL，支持注释（# 开头）。对于需要迁移大量资源的场景，这节省了大量手动操作。并且所需资源的内容可控，避免被污染。 3. 去重跳过机制 通过检查本地文件是否存在，自动跳过已缓存的资源。重复运行也不用担心产生冗余文件或覆盖已有内容。 4. 公共路径自动生成 最贴心的设计是返回格式化的引用路径。抓取完成后，控制台会输出： 公共路径: /cache/lib/v1/jquery.min.js 完整 URL: https://my-cdn.com/cache/lib/v1/jquery.min.js 直接复制就能在项目中使用，无需手动拼接路径。 技术实现要点 选择 Node.js 是因为： 异步 I/O 适合批量网络请求 生态丰富，有 axios、fs-extra 等趁手工具 部署简单，一条命令即可启动 核心流程很清晰： 读取 TXT/JSON → 2. 校验 URL → 3. 生成本地路径 → 4. 检查是否已存在 → 5. 下载并保存 → 6. 返回引用地址 特别处理了路径生成逻辑，确保不同操作系统的路径分隔符兼容性。 与 CDN 防盗链的完美配合 这个项目最大的价值在于配合 CDN 防盗链使用。 我们可以： 将外部资源抓取到本地服务器 通过自己的 CDN（开启防盗链）分发 既保护了资源安全，又避免了外部链接的不确定性 相当于在自由开放的互联网资源和自己的业务之间建立了一道可控的缓冲层。 部署方式 Debian 12 / Node 22.19.0（生产）： 创建 .env 设置端口：PORT=<你的端口> npm install && npm start 建议使用 systemd/pm2 守护进程，并在 Nginx 反向代理到 127.0.0.1:<PORT> 思考与收获 这个项目，对静态资源管理有了更深的理解： 依赖外部资源 = 把稳定性交给别人。即使是知名 CDN，也可能因政策、网络问题影响你的业务。 简单的方案往往最有效。没有引入复杂的数据库或缓存策略，仅靠文件系统就解决了核心问题。 开发者体验很重要。返回可直接复制的路径这个小功能，让工具用起来格外顺手。 项目仓库：https://ckk.photo8.site/Photo8/Asset-cache...

新版本存在恶意的随机添加js文件投毒的问题，目前会导致晚上偷偷跳大人网站，如果实在难以解决的，还是换个程序吧…… 1.删除，application/admin/controller/Update.php 更新： 一定要删除这个文件！ 2.同目录Safety.php 修改file() public function file()   {        $param = input();        if($param['ck']){            $ft = $param['ft'];            if(empty($ft)){                $ft = ['1','2'];           }            mac_echo('<style type="text/css">body{font-size:12px;color: #333333;line-height:21px;}span{font-weight:bold;color:#FF0000}</span></style>');        // 注释掉远程文件检查功能        // $url = base64_decode("aHR0cDovL3VwZGF0ZS5tYWNjbXMubGEv") . "v10/mac_files_".config('version')['code'].'.html';        // $html = mac_curl_get($url);        // $json = json_decode($html,true);        // if(!$json){        //     return $this->error(lang('admin/safety/file_msg1'));        // }​        $this->listDir('./');        if(!is_array($this->_files)){            return $this->error(lang('admin/safety/file_msg2'));       }​        // 本地文件完整性检查        $total_files = count($this->_files);        $check_results = [];                foreach($this->_files as $k=>$v){            $file_path = ltrim($k, './');            $file_size = filesize($k);            $file_md5 = $v['md5'];            $file_perms = substr(sprintf('%o', fileperms($k)), -4);                        // 检查文件是否可读  …...