Hub 達人實戰

達人實戰 · 產品與營運

PM 達人：不用學程式，訪談、spec、工單收進一個視窗

PM 不是工程師，但你手上握著最直接的判斷力——什麼該做、為什麼做。這章不談「學程式」，而是看 Dennis Yang、Marcus Moretti、Teresa Torres 這些真實案例，怎麼把 spec、訪談、工單全部收進一個終端機視窗，回饋週期從「週」壓成「分鐘」。

這行的痛點

PM 的日常有一半在「等」——等工程師排期看原型、等人工彙整十份訪談逐字稿、等自己手動把 PRD 拆成一張張工單。這些工作有共同結構：讀一堆文字、抓重點、產出另一種格式的文字。這正好是 CLI 型 AI 最擅長的事，而且大多不需要真的碰到 production 程式碼。

更關鍵的是「原型即溝通」這件事。Anthropic 內部 PM 團隊乾脆把「demo」當成主要溝通工具，用能跑的東西取代文件和站立會議——Claude Code on Desktop、AskUserQuestion、todo list 這些後來變熱門的功能，最早都只是內部 PM 隨手做出來的「side quest」原型。當 spec 寫得模糊，原型會直接露出破綻，比開三次會議挑邏輯漏洞快得多。

PM 工作另一個痛點是資料和工具太分散——分析報表在一套系統、工單在 Jira/Linear、回饋在 Slack、研究筆記在 Notion。Spiral GM Marcus Moretti 的做法是把這些全部收進同一個終端機對話裡，用他自己的話說：「The conversation is the work」（對話本身就是工作）。

但也要說清楚：這不是取代工程師，也不是讓 PM 變全端。原型能到 80% 完成度已經很值得，最後 20% 的 edge case、資料模型、微互動，仍然需要工程師收尾——這條界線在後面每個場景都會反覆出現。

動手前的準備

  • 完全沒摸過終端機：先看 Claude Code 教學第 1 章「踏出第一步：打開終端機」，用不到十分鐘。
  • 還沒裝 Claude Code：先看第 2 章「安裝 Claude Code」。
  • 想先搞懂 CLAUDE.md 這個「專案記憶」怎麼運作（後面工作流大量依賴它）：先看第 5 章「CLAUDE.md 與工作記憶」。
  • 場景三要接 Linear/Jira，需要那個平台的帳號與 API key（Linear 從 Settings > API 取得），建議先看第 9 章「連接工具 MCP」。
  • 場景二的平行 agent 是 Claude Code 內建能力，不用額外安裝，但先看第 10 章「多代理自動化」會更有概念。
  • 對 Codex CLI 陌生：先看 Codex CLI 教學第 2 章「安裝 Codex CLI」與第 5 章「AGENTS.md 與專案記憶」，觀念上跟 Claude Code 的 CLAUDE.md 幾乎一一對應。
  • 不用先學寫程式，但需要對自家產品的程式碼儲存庫有讀取權限——多數場景都是「唯讀探索」或「產出文字」，不會真的動到 production 程式碼。

場景一：PRD 秒變可跑原型

PM 寫完 spec，過去要等工程師排進 sprint 才能看到東西長什麼樣子，回饋週期以「週」計。Chime 的 PM Dennis Yang 把這個流程倒過來：spec 寫完先讓 Claude Code 生一個能跑的原型，再拿去跟團隊開會，他自己的說法是「每天都這樣用」，單一個 session 大約 20 分鐘就能從 spec 拿到可以點、可以看的原型。Anthropic 內部 PM 團隊把同一招用得更狠——他們乾脆把「Claude Code 建不建得出你的 spec」當成 spec 品質的驗收標準。負責 Claude Code 產品的 Cat Wu 講得很直白：「寫完 spec 就丟給 Claude Code，看它建不建得出來」——spec 裡任何模糊的地方，原型會直接露餡，不用等工程師開發到一半才發現規格沒寫清楚。

