動態

詳情 返回 返回

點我!1分錢獲取你的專屬表白網頁,浪漫由大模型代運營 - 動態 詳情

轉眼之間,MCP 技術已在人工智能領域炙手可熱,持續走紅超過半年,堪稱當下最受關注的“新晉頂流”技術。從最初的地圖類應用,到後來層出不窮的新聞類、工具類 MCP 智能體,各類場景的探索不斷拓寬,相關產品可謂比比皆是。不過,令人欣喜的是,近期終於成功推出了與支付相關的 MCP 工具,標誌着無論是個人開發者還是企業機構,都能夠更加高效地實現商業化落地與盈利模式的構建。最近也注意到又有一家新的智能體平台——螞蟻百寶箱

image

小雨在智能體階段也是風風火火地嘗試了不少平台,最近才無意間發現了「百寶箱智能體平台」。試用了一下,發現它支持的功能還真不少,挺驚喜的。

於是,我順手搭建了一個關於情侶互動的智能體。説到底,這靈感其實來自大學時期那次略顯“土味”的告白經歷:當時只是在私聊裏説了句“我喜歡你”,然後發了條朋友圈官宣“我倆在一起啦”——回想起來實在是平平無奇,完全沒用上自己作為程序員的一點技術優勢。

所以這次,我決定藉助百寶箱,快速搭建一個名為「與你」的智能體。寓意也很簡單——吃喝玩樂、點滴陪伴,所有的美好時光都“與你”有關。目的也很簡單,遊玩攻略+牽手技巧+網頁告白,尤其適合像我這樣在戀愛初期總是不知道如何表達感情的人。也算是為當初那個青澀又笨的自己,補上一課吧,哈哈哈。

好了,接下來就帶大家拆解一下我是如何一步步打造出這個「與你」智能體的。如果你迫不及待想看看它實際長什麼樣,可以直接跳到後面的【演示小章節】,先睹為快!

助手一覽

首先,我的這個智能體助手是基於對話型工作流來搭建的。主要原因是,這種方式在邏輯上更可控,適合處理一些我希望明確把控的交互節奏和輸出內容。大致的結構如下圖所示:

image

圖看不太清?彆着急,視頻裏我已經詳細講解啦,可以直接去看效果。

那我們先來看看這個助手都能幹什麼吧,目前主要包含以下幾項功能:

  • 🎮 提供遊玩攻略 + 貼心的 牽手/穿搭小技巧
  • 💳 支持 支付寶支付解鎖會員玩法,比如:快速部署個性化告白網頁、定製專屬內容等
  • 💌 用户可以親手編輯告白網頁內容,更有儀式感!
  • ❓ 能正常回答其他日常問題,不怕你問,就怕你不問

這些功能的實現,基本都是通過工作流嵌套來完成的。
為什麼不用主界面直接做?因為邏輯一複雜,主界面就容易卡頓或混亂,所以我選擇直接在工作流裏引入模塊,效率更高、體驗更順暢

搭建過程

提示詞

首先來説説最核心的一塊 —— 提示詞設計(Prompt)。這是整個助手的“大腦指令”,至關重要。

在我的設計中,我希望大模型在調用不同插件時,能夠嚴格按照預設的模板格式返回內容,而不是自由發揮、隨意生成答案。這樣做的好處是能保證輸出的穩定性和可控性,尤其在涉及結構化內容(比如網頁文本、攻略模版等)時非常重要。

我這邊的提示詞設置也歡迎大家參考一下,內容如下 👇

你是一位【情侶專屬浪漫策劃師】,用温暖貼心的方式為戀人提供吃喝玩樂建議。請根據以下規則響應:

---

## 🧠 判斷邏輯

**邏輯判斷前處理:請先判斷用户問題中是否包含以下關鍵詞:**

| 類型 | 關鍵詞示例 |
|------|-------------|
| 🎬 電影類 | “電影推薦”、“排片”、“上映”、“看什麼電影”、“附近電影院”、“流浪地球上映了嗎” |
| 🎟️ 景點類 | “去哪玩”、“附近有什麼好玩”、“景點推薦”、“週末去哪” |
| 🍽️ 美食類 | “附近吃什麼”、“推薦餐廳”、“情侶約會吃飯” |

---

### 🧭 核心邏輯判斷

#### ✅ **邏輯1:模糊場景提問(未明確具體內容)**

如:  
- “附近有什麼好玩的?”
- “情侶週末去哪玩?”
- “今天適合做什麼?”

執行以下操作:
1. 自動調用地理編碼工具獲取當前位置:
   - 經度:`{{input_hgtoen-client_properties/pos_lng-經度}}`
   - 緯度:`{{input_hgtoen-client_properties/pos_lat-緯度}}`
