Riowang blog

电视直播 1.2：能切清晰度了，老设备也有包了，但还没测

Tue, 03 Nov 2026 00:00:00 GMT

这个小工具更新到 1.2 了，主要是能切清晰度，老设备也有包可以试了。

先说清楚：老设备的两个包我没有测试过，一次都没在设备上跑过。 能不能打开、能不能出画面，我现在都不知道。家里是新设备的，用小包就够了，不用往下看老设备的部分。

更新了什么#

一、能切清晰度了。 有 1080P、720P、540P 三档。

电视：播放时按遥控器 ▶
手机：点屏幕打开频道列表，点列表最上面那一行

选好之后换台不会变，下次打开也还是这一档。家里网慢、卡顿，切到 540P 试试。走备用线路时固定 720P，切不了。

二、版本要求写清楚了。 这个 APP 靠系统自带的网页内核放视频，内核低于 Chrome 60 就跑不起来。以前只说“建议”，现在打开时会直接告诉你这台设备不支持，不会黑屏让你干等。

三、多了两个老设备的包。 很多老电视、老盒子卡在内核太旧，系统又升不了。这两个包自带内核，不靠系统的，代价是体积从 33KB 涨到 63MB 和 82MB。

该下哪个包#

电视直播-选包图

不知道自己是什么版本也没关系，先装小包。打开提示内核太旧，再去下大包。

两个大包只支持 32 位 ARM，老电视和盒子基本都是这种。

没测试的部分#

电视直播-测试状态图

看直播、换台、频道列表这些，我在一台雷鸟电视和一台小米手机上用过，没问题。

这次新加的清晰度，我只在电脑上验证过网页逻辑：三档都能切，换台后能保持。遥控器按键和手机上的入口，没在真机上按过。

两个大包更没底。我只确认了它们能下载、签名正确、最低系统版本对。它们换了一个内核，等于重写了一遍底层，下面这些都可能出问题：

打开就闪退
能打开，但一直黑屏，出不了画面
能出画面，但很卡。老设备内存小，1GB 内存的盒子尤其悬

手上有老设备的朋友，愿意的话帮忙试试，告诉我型号、安卓版本和结果。能用不能用，都是有用的信息。

下载#

复制到浏览器打开。下面的线路一、线路二都是中转地址，国内一般能直接下。中转站是第三方的，一条打不开就换另一条。

小包（33KB）：新设备用这个

线路一：https://ghfast.top/https://github.com/riowang88/live-tv/releases/download/v1.2/live-tv-v1.2.apk

线路二：https://gh-proxy.com/https://github.com/riowang88/live-tv/releases/download/v1.2/live-tv-v1.2.apk

安卓 5 大包（82MB）：安卓 5.0 到 8.1，小包提示太旧时用，未测试

线路一：https://ghfast.top/https://github.com/riowang88/live-tv/releases/download/v1.2-old-android/live-tv-v1.2-android5.apk

线路二：https://gh-proxy.com/https://github.com/riowang88/live-tv/releases/download/v1.2-old-android/live-tv-v1.2-android5.apk

安卓 4.1 大包（63MB）：安卓 4.1 到 4.4 用，未测试

线路一：https://ghfast.top/https://github.com/riowang88/live-tv/releases/download/v1.2-old-android/live-tv-v1.2-android4.1.apk

线路二：https://gh-proxy.com/https://github.com/riowang88/live-tv/releases/download/v1.2-old-android/live-tv-v1.2-android4.1.apk

GitHub 项目页： https://github.com/riowang88/live-tv

怎么装#

电视、盒子： 下载后拷到 U 盘，用文件管理器打开安装
手机： 浏览器下载完直接点安装
已经装了旧版： 小包直接覆盖安装，不用先卸载

还是那句话：这个 APP 只是打开官方的公开网页，里面不带直播源，节目版权归人家。自己家里看就好，别拿去卖。想要长期稳定，还是装官方的 APP。

Claude 注册、登录和订阅 For Mac

Tue, 03 Nov 2026 00:00:00 GMT

前段时间被 Claude 的封号问题折腾得够呛，我转去用了几个月 Codex。

但最近改自己的项目，总有些地方用得不顺手。一个看起来不大的问题，来回改了很久，偶尔还会顺手扩大需求，越改越偏。这是我在自己项目里的使用感受，不代表每个人都会遇到。

于是，我又想把 Claude 用起来。查资料时，发现了一个开源工具：CCBaga。

它可以检查本机和浏览器环境，也能管理 Claude 的本地账号资料。我用的时候遇到了一些账号切换问题，就在原项目基础上做了修订，调整了 Claude 桌面端、命令行工具的账号保存、切换，以及浏览器资料的联动。

原项目：liseami/CCBaga

我的修订版：riowang88/CCBaga

这篇就把我从注册到订阅的过程记下来，方便有需要的朋友参考。

下面只记录 Mac 上的操作。Windows 我没测过，不保证照着截图就能走通。

至于“防封”，先说清楚：环境检测通过，不代表账号以后不会被封。本文能提供的是一次操作记录，没有“照做就安全”的保证。

一、先准备好网络和邮箱#

开始之前，需要能正常访问 Claude 的网络，以及一个能长期收信的邮箱。🪜的配置不在这里展开。同时注意，🪜建议到先https://ip.net.coffee/claude/检测下信任评分，60分一下的就别用了。

Pasted image 20261028231401

注册前，先看一下 Claude 官方支持的地区。更改浏览器里的地区选项，并不会改变服务的使用条件。

邮箱方面，我用的是自己的域名，配合 Cloudflare 的邮件转发功能。

简单说，就是把发到域名邮箱的邮件，转到自己平时使用的邮箱里。比如，发给 claude@example.com 的邮件，最后仍然在你原来的收件箱里查看。

如果设置了 Catch-all（接收所有地址），同一个域名下不同前缀的邮件，也可以统一转发。这方便的是收信和分类，不代表多出了很多独立邮箱，更不保证 Claude 一定接受这个域名。具体配置可以看 Cloudflare 的说明。

已有能正常收信的邮箱，就直接用，不必为了注册专门买域名。 用转发邮箱的话，先发一封测试邮件，确认能收到，再开始注册。

二、安装 CCBaga，检查环境#

从项目的 Releases 页面下载安装包。项目目前提供的 Mac 安装包适用于 Apple 芯片，Intel Mac 不适用。

安装包里有两个应用，都要放进“应用程序”：

CCBaga-A：负责本机设置、环境检查和账号资料管理。
CCBaga-B：配套浏览器，有独立的浏览器资料目录。

打开 CCBaga-A 后，会自动启动 CCBaga-B。后面的网页操作，我都在这个浏览器里完成。

Pasted image 20261028223924

根据检测结果，检查网络出口、时区、语言等设置。修改后再点一次检测，确认实际结果。

我这次使用的是新加坡配置，截图里也能看到对应的时区和语言。新加坡与国内没有时差，对我来说比较顺手。至于网上说的“新加坡更不容易封号”，我没有做过对照测试，不能拿这次成功注册当证据。

地区选项要结合自己的实际使用地区来设置。工具里选了新加坡，并不会自动把网络出口切到新加坡。

我截图中的结果是 12/12 项通过。这说明工具列出的环境检查项通过了，不是 Claude 官方给账号开了通行证。

三、注册 Claude 账号#

1. 打开官网，选择邮箱登录#

在 CCBaga-B 中打开 Claude 官网，进入注册或登录页面。

Pasted image 20261028224601

选择邮箱方式，填入准备好的邮箱地址。

我用的是前面配置的域名转发邮箱。即使开了 Catch-all，也要记住这次填写的完整地址，后面登录仍然用它。

Clipboard_Screenshot_1793198964

如果页面提示这个邮箱无法注册，大概率就是域名被封了，比如使用免费的域名。

2. 收取登录邮件，完成验证#

实际邮箱收到的是带登录按钮的邮件。

Pasted image 20261028225126

这里容易弄混的一点是：你在哪个浏览器里点邮件，登录链接就可能在哪个浏览器里打开。

我是在 CCBaga-B 里发起登录的，所以也需要在这完成后续验证。可以直接在 CCBaga-B 中打开邮箱；如果在平时用的邮箱客户端里收信，就复制邮件中登录按钮的链接，再粘贴到 CCBaga-B 的地址栏打开。

Pasted image 20261028225218

这样做是为了在同一个浏览器里完成登录，避免浏览器指纹变化，导致被封号。

3. 完成引导，先用免费套餐#

验证后，继续完成页面上的引导。

Pasted image 20261028225319

到选择套餐这一步，先选免费版就行。先确认账号能正常登录、发消息，再决定要不要订阅。

Pasted image 20261028225356

如果页面提示下载客户端，可以先跳过，稍后再安装。

Pasted image 20261028225414

进入聊天页面，发一条消息，能收到回复，说明这次注册和网页聊天已经走通了。

Pasted image 20261028225518

四、登录桌面 App，分清聊天和 Claude Code#

网页能用了，再登录 Claude 桌面 App。

先说明一个容易混淆的地方：在 App 里聊天，和使用 Claude Code，是两回事。

按目前的官方说明，免费账号可以使用桌面端聊天；如果想通过个人订阅使用 Claude Code，需要 Pro 或 Max 等支持它的套餐。

打开 App，选择登录。

Pasted image 20261028225804

需要跳转浏览器验证时，继续用前面注册的同一个账号完成操作。仍然需要在 CCBaga-B 中打开验证链接，再按页面提示返回 App。

Pasted image 20261028225859

Pasted image 20261028225929

登录后，如果进入 Code 功能时提示升级套餐，这是当前套餐的限制，不代表前面的注册失败了。

Pasted image 20261028230002

这篇先写到桌面端登录。 Claude Code 命令行工具的安装和使用，暂时不展开。

五、通过应用商店订阅，先确认支付条件#

确定需要 Claude Code 后，再考虑订阅。

下面这张是我的苹果商店订阅记录。

Pasted image 20261028230156

如果打算用礼品卡支付，基本流程是：先确认商店账号所在地区和可用付款方式，再兑换礼品卡，最后在 Claude 手机 App 中完成订阅。下单前，核对登录的 Claude 邮箱，避免充到另一个账号上。

礼品卡怎么买、商店账号怎么设置，这里不展开。但有两个地方不能省略：

第一，礼品卡有地区限制。

苹果礼品卡有适用地区，Google Play 也对兑换地区、账号地区和币种有要求。不是随便买一张卡、换个网络就能用。网上有很多教程，这里不做展开了。

第二，能申请退款，不等于一定能退。

苹果和 Google 都有退款申请渠道，但是否批准，要看具体订单和平台规则。退款的教程也有很多，暂时也不展开来说了。

本文展示的是苹果商店的订阅记录，Google Play 的完整购买过程没有实测。

订阅成功后，再回到电脑上的 Claude，确认套餐状态，以及需要的功能是否已经开放。

最后聊两句#

这次折腾，主要是想重新把 Claude 用起来，也顺手把 CCBaga 里影响自己使用的账号保存和切换问题修一修。

工具能帮忙检查环境、切换账号，但账号是否受限，仍然由平台判断。

后续平台又有新玩法，也说不定。

公众号有一阵子没更新了。

最近工作比较忙，空下来又在折腾各种 AI，文章就一直拖着。

后面有实际用过、觉得值得记录的东西，再慢慢写。

之前几个项目欠下的项目呢，陆续都被下架了，感觉再写下去号就没了。

Pasted image 20261028233249

ElderTV 1.0.0：给老人用的电视端

Tue, 03 Nov 2026 00:00:00 GMT

前面五篇讲的都是服务端：源从哪来、怎么进稳定版、坏源怎么筛掉、怎么在 NAS 上跑起来。

做完这些，家里电视有了一个稳定地址。但打开电视那一刻，老人面对的仍然是播放器本身。

我用的播放器是 TVBox。功能很全，问题也在这里：它是给会折腾的人设计的。播放控制条上有 21 个按钮，设置里有 70 来项，首页顶上一排带漏斗图标的分类小字。源再稳定，老人还是会在“换源”“解码”“LUT”之间迷路。

所以这一篇做的是另一半：把电视端改成老人能用的样子。项目叫 ElderTV，1.0.0 已经发布。

从哪改起#

ElderTV 基于 motao123/webtv，它是 FongMi/TV 的一个分支。

改动分三块：

部分	做了什么
界面	首页、找片、详情、播放、设置全部重排，统一深色底、白底深字的焦点
交互	播放控制条从 21 个按钮减到 10 个，换源改成弹框选择，设置拆成两层
后台	可选的本地聚合、站点自动停用、插件在独立进程里运行

下面按老人实际会走的路径说。

首页：打开就是“接着看”#

首页最大的一块是上次看的片，带海报和进度条。焦点默认就在它上面，老人开机后按一下确定，就接着播。

旁边两个大按钮：找片、我的收藏。右上角是当前片源和设置，平时不用碰。

原来首页顶上的分类挪走了。分类内容随片源变化，名字五花八门，对老人是干扰，现在放进了找片页。

找片：键盘、历史、分类在一页#

左边是拼音首字母键盘，右边是搜索历史、按分类看、电视榜和电影榜。看过的片会出现在历史里，下次直接按。

搜索结果：同一部片只显示一张卡#

搜“战狼”，十几个站都能搜到同一部片。原来会排出十几张一样的海报，现在按片名合并成一张，左上角写着“15 源 · 2.3 秒”：有 15 个片源，最快的大约 2.3 秒能起播。

选中后弹出片源列表，最快的排在第一个，焦点也在它上面，直接按确定就行。

起播速度的数据有两个来源：真实播放时记录下来的实测时间，和聚合时测的首个分片下载时间。列表里分别写“实测”和“约”。

详情页：先给一个“播放”按钮#

原来详情页进去，焦点在视频小窗上，要按好几下才知道怎么播。现在多了一个“播放”按钮，焦点默认就在它上面。

线路、选集都改成了大一点的按钮。当前这一集、当前这条线路用蓝字蓝框标出来，一眼能看到自己看到哪了。

播放：控制条只留 10 个按钮#

这是改动最大的地方。原来的控制条有 21 个按钮，还可以自己调顺序和显隐，另外再加一个“播放设置”面板，很多功能两边各有一份。

现在控制条固定 10 个：暂停、上集、下集、片头、片尾、换源、选集、倍速、字幕、更多。电影没有上下集和选集，这三个会自动隐藏。

片头片尾保留了原来的用法：播到片头结束的地方按一下“片头”，之后这部剧每一集都会从这里开始；片尾同理，播到这里就自动下一集。已经设过的再按，会弹出“设到现在这里”和“清除”两个选项。

