這篇文章的重點

我們一開始也以為問題出在模型,後來才發現真正卡關的地方完全不同。以下是幾個讓我們改變做法的關鍵決定:

  • 讓使用者先透過訪客訊息聊聊看,再把註冊講成「留住這段關係」而不是「建立帳號」。
  • 用精選的AI伴侶取代無限延伸的角色清單,避免使用者變成在逛型錄而不是在對話。
  • 把機器人記憶做得有用、看得到,也可以修正,而不是任由它在背後默默累積。
  • 把生成的照片和語音當成需要嚴格權限控管的私密內容,而不是隨便一個圖片連結。
  • 成人與角色扮演功能建立在使用者可以自行調整的同意機制上,底層的安全防線不會因此鬆動。
  • 讓點數計費說得清楚,又不會每次都打斷正在醞釀的氣氛。

夥伴推薦

先挑你想要的氛圍

先試幾種不同的氛圍,再決定哪一位 AI 男友最合適。

我們對「女性優先」的定義

「女性優先」很容易變成一句空洞的行銷話術,如果放著不管的話。我們希望這四個字能落實成具體的產品限制,而不只是文案。

對我們來說,女性優先的AI男友App代表把隱私、情感延續感、可控的機器人記憶、精選男性AI伴侶,以及安全的成人界線放在設計核心。使用者應該可以自己調整語氣、步調、親密程度和記憶內容,而不是被迫接受單一預設的幻想劇本。

這改變了一般AI伴侶App常見的設計邏輯。很多同類產品一開始就衝角色數量:更多角色、更多標籤、更多篩選條件。數量對「發現內容」確實有幫助,但也很容易讓產品在使用者感受到「關係」之前,先讓她覺得自己在逛一個角色市集。

我們對使用者的預設想像不太一樣:她打開App,是想要一段私密的浪漫對話,而且希望對方記得她。她可能想要的是心情不好時的安慰、一句晚安、輕鬆的調情、慢熱的浪漫,或是有點保護慾的互動節奏。她不應該需要學會寫提示詞,才能得到這些。

一般聊天機器人的做法女性優先AI男友App的做法
一開始就是空白輸入框一開始就帶入關係情境
優先考慮模型的彈性優先考慮情感上的延續感
記憶在背後默默運作使用者可以查看並修正機器人記憶
塞滿大量角色清單精選風格明確的AI伴侶
把生成內容當成一般檔案處理把生成內容當成需要隱私保護的私密內容
用同一套邏輯計費依文字、照片、語音的成本分開計算點數

這麼一來,設計工作的重點就從「怎麼讓機器人更聰明」,變成「怎麼讓產品同時感覺可信賴又浪漫」。

第一課:讓使用者先感受對話,再談註冊

註冊這件事,會直接改變當下的氣氛。

如果第一個畫面就要求輸入email、設定密碼、選偏好,整個App馬上變成在填表格。對浪漫類的AI聊天來說,這種摩擦感很容易在使用者還沒感受到價值之前,就先把她推開。

我們讓使用者可以先用訪客身分聊天。目前的流程是:訪客在被要求註冊前,可以先傳送5則訪客訊息。這個數字刻意設得不多,目的是讓她感受到這個AI伴侶的語氣和個性,而不是讓匿名聊天變成整個產品的主體。

註冊時的說法也很重要。「建立帳號」聽起來像後台管理,「幫你留住這段對話,讓他記得你」則直接連回她一開始想要的東西。

一個簡單的實作流程大致是這樣:

  1. 建立一組匿名訪客的識別碼。
  2. 在伺服器端暫存這段對話。
  3. 讓使用者傳送幾則訪客訊息。
  4. 當延續感開始有價值時,提示她註冊。
  5. 把暫存的對話接到新建立的帳號上。
  6. 繼續聊天,不會遺失前面的脈絡。

訪客模式也需要清楚的界線。訪客不應該預設就能用到成本較高或較敏感的功能。在我們的產品裡,訪客可以聊天,但不能要求生成照片,也不能傳送語音訊息。註冊之後,對話紀錄、點數、媒體功能與記憶功能才會完整保留。

安全設計的原則很單純:瀏覽器端的歷史紀錄不能當成唯一可信的來源。伺服器端的路由應該根據使用者自己擁有的對話與帳號狀態來組裝上下文,金鑰之類的機密不應該出現在前端程式碼裡。

