Claude Code for Product Managers

全書精華

主要主題、論點、核心訊息的精簡摘要

主要主題：本書專為「管理產品但不直接閱讀程式碼的產品經理（PM）」所寫，探討如何利用具備代理能力（Agentic AI）的命令列工具「Claude Code」來優化 PM 的日常工作流程，並產出具戰略價值的成果。

• 核心論點：選擇正確的 AI 工具是節省時間的關鍵。網頁版的 Claude.ai適合一次性的對話與腦力激盪；而 Claude Code具備存取本機檔案系統、執行終端機指令及保留專案脈絡的能力，它是處理「需要讀寫檔案、會重複執行、產出需進入版本控制」等 PM 核心任務的唯一正解。
• 核心訊息：透過 Claude Code，PM無需具備寫程式的能力，就能直接從程式碼庫中找尋答案（例如除錯、釐清功能邏輯），大幅減少打斷工程師的次數。此外，PM可將用戶回饋分析、競品調查與需求文件（PRD）撰寫等重複性工作，編寫成可重複執行的「技能（Skills）」，甚至結合外部工具整合，徹底將零散的日常雜務轉化為標準化、自動化的高效流程。

掌握作者思路必懂的關鍵要點

• 雙工具思維模型（The Two-Tool Mental Model）：作者提出明確的判斷準則——如果任務符合「涉及檔案」、「會再次執行」、「產出需與程式碼存放在一起」這三個條件之一，就應該使用 Claude Code；否則，請使用Claude.ai。
• 不讀程式碼的程式碼調查法（Reading Code Without Reading Code）：PM可以透過設定唯讀的安全模式（plan mode），要求 Claude Code將複雜的程式碼翻譯成產品視角的白話文、流程圖或資料流。這讓 PM能自行釐清「功能如何運作」、「存取了哪些資料」與「邊界情況為何」，完成第一線的Bug 分析並提供高價值的報告給工程師。
• 建立可重複執行的「技能」系統（Building Skills）：拒絕無止盡地重複輸入長篇Prompt。作者提倡將反覆執行的任務（如每週分析用戶回饋、撰寫 Release Notes、競品分析）封裝成標準化的 Markdown指令集（SKILL.md）。這不僅能省下每次設定的時間，更能確保跨季度的分析報告擁有一致的格式與品質。
• 透過 MCP 消除「匯出/匯入」的無效勞動（MCP Integration）：利用模型脈絡協定（Model Context Protocol），PM 可以讓 Claude Code 直接查詢 Jira 票券、發布 Slack 訊息、提取 Figma設計規格或讀取資料庫。這消除了過去在多個軟體間手動匯出 CSV 再貼給 AI分析的繁瑣流程。
• 嚴守 PM 與工程師的責任邊界（Boundaries and Escalation）：作者強烈警告 AI的盲區。Claude Code只能進行「靜態程式碼分析」，無法了解系統在正式環境的實際運行狀況或動態設定。因此，PM可以提出假設、縮小除錯範圍，但絕對不能越界去修改正式程式碼、決定架構或自行評估資安問題。所有執行與實作的責任，最終仍必須交還給工程師。

反主流洞見

• 與主流觀點不同、值得深思的關鍵觀點一：PM 不應預設使用網頁版AI，而應擁抱具備代理能力的終端機工具

  • 差異點：主流觀點通常認為，PM 只需使用網頁版對話式 AI（如 Claude.ai 或ChatGPT）即可，因為簡單且不需要技術背景；但作者強烈主張，PM應該改用在終端機運行的 Claude Code。
  • 作者論證：網頁版 AI缺乏存取檔案系統與保持專案上下文的能力，這會導致極高的「隱形成本」——PM每次對話都要重新複製貼上脈絡、手動整理輸出。而 Claude Code能直接讀寫專案檔案、執行指令，並將單次對話轉化為可重複執行的「技能（Skill）」，徹底消除這些無謂的手工勞動。
  • 相關案例：在分析客戶回饋時，使用 Claude.ai 需要花 30分鐘解釋脈絡並手動搬運 CSV 資料；若改用 Claude Code，只要花 30分鐘設定好一次「技能」，未來每次分析都只需要 5 分鐘，直接在本地產出格式化報告。

