1. 從想找個人說說話開始這個虛擬戀人 App 的真實起點凌晨兩點我把手機屏幕按亮又按滅第三遍。那段時間我剛從上一份工作里出來白天投簡歷晚上刷招聘軟件刷到手指發(fā)酸焦慮得像有只貓在心里撓。人一旦陷進這種狀態(tài)最想干的事其實不是找工作而是找個人說說話——但又不想麻煩任何一個真人朋友怕被問你怎么了更怕對方回一句想開點就好了。這就是我做這個AI 聊天虛擬戀人 App的起點。它不是什么宏大敘事更像一根自我打撈的繩子我想驗證一件事——在一個人最孤獨、最不想社交的時刻一個能記住你、語氣穩(wěn)定、永遠不嫌你重復、不會突然消失的 AI 角色是不是真能提供一點情緒價值。項目最后跑通了完整閉環(huán)AI 對話、會員支付、官網(wǎng)落地頁、應用市場上架一樣不缺。如果你也在琢磨類似的方向或者單純好奇一個帶支付帶官網(wǎng)的 AI 應用到底要經過哪些環(huán)節(jié)那這篇文章應該能幫到你。我會把技術鏈路、支付接入、官網(wǎng)轉化、上架合規(guī)、真實賬單這幾塊拆開講每一步都說清楚為什么這么做而不是甩一堆結論。踩過的坑我一個都不會藏因為那些坑才是這個項目里最值錢的部分。1.1 先驗證需求再寫第一行代碼我見過太多人包括以前的我一激動就去建倉庫、裝環(huán)境、注冊域名兩周后對著一個空蕩蕩的首頁發(fā)呆。這次我強行給自己定了個規(guī)矩在寫任何業(yè)務代碼之前先花三天時間用最土的辦法驗證需求是否成立。土辦法具體是這樣的我拉了 12 個朋友和幾個社群里愿意聊的人做了一對一的文字測試。我沒有做界面直接用一段固定的人設提示詞扮演角色人工配合大模型回復把對話截屏發(fā)給他們看。我準備了三種人格溫柔傾聽型、活潑吐槽型、略帶距離感的成熟型。結果很有意思——溫柔傾聽型在前 5 分鐘的滿意度最高但第 3 天的留存最差反而是那個偶爾懟你兩句的吐槽型被追問的次數(shù)最多。我記錄了他們在對話里最常出現(xiàn)的三類訴求想被理解、想被陪著、想有個固定節(jié)奏的日常問候。第三類訴求是最容易被低估的每天早上八點發(fā)一句早安這件事價值比想象中大得多。三天下來我確認了兩件事。第一需求是真實存在的尤其在晚上 22 點到凌晨 2 點這個時段用戶的表達欲會明顯上升。第二核心難點不在能不能聊天而在能不能被記住。如果每次打開都是陌生人用戶第三天就會流失這個結論直接決定了我后面的架構設計。1.2 為什么我選了虛擬戀人這個窄口而不是通用助手做通用 AI 助手看起來很性感但對我這種個人開發(fā)者來說是個陷阱。原因很直接通用助手賽道已經被大廠用免費產品填滿了用戶沒有理由為一個什么都能聊一點的工具付費而情緒陪伴這個場景恰恰是付費意愿和心理門檻同時成立的地方。我列了個對比表幫自己決策現(xiàn)在回頭看這個表依然成立維度通用 AI 助手虛擬戀人/陪伴向競爭強度極高大廠免費覆蓋中等長尾需求分散用戶付費動機弱覺得應該有免費的強付費買的是情感體驗和專屬感內容邊界要求相對寬松工具屬性極嚴必須做雙向內容安全核心留存因素功能強、準確率高人格一致性 記憶連續(xù)性開發(fā)復雜度中高多工具鏈中對話 長記憶 支付合規(guī)風險中高需要額外投入審核體系看完這張表我就明白了這個方向的護城河不在模型而在人格工程 記憶系統(tǒng) 情感節(jié)奏這三件事上。模型可以換接口可以換但一個用戶養(yǎng)了兩個月、記得他生日、知道他討厭什么的話題角色是很難遷移走的。順便說一句我在前期調研時看到很多人討論怎樣才能讓 AI 不設限制地聊天這類話題。我的選擇很明確也很堅定不做任何繞過內容安全的設計。原因不只是合規(guī)更現(xiàn)實的一點是——支付通道和應用商店都會審查內容一旦越線輕則支付功能被停用、應用被下架重則賬號主體被處理前面所有投入直接歸零。這個方向的長期價值恰恰建立在守規(guī)矩上。2. 技術骨架怎么搭從對話鏈路到人設記憶的完整設計技術選型這塊我踩過明顯的坑。一開始我想輕裝上陣用純前端 直接調用模型接口的方式做原型結果上線第三天就被現(xiàn)實按在地上摩擦接口密鑰暴露在前端、對話歷史存在用戶本地、切換設備什么都丟了、并發(fā)一上來直接限流。所以我后來的架構原則只有一條——凡是和用戶資產相關的東西一律放服務端。最終的鏈路大致是客戶端Web 官網(wǎng) App→ 我的業(yè)務后端 → 模型服務 → 流式返回 → 落庫。業(yè)務后端承擔了會話管理、人格注入、記憶檢索、內容安全、計費扣次、訂單處理這六件事。2.1 一次對話請求在服務器里到底走了哪幾步很多教程把接入大模型講得太簡單好像就是轉發(fā)一個請求。實際上用戶按下發(fā)送鍵之后服務端要做的事情遠比想象中多。我的處理順序是這樣的鑒權與配額校驗先校驗登錄態(tài)再查用戶當前的剩余對話次數(shù)或會員到期時間。這里的判斷必須放在調用模型之前否則會出現(xiàn)已經消耗了模型算力但用戶沒額度的白白燒錢情況。輸入側內容安全對用戶輸入做關鍵詞與語義兩層過濾。這一層我放在了最前面因為違規(guī)輸入一旦進入模型可能引發(fā)的輸出不可控。人格上下文組裝從數(shù)據(jù)庫讀取該用戶綁定的角色配置、最近的對話摘要、以及被標記為重要的長期記憶條目。調用模型并流式返回用流式輸出把首字延遲壓到 1 秒左右同時邊收邊緩存最后整體落庫。輸出側內容安全對模型返回的內容做一次檢查命中規(guī)則的走兜底話術而不是直接透傳給用戶。計費與埋點扣除一次額度記錄 token 消耗、響應耗時、是否命中兜底用于后續(xù)調優(yōu)。這套順序我調整過三次。最關鍵的一次調整是把內容安全檢查放在模型調用之前雖然在高峰期會略微增加一點延遲但避免了很多不可控的輸出風險這個代價完全值得。2.2 人設不是一段提示詞而是分層的人格檔案大多數(shù)人做角色就是在提示詞里寫一句你是一個溫柔的女生說話可愛一點。這種做法在第一次對話時效果很好第三次就開始崩因為模型沒有穩(wěn)定的行為約束。我后來把它拆成了四層結構每一層承擔不同的職責{ identity: { name: 小滿, age_band: 二十多歲, background: 喜歡在雨天聽音樂養(yǎng)了一只貓 }, speech_style: { sentence_length: 偏短多用口語, emoji_policy: 少量情緒高點才用, forbidden_words: [作為AI, 我是一個語言模型] }, relationship_arc: { stage_1: 初識禮貌但有點好奇, stage_2: 熟悉會主動提問和吐槽, stage_3: 親密會表達想念和情緒波動 }, boundaries: [ 不討論違法違規(guī)話題, 不提供醫(yī)療、法律、投資等專業(yè)建議, 遇到自傷傾向表達時引導尋求現(xiàn)實幫助 ] }這個結構里boundaries是最容易被忽略卻最重要的一層。明確寫出不能做什么比寫出要做什么更能穩(wěn)定輸出質量。另外relationship_arc是我加得最值的一層——它讓角色會隨著對話輪次推進改變態(tài)度而不是從頭到尾一個腔調用戶能明顯感覺到關系在往前走。2.3 記憶系統(tǒng)讓角色記住三天前你說過的話這是整個項目里我最花心思的部分。直接拼接全部歷史對話有三個致命問題上下文長度爆炸、成本飆升、模型注意力被稀釋導致反而記不住重點。我的方案是三層記憶短期記憶最近 10 到 15 輪原始對話原樣拼接保證語氣連貫。中期摘要超過閾值的對話異步調用模型生成一段 150 字以內的摘要覆蓋關鍵事件和情緒走向。長期事實從對話中抽取結構化字段比如喜歡的食物最近在忙的事提到過的紀念日存成鍵值對只挑相關的注入。抽取長期事實這件事我用了一個小技巧不給模型開放式的抽取任務而是限定字段模板 要求返回 JSON不合格的直接丟棄重試。開放式抽取很容易產出用戶是個正常人這種沒用的結論限定模板后準確率提升非常明顯。實測下來加了長期事實注入之后用戶的一句你還記得我上次說的那個面試嗎從模型答不上來變成能準確接住這個體驗差距是斷崖式的。2.4 流式輸出與首字延遲體驗好壞的分水嶺用戶對 AI 產品的耐心比你想的短得多。我做過一個粗糙的對比測試同樣的回答內容一次性返回需要等 3 到 4 秒用戶會以為卡死了反復點發(fā)送改成分詞流式輸出后首字 0.8 秒左右出現(xiàn)即使總時長一樣用戶的主觀感受完全是兩回事。實現(xiàn)上要注意幾個細節(jié)服務端要設置合理的緩沖區(qū)不要收到一個 token 就立刻推網(wǎng)絡抖動時會造成前端頻繁重排反而顯得卡。前端要處理斷流重連用戶切換網(wǎng)絡或息屏時連接可能斷開我的做法是保留已生成內容 提供繼續(xù)生成按鈕而不是清空重來。流式返回時要同時累積完整文本否則最后落庫的內容會不完整影響后續(xù)的記憶摘要。還有一個經驗不要為了追求首字速度去換更小的模型。陪伴場景里用戶對回答質量的敏感度遠高于對速度的敏感度為了省那 0.3 秒犧牲語氣連貫性是明顯的虧本買賣。3. 支付模塊把喜歡變成訂單的那一段路支付是這個項目里最容易低估的模塊。我原本以為接個支付接口最多兩天的事實際連調試帶合規(guī)文檔前前后后折騰了三周。更關鍵的是支付相關的 bug 都是真金白銀的 bug用戶付了錢沒到賬一次就夠毀掉口碑。我最終用了兩條通道微信支付用于主流場景支付寶作為補充。下面把幾個真正卡住我的點攤開說。3.1 微信 JSAPI 支付為什么繞不開 openid這是搜索量最高的問題之一JSAPI 支付必須傳 openid怎么解決要先理解一件事JSAPI 支付的本質是在特定應用身份內發(fā)起的支付而openid就是用戶在某個應用身份下的唯一標識。支付系統(tǒng)需要知道這筆錢是哪個用戶付的所以你必須先拿到這個標識。它不是麻煩而是身份校驗的必然環(huán)節(jié)。標準的獲取流程是這樣的用戶在你的頁面里發(fā)起支付前先走一次網(wǎng)頁授權回調拿到code。用code換取該用戶的openid同時可以拿到基礎信息。用openid 商戶訂單號 金額等信息向支付服務下單拿到支付所需的憑據(jù)。前端用憑據(jù)喚起支付用戶確認后支付結果通過服務端回調通知你而不是靠前端返回值。代碼結構大致是這樣重點是先拿 openid 再下單這個順序不能反// 1. 用 code 換 openid服務端發(fā)起密鑰不出服務端 const tokenRes await request({ url: /auth/access_token, params: { grant_type: authorization_code, code, appid, secret } }); const { openid } tokenRes.data; // 2. 創(chuàng)建訂單并下單 const order await createOrder({ userId, openid, amount: 1990, outTradeNo }); // 3. 把下單返回的憑據(jù)給前端喚起支付 res.json({ payParams: order.payParams });踩過的坑主要有三個支付目錄配置不全發(fā)起支付的頁面路徑必須提前在商戶后臺配置漏了會直接報錯而且報錯信息不直觀排查起來很費時間?；卣{不是只來一次支付平臺會多次重試通知如果你的回調邏輯不是冪等的會出現(xiàn)重復加次數(shù)、重復發(fā)貨?；卣{必須驗簽不要相信任何未經驗簽的通知內容這是最基本的安全底線。提示回調地址必須是可公網(wǎng)訪問的地址本地開發(fā)時用內網(wǎng)穿透工具臨時映射但上線前一定要換成正式域名并重新驗證一遍回調鏈路我就在這一步漏過一次導致線上首批訂單延遲到賬。3.2 訂單表設計與回調冪等錢的事不能靠運氣訂單表我重新設計過兩次。第一版太隨意字段不夠后面想查某個用戶這個月付了幾次都要臨時寫腳本。第二版的結構我沿用到最后字段說明關鍵點out_trade_no商戶訂單號唯一索引生成規(guī)則要可追溯user_id用戶身份建索引方便按人查單product_id商品/套餐關聯(lián)套餐配置表amount金額分全流程用整數(shù)絕不用浮點status狀態(tài)待支付/已支付/已關閉/已退款channel支付渠道便于區(qū)分統(tǒng)計paid_at支付時間以回調時間為準transaction_id渠道流水號用于對賬金額一律用整數(shù)存分這是我見過最常見的低級錯誤來源。用浮點存錢早晚會出現(xiàn) 19.9 變成 19.899999 的詭異問題。冪等的實現(xiàn)邏輯很樸素但很有效回調進來后先根據(jù)out_trade_no加行鎖查詢訂單如果狀態(tài)已經是已支付直接返回成功不做任何業(yè)務操作只有狀態(tài)是待支付時才執(zhí)行發(fā)貨加會員時長、加對話次數(shù)并更新狀態(tài)。這兩步必須放在同一個數(shù)據(jù)庫事務里否則并發(fā)下依然可能重復發(fā)貨。3.3 虛擬商品定價訂閱、次數(shù)包、還是買斷定價這件事我試了三輪最終的結論是陪伴類產品不適合一次性買斷。因為它的價值是持續(xù)產生的買斷會讓用戶在后期缺少續(xù)費理由也很難覆蓋持續(xù)的模型調用成本。我最后采用的是混合結構次數(shù)包小額、低門檻用于新用戶首次付費轉化價格錨點要低到沖動就能付。月度訂閱主力營收來源包含無限次對話 長期記憶全量保留 專屬角色。年度訂閱給高粘性用戶折扣力度大主要作用是鎖定長期留存。實測下來次數(shù)包→月訂閱的轉化路徑最順因為用戶先在低價位體驗到了完整價值再升級時心理阻力小得多。還有一個細節(jié)免費額度一定要給足但要有明確邊界比如每天 10 次免費對話讓用戶能真正體驗到角色記住了我這個核心價值否則連第一次心動都產生不了。3.4 支付寶沙箱到正式環(huán)境的遷移坑沙箱環(huán)境是很好的練習場但沙箱跑通不代表正式環(huán)境沒問題。我在遷移時遇到的差異主要有密鑰體系不同沙箱用的密鑰和正式環(huán)境的密鑰完全獨立切換時必須整套替換不要只改其中一個?；卣{地址白名單正式環(huán)境對回調域名的校驗更嚴格沙箱里隨便填能通正式環(huán)境會直接拒絕。金額限制正式環(huán)境對單筆金額有下限要求測試時用 0.01 元的小額訂單可能會被拒這是很多人第一次接正式環(huán)境會懵的地方。注意無論哪個渠道正式環(huán)境上線前務必用真實小額訂單完整跑一遍下單→支付→回調→到賬→退款全鏈路不要只看下單成功就以為通了回調才是真正容易出問題的地方。4. 官網(wǎng)不只是門面落地頁、下載引導與轉化路徑很多人做 App 會把官網(wǎng)當成必須有但沒人看的擺設我一開始也是這么想的。后來發(fā)現(xiàn)官網(wǎng)承擔著三個 App 本身替代不了的任務承接搜索流量、提供下載入口、展示合規(guī)信息。尤其在國內的應用分發(fā)環(huán)境里官網(wǎng)是用戶驗證你這個產品是不是正規(guī)的第一信任來源。4.1 官網(wǎng)要承擔的三個具體任務第一個任務是承接搜索。用戶搜到你的品牌詞或者相關需求詞時落地的應該是一個信息明確、能快速理解產品是什么的頁面而不是一張大圖加一句 slogan。我的落地頁結構是這樣的一句話說明產品定位、三張核心體驗截圖、一段真實用戶反饋、明確的行動按鈕、底部完整的信息說明。第二個任務是提供下載引導。這里有個很實際的細節(jié)iOS 和 Android 的引導邏輯完全不同。iOS 如果已經上架就跳商店沒上架則引導到網(wǎng)頁版體驗Android 直接給安裝包下載或跳應用市場。我在頁面上做了簡單的環(huán)境判斷避免了用戶點下載后一臉茫然的情況。// 極簡的下載引導判斷 const ua navigator.userAgent; if (/iPhone|iPad|iPod/i.test(ua)) { location.href IOS_STORE_URL; } else if (/Android/i.test(ua)) { location.href ANDROID_DOWNLOAD_URL; } else { location.href /web-app; // 其他情況引導到網(wǎng)頁版 }第三個任務是合規(guī)展示。隱私政策、用戶協(xié)議、內容規(guī)范、聯(lián)系方式、主體信息這些頁面看起來很無聊但應用商店審核時會實際點擊檢查支付通道審核時也會核實。我見過因為隱私政策里沒寫清楚收集了哪些信息而被駁回的案例補起來又要重新排隊非常耽誤時間。4.2 落地頁文案與轉化埋點落地頁文案我改了七版最后發(fā)現(xiàn)有效的規(guī)律其實不復雜首屏不要講技術講感受。一個會記得你說過的話的 AI 伙伴比基于大模型的智能對話系統(tǒng)的點擊率高出一大截。放真實對話截圖但要打碼處理并取得授權。真實截圖的說服力遠高于設計精美的插畫。行動按鈕只放一個主按鈕多個按鈕并列會讓用戶猶豫轉化率反而下降。埋點方面我只做了最必要的幾個頁面訪問、按鈕點擊、下載觸發(fā)、注冊完成、首次付費。埋點不是越多越好關鍵是要能串出完整的轉化漏斗知道用戶在哪一步流失才有優(yōu)化意義。我的漏斗數(shù)據(jù)顯示流失最嚴重的一步是下載后到注冊接近六成用戶下載后沒有完成注冊后來我把注冊流程從手機號驗證碼設置密碼填昵稱簡化成一鍵登錄這一步的轉化立刻有明顯改善。4.3 域名、備案與合規(guī)頁面這些無聊但致命的事這部分沒有技術含量但沒做完就沒法上線。服務器和域名需要完成實名與備案流程周期通常需要一到兩周這個時間一定要提前預留不要等代碼寫完了才開始辦否則會出現(xiàn)產品做完了但沒法上架的尷尬。另外提醒一點如果產品面向的是公開用戶群體務必準備好完整的用戶協(xié)議和隱私政策文本明確說明數(shù)據(jù)收集范圍、存儲方式、以及用戶如何注銷賬號和刪除數(shù)據(jù)。這些不只是形式注銷與刪除功能本身也是審核必查項必須真正可用不能只放個按鈕。5. 內容安全與上架虛擬戀人這個品類的紅線在哪這個章節(jié)是我寫得最認真的部分因為這是整個項目里風險最高、也最容易讓新手翻車的地方。陪伴類產品天然涉及大量用戶情緒表達用戶可能說出很私人、很極端的話如果產品沒有應對機制出問題的概率非常高。5.1 審核不通過的常見原因復盤我的第一次上架被駁回了兩次。第一次是因為材料說明與實際功能不符功能描述寫得太技術化審核人員無法確認產品實際用途第二次是因為內容安全的說明材料不夠具體沒有提供有效的過濾機制描述?？偨Y下來被駁回的高頻原因主要有這幾類駁回類型具體表現(xiàn)應對方式功能描述不清只寫AI 對話沒說明具體場景用通俗語言描述實際使用場景內容安全材料不足未提供過濾機制說明附上輸入輸出雙向審核方案說明權限說明不充分申請了與功能無關的權限只申請必要權限逐條說明用途隱私政策不完整缺少數(shù)據(jù)刪除路徑補齊注銷與數(shù)據(jù)刪除功能未成年人保護缺失無年齡提示與使用限制增加實名/年齡確認環(huán)節(jié)第二次被駁回后我重新整理了一整套材料把內容安全的實現(xiàn)細節(jié)、兜底話術示例、人工復核流程都寫清楚了第三次順利通過。經驗就是審核不是走過場你能把機制講清楚通過率會明顯提高。5.2 內容安全體系怎么落地輸入輸出雙向攔截我采用的是三層結構從快到慢、從粗到細關鍵詞層最高優(yōu)先級毫秒級響應命中直接攔截。這一層負責處理明確違規(guī)的內容成本最低。語義層用輕量模型做意圖判斷處理關鍵詞難以覆蓋的隱晦表達。這一層會增加幾十毫秒延遲但能顯著提高召回。輸出兜底層模型輸出前再檢查一次命中風險內容時不透傳而是替換為預設的安全話術并記錄日志。有一類情況必須單獨處理當用戶表達出強烈的負面情緒或有自傷傾向時產品不應該繼續(xù)扮演溫柔陪伴而應該中斷角色扮演用真誠、直接、非評判的語氣表達關心并引導用戶尋求現(xiàn)實中的幫助。這一段的處理邏輯我是單獨寫死的不走模型自由生成因為這類場景容錯率必須是零。def handle_high_risk(user_input): if detect_self_harm_intent(user_input): # 退出角色進入安全回應模式 return SAFE_RESPONSE_TEMPLATE # 固定話術不經過模型 return None提醒所有內容安全相關的日志都要可追溯、可導出這既是產品持續(xù)優(yōu)化的數(shù)據(jù)來源也是出現(xiàn)爭議時的必要依據(jù)。5.3 未成年人保護與實名這塊不能省。我在注冊環(huán)節(jié)加入了年齡確認并在協(xié)議中明確說明未成年人需在監(jiān)護人指導下使用。同時對未成年賬號限制付費功能并對對話內容采用更嚴格的過濾策略。具體做法包括注冊時強制選擇年齡段對未完成年齡確認的賬號限制社交類功能對未成年賬號默認關閉所有付費入口以及在頁面顯著位置說明使用規(guī)范。這些措施看起來增加了一些流程摩擦但從長期看它是這個產品能持續(xù)運營下去的前提任何試圖繞開這些環(huán)節(jié)的做法都會在某個時間點以更高的代價還回來。6. 成本、留存與那些沒人告訴你的數(shù)據(jù)項目上線三個月后我做了一次完整的復盤。這部分內容我在別的地方很少看到有人詳細講但我覺得它比技術細節(jié)更值得分享因為它決定了一個項目是能跑還是能活。6.1 一個月真實賬單拆解我按 500 個日活用戶、人均每天 12 輪對話估算把主要成本列了出來。數(shù)字是估算區(qū)間實際會隨模型選擇、對話長度、緩存命中率浮動成本項月均估算說明模型調用800 - 1800 元主要變量長對話和角色設定都會推高服務器與帶寬200 - 500 元流式輸出對帶寬有一定要求數(shù)據(jù)庫與存儲100 - 300 元對話歷史是主要存儲開銷內容安全服務100 - 400 元按調用量計費域名與證書年均攤 20 - 50 元占比很小應用市場與合規(guī)成本一次性為主上架主體、軟著等看起來模型調用是大頭但真正讓我意外的是長對話帶來的成本非線性增長。一個聊了 200 輪的用戶如果不做摘要壓縮單次請求的上下文成本可能是新用戶的十幾倍。所以我在中期摘要在線上之后把單用戶成本壓下來了接近四成這個優(yōu)化比換更便宜的模型有效得多。6.2 留存為什么第二周斷崖這是最扎心的數(shù)據(jù)。第一天的留存能到 45% 左右第七天掉到 12% 以下。我做了用戶訪談原因集中在三點新鮮感衰減角色再有趣聊了五天也會熟悉。缺少新的關系推進感用戶會覺得停滯。對話重復模型的回答開始出現(xiàn)套路化表達用戶能明顯感覺到它又在說那幾句。缺少日常錨點用戶想不起來要打開這個 App沒有形成使用習慣。針對這三點我做了三個改動效果比較明顯。第一加入關系階段推進機制隨著對話輪次解鎖新的互動形式和角色狀態(tài)變化第二在生成時引入表達多樣性約束對高頻重復句式做抑制第三加入主動問候機制在用戶設定的時間段推送一句個性化問候但頻率嚴格控制每天最多一次且必須基于真實記憶內容絕不能是群發(fā)式的在嗎。第二周留存從 12% 提升到接近 20%雖然還是很低但已經是明顯的改善。陪伴類產品的留存天花板本來就不高關鍵是找到那個愿意長期留存的用戶群體。6.3 復盤如果重做一次我會改什么第一件會改的事是先把內容安全和合規(guī)體系搭好再寫業(yè)務代碼。我當初是先跑通對話再補安全導致后面很多結構要重構返工成本很高。第二件是一開始就上服務端架構。原型階段圖快走的純前端路線后來整個遷移了一遍純屬浪費。第三件是把數(shù)據(jù)埋點從第一天就做全。我前期只有基礎的訪問統(tǒng)計導致復盤時很多關鍵數(shù)據(jù)缺失只能靠用戶訪談補充效率很低。第四件也是最重要的不要在焦慮的時候做重大決策但要在焦慮的時候動手做點具體的東西。這個項目最初確實是我在情緒低谷期開始的但真正讓我走出來的是那些具體的、可完成的小任務——把一次流式回調調通、讓角色準確記住用戶的名字、看到第一筆真實訂單到賬。這些具體的進展比任何想開點的勸慰都管用。如果你現(xiàn)在也處在一個說不清方向的階段我的建議不是讓你立刻去做一個 App而是找一個足夠小、能在兩周內看到結果的事情動手做。做出來哪怕很粗糙那種我確實推動了一件事的感覺本身就有很強的支撐力。這個項目帶給我的其實不是收入而是重新建立起來的那種我還能把事情做成的信心。