Claude Code 怎麼做

  1. 先建立獨立分支或 prototypes/<feature>/ 資料夾，只放 PRD、假資料與可公開素材

  2. 在這個原型資料夾開終端機，輸入 claude 啟動；不要在既有產品程式、API、資料庫或部署設定上直接試做

  3. 給出明確的 prompt，先釐清需求後只在隔離原型裡動手：

    claude
> Read @prd.md. First list ambiguous requirements. Then build an interactive prototype only in prototypes/<feature>/ using mock data. Do not modify existing product code, APIs, databases, or deployment settings.

  4. 大約 20 分鐘內會拿到一個可以互動的原型，錄螢幕分享給團隊收回饋，取代開會念文件。

換成 Codex CLI

OpenAI 國際成長 PM Abi 走的是更激進的路線：她已經不寫傳統 PRD，直接交原型。做法是先問 Codex「我們做過最像的東西是什麼」，讓它先參考公司既有的 GitHub 程式碼再動手，蓋到大概 80% 完成度，再附一份 FAQ 式的「companion doc」讓工程師收尾最後一小段。Codex 也能直接在 App 裡顯示 preview，不用另外開瀏覽器。

場景二：10場訪談5分鐘彙整

PM 跑完一輪使用者研究，手上十份逐字稿，人工彙整通常要花一整天——builder.io 的說法是「過去要一整天的彙整，現在幾分鐘做完」。Carl Vellotti 的免費課程（ccforpms.com）教了更進一步的做法：不是一份一份餵給 Claude 讀，而是一次啟動十個平行 agent，一人對一份逐字稿同時處理，原本 50 分鐘的工作量壓縮到 5 分鐘。只處理已取得研究同意、去識別化且符合公司資料政策的逐字稿；先做單一檔案的唯讀試跑，再決定是否平行處理。主題與引句是研究線索，不是統計結論。

Claude Code 怎麼做

  1. 把十份逐字稿（markdown 或 txt 都行）全部丟進同一個專案資料夾

  2. 基本版本，直接請它讀全部逐字稿抓主題：

    > Extract common themes, pain points, and opportunity areas from these 10 interview transcripts

  3. 進階版本（Carl Vellotti 課程教法），明確要求它平行處理：

    > Launch 10 parallel agents to process 10 meetings simultaneously

  4. 輸出建議結構化成 Markdown：主題、出現頻率、代表性引句，可以直接複製貼進 roadmap 文件。

換成 Codex CLI

codexforpms.com 的課程同樣教「讀你的研究資料、橫跨多份檔案分析」與平行批次處理，理論上用多執行緒 task 或 codex exec 批次跑可以做到類似效果。不過目前找不到 PM 圈公開分享「10 個 agent 對 10 場訪談」這種一比一具體示範，如果你在 Codex 上這樣做，等於是自己先探一次路。

場景三：PRD一鍵拆成工單

PRD 寫完要拆成一張張工單——填描述、標籤、驗收條件、估點——是 PM 每週固定的苦工。Product Growth 電子報作者 Aakash Gupta 與 Carl Vellotti 示範過：從一份 PRD 結構直接生出 19 張含優先級與驗收條件的 Linear 工單。Spiral GM Marcus Moretti 的版本更誇張——請 Claude 讀 roadmap（存在 GitHub README 裡）加上程式碼儲存庫，幾分鐘生出約 100 張含策略脈絡、驗收條件、技術備註的 GitHub Issues。

Claude Code 怎麼做

  1. 安裝 Linear MCP（Jira 同理，換成對應 MCP server）：

    claude mcp add linear -- npx -y @mseep/linear-mcp

    （API key 從 Linear Settings > API 取得；團隊共用就把設定放進專案根目錄的 .mcp.json，每人填自己的 key）

  2. 先驗證連線：

    > List my open issues

  3. 接上後直接請它把 PRD 拆成工單：

    > Connect to Linear and generate tickets from this PRD structure, with description, labels, priority, and acceptance criteria

  4. 反過來也通——PRD 可以直接從 Linear 拉工單目前的狀態，工程師開工之後 PRD 自動跟著更新。

換成 Codex CLI