• 與主流觀點不同、值得深思的關鍵觀點二：不懂寫程式的 PM也應該自己「調查」程式碼庫

  • 差異點：一般認為，不懂程式語法的 PM遇到系統行為問題時，只能轉交工程師調查；但作者認為，PM 應該直接透過 Claude Code詢問程式碼庫，自己完成問題的初步調查與釐清。作者論證：將所有疑問都丟給工程師會造成龐大的「上下文切換（context-switch）」成本，拖累開發進度。PM 的目的不是去改 code，而是透過 AI將程式碼的邏輯翻譯成產品語言。這能幫助 PM 建立系統心智模型，區分這是真Bug、使用者誤操作，還是極端情況，進而帶著具體的假設與檔案位置交接給工程師。
  • 相關案例：當客戶反映「折扣碼無法疊加」時，PM不用打斷工程師的衝刺，而是直接用 Claude Code 追蹤程式路徑。AI 會用白話文解釋，在discount-validator.js 的第 92 行有一條明確的商業規則阻擋了疊加。PM 花 15分鐘就能釐清這是商業邏輯而非 Bug，並決定後續行動。

與主流觀點不同、值得深思的關鍵觀點三：產品文件（PRD、Persona）應該像程式碼一樣放在 Git 儲存庫裡

• 差異點：主流習慣將產品需求文件（PRD）、使用者輪廓等文件放在 Google Docs或 Notion 中；作者則推崇對 PM 實施「Docs-as-Code（文件即程式碼）」，將文件以Markdown 格式直接放在程式碼儲存庫中。作者論證：將文件與程式碼分離，必然會產生「文件漂移（Drift）」——工程師實作後文件就過時了。放在儲存庫中進行版本控制，文件能與產品同步演進，工程師在開發時也能直接參照；更重要的是，這讓 Claude Code 能夠輕易讀取這些文件，在擴充 User Story或調查 Bug 時，確保決策與原始需求保持一致。
• 相關案例：撰寫「大量匯入使用者」功能的 PRD 時，文件被儲存為docs/prds/bulk-user-import.md。當實作過程中需求發生改變（如限制人數），PM直接修改該 Markdown 檔案並透過 Git 提交，Git歷史紀錄就會留下完整的決策與變更脈絡，取代容易失效的雲端連結。

與主流觀點不同、值得深思的關鍵觀點四：平行處理的「子代理（Subagents）」通常昂貴且無謂，循序漸進往往更好

• 差異點：在 AI工具的應用上，大眾常對「多代理協作（Multi-agent）」平行處理任務感到著迷，認為這是提升效率的終極解法；作者卻警告，對於大部分的 PM任務而言，盲目開啟多個子代理是不智且極度昂貴的。作者論證：每一個子代理都會建立獨立的上下文視窗，當多個代理同時讀取檔案時，To ken 消耗量會呈倍數暴增（可能高達 8 倍到 50倍）。此外，子代理缺乏主對話的歷史記憶，難以除錯。除非任務是「完全獨立（例如分析四個不同對手）」且「節省的時間價值遠大於暴增的 API成本」，否則簡單的循序漸進提示（Sequential prompts）反而品質更好、成本更低。
• 相關案例：進行四家競爭對手的分析時，循序處理需要 45 分鐘、花費約 0.60美元；開啟四個子代理平行處理只需 12 分鐘，但要花費 4.80 美元。這是一個用 8倍成本換取 6 倍速度的取捨。如果幫你省下這 33 分鐘的價值大於 4.20美元，那才值得使用子代理。

內化行動計畫(含記憶強化)

1. 建立工具選擇直覺：三問法則

• 行動目標：終結無效的「複製貼上」循環，根據任務特性精準選擇適當的 AI工具（Claude.ai 或 Claude Code）。
• 記憶鉤子：「三問法則」——要讀檔嗎？會重複嗎？要進版控嗎？
• 故事或例子：PM 小林習慣用 Claude.ai寫每週競品報告，每週都要手動貼上背景資料與格式要求，耗費半小時。某次他驚覺這完全是浪費生命，於是改用 Claude Code。現在他直接將報告產出在專案資料夾中，一鍵更新，將時間縮短至五分鐘，徹底擺脫複製貼上的無間道。
• 觸發情境：準備開始一項新的 PM 任務或分析時。
• 對象與場景：產品經理；日常分析、文件撰寫或代碼調查。
• 具體步驟：
  1. 問自己三個問題：任務需要讀寫檔案嗎？未來會重複執行嗎？產出需要留在版本控制（Repo）裡嗎？
  2. 若任一題為「是」，開啟終端機使用 Claude Code。
  3. 若全為「否」（如單次腦力激盪、草稿潤飾），使用網頁版 Claude.ai。