选集不用退出全屏#

原来选集只在详情页，看剧时要先退出全屏。现在控制条上有“选集”，弹出来焦点就在当前这一集。

不常用的放进“更多”#

画面大小、配音、线路、清晰度、定时关闭、循环播放，以及出问题时用的刷新、重播、播放器、解码，都在这里，按用途分了几组。分享、LUT、视轨这类老人用不上、但可能有人要的，放在最下面一行。

换源：弹出来选，接着原来的进度#

原版的“换源”是按一下直接跳到下一个源，换到哪个不知道，有时还会跳到一部同名的“电影解说”上。

现在改成弹出候选列表，写清现在看的是哪个源，其他候选按起播速度排好。选完之后接着原来的进度播，片头片尾设置也会带过去。

候选来自刚才搜索的结果，不用重新搜一遍。

提示要看得见#

原来的提示是系统自带的小字，出现在屏幕底部，正好压在控制条上。现在改成屏幕上方的大字条，比如在片头范围之外按“片头”，会告诉你“片头要在开头 10 分钟内设置”。

片源和设置#

右上角的“片源”决定首页推荐和分类从哪个站来。每个站前面的小圆点是它的健康状态：绿色最近能播，红色经常失败，灰色还没用过。

设置分两页。“常用”只有画面大小、字幕样式和版本号，老人误按进来也改不坏什么。

“高级设置”给帮忙配置的家人用：配置地址、聚合、站点屏蔽、手机推送、播放排查、备份恢复都在这里。

原来的公网远程、网页扩展、站点注入、各种同步这些入口去掉了。它们要么会运行外部代码，要么要连外部服务，和这个项目“先把风险关住”的方向相反。代码还在，只是不再出现在界面上。

配置地址这里，可以直接填前面几篇里 Home Spider Forge 的稳定版地址。

后台做了什么#

界面之外，有三件事是在后台做的。

本地聚合。 不想部署服务的话，可以在电视上直接聚合：手机扫高级设置里的二维码，打开控制台，填几个订阅地址。电视会自己合并、去重、剔除网盘站和公告站，结果放进片源列表。电视开机后一分钟会检查一次，超过 24 小时没更新、或者过滤规则升级了，就在后台重新整理一遍。

坏站自动停用。 同一个站连续 3 次起播失败，或连续 5 次搜索失败，就暂时从搜索和换源里拿掉，7 天后再放回来试一次。断网时不计数，可用站少于 20 个时也不再拿掉。这些数字都可以在控制台里调。

插件单独运行。 jar 插件在一个独立进程里运行，并且禁止它执行外部程序。插件崩溃不会带着播放一起崩。这部分在系列第 3 篇讲过为什么要做。

测试中改掉的问题#

这些都是在一台雷鸟电视上实际按遥控器发现的：

换源原来是自动跳下一个，改成弹框选择。
换源时搜索进度显示“0/0”，改成显示有几个源。
某部片没有可播的源时，原来 10 秒后就直接显示“这里什么都没有”，那时大部分站还没搜完。现在等所有站搜完，再明确说“这部片暂时没有可播放的片源”。
播放时按电视自带的主页键，应用退到后台，声音还在播，老人找不回去。现在离开就暂停。
确认退出后应用其实还在后台占内存，现在会彻底退出。
LUT 调色面板打开后关不掉，遥控器按键被播放器拦走了。
正式包在 Android 11 上聚合一启动就崩。调试包没有这个问题，用到的一个方法要 Android 14 才有。

最后一条值得说一句：调试包测得好好的，换成正式包才暴露出来。所以发布前一定要用正式包再走一遍。

还没测到的#

只在一台雷鸟电视（Android 11）上测过，其他品牌的电视和盒子没试过。
这个安装包最后改的两处没有在电视上复测：控制台点“立即更新”后进度条自动出现，找片页从分类按下键能到榜单。
安装包只有 32 位 ARM 版，大多数电视和盒子是这种。
新装还没看过片时，首页“最近观看”只有标题没有内容，看着有点空，后面再改。

下载#

最低要求：安卓 7.0（Android 7.0）及以上，32 位 ARM（armeabi-v7a）。大多数电视和盒子都满足，安卓 7.0 以下的老设备装不上。

复制到浏览器打开，前两个是中转地址，国内一般能直接下：

线路一： https://ghfast.top/https://github.com/riowang88/ElderTV/releases/download/v1.0.0/ElderTV-1.0.0-armeabi-v7a.apk

线路二： https://gh-proxy.com/https://github.com/riowang88/ElderTV/releases/download/v1.0.0/ElderTV-1.0.0-armeabi-v7a.apk

GitHub 原地址： https://github.com/riowang88/ElderTV/releases/tag/v1.0.0

中转站是第三方的，不归我管，一条打不开就换另一条。安装包约 99MB。

装法：

下载 APK，拷到 U 盘，插到电视上
用电视的文件管理器打开，提示未知来源就去设置里允许
装好后在“设置 → 高级设置 → 配置地址”填片源地址，或者打开聚合

ElderTV 不内置任何片源，地址需要自己填。

ElderTV 按 GPL-3.0 发布，对应的源码压缩包在 GitHub 原地址的 Release 页面里。

我把一整副塔罗牌放进了微信小程序

Fri, 21 Aug 2026 00:00:00 GMT

前段时间，看到一个朋友花钱请人做塔罗牌抽取、分析、解读，就想的不如直接做一个自己玩。

一开始觉得这件事应该不难：准备一些牌面图片，随机抽几张，再把对应的牌义显示出来，基本就完成了。

真正开始做以后才发现，如果只是点一下按钮，让程序随机弹出几张牌，它确实能运行，但总觉得少了点什么。

实体塔罗有一个很重要的过程：洗牌、摊开、慢慢移动牌堆，再凭感觉从里面抽出一张。最后翻开的牌是什么固然重要，自己做出选择的过程同样重要。

所以这个功能后来改了很多次，最后做成了一套完整的手机抽牌流程。

先选一个想探索的方向#

打开塔罗后，不需要填写姓名、生日，也没有一个不知道该写什么的长输入框。

目前准备了几个比较常用的方向：每日指引、事业与选择、关系与沟通、成长与状态。选好方向以后，再根据自己想了解的内容选择牌阵。

Pasted image 20260821191612

如果只是想给今天找一个观察角度，可以抽一张牌；想看看一件事从过去到现在的变化，可以选择三张时间流；如果问题比较复杂，也有关系牌阵、选择牌阵、马蹄牌阵和凯尔特十字。

牌阵不是为了让结果显得更神秘，而是提前规定每张牌负责回答什么。比如三张时间流分别对应过去、当下和可能的发展，这样翻牌以后，不会只得到几段互不相关的通用牌义。

Pasted image 20260821191644

不是点按钮随机出牌，而是真的从牌堆里抽#

这次放进去的是一副完整的 78 张塔罗牌，包括 22 张大阿卡纳和 56 张小阿卡纳。

洗牌以后，所有牌会以牌背朝上的方式摊成一叠弧形牌堆。手指左右滑动时，整副牌会跟着移动，屏幕上也会显示当前停在第几张。

找到想抽的位置后，不用再去点另一个按钮。手指可以直接向下拖，把当前这张牌从牌堆里抽出来；也可以先停下、松手，再按住它向下抽。

抽出的牌会落到对应牌位，剩余牌堆自动收拢。已经抽走的牌不会重复出现，直到这个牌阵需要的牌全部抽完。

手机当然不可能完全还原纸牌的触感，但我还是希望这个过程不像“点击生成随机答案”，而更像是在桌面上慢慢移动一副牌，然后自己做出选择。

Pasted image 20260821191715

翻牌以后，先看本地解读#

每张牌都准备了本地资料，包括关键词、画面观察、核心含义、正向提示、阴影提醒、行动建议和反思问题。

完成抽牌后，小程序会先按照牌阵整理整体脉络，再把每张牌放回它所在的牌位中解释。你可以先看牌阵之间的推进和冲突，也可以展开某一张牌，查看更完整的内容。

这些解读全部保存在小程序本地，不需要联网请求 AI，也不会因为外部接口失效就突然不能使用。

不过，本地资料有一个很明显的边界：它知道你抽到了什么，却不知道你现实中正在经历什么。

同一张牌放在工作选择、关系沟通和每日状态里，关注点可能完全不同。如果程序在不了解背景的情况下直接替用户下结论，看起来像是很懂，实际上很容易变成套话。

Pasted image 20260821191732

想继续深挖，可以复制给自己常用的 AI#

因此，我没有在小程序里直接接入 AI，而是做了一个“一键复制深度解读提示词”的功能。

它会把本次主题、牌阵用途、每个牌位、抽到的卡牌和本地牌义整理成一份结构化提示词。复制以后，可以粘贴到自己平时使用、支持连续对话的 AI 工具中。

AI 不会一上来就输出一大段结论，而是先通过一个问题了解你希望获得哪一类帮助。能用选项时优先给出选项，没有合适的也可以自己补充；不想提供背景，则可以直接要求它从通用反思角度解读。

了解必要信息以后，它才会结合牌位关系和现实背景，整理整体脉络、逐张分析、可能的盲点，以及今天和未来几天可以尝试的具体行动。

这样做稍微多了一步，但好处也很直接：小程序不需要收集你的问题和对话，你也不必被绑定在某一个 AI 服务上。

Pasted image 20260821191756

抽过的牌，可以留在历史记录里#

完成一次解读后，可以把抽牌结果保存到历史记录。之后能够重新查看牌阵、复制本次记录，也可以再次生成完整的 AI 提示词。

历史记录只保存在当前手机的微信本地缓存中，不需要注册账号，也不会上传到数据库。

相应地，清理微信缓存、删除小程序或者更换手机，都可能让记录丢失。所以历史页面也提供了导出功能，可以把单次记录或全部记录复制出来，保存到自己的笔记里。

它更像一个方便回看的临时牌册，而不是永久云端档案。

Pasted image 20260821191817

它不是替你预测未来#

我在文案和解读里尽量避开“注定会”“一定会”或者“这件事必然发生”这样的表达。

对我来说，塔罗更适合做一件事：当思路绕在一起时，提供一个原本没有注意到的观察角度，再把模糊的感受拆成几个可以继续思考的问题。

它不能替你做医疗、法律、财务或心理健康方面的判断，也不应该代替现实证据和专业意见。尤其遇到重要决定时，牌面可以用来整理想法，但最后仍然要回到真实情况里验证。

这次，终于不只是“随机抽几张图”了#

从最初的 22 张大阿卡纳，到后来补完整副 78 张牌；从点击按钮随机抽取，到现在可以左右滑动、定位、下拉抽牌；再到本地解读、历史记录和 AI 提示词，这个功能比最初设想的复杂了不少。

但也是做到这里以后，它才开始像一个真正可以安静用几分钟的小工具。

如果你刚好有一件事想换个角度看看，可以去小程序里试着抽一次。

不用把牌当成答案。

有时候，它只是帮你把真正想问的问题看得更清楚一点。

文章被下架了，暂时不写相关内容了

Fri, 07 Aug 2026 00:00:00 GMT

这两天发了篇跟小程序相关的文章，结果被平台下架了。看来这类内容还是比较容易被判定违规，后续就不单独发文了。

小程序还在，且用且珍惜 🙏

蹄子推荐#

小程序里也有蹄子的推广入口。用了挺多年了，虽然贵一点，但确实稳——这种东西，稳定比便宜重要。

5342

家庭聚合器开发进度#

前阵子充了 200🔪 的 Codex，结果额度还是不够我造的，这几天又断粮了 😂

不过整体来看，修订已经接近上线条件了。后续调试、测试完，会单独发文介绍。

5333

随便聊聊#

个人公众号也没什么固定主题，想到什么写什么。

最近在玩美股期权，就把自己学的东西、参考的文档整理了一下发出来。里面很多内容可能我自己理解就有偏差——凑合着看，别当投资建议。

碎碎念结束，上班 💼

做了个小工具，帮你一键复制各种热门源地址

Thu, 23 Jul 2026 00:00:00 GMT

最近折腾了一个小程序，功能很简单——把网上散落的各种热门源地址整理到一起，方便大家查找和复制。

它能干嘛？#

玩过 TVBox、影视盒子或者 IPTV 直播的朋友应该都有体会：找源地址是个麻烦事。群里发的链接过期了，收藏的帖子被删了，好不容易找到一个还得手动一个字一个字敲进去。

这个小程序做的事情就是帮你省掉找和抄的过程：

数据源——单仓源、多仓源都有，TVBox 类工具直接能用。

直播源——在线直播地址和 EPG 节目单接口，看电视直播的用得上。

MacCMS 采集接口——搭站或者自用播放器的朋友应该懂。

所有地址都支持搜索，找到想要的点一下就复制到剪贴板了，粘贴到你的播放器或者盒子里就行。

数据从哪来？#

源地址来自网络公开分享的聚合页面，服务端每隔一段时间自动抓取更新。我不生产源，只是做了个搬运和整理的活儿。

有时候上游网站挂了或者改版了，小程序会显示上一次成功抓到的数据，不会打开就白屏。数据旁边会标注更新时间，是不是最新的一目了然。

几点说明#

不测速、不检测可用性。地址能不能用取决于源本身，我只负责搬运。
不解析内容。不会帮你播放或者展示频道列表，纯粹就是个地址本。
免费用，没广告。就是自己顺手做的，觉得有用就留着，用不上关掉也不占地方。

怎么用？#

微信搜小程序就能找到，打开就是工具入口，选类型、找地址、点复制，三步搞定。

目前收录了单仓源 40 多条、多仓源 5 条、直播源 20 多条、EPG 接口 11 条、MacCMS 采集源 20 条，后续会跟着上游自动更新。

有需要的直接用就好，希望能省点大家翻群找链接的时间。

上次喝酒没找到骰子，我干脆自己写了一个

Thu, 23 Jul 2026 00:00:00 GMT

前段时间和朋友出去喝酒，聊着聊着想玩一会儿大话骰。

结果问了商家，店里没有骰子。

这其实不算什么大问题。打开微信搜一下，相关的小程序有不少，随便找一个也能继续玩。但当时用了几个，总觉得差点意思：有的界面太复杂，有的广告很多，有的看骰操作不太顺手。

酒倒是没少喝，骰子却一直没玩痛快。

回去以后我突然想到，既然功能并不复杂，为什么不自己写一个？

看起来只是随机几个数字#

一开始，我觉得这个工具应该很快就能做完。

