打洞周报第6期
开始回顾上周进度。 
bilibili无限历史记录插件的进展
目前bilibili插件在chrome商店是1459个用户。RedArchive插件目前是393个用户。
上周打工比较忙，在赶需求，工作日晚上都没有搞副业的事，基本上回到住处就累得躺床上了。唯一没有躺的一天是在看readecho的mcp功能，看得我直摇头，这个我后面说一下。 双休日的话，周六是有事出去了一天，然后周日敲了一天代码。 昨天把插件的云同步功能做好了，然后插件也发布了1.7.0版本。
点击上传数据到云端可以通过网页端的接口将数据上传到supabase数据库。
点击查看云端数据就可以在网页端查看上传上去的数据了。
另外，还在popup中增加了一个可以勾选使用全量同步的功能。
还有就是修改了indexeddb中的一些字段，比如viewTime改成view_at。当初做的时候比较随意，有的是驼峰风格，有的是下划线风格。现在来看真想抽自己几个大嘴巴子。花了好一番功夫才把网页端、插件端、b站接口返回内容的字段全部统一，现在全部是按照b站接口的风格来，这样最方便，也不需要转换。
接下来，我会做支付功能。现在免费用户上传限制是500条数据。付费以后就能无限制上传。打算做月付和年付，不做买断制。
另外就是一些细节优化一下，比如显示已经保存在插件的历史记录的总条数，这样用户看到了以后就会说：哇，原来这个插件已经帮我保存了那么多历史记录啊，要是没有这个插件我这些宝贵的历史记录都得丢失（我戏精一下）。
可优化的点还有很多。可以给大家看一下用户提的建议。
目前我肯定是搞不过来的，打算先做我自己能用到的，比如收藏的保存和上传。
这周的话bilibili插件的开发有时间就搞，没时间就不搞，因为我还有其他的事。
shopify app开发进展
shopify app开发这块的话，我周日晚上也搞了一阵，但其实是没有那么顺利的。
我先是按照cursor的方案尝试了一下，发现行不通。cursor给我的方案是这样的： 
看起来很有道理是吧，跟stripe和微信支付的流程很像。所以我以为这是对的。但是我试了一下发现不行。没有webhook发送过来。然后我去看了一下官方文档上关于webhook的说明，发现shopify的webhook和支付好像没什么关系。别人用webhook都是用来监听一些商品、库存之类的事件。于是我开始怀疑了，还去两个shopify开发的相关群里问了一下，想把shopify app向卖家收取订阅费的流程搞清楚，还发了红包，但是几乎没有人回答我（真惨）。
后面我在google搜了一下“shopify app billing api”，找到了一个老外的youtube视频。看了以后我才终于恍然大悟，原来是不需要webhook的，也不需要额外的表来管理用户的订阅状态。
shopify本身就提供了billing api来查询和管理用户的订阅状态，比如这样的代码： 
这样就简单多了，每次打开pricing页面的时候，就先进行一次查询，如果用户处于某个订阅计划就让那个计划显示为绿色，否则就把free的计划显示为绿色（绿色表示已激活）
其实这个视频里这个老外也是看官方文档搞的。看来以后搞shopify app还是多看官方文档和老外视频吧，问群里的人是不用指望了。
这周打算按照新的方案把支付的流程跑通。
关于出海工具站
出海工具站这块，本来上周是打算把良辰美大佬的开源模板部署一下上线的（我公众号中发过），上周也没来得及搞了。这周看有没有时间吧，希望能把生图的核心功能搞定。
我看james老哥花了几天时间早早就搞定了，心里是有点急的。
无奈我现在身上的项目太多了。时间不够用，这真是个问题。
算了，索性慢慢来吧，也没什么其他办法。
readecho的mcp功能
我合伙人周三的时候给readecho搞了一个mcp客户端功能，花了一中午就搞定了。我表示很震惊，因为我目前还没看到哪个产品可以网页端调用mcp server，目前看到的能作为mcp客户端的只有cursor、claude desktop、cherry studio等工具，这绝对是遥遥领先了呀。然后我下班回来兴冲冲打开代码一看，得了，逻辑是写死的，并不是大模型只能分析的。测试了一下，效果很差。然后他表示很伤心，晚上睡不着了。
这周我打算搞一下这个网页端集成mcp客户端的功能，已经在研究了。
最近一周刷到的精华分享
用 Cursor 三天重做了 YOOART 免费AI生图网站
结语
其实我自己在处理shopify支付的时候还是会有害怕和拖延症。害怕困难和失败，老毛病了。后面我想起了小红书上的一篇帖子，用滑滑梯效应来克服拖延症。简单来说，就是先直接开始，然后做着做着就会慢慢进入状态了。真正直面困难的时候，就不会再那么害怕了。
希望我能慢慢把拖延症克服。