• 可衡量的成果：每週省下至少 1-2 小時前置文脈設定與複製貼上的時間。
• 失敗補救機制：若開啟 Claude Code 後發現其實只是想隨意發想，輸入 /exit關閉，無縫切回網頁版，不糾結沉沒成本。

2. 建立產品全局觀：架構快照法

• 記憶鉤子：「架構快照法」——不用逐行看 code，只需為架構拍張照。
• 故事或例子：剛接手新產品的 PM Alice遇到客訴總是不知從何查起，頻繁打斷工程師 Sprint。她利用 Claude Code 的 plan模式要求生成「給 PM的架構總覽」，快速掌握前端與資料庫的關聯。下次遇到問題時，她已能精準指出「問題可能在結帳邏輯模組」，讓工程師對她的進入狀況刮目相看。
• 觸發情境：剛接手新專案、新 Repo，或產品架構發生重大改版時。
• 對象與場景：非技術背景的 PM；專案探索期、新人 Onboarding。
• 具體步驟：
  1. 以 claude --permission-mode plan 啟動安全模式。
  2. 輸入提示詞：「請向產品經理用白話文解釋此專案架構，包含主要元件、資料流向、功能對應位置」。
  3. 將生成的回答存成 docs/architecture-overview.md 或放入 CLAUDE.md作為未來參考。
• 可衡量的成果：產出一份 PM 專屬的架構總覽文件，能在 5分鐘內指出特定功能對應的資料夾。
• 失敗補救機制：若 Claude給出的回覆太過技術化，回覆「請拔除所有程式碼語法，純用產品經理的商業語言與使用者旅程重新解釋」。

3. 守住調查邊界：二十分鐘停損線

• 行動目標：為工程師提供高價值的上下文線索，同時避免 PM陷入深似海的技術除錯兔子洞。
• 記憶鉤子：「二十分鐘停損線」——收斂線索，交接給專業的來。
• 故事或例子：PM Bob 為了查一個偶發的結帳失敗 Bug，在 Claude Code耗了兩小時試圖找出完美解答，反而拖延了修復進度。後來他嚴守「20分鐘停損線」，查出影響範圍與可疑檔案後直接交接。工程師根據他的線索，僅用 5分鐘就解開了這個需要看正式環境 Log 才能發現的連線超時問題。
• 觸發情境：接到客戶回報 Bug，準備進行初步調查（Triage）時。
• 對象與場景：負責處理第一線客訴的產品經理；與工程師交接前。
• 具體步驟：
  1. 設定 20 分鐘計時器。
  2. 請 Claude 尋找觸發該 Bug 的程式碼路徑、邊界條件與可能假設。
  3. 整理包含「用戶症狀、關聯檔案、PM 假設」的交接報告。
  4. 時間一到，不論是否找到確切 Root Cause，立即將報告移交工程師。
• 可衡量的成果：Bug 移交報告 100% 包含程式碼路徑線索，且 PM單次除錯調查時間絕不超過 20 分鐘。
• 失敗補救機制：若 20 分鐘內連邊緣都摸不到，在報告中寫明「代碼邏輯過於複雜/ 需 Production 權限，PM 無法判定，請工程師協助」，果斷放手。

4. 控制預算與品質：清縮查三把斧

• 行動目標：防止超長對話導致 AI 產生幻覺（遺忘脈絡），並有效控制 API預算消耗。
• 記憶鉤子：「清、縮、查 三把斧」——換題用 /clear、太長用/compact、隨時看 /cost。
• 故事或例子：資深 PM陳經理在追查一個複雜的競品分析時，開啟了無數個對話與檔案，結果發現 Claude越來越笨，甚至開始亂編功能，月底 API帳單還爆表。他開始養成習慣：切換任務用清空，對話過長用壓縮，並時常確認花費。從此回覆變聰明了，成本也穩定控制在每月 $50 內。
• 觸發情境：發現 AI回覆變慢、開始鬼打牆、忘記之前的約定，或準備切換完全不同的任務時。
• 對象與場景：頻繁使用 Claude Code 進行長篇分析的 PM；使用 API計費機制的用戶。
• 具體步驟：
  1. 查：每完成一個小段落，輸入 /cost 檢查花費與 Context 水位。
  2. 縮：當 Context 累積過高但仍需原主題脈絡時，輸入 /compact 壓縮記憶。
  3. 清：進入下一個完全不同的任務前，必定執行 /clear 獲得乾淨白板。