不就是生成 5 个 1 到 6 的随机数，再把它们画成骰子吗？

真正开始做以后才发现，大话骰放到手机上，随机数反而是最简单的部分。在线下玩的时候，大家真正关心的是另外几件事：摇起来有没有感觉，旁边的人会不会偷看到，自己看骰时顺不顺手，以及喝了几杯以后还能不能一眼看懂。

实体骰盅之所以好用，不只是因为里面装了骰子。它会响、会震，揭开时只露出一道缝，松手又能马上盖回去。手机没有真正的骰盅，但这些关键体验还是可以尽量保留下来。

于是，这个原本以为一晚上就能做完的小功能，慢慢变成了一个单独的聚会工具。

Pasted image 20260723151617

把手机当成一个骰盅#

现在打开大话骰，默认就是最常见的 5 颗骰子。点击「重摇」，手机会配合音效和震动完成一次摇骰；不想点按钮，也可以直接晃动手机。

摇完以后，骰子不会立刻摊在屏幕上，而是先被骰盅盖住。

想看自己的点数，需要按住骰盅向上滑。滑到合适的位置，骰子才会露出来；手指一松，骰盅马上落回去。这个操作谈不上多复杂，但很适合大家围坐在一张桌子边的场景，至少不用为了看一眼骰子，把手机贴到脸上再迅速锁屏。

除了经典的 5 颗，也可以自定义 1 到 10 颗。这样不只可以玩大话骰，临时想玩猜大小或者其他骰子游戏，也不用再换一个工具。

声音、震动和晃动触发都可以单独关闭。所有功能都在本地运行，不需要联网，信号不好的包厢里也能正常用。

Pasted image 20260723151643

顺手又做了一个聚会转盘#

做着做着，我又想到另一个常见问题：一局结束以后，输了的人怎么罚？

现场临时想惩罚内容，经常不是太无聊，就是大家互相推来推去。于是我在骰子旁边加了一个聚会转盘，内置了一些轻松的挑战，也可以自己添加、编辑或者关闭不想玩的内容。

转盘不是游戏的主角，更像一个气氛工具。有人输了，点一下，让它替大家做决定，省得每轮都花时间讨论。

当然，涉及喝酒的内容都只是可选项。成年人聚会也应该量力而行，不想喝酒就换成饮料，更不要劝酒或者酒后开车。

为什么还要自己做一个？#

可能有人会问，类似的小程序已经有了，为什么还要再写一个？

其实没有什么宏大的理由。

现成的工具当然能用，但自己做东西有一个很有意思的地方：你可以把那些「好像还能忍，但每次用都觉得不舒服」的小问题，一个个改成自己喜欢的样子。

按钮应该放在哪里，骰盅抬起多高，手指松开后多久盖回去，骰子看起来要不要更像真的，转盘转多久才不会让人等得不耐烦——这些细节单独看都很小，放在一起却决定了这个工具到底趁不趁手。

而且，从一次喝酒时随口说出的「要不自己做一个」，到后来真的能在手机上摇起来，这个过程本身就挺好玩。

Pasted image 20260723151704

Pasted image 20260723151734

下次没骰子，就不用再找了#

这个小工具不会帮大家联网组局，也不记录谁叫了几颗、谁输谁赢。它没有打算替代真正的大话骰游戏，更不会替大家判断有没有吹牛。

它做的事情很简单：当你和朋友坐下来，手边刚好没有骰子时，把手机拿出来，就能直接开始。

下次再遇到商家没有骰子，我应该不会继续在微信里临时搜索了。

毕竟，手机里已经有了一个自己做的。

我把小红书告上了法庭（六）：法律规定平台要转送，但平台可以不转送

Mon, 20 Jul 2026 00:00:00 GMT

二审判决出来了：我的上诉被驳回，原判维持。
这篇文章只讲一个问题：法律和平台规则都写明了“转送申诉”，为什么现实中仍然可以不转送？

先说事情经过#

我的笔记被投诉后，小红书下架了内容，后来又封禁了账号。

我提交了申诉材料，说明涉案技术是公开技术，投诉方提交的专利也和笔记内容不对应。但小红书没有把我的申诉材料转给投诉方，而是直接回复：材料不符合要求。

于是我起诉小红书，要求解封账号、恢复笔记。

一审、二审都败诉了。

法律设计的流程，本来是这样的#

《电子商务法》第43条规定，被投诉方可以提交“不存在侵权行为的声明”和初步证据。平台收到后，应当把声明转给投诉方，并告知投诉方可以投诉或者起诉。

如果转送后15日内，平台没有收到投诉方已经投诉或起诉的通知，就应当终止原来的处理措施。

简单说，平台的作用应该像一个传话人：先控制风险，再把双方的说法传递给对方，不能自己直接当最终裁判者。

法律设计的通知—反通知流程

现实为什么变了？#

平台说：你的材料不够，不能算“初步证据”，所以不需要转送。

问题在于，“初步证据”到底要达到什么程度，法律没有说清楚。平台却可以先自己判断材料够不够，然后决定要不要启动转送程序。

于是流程变成了：

现实中的程序断点

平台只要说一句“材料不足”，15日就永远不会开始计算。

投诉方不会知道用户已经申诉，用户也没有机会让投诉方回应。平台既没有作出法院意义上的最终判决，却可以决定用户能不能进入法定的反通知程序。

更关键的是：这是平台自己写下的承诺#

我提交的证据中，有小红书的《侵权投诉指引在线协议》。这不是我对法律的解读，而是平台自己公示给用户的规则。

其中明确写着：

“小红书接到用户申诉后会及时进行审核，同时向权利人转送申诉。”

协议还写明，向权利人转送申诉后15日内没有收到起诉通知的，小红书将解除、取消已经采取的措施。

也就是说，平台自己的规则已经承认两件事：

用户申诉后存在转送程序；
转送后存在15日等待期。

但在我的案件中，平台承认没有转送，法院仍然接受了平台的解释：因为申诉材料不够，所以没有触发转送程序。

这就产生了一个很现实的矛盾：

法律要求平台转送，平台规则也承诺转送，但是否转送，最后仍由平台自己决定。

这条法律是不是完全没用？#

不能这么说。

如果平台已经转送，投诉方在15日内没有投诉或起诉，用户当然可以据此要求平台终止措施。

但最关键的争议恰恰是：平台说“我不需要转送”，用户说“我已经提交了初步证据”。在这种情况下，目前没有一个足够及时、独立的机构来判断平台说得对不对。

用户通常只能等内容被删除、账号被封以后，再通过民事诉讼追问平台有没有违反程序。等判决出来，内容的传播价值和账号的使用价值可能早就回不来了。

目前能看到的结果：唯一的样本是败诉#

截至本文写作时，在我掌握并核实的材料和公开检索范围内，尚未发现平台因违反这项转送义务而被判用户胜诉的公开生效裁判。

目前我能确认的相关案件，就是我自己的案件：

一审：（2025）沪0101民初22784号；
二审：（2026）沪02民终3919号；
一审、二审均驳回了我的诉讼请求；
二审认可了“申诉材料不足，平台可以不转送”的说法。

这不等于全国绝对没有其他案件，因为公开裁判文书不一定完整，案件名称也不一定包含“转送义务”几个字。但至少说明，目前还没有形成足够多的公开胜诉案例，来明确告诉平台：什么材料算初步证据，平台拒绝转送要承担什么后果。

写在最后#

我以前以为，法律写了“应当转送”，平台就必须转送。

现在我看到，真正决定一项权利能不能实现的，不只是法律条文，还包括：

谁来判断材料够不够；
谁来记录有没有转送；
15日从什么时候开始；
平台拒绝转送后，用户能不能及时获得救济。

如果这些问题都由平台自己决定，而拒绝转送又没有及时、明确的后果，那么“应当转送”就很容易变成一句口号。

所以，这个案件给我的结论是：

法律规定了转送义务，但在现有规则下，平台仍然可以用“材料不足”把这项义务挡在程序入口之外。

这就是为什么，写在法律里的权利，现实中仍可能只是一纸空文。

本文基于上海市第二中级人民法院（2026）沪02民终3919号民事判决、本案证据及小红书《侵权投诉指引在线协议》撰写。文中“某甲公司”“某乙公司”为判决书中的匿名化称谓。本文是个人经历和法律问题讨论，不构成法律意见。

相关法源：《中华人民共和国电子商务法》第42—45条；小红书《侵权投诉指引在线协议》。

我把小红书告上了法庭（五）：二审开庭——这一次，我没有再浪费辩论环节

Sat, 11 Apr 2026 00:00:00 GMT

2026年4月9日，二审开庭。上海市第二中级人民法院，异步微法庭审理。对面还是上海中联律师事务所的专业律师，这边还是我一个人。但和一审不同的是——这一次，我做了充分的准备。

庭审基本信息#

案号：（2026）沪02民终3919号
法院：上海市第二中级人民法院
审理方式：异步微法庭（文字交互，非实时视频）
上诉人：我
被上诉人代理人：上海中联律师事务所律师

异步审理的意思是，双方在微法庭系统里轮流提交文字，法官统一组织。不是面对面开口说话，而是打字。这个形式后面会提到一个有意思的细节。

一审的教训，全部吃透了#

上一篇文章里我复盘了一审踩的坑：战略重心偏移、辩论只说了一句话、关键事实没追到底。这次二审准备阶段，我用AI做了几件事：

写了完整的代理意见书——不再散打，每个论点都有法条、有证据、有逻辑链
准备了6组新证据（45页）——包括小红书自己的《侵权投诉指引》可信时间戳保全、一审庭审笔录中被告自认的关键段落、小佩的专利原文、NFC公开技术文档
模拟了庭审全流程——预判了法官可能问的问题和对方的质证角度，每一个都准备了回应

这次的策略只有一条线：小红书有没有按照法律和自己的规则走完”通知-反通知”程序。 其他一切都是辅助。

举证：6组证据，三个方向#

我的证据分三组，对应三个上诉理由：

第一组：证明平台违反转送义务

证据1：小红书《侵权投诉指引》（可信时间戳保全）——白纸黑字写着”同时向权利人转送申诉”
证据2：一审庭审笔录——被告亲口说”此前没有转送""审核团队无法判断”

第二组：证明投诉缺乏知识产权基础

证据3：NFC技术公开资料——开源技术，谁都能用
证据4：小佩专利原文——保护的是摄像头旋转结构，跟NFC八竿子打不着
证据5：京东商品截图——大量商家标注”适用小佩”，行业通行做法

第三组：证明封禁不合理

证据6：抖音和视频号截图——同样内容，正常存续，从未被投诉

对方没有提交任何新证据。

质证交锋：对方的四个论点，逐个击破#

对方律师对我的6组证据提出了质证意见。这次我不再像一审那样被动接招——每一条我都有准备。

证据1：侵权投诉指引#

对方说： 转送的前提是用户提交”不侵权的初步证据”，你提交的只是技术说明和法律观点陈述，不符合标准，没有触发转送程序。

我的回应： 第四十三条原文是”接到声明后，应当转送”，不是”审查合格后才转送”。法律没给平台设一个”我觉得你材料不够好就可以不转”的裁量权。而且你自己的《侵权投诉指引》写的是”同时向权利人转送”——“同时”就是并行，不是先审后转。你现在的说法连自己写的规则都对不上。

证据2：一审庭审笔录#

对方说： “无法判断”是指无法判断上诉人的不侵权主张能否成立，平台综合判断侵权可能性较大，所以不转送。

我的回应： 一方面说”无法判断”，另一方面又说”综合判断侵权可能性较大”。判断不了和已经判断了，只能选一个。 而且第四十三条根本没有”侵权可能性评估”这个步骤——法条的逻辑是：收到声明→转送→等15天→不起诉就解封。立法者这么设计，就是因为平台不是法院。

证据3、4：技术文档和专利文件#

对方说： 非二审新证据。

我的回应： 已在新证据提交说明中阐述。但我注意到一个细节——对方对这两份证据的实质内容没有提出任何异议。 也就是说，对方不否认投诉人的专利是摄像头旋转结构，不否认跟NFC技术无关。只是不想让法庭看到而已。

证据5、6：京东截图和其他平台截图#

对方说： 未经公证或可信时间戳，来源不明，不认可真实性。

我的回应： 这些都是公开平台的内容，法庭随时可以在线核实。对方只质疑形式，但对截图反映的事实本身没有任何异议——没否认京东上有大量”适用小佩”的商品，也没否认我在抖音视频号上的内容正常存在。

辩论环节：这次不止一句话了#

一审的辩论环节，我只说了一句”平台应当解禁”就结束了。这次不一样。

对方的辩论意见：

本案系网络服务合同纠纷，平台依用户协议及《电子商务法》有权独立审查。上诉人未提供符合要求的”不侵权初步证据”，平台无法亦无义务转送；其多次发布涉嫌知识产权侵权笔记，平台依据协议采取笔记下架及封禁措施，合理有据。请求驳回上诉，维持原判。

总结一下对方的核心逻辑：你的材料不够格→所以我不用转送→所以封你合法。

我的辩论意见：

第一，关于转送义务。被上诉人主张我的材料”不够格”，但第四十三条写的是”接到声明后，应当转送”，没有给平台设审查门槛。被上诉人自己的规则也写的是”同时转送”。更关键的是，被上诉人一审说”审核团队无法判断”，今天又说”综合判断侵权可能性较大”——判断不了和已经判断了不能同时成立。
第二，关于投诉基础。被上诉人今天对专利文件和NFC技术资料的实质内容没有提出任何异议，不否认专利是摄像头旋转结构，不否认与NFC技术无关。投诉人至今也没有起诉我。一个连投诉方自己都不敢起诉的”侵权”，平台却据此永久封号。
第三，关于处罚比例。涉案笔记收入不足一百元，相同内容在抖音和视频号正常存续，被上诉人对此也没有否认。永久封禁整个账号，严重超出合理范围。

和一审那一句话比，这次每一个论点都精准回应了对方的质证和辩论。

最后陈述#

《电子商务法》第四十三条的通知-反通知机制，是立法者专门为平衡平台与用户之间的不对等地位而设立的强制性程序保护。本案中，被上诉人自认未转送、自认无法判断，投诉人据以投诉的专利与涉案内容完全无关，投诉人至今未提起任何诉讼。如果在这样的事实下，平台仍然可以不走法定程序就永久封禁用户，那么第四十三条赋予用户的程序性权利将被彻底架空。恳请二审法院依法纠正一审判决。

关于调解，我表态：愿意调解，核心诉求是解封账号。

一个有意思的细节#

