我如何在擴展 AI 產品前先驗證需求

在擴展 AI 產品前，我會先確認現有工作流程能否在清晰邊界內被使用、檢查與驗證。

實際可行的循環應該刻意保持細小：先建立可以回答一個真實問題的最小版本，再交給真實使用者，觀察實際使用方式與付費意願，最後只在證據支持下一步時擴展。這是一套決策紀律，不代表每次實驗都一定會變成產品。

先釐清一個有用問題

當 MVP 的工作清楚，驗證會比較容易。第一個版本應該只負責一個工作流程，亦要清楚列出界線：輸入是甚麼、輸出是甚麼、哪些決定仍然由人作，以及甚麼結果會支持下一輪修改。

界線不是掩飾未完成工作的藉口，而是令一次有用測試可以覆核。具備清楚失敗狀態的小型流程，比起無法分辨價值來源的大型介面，更容易帶來下一個決定所需的資訊。

驗證循環

1. 建立最小可用版本。 將工作流程收窄到可以由輸入一路檢查到輸出。
2. 交給真實使用者。 觀察使用者在哪裡理解流程、在哪裡猶豫，以及實際使用了甚麼。
3. 記錄證據。 將實際使用、付費意願與實作假設分開，不要將假設寫成結果。
4. 作出下一個決定。 按現有證據選擇擴展、修改、暫停或移除。

MVP 紀律不等於低質素

兩者必須分開。驗證不是要求使用者接受粗疏工作，而是令最小版本足夠誠實，讓下一個決定建基於真實觀察。

限制 — 這套原則本身不會產生轉換數據，只會界定在擴展範圍前如何收集及理解證據。

一份實用的決策紀錄

question: 這個有界線的工作流程能否被使用及覆核？
observed_use: 記錄使用者實際做了甚麼。
missing_evidence: 記錄仍然未知的部分。
next_decision: 擴展、修改、暫停或移除。

可立即採取的做法很簡單：在新增功能前先寫下要回答的問題。如果目前版本未能產生可覆核的答案，增加範圍通常只會令決策更難，而不是更清楚。