• 可衡量的成果：每月 API 成本穩定控制在預算內，且不再出現 AI 將 A功能邏輯誤套用在 B 功能上的幻覺。
• 失敗補救機制：若不小心清空（/clear）了還需要的資訊，由於 Claude Code無法復原，平時應要求 Claude「將每個階段性結論隨時存成 Markdown檔」，即可隨時把實體檔案讀回來。

5. 拒絕重複勞動：事不過三建 Skill

• 行動目標：將重複性的 PM任務自動化，把個人大腦的「隱性知識」轉化為「可執行的代碼技能」。
• 記憶鉤子：「事不過三，建 Skill」——做第三次就該寫成腳本。
• 故事或例子：運營 PM 小張每個月都要手動匯出 NPS，再請 AI整理成報告。每次提示詞格式都不太一樣，老闆看得很痛苦。後來他花一小時把這個流程寫成 feedback-synthesizer 技能 (SKILL.md)。現在每月只需打一行指令，10分鐘內自動產出格式一致的完美分析，省下無數微調時間。
• 觸發情境：同一個下指令的流程/任務，你已經手動重複執行了 2 次，準備執行第3 次時。
• 對象與場景：處理例行性報告（如競品分析、用戶回饋分析、Release Notes）的PM。
• 具體步驟：
  1. 在 .claude/skills/ 建立專屬技能資料夾與 SKILL.md。
  2. 定義 YAML 檔頭的 Trigger Keywords（讓 AI 能自動辨識調用）。
  3. 寫下清晰的 Purpose、Process (步驟步驟) 與明確的 Output Format（輸出模板）。
  4. 放入測試資料運行，微調後 Commit 進入版控。
• 可衡量的成果：建置 3 個核心 PM 技能（如客訴分析、Release Notes），每次例行公事執行時間從 45 分鐘降至 10 分鐘以內。
• 失敗補救機制：若 Skill產出常常不如預期或格式跑掉，不直接丟棄，而是將錯誤情況補充進 SKILL.md 的 Edge Cases 或 Quality Criteria 段落持續迭代。

6. 文件代碼化：PRD 與程式碼同居

• 行動目標：解決產品文件與實際開發脫節的問題，讓文件隨程式碼一同進化。
• 記憶鉤子：「PRD 與程式碼同居」——把文件搬進 Repo，消滅版本落差。
• 故事或例子：以前 PM 王大明的 PRD 都放在 Google Doc，工程師改了邏輯後，PRD就成了沒人看的廢紙，新人永遠搞錯規格。後來他推動「Docs-as-Code」，把 PRD 變成Repo 裡的 .md 檔。現在只要工程師發 PR，他就會順手用 Claude Code自動比對並更新文件，確保文件與程式碼永遠同步。
• 觸發情境：功能準備進入開發、或工程師合併程式碼準備發布 (Release) 時。
• 對象與場景：負責撰寫產品規格與 Release notes 的 PM；專案版控庫。
• 具體步驟：
  1. 在專案 Repo 中建立 docs/prds/ 目錄，將所有需求檔改為 Markdown 儲存。
  2. 使用 Claude Code 根據訪談與架構上下文產出初步 PRD。
  3. 開發完成或每季初，請 Claude Code 執行文件審計 (Documentation Audit)，比對現有 .md 與實際程式碼的差異。
  4. 根據 AI 列出的差異清單同步更新 PRD。
• 可衡量的成果：產品核心文件 100% 存在於版本控制中，且能隨時用 Git Blame追蹤規格變更歷史。
• 失敗補救機制：若工程師忘記同步更新文件就 Merge，在每季的 Sprint規劃時排入常規的「文件審計任務」，讓 Claude Code 當作自動抓漏的防護網。

整體執行建議

搭配方式：建議採取「心智與工具對齊」+「流程自動化」雙軌制。先將三問法則與架構快照法變成日常直覺，建立信心後，再將高頻率的工作導入事不過三建 Skill與PRD與程式碼同居，將個人生產力系統化為團隊資產。

• 執行週期：
  • 每日/每週：執行二十分鐘停損線與清縮查三把斧。
  • 每月/每季：進行 Skill 審核優化、執行文件審計 (Documentation Audit)。
• 防棄機制：
  • 預設安全鎖：在設定檔將預設模式改為plan，消除「怕把程式碼改壞」的心理障礙。
  • 團隊共建：將寫好的 SKILL.md 與 CLAUDE.md 放入 Git Repo與工程師共享，透過團隊依賴性來逼迫自己持續維護文件。

記憶卡片總表