LLM 應用的產品化思考

過去一年多，我參與了好幾個 LLM 應用的產品化專案。從智能客服到文檔問答，從代碼輔助到內容生成，每做一個專案就對 LLM 應用的產品化多一層理解。

這篇文章把我的思考系統整理一下，不一定對，但希望對正在做類似探索的人有一點參考價值。

LLM 應用的第一性原理

在討論具體產品形態之前，需要先想清楚一件事：LLM 應用和傳統軟體產品的本質區別在哪裡？

傳統軟體是確定性的——輸入 A，經過確定的邏輯，輸出 B。如果輸出不對，是代碼有 bug，修 bug 就好。

LLM 應用是概率性的——輸入 A，模型輸出 B，這次和下次不一樣。模型可能今天回答正確，明天因為 context 長度變化就回答錯了。這種不確定性是模型固有的，不是 bug，不能通過修代碼解決。

理解了這個區別，就理解了很多 LLM 產品失敗的根本原因：產品經理在用設計確定性產品的方式設計不確定性產品。

什麼時候該用 LLM

我有一個簡單的決策框架：當用戶願意為「大概正確」付費時，用 LLM；當用戶需要「絕對正確」時，慎用。

這個框架可以幫助快速排除很多不適合 LLM 的場景。

比如「幫我寫一封商務郵件」——用戶需要的是「好用的模板」，LLM 写出來的「大概能用」就夠了，這個場景適合用 LLM。

比如「幫我算一下這個財務數據是否準確」——用戶需要的是精確結果，任何錯誤都可能導致嚴重後果，這個場景不適合直接用 LLM，至少不能不加校驗地直接用。

Prompt Engineering 被嚴重低估了

在整個 LLM 應用開發流程裡，Prompt Engineering 是被嚴重低估的環節。

很多人以為 Prompt 就是寫幾句話的事情。實際上，在真實產品中，Prompt 往往是一套複雜的指令體系：System Prompt 定義角色和邊界，Few-shot Examples 提供參考案例，Output Format Specification 定義輸出格式，Constraint Rules 定義各種約束條件……

好的 Prompt 設計可以讓模型表現提升 20-30 個百分點，效果可能比換一個大參數模型還明顯。但 Prompt 優化又是一個極其依賴領域知識和產品感的環節，這恰恰是 AI PM 可以深度參與的環節。

幻覺問題怎麼解決

被問到最多的技術問題：LLM 胡說八道怎麼辦？

答案很殘酷：LLM 本身無法保證不胡說。這是模型的固有问题，不是在應用層可以完全解決的。

但產品層可以有緩解手段：

RAG（檢索增強生成） 是目前最有效的方案——讓模型在回答之前先檢索相關文檔，然後把檢索結果作為 context 一起給模型。模型不是在自己知識庫裡搜尋，而是被強制「限定」在已知資訊範圍內。

這個方案的問題是需要維護一個檢索系統，增加了工程複雜度。什麼時候值得做 RAG？我的經驗是：當回答準確性的重要性 > 響應速度 + 工程成本時，做。

成本結構是產品決策的一部分

LLM 應用有一個傳統軟體沒有的成本維度：token 消耗 = 錢。

每一次 API 調用都是成本。這個成本結構直接影響了產品設計：上下文越長成本越高，流式輸出比非流式用戶體驗好但工程更複雜，模型越大效果越好但成本也更高。

做 AI 產品經理，必須對成本有清晰的概念。不需要會優化模型，但需要知道：什麼樣的產品設計會產生什麼樣的 token 消耗量級，用戶願意付的錢能不能覆蓋成本。

這個問題在 ToB 產品裡尤其重要。很多 ToB AI 產品失敗，不是因為效果不好，而是因為成本結構算不過來帳。

寫在最後

LLM 應用的產品化和傳統軟體產品化，底層邏輯是一樣的：用戶願意付費的是解決問題的價值，不是技術本身。

但因為 LLM 的不確定性特徵，產品設計需要在更早的階段就把「AI 能做什麼、不能做什麼」納入約束條件。這對 AI PM 提出了更高的要求：既要有傳統 PM 的用戶洞察和商業思維，又要對 LLM 能力邊界有足夠深的體感。

這條路沒有捷徑，只有在實戰中不斷積累。