最近我在產品管理 (PM) 的工作中導入了 Claude Code，這是我近期工作方式最大的變革。原本需要幾天才能完成的規格文件與原型製作，現在幾個小時就能搞定，而且 AI 考慮的邊角案例 (Edge Cases) 甚至比我還周全一百倍。

這不僅僅是用 ChatGPT 問問題，而是將 AI 之於工作流 (Workflow) 的深度整合。正如 Anthropic 在其 Building Effective Agents 指南中所述，真正的生產力爆發來自於將 AI 從單純的「問答機器」轉變為能夠執行複雜任務的「代理人 (Agents)」。

核心流程：一人產品團隊

我的新工作流大致如下，這是一個從模糊到精確的收斂過程：

需求進來 → Claude Skills (SOP) 初步分析 → Sub-agents (多角度) 檢視與辯論 → 產出高品質 PRD + Prototype → 跨部門溝通 → 規格確立

這就像是你擁有了一個隨傳隨到的虛擬團隊，隨時準備好為你工作。與其說我是 PM，我現在更像是一個 AI 團隊的指揮官。

---

1. Claude Skills：把你的 SOP 寫進大腦

Skills 的概念很簡單：把你腦袋裡的標準作業程序 (SOP) 寫下來，讓 AI 嚴格遵守。這對應到 Anthropic 提到的 "Workflows" 概念——透過預定義的路徑來引導 LLM，確保產出的一致性。

以前寫 PRD，我們要注意命名一致性、格式規範、團隊慣用語，還要記得參考以前的舊文件。人腦很容易漏掉細節，改了 A 卻忘了壞了 B。

現在，我將這些規則封裝成 Skills。以下是一個真實的 requirement-analyzer Skill 範例：

# Skill: Requirement Analyzer

## Role
你是一位資深的技術產品經理 (TPM)，擅長將模糊的商業需求轉化為結構化的 User Stories。

## Input
- 原始需求 (Raw Input)
- 目標客群 (Target Audience)

## Output Format (Markdown)
1. **Executive Summary**: 一句話解釋這個功能是做什麼的。
2. **User Stories**: 格式為 "As a <role>, I want to <action>, so that <benefit>"。
3. **Acceptance Criteria (Gherkin Syntax)**:
   - Given [情境]
   - When [動作]
   - Then [預期結果]
4. **Edge Cases**: 至少列出 3 個極端狀況 (例如：斷網、資料為空、權限不足)。

## Rules
- 必須使用這種格式: `FE-[Feature Name]-001` 作為 ID。
- 優先考慮 Mobile First 的體驗。

當這些規則被寫成 Code (或 Prompt)，AI 就會按照預設的標準產出，既穩定又一致。那些花時間又容易出錯的 Cross-reference 工作，就全交給 AI 處理。

2. Sub-agents：換位思考的虛擬分身

如果說 Skills 是「手」，那麼 Sub-agents 就是「腦」。

自己寫規格時，很容易陷入盲點 (Blind spots)。根據 Basecamp 的 Shape Up Methodology，產品開發最忌諱的是在還沒想清楚 (Shaping) 之前就冒然投入開發。

為了避免這個問題，我創造了不同的 Agent 來進行「自我辯證」：

• User Researcher Agent: 質疑這個流程是否符合直覺？有沒有更好的體驗？
• Dev Agent: 評估技術可行性，釐清資料庫 schema 要怎麼開，API 要怎麼接。
• QA Agent: 專門找漏洞，列出所有可能的極端狀況。
• Stakeholder Agent: 從商業價值的角度挑戰這個需求的必要性。

實際運作對話 (Simulation)

Me (PM): "我想做一個『一鍵產出週報』的功能。"

Dev Agent: "技術上可行，但要考慮 Context Window 的限制。如果使用者的每週 Ticket 數量超過 500 張，API 可能會 Timeout。建議加上 Pagination 或與非同步處理 (Async Job)。"

QA Agent: "同意。另外，如果這一週完全沒有 Ticket 怎麼辦？報表會顯示空白還是有預設文案？還有，如果 API call 失敗，要有 Retry 機制嗎？"

User Researcher Agent: "等等，使用者真的需要『一鍵』嗎？他們通常會想要編輯 AI 產出的內容。我建議流程改成：生成草稿 -> 讓使用者預覽/編輯 -> 存檔發送。"

運作起來，就像是在電腦裡開了一場高效的會議。以前這些來回確認要開好幾次會，現在幾個小時內就能完成。這正是 "Shift Left" (測試左移) 的極致表現——在寫下第一行程式碼之前，問題就已經被發現並解決了。

3. 秒產 Prototype：溝通不再靠想像

這是最強大的部分。文字再精準，都不如一個能動的畫面。

以前常常規格寫好了，但設計圖還沒出來，跟工程師或老闆討論時大家只能「各自想像」，導致上線後才發現誤會大了。

現在利用 Claude Code 結合 v0.dev 或 Tailwind CSS，我可以直接產出前端代碼，給我一個能動的 Interaction Prototype。

• Before: "點擊這個按鈕後，會彈出一個 Modal，裡面有三個選項..." (工程師：聽起來好複雜)
• After: "直接看這個 HTML 檔，點點看就知道了。" (工程師：秒懂)

溝通效率快非常多，甚至可以在開發前先驗證技術細節。沒圖沒真相，現在我幾乎是帶著 Prototype 去開會。

4. Git Flow：文件即代碼 (Docs as Code)

最後一個關鍵改變是 Git Flow。這與 Atlassian 提倡的 Docs as Code 理念不謀而合。

以前文件散落在 Google Docs、Confluence 或 Slack 對話裡，久了就變成沒人維護的垃圾 (Stale documentation)。現在我嘗試讓所有的產出都進入 Git 版本控制。

推薦的文件結構

project-root/
├── src/                # 原始碼
├── docs/
│   ├── adr/            # 架構決策紀錄 (Architecture Decision Records)
│   ├── prd/            # 產品需求文件
│   │   ├── 2026-02-feature-A.md
│   │   └── 2026-03-feature-B.md
│   └── specifications/ # 技術規格書
├── .claude/            # AI 相關設定
│   ├── skills/         # 定義好的 Skills
│   └── prompts/        # 常用的 Prompt Templates
└── README.md

這樣做的好處是：

1. Single Source of Truth: 代碼變了，文件就在旁邊，提醒你要由改。
2. Code Review: 文件的修改也走 Pull Request 流程，確保有人看過。
3. Traceability: 誰在什麼時候改了什麼規格，Git Log 寫得清清楚楚。

總結

目前這都還是很粗淺的應用，但已經顯著減少了「產出低品質文件」的機會，也省下大量重複造輪子的時間。

很多 PM 擔心 AI 會取代他們，但我認為，AI 取代的是「執行者 (Doer)」，而不是「思考者 (Thinker)」。把繁瑣的工作 (寫文件、畫圖、查資料) 交給自動化，PM 才能將時間花在真正有價值的地方：決策與溝通。

未來的 PM，或許更像是一個 AI 團隊的指揮官，你的價值取決於你能調度多少 AI Agents 來為你解決複雜問題。