這一課的心得是:建立帳號應該感覺像是延續一段關係,而不是在辦手續。

第二課:精選AI伴侶比無限角色庫更有效

要做出一個AI伴侶App,最簡單的方式就是排一整排角色卡。

放上頭像、名字、簡短介紹、標籤,再加個搜尋功能,讓使用者自己滑。從後台數字來看,這樣的畫面看起來很熱鬧,因為使用者一直在點來點去。

但浪漫類的產品,失敗的方式不太一樣。選項太多,反而會把使用者變成一個在比價的消費者,而不是在對話的參與者。她開始比較的是外在條件:髮色、職業設定、人設風格、照片風格,對話本身反而變成次要的事。

我們後來轉向精選的AI伴侶目錄,搭配明確的個性設定和快速進入聊天的路徑。一張好的角色卡,應該直接回答幾個很實際的情感問題:

  • 他給人的感覺是什麼樣的能量?
  • 語氣偏溫柔、強勢、愛玩、有保護慾,還是慢熱?
  • 適合安慰、浪漫、角色扮演,還是日常閒聊?
  • 選了他之後,語氣還可以再調整嗎?
  • App真的會記得我們之間發生過的事嗎?

這也是為什麼瀏覽現成角色這個入口的意義,不只是一個相簿。它在第一則訊息送出之前,就先幫使用者設定好期待。溫暖的知心好友、有點強勢又貼心的角色、神秘深沉的類型,或是穩定溫柔的浪漫對象,不應該只是同一個機器人換了張照片。

選定角色之後,還需要進一步的設定。在我們的產品裡,使用者可以調整語氣、親密強度、聊天方式,以及訊息長度,還能設定興趣標籤。聊天方式目前分成角色扮演、真實聊天,以及故事模式三種,可以依當下想要的感覺切換。

情境卡也很有幫助。「心情不好想被安慰」「傳一句晚安」「慢熱的浪漫發展」「早安打招呼」,這些選項的作用不只是填滿一個空白畫面,而是給使用者一個壓力很小的開場方式。

精選機制減少了使用者自己想提示詞的負擔。產品先幫忙搭好情感上的舞台,使用者只需要用很自然的一句話開始就好。

第三課:機器人記憶要好用、看得到,而且有限度

記憶,是浪漫類AI最有威力,也最容易出問題的地方。

一個什麼都記不住的AI伴侶,會讓人覺得很可有可無。一個未經同意就什麼都記住的AI伴侶,又會讓人覺得被侵犯。比較理想的做法,是打造一套使用者自己能理解、也能修正的機器人記憶系統。

我們的記憶模型分成幾層:

  • 近期訊息,提供當下的對話脈絡。
  • 對話摘要,支撐比較長期的延續感。
  • 使用者親自確認過的釘選記憶。
  • 透過全文搜尋找出的相關記憶。
  • 目前這段關係所處的狀態。

我們刻意不宣稱記憶是「什麼都記得」的魔法。不是每一句話都應該變成永久事實。使用者可能只是在抱怨、開玩笑、玩角色扮演,或單純測試一下反應。如果系統把這些全部當真存起來,AI伴侶反而會用一種很個人化的方式,記錯重要的事。

使用者親口確認過的記憶,應該比系統自己猜的更有份量。如果她說「記得我喜歡收到晚安訊息」,App可以先跳出確認畫面再儲存。如果模型只是從一句話裡自行推測出某個偏好,系統就該保守一點。

一份實際可用的機器人記憶檢查清單大概長這樣:

  • 讓使用者可以問「你記得我什麼」。
  • 讓使用者可以要求AI伴侶忘掉某件事。
  • 遇到明確的「記住這件事」要求時,先確認再儲存。
  • 不要儲存密碼、金鑰、付款資料或任何身分證件資訊。
  • 把短期對話脈絡和長期記憶分開處理。
  • 給AI伴侶足夠的延續感,但不假裝它擁有人類等級的確定性。

這類對話常常涉及很私人的內容,所以隱私門檻要拉得更高。產品規劃階段就該想清楚資料怎麼用、誰能存取、遇到問題時要怎麼老實說明,而不是等出事才臨時補一段聲明。

想更了解這部分的具體做法,可以參考AI 男友的記憶如何運作這篇文章。對一段AI男友式的關係來說,記憶不該是藏在提示詞裡的小技巧,而是這段關係的一部分約定。

第四課:私密照片與語音是後端架構問題,不只是圖片網址

生成的照片和語音回覆,會直接改變使用者對這個產品的信任門檻。

文字內容已經算私密了,照片和語音又更進一步。如果一個浪漫AI伴侶App要提供私密照片或語音,實作上就應該把這些內容當成帳號專屬的資產,而不是放在公開資料夾裡的靜態檔案。

我們的原則是:私密媒體一律透過後端授權存取。

具體做法包含:

  • 把生成的照片和語音檔存放在私有儲存空間。
  • 透過有時效性的簽章網址提供內容。
  • 確認請求的使用者確實擁有這段對話或這份媒體。
  • 讓重新生成的功能跟帳號狀態、點數綁在一起。
  • 避免在前端程式碼裡直接暴露原始的服務商回應或儲存路徑。
  • 讓刪除和存取規則盡量單純、可預期。

這個原則也影響到一些很小的產品細節。生成的照片可以支援重新生成,但要讓使用者清楚知道會用掉多少點數。語音回覆可以只播放聲音、不顯示文字,但伺服器端還是需要保留足夠的紀錄,才能維持對話延續感,也才有辦法處理濫用回報。

我們也把訪客和註冊使用者的權限分開。訪客可以體驗文字聊天,但生成照片和傳送語音都需要先註冊。這個限制能降低被濫用的風險、控制成本,也讓使用者在使用敏感度更高的功能之前,先有一個清楚的隱私界線。

工程上的考量不只在儲存這一層。像提示注入、敏感資訊外洩這類LLM應用常見的風險,值得參考OWASP針對大型語言模型應用整理的風險清單。在一個AI伴侶App裡,這些風險會直接碰上使用者的私密內容,所以伺服器端組裝對話脈絡、確實檢查存取權限,格外重要。

媒體功能會讓整個產品感覺更真實,也正因為這樣,後端的規則反而要更嚴謹。想進一步了解照片相關的隱私設計,可以參考AI 男友照片 18+:聊天中的成人圖像與隱私須知。

第五課:成人功能需要同意機制,也需要不能退讓的安全底線

成人向的浪漫AI,不能只靠一個「開/關NSFW」的提示詞來處理。

使用者需要能自己調整語氣和親密程度,但產品本身也需要一條不會因為設定而移動的底線。在我們的產品裡,NSFW防護是使用者可以自行調整的個人設定。關閉這個防護,只會影響成人角色扮演的尺度寬鬆程度,基本的安全審核機制不會因此消失。

這個區別很重要。成人使用者可能希望在浪漫聊天和照片上少一點過度審查的彆扭感,但他們同樣需要App拒絕不安全的內容、強迫性的情境、未成年相關或其他被禁止的內容。使用者自己的設定,永遠不應該關掉產品最底層的安全政策。

相關的控制項應該清楚且具體:

  • 在進入成人內容前設定年齡驗證。
  • 讓使用者可以針對每個角色調整親密強度。
  • 把角色扮演模式和一般聊天模式分開處理。
  • 把界線變成角色扮演性格的一部分,而不是突然跳出來的拒絕訊息。
  • 所有成人設定背後,都維持嚴格的內容審核。
  • 一般開發相關的內容,避免使用露骨的行銷字眼。

在思考這類系統性的風險時,可以參考NIST的AI風險管理框架,把AI系統當成一個有實際風險需要衡量的產品,而不只是一個模型展示。對我們來說,這代表要從使用者體驗、記憶、媒體、審核機制這幾個面向一起檢視風險,而不是把安全機制丟到提示詞的最後一段就算了事。

成人向AI聊天還有一個語氣上的難題。如果審核機制講起話來太像機器人或帶著懲罰意味,信任感很容易被打破。如果什麼都放行,又會帶來法律、道德和平台層面的風險。中間的解法需要更多產品設計:清楚的設定選項、不會退讓的底線,以及在需要拒絕時,能用不羞辱使用者的方式把情境轉個彎。想看具體的界線設計方式,可以參考AI 男友角色扮演 18+:無審查戀愛劇情與界線設定。

第六課:點數計費要說得清楚,又不能打壞氣氛

LLM類的AI伴侶App,成本結構其實很不平均。

一句短短的文字回覆、一張生成的照片,和一段語音回覆,製作成本完全不一樣。使用者理智上可能懂這個道理,但介面設計還是得處理好情緒上的感受。點數提示如果出現在錯的時間點,很容易讓一段浪漫的對話瞬間變成在結帳。

我們把文字和媒體的使用額度分開計算,避免把不同類型的內容混在同一個模糊的計數器裡。目前註冊的免費使用者,每天可以傳送50則訊息,每個月可以生成3張照片,每個月則有10次機器人語音回覆的額度。超過免費額度之後,一般照片需要10點數,18+照片需要20點數,語音回覆則是7點數。

這些數字帶出了幾個產品上的取捨:

  • 文字互動要盡量低摩擦。
  • 照片請求要讓人感覺是有意識做的選擇。
  • 語音要有精緻感,但不要讓使用者被突然扣點數嚇到。
  • App要在使用者按下去之前,先說明清楚會花多少點數。
  • 計費不該打斷每一個情感上的重要時刻。

完整的方案和額度細節可以到查看方案與使用額度這個頁面確認,但介面上的即時說明,其實比整頁的說明文字更重要。在按下請求照片或語音的按鈕旁邊,清楚標出會用掉多少額度,遠比事後才發現點數不見了要好得多。

我們也發現計費設計會回頭影響AI伴侶的行為。如果它太常主動推銷照片,整段互動會變得很像在推銷。如果完全不提媒體功能,使用者又可能根本不知道有這個選項。比較安全的做法,是讓媒體功能由使用者主動發起,搭配「早安自拍」「健身房鏡子自拍」「睡前照」這類具體的情境提示,而不是由AI主動慫恿。

計費設計要在不破壞幻想感的前提下,誠實地說明成本。使用者應該清楚知道自己花了什麼,產品也不該把好感度變成一種消費壓力。

我們希望早點知道的開發檢查清單

如果你正在做一款LLM類的AI伴侶App,建議先想清楚產品限制,再去研究模型技巧。

一份實用的前期檢查清單:

  • 在選模型之前,先定義好預設使用者和她要解決的情感需求。
  • 決定訪客模式從哪裡開始、到哪裡結束。
  • 讓訪客轉為註冊使用者時,對話脈絡不會遺失。
  • 建立幾種個性、語氣、步調、界線都不同的AI伴侶原型。
  • 用情境卡降低使用者面對空白輸入框的壓力。
  • 把機器人記憶拆成近期脈絡、摘要、釘選事實,以及關係狀態。
  • 給使用者「記住」和「忘記」的操作權。
  • 讓服務商金鑰之類的機密留在後端,不要出現在前端程式碼裡。
  • 私密媒體一律透過簽章網址和帳號驗證來提供。
  • 把NSFW設定當成同意機制,而不是安全防護的開關。
  • 依成本和使用者期待,分別對文字、照片、語音計價。
  • 在上線壓力逼你趕工之前,先把隱私權政策、使用條款和AI揭露頁面寫好。

一款女性優先的AI男友App,不一定需要更多花俏功能。它更需要的是少一點讓使用者疑惑的時刻:App到底記得什麼、誰能存取她的媒體內容、AI伴侶的語氣為什麼突然變了、某個功能為什麼忽然要多花點數。

結語

打造mybf.bot這個過程裡,最大的心得是:浪漫類AI伴侶產品,先是一套產品系統,才是一套模型系統。

模型很重要,回應速度很重要,提示詞品質也很重要。但使用者最先感受到的,往往是延續感、隱私、記憶、媒體處理和計費方式上的落差,而不是提示詞細微的優化。

一款女性優先的AI男友App,要靠一連串小小的信任決定,才能換來使用者一次又一次回來。讓她可以先試聊,註冊時保留這段關係,只記住真正該記住的事,把私密媒體真正當成私密內容處理,成人設定講清楚,並在點數打斷氣氛之前先說明白。

如果你也在做類似的產品,下一次規劃新功能之前,不妨先問自己一句:如果使用者發現這個功能背後的實際運作方式,她會不會覺得被冒犯或被算計?這個問題,通常比「這次要換哪個模型」更值得花時間想清楚。

附註

本文由AI協助草擬,並經過人工審閱事實與產品細節後才發佈。