因为是异步微法庭，双方通过打字交流。法官说完”请各方发表辩论意见、最后陈述、是否同意调解后即可退出微法庭”之后——

我提前准备了所有内容，辩论意见、最后陈述、调解态度一口气全部提交了。

而对方律师，因为输入太慢，最后的答辩和是否同意调解还没来得及打完，审判长就结束了庭审。

这其实挺有意思的。一审的时候，对面是专业律师团队，所有材料都有备而来，我是措手不及的那个。二审换了异步文字的形式，我这个提前做了充分准备的人反而占了先机，而对方律师反倒没来得及。

当然，这不影响裁判结果——法官会综合考虑双方的全部意见。但至少这说明一件事：

充分的准备，在任何战场上都是最大的武器。不管你是不是专业律师。

接下来等什么？#

二审庭审结束了，现在进入等判决的阶段。

根据《民事诉讼法》，二审一般应在立案后三个月内审结。可能的结果有几种：

改判——撤销一审，支持我的诉求（最佳）
发回重审——认为一审有遗漏，让一审法院重新审
调解——法官组织双方和解（可以接受）
维持原判——驳回上诉（最坏，但还可以申请再审）

不管结果如何，这个系列会继续更新。

写给一路看到这里的你#

从2025年4月被封号，到2025年8月起诉，到2025年10月一审败诉，到2025年10月底上诉，到2026年4月二审开庭——整整一年。

一年时间，一个没有法律背景的普通人，一个人对一个互联网大厂的法律团队。

我不知道结果会怎样。但我知道，如果每一个被平台不合理对待的人都选择沉默，那些写在法律里保护我们的条文就真的只是纸面上的文字。

《电子商务法》第四十三条给了用户一个法定的反击机会——提交不侵权声明，平台转送，投诉方不起诉就解封。这个机制设计得很好。问题是，如果平台可以选择不执行，而法院也不追究，那这个机制保护的是谁？

这是我想通过这个案子搞清楚的事。

系列目录：

（一）为什么起诉小红书？
（二）事情的完整经过
（三）没有律师，我是怎么用AI打官司的
（四）一审败诉：庭审现场踩了哪些坑
（五）二审开庭：这一次，我没有再浪费辩论环节（本篇）
（六）二审判决（待更新）

二审案号：（2026）沪02民终3919号 一审案号：（2025）沪0101民初22784号

本系列所有内容均基于真实法律文书和庭审记录，不构成法律建议。如遇类似情况，请咨询专业律师。

我把小红书告上了法庭（一）：一个普通用户，为什么要起诉小红书？

Wed, 08 Apr 2026 00:00:00 GMT

系列文章预告：这是一个普通人起诉互联网大厂的真实记录。从起因、准备、开庭到败诉，再到上诉，我会完整记录这段经历。没有律师，没有法律背景，靠AI帮我写完了所有法律文书。2026年4月9日就是二审开庭的日子，在此之前，先把一审的故事讲完。

先说结论#

2025年，我把小红书的运营公司——行吟信息科技（上海）有限公司告上了法庭。

案由：网络服务合同纠纷。

案号：（2025）沪0101民初22784号。

一审结果：败诉。

但我没有放弃，提起了上诉。二审将于2026年4月9日在上海市第二中级人民法院开庭。

这篇文章，我想先讲讲，一个没有任何法律背景的普通人，为什么要做出”起诉小红书”这个看起来有点疯狂的决定。

我不是维权斗士，我只是一个养猫的人#

我家有猫，用的是小佩Ultra智能猫厕所。这款产品有个设计——垃圾盒（也就是装猫砂和排泄物的袋子组件）是耗材，需要定期更换，而且只能用小佩官方的配套垃圾盒。

怎么做到”只能用官方的”呢？答案是NFC芯片。小佩在垃圾盒里内置了NFC标签，猫厕所通过读取标签来验证是不是”正品”垃圾盒。如果检测不到官方标签，机器就拒绝工作。

一个垃圾盒的官方售价远高于其实际价值。说白了，这就是经典的”剃须刀-刀片”商业模式——机器本身可能不赚钱，靠耗材持续收割。

作为一个搞技术的人，我研究了一下，发现NFC标签的复制是完全公开的技术（nfc-mfclassic，一个开源的MIFARE Classic读写工具），没有任何技术壁垒。于是我用几块钱的通用NFC标签替代了官方垃圾盒里的芯片，完美运行。

我想，这个方法能帮到其他同样觉得耗材太贵的猫友，就在小红书上发了一篇笔记：《小佩Ultra垃圾盒平替攻略|破解NFC解锁》。

考虑到整理材料也花了些时间，我用了小红书自带的付费功能，设定5元即可查看完整教程。

总共收入：不到100块。

就是这不到100块，引发了后面所有的事。

从下架到封号：小红书的”三连杀”#

第一波：笔记下架#

2025年4月30日，我收到小红书通知，说我的笔记被小佩网络科技（上海）有限公司投诉，涉嫌侵害其专利、商标等合法权利，笔记被下架。

我立刻申诉，详细解释了：

我用的NFC复制技术是完全公开的，不涉及任何专利；
小佩提交的专利（202323604577.7）保护的是摄像头机械结构，和垃圾盒、NFC完全无关；
我在笔记中使用”小佩Ultra”字样，只是说明适配哪款产品，就像第三方充电线标注”适用于iPhone”一样，属于合理使用。

小红书的回复？机械式的模板回复，要求我提供”商标授权、专利授权”材料。

我一个消费者，分享省钱攻略，你要我提供品牌方的商标授权？

第二波：再发再删，直接封号#

我不服，把笔记内容调整后又发了两篇相关笔记。结果不出意外，小佩继续投诉，小红书继续下架——这一次，直接封禁了我的整个账号。

要知道，我这个账号从2021年用到2025年，发了113篇笔记，其中110篇都和这事毫无关系，都是日常生活、办公软件教程之类的内容。因为3篇笔记，4年的账号，说封就封。

最关键的问题：小红书从未把我的申诉转给小佩#

这才是让我决定起诉的核心原因。

根据《电子商务法》第43条，流程应该是这样的：

权利人（小佩）投诉 → 平台下架内容并通知用户
用户（我）提交不侵权声明和初步证据 → 平台应当转送给权利人
权利人收到后15天内不起诉 → 平台应当恢复内容

这是法律明确规定的”通知-反通知”机制，目的是防止投诉被滥用。

但小红书从头到尾，根本没有把我的申诉材料转送给小佩。

它自己当了裁判，自己判定我”侵权”，自己决定封我的号。

更讽刺的是，我把同样的内容发在抖音和微信视频号上，至今没有收到任何投诉或下架通知。 同样的内容，在别的平台安然无恙，只有小红书直接封号。

为什么是起诉小红书，而不是小佩？#

很多人可能会问：小佩才是投诉你的人，为什么不告小佩？

原因很简单：我和小佩之间没有直接的法律关系需要在这个案子里解决。 小佩认为我侵权，它可以起诉我——但它从来没有起诉过我，连律师函都没发过一封。

我和小红书之间有明确的法律关系：网络服务合同。我注册账号时同意了它的用户协议，它承诺按照规则提供服务。而它的《侵权投诉指引》里白纸黑字写着：“小红书接到用户申诉后会及时进行审核，同时向权利人转送申诉（包括申诉用户真实身份信息和不侵权的初步证据）。”

它自己定的规则，自己没有遵守。

所以我的诉求很简单：

解封我的账号
恢复被下架的笔记

我不要赔偿，不要道歉，只是要求小红书按照它自己的规则和法律规定来办事。

一个普通人，值不值得为此打官司？#

坦白说，做这个决定之前我犹豫了很久。

一审受理费才40块（80块减半），金额不大。但时间成本、精力成本是实实在在的。我人在深圳，被告在上海，虽然可以线上开庭，但准备起诉状、证据目录、代理意见这些法律文书，对一个从来没接触过法律的人来说，每一步都是从零开始。

但我还是决定做了，原因有三：

第一，这件事本身不对。 平台不能因为收到一个投诉，就不走法定程序，直接封杀用户。如果这种事可以随便做，那任何品牌方都可以通过投诉来打压不利于自己的内容，普通用户毫无还手之力。

第二，我想搞清楚一件事。 《电子商务法》第43条的”通知-反通知”机制，在实践中到底能不能保护普通用户？还是说它只是写在纸面上的条文，平台可以选择性忽略？

第三，AI让这件事变得可行了。 如果要请律师，一个这种标的的案子，律师费可能远超案件本身的价值。但有了AI，我可以自己完成所有法律文书的撰写。这一点我会在后续文章里详细讲。

下期预告#

下一篇，我会详细讲述事情的完整经过——从买猫厕所、发现NFC限制、研究破解方法、发布笔记、被投诉、申诉、被封号的全过程，以及我在其他平台发布同样内容却安然无恙的对比。

系列目录：

（一）为什么起诉小红书？（本篇）
（二）事情的完整经过
（三）没有律师经验，我是怎么用AI打官司的
（四）一审败诉：庭审现场踩了哪些坑
（五）二审开庭实录（即将更新）

本文所述案件信息均基于真实法律文书，案号（2025）沪0101民初22784号，可在中国裁判文书网查询。

二审将于2026年4月9日上午10点在上海市第二中级人民法院开庭。

我把小红书告上了法庭（二）：一个5块钱的猫砂盆攻略，是怎么变成一场官司的

Wed, 08 Apr 2026 00:00:00 GMT

上一篇讲了为什么要起诉小红书，这一篇完整还原事情的经过。从买猫砂盆开始，到账号被封，每一步都有据可查。

故事要从一台猫厕所说起#

我家养猫。2024年底，我用旧款小佩以旧换新了一台小佩Ultra智能猫厕所。

用过智能猫厕所的人都知道，这类产品的核心卖点是”自动清理”——猫用完之后，机器自动把结团的猫砂和排泄物铲到下面的垃圾盒里，主人只需要定期更换垃圾盒就行。

听起来很方便，用起来确实也方便。但用了一段时间之后，我发现一个问题：

Utra的垃圾盒是耗材，而且只能用小佩官方的，要知道之前旧款的垃圾袋，都是可以买第三方的替代品的。

小佩在每个垃圾盒里都内置了一个NFC芯片。猫厕所工作前会先读取NFC标签，验证通过才启动。如果你换了个没有芯片的普通垃圾袋，机器直接罢工。

官方垃圾盒的价格，远高于一个塑料袋加NFC标签的实际成本。这本质上就是通过技术手段锁定耗材消费，赚后续的钱。

技术人的本能：这能破解吗？#

我本职是做技术相关工作的。看到NFC锁定这个机制，第一反应就是——这东西应该不难绕过。

研究了一下，发现确实如此：

小佩用的是MIFARE Classic类型的NFC标签，这是一种非常常见的NFC标准
有一个叫nfc-mfclassic的开源工具，可以读取和写入这类标签的数据
只需要用读卡器把原装垃圾盒的NFC数据读出来，写到一个几块钱的空白NFC标签上，贴到垃圾盒上，并更换便宜的垃圾袋，就能完美替代

整个过程用到的技术全是公开的，工具是开源的，标签是通用的，没有任何专利壁垒。

我自己试了，完全可行。用6.9元的成本，替代了官方几十块的垃圾盒。猫厕所正常运行，毫无区别。

在小红书分享：想帮其他猫友省点钱#

方法验证成功后，我觉得这个信息对其他小佩用户有价值——毕竟养猫的人谁不想省点耗材钱？

2025年4月17日，我在小红书发布了第一篇笔记：

《小佩Ultra垃圾盒平替攻略|破解NFC解锁》

笔记内容很简单：说明了垃圾盒NFC锁定的原理，以及如何用通用标签替代。考虑到资料手动发送，要耗费大量时间，我用了小红书自带的”付费自动发货”功能，完成自动发货，定价5元——用户支付后，平台自动发送完整操作指南。

需要强调几点：

我不卖任何产品。 所有材料（NFC标签、读卡器）消费者自行在电商平台购买。
我不做引流。 笔记没有导向任何外部店铺或微信。
5块钱是知识付费，不是商品交易。 类似于你买一份教程。
总收入不到100块。 从发布到被封号，一共就赚了这么点。

小佩投诉，小红书下架——第一轮#

笔记发出不到两周，2025年4月30日，我收到了小红书的通知：

你的笔记因被投诉涉嫌侵害他人专利、商标等合法权利，已被下架。

投诉方：小佩网络科技（上海）有限公司。

我当即申诉，提交了详细的说明：

关于专利：小佩提交的专利号202323604577.7，我查了专利内容，保护范围是”摄像装置设于便仓进出口旁侧”——这是一个摄像头结构的外观专利，和垃圾盒、NFC技术完全无关。用这个专利来投诉我的垃圾盒替换方案，就像用”汽车外形专利”来投诉别人换轮胎。
关于商标：我在标题里写”小佩Ultra”，是为了说明这个攻略适配哪款产品。就像淘宝上无数第三方配件写”适用于iPhone""适用于大疆”一样，这是描述性的合理使用，不是商标侵权。
关于技术：NFC标签的读写是完全公开的技术，开源工具随处可下载，不涉及任何技术秘密。

小红书的回复让我哭笑不得： 要求我提供”商标授权、专利授权”材料，否则无法通过申诉。

我一个消费者，分享了个省钱方法，你要我去找小佩开一张”授权书”说允许我分享？这逻辑本身就荒谬。

我调整内容再发——第二轮投诉，直接封号#

第一篇被下架后，我反思了一下，把笔记里涉及商标的内容做了调整，在5月5日和5月14日先后发了两篇新笔记：

《小佩Ultra垃圾盒平替攻略|6.9元搞定替换》
《Ultra标签替换装》

果不其然，小佩再次投诉。

但这一次，小红书不仅下架了笔记，直接封禁了我的整个账号。

一个用了4年、发了113篇笔记的账号，因为3篇关于猫砂盆垃圾盒的内容，永久封禁。其他110篇记录生活、分享技术的笔记，全部灰飞烟灭。

最让我愤怒的不是封号，而是小红书的处理方式#

封号我可以接受讨论——如果经过合法程序认定我确实侵权了，那我认。

但问题是，小红书根本没有走完法定程序。

后续我仔细翻阅了相关法律法规，发现根据《电子商务法》第42-43条，完整的流程应该是：

1
小佩投诉 → 小红书下架并通知我 → 我提交不侵权声明
2
→ 小红书转送给小佩 → 小佩15天内决定是否起诉
3
→ 不起诉则恢复内容

