聊一个我针对某老司机网站开发脚本的历程（个人开源项目，不做推广，无群组，无收费）

作者：#drnleas 板块：#搞七捻三 最近，我花了一个月时间，针对一个老司机们经常上的知名日式影片数据站点进行开发的前端优化脚本这是一个专门针对这个网站的前端界面重构脚本项目，是根据我这些年使用这个网站的日常痛点开发的，好几年前我就有想法了，我当时甚至想花钱找人给我定制一份。但是觉得沟通很麻烦也不可能有人做到我满意的地步，现在完全借助AI的能力，帮我达成了这个目标。可以说，感谢现在AI生产力大爆发的时代，没有它们，我估计我理想中能达到我功能要求的插件，还得好多年后才会等别人做出来。 先说我日常用这个网站的痛点： 1：界面老旧、非常典型的日式老土网页设计风格。规整是规整，但是毫无WEB3时代的先进设计理念。主打一个耐用但是不好用。 2：数据经常性不全，或者数据错误。我知道这个不算是他们的问题，是源头DMM自身的元数据问题，但是它们提供了订正功能给用户修正，可是修正的数据不显示，需要它们审核通过才行，但是他们官方又非常懒惰。于是我这个修改JAVDB元数据的需求就很大了。 3：收藏功能过于难用，他们的收藏功能就是收藏到清单里，可是每个清单只支持501个视频，超过了要另外创建新清单，并且他们不支持在清单里面搜索在这个清单里存在的演员，或者我在把某演员的那些作品进行了收藏，这体验非常的蛋疼，他们的收藏基本就变成了一种标记功能罢了。所以这个脚本最核心的功能除了界面重构外就是把你账号里面的数据抓取到本地来，进行本地的存储和各种个性化的管理，并且出了数据库成本只有几M外，其它的成本全部调用云端的，比如图片视频，这样做的结果就是维护超级方便，迁移性高，并且可以跟官方的随时同步。还能形成一个伪本地收藏的EMBY高仿媒体库，只是区别是视频不是你本地的，是在云端的。现在的时代网络很发达，基本上没有特殊需求的人来说那些在线网站已经足够看了。所以这个脚本不针对本地视频进行管理，它的一切都是依托于这个网站伪本地化变成媒体库的。并且力求在体验上超越EMBY的界面和管理设计之类的。但是总的前端样式还是基于EMBY成型的。 最核心的痛点就是这三样，别的小毛病问题我就不列举了不同人各有各的痒处，但是我的脚本里面都完全针对它们进行了增强，这个项目在我的github页面上我已经对它写了更详细的readme，功能不止上面那么点，这个README一半AI写的一半我写的。我是没想到一个项目完成之后写README是真的很累人，为了美观简洁且信息量丰富，我硬是搞了三四个小时。 再说我开发这个脚本的初衷： 核心目的肯定是为了解决上面说的增强这个网站使用的痛点，但是这个还是没提到本质问题。 我曾经是一个仓鼠党，收藏下载了非常大量的各种类型影片，NAS，还有云端各种免费大容量网盘羊毛等等都薅过了，有几年玩刮削整理自己观影数据库天天废寝忘食乐此不疲的。最终看到EMBY读取整理好的数据把那个海报墙形成的时候，成就感真的很满足。 直到有一天，我的云端账号没了，我放在上面十几个P的心血，全都付之一炬的时候，那时候我就心死了，彻底戒了当一个仓鼠党。我就开始想，我这么费尽心思的下那么多影片资源到底是为了什么，答案不是为了给互联网备份数据做贡献，而是喜欢那个生动的海报墙，喜欢自己的收藏数据被可视化出现的时候，那么本质上，我收藏的不是影片，而是一个个的元数据组成数据库和海报墙。找到核心问题后，我就才意识到，如果我自己的观影数据能做成一个类似于EMBY媒体库这样美观的前端展示，那么再匹配上现在网络上海量的各种在线播放站点，也就意味着我根本不需要费力下载所谓的高清电影去折腾自己那可怜的存储了。当然这个核心前提是你不是一个非看高清资源不可的人。要满足高清党还是得自己亲自下载来才可以。所以当理清楚我自己的需求后，我就盯上了这个老司机们都爱逛的日式影片数据站，为它定制了一个变成EMBY皮肤再加个性化数据管理工具的一个脚本。 我自认为目前所有针对这个网站开发的脚本都没有我的这个美观精致好用没有我的这个强大。所以我前几天想发到这个论坛做一次推广让大家都用起来，我按照要求添加了推广模板，加了标签，readme写了linuxdo，都不给我通过，管理员也不解释这帖子为什么就是不给通过。所以这次我重新发帖，原帖的内容和这个帖子的内容其实基本没什么区别，只是一个贴了GITHUB的项目链接，这个没贴。我也不打算贴了，我相信有心之人自然会找到我这个脚本的，我声明我这次发帖没有任何推广要素，我自己的项目完全开源没有群组没有收费内容，如果还要删帖，管理员请你说清楚理由！！ 下面是我开发这个脚本的一些历程，以及开发心得，发出来是想在论坛上有人交流想法。有点啰嗦，不感兴趣的可以不往下看了。 终于可以发布这个脚本了，本来两天前就开发完毕的，但是最后进行健壮性审查对抗验证的最终阶段时候发现留下来的漏洞问题并不少于是前前后后又花了两天调试，进行验证之前的脚本就像是一个只能跑在特定条件路况下的车，跑别的路就会散架似的。而最后两天时间调优完毕后，算是一个合格可以出场的车了，所以大家现在上车吧。 这次开发交付的虽然只是一个1M左右的文件，但是在油猴脚本来说算是中等体量而且也挺复杂的，对于一个不会写代码的人来说，它不算是一个小项目，整个脚本要自成一环，各种模块互相搭配，依赖要互相牵制，功能要互相影响。开发出一个多功能脚本的过程，真的是完全进行了一次当产品经理从调研到立项到开发到调优的全环节。对一个人学习规范性开发是很有用的，整个环节一个人亲自走通，也就理解了现在AI编程强大是强大，但是强到什么程度，看的还是用的那个人这句话。也懂了项目管理能力和开发能力同样重要的理念。 这个不是我第一个vibecoding的项目了，但是是我最花时间的一个。我没想到这个脚本最终形成是那么复杂的，不过还好开发之前做了很多准备工作，写的计划书结构都比较清晰，整个项目从第一次对话给的文件开始到最终版，一直都没有偏离框架的，我觉得是这个项目成型后我认为质量还算比较高且维护性好的一个原因。 总之，开发功能一时爽，对抗验证火葬场。最后收尾的两天比开发时期还累人，修的BUG最多，但是也让我得到了很多心得。 这个项目最开始是用work Buddy白嫖的HY3还有Hermes的HY3交替着开发的，整个项目的基础架构，功能框架。皮肤原型都是HY3完成的，初期只有前端重构和收藏清单抓取数据这些核心功能的时候，完成度其实真的很高，并没有大家觉得的流口水那么差，当然用起来BUG肯定是有的，以至于我在用HY3时期最花时间的就是跟它磨细节，最尤其是前端页面上的细节，真的磨合得我一度想放弃。当然不是说写得没法看，这个脚本的EMBY经典皮肤和毛玻璃皮肤其实就是HY3完成的，两遍就过了，但是涉及到复杂的液态玻璃，就下瞎眼了细节问题很抓狂，一百多轮对话里面至少三十轮是跟它聊这个，然后受不了了开始用DSV4开发，但是4.1之前的V4真的能力一般，前端能力也跟HY3半斤八两的，所以这个阶段我是让DSV4F打磨技术细节，修补BUG，准备寻一个前端写得好的来接手后面的开发。KIMI前端写得好，但是我让它开始准备接手的时候，第一轮就给我去掉五百积分，还没开始正式干活呢，用不起。跑了。 正一筹莫展之际Gemini带着它的3.8Flash来了，都说Gemini前端写得还可以，死马当活马医吧，刚巧它的token也给的大方，然后我就让Gemini接手了后续的开发直到项目收尾DS4.1F发布。 确实Gemini实际表现比多数人说的口碑强太多了，速度快不说，干起活来指哪打哪的，省掉了我很多时间，加速了我后面不少内容的开发，后面看到几个脚本做的功能很好用，我还让它对插件功能进行过一次重构，都是非常轻松完成了。 不过它的问题也不小，但是我觉得问题是多数模型的通病，比如幻觉问题，它的幻觉不是瞎编乱造那种，是看了一两句话就爱以偏概全的这类，经常需要纠正。还好反重力对它的约束做得很好，每次比较大的修改，都会强制出计划，让我确认审批再执行，这种对齐了沟通的，执行能力就好很多。 还有就是爱过度思考，它思考是很快的，你能感觉到它过度思考的地方是喜欢给你做决定觉得你需要这个，然后把功能写进去，但是写完又是官杀不管埋的，后面增加的什么东西需要依赖上这个功能，它不会主动把他们串联在一起，我的理解是它的幻觉导致了一些记忆丢失问题。所以反重力强制要求计划多的都写计划书对齐确认了再开发，本质上是补救措施。只是它这个幻觉并不是坏事，因为总体能力是提升的，这个后面会说到。 一个很有意思的点是，可能因为训练语料的原因，现在的这些大模型，其实都不能真正做好液态玻璃原生的那种效果。它们都是在毛玻璃上面根据自己的理解微调的，最后的观感，其实是比毛玻璃设计还好的毛玻璃。所以我这个脚本，里面的毛玻璃皮肤，其实是最先让hy3模型设计的液态玻璃皮肤。我看了这个效果直接拍板让改名为毛玻璃。而真正的液态玻璃我是找到一个真液态玻璃实现的仓库给Gemini研究学习的，Gemini还为此专门写了很多公式研究。在计划书里告诉我这些公式负责了什么，才把这个效果做对的，但是也调整了十几轮。 后来赶上DEEPSEEK发布V4.1Flash，我用在别的项目上了，能确实感觉到能力的提升，但是我不想现在冒着风险换模型，继续让Gemini开发，反正功能也接近尾声，但是有意思的就开始了。下面鲸鱼就是D，哈吉米就是G。 前几天学习到让模型之间互相对抗赛马可以提升交付质量的思路，我就把脚本扔给了DS测试它对一个全新的没有接手指南的文件，理解怎么