我是 Ward，做了九年 B 端產品經理，做過生產製造、供應鏈和批發零售的業務系統。後來我開始用 AI 做自己的小產品，從需求、開發到上線都自己走完。兩段經歷疊在一起，我感受最明顯的變化有兩處，一是需求文件裡哪些話還算需求，二是做使用者研究時要看什麼。
需求文件先寫邊界，再寫功能
傳統 PRD 寫的是，使用者點了這個按鈕，系統做什麼。同樣的操作，結果是確定的，驗收就看按鈕在不在，點了有沒有反應。
AI 功能就沒有這麼確定了。同一句話，模型這次答得很好，下次可能答偏。所以我建議寫需求時，先寫能力邊界和失敗模式，最後才是驗收標準。
能力邊界要寫到銷售、研發和產品說的是同一件事。下面這些是示例，我沒有做過實測。例如能總結八千字以內的文章，不處理圖片和影片，知識庫以外的問題直接說不知道。邊界寫清楚，銷售就不會承諾一個研發做不出來的功能。
失敗模式也要寫。AI 一定會出錯，常見的情況有三類。它不知道答案，它答了但使用者不滿意，它答錯了。每一種都要有產品上的對策。不知道就直說，並給出其他途徑；不滿意就給重新生成和補充要求的入口；答錯了要能糾正，並且有人接手。這些最好整理成一張表，體驗和技術方案分開寫。
我在紡織工藝問答的覆盤裡寫過一條，資料不夠的時候，不硬答，告訴使用者去哪裡查。這就是一種失敗模式的對策。
驗收從功能有沒有，變成品質怎麼樣
傳統產品的驗收是功能有沒有實現。AI 產品要看品質指標。下面的數字只是示例，寫法可以參考，具體值要按你的場景定。比如總結準確率達到百分之九十五以上，人工抽檢一百條；幻覺率低於百分之三；每條回答後的使用者評分均值超過四分。
驗收最後要靠日誌和抽樣來回答，靠感覺答不了。我的多模型路由配完以後，用了幾天，只覺得活沒有交給該交的模型，具體是哪裡出了問題，光靠感覺說不清。後來讓 AI 對著 2026 年 10 月的四千六百多條請求日誌做了體檢，又抽樣檢查了 248 輪推理強度的判斷，才看出問題在哪。比如，使用者只回一句「繼續」的時候，意圖模型經常會判成低強度，因為它只看這一輪輸入的字面內容。設定能跑，只說明它能用。跑起來有沒有按設計走，只有日誌能回答。
使用者研究，先分清問題出在哪邊
使用者說「這個 AI 不行」，這句話底下通常壓著兩種問題。一種是模型確實答不準。在紡織工藝問答裡，行業詞被搜偏，要改的是檢索和詞庫。另一種是使用者不會問。我們很快發現，工廠的使用者不習慣寫完整的問題，很多人只打一兩個詞。純對話框對他們太難，要改的是介面，把對話換成場景按鈕加表單。
兩種問題的改法完全不同，混在一起看，就會在錯的地方使勁。
AI 產品的訪談，比較適合讓使用者邊用邊說。使用者在哪一步覺得驚喜，在哪一步覺得失望，最容易從這裡看出來。測試也可以專門設計幾類，比如問一個資料裡沒有的問題，看它會不會編；多輪對話裡，看它能不能跟上上下文；指出它的錯誤之後，看它能不能改對。
產品的事實，放在一個地方
最後是我自己做小產品的一個做法。我把產品的名稱、狀態、價格和版本放進一份設定，頁面、腳本和 SEO 資訊都從它讀，不在幾處手寫。自己做產品，沒有人替你核對口徑，只能靠結構保證。
回頭看那個紡織問答專案，我最該先做的一件事，是去看工人實際會怎麼問。