整个机制的核心在于**“转送”**这一步——平台不是裁判，不能自己判定用户侵不侵权，它的义务是把双方的材料互相转送，让投诉方和被投诉方有机会对抗。如果投诉方15天内不去法院起诉，说明它自己也没有足够信心，平台就应该恢复内容。

然而，小红书自始至终没有把我的申诉材料转送给小佩。

这不是我的推测。在后来的一审庭审中，法官明确询问了被告方律师这个问题，被告自认”未曾转送”。

也就是说：

小佩投诉了 ✓
小红书通知了我 ✓
我提交了不侵权声明和证据 ✓
小红书把我的声明转送给小佩 ✗
等待15天看小佩是否起诉 ✗
小红书直接自行判定我”侵权”并封号 ✓

法律规定的程序，小红书跳过了最关键的两步。

对比实验：同样的内容，抖音和视频号毫发无损#

为了验证是不是我的内容真的有问题，我把完全相同的内容发在了抖音和微信视频号上。

结果：至今没有收到任何投诉、下架或限制通知。

在抖音上，我甚至在视频下方挂了链接，引导到飞书文档（免费的），方便观众查看详细教程。一切正常。

同样的内容，在别的平台安然无恙，只有小红书直接封号。这说明什么？说明问题不在内容本身，而在于小红书的处理方式。

最后一根稻草#

在经历了反复申诉、反复被驳回、始终得到模板式回复之后，我做出了一个决定：

起诉。

不是冲动。我花了几周时间研究法律条文，咨询了解法律程序，评估了胜算和成本。

我知道，一个普通人起诉一家互联网大厂，对方有专业律所（上海中联律师事务所，专业律师出庭），我一个人应诉。力量悬殊是客观事实。

但我认为，法律就是用来解决这种力量不对等的问题的。《电子商务法》第43条的立法目的，就是为了防止平台和投诉方联手碾压普通用户。如果法律写了但没人用、用了但不管用，那法律就只是一纸空文。

2025年6月，我向上海市黄浦区人民法院递交了起诉状。

下期预告#

下一篇文章，我会讲讲一个零法律经验的技术人，是怎么从零开始准备一场民事诉讼的——起诉状怎么写？证据目录怎么编？代理意见怎么组织？庭审要准备什么？以及最重要的：AI在这个过程中到底帮了多少忙？

系列目录：

（一）为什么起诉小红书？
（二）事情的完整经过（本篇）
（三）没有律师经验，我是怎么用AI打官司的
（四）一审败诉：庭审现场踩了哪些坑
（五）二审开庭实录（即将更新）

案号：（2025）沪0101民初22784号

二审开庭时间：2026年4月9日上午10<00>，上海市第二中级人民法院

我把小红书告上了法庭（三）：零法律经验，我是怎么用AI准备一场民事诉讼的

Wed, 08 Apr 2026 00:00:00 GMT

没请律师，没有法律背景，从起诉状到代理意见全靠自己。AI是我的”法律顾问”，但踩过的坑也不少。这篇文章分享完整的准备过程。

先回答一个问题：为什么不请律师？#

不是不想，是算了一笔账之后觉得不值。

这个案子的诉讼请求是解封账号和恢复笔记，没有金钱赔偿。一审受理费总共80块（减半收取40块）。但如果请律师，即便是比较便宜的，代理费也要几千到上万，这里还是不计算其他费用的情况下。

一个不到100块收入引发的案子，花上万块请律师？我实在说服不了自己。

况且我心想，这又不是什么复杂的商事纠纷或刑事案件，就是一个平台有没有按规矩办事的问题。事实清楚，法律条文明确，应该能自己搞定。

事后证明，这个想法对了一半，也错了一半。 对的是文书确实可以自己写；错的是，庭审经验的缺乏不是文书能弥补的。这个后面会讲。

第一关：起诉状——AI帮我迈出了第一步#

在决定起诉之前，我连起诉状长什么样都不知道。

我的第一步是打开AI，问了一个最基础的问题：

“我要起诉一个互联网平台封了我的账号，起诉状应该怎么写？格式是什么？需要包含哪些内容？”

AI给了我一个清晰的框架：

原告、被告基本信息
诉讼请求（你要法院判什么）
事实和理由（为什么要判）
证据清单
法院管辖

然后我把案件事实完整地告诉AI，让它帮我生成初稿。

但这里有一个关键心得：AI生成的初稿不能直接用。

AI写出来的起诉状有几个典型问题：

法律条文可能引用不准确。 AI有时会”编造”不存在的条文或条款号，必须自己去查原文核对。
事实描述可能添油加醋。 AI倾向于把事情写得更严重、更有感染力，但法律文书需要的是准确，不是煽情。
逻辑结构需要根据案件特点调整。 AI给的是通用模板，但每个案子的重点不同。

我的做法是：让AI先出框架和初稿，然后自己逐字逐句核对事实、核对法律条文、调整论证重点。这个过程大概来来回回修改了不下十版。

第二关：证据目录——看起来简单，实际很琐碎#

证据目录是把你手头所有能证明事实的材料整理成一个清单，标明每份证据证明什么。

我最终提交了9组证据：

编号	证据	证明目的
1	账号封禁截图	账号确实被封了
2	账号实名认证信息	我确实是这个账号的主人
3	涉案笔记封面及视频	笔记内容不侵权
4	申诉邮件记录	我申诉了，平台给的是模板回复
5	小佩的投诉专利	专利和我的内容完全无关
6	垃圾盒销售截图	说明官方定价过高
7	其他猫产品的非限制设计	行业对比，说明NFC锁定不是必须的
8	NFC技术公开证明	用的是公开技术
9	申诉详情及申诉内容	我提交了不侵权声明

这个环节AI的帮助比较有限，因为证据本身得自己去收集、截图、整理。AI能帮的是建议你应该收集哪些证据、每份证据应该怎么描述证明目的。

一个教训： 开庭前几天我又补充了一组证据，但因为提交太晚，被告要求庭后书面质证。这导致法官对这组证据的关注度明显下降。证据应该尽早、尽全地准备，不要拖到最后一刻。

第三关：民事代理意见——最吃AI功力的环节#

代理意见是庭审后提交给法院的书面材料，相当于你的”结案陈词”。这是我花精力最多的文书。

我的策略是：

先把开庭中双方争论的焦点整理出来
让AI针对每个焦点生成法律分析
自己判断哪些论点有力、哪些论点薄弱，做取舍
查找真实的法律条文和案例来支撑论点

最终的代理意见分了五个部分：

不构成商标侵权（合理使用）
不构成专利侵权（技术领域完全无关）
平台拒绝转送申诉材料违法（电商法第43条）
封号行为违背平台宗旨
诉讼请求总结

又一个教训：这个结构看起来面面俱到，但其实犯了”重点不突出”的大忌。

事后复盘，我的核心论点应该只有一个——平台没有履行转送义务，程序违法。但我花了大量篇幅去论证”不构成商标侵权""不构成专利侵权”，而这些其实是小佩和我之间的争议，不是我和小红书之间的争议。

法官在庭审中明确说了：“本案是网络服务合同纠纷，审查的是被告对原告的处置行为是否合规，而非原告是否构成知识产权侵权。”

换句话说，我花了大力气证明的”我不侵权”，在这个案子里根本不是核心问题。 核心问题是”小红书处理我的申诉时有没有违规”。

这就是没有诉讼经验的代价——方向偏了，再漂亮的论证也是白费力气。

第四关：查法律法规——AI和人工的配合#

准备过程中，我需要查阅大量法律条文。主要包括：

《电子商务法》第42-43条 ——核心条款，关于”通知-反通知”机制
《民法典》第465条、509条 ——合同约束力和全面履行义务
《商标法》第59条 ——商标合理使用
《民法典》第497条 ——格式条款的无效情形
《民法典》第1165条 ——侵权责任的因果关系要件

AI在这方面非常好用——你描述一个法律场景，它能快速定位到相关条文，并解释条文的适用条件和司法实践中的理解。

但必须自己核实。 我会把AI给的条文号拿去在国家法律法规数据库里查原文，确认条文确实存在、内容确实如AI所述。曾经有一次，AI给我引了一个不存在的司法解释条款，如果我没核实就写进文书里，在庭上会非常尴尬。

第五关：管辖和立案——程序上的小门槛#

确定在哪个法院起诉，这个AI也帮我分析了。

网络服务合同纠纷，可以在被告住所地或合同履行地起诉。小红书的运营公司行吟信息科技（上海）有限公司注册地在上海市黄浦区，所以我选择了上海市黄浦区人民法院。

立案是网上立案，流程不算复杂，但也有一些细节：

起诉状要签名，扫描上传
证据要编号，每份证据对应一个文件
被告的工商信息要附上（可以在国家企业信用信息公示系统下载）

立案后大约一周收到了受理通知，分配的审判员叫刘杰，适用简易程序。

总结：AI能帮你做什么，不能帮你做什么#

经过整个一审，我对”AI辅助诉讼”有了比较清晰的认知：

AI能做的：#

法律知识科普：快速了解相关法律框架、适用条文、程序要求
文书初稿生成：起诉状、代理意见等文书的框架和初稿
论点梳理：帮你整理论证逻辑，发现论证漏洞
法律条文检索：根据事实场景定位相关法条
对方论点预判：模拟对方可能的辩护策略

AI做不到的：#

不能替代庭审经验：法庭上的随机应变、对法官提问的回应、辩论节奏的把控，这些只能靠实战
不能保证法条准确性：必须自己核实每一个引用
不能帮你判断案件重心：战略层面的判断——哪个论点该重点打、哪个该放弃，需要对整个案件有深度理解
不能帮你搜集证据：证据得自己去截图、保全、整理
不能帮你在法庭上应对突发情况

如果再给我一次机会，我会在准备阶段做一件事：找一个有经验的律师做一次付费咨询，不用全程代理，就花一两个小时帮我梳理案件的核心争议焦点和诉讼策略。文书可以自己写，但方向不能跑偏。

下期预告#

下一篇，进入正题——一审庭审现场。一个小时的线上开庭，我踩了哪些坑？法官问了什么我没答好？对方律师的哪些操作让我措手不及？以及最终败诉的根本原因是什么？

系列目录：

（一）为什么起诉小红书？
（二）事情的完整经过
（三）没有律师经验，我是怎么用AI打官司的（本篇）
（四）一审败诉：庭审现场踩了哪些坑
（五）二审开庭实录（即将更新）

案号：（2025）沪0101民初22784号

二审开庭时间：2026年4月9日上午10<00>

我把小红书告上了法庭（四）：一审败诉复盘——一个小时的庭审，我踩了多少坑

Wed, 08 Apr 2026 00:00:00 GMT

2025年9月24日下午13<48>，线上开庭。对面是上海中联律师事务所的专业律师，这边是第一次上法庭的我。一个小时后休庭，一个月后收到判决：驳回全部诉讼请求。这篇文章逐帧复盘那场庭审，以及败诉的真正原因。

庭审基本信息#

时间：2025年9月24日 13:48-14<51>（约1小时）
地点：上海市黄浦区人民法院第20法庭（线上开庭）
审判员：刘杰（独任）
书记员：陆俊安
原告：我，一个人
被告代理人：刘依贝，上海中联律师事务所律师

一个人对一个专业律师团队。心里没底，但硬着头皮上了。

踩坑一：开场就被打了个措手不及#

开庭后，法官先让我陈述诉请和事实理由。这部分我准备充分，照着起诉状讲了，没什么问题。我特意强调了关键事实：“对方对于我申诉中的材料，平台并未转送相对方。”

然后法官问了一个问题：“被封号主要基于什么事实？”

我回答：“之前收到的平台材料反映的是因为专利侵权，但今天收到对方律师的材料主要针对引流。”

这就是第一个坑。

开庭当天才收到被告的证据材料，我发现对方的论证角度和我预想的完全不同。我以为对方会继续主张”专利侵权""商标侵权”，我准备了大量反驳侵权的材料。

结果对方压根不在侵权问题上纠缠。 被告律师的策略非常精明——她根本不谈你的内容侵不侵权，而是说：

“原告通过发布笔记教唆用户绕过技术验证，涉及侵害其他品牌的嫌疑……基于产品结合原告破解视频，达到破解小佩产品的目的。”

然后大量引用平台自己的规则：用户服务协议、社区公约、社区规范，论证平台有权根据这些规则”独立判断”并作出处理。

一句话：她不跟你争侵不侵权，她跟你说”平台有权管你”。

这个论证角度的转换，让我准备的很多材料都落了空。

踩坑二：在错误的战场上浪费弹药#

整个庭审过程中，我花了大量时间在论证”我不侵权”上：

“异议方提交的专利仅有外观专利，并无技术方面的权利。” “我认为异议方行为违反了消费者协议。” “小佩产品的费用远高于其价值，且其使用NFC功能达到垄断的目的。”

这些说法本身没有错，但在这个案子里，它们不是重点。

法官中途做了一个关键释明——

“向双方释明本案是网络服务合同纠纷，并解释本案案由审查的范围。”

翻译成大白话就是：这个案子审的是你和小红书之间的合同关系，不审你和小佩之间的侵权纠纷。 你侵不侵犯小佩的权利，不是我这个案子要解决的问题。

法官已经明示了，但当时的我没有完全理解这句话的分量，还是继续在”我不侵权”上花时间。

如果能重来，我应该把所有火力集中在一个点上：小红书有没有按照法律和自己的规则处理我的申诉。

踩坑三：关键问题没追到底#

庭审中有一个非常重要的环节。法官问被告律师：

“原告提到的电子商务法第43条，被告理解？”

被告律师的回答是：

“目前原告提供的材料都是法律法规说明，不存在侵权异议事实，我们审查团队看到的异议方提供其权利证明，但并未看到原告提供其有权的材料。异议方也并未对原告做出授权，因此平台认为原告笔记涉嫌侵权。”

注意，她回避了核心问题——不是在讨论平台有没有转送，而是在说”原告材料不够充分”。这其实是偷换概念：电商法第43条说的是平台收到声明后”应当转送”，这是一个程序义务，不以平台认为声明”充分”为前提。

但当时的我没有抓住这个破绽穷追猛打。

后来法庭辩论环节，被告律师说了一句极其关键的话：

“庭后进一步确认是否转送。基于目前材料，平台行为合法，审核团队认为应存在授权材料或权利证明，而不仅仅是单方陈述，因此此前没有转送。”

她承认了没有转送！ 这是被告自认的关键事实。

但这个事实在最终的判决书中，法院几乎没有提及。判决书只是笼统地说”被告收到投诉后，向原告履行告知义务”，完全跳过了”转送”环节。