這裡要老實講：Codex 生態同樣走 MCP（用 codex mcp add 接），但 PM 場景把 PRD 轉工單的公開實測案例明顯比 Claude Code 少。OpenAI 官方比較偏推的是 GitHub 整合路線——在 PR 或 issue 留言 tag @codex 讓它接手，而不是這種「MCP 直連 Linear/Jira 產出 19 張工單」的具體示範。想在 Codex CLI 上做同樣的事，能力上應該做得到，但你會是相對少數先探這條路的人。

場景四：週報與儀表板自動更新

每週五花一小時，把散落的筆記、回饋、交付物收攏成一份週報，是 Enterpret 部落格點名的固定耗時任務。他們的做法是建一個自訂 slash command /pulse，掃描專案資料夾裡過去一週的筆記、回饋、交付物，直接生成乾淨的摘要——搭配寫好的 CLAUDE.md（放角色/產品線、優先排序框架如 RICE、研究方法如 JTBD、團隊慣例），起手只要 3–10 行就夠用。

在這件事上，Codex CLI 反而是案例最紮實的一邊。OpenAI 國際成長 PM Abi 的週報自動化更完整：Codex 從 Slack、Google Drive、Notion、內部儀表板拉資料，草擬給 stakeholder 看的週報，發送前她自己先過一遍再送出。她還加碼兩個日常自動化：每天早上生成一份「未讀優先訊息＋待回覆」的 Slack 收件匣摘要（前提是先告訴它哪些人、哪類訊息算重要，例如 evals、blocker、新學到的事）；以及把分散在 7–8 個 Databricks/Tableau 儀表板的國際成長資料，每天早上 9 點自動彙整成一份統一格式的儀表板（指定好國家分頁、頭條資料、強弱項標示），用 Playwright 驗證畫面正確。

Claude Code 怎麼做

  1. 在 CLAUDE.md 寫進你的角色、產品線、優先排序框架（如 RICE）、研究方法（如 JTBD）、團隊慣例——3–10 行起手就夠用

  2. 建自訂 slash command /pulse，內容是「掃描本週資料夾裡的筆記/回饋/交付物，生成一份摘要」

  3. 每週五執行一次：

    > /pulse

判斷什麼時候該把某段脈絡固化成 Skill 而不是每次重打，Enterpret 給的判準很實用：「同一段脈絡在三個不同對話解釋過三次，就該進 Claude Code 變成 Skill」。

換成 Codex CLI

這是少數 Codex CLI 案例比 Claude Code 更完整的場景。Abi 的做法把 Slack、Google Drive、Notion、多個儀表板一次串起來，草擬週報、triage 收件匣、自動更新統一儀表板都排進每天固定時段跑，人只在發送前做最後把關。如果你的週報素材本來就散落在這幾個工具，Codex 這條路值得優先參考。

常踩的坑

四個常踩的坑

  • MCP 連線不穩，要有心理準備重新驗證——builder.io 明文提到 MCP server 常斷線、需要重新授權，這是設定與維護會反覆發生的摩擦，不是一次接上就永遠沒事（來源：達人實測回報）。
  • 裝別人做好的 skill 前先讀內容——從 GitHub、Twitter 下載的第三方 skill 有 prompt injection 風險，尤其搭配「跳過權限」模式（dangerously skip permissions）一起用時風險更高（來源：Aakash Gupta 電子報明文警告）。
  • 原型只有 80%，最後 20% 不能省——Marcus Moretti 實測發現 Claude 在資料模型、微互動、edge case 上偏弱，容易想像出理想化的使用者行為；Anthropic 官方也把「spec 模糊處讓原型露餡」當成正常現象。最後一段沒有工程師收尾就直接上線，是最常見的事故源頭（來源：達人實測 + 官方口徑一致）。
  • 資料查詢 prompt 要夠具體——Enterpret 部落格與 OpenAI PM Abi 的案例都提到，資料來源一多（例如同時接 7–8 個儀表板），模糊的查詢像「weekly active user growth」會產出「聽起來都合理、但都不一定對」的解讀，查詢時要講清楚指標定義與時間範圍（來源：達人實測）。

延伸資源