很多 PM 使用 AI 的第一反應，是把長文件丟給 AI，請它摘要、改寫、產出 PRD、User Story 或簡報。在軟體專案裡，也有人開始把 AI 視為寫 Code、產文件、產簡報的加速器。 這些當然有用，但如果 AI 只是幫我們把既有內容重新包裝，那它真正的價值其實還沒有被發揮出來。
我也蠻常使用 AI 處理需求分析、重點摘要、概念圖製作、或創意發想等工作，也用它產出文件或簡報內容。但我通常不會期待 AI 產出的內容可以直接成為最終答案。正確性仍然是我必須負責的事情。AI 的價值不在於取代判斷，而在於擴大我的觀察範圍。它可以幫我提出不同角度的看法、找出矛盾、提醒假設、生成追問問題；至於哪些成立、哪些不成立，仍然需要由我回到脈絡、事實與利害關係人再進一步確認。 這樣才能讓我不受限於本身經驗與知識，產生經驗盲點。而這樣的分工合作也才能真正產生出最大綜效。
把這樣的概念放在專案需求分析上，尤其適合。
因為需求分析是從專案啟動，甚至是啟動前，就要執行的步驟。若需求沒釐清，後續工作規劃得再漂亮，最終多半也只是落得一個「垃圾進、垃圾出」的悲慘下場！
依 PMI / PMI-PBA 的標準脈絡，需求工作通常會經過 需求蒐集、需求分析與建模、需求定義與細化、訂定驗收標準、需求確認與驗證、需求管理與追蹤等步驟。但在實務上，真正困難的往往不是知道如何執行這些步驟，而是如何在每一步中發現「還沒被說出口的問題」。
這種看出我們自己沒看出來的需求缺口，才是 AI 最能發揮的價值。
舉個例來說，有很多需求規格書裡可能會有這樣一個需求：可以快速查詢案件狀態。
乍看這只是要做一個可以查案件狀態的功能，不是很複雜。很多人可能只會問「頁面上要顯示哪些欄位」、「要不要按使用者權限區分可查詢之案件」等等。
但其實若深究，可以再追問的問題可能還包含：
- 誰需要查詢？主管、承辦人、客服，還是外部民眾？
- 查詢「快速」是指 3 秒內，還是減少操作步驟？
- 查詢的資料是即時狀態，還是每日批次更新即可？
- 是否需要留下查詢紀錄？留多久？
- 當資料不完整時，畫面應該如何提示？
- 這個需求真正要解決的是效率問題、透明度問題，還是責任歸屬問題？
- … 等等
透過這些我們會發現原來「查詢功能」背後還有權限、資料更新、責任邊界、使用者角色與驗收標準等問題。 若我們提供 AI 更多 context，也就是與此專案、客戶、流程或限制相關的背景資訊，AI 通常可以協助找出更多需求缺口。
一般來說，AI 能幫我們找出的需求缺口可歸納為以下三大類：
- 問題缺口：我們是否問錯問題，或只看到表面問題？
- 脈絡缺口：是否忽略角色、流程、限制、例外情境？
- 驗收缺口：需求是否可驗收、可測試、可追蹤？
AI 可以從這三個面向協助我們產生追問問題、找 root cause、補充角色、情境與限制，並進一步將需求轉成可驗收的標準或可測試的情境。
這樣，AI 就不再只是很吃 token 的文書助理，而是能真正協助 PM 提升判斷品質、擴大觀察範圍，並創造更大工作價值的人工智慧夥伴。