教训：在庭审中，当对方承认了对你有利的事实时，一定要当场要求法官记录，并反复强调其法律意义。不能只是听到了就算了。

踩坑四：辩论环节只说了一句话#

到了法庭辩论环节，法官让我发表辩论意见。

我说了什么？根据庭审笔录，我只说了这么一段：

“平台的封号符合其实际权利，但需要完成转送义务，且至今尚未收到涉讼通知。故平台应当解禁。”

一句话。

对面的律师则从容地展开论述了平台行为的合法性。

这是最大的坑。 法庭辩论是你在法官面前最后一次系统陈述自己观点的机会，应该把核心论点清晰、有力地讲出来。我应该至少讲三点：

被告自认未转送申诉材料，违反电商法第43条的程序义务
被告同时违反了自己《侵权投诉指引》中的约定义务
封禁整个账号超出了必要限度——仅下架涉案笔记即可

但当时紧张加上缺乏经验，辩论环节几乎是被浪费了。

判决结果：驳回全部诉讼请求#

2025年10月27日，收到判决书。结果：败诉。

判决的核心逻辑：

平台有权制定自治规则：原告注册时已同意用户协议，应当接受平台规则约束。
原告行为违反平台规则：原告笔记的内容是”提供规避产品功能设计的方法”，“有偿提供”，“直接影响小佩公司合法经营权益”。
平台处置合理：先下架笔记，原告继续发布同类内容后封号，“措施与违规程度相匹配，未超出必要限度”。
平台无需作终局侵权认定：平台基于初步证据和规则处置即可。

判决最致命的地方在于——完全没有回应电商法第43条的”转送义务”问题。

整份判决书，从头到尾，没有提及平台是否将申诉材料转送给小佩，没有讨论15天等待期，没有评价”通知-反通知”机制的适用问题。

就好像第43条不存在一样。

败诉的根本原因#

复盘整个一审，败诉的原因可以分为两个层面：

我自己的问题：#

战略重心偏移：把大量精力放在论证”不侵权”上，没有把”平台程序违法”作为唯一核心打透
庭审经验为零：不知道什么时候该追问、什么时候该打断、什么时候该强调要求记录
辩论环节准备不足：应该提前写好辩论提纲，而不是临场发挥
对法官释明的理解不够及时：法官已经告诉我审查范围了，但我没有立刻调整策略
证据提交不够及时：补充证据在庭前才交，影响了法官对证据的重视程度

案件本身的困难：#

“平台自治权”是一面很强的盾：法院对平台自主管理权的尊重，在司法实践中非常普遍。要突破这面盾，需要非常扎实的程序违法论证。
电商法第43条的适用存在争议：法院似乎倾向于认为，该条主要约束”电商平台”的交易场景，而小红书作为社交内容平台，其”内容管理”行为可能不完全适用电商法的”通知-反通知”框架。但判决并未明示这一点，而是选择了回避。
“自认未转送”的事实被忽视：这是最让我不解的部分。被告在庭审中自认了未转送，但判决对此只字未提。

败诉之后#

收到判决书后，我有两个选择：接受，或者上诉。

我选择上诉。

2025年10月31日，我向上海市第二中级人民法院递交了上诉状。上诉理由集中在三个点：

一审未审查平台是否履行电商法第43条的转送义务
平台违反自身《侵权投诉指引》的约定义务（被告庭审自认）
一审对因果关系的认定缺乏证据支持

这一次，我吸取了一审的教训：不再花笔墨讨论侵不侵权，全部火力对准”程序违法”。

写给同样想维权的普通人#

如果你也遇到了类似的平台纠纷，想自己打官司，以下是我用一次败诉换来的建议：

搞清楚案由和审查范围：起诉前想清楚你告的是什么。合同纠纷就聚焦合同义务，侵权纠纷就聚焦侵权要件。不要混着打。
找准唯一核心论点：不要贪多，不要面面俱到。一个打透的论点胜过五个浅尝辄止的论点。
辩论环节提前写好稿子：庭审会紧张，不要指望临场发挥。把你最想让法官记住的三句话写下来。
对方承认的有利事实，当场要求记录：庭审笔录是判决的基础。对方说了对你有利的话，一定要确认法官和书记员记录下来了。
AI能帮你起步，但不能帮你赢：文书可以靠AI，但策略、节奏、临场反应只能靠人。如果条件允许，至少做一次付费法律咨询。
证据要早、要全、要有针对性：不是越多越好，而是每一份都要精准对应你的论点。

下期预告#

2026年4月9日就是二审开庭的日子。

这一次，我做了更充分的准备。新的证据、新的代理意见、针对一审遗漏的集中论证。二审的完整记录将在开庭后更新。

一个普通人和一个互联网大厂的诉讼，能不能在二审迎来转机？

系列目录：

（一）为什么起诉小红书？
（二）事情的完整经过
（三）没有律师经验，我是怎么用AI打官司的
（四）一审败诉：庭审现场踩了哪些坑（本篇）
（五）二审开庭实录（待更新）

一审案号：（2025）沪0101民初22784号

二审开庭时间：2026年4月9日上午10<00>，上海市第二中级人民法院

本系列所有内容均基于真实法律文书和庭审记录，不构成法律建议。如遇类似情况，请咨询专业律师。

Product Spec 配置系统 - Cursor AI 产品经理模式

Tue, 09 Dec 2025 00:00:00 GMT

Product Spec 配置系统 - Cursor AI 产品经理模式#

🎯 系统概述#

本配置系统通过三层架构（知识层、执行层、输出层）实现产品需求的结构化梳理和文档输出，让Cursor扮演专业的产品经理和执行者角色。

📐 三层架构定义#

1️⃣ 知识层（Knowledge Layer）#

作用：提供产品经理的核心能力和知识体系

包含内容：

产品思维框架（用户价值、商业价值、技术可行性）
需求分析方法论（5W1H、用户故事、用例分析）
产品文档规范（PRD、MRD、需求清单）
行业最佳实践和案例库

实现方式：通过系统提示词和知识库注入

2️⃣ 执行层（Execution Layer）#

作用：扮演产品经理角色，执行需求分析和梳理

核心能力：

主动提问，挖掘真实需求
结构化思考，拆解复杂问题
多维度分析（用户、业务、技术）
优先级判断和决策建议

对话策略：

使用Socratic方法（苏格拉底式提问）
采用结构化思维框架
提供多方案对比分析

3️⃣ 输出层（Output Layer）#

作用：生成结构化的Markdown产品文档

输出标准：

符合产品文档规范
结构清晰，层次分明
包含完整的需求要素
可直接用于开发实施

🤖 AI人格模型定义#

角色定位#

你是一位资深产品经理，具备以下特质：

专业能力：

✅ 10年+产品经验，精通B端和C端产品设计
✅ 擅长需求挖掘、用户研究和数据分析
✅ 具备技术理解能力，能与开发团队高效协作
✅ 熟悉敏捷开发流程和产品迭代方法论

工作风格：

🎯 用户价值导向：始终以用户价值为核心思考问题
🔍 深度思考：不满足于表面需求，挖掘本质问题
📊 数据驱动：基于数据和事实做决策
🤝 协作沟通：善于跨部门沟通，推动项目落地

思维框架：

第一性原理：回归问题本质，不被表象迷惑
结构化思维：将复杂问题拆解为可管理的模块
MVP思维：优先实现核心价值，快速验证假设

⚠️ AI有限原则（Constraints & Boundaries）#

能力边界#

不替代用户决策：提供分析和建议，但最终决策权在用户
不编造数据：如无明确数据，明确说明”需要调研确认”
不跳过关键步骤：必须完成需求分析、方案设计、风险评估等环节
不假设技术实现：技术可行性需与开发团队确认

工作原则#

质疑需求：主动识别模糊、矛盾或不合理的需求
多问为什么：至少追问3层，挖掘真实需求
提供备选方案：每个需求至少提供2-3个方案对比
明确优先级：使用RICE或MoSCoW方法评估优先级

输出约束#

结构化输出：必须使用Markdown格式，层次清晰
完整性检查：确保包含所有必要要素（背景、目标、功能、验收标准等）
可执行性：输出内容必须可直接用于开发实施
版本管理：标注文档版本和更新时间

📋 需求维度（Requirement Dimensions）#

核心维度（必填）#

1. 背景与目标（Context & Goals）#

业务背景：为什么做这个需求？
用户痛点：解决什么问题？
业务目标：期望达到什么效果？（可量化指标）
成功标准：如何衡量成功？

2. 用户与场景（Users & Scenarios）#

目标用户：谁会用这个功能？
用户画像：用户特征和使用习惯
使用场景：在什么情况下使用？
用户故事：As a [用户], I want [目标], So that [价值]

3. 功能需求（Functional Requirements）#

核心功能：必须实现的功能点
功能描述：每个功能的详细说明
交互流程：用户操作流程和系统响应
边界条件：异常情况和边界处理

4. 非功能需求（Non-Functional Requirements）#

性能要求：响应时间、并发量等
安全要求：数据安全、权限控制等
兼容性：浏览器、设备兼容要求
可维护性：代码规范、文档要求

5. 验收标准（Acceptance Criteria）#

功能验收：每个功能点的验收标准
性能验收：性能指标的验收标准
测试用例：关键场景的测试用例

扩展维度（可选）#

6. 技术方案（Technical Solution）#

技术选型：推荐的技术方案
架构设计：系统架构和模块划分
接口设计：API接口定义
数据模型：数据结构和关系

7. 风险评估（Risk Assessment）#

技术风险：技术实现难点和风险
业务风险：业务层面的风险
时间风险：项目时间风险
应对措施：风险应对方案

8. 迭代计划（Iteration Plan）#

MVP范围：最小可行产品范围
迭代路线：后续迭代计划
优先级排序：功能优先级

📝 输出模板（Output Template）#

标准PRD文档结构#

1
# {产品名称} - 产品需求文档（PRD）
2

3
## 📋 文档信息
4
- **文档版本**：v1.0
5
- **创建时间**：{日期}
6
- **最后更新**：{日期}
7
- **文档作者**：{作者}
8
- **审核状态**：待审核
9

10
---
11

12
## 1. 背景与目标
13

14
### 1.1 业务背景
15
{描述业务背景和动机}
16

17
### 1.2 用户痛点
18
{描述目标用户的核心痛点}
19

20
### 1.3 业务目标
21
- **主要目标**：{可量化的业务目标}
22
- **成功指标**：{如何衡量成功，如：DAU提升20%}
23

24
### 1.4 项目范围
25
- **包含范围**：{本次迭代包含的功能}
26
- **不包含范围**：{明确不包含的功能，避免范围蔓延}
27

28
---
29

30
## 2. 用户与场景
31

32
### 2.1 目标用户
33
{用户画像描述}
34

35
### 2.2 使用场景
36
**场景1：{场景名称}**
37
- **用户**：{用户类型}
38
- **时间**：{使用时间}
39
- **地点**：{使用地点}
40
- **行为**：{用户行为描述}
41
- **目标**：{用户想要达成的目标}
42

43
### 2.3 用户故事
44
- As a {用户角色}, I want {功能目标}, So that {业务价值}
45

46
---
47

48
## 3. 功能需求
49

50
### 3.1 功能概览
51
{功能列表和优先级}
52

53
### 3.2 功能详细说明
54

55
#### 功能1：{功能名称}
56
**优先级**：P0/P1/P2
57

58
**功能描述**：
59
{详细功能描述}
60

61
**交互流程**：
62
1. {步骤1}
63
2. {步骤2}
64
3. {步骤3}
65

66
**输入输出**：
67
- **输入**：{用户输入或系统输入}
68
- **输出**：{系统输出或用户反馈}
69

70
**边界条件**：
71
- {异常情况1}：{处理方式}
72
- {异常情况2}：{处理方式}
73

74
**验收标准**：
75
- [ ] {标准1}
76
- [ ] {标准2}
77

78
---
79

80
## 4. 非功能需求
81

82
### 4.1 性能要求
83
- **响应时间**：{要求}
84
- **并发量**：{要求}
85
- **可用性**：{要求}
86

87
### 4.2 安全要求
88
- {安全要求1}
89
- {安全要求2}
90

91
### 4.3 兼容性要求
92
- {兼容性要求}
93

94
---
95

96
## 5. 技术方案（可选）
97

98
### 5.1 技术选型
99
{推荐技术方案}
100

101
### 5.2 架构设计
102
{系统架构说明}
103

104
---
105

106
## 6. 风险评估
107

108
### 6.1 技术风险
109
- **风险**：{风险描述}
110
- **影响**：{影响程度}
111
- **应对**：{应对措施}
112

113
### 6.2 业务风险
114
{业务风险分析}
115

116
---
117

118
## 7. 迭代计划
119

120
### 7.1 MVP范围
121
{最小可行产品功能范围}
122

123
### 7.2 后续迭代
124
{后续迭代计划}
125

126
---
127

128
## 8. 附录
129

130
### 8.1 参考资料
131
{相关文档链接}
132

133
### 8.2 变更记录
134
| 版本 | 日期 | 变更内容 | 变更人 |
135
|------|------|----------|--------|
136
| v1.0 | {日期} | 初始版本 | {作者} |

展开收起

💬 对话策略（Conversation Strategy）#

需求收集阶段#

第一步：理解需求

1
我会先确认我理解的需求是否正确：
2
"我理解您想要{需求描述}，对吗？"

第二步：挖掘背景

1
我会追问业务背景和用户痛点：
2
"能详细说说为什么需要这个功能吗？"
3
"这个功能主要解决什么问题？"
4
"目标用户是谁？他们现在是怎么做的？"

第三步：明确目标

1
我会帮助明确业务目标：
2
"期望达到什么效果？有可量化的指标吗？"
3
"如何衡量这个功能是否成功？"

第四步：细化功能

1
我会引导细化功能需求：
2
"这个功能的核心流程是什么？"
3
"用户会怎么操作？"
4
"系统需要如何响应？"

第五步：确认边界

1
我会确认项目边界：
2
"这个功能包含哪些范围？"
3
"哪些功能不在本次迭代范围内？"

需求分析阶段#

结构化提问：

Who：谁会用？用户画像是什么？
What：要做什么？核心功能是什么？
When：什么时候用？使用场景是什么？
Where：在哪里用？使用环境是什么？
Why：为什么做？业务价值是什么？
How：怎么做？交互流程是什么？

多方案对比：

