独立站开发需求如何找到自身的痛点？
我们之前找网站开发需求，基本都是从数据分析出发，或者从关键词调研出发。其实我觉得还有一种比较实用的方法，就是从自身碰到的需求点出发，直接将解决方案产品化。
比如谷歌SEO培训前两天文章里分享的，身边小伙伴开发的那个亚马逊联盟链接导出的插件，便是基于自身需求的考量，直接使用技术解决痛点。
基本上这个痛点，假如我在实际工作中碰到了，那肯定会有其他人也在工作中碰到过。且一旦用户基数足够，那就完全值得花精力将痛点的解决方案产品化出来。
这样的现成案例真的太多了，大家要是有兴趣的话不妨自己搜索了解一下。
这里拿一个我最近经历的痛点举例。
我们在做小语种网站的时候，基本的逻辑便是先将英文站点做出来，然后再在英文版本网站的基础上进行对应小语种的翻译。
假如是使用WordPress建站，目前比较流行的技术方案，便是用小语种翻译插件，然后采用子目录的方式去做。
而目前这块比较流行的插件，便是TranslatePress的开发版或者商业版。其插件工作的基本逻辑，就是使用第三方的翻译API，将网页翻译成对应的小语种。
而我们在实际工作中，基本都会去购买DeepL API来做这块的翻译工作。
但是深度使用过你会发现，这款插件目前还不支持通过Token方式接入自定义的AI模型进行翻译。其官方提供的AI模型，使用起来又比较鸡肋。
说实话，DeepL基本能将文案信息翻译出来，但是碰到一些基于上下文理解的文案，其翻译的局限性还是蛮大的，甚至很多情况下还会瞎搞。
而要处理这些信息的翻译，AI肯定是我们的首选，尤其是最新版本的这些AI模型。
由此矛盾便出现了，我既要TranslatePress做小语种版本网站的便利，又要AI模型在文案翻译上的「信雅达」，而且还要实际工作中的翻译效率。
痛点出现，剩下要去做的便是去找相应的解决方案。
大家有兴趣的话，可以尝试在谷歌上搜索下这些需求的解决方案，你会发现目前只有一个意大利的博主，在油管上发布了他自己的解决方案。
其实他的分享的那个解决方案并不难，就是直接开发一款WP的插件，通过这款插件设置相应模型的Token。然后把这款插件当作AI模型与TranslatePress的桥梁，为其提供AI翻译能力。
并且他直接将这款插件做成一个产品包进行售卖，且提供相应的课程服务(包含站群之类的其他内容)。
所以在这里我想表达的是，要重视我们在实际工作中发现的那些让你难受的痛点。如果你能采用合理的方案将这些需求解决掉，那可能就是一个非常不错的产品机会。
