PM x Gemini CLI (五)：AI 時代的敏捷實踐與 PM 新角色

要點一：AI 驅動的敏捷開發新流程

當 AI 成為您團隊的一員後，整個敏捷開發的樣貌將會從瀑布式的線性流程，轉變為一個快速反應的「概念-驗證-迭代」閉環。我們可以將這個新流程視覺化如下：

這個流程的核心在於，AI 大幅縮短了每個環節所需的時間，讓 PM 能在極短的時間內，完成從「抽象想法」到「具體規格」的轉化，並快速驗證市場反應。以下是更詳細的說明：

第一階段：構思 (Conception)

這是旅程的起點。PM 腦中有一個模糊的想法或觀察到一個用戶痛點。此時，AI 的角色是您的「策略夥伴」與「市場分析師」。

• 深化想法與腦力激盪：AI 透過提問，協助您釐清想法的邊界、挖掘潛在的價值主張。

我觀察到用戶在我們的 App 中，完成任務的效率很低。我有一個初步想法，是開發一個「智慧助理」來引導他們。請你扮演一位經驗豐富的產品顧問，針對這個想法，向我提出 10 個尖銳但關鍵的問題，幫助我思考得更周全。

• 結構化需求與產出用戶故事：將發散的想法收斂為具體的功能點。

基於我們剛剛的討論，請將「智慧助理」這個概念，拆解成 3 個核心功能 (Epics)，並為每個 Epic 提供 2 個具體的用戶故事 (User Stories) 和對應的驗收條件 (Acceptance Criteria)。

• 快速市場研究：AI 能快速掃描網路資訊，提供初步的市場競爭格局分析。

針對「App 內的智慧助理」這個功能，請幫我分析市面上 3 個主要的競品 (例如 Intercom, Drift, Zendesk)，它們是如何實現類似功能的？各有什麼優缺點？請以表格形式呈現。

第二階段：驗證 (Validation)

在投入昂貴的開發資源前，必須先驗證這個想法是否真的有價值。AI 在此階段是您的「原型設計師」與「研究助理」。

• 生成視覺概念與流程圖：雖然 AI 目前還無法直接取代 Figma，但它可以快速生成流程圖或低擬真線框圖 (Wireframe) 的描述，幫助您與設計師溝通。

我想設計一個新用戶引導流程，讓他們能快速上手「智慧助理」功能。請用 Mermaid 語法，生成一個流程圖，包含以下步驟：1. 用戶首次登入 2. 彈出歡迎視窗 3. 詢問用戶想完成什麼任務 4. 根據選項提供教學 5. 完成引導。

• 產出訪談大綱與問卷：為了收集用戶回饋，您需要好的問題。

你是一位資深的使用者研究員。為了驗證「智慧助理」這個功能的價值，請幫我設計一份 8 個問題的訪談大綱，目標是了解用戶目前遇到的困難，以及他們對智慧助理的期待與疑慮。

第三階段：迭代 (Iteration)

根據收集到的回饋，快速調整產品方向。AI 在此階段是您的「產品分析師」與「文件管理員」。

• 分析與總結回饋：從大量的用戶回饋中，快速提煉出關鍵洞察。

這是我們訪談 5 位用戶後的逐字稿 @interview_notes.txt。請幫我總結出 3 個最主要的正面回饋、5 個最關鍵的負面回饋，並找出用戶提到最多次的 3 個期待功能。

• 自動化文件更新：這是 AI 發揮巨大價值的地方。PM 只需要做出決策，AI 就能完成繁瑣的文件更新。

你現在是我的產品助理。這是上一版的使用者回饋摘要 @feedback_summary.txt，以及目前的規格 @spec_v1.md。請根據回饋，直接輸出一份更新後的規格文件 @spec_v2.md，並在修改處加上註解說明原因。

在這個流程中，PM 的角色更像是一位「產品建築師」，專注於設計藍圖與驗證結構，而 AI 則像是高效的施工團隊，負責將藍圖精準地實現出來。

要點二：「活文件」的實現：讓規格與實作同步

產品開發中最常見的麻煩之一，就是規格文件在幾次迭代後就失去參考價值，因為沒人有時間去手動更新它，導致文件與程式碼產生脫鉤 (out of sync)。這不僅造成溝通誤解，更會在未來累積為巨大的「技術債」與「溝通債」。

AI 工具提供了一個革命性的可能性：透過「半自動化」的工作流，大幅降低維持文件同步的時間成本，讓「活文件」不再只是個理想口號。

核心作法一：以「API 測試報告」為依據，校準技術規格

在敏捷開發的實務中，要求 PM 直接解讀 QA 團隊瑣碎的測試記錄，或甚至深入程式碼來更新規格，往往不切實際。一個更為高效且可靠的作法，是利用開發流程中自動化產出的「API 測試報告」。

在規格書完成後，可能會因為一些考量，在實作過程中有來回修改規格，這些紀錄可能存在好幾張 Jira Ticket 中；也可能在與工程師的口頭討論迭代過好幾次。當後端工程師完成開發後，CI/CD 流程會自動運行 API 測試（例如使用 Postman/Newman），並產出一份結構化的報告 (通常是 JSON 格式)。這份報告就是 API 行為最客觀、最即時的「真相」。PM 可以利用這份報告，來確保規格文件中的技術細節與實際情況一致。

你現在是我的技術文件同步助理。

這是 CI/CD 流程剛產出的 API 測試報告 @api_test_report.json。
請閱讀這份報告，它描述了「/users/{id}」這個端點的實際回應。

然後，請比對我們現有的規格文件 @prd_v1.2.md 中關於「取得用戶資料 API」的章節。

如果測試報告顯示 API 的回應欄位、資料格式或狀態碼與 PRD 中的定義不符，請直接更新 PRD 的內容，確保文件與 API 的實際行為一致，並在摘要中告訴我你修改了哪些地方。

這種作法不僅更貼近 PM 的工作流，也讓「規格校準」這件事，建立在一個客觀、自動化產出的數據基礎之上，大幅提升了準確性與效率。

核心作法二：從「源頭」擴散，以「規格變更」產生摘要

當您身為 PM，主動更新了規格文件後，下一個挑戰是如何快速告知所有利害關係人（工程師、設計師、測試人員）到底改了什麼。這時，您可以讓 AI 幫您做「版本比對」，並為不同對象客製化摘要。

你現在是我的專案助理。

請比較 @PRD_v1.1.md 和 @PRD_v1.2.md 這兩個版本的差異，並生成兩份「版本變更摘要」：
1.  **給工程師的技術摘要**：包含所有 API 變更、欄位修改等技術細節。
2.  **給業務團隊的市場摘要**：聚焦在對使用者有感的價值和功能變化。

請用條列式的方式呈現，讓我能直接貼到不同的溝通頻道。

核心作法三：從「實作」生成，以「程式碼」產生技術文件

對技術團隊而言，最準確的文件就是程式碼本身。但不是每個人都有時間或能力去閱讀原始碼。這時，可以讓 AI 擔任「技術翻譯官」，直接從程式碼生成人類可讀的技術文件。

這對於 API 文件、組件庫說明等場景尤其有用，可以確保文件與程式碼 100% 同步。

你現在是一位資深技術文件撰寫員。

這是我們新開發的登入驗證模組 @auth.py。請閱讀裡面的 `login_user` 和 `refresh_token` 這兩個函式，並為它們生成符合 OpenAPI 格式的 API 文件草稿。

文件需包含：
- 功能簡介
- 請求參數 (Parameters) 及其型別
- 成功與失敗的回應範例 (Response Examples)

透過上述三種 AI 協作手法，團隊可以建立一個「文件同步」的飛輪效應：無論變更是從規格、實作還是測試結果開始，都能快速地將變動同步到其他環節，大幅降低溝通成本，讓文件在整個產品生命週期中，持續保持其參考價值，真正成為團隊溝通的有效依據。

要點三：人類角色的轉變：從「執行者」到「決策者」

AI 的崛起，並非要取代 PM，而是要「解放」PM，或者說，是「昇華」PM 的角色。

過去，PM 的許多時間被花在撰寫文件、整理回饋、追蹤進度等「執行性」工作上。現在，這些都可以交給 AI 處理。

您的核心價值，將更聚焦在那些真正無法被 AI 取代的、屬於人類的獨特能力上：

• 願景與策略：定義產品的靈魂，決定「為什麼做」以及「要做什麼」。
• 同理心與洞察：真正走入用戶的世界，理解他們言語之外的需求與渴望。
• 溝通與領導：凝聚團隊共識，激發團隊熱情，帶領大家朝著共同的目標前進。
• 決策與擔當：在充滿不確定性的專案路上，憑藉經驗與直覺，做出關鍵決策，並為結果負責。

AI 是您最強大的槓桿，讓您能從繁瑣的日常中脫身，專注於成為一位真正的「產品領袖」。