从自身痛点找需求

我们之前找网站开发需求，基本都是从数据分析出发，或者从关键词调研出发。其实我觉得还有一种比较实用的方法，就是从自身碰到的需求点出发，直接将解决方案产品化。

比如前两天文章里分享的，身边小伙伴开发的那个亚马逊联盟链接导出的插件，便是基于自身需求的考量，直接使用技术解决痛点。

基本上这个痛点，假如我在实际工作中碰到了，那肯定会有其他人也在工作中碰到过。且一旦用户基数足够，那就完全值得花精力将痛点的解决方案产品化出来。

这样的现成案例真的太多了，大家要是有兴趣的话不妨自己搜索了解一下。

这里拿一个我最近经历的痛点举例。

我们在做小语种网站的时候，基本的逻辑便是先将英文站点做出来，然后再在英文版本网站的基础上进行对应小语种的翻译。

假如是使用 WordPress 建站，目前比较流行的技术方案，便是用小语种翻译插件，然后采用子目录的方式去做。

而目前这块比较流行的插件，便是 TranslatePress 的开发版或者商业版。其插件工作的基本逻辑，就是使用第三方的翻译 API，将网页翻译成对应的小语种。

而我们在实际工作中，基本都会去购买 DeepL API 来做这块的翻译工作。

但是深度使用过你会发现，这款插件目前还不支持通过 Token 方式接入自定义的 AI 模型进行翻译。其官方提供的 AI 模型，使用起来又比较鸡肋。

说实话，DeepL 基本能将文案信息翻译出来，但是碰到一些基于上下文理解的文案，其翻译的局限性还是蛮大的，甚至很多情况下还会瞎搞。

而要处理这些信息的翻译，AI 肯定是我们的首选，尤其是最新版本的这些 AI 模型。

由此矛盾便出现了，我既要 TranslatePress 做小语种版本网站的便利，又要 AI 模型在文案翻译上的「信雅达」，而且还要实际工作中的翻译效率。

痛点出现，剩下要去做的便是去找相应的解决方案。

大家有兴趣的话，可以尝试在谷歌上搜索下这些需求的解决方案，你会发现目前只有一个意大利的博主，在油管上发布了他自己的解决方案。

其实他的分享的那个解决方案并不难，就是直接开发一款 WP 的插件，通过这款插件设置相应模型的 Token。然后把这款插件当作 AI 模型与 TranslatePress 的桥梁，为其提供 AI 翻译能力。

并且他直接将这款插件做成一个产品包进行售卖，且提供相应的课程服务（包含站群之类的其他内容）。

所以在这里我想表达的是，要重视我们在实际工作中发现的那些让你难受的痛点。如果你能采用合理的方案将这些需求解决掉，那可能就是一个非常不错的产品机会。