规则仓库，其实是一个文件夹
它没有服务端、没有账号、没有签名，也没有后台。软件只做两次 GET：先取一份清单，再按名字取那一条规则。弄懂这两步，安装、更新、镜像、手动导入这些事就全都能对上号了。
仓库地址写死在客户端里
规则仓库不是你在软件里填一个地址连过去的，它是代码里的一个常量：
https://raw.githubusercontent.com/Predidit/KazumiRules/main/
这行地址指向 GitHub 的 raw 文件通道，不是网页地址，也不是 API。所以「换一个规则仓库」这件事在客户端里并不存在——你唯一能改的是前面那段镜像前缀，后面要取哪个文件是固定的。
| 时机 | 请求 | 拿到的内容 |
|---|---|---|
| 打开「规则仓库」页 | index.json | 一份清单：有哪些规则、各自什么版本、最后更新于哪天 |
| 点某一条的「安装 / 更新」 | {name}.json | 那一条规则的全文：站点地址、选择器或接口配置、版本号 |
index.json：只是清单，不是规则
清单里每条只有六个字段，长这样（取自仓库当前内容）：
{
"name": "akianime",
"version": "1.4",
"author": "",
"lastUpdate": 1786942825000,
"useNativePlayer": true,
"antiCrawlerEnabled": false
}
对应到界面上：version 是规则卡片上那个版本号，lastUpdate 是「更新于 …」（原始值是从 1970 年起的毫秒数），antiCrawlerEnabled 为真时会多一个「含验证支持」标签。name 不只是名字，它同时就是文件名——清单里写 akianime，软件就去取 akianime.json。
列表页本身能做的事不多，但够用：按名称或作者搜索、在「全部 / 已安装 / 可更新」之间筛、按最近更新或名称排序。加载失败时会显示上次的成绩单，并直接给你一个「切换加速」的按钮——那不是装饰，原因见下面的镜像一节。
点「安装」之后，发生五件事
下载只是第一步。真正拦住坏规则的是中间那三道校验，三道都过，才会写进本地。
用清单里的 name 拼出 {name}.json 再请求一次。所以仓库里多一条规则，客户端代码一行都不用动。
文件里写的名字和你要装的名字不一致，这份文件会被丢弃。这道关是给镜像和上游兜底的——防止拿错包，也防止某个镜像把旧内容套在新名字上。
规则声明了自己需要哪个级别的能力。客户端够不到就装不上，提示「规则需要更高版本客户端」。这不是规则坏了，是版本旧了。
远端版本不比本地新时直接跳过。镜像同步有延迟，少了这一关，一次刷新就可能把昨天更新的规则换回旧版。
全部规则存在同一份 plugins.json 里（应用支持目录下的 plugins/v2/）。装是追加，更新是替换，同一份文件里不会出现两条同名规则。
api 字段是版本门槛，不是文件格式
规则文件里的 "api": "4" 这行，说的不是「这是第 4 版规则」，而是「我用了第 4 级能力，客户端至少得支持到这一级」。仓库 README 给了一张对照表：
| api | 最低客户端 | 这一级开始有的能力 |
|---|---|---|
| 1 | 1.0.0 | 基础的 GET 抓取与 XPath 解析 |
| 2 | 1.3.0 | 搜索可以走 POST |
| 3 | 1.3.6 | 支持自定义 Referer，以及基于 iframe src 的 legacy 解析器 |
| 4 | 1.6.8 | 沿用第 3 级的全部能力（README 未单列新增项） |
| 5 | 1.9.3 | HLS 清单播放前的广告段过滤 |
镜像改的是地址前缀，不是内容
raw.githubusercontent.com 在大陆经常连不上，于是客户端在请求前把地址前缀换掉。四个选项都是这个思路，只是换法不同：
| 界面上的名字 | 实际请求地址 | 什么时候用 |
|---|---|---|
| gh-proxy（默认） | 前缀 gh-proxy.org/ 加完整原始地址 | 默认值，多数地区直接可用 |
| ghfast | 前缀 ghfast.top/ 加完整原始地址 | 默认镜像超时或返回错误时换这个 |
| GitCode | raw.gitcode.com/gh_mirrors/ka/KazumiRules/raw/main/ 加域名之后的路径 | 国内镜像，前面两个都不通时试 |
| 直连 | 原地址，不加前缀 | 能正常访问 GitHub 的网络 |
它改的只是「从哪儿把文件拿回来」，拿到手的仍是同一份 json，内容一个字都不会变。所以换镜像不会让规则变得更好用，只会让列表刷得出来。入口在「规则仓库」页右上角的「切换加速」，加载失败页上也有同名按钮——站上别处说的「打开规则仓库镜像」，指的就是这个四选一。
更新只比版本号，而且不会偷偷换
本地记着每条规则装的是哪个版本，清单里写着仓库里是哪个版本，两个一比就知道该不该动。比出来有新版，列表上出现「可更新」，筛选栏里的计数也会跟着变；点「更新全部」时最多同时下载 4 条，全部就绪后一次性写盘——中途断网不会留下一半新一半旧的状态。
两件事需要知道：第一，更新不会在后台自动替换，得你点；第二，因为禁止降级，镜像落后时你会看到「已是最新」，而不是版本被推回去。装好的规则不会因为仓库改了什么而突然消失——它已经是本地的一份拷贝，只有你主动更新才会变。
手动导入和点「安装」，其实是一回事
软件里「安装」这个动作，本质就是「下载这个 json 然后导入」。所以你把同一条规则的文件存到本地再从文件导入，结果完全一样，都落在同一份 plugins.json 里。差别只在护栏：
| 点「安装 / 更新」 | 手动导入 | |
|---|---|---|
| 名字与清单一致 | 校验，不一致就丢弃 | 只校验名字不为空 |
| api 级别 | 校验 | 校验 |
| 降级 | 拒绝写入 | 允许，同名直接覆盖 |
| 进本地 plugins.json | 是 | 是 |
| 参与「可更新」判断 | 是 | 是，只要名字和清单对得上 |
最后一行值得多说一句：更新判断只看名字和版本号，不问这条规则是装的还是导的。所以手动导入的规则，以后仓库里更新了你照样会收到提示；反过来，如果你在导入前改过名字，它就再也不会被提示更新了。
另外两个操作层面的细节：文件导入一次只能选一个文件，但那个文件的内容可以是 JSON 数组，一次装多条；剪贴板导入更宽松，支持一次粘多条 kazumi:// 链接、单条 JSON 或 JSON 数组，同名规则会被替换。
往仓库里塞一条规则
仓库对提交的要求很窄，但有几条必须遵守，否则 PR 会被直接打回：
一次 PR 只加或改 *.json。文件名必须和文件里的 name 一致，因为客户端就是按这个名字取文件的。
改动了规则就递增版本号。别人的客户端靠这个数字判断要不要更新，不升等于改了也没人收到。
用了哪一级能力就声明哪一级。写低了客户端会按老方式解析然后出错，写高了老用户装不上。
这两个文件由仓库在 PR 合并后自动生成。手改的那部分会被覆盖，而且会让后续合并冲突。清单是结果，不是输入。
合并之后什么都不用做：客户端下一次刷新列表就看到了。没有发布按钮，没有审核队列，也不用通知谁。
四个常见卡点
规则仓库一直转圈，或者提示「无法访问规则仓库」
这是取不到清单，不是规则有问题。四个加速选项轮流试一遍，通常有一个能通；能正常访问 GitHub 的网络选「直连」反而更快。
装的时候提示「规则需要更高版本客户端」
规则用了你这版还不支持的能力。升级 Kazumi 再装；升不了就只能放弃这一条，没有别的绕过办法。
装好了，但搜不到某部番
大概率是那个源没有这部作品，跟仓库无关。换关键词（日文原名、罗马音）或换一个源再试。规则本身的失效判断在规则入门里有专门一节。
「可更新」一直是 0，但仓库明明更新了
先看名字。更新判断靠名字去清单里找对应条目，导入时改过名字、或者装的是仓库里已经删掉的规则，就永远匹配不上。其次看镜像是否还没同步到最新——换回直连刷新一次再判断。
弄懂仓库了，
接下来是自己写一条。
仓库里没有你要的源，就照着五个选择器自己搭一个——写完之后同样能导成链接发出去。