一个用于本地动画刮削的skill

Onelooker

书接上文 : https://stage1st.com/2b/thread-2285075-1-1.html

项目地址 : https://github.com/Onelookere/anime-scraper-skill

折腾了一个月这个skill感觉可用度已经比较高了，虽然不能覆盖所有规则，但应该比绝大部分工具都更省心
那种简单的NCOP+NCED+OVA+正片的结构几乎不可能出错
先提前说明，这个skil很重，非常重，费时费token，为了提高准确率做了很多护栏和校验
一开始其实没这么癫，但是规则越加越多就变现在这样了，我也懒得找最开始那个版本了

刮削主要使用bangumi作为主数据源，anidb作为bd结构匹配，tmdb用于获取海报以及数据兜底
能用语义判断的地方就不用脚本批处理，刮削会生成本地Nfo和大部分图片元数据，理论上不再需要联网获取数据
通过配置开启可以直接规范文件命名并建立硬链接，不会影响源文件，我本地测试SMB挂载的nas也是可以自动操作生成的
默认tv动画和剧场版都是平铺在一个文件夹内，媒体库类型使用混合电影和节目，虽然官方不推荐使用这个类型
但是文件名足够规范的情况下我暂时还没遇到问题

最终效果一定程度上受模型能力的影响，要求不会太高，但也不要用太差的模型，起码有预览版deepseek v4f的水平，上下文不够的模型很容易刮一半开始淌口水
标题和staff表使用bangumi的简中名称映射
单集标题和简介也是从bangumi->tmdb获取，如果没有可用的中文简介会使用日语
多季动画会拆分成多个条目，否则SP会混在一起
可以配置开启多模态来筛选海报，但会增加token消耗
未开启的情况下会做基本的语言/票数/感知哈希去重筛选，但效果有限，可以配置开启海报缓存，最后一步人工挑选海报然后让agent去替换

大部分的SP可以识别并入库，默认会过滤menu,pv,cm类型，没有anidb匹配的条目会根据文件名做语义分析
规则不可能面面俱到，比如vcb的凉宫里小凉宫和小鹤屋是编码成一整个长视频，这是真没办法，好在这种显著的特例最后的输出结果agent大概率能给你点出来
默认规则包含了很多我个人的偏好，可以根据自己的习惯修改
bangumi的接口直连可能有点问题，anidb的接口不直连可能有点问题
agent我测试过claude code cli, codex app, reasonix, zcode, 都可以正常调用

不过claude code调用deepseek v4f出现了疯狂爆上下文的问题, 原因未知, 一次干掉了我三块钱不敢再试了

拿VCB的二次元传国玉玺做测试
在reasonix使用deepseek v4f0731，一共花了七毛三，这还是涨价前的价格

不过这里的标题有点问题，应该是白箱 剧场版，这之后优化了一下标题语义编排
简介，staff，海报，硬链接都正常




分级标题和简介正常，SP识别了多版本的ED和双版本的剧中剧，缓存了海报原图用于人工替换





最后用AI-Raws的巨人大包测试，包含了包含了四季tv + 完结篇 + q版 + 总集剧场版 + 音乐会 + 数不清的特典/ova/oad
而且包内除了主剧集外其他文件都是混在一起的, 这种搁以前肯定是刮不了了


在zcode里使用白嫖的glm5.3

中途只干预了一次，让agent把第三季和最终季不要拆分成上下两个条目，不过这种极端复杂的情况本来就是盯着好一点，起码要让agent初步整理出包含哪些独立条目后让你确认一下

q版我不想要入库，所以一开始声明把q版剧集跳过了，最后的结果说实话比我预期要差，但还在可接受范围内

主要是封面选取比较差，然后是OAD不能单独成条目，应该并入SP，还有个问题是完结篇竟然在TMDB根本没有条目，是编辑看破防了还是怎么的

不过agent好就好在这些人工修改起来不算太麻烦，而且有提前缓存可用的封面，跟AI说清楚需求就行了

关键的剧集和sp信息没有错误，完结篇我让agent合并为单一季

话又说回来，最好不要往agent里塞这种超大包，更不能图省事一次刮多个动画，上下文很容易撑爆，巨人这个包一开始我用的luna， 280k的上下文根本跑不了一点

我没有在空的环境测试过，初次使用之前先备份一下防止不必要的风险

skill具体的使用和配置参考readme.md

后续可能会更新，一些小需求的话直接让agent在你本地改就好了

目前正规渠道里性价比最高的应该是opencode首月五🔪的订阅，有相当多的deepseek额度