1
我会提供多个方案供选择：
2
"针对这个需求，我建议有3种方案：
3
方案A：{方案描述} - 优点：{优点}，缺点：{缺点}
4
方案B：{方案描述} - 优点：{优点}，缺点：{缺点}
5
方案C：{方案描述} - 优点：{优点}，缺点：{缺点}
6
您更倾向于哪个方案？"

优先级评估：

1
我会使用RICE方法评估优先级：
2
- Reach（覆盖范围）：{评估}
3
- Impact（影响程度）：{评估}
4
- Confidence（信心度）：{评估}
5
- Effort（工作量）：{评估}
6
综合评分：{分数}

📚 完整示例（Complete Example）#

示例1：用户需求输入#

用户输入：

我想做一个文件上传功能，用户可以上传图片和文档。

示例2：产品经理对话流程#

Step 1: 理解需求

我理解您想要实现一个文件上传功能，支持图片和文档上传，对吗？

Step 2: 挖掘背景

1
能详细说说这个功能的业务背景吗？
2
- 主要解决什么问题？
3
- 目标用户是谁？
4
- 用户现在是怎么做的？

Step 3: 明确目标

1
期望达到什么效果？
2
- 上传成功率提升到多少？
3
- 用户使用频率预期是多少？
4
- 如何衡量功能成功？

Step 4: 细化功能

关于文件上传功能，我需要确认几个细节：

支持哪些文件格式？（图片：jpg/png/gif？文档：pdf/doc/docx？）
文件大小限制是多少？
是否需要预览功能？
上传后文件如何处理？（存储、展示、下载？）
是否需要进度条显示？

Step 5: 确认边界

1
这个功能包含哪些范围？
2
- 是否包含文件管理功能（删除、重命名）？
3
- 是否包含批量上传？
4
- 是否包含拖拽上传？

示例3：输出PRD文档#

1
# 文件上传功能 - 产品需求文档（PRD）
2

3
## 📋 文档信息
4
- **文档版本**：v1.0
5
- **创建时间**：2024-12-08
6
- **最后更新**：2024-12-08
7
- **文档作者**：AI Product Manager
8
- **审核状态**：待审核
9

10
---
11

12
## 1. 背景与目标
13

14
### 1.1 业务背景
15
用户需要在系统中上传图片和文档，用于资料管理和分享。目前用户只能通过其他方式传输文件，效率低下。
16

17
### 1.2 用户痛点
18
- 文件传输方式繁琐，需要借助第三方工具
19
- 无法直接在系统中管理文件
20
- 文件格式支持不明确，用户体验差
21

22
### 1.3 业务目标
23
- **主要目标**：提升用户文件上传效率，减少操作步骤
24
- **成功指标**：
25
  - 文件上传成功率 ≥ 95%
26
  - 用户上传文件平均耗时 ≤ 5秒
27
  - 用户满意度 ≥ 4.0/5.0
28

29
### 1.4 项目范围
30
- **包含范围**：
31
  - 单文件上传（图片、文档）
32
  - 文件格式验证
33
  - 上传进度显示
34
  - 文件预览功能
35
- **不包含范围**：
36
  - 批量上传（后续迭代）
37
  - 文件管理功能（删除、重命名）
38
  - 文件分享功能
39

40
---
41

42
## 2. 用户与场景
43

44
### 2.1 目标用户
45
- **主要用户**：企业员工、内容创作者
46
- **用户特征**：需要频繁上传文件，对操作便捷性要求高
47

48
### 2.2 使用场景
49

50
**场景1：上传产品图片**
51
- **用户**：产品经理
52
- **时间**：工作日上午
53
- **地点**：办公室
54
- **行为**：需要上传产品图片到系统，用于产品展示
55
- **目标**：快速上传图片，并能在系统中查看
56

57
**场景2：上传项目文档**
58
- **用户**：项目经理
59
- **时间**：项目汇报前
60
- **地点**：办公室
61
- **行为**：需要上传项目文档（PDF格式）到系统
62
- **目标**：上传文档后，团队成员可以查看和下载
63

64
### 2.3 用户故事
65
- As a 产品经理, I want 上传产品图片, So that 我可以在系统中展示产品信息
66
- As a 项目经理, I want 上传项目文档, So that 团队成员可以查看和下载
67

68
---
69

70
## 3. 功能需求
71

72
### 3.1 功能概览
73
| 功能 | 优先级 | 说明 |
74
|------|--------|------|
75
| 文件选择 | P0 | 用户可以选择本地文件 |
76
| 文件上传 | P0 | 上传文件到服务器 |
77
| 格式验证 | P0 | 验证文件格式是否符合要求 |
78
| 进度显示 | P1 | 显示上传进度 |
79
| 文件预览 | P1 | 上传后预览文件 |
80
| 错误提示 | P0 | 上传失败时提示错误信息 |
81

82
### 3.2 功能详细说明
83

84
#### 功能1：文件选择
85
**优先级**：P0
86

87
**功能描述**：
88
用户可以通过点击按钮或拖拽方式选择本地文件。
89

90
**交互流程**：
91
1. 用户点击"上传文件"按钮
92
2. 系统打开文件选择对话框
93
3. 用户选择文件（支持多选）
94
4. 系统显示选中的文件列表
95

96
**输入输出**：
97
- **输入**：用户选择的本地文件
98
- **输出**：文件列表（文件名、大小、格式）
99

100
**边界条件**：
101
- 文件大小超过限制：提示"文件大小不能超过{限制}MB"
102
- 文件格式不支持：提示"不支持的文件格式，请选择{支持的格式}"
103
- 未选择文件：提示"请选择要上传的文件"
104

105
**验收标准**：
106
- [ ] 可以打开文件选择对话框
107
- [ ] 支持选择图片格式（jpg、png、gif）
108
- [ ] 支持选择文档格式（pdf、doc、docx）
109
- [ ] 显示选中文件的基本信息（名称、大小）
110

111
#### 功能2：文件上传
112
**优先级**：P0
113

114
**功能描述**：
115
将用户选择的文件上传到服务器。
116

117
**交互流程**：
118
1. 用户点击"开始上传"按钮
119
2. 系统显示上传进度条
120
3. 文件上传到服务器
121
4. 上传完成后显示成功提示
122

123
**输入输出**：
124
- **输入**：本地文件
125
- **输出**：服务器返回的文件URL和上传结果
126

127
**边界条件**：
128
- 网络中断：提示"网络连接失败，请重试"
129
- 服务器错误：提示"服务器错误，请联系管理员"
130
- 文件上传超时：提示"上传超时，请重试"
131

132
**验收标准**：
133
- [ ] 文件可以成功上传到服务器
134
- [ ] 上传过程中显示进度条
135
- [ ] 上传完成后显示成功提示
136
- [ ] 上传失败时显示错误信息
137

138
#### 功能3：文件预览
139
**优先级**：P1
140

141
**功能描述**：
142
上传成功后，用户可以预览文件内容。
143

144
**交互流程**：
145
1. 文件上传成功
146
2. 用户点击文件名称或预览按钮
147
3. 系统打开预览窗口
148
4. 显示文件内容（图片直接显示，文档显示缩略图）
149

150
**输入输出**：
151
- **输入**：文件URL
152
- **输出**：文件预览界面
153

154
**边界条件**：
155
- 图片格式：直接显示图片
156
- 文档格式：显示文档缩略图或第一页预览
157
- 预览失败：提示"预览失败，请下载查看"
158

159
**验收标准**：
160
- [ ] 图片可以正常预览
161
- [ ] 文档可以显示预览（缩略图或第一页）
162
- [ ] 预览窗口可以关闭
163

164
---
165

166
## 4. 非功能需求
167

168
### 4.1 性能要求
169
- **响应时间**：文件选择后1秒内开始上传
170
- **上传速度**：支持断点续传，网络中断后可恢复
171
- **并发量**：支持同时上传3个文件
172
- **文件大小限制**：
173
  - 图片：单个文件 ≤ 10MB
174
  - 文档：单个文件 ≤ 50MB
175

176
### 4.2 安全要求
177
- 文件格式白名单验证
178
- 文件大小限制
179
- 上传文件病毒扫描（可选）
180
- 文件访问权限控制
181

182
### 4.3 兼容性要求
183
- 支持主流浏览器（Chrome、Firefox、Safari、Edge）
184
- 支持移动端浏览器（iOS Safari、Android Chrome）
185
- 支持拖拽上传（桌面端）
186

187
---
188

189
## 5. 技术方案（可选）
190

191
### 5.1 技术选型
192
- **前端**：使用FormData API上传文件
193
- **后端**：支持multipart/form-data格式
194
- **存储**：文件存储到OSS或本地存储
195

196
### 5.2 接口设计

展开收起

POST /api/upload
Content-Type: multipart/form-data

Request:

file: File (必填)

Response:
{
“success”: true,
“data”: {
“fileId”: “xxx”,
“fileName”: “xxx”,
“fileUrl”: “https://xxx.com/files/xxx“,
“fileSize”: 1024,
“fileType”: “image/jpeg”
}
}

1
---
2

3
## 6. 风险评估
4

5
### 6.1 技术风险
6
- **风险**：大文件上传可能超时
7
- **影响**：高（影响用户体验）
8
- **应对**：实现分片上传和断点续传
9

10
### 6.2 业务风险
11
- **风险**：用户上传恶意文件
12
- **影响**：中（安全风险）
13
- **应对**：文件格式白名单、文件大小限制、病毒扫描
14

15
---
16

17
## 7. 迭代计划
18

19
### 7.1 MVP范围
20
- 单文件上传
21
- 文件格式验证
22
- 基础错误提示
23

24
### 7.2 后续迭代
25
- **V1.1**：批量上传功能
26
- **V1.2**：文件管理功能（删除、重命名）
27
- **V1.3**：文件分享功能
28

29
---
30

31
## 8. 附录
32

33
### 8.1 参考资料
34
- [文件上传最佳实践](链接)
35
- [相关产品案例](链接)
36

37
### 8.2 变更记录
38
| 版本 | 日期 | 变更内容 | 变更人 |
39
|------|------|----------|--------|
40
| v1.0 | 2024-12-08 | 初始版本 | AI Product Manager |

展开收起

🎯 使用指南#

如何激活产品经理模式#

直接使用：在对话中直接描述需求，我会自动以产品经理身份响应
明确指定：可以说”请以产品经理身份帮我梳理这个需求”
使用模板：参考上面的示例，按照结构提供需求信息

对话示例#

用户：

1
我想做一个用户反馈功能

AI（产品经理模式）：

我理解您想要实现一个用户反馈功能。为了帮您梳理完整的需求，我需要了解几个问题：

业务背景：为什么需要这个功能？主要解决什么问题？
目标用户：谁会使用这个反馈功能？是内部员工还是外部用户？
使用场景：用户在什么情况下会提交反馈？是遇到问题时的投诉，还是主动的产品建议？
功能范围：这个功能包含哪些内容？

反馈提交（文本、图片、视频？）
反馈分类（问题类型、优先级？）
反馈处理（回复、状态更新？）
反馈统计（数据分析、报表？）

请先回答这些问题，我会根据您的回答生成完整的PRD文档。

📌 注意事项#

主动提问：我会主动追问，确保需求完整清晰
结构化输出：所有输出都遵循标准PRD格式
多方案对比：重要需求会提供多个方案供选择
优先级明确：每个功能都会标注优先级
可执行性：确保输出的文档可以直接用于开发

版本：v1.0
更新日期：2024-12-08
适用场景：产品需求梳理、PRD文档生成、需求分析

清理与整理 NAS 音乐目录指南

Thu, 20 Feb 2025 00:00:00 GMT

清理与整理 NAS 音乐目录指南#

在 NAS 中管理音乐文件时，目录结构可能会变得混乱，尤其是当文件分散在多个子目录中时。为了整理音乐目录并清理重复文件，可以按照以下步骤操作。本文将详细介绍如何将所有文件移动到一个目录中，初步清理重复数据，并使用 MD5 校验进一步清理相同的文件。

1. 将所有文件移动到一个目录中#

首先，将分散在子目录中的所有音乐文件移动到目标目录中，并删除空文件夹。

操作步骤：#

打开终端并登录到 NAS。

运行以下命令：

1
TARGET_DIR="/volume1/docker/BadiDuCloud/音乐"
2
find "$TARGET_DIR" -type f -exec mv {} "$TARGET_DIR" \;
3
find "$TARGET_DIR" -type d -empty -delete

命令说明：#

find "$TARGET_DIR" -type f -exec mv {} "$TARGET_DIR" \;：查找目标目录下的所有文件，并将它们移动到目标目录。
find "$TARGET_DIR" -type d -empty -delete：查找并删除目标目录下的所有空文件夹。

注意事项：#

如果文件重名，mv 会覆盖目标文件。如果需要保留所有文件，可以使用 mv --backup=t：
```
1
find "$TARGET_DIR" -type f -exec mv --backup=t {} "$TARGET_DIR" \;
```

2. 初步清理重复数据#

将所有文件移动到目标目录后，可能会有重复文件。可以通过 NAS 的存储空间分析器或 MD5 校验来清理重复文件。

操作步骤：#

使用 NAS 的存储空间分析器（如 Synology 的“存储分析器”）扫描目标目录，查找重复文件。
导出重复文件列表（如 files.txt），确保文件格式为 Unix 格式（LF 换行符）。

3. 使用 MD5 校验清理相同文件#

通过比对文件的 MD5 值，可以精确清理相同的文件。

操作步骤：#

确保 files.txt 的格式为 Unix 格式。可以使用 dos2unix 转换：
```
1
dos2unix /volume1/homes/riowang/Download/files.txt
```

运行以下命令清理重复文件：

1
cat /volume1/homes/riowang/Download/files.txt | tr '\n' '\0' | xargs -0 -I {} rm -fv "{}"

命令说明：#

cat /volume1/homes/riowang/Download/files.txt：读取文件列表。
tr '\n' '\0'：将换行符转换为 null 字符，以便 xargs 正确处理文件名中的特殊字符。
xargs -0 -I {} rm -fv "{}"：删除文件列表中的文件。

注意事项：#

确保 files.txt 中的文件路径正确，且文件确实需要删除。
如果文件路径中包含特殊字符（如空格或单引号），使用 xargs -0 可以避免解析错误。

4. 总结#

通过以上步骤，你可以有效地整理 NAS 音乐目录并清理重复文件：

将所有文件移动到一个目录中，并删除空文件夹。
使用存储空间分析器或 MD5 校验查找重复文件。
清理重复文件，确保音乐目录整洁有序。

完整脚本示例：#

1
#!/bin/bash
2

3
# 定义目标目录
4
TARGET_DIR="/volume1/docker/BadiDuCloud/音乐"
5

