以「好」為核心,內容與社交是入口,AI 是決策助手
Kitch Chat 幫助年輕食客發現值得吃的餐廳與菜品,並找到合口味、適合一起吃的選擇。
為誰服務
先服務 UCI 的美食探索者、日常選餐者與朋友聚餐組織者;以實際需求分群,不假設所有學生都有相同喜好。
解決什麼問題
看過很多內容、評分和餐廳,仍不知道哪家適合自己、該點什麼,或怎樣兼顧朋友。
交付什麼價值
看得懂推薦依據,選到合適的一餐;吃完願意認可、記錄、分享,下次還會回來。
為什麼選擇「好」
「多」提供選擇,「快」降低操作成本,「省」減少花費;但都不能單獨保證用戶吃得滿意。KC 的戰略假設是:持續幫用戶選對,才能形成比一次優惠更持久的使用理由。預算與效率仍重要,但服務於「好」,不再各自成為獨立主線。
這是待驗證的產品方向,不是已證明的競爭優勢。AI 決策、電話與人工兜底保留;不重建支付交易平台,不以商家入駐作為用戶使用的前提。
「好吃且合口味」是核心,場景與預算是必要條件
| 「好」的層次 | 用戶要的答案 | KC 怎麼做 | 怎樣判斷真的好 |
|---|---|---|---|
| 菜品值得吃 | 這家有什麼值得點,為什麼? | 具體菜品、味型、推薦官原因、近期真實反饋 | 實際吃後認可,而非只有點擊或影片觀看 |
| 合我的口味 | 別人喜歡,但適不適合我? | 理解濃淡、辣度、甜度、口感;解釋適合與不適合之處 | 用戶認為符合偏好;失配可說清原因並修正 |
| 適合這次用餐 | 今天和這些人去,合適嗎? | 結合人數、氛圍、時間、距離與同行者限制 | 實際場景成立,同行者也能接受 |
| 值得這個預算 | 不一定最便宜,但值得嗎? | 先排除超預算選項,再比較菜品與體驗;交代價格依據 | 實際花費符合預期,用戶覺得值得 |
首頁標記「好」,必須讓人看懂依據
有明確入選理由
資料與營業資訊核查,加上可追溯的具體用餐證據;說明推薦菜、適合誰與更新時間。
知道是誰、為何推薦
顯示推薦者口味、實際吃過的菜與體驗日期;是否受贈或贊助需揭露。
有潛力,不冒充已驗證
可以曝光資料完整的新店,標註「反饋待累積」;沒有評分不等於差,也不等於已證實好吃。
入選機制建議:運營依統一清單核查來源和推薦理由,記錄審核人及日期;推薦官不是自動認證。出現菜單變更、重複失配或履約投訴時複核,必要時撤下精選標記。
榜單不只有一種「最好」
先做「UCI 課後值得吃」「適合聊天的聚餐」「同一道菜的不同風格」等有理由的專題清單;資料足夠後再做同菜排名及個人必吃榜。公開範圍、樣本和時間,不用餐廳總評冒充菜品評分。
口味以本人表達和實際反饋為主;飲食文化背景可自願補充,不按族裔、姓名或語言直接推定喜好。過敏與嚴格飲食限制需餐廳確認,不以 AI 推論保證安全。
差異不在單個功能,而在「發現到吃後認可」的體驗
以下比較美國餐飲入口的主要角色,不代表各平台只有這些功能。KC 的差異是擬驗證方向,不能僅憑功能組合宣稱領先。
| 入口/競品 | 現有能力或主要角色 | 對 KC 的要求 |
|---|---|---|
| Google Maps | 地點資訊、對話式個性化推薦及訂位等行動。官方介紹 ↗ | 不能只說「懂需求的 AI」;要在 UCI 的具體菜品與聚餐結果上證明價值。 |
| Yelp | 評論與商家資訊,並擴展 AI 個性化與行動能力;部分電話功能屬公告規劃。官方公告 ↗ | 不只整理評論;把誰推薦、為什麼合口味和實際結果串起來。 |
| Beli | 餐廳記錄、朋友分享、個性化推薦與榜單。官方介紹 ↗ | 是內容/社交方向的直接競爭參考;KC 要把具體菜品、多人選擇與履約協助做出深度。 |
| OpenTable | 餐廳發現、預訂及餐廳經營服務。官方介紹 ↗ | 訂座是基礎行動,不是定位中心;先回答為什麼值得去。 |
| 社媒/外送入口 | 作為用戶替代路徑:看內容種草,或直接找可下單餐廳。各入口實際能力另有差異。 | 訪談學生如何在這些入口間切換,驗證 KC 是否減少重新搜尋,且提高選餐滿意度。 |
在一個學生生活圈,把「有依據的本地好店與菜品」「可信推薦者」「個人口味與多人需求」「實際用餐反饋」連成同一個體驗。
鴨覓給我們的啟發:推薦官、口味適配與組隊找店可作產品參考,但不是把整套社區一次搬來。KC 先以 UCI 小範圍供給與學生關係網建立可信度,再看是否能複製。
長期可積累的是「用戶—菜品—偏好—真實結果」及信任關係,不是公開資料、通用 AI 或電話功能本身。商業化不得購買自然榜單排名。
核心假設:選得好,才會再用和分享
發現值得吃
判斷適不適合
作出選擇
實際用餐
再用與分享
| 驗證問題 | 主要指標與口徑 | 結果影響什麼決策 |
|---|---|---|
| 是否真的選對? | 餐後推薦認可率=符合/超出預期的用餐次數 ÷ 有效餐後反饋次數;同報樣本數與回收率 | 優化口味理解、推薦證據或供給,不用點擊代替滿意 |
| 朋友是否也滿意? | 有完整成員反饋的聚餐中,全員認可的比例;同報成員反饋完整率 | 多人需求是否真正被兼顧,不只看組織者 |
| 是否形成持續使用? | 已滿觀察期的首用戶中,28 日內再次主動選餐/規劃/發起履約的比例 | 判斷是否可加大市場投入,而非只靠一次活動 |
| 分享是否帶來增長? | 分享帶來的新註冊、首次有效使用與後續回訪;區分自然分享與獎勵活動 | 投入好友分享、推薦官內容還是社團渠道 |
同步保留經營指標:累計與新增註冊、DAU/MAU、渠道轉化、確認履約成功率、人工成本。核心價值指標建議為「每週已確認用餐且餐後認可推薦的次數」,同時看獨立用戶數。
驗證方式:先由校友引薦在校生,在日常用餐與真實聚餐中試用;記錄原本找餐方法、推薦前預期和吃後結果。建議首輪 30–50 名學生、至少 30 次有效餐後反饋作方向性判斷,再校準 KPI,不將小樣本稱為規模化成功。
提交訂座/下單需求 ≠ 餐廳確認 ≠ 實際用餐 ≠ 滿意。訂單或支付由既有餐廳/渠道承接;AI 尚不穩定時可由客服兜底,清楚告知處理狀態。
以學生真實生活出發,不要求每個人先跟 AI 聊天
| UCI 場景 | 用戶路徑 | 「好」怎樣呈現 |
|---|---|---|
| 下課後不知道吃什麼 想吃好,時間與預算有限 | 附近精選 → 課後用餐專題 → 看簡介與推薦菜 → 有疑問問 AI → 下單/到店 → 打卡 | 不是無限滑餐廳,而是清楚知道附近有什麼值得吃、為什麼適合現在。 |
| 週末想探索新店 想吃某道菜或某種風味 | 同菜/口味專題 → 比較推薦官理由 → AI 結合喜好解釋候選 → 收藏/安排用餐 → 反饋 | 區分味型、價格和證據;新店用探索標記,不假裝已有大量好評。 |
| 朋友/社團聚餐 4 人口味不同,預算也不同 | 發起飯局 → 好友連結填需求 → AI 給 2–3 個候選與取捨 → 投票 → 組織者確認訂座 → 各自反饋 | 顯示共同滿足的條件及未完全滿足之處;餐廳內也可推薦不同人的菜。 |
| 看到同學打卡被種草 信任熟人,想和朋友一起試 | 關注動態/分享連結 → 查看實際點菜和理由 → 餐廳詳情 → 收藏/發起飯局 → 自己體驗後再分享 | 知道誰吃過、吃了什麼、為何喜歡;不是只有一張照片和總分。 |
以上是待訪談與試用驗證的場景假設,不代表所有 UCI 學生的共同偏好。校友協助引薦與理解背景,仍需在校生實際使用。
本版內容更重、社交更輕、AI 理由更清楚
| 模組 | 本輪最小設計 | 承擔的價值 | 後續再擴展 |
|---|---|---|---|
| 首頁與附近好店 | 附近精選、榜單專題、學生/推薦官內容;保留精簡 AI 入口;卡片有簡介、人均、特色菜與入選理由 | 先發現值得吃的選擇 | 更深個性化排序 |
| 榜單與專題 | 按菜品、場景、預算瀏覽;清楚標示範圍、理由、來源和更新時間 | 不用從空白問題開始找餐 | 足夠樣本後的同菜排名、個人榜 |
| 餐廳詳情 | 簡介、菜單、內容、評論、推薦官及其推薦理由;區分商家介紹和獨立反饋;保留訂座/下單入口 | 建立信任並支持選擇 | 更完整的菜品級反饋 |
| AI 推薦 | 少量候選,說明符合哪些需求、推薦點什麼、預算依據與限制;允許糾正偏好 | 從「看起來好」到「適合我」 | 根據餐後結果持續校準 |
| 多人決策 | 組織者建飯局;朋友免註冊填預算/忌口、投票;候選取捨清楚,組織者確認 | 兼顧朋友,降低協調成本 | 常用飯搭子、群體偏好記憶 |
| 打卡、分享與收藏 | 選餐廳/菜品、加照片、寫感受與是否願再吃;分享頁可直接看;收藏可回找 | 沉澱真實體驗,帶來下一次發現 | 個人美食地圖與完整清單管理 |
| 用戶頁與關注 | 口味自介、公開打卡、關注/取消關注、簡單關注動態 | 找到值得持續參考的人 | 口味相似用戶發現;不先做私訊與複雜社交等級 |
| 履約、運營與治理 | AI 電話/客服回傳狀態、餐後回訪;精選審核、舉報與內容處理;基本渠道追蹤 | 保證可用、可信與可驗證 | 更多自動化與商家自助工具 |
內容從哪裡來
起步:運營核查資料,邀請校友、學生體驗者與推薦官提供真實內容;MCN 將真實體驗製作成菜品/聚餐內容。使用後:普通用戶打卡反饋與分享。兩種來源清楚標示,不把宣傳內容包裝成獨立評價。
以上為功能規劃,不代表已上線。本次只確認方案;Demo 待確認後製作,沿用現有 Web 品牌與餐廳詳情結構,不改正式產品。
幫值得被發現的商家,找到真正適合的食客
KC 首先服務消費者。商家獲得的是特色被理解、匹配的客流與真實反饋,不是購買「好店」認證。Chowchow 可以參與,但不再作為整個定位的中心。
| 商家參與方式 | 商家提供什麼 | KC 提供什麼 |
|---|---|---|
| 被收錄,未合作 | 無需正式入駐;使用合規來源的公開資訊 | 被搜尋和按需求匹配;資訊缺口與證據不足如實標示 |
| 資料與履約協作 | 確認菜單、特色菜、營業及預訂方式;接受事實性資料修正 | 更完整呈現特色,減少錯誤推薦,承接匹配的用餐需求 |
| 內容/體驗合作 | 自願提供訪談、試吃或學生權益;承認用戶可給真實負面反饋 | 合適人群探索、可追溯內容、匿名匯總的用餐反饋與效果報告 |
| 後續工具使用 | 自助維護資料、處理需求與顧客溝通 | Agent 與經營協助;是否付費不影響自然榜單 |
小商家、新商家、沒有評分,怎麼辦?
先確認資料與特色,進入獨立的「新店探索」內容;邀請願意探索的學生真實體驗,逐步形成具體菜品反饋。證據足夠後再審核是否精選。沒有評分不應被永遠埋沒,但 KC 也不能在缺乏證據時保證好吃。
後續商業化:可評估商家工具訂閱、透明標示的活動合作或可核驗效果服務;現階段先驗證消費者價值與商家實際獲益,不把付費設成被推薦的門檻。
本版依據與邊界
參考用戶提供的《鴨覓 App 全面競品調研》HTML/Markdown及 KC 討論;美國競品能力以文中官方來源為據。未進行完整登入測試,不推斷競品不存在未列出的功能。既有 Web 與 Figma 僅作後續 Demo 視覺參考。本版未更改正式產品。公開資料與社媒內容需確認授權/嵌入條件;營業狀態正常不代表可接受本次訂位或訂單。