我們之前找網(wǎng)站開發(fā)需求，基本都是從數(shù)據(jù)分析出發(fā)，或者從關(guān)鍵詞調(diào)研出發(fā)。其實我覺得還有一種比較實用的方法，就是從自身碰到的需求點出發(fā)，直接將解決方案產(chǎn)品化。

比如前兩天文章里分享的，身邊小伙伴開發(fā)的那個亞馬遜聯(lián)盟鏈接導(dǎo)出的插件，便是基于自身需求的考量，直接使用技術(shù)解決痛點。

基本上這個痛點，假如我在實際工作中碰到了，那肯定會有其他人也在工作中碰到過。且一旦用戶基數(shù)足夠，那就完全值得花精力將痛點的解決方案產(chǎn)品化出來。

這樣的現(xiàn)成案例真的太多了，大家要是有興趣的話不妨自己搜索了解一下。

這里拿一個我最近經(jīng)歷的痛點舉例。

我們在做小語種網(wǎng)站的時候，基本的邏輯便是先將英文站點做出來，然后再在英文版本網(wǎng)站的基礎(chǔ)上進行對應(yīng)小語種的翻譯。

假如是使用 WordPress 建站，目前比較流行的技術(shù)方案，便是用小語種翻譯插件，然后采用子目錄的方式去做。

而目前這塊比較流行的插件，便是 TranslatePress 的開發(fā)版或者商業(yè)版。其插件工作的基本邏輯，就是使用第三方的翻譯 API，將網(wǎng)頁翻譯成對應(yīng)的小語種。

而我們在實際工作中，基本都會去購買 DeepL API 來做這塊的翻譯工作。

但是深度使用過你會發(fā)現(xiàn)，這款插件目前還不支持通過 Token 方式接入自定義的 AI 模型進行翻譯。其官方提供的 AI 模型，使用起來又比較雞肋。

說實話，DeepL 基本能將文案信息翻譯出來，但是碰到一些基于上下文理解的文案，其翻譯的局限性還是蠻大的，甚至很多情況下還會瞎搞。

而要處理這些信息的翻譯，AI 肯定是我們的首選，尤其是最新版本的這些 AI 模型。

由此矛盾便出現(xiàn)了，我既要 TranslatePress 做小語種版本網(wǎng)站的便利，又要 AI 模型在文案翻譯上的「信雅達」，而且還要實際工作中的翻譯效率。

痛點出現(xiàn)，剩下要去做的便是去找相應(yīng)的解決方案。

大家有興趣的話，可以嘗試在谷歌上搜索下這些需求的解決方案，你會發(fā)現(xiàn)目前只有一個意大利的博主，在油管上發(fā)布了他自己的解決方案。

其實他的分享的那個解決方案并不難，就是直接開發(fā)一款 WP 的插件，通過這款插件設(shè)置相應(yīng)模型的 Token。然后把這款插件當(dāng)作 AI 模型與 TranslatePress 的橋梁，為其提供 AI 翻譯能力。

并且他直接將這款插件做成一個產(chǎn)品包進行售賣，且提供相應(yīng)的課程服務(wù)（包含站群之類的其他內(nèi)容）。

所以在這里我想表達的是，要重視我們在實際工作中發(fā)現(xiàn)的那些讓你難受的痛點。如果你能采用合理的方案將這些需求解決掉，那可能就是一個非常不錯的產(chǎn)品機會。