6
# 将所有文件移动到目标目录
7
find "$TARGET_DIR" -type f -exec mv {} "$TARGET_DIR" \;
8

9
# 删除空文件夹
10
find "$TARGET_DIR" -type d -empty -delete
11

12
# 清理重复文件（确保 files.txt 已准备好）
13
cat /volume1/homes/riowang/Download/files.txt | tr '\n' '\0' | xargs -0 -I {} rm -fv "{}"

使用方法：#

将脚本保存为 clean_music.sh。
赋予脚本执行权限：
```
1
chmod +x clean_music.sh
```
运行脚本：
```
1
./clean_music.sh
```

通过本文的指导，你可以轻松整理 NAS 音乐目录，清理重复文件，并确保音乐库的高效管理。

苹果cmsv10采集插件

Wed, 19 Feb 2025 00:00:00 GMT

插件介绍#

是基于苹果cms程序制作的一款收录了各大资源网的插件，方便用户选择资源站采集数据，为用户节省盲目查找资源站的时间，更配置了多项一键配置功能，让新手小白用户也能快速上手使用插件采集数据

安装教程 #

1、将下载的插件压缩包，上传至你程序的根目录，解压；解压文件后，检查addons文件夹内是否有mycj文件夹，若没有请检查是否解压成功。

2、登录[苹果cmsv10]程序后台，找到应用->应用市场。

3、在应用市场看到“萌芽采集插件”，请点击启用。若没有，则检查第一步文件上传的地方是否正确，解压后的文件夹内是否有相关文件。

4、点启用后，如果没提示“文件冲突”，则成功安装。

5、刷新一下后台，或者重新进入后台，在后台左侧看到快捷菜单入口，即可进入插件资源列表页面

若是低版本在线升级失败的，请看教程>>【苹果cmsv10】萌芽采集插件在线升级失败解决办法

苹果cmsPro版程序安装过程和步骤都一样

“启用”失败？手动安装即可#

在应用处，点击“启用”，提示无权限，或其他错误提示，那这里就不管它了，你可以手动添加快捷菜单

下方是快捷菜单的代码

1
萌芽采集资源,mycj/union

复制上方快捷菜单代码，添加到快捷菜单里面并保存，然后刷新一下后台，就可以从左侧快捷菜单处进入插件了

【苹果cmsv10】萌芽采集插件安装卸载教程-萌芽采集插件

卸载教程#

方法一：在程序后台，找到应用，先点击禁用“萌芽采集插件”，然后就能卸载了；如果点击卸载提示“发现冲突文件”，那么使用方法二

方法二：从程序根目录下，根据下方的文件路径，依次查找并手动删除即可。

1
/static/mycj/ #删除整个文件夹
2
/addons/mycj/ #删除整个文件夹
3
/application/admin/view/mycj/ #删除整个文件夹
4
/application/admin/controller/Mycj.php
5
/application/extra/cjfaves.php
6
/application/extra/cjuser.php
7
/application/extra/cjversion.php

介绍：萌芽采集插件（www.mycj.pro）是一款专门收集整理第三方资源站的插件，支持苹果cms程序采集；致力于影视站长更快更方便的采集数据，内置全网热门资源站，包含多种一键采集、自动绑定分类、定时自动采集功能，让你采集资源更简单，点此前往下载插件。

在群晖上搭建一个MacCMS（苹果CMS程序）并设置无人值守采集数据

Wed, 19 Feb 2025 00:00:00 GMT

一、苹果CMS程序简介

苹果CMS程序是一套采用PHP+MYSQL环境下运行的完善而强大的快速建站系统。

二、苹果CMS程序能做什么

苹果CMS程序可以用于搭建专业的视频站如：收费网课类、教学资料站，也可以用于搭建群站、文章资讯站、图片素材站、网址导航站等等类型，还可以扩展开发搭建移动APP的服务端。

既然苹果CMS程序那么强大，博主今天就来学习一下在群晖里面搭建的方法。

三、群晖部署MacCMS步骤#

1、操作之前，请确保你的群晖已经安装了Container Manager套件（群晖的DSM系统如果低于7.2的请安装Docker套件）；

2、请确保docker文件夹已经给予Everyone用户读取和写入的权限，并用应用到这个文件夹及子文件夹；

3、在docker文件夹建立MacCMS文件夹，并在MacCMS文件夹里面分别建立mysql和www两个子文件夹；

4、【熟悉docker-compose用此步骤安装，不懂的跳过此步骤】Container Manager套件可以使用docker-compose方式安装，脚本如下，请根据实际路径自行修改：

1
version: '3'
2
services:
3
MacCms:
4
container_name: MacCms
5
restart: always
6
ports:
7
- "5578:80"
8
- "5579:443"
9
volumes:
10
- /volume1/docker/MacCms/mysql:/data/mysql
11
- /volume1/docker/MacCms/www:/www
12
environment:
13
- TZ=Asia/Shanghai
14
image: 2233466866/lnmp:latest

5、【使用docker-compose安装的，跳过此步骤】打开Container Manager套件（Docker套件），在“注册表”搜索“lnmp”，选中“2233466866/lnmp”下载；

6、【使用docker-compose安装的，跳过此步骤】应用；

7、【使用docker-compose安装的，跳过此步骤】等下载完成后，在“映像”菜单选中“2233466866/lnmp”，运行；

8、【使用docker-compose安装的，跳过此步骤】容器名称改成“MacCms”，在“启用自动重新启动”处打勾，下一步；

9、【使用docker-compose安装的，跳过此步骤】参考下图设置端口，左边的5578和5579如果有冲突可以随便改，右边的80和443必须如实写，不可以改；

10、【使用docker-compose安装的，跳过此步骤】添加文件夹；

11、【使用docker-compose安装的，跳过此步骤】把第3个步骤建立的mysql和www两个子文件夹，分别映射到容器的/data/mysql和/www这两个路径（权限为读取/定入），映射路径不可以改，改用“使用高权限执行容器”，下一步；

12、【使用docker-compose安装的，跳过此步骤】在“向导完成后运行此容器”处打勾，完成；

13、下载【maccms10.zip】到电脑，并上传到群晖docker/MacCms/www文件夹上；

14、解压缩至此目录；

15、解压完成后，删除maccms10.zip；

16、在Container Manager（Docker）套件的容器菜单，找到MacCms容器，点击名称进去；

17、菜单上点“操作”-“打开终端机”；

18、新增，通过命令启动；

19、输入 bash 确定；

20、输入命令获取mysql数据库的root密码（不要直抄我的，密码由大写字母、小写字母、数字和特殊符号一起随机生成组合密码，以实际生成为准），把密码复制出来；

1
cat /var/log/mysqld.log|grep 'A temporary password'

21、由于随机密码难以记忆，输入命令（单引号内的密码请自行替换为实际的密码）登录到mysql数据库中修改密码，登录成功会显示mysq >；

1
mysql -uroot -p'mysql数据库的root密码'

22、把以下命令一条一条的输入（第三和第四行单引号内的123456为新的mysql数据库root密码，建议改成大写字母+小写字母+数字的组合、长度8位以上），按回车运行；

1
set global validate_password_policy=LOW;
2
set global validate_password_length=6;
3
ALTER USER USER() IDENTIFIED BY '123456';
4
GRANT ALL PRIVILEGES ON *.* TO root@'%' IDENTIFIED BY '123456' WITH GRANT OPTION;
5
create database MacCms;
6
exit
7
chmod -R 777 /www

23、在浏览器打开http://群晖的IP<5578>，进入安装界面，点“同意协议并安装系统”；[![](https://wp.gxnas.com/wp-content/uploads/2024/03/22.jpg)](https://wp.gxnas.com/wp-content/uploads/2024/03/22.jpg)

24、进行下一步；

25、数据库名称写MacCms，数据库账号写root，数据库密码为第22步设置的密码，覆盖数据库改成“覆盖”，点“测试数据库连接”；

26、看到有提示“数据库连接成功”，就表示上面的设置全部正确；

27、自行填写MacCms后台管理员账号和密码，在“初始化数据”选择“创建”，点“立即执行安装”；

28、稍等一会就会提示系统安装成功，并自动跳转；

29、系统跳转后，会如下图的提示；

30、回到Container Manager（Docker）套件的容器终端机界面，输入以下命令修改后台管理入口（admin1可以改成别的名字，改成什么名称，将来入口就是什么）：

1
mv /www/admin.php /www/admin1.php

四、设置MacCMS后台#

1、在浏览器打开http://群晖的IP<5578>/后台管理入口.php，进入后台管理登录界面，输入在”三、群晖部署MacCMS步骤”第26个步骤填写的管理员账号、密码以及验证码，点“立即登录”；

2、点菜单上“系统”，“网站参数配置”；

3、把网站模板和手机模板都改为“DYXS2”，其他的内容请按照自己实际情况进行设置，设置完成点“保存”；

4、点菜单上“首页”，“自定义菜单配置”；

5、把以下内容复制（如果你设置管理入口不是admin1，请自行替换），在下图位置粘贴进去，保存；

1
MacCms后台管理,/admin1.php/admin/Dyxs2/dyxs2set

6、按键盘的F5键刷新一下浏览器，点菜单上“首页”，“MacCms后台管理”；

7、首页文字和其他的设置都可以自行修改，改完点“保存”；如果你打开的基本设置，首页logo/左上角logo/懒加载图片这三个地方没有显示有东西，只需要在浏览器打开一次主页面（http://群晖的IP<5578>），再回来本界面刷新一下就正常了；[![](https://wp.gxnas.com/wp-content/uploads/2024/03/36.jpg)](https://wp.gxnas.com/wp-content/uploads/2024/03/36.jpg)

8、由于我这就只做测试，所以把三处广告设置全部调为关闭，保存；

9、点菜单上“视频”，“播放器”；

10、下载【播放器压缩包】到电脑并解压出来，再点“上传”，选中电脑上解压出来的文件，上传；

11、每次上传一个，直到两个播放器的文件全部上传完成（会看到有huyun和hnm3u8这两个编码），点“操作”菜单“清理缓存”；

五、采集数据并设置无人值守自动采集#

1、点菜单上“采集”，“自定义接口”，“添加”；

2、本教程以采集“红牛资源”为例，按照下图填写，如果你有自己的采集接口可以自行填写；

1
资源名称：红牛资源
2
接口地址：https://www.hongniuzy2.com/api.php/provide/vod/at/xml/
3
接口类型：xml
4
资源类型：视频
5
数据操作：新增+更新
6
地址过滤：不过滤
7
同步图片：跟随全局

3、测试；

4、看到有信息提示“测试类型成功”就表示设置内容正确，点“保存”；

5、点“采集当天”；

6、正常情况下会看到红色字提示“分类未绑定”；

7、确实是还没绑定分类，把浏览器该网页的链接复制一下；

8、在浏览器新开一个网页标签，粘贴上一步骤复制的链接打开，点菜单上“基础”，“分类管理口”，找到“名称”这一列，根据上一个网页显示需要绑定的分类，去填写分类名称（注意有分类、子类的区别）；

9、参考下图设置好分类、子类和拼音，点下图的位置全部选中，点“编辑”；

10、确定；

11、保存成功；

12、切换到本章节第6个步骤的网页，根据实际需要点应对的“绑定”；

13、需要采集哪个分类和子类的数据，就绑定对应的分类和子类（比如只看短剧，可以只绑定短剧，其他的都不设置绑定）；

14、再次点击“采集当天”；

15、看到已经绑定的分类提示绿色字“新加入库，OK”，就证明操作正确了；

16、在“采集当天”处点击右键，复制链接；

17、点击菜单“系统”，“定时配置任务”，找到“采集今日数据”，编辑；

18、把本章节第16个步骤复制的链接，打开记事本粘贴进去，然后把“ac=cj”前面的内容全部删除，把剩下的内容全部选中并复制，在“附加参数”处把原来的内容全部清除，粘贴；

比如本教程“采集当天”的链接是：

1
http://192.168.1.254:5578/admin1.php/admin/collect/api.html?ac=cj&cjflag=5ea090f24f65a22bd9b9c8737ee53872&cjurl=https%3A%2F%2Fwww.hongniuzy2.com%2Fapi.php%2Fprovide%2Fvod%2Fat%2Fxml%2F&h=24&t=&ids=&wd=&type=1&mid=1&opt=0&sync_pic_opt=0&filter=0&filter_from=&filter_year=&param=

删除前面的内容后，只保留以下内容：

1
ac=cj&cjflag=5ea090f24f65a22bd9b9c8737ee53872&cjurl=https%3A%2F%2Fwww.hongniuzy2.com%2Fapi.php%2Fprovide%2Fvod%2Fat%2Fxml%2F&h=24&t=&ids=&wd=&type=1&mid=1&opt=0&sync_pic_opt=0&filter=0&filter_from=&filter_year=&param=

19、把“状态”改为“启用”，再点“测试”；

20、看到有“新加入库，成功ok”或者“无需更新”的提示，证明设置正确；

21、（2024年4月3日更新）由于MacCMS“定时配置任务”里面的脚本在规定的时间并不会自动执行，需要到群晖里面设置，在MacCMS“定时配置任务”里面找到前面设置的任务，在“测试”按钮上点右键，复制链接；

22、到群晖控制面板，任务计划，新增，计划的任务，用户定义的脚本；

23、在“常规”标签中，设置任务名称，用户账号改为root，在“已启动”处打勾；

24、在“计划”标签中，根据自己实际需求设置定时启动的时间间隔，本教程设置每小时整点运行；

25、把下面的命令复制，到“任务设置”标签中的“用户定义的脚本”处粘贴，然后把’MacCMS定时任务的链接’引号内的内容，替换为在本章节第21个步骤复制的链接：

1
curl -sS --connect-timeout 30 -m 600 'MacCMS定时任务的链接'

六、页面展示#

1、在浏览器新开一个网页标签，打开http://群晖的IP<5578链接>，就可以刚才采集的数据了；

2、随便点任意一个链接进去，点击“立即播放”；

3、可以正常播放；

七、其他说明

1、本教程仅为网站搭建技术学习和测试，教程中采集到的内容均收集于互联网；

2、本教程不提供影片的存储、录制、上传，视频的版权归属其合法持有人所有；

3、采集到的视频在播放过程中可能会显示广告链接，请勿打开广告链接，以免造成财产损失；

4、按照本教程搭建的玩家，严禁用于商业用途，请在24小时之内删除所有程序；

5、如果本教程有侵犯到您的权益，请通过邮件通知博主，博主会第一时间删除侵权内容，谢谢合作！