企业官网建设流程全解析

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

想弄清一个插件怎么把三个站点变成同一种交互，不必读完实现。README 已经把骨架写在明面上：一个工具名、一份配置结构、五个卡片字段，以及两条明确的懒加载边界。顺着这四条线索读，比翻入口文件快。想先看它在插件生态里的位置，可参考 完整插件清单与汉化避坑指南。

入口只有一个：anime_find_search

对模型来说只暴露一个工具。用户说的是「搜一下无职转生」「最近有哪些好看的动漫」「还有吗」，都被收敛成一次带关键词的调用，区别只在关键词是具体番名还是空。

后果有二：参数面很窄，模型不必理解三个来源各自的参数；追问「还有吗」是同一工具再次调用，卡片只是结果的呈现层。调用链因此是一条直线：会话 → 工具 → 已启用来源 → 归一 → 卡片。

三个来源是三条独立通道

来源在配置里是一个集合，默认只有 Mikan，AniBT 和 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 源安装会触发prepare，pnpm 默认拦截，于是报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 自动整理，数据来源于插件详情页。