首页 / 资讯中心 / 文章详情

读 anime-find 的源码,看三个来源怎么归一成一张卡片

读 anime-find 的源码,看三个来源怎么归一成一张卡片 ★ FEATURED ARTICLE
读 anime-find 的源码看三个来源怎么归一成一张卡片想弄清一个插件怎么把三个站点变成同一种交互不必读完实现。README 已经把骨架写在明面上一个工具名、一份配置结构、五个卡片字段以及两条明确的懒加载边界。顺着这四条线索读比翻入口文件快。想先看它在插件生态里的位置可参考 完整插件清单与汉化避坑指南。入口只有一个anime_find_search对模型来说只暴露一个工具。用户说的是「搜一下无职转生」「最近有哪些好看的动漫」「还有吗」都被收敛成一次带关键词的调用区别只在关键词是具体番名还是空。后果有二参数面很窄模型不必理解三个来源各自的参数追问「还有吗」是同一工具再次调用卡片只是结果的呈现层。调用链因此是一条直线会话 → 工具 → 已启用来源 → 归一 → 卡片。三个来源是三条独立通道来源在配置里是一个集合默认只有 MikanAniBT 和 AnimeGarden 要手动启用。没启用的来源不发请求也就不会产生结果或错误。每个来源带一个可替换的站点地址README 写的是「可按需替换镜像」站点换域名时改配置比等发版快。三条通道彼此隔离单源失败不会阻止其他来源返回结果所以「结果变少」和「插件坏了」是两件事。也可以用配置文件设默认来源-id:anime-findconfig:sources:[mikan]三条通道的调用形态相同一次搜索请求加一次详情请求。README 没有逐站公开请求参数与字段映射能确认的补充只有「启用后才请求对应站点」。归一化五个字段是唯一的公共契约卡片上只有封面、标题、评分、格式、资源数量。三个站点的结构不可能一样但只要能填出这五项上层就不必知道数据来自哪。字段各有分工标题和封面用于识别评分用于粗筛格式和资源数量回答「有没有、是什么」。再多会破坏节奏更细的信息下沉到详情面板。封面不是浏览器直连来源站而是经插件服务转发对话里的图不会因热链策略碎掉代价是图片流量要过插件服务用带宽换稳定。详情面板不改字段语义只换维度按字幕组和集数浏览。卡片回答「有没有」面板回答「哪个组、到第几集」。分页由设置里的结果上限控制不是隐藏常数。详情面板为什么介绍和短评要等一次点击详情卡有 Bangumi subject ID 时通过 Host 发请求User-Agent 和超时来自插件配置。数据分两层介绍、评分和基础信息来自公开 v0 API短评由 Host 代理非公开 p1 接口最多 5 条。两层都只在点击后加载渲染不写入提供给模型的工具正文。这解释了三件事介绍动辄几百字每次都塞进工具结果会占满上下文搜索只要一次往返简介要额外一次点击才付更合理第三方内容只在用户主动查看时出现不进入模型输入。降级也围绕这条边界p1 可能变更或不可用届时短评 Tab 自动隐藏不影响介绍和资源浏览本期不做 HTML 抓取后备。「昨天有短评今天没有」不是数据丢了是接口不通了。流媒体规则为什么必须可静态解析流媒体默认开启内置一条试点规则xfdm。规则不是脚本而是能被服务端预先解释的数据至少包含name、baseURL、searchURL、searchList、searchName、searchResult、chapterRoads、chapterResult{{keyword}}或{{query}}会被替换成关键词。播放地址有两种取法指向src/href的选择器或script:player_aaaa.url。后者从播放页的内联脚本对象里读MacCMS 站点常用会按同级encrypt字段处理 URL 编码或 base64。网络侧的约束更值得读。媒体在站外 CDN 时须用mediaHosts显式声明只有声明过的域才被解析和代理放行私网、回环、链路本地地址始终拒绝。mediaHeaders只作用于媒体请求值留空表示不发送该头键名含点视为域名README 特意说明不同 CDN 要求可能相反有的必须带 Referer有的带了就报错。结论是插件是有限代理而非开放代理HLS playlist 会重写分片链接。能力上限也明确不支持依赖 Kazumi WebView 拦截的动态规则不自动同步社区规则仓库受限 XPath 支持//tag、层级、序号、属性与属性包含谓词脚本、函数、文本匹配谓词都不支持。限制在静态子集里换来的是可审计配置能被读懂就不会在服务端跑出意料之外的请求。配置与构建两个结构性事实用户配置存在$DSH_HOME/settings.yaml的anime-find:段由 dsh 设置服务原子写入版本号与安装来源不落在这个段里。旧版anime-find.json只在 yaml 无该段时才被导入并改名备份。构建结构决定了安装方式源码在src/输出到lib/而lib/不进版本库、由prepare生成。git 源安装会触发preparepnpm 默认拦截于是报ERR_PNPM_GIT_DEP_PREPARE_NOT_ALLOWED。这不是配置问题。能力边界与需要知道的风险安全扫描 「含敏感能力」证据项为读写/删除本地文件、写入剪贴板不计风险以及发起外部网络请求。目前尚无人工评估站点也未做风险分级。这三项对搜番插件都在预期内但预期内不等于已审。版本条件有落差站点写「未声明 dsh 版本约束」README 要求 Node.js 22 且面向 DSH Web。数据来自第三方站点可用性不由插件保证插件不托管内容请遵守来源站点条款。总结拆开看anime-find 的复杂度几乎全在边界上三个来源收成一个工具不同结构的返回收成五个字段介绍和短评推到点击之后流媒体规则限制在静态子集。这些选择单看都朴素叠起来才让「在对话里搜番」不必理解站点差异。想写 tool 型插件的话它更像一份边界清单其余见 完整插件清单与汉化避坑指南。适合与不适合适合想理解 tool 型插件如何做多源归一的人准备自己写流媒体规则、需要知道字段与解析边界的人已在 DSH Web 上跑插件、想弄清配置落点的人不适合只想装完就用、不打算碰配置的人默认只有 Mikan结果少时要自己开来源期待动态规则或社区规则同步的人这两项首期都不支持需要短评长期稳定的人它依赖 Bangumi 的非公开接口随时可能隐藏标签anime-find、DeepSeek Harness、源码阅读、插件架构、多源聚合本文由 DeepSeek Harness Hub 自动整理数据来源于插件详情页。
阅读完成 · 觉得有帮助?
咨询建站