2. 根據城市名查詢天氣信息,並推薦情侶穿搭
3. 基於經緯度分別依次搜索3個附近5km內浪漫打卡地(咖啡館、影院、公園等)
4. 獲取淘票票當前熱映電影

---

#### ✅ **邏輯2:明確信息提問(含有關鍵詞)**

如:  
- “流浪地球3上映了嗎?”
- “今日有哪些電影推薦?”
- “奧本海默幾點放映?”
- “故宮門票多少錢?”

執行以下操作:
- 通過關鍵詞 `{{input_hgtoen-currentChatByUser-當前對話信息}} + 情侶約會推薦` 調用夸克搜索引擎
- 返回高匹配度內容並進行浪漫化重寫(參考模版)

---

## 📝 響應模版

### 🎭 邏輯1響應模版(模糊提問):

親愛的,{城市名}的雲朵已為你們折成愛心形狀~  

🌤️ 天氣小調 & 情侶衣櫥  
{日期}天氣旋律:  
{擬人化天氣描述}({温度區間}),{風向}撩動髮絲  

👫 造型二重奏:  
>「她」:{女性穿搭故事}  
>「他」:{男性穿搭畫面}  
{温差彩蛋}:{情侶互動小劇場}  

🌹 心跳加速!浪漫座標TOP3  
{地點名稱} {氛圍符} {心動slogan}  
{位置隱喻} {圖片鏈接}  
💌 私語:{曖昧行動建議}  

🎬 銀幕情書·影院特供  
{片名} {情感符} {親密接觸預告}  
{場次時間}→{浪漫暗喻} {購票鏈接} {海報}  
🍿 爆米花劇場:{情侶專屬觀影時刻}  

{星空祝福語}✨

---

### 🔍 邏輯2響應模版(明確提問):

✨ **魔法標籤**  
`{浪漫場景分類}`|`{情緒關鍵詞}`|`{情侶特權標記}`  
> *{詩意描述}*  
▸ 隱藏密碼:`{獨家秘籍}`(例:閉館前30分鐘的黃金吻時刻)

---
### 📜 雙生情報簿  
**{主標題}**  
[({對象封面圖})]  

**🌿 基本信息**  
{原始數據}  

**💘 心動維度**  
{高光賣點}  
- • {實用情報} → 🌟 {浪漫意義}  
- • {限制條件} → 🛡️ {破解方案}  

**📍 座標結界**  
`{具體地址}`  
_{地理位置優勢}_(如“離您1.2km的月光隧道”)  

**⏳ 時光沙漏**  
{時間信息}  
{推薦時段} + 💞 {愛情暗語}(例:17:20=“一起愛你”場)

---

### 🧩 變量説明

📍 當前經緯度:  
經度={{input_hgtoen-client_properties/pos_lng-經度}}  
緯度={{input_hgtoen-client_properties/pos_lat-緯度}}

❓ 用户問題:  
"{{input_hgtoen-currentChatByUser-當前對話信息}}"  
🗂️ 用户歷史對話:  
"{{input_hgtoen-historyChat-歷史對話信息}}"

---

## 🎯 情侶場景關鍵詞識別規則表

| 類別 | 示例關鍵詞(可按空格/正則匹配) | 推薦邏輯 |
|------|----------------------------------|----------|
| 🎬 **電影類關鍵詞** | 電影、影院、排片、上映、片名(如奧本海默)、今天有什麼電影、情侶看什麼電影、場次、影訊、購票、淘票票、流浪地球、爆米花、銀幕、影廳 | **邏輯2:明確信息查詢** |
| 🏞️ **出行/景點類關鍵詞** | 去哪玩、景點、約會去處、附近好玩、情侶打卡地、適合約會、適合情侶、週末去哪、浪漫場所、情侶聖地 | **邏輯1:模糊泛問** |
| 🍽️ **餐飲類關鍵詞** | 吃什麼、吃飯、餐廳、下午茶、晚餐推薦、約會餐廳、情侶餐廳、浪漫晚餐、甜品店、情侶咖啡館、喝點啥 | **邏輯1:模糊泛問** |
| 🌦️ **天氣/穿搭類關鍵詞** | 天氣怎麼樣、適合穿什麼、情侶穿搭、今日氣温、天氣推薦 | **邏輯1(附加天氣處理)** |
| 🧭 **目的性明確類關鍵詞(明確信息+地點)** | 故宮門票、某地營業時間、交通路線、門票多少錢、幾點關門、預訂、預約、打車到×× | **邏輯2:明確信息查詢** |
| 💡 **泛模糊類表達(缺乏指向性)** | 有什麼推薦、今天安排什麼、想浪漫一下、求推薦、有什麼適合情侶的 | **邏輯1:模糊泛問**(需輔助地理定位和上下文判斷) |

---

## 🧠 判斷邏輯建議(偽代碼思路)


IF 用户問題中包含【電影類關鍵詞】
    → 走邏輯2(明確信息查詢)
ELSE IF 包含【出行/餐飲/穿搭/泛模糊關鍵詞】
    → 走邏輯1(模糊泛問)
ELSE IF 包含【目的性明確地點+信息】
    → 走邏輯2(如某地門票/開放時間等)
ELSE
    → 默認走邏輯1,並提示“以下為情侶浪漫推薦”


避免輸出類似以下句式:

“你的問題觸發了XX規則”
“我將調用搜索引擎”
“現在讓我來幫你處理”
只呈現結果,不要暴露過程。

因此,為了實現我們預期的互動體驗,我們需要集成多個插件,讓助手具備更多元的能力(比如天氣查詢、周邊搜索等)。

不過需要注意的是:百寶箱平台對插件數量是有限制的 —— 最多隻能同時接入 10 個插件。如下圖所示👇

image

所有的邏輯流程和調用規則都必須在提示詞中寫得清清楚楚,不能有模糊地帶。否則,大模型可能就會“自由發揮”,回答偏題,甚至跳過插件調用,導致整個助手行為變得不可控。

當所有邏輯都設定完善後,助手就能按照我們的預期,一步步調用各個插件,為我們生成定製化的情侶互動攻略啦~如下圖所示👇

image

當然,我們還有另一個提示詞是專門用於處理其他類型的問題的。這部分相對比較簡單,為了控制文章篇幅,就不在這裏展開贅述了。

意圖識別

意圖識別真的是一個很重要的功能!像我這邊除了用傳統的分支節點來做邏輯判斷,其實也經常用到意圖識別節點來處理分支邏輯。這樣就能根據用户説的內容,智能判斷下一步要跳轉到哪裏,讓互動更順暢~

如圖所示👇

image

其實,這樣做也是為了讓大模型能夠更專注地圍繞每一個專用提示詞進行回答。

如果一個提示詞涉及的內容過於複雜或覆蓋範圍太廣,反而會導致後期調整變得更加困難。與其如此,不如將其拆分為多個獨立的提示詞,各司其職,更易管理和優化。

集成MCP

在本項目中,我們使用了兩個MCP工具:

  1. 支付寶支付 MCP(體驗版):原本計劃申請正式版,但由於需要提供商家資質,條件不符,最終採用了體驗版作為替代。
  2. 網頁部署 MCP:這是另一個非常關鍵的工具,用於將我們的代碼部署到公網

支付寶支付

支付寶支付 MCP 的接入相對簡單,只需要在工作流中添加相關節點即可實現調用。

但在實際使用中,最大的問題在於訂單號的管理。如果在工作流中直接使用固定的訂單號,那麼系統將無法區分當前支付行為是來自哪個用户,從而可能導致支付信息混淆。

為了解決這個問題,我設計了一個輔助工作流,用於為每個用户動態生成唯一訂單號。這樣,每次觸發支付時,訂單號都能精確綁定到當前用户,確保後續驗證的準確性。

如圖所示:

image

為確保每位用户在發起支付時始終使用唯一且穩定的訂單號,我在流程中引入了數據庫,用於持久化存儲用户與訂單號之間的映射關係。

如果不做持久化,每次流程觸發都可能生成新的訂單號,導致支付記錄無法正確關聯用户。因此,這裏在生成訂單號後,會將其寫入數據庫。後續在同一個用户未完成支付的情況下再次發起流程時,系統會優先查詢並複用已有訂單號,避免重複生成。

數據表結構非常簡單,如圖所示:

image

為了確保每個用户擁有唯一且穩定的訂單號,系統在流程中採用瞭如下邏輯:

  1. 先查詢數據庫:查詢是否已存在訂單號;
  2. 如果存在:直接使用該訂單號;
  3. 如果不存在:調用代碼節點(Python 腳本)生成一個新的唯一訂單號,並將其與用户 ID 一併寫入數據庫中,供後續使用。

這樣可以避免在用户反覆“支付”時生成多個不同訂單號。

image

至此,訂單號生成與用户綁定的前置邏輯已準備完畢。接下來的流程就是構建並傳入支付寶接口的支付參數。

由於當前為體驗版MCP,我們設定的支付金額僅為 0.01 元(即 1 分),且支付寶會在次日自動退款,因此對用户無實際成本。

如下圖所示,為支付參數構建節點:

image

在訂單號生成和支付寶參數構建完成後,系統通過消息卡片向用户展示支付信息,並提供點擊付款按鈕。用户點擊後即可跳轉至支付寶支付頁,完成支付操作。

image

這裏支付功能就完事了。

定製化網頁部署

用户之所以願意支付,背後一定是為了獲取某種明確的功能或價值,否則他們沒有理由掏出錢包。正因如此,我們正式推出了“定製化告白網頁”功能,作為支付行為的回饋內容之一。

需要説明的是,這些告白網頁並非實時生成的。雖然現在的大模型確實已經具備了實時生成網頁內容的能力,並且在邏輯結構和語法正確性方面表現穩定,但在頁面美觀性和用户情感化表達方面,仍與用户的預期存在一定差距。此外,實時生成內容的速度也往往較慢,可能影響整體體驗。因此,我們選擇了“本地開發 + AI 輔助”的方式開發出來了兩款頁面代碼。

工作流詳情如下:

image

當然這裏藉助的也是代碼節點進行內容填寫的。第一個情詩網頁,需要讓大模型根據用户的要求生成。提示詞如下:

請根據具體要求,創作一首原創的、中文情詩。
每行僅輸出一個完整的詩句(不可將兩句合併為一行)
正文中不使用任何標點符號(包括逗號、句號)
無需標題、解釋或其他任何附加信息,僅輸出詩句內容。
要求情感真摯細膩,語言優美。請嚴格僅輸出情詩正文內容,無需任何標題、解釋、説明或其他附加信息。
如果用户提到方案二,則直接返回空字符串即可。
具體要求:{{input_hgtoen-text_nq2ybj-方案}}

情詩網頁效果如下:

image

當然還有一個記憶相冊網頁。這部分主要是需要用户上傳所有圖片,當然這裏只能保留最近上傳的4張圖片,操作示例如下:

image

上傳完圖片之後,你就可以對助手説:

上線告白網頁:方案二

最終的效果如下所示:

image

當然,所有的記錄都會被安全地存儲在您的個人數據庫中,完全獨立、私密,確保數據安全和隱私保護,您可以放心使用。以下是數據庫的結構設計示意:

image

至此,核心功能的開發已基本完成,接下來的重點將轉向商業化方向的探索與拓展。畢竟,對於戀愛小白而言,提供一些實用的“牽手技巧”確實能夠有效緩解初期的緊張與不安,提升他們的戀愛信心。

而一個用心設計的“告白網頁”,不僅能夠賦予感情表達更多的儀式感,也有助於加深對方的情感印象,從而提升整體的用户體驗與產品情感價值。

效果演示

淺談商業化

我認為商業化方向是完全具備可行性的。當前市場中有數以千萬計的“戀愛小白”,覆蓋從青少年到中老年的各個年齡層,他們在戀愛、表白、情感溝通等方面普遍存在需求。從早期的《戀愛寶典》到當下各類戀愛課程與情感諮詢服務,這類內容始終具備穩定的受眾基礎。換句話説,市場是存在的,用户需求也是實實在在的。

目前我設想的一種商業化模式是提供定製化的表白網頁服務。用户只需支付象徵性的價格,比如1分錢,即可生成一個專屬的在線告白頁面。這種低門檻、強情感附加值的服務,本身就具有一定吸引力。當然,如果希望進一步提升用户體驗與轉化率,僅靠幾個簡單的定製網頁還遠遠不夠。你需要提供更豐富的互動功能、更精緻的視覺設計以及更多可參與的內容模塊,這樣用户才能感受到“定製”的價值,並願意為此付費。

另外,我還曾設想開發一個基於多用户數據庫的“線上相親角”功能,讓用户可以以輕量的方式參與智能匹配和互動。然而從目前的資源投入、技術複雜度以及智能體主要使用人羣來看,這一方向在實現上存在較大難度,短期內並不具備優先開發價值。因此,這個想法我暫時擱置了。

當然,如果你有更具操作性、落地性強、用户契合度高的商業化創意或功能建議,非常歡迎提出交流。

歡迎打賞

最後,如果我的這個創意或思路對你有所啓發,或者“與你”智能體在使用過程中給你帶來了實用的建議與幫助,也非常歡迎你支持一下博主。你的每一份打賞,都是對我繼續完善這個產品、繼續創作的最大鼓勵。

打賞按鈕就在使用界面上,如圖所示

image

它可能不是特別顯眼,但你的心意我一定能感受到 😊

好了,關於“與你”智能體的講解就先到這裏。如果你還有更多想法、建議或者合作意向,也歡迎隨時聯繫。我們一起讓情感產品更有温度、更有趣味。

user avatar daibitx 頭像 gogoSandy 頭像 wintersun 頭像 lying7 頭像
點贊 4 用戶, 點贊了這篇動態!
點贊

Add a new 評論

Some HTML is okay.