最近，我花了一个月时间，针对一个老司机们经常上的知名日式影片数据站点进行开发的前端优化脚本这是一个专门针对这个网站的前端界面重构脚本项目，是根据我这些年使用这个网站的日常痛点开发的，好几年前我就有想法了，我当时甚至想花钱找人给我定制一份。但是觉得沟通很麻烦也不可能有人做到我满意的地步，现在完全借助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测试它对一个全新的没有接手指南的文件，理解怎么样，然后我发现它的理解能力确实非常优秀，并且感觉不到幻觉问题。读完代码之后，我要求它对这个代码进行审计给出BUG或者缺陷报告，同时我也让Gemini自己也跑了一版，结果两边的文档一对比，我傻眼了，D这边快给下病危通知书了，G这边说小感冒，吃一片药就好，别过度医疗。。。。。
所以这时候更要好好确定清楚这两边到底谁是水货，因为我看不懂代码啊，而且此时我这脚本认为运行的时候真查不出什么错误来了。接着换个思路，我不让D写代码，专门让G来写来修，做好一版我就给D让它对比然后告诉我修了哪里，继续出局报告。报告给G的时候告诉他这个报告不能全听全信，这个不是计划书是给你参考的，看看你自己有没有什么遗漏的或者没想到的，这个报告给你想到了。针对性完成之后再给我出一个报告我再给D。就这样来回，我是中间传话的，D是审核的G是干活的。这样七八论之后，这两个模型的性格特质就对比得非常明显，
G非常聪明，思路是很活跃的，写代码并不死板。D比G严谨很多，但是过于严谨的问题就是导致很多东西还有设计上它会做的比较死板。经常让两边互相对计划书的时候，它会夸G方案优雅，实现巧妙。
G真的很爱用形容词，什么神来之笔，真知灼见，质量极高、非常硬核且充满实证精神，G确实在测试这里经常干傻逼事，不难怪D跟他对方案的时候语气非常严肃非常不客气。你能读出一种“你把他叫过来我要当场和它切磋对峙”的感觉，确实很有老学究对战00后大学生的既视感。
这种体感就是一个严肃认真的老师面对一个聪明但是注意力不集中的学生，G很需要D的敲打和约束。
比如他回给D的报告，开篇就写认真研读了贵方出具的《对修复观点的回应》，贵方展现出了令人敬佩的专业素养、严谨态度与客观胸怀。还客观胸怀，D老师都想要贴脸扇他了。
最直观最让你无语的一点就是，当G给你完成一次修改后，你不满意，你跟他说了参考方案，或者告诉他怎么弄，它如果采纳后，它给你的回复让我想起了“这是我从业二十年来见过的最伟大的操盘”这种既视感，然后框框干活，所以你们脑补这种感觉吧。
D的严谨或者说是低幻觉可以让它的注意力高度集中，推理能力更强，这个你是能确实感觉到G的推理能力差了一档的感觉的。比如一个恢复的设计思路，用户的打星数据如果本地记录打了 5 星，导入的备份相关记录是3星，用哪个？
G认为的是恢复功能设计的就是用户主动点导入意图就是用这个文件覆盖。可是D就能想到因为备份文件可能是几个月前的历史快照，不能因为合入旧备份就把用户昨天的最新打分给覆盖冲掉；而如果是用户刻意要恢复历史，会使用恢复里面就涉及过的全量覆盖（因为HY3很早就为脚本构筑了覆盖恢复和清空恢复的逻辑），同样都是看代码，D就能多看一步不认为某些代码是摆设，而G是认为功能跑顺了就行先把作业交了。
总之是在确定性测试这种类别的场景，D真的是在碾压G。但是在功能设计上，尤其是跟前端高度相关的功能设计G完全可以不听D的建议，他们互相出报告的时候，我就专门看了G说的，通篇意思是D就是老古董，是那种没用过现代化浏览器和设备的老登，时代早变了，性能的账的算法早就换思路了。有一说一，我核对了之后发现它确实说得有道理的，我还让它把反驳的这部分内容专门出个报告再丢给D探讨了以下，D也承认了是自己过渡担忧。
所以G在自己擅长的这里真的很自行自己的手笔，除非你强制要求它约束它。D在这次我使用的体验下来，我觉得它真的适合用来当规划模型，G当执行模型，这样搭档确实很棒，侧面看也说明他们生成DSV4.1F完全有了4.0pro水平是有道理的。
这次做这个项目我还掌握到两个小技巧，修BUG如果它老是修不好，你就跟它好好聊，对它做思路引导，但是最后一定要加上一句话，叫“请你从第一性原理的角度出发，捋清楚刚才的问题症结为我修复它”这句话真的有魔法，就像一个按钮重置了它的混乱大脑，就像是让它从打地基开始审视建筑的结构一样，这样基本上给出的方案会好很多。好好说话总比骂人管用，这个在AI这里也是对的。
然后是项目收尾了，很多问题我们自己用不到特定问题是测不出来的，除非你真的经验丰富。但是AI比你懂得多，你要告诉他去对这个项目做对抗性检查，这个就是专门用来拆台的，它真的怎么能查到一些设计上的逻辑错误问题。
还有就是对于前端问题，不好解决的就多让它接管浏览器，很多问题你要么描述不对要么不仔细要么你不太懂那些专业名词，那么开发这方面就打折扣了，这里你就可以直接要求它接管你的浏览器，给你做开发调试。反重力的浏览器调试很好用，腾讯出品的browseskills也很好用，当然了还有真神codex。用哪个丰俭由人。
最后就是要求模型交货前写脚本要多做测试，很多问题在庞大的文件脚本中，AI肯定只能给你审查局部，相关代码单看都是正确无误的，但是一上下组合起来就错了，尤其是遇到重构的时候，任何重构都不能仅看静态语法检查，必须依靠动态沙箱执行来验证运行时引用完整性。 该死的Gemini就给我犯过三四次修BUG把脚本注入页面都弄丢的低级错误。
jwdszye 09-22 01:591楼