一、2025 年：在「PM 不直接碰 Code」的工作流裡，AI 能做到哪裡
⠀⠀
在 2025 年的產品團隊，PM 沒有 GitHub 權限，所有 AI 應用都只能在 PRD、User Story 這類型的 PM 文件進行發揮，演進方式如下：⠀⠀
▍Phase 1：把過往的產品文件匯入 NotebookLM
PM 剛開始接觸 AI 工具是 NotebookLM、Claude。
把團隊過往的所有 PRD、PPT、PDF 等產品手冊或文件，都匯入 NotebookLM，PM 寫新功能的第一個動作，從打開空白文件變成先問 NotebookLM：
- 請問 X 功能現在的限制有哪些？來自哪份文件？
- 若要針對 Y 模組增加 a/b/c 功能，建議的方式？
從上述回答開始寫新的 PRD，對於 Junior PM 是加速了解產品現況，而對於已經熟悉產品的 Senior PM 則是協助判斷。
但這個 phase 也有個限制：NotebookLM 的輸出品質完全取決於你匯進去的 PRD 品質。
因為 PRD 寫出來後，實際轉成工單系統的 Ticket，到工程師實際開發，可能又會改了好幾版，因此在 phase 1 難免還是會遇到寫出來的 PRD 需要 Tech Lead 檢查。
⠀⠀
▍Phase 2：建立 PRD Review 的機制
AI 寫 PRD 有了之後，接下來 phase 2 就是要檢查 PRD，因此當時 Senior PM 建立了一個有人格設定的 Claude Chat，專門用來進行 PRD Review 跟 User Story Review。
這個 Claude 內建一份檢查清單，像是 PRD 必須涵蓋緣起、範圍、效益、影響範圍、驗收標準等面向，少一個就會被指出來。
它的價值是把 Senior PM 的判斷標準從「經驗談」變成「可以複製的清單」。
過去資深 PM 的優勢是「我能根據過往經驗挑出 Junior PM 的問題」，但這個經驗不容易複製，當判斷標準被寫成 Claude 的 skill 清單，Junior PM 就可以隨時使用 Claude 來檢查自己的 PRD。
但這個 phase2 也會遇到 phase1 的問題，假設 NotebookLM 內的產品文件本來就有誤，不論是功能描述已過時、或沒寫到最新的功能現況，AI 都是在這個錯誤的基礎上產出錯誤的 PRD 跟修改方向，Review 機制檢查的是「PRD 是否完整覆蓋必要面向」，但無法 100% 檢查到「PRD 是不是符合現況」，因此這個階段仍會需要 Tech Lead 做最後的技術把關。
⠀⠀
▍Phase 3：將 PRD 自動拆成 User Story
接著的 phase3 則是和開工單有關，在 phase 2 理想上會請 AI 撰寫 PRD 時就要用 User Story 概念拆分範圍，PM 進行 Story 的複查。
因此這個階段 AI 就可以針對 User Story 生成驗收標準，甚至前端、後端、QA 的驗收卡片。
⠀⠀
▍備註：設計的角色在哪？
上述 phase 1~3 都是講 PM 的工作流程，但缺少設計師的角度，當時的設計流程脈絡：
- 設計師會根據 PRD 來產出 Figma
- PM 看 Figma 給回饋，設計師繼續調整 Figma
- 工程師根據 Figma 和 PRD 實作
- QA 人員根據 Figma 和 PRD 做測試和驗收
Figma 在這個工作流程是最終產品的畫面樣貌，但在 PRD 持續修改的過程中，Figma 也會隨著改變。
⠀⠀
二、2026 年：當 PM 擁有 Code 權限 ，PM 的工作流程怎麼轉變
⠀⠀
在新的產品團隊，PM 有 Github 權限，不需要閱讀 PRD 舊文件，可以直接透過 Claude Code 了解最新產品現況，演進流程如下：
⠀⠀
▍Phase 1：PM 直接用 Claude Code 寫 PRD
PM 擁有 Github 的一個席位，且可以下載 repo 的 clode 到本機，並串上 Claude Code，從此規劃任何功能我都可以直接問 Claude Code：
- 功能 A 現在怎麼運作？相關的 service 有哪些？
- 這個 API 改動會影響哪些前端元件？
- 過去這個邏輯改過幾次、是哪張 PR 改的？
最重要的轉變不只是「能查 code」這件事本身，而是幾乎不用再看過往的 PRD，因為 Claude Code 能回答跨檔案、跨模組的問題，直接問現在的 code 比看過去的 PRD 還要準。
最終我可以直接在 Claude Code 針對現況加上功能迭代方向，產出一份相對精準的 PRD，甚至可以說出這份 PRD 會改動多少範圍和服務給工程師看。
⠀⠀
▍Phase 2：PRD review 變成 PM 跟 Claude Code 的對話
接著演化的是 PRD review 流程。
用 Claude Code 寫完 PRD，PM 直接繼續追問：
- 有沒有按照過往開發慣例？
- 有沒有過度設計？過度開發？
- 有沒有保留必要的彈性？若未來要 OO 迭代是否可以？
Claude Code 因為知道 code 的脈絡，能回答這些過去要靠 Senior PM、Tech Lead 的問題，它能告訴你「這部分改動會影響既有的 OO 程式，導致 OO」、「這層抽象在現有 code 裡找不到先例，可能是過度設計」。
而當然 PRD 格式、驗收標準，都是可以透過 Claude Code 達成，真正改變的是 PRD Review 的本質不再是「找另一個 Sr PM 來檢查功能規劃細節」，而直接做出 PRD One Pager（重點摘要）來向上回報即可，大部分潛在問題都在 PM 跟 Claude Code 來回的過程中就解決了。
⠀⠀
▍Phase 3：PM 也能參與開發到部署到發 PR
PM 寫完 PRD 後，最後一哩路就是直接請 Claude Code 開發，部署到自己的測試環境，發 PR。
雖然聽起來像 PM 在搶工程師的工作，但我在的團隊嘗試讓 PM 負責簡單的 ticket、bug 修正、和查看 log，將工程師的時間被用在真正需要工程判斷的 feature，因為 PM 一開始還不夠有技術深度去辨識 Claude Code 寫的是不是正確的。
這個分工有個重要的環節： Code Review。
PM 自己的角色也跟著變，從「描述要做什麼」延伸到「自己驗證 PRD 做出來會長什麼樣子」 ，PM 用 Claude Code 部屬到測試環境，實測後再送出的 PR 也不一定完全正確，PM 自己可能也看不出來，所以工程師仍會需要幫 Review PM 的 PR，這部分變成新的負擔。
必須說的是，這只是其中一種 2026 工作流的樣貌，不同團隊的能給予 PM 的權限很不一樣，更大的組織可能 PM 仍無法直接擁有 Github 席位，在資安更嚴謹的產業，甚至無法使用 Claude Code。
⠀⠀
三、兩條故事線疊起來的共同模式
⠀⠀
兩家公司各自的 phase：
- 2025 的三個 phase 都在文件層運作：PM 用 NotebookLM 從歷史產品文件撈脈絡、用 Claude 產出 PRD、再用 Claude 檢查文件。
- 2026 的三個 phase 都在系統層運作：PM 用 Claude Code 查看真實程式碼、並根據既有程式碼寫 PRD、再部署到測試環境。
同樣的邏輯也影響到設計工具，Figma 從「PM 必看」逐漸降級為「特定場景才回去翻」（這個之後會再寫一篇現在的 AI 設計工具轉變）。
⠀⠀
上述模式寫成兩段話很簡單，但實際在組織裡推動都不是完全順暢。
▍之前團隊的 AI 寫文件
前一個團隊推「大家都用 AI 產 PRD、用 AI Review PRD」這件事比想像中難，每個 PM 寫 PRD 的格式都不同，要先統一所有 PM 的寫法和驗收標準，才能讓所有 PM 都接受同一套 Review 標準
要讓 PM 們真的把 AI 放進日常工作流，需要反覆的說服、示範、修正、再示範，技術不是難點，習慣才是，即使所有 PM 都認同，從認同到實際每天這樣做，還是有至少 3 個月的適應期。
▍現在團隊的 AI 寫 Code
現在團隊的痛苦點不一樣，從「PM 可以用 Claude Code 發 PR，但錯誤百出」到「PM 真的能發出可用的 PR」中間有一個學習曲線，一開始非常陡。
最初發出的 PR 很多是不堪用的，像是 AI 改錯了東西、漏處理 edge case、多了很多 branch 的 commit、或是多改到不需要動的服務，這些 PR 對 RD 來說 review 起來很痛苦，可能比自己重寫還慢，他還得花心思跟我解釋為什什麼這張 PR 有問題。
因此剛導入新工作流程時，團隊產能其實都會下降，因為我製造的 PR 並沒有節省 RD 開發時間，直到最近我開始可以和 Claude Code 來回檢查修改範圍，確認沒問題再動工、開 PR、甚至自己部屬測試，才讓整件事節奏越來越好。
⠀⠀
四、PM 的工作流程最終是什麼
⠀⠀
這篇記錄的是我在不同團隊的工作流程轉換，但也需要先說明，把同樣的權限發給不同的 PM，產出仍會有差，且無法保證這個導入可以全面讓所有 PM 都接受，可能會遇到 PM 缺乏技術直覺去直接相信 Claude Code 講的話、或是 PM 仍習慣逐字寫 PRD。
對 PM 個人來說，拿到權限不是終點，是新的學習開始。
要開始學習看自己的 PR、練習改 code 前都和 Claude Code 釐清正確的方向、練習什麼時候要相信 Claude Code、什麼時候要持續懷疑。
⠀⠀
可能有人會問：「PM 不是應該要做好決策就好？為什麼要花時間去做工程師的事？不會減少原本 PM 本來工作嗎？」
這也是我正在摸索的，自從有了 Claude Code 後，雖然花很多時間在和 Claude Code，但也默默在累積自己的技術知識，開始能知道為什麼有些地方不好客製化、有些地方無法直接改，因為 Claude Code 都可以白話文解釋技術限制，這些是之前 PM 自己無法想透的。
而 PM 修 ticket 這件事，我發現與其自己開票、描述內容、修改方向、排隊等工程師修改，我直接請 Claude Code 調整可以省去這段溝通時間以及溝通落差的成本，實際上可以加速工作效率。
⠀⠀
可能有人會再問：「如果 PM 能用 AI 寫 PRD、能部屬、能發 PR，那 PM 跟一個有產品 sense 的工程師有什麼差別？PM 還必要嗎？」
我認為 PM 真正能做出差別的位置在「判斷」，不在「執行」。
但有些公司的 PM 仍是純執行者、協調者，這也是部分組織需要的角色，沒有絕對，但對於正在思考「AI 之後我該往哪去」的 PM 來說，PM 仍握有以下優勢：
- 該做什麼（市場探索、用戶研究、優先級判斷）
- 不該做什麼（拒絕、聚焦、戰略捨棄）
- 為什麼做（why，而不只是 what 跟 how）
這三件事 AI 也可以幫 PM 做，但只要 PM 仍有足夠的商業敏感度或產品判斷力，我認為是現階段 PM 仍有存在必要的原因之一。
⠀⠀
五、關於要不要導入 AI 工作流程
⠀⠀
在整理文章時，一直在思考到底這個經驗能不能複製，但後來發現這個非常看各公司的產品團隊文化、權限管理、階層管理制度。
⠀⠀
情境一：公司內有沒有嚴格的向上彙報流程，必須以 PRD 作為基本文件？
假設公司內需要 PRD 來進行向上報告、審核才能提交給開發團隊，則可能還無法導入上述的 PM 自己開發的制度。
情境二：公司是否多個 PM 都認同這個流程？是由上而下都贊成嗎？
假設公司是由上而下就會相對容易推動，但如果只有一個 PM 想做這件是，就會遇到層層通關、要提交工作制度調整的問題，甚至要先說服其他 PM。
情境三：改變工作流程之後，其他人是否接受？
假設 PM 可以自己發 PR，原本的工程團隊能否接受？這個也要先確保 Tech Lead 是站在同一陣線。
⠀⠀
回到文章中間的對比：兩個產品團隊、不同的工作流。
沒有哪一種才是正確的做法，不論 PM 是用 AI 來寫 PRD、或是用 AI 來開發，只要該團隊是運作健康、穩定的都是好方法，所有改變工作流程的事都會有反彈，且不一定每個改變都能達到目的。
可能會以下因素有關：
- 團隊規模：小團隊比較好實現
- 導入方式：由上往下比較能從 Product Lead、Tech Lead 改變
- 說服方式：要看 PM 們和 RD 們是否都能接受
- 導入決心：是否能接受初期的不適應、是否能持續調整
⠀⠀
如對這系列文章有興趣可以再觀看：
