@kongge_space 的實作展示了一條很有說服力的產品工作鏈：從介面調研、競品與問卷出發，接著產生原型與 PRD，先讓多個角色預審，再補上埋點、QA 與驗收 SQL，最後交付成同事可打開討論的網站。
原文將這套方法稱為「21 個 Skill，用 Codex 做產品經理全流程工作」。它的真正啟發不是把產品經理濃縮成 21 個 Prompt，而是把原本散落在瀏覽器、文件、原型工具、試算表與會議裡的工作，接成一條有中間產物的鏈。
不過，鏈路能跑，不表示需求已被證明正確。原文 demo 中的「3 個阻斷項、7 個問題」與「15 個埋點事件」都是單次執行結果；AI 產生的審查意見是待查問題，不是正式批准。把這條界線留住，才能讓 Agent 加速工作，而不是更快地把錯誤推到下一站。
原文其實已經給出六個 artifact
作者使用的 pm-skills 專案列出 21 個 Skill；其中 pm-url2proto、pm-prd-writer、pm-review-board、pm-tracking-spec-writer 的名稱剛好對應一條產品鏈上的幾個轉換點。這些名稱本身不保證產出可用，但讓每個階段能有更清楚的輸入與輸出。
| 階段 | 可交付 artifact | 不能省略的 gate | 不通過時怎麼辦 |
|---|---|---|---|
| 調研 | 問題、來源、受訪／競品證據與未確認假設 | 每一項結論能指回來源 | 缺證據就標為假設，不寫進需求 |
| 原型 | 可操作畫面與主要流程 | 目標使用者能完成關鍵任務 | 回到流程與資訊架構，不只微調樣式 |
| PRD | 目標、範圍、角色、例外與非功能需求 | 團隊能說出「不做什麼」 | 縮小範圍或補足決策 |
| 預審 | 依角色分類的問題與阻斷項 | 每一項都有 owner、證據與處置 | 保留為未解風險，不能被模型自動結案 |
| 埋點 | 事件、欄位、觸發時機、QA 與驗收查詢 | 實作後可從真實事件驗證 | 回到需求與流程，修正事件模型 |
| 交付 | 可分享的原型／文件入口 | 讀者拿到同一版本與下一步 | 回到缺少的 artifact，而非再生一份摘要 |
這張表刻意不放「選一個更強的模型」。因為這些失敗大多是 artifact 沒有 owner、來源、完成條件或下一步，不是文句寫得不夠流暢。
先做一條線，不要先做一個「產品經理 Agent」
把所有產品工作塞進單一總控 Agent，最容易得到兩種假進度：看起來完整的長文件，和看起來熱鬧的多角色對話。它們都不必然能回答最基本的問題：誰會依據哪份證據，批准哪一個選擇？
更小、也更可靠的起點，是選一個真實需求，只跑下面這一條線：
來源與假設 → 可點的關鍵流程 → 範圍清楚的 PRD → 可指派的風險清單 → 一組可驗證事件每次 handoff 都要求四個欄位：
- 輸入引用：這一步讀了哪些來源、上一版 artifact 和限制？
- 輸出契約：下一位需要什麼格式、粒度與版本？
- 驗收條件：什麼觀察結果會讓它通過，誰能拒絕？
- 停止原因：資料不足、等待決策、風險未解，還是已完成？
例如，原型不該只收到「做一個好看的頁面」。它至少要知道要驗證的任務、不可變更的限制、要展示的狀態，以及由誰確認。PRD 也不該只收到原型網址；它要能指向研究來源與未確認假設。這些欄位很樸素，卻把後續的 AI 產出從「又一份文字」變成可追溯的工作項目。
多角色預審是提早找洞，不是替你簽核
原文用 pm-review-board 讓產品、設計、前端、後端、測試與業務先提出意見。這是合理的低成本壓力測試：不同角色的問題被提前攤在桌面上，比在開發尾端才第一次看到容易處理。
但角色名稱不會帶來權限或真實世界的責任。模型模擬「後端」並不知道目前服務的容量、資料保留政策或依賴系統；模型模擬「業務」也拿不到尚未做的訪談。審查結果最好長成一份 issue list，而不是一句「通過」：
| 欄位 | 例子 |
|---|---|
| 問題 | 免費方案達到上限時，匯出是否仍可使用？ |
| 提出角色 | 客服／後端 |
| 證據 | 目前方案文件缺少例外流程 |
| 風險 | 使用者資料處理與客服承諾不一致 |
| Owner | 產品負責人 |
| 處置 | 補決策、加測試，或明確不支援 |
| 狀態 | open／accepted risk／resolved |
這個格式讓 AI 擅長的「找可能遺漏」保留價值，也不會偽造一個不存在的正式審查。要進入開發、接觸個資、改動價格或發布正式環境，仍應由真正持有責任與權限的人批准。
把埋點放在最後，卻不要最後才想
原文在流程末端才用 pm-tracking-spec-writer 產生事件、欄位字典、QA 清單與驗收 SQL。交付物放在最後是對的：事件命名要依賴已確認的畫面、狀態與例外流程。
但量測問題必須在需求階段先存在。否則埋點就會退化成「把所有點擊都記下來」，卻無法回答需求是否成功。最小寫法是先在 PRD 裡放三句話：
決策：使用者可在首次建立後完成一次有效設定。
成功訊號：完成設定且未在同一流程中發生回退。
反證：設定被儲存但下一步無法使用，或使用者立即撤銷。等流程穩定後，再定義真正需要的事件、屬性與 QA。事件的驗收也不該只看 schema 合法：要在測試或 staging 的真實路徑上觸發一次，再用查詢確認事件、欄位值、重複與漏送是否符合定義。
「能打開」是交付開始，不是發布完成
原文最後把原型、PRD、預審、埋點與問卷收進可分享網站。這個決定很實用，因為討論需要一個共同入口，而不是五個附件和一串過期連結。
不過可分享網站仍要通過自己的 gate。OpenAI 的 Sites 文件把本地 preview、production build 與 hosting 分開；可在自己電腦看到的頁面，並不表示同事有權看到、所有連結有效、資料沒有外洩，或部署已成功。交付前至少逐項確認：
- 分享範圍符合內容敏感度，沒有把訪談原文、個資或內部資料一起公開；
- 入口指向的 artifact 是同一版本，且未解風險仍可見；
- 能回到來源、PRD 與 issue list，而非只剩漂亮截圖；
- 部署與存取測試確實跑過，未把生成紀錄當成通過證據。
Codex 可以執行測試、保留終端輸出與 test result，但 OpenAI 仍要求整合前進行人工 review 與驗證。這不是多一道儀式，而是把「Agent 說完成」轉成能被團隊獨立拒絕或接受的證據。
何時才值得增加更多 Skill
先跑過一條小流程，再看瓶頸在哪裡：
- 問題總出在研究品質，才加來源檢查或訪談設計；
- handoff 常缺例外流程，才加 PRD 的固定 rubric；
- 風險總在跨角色會議才浮現，才保留預審板；
- 指標常在上線後才發現無法回答，才加埋點規格與 QA；
- 只有當輸入、輸出與驗收都穩定，才有理由把這一步固化為 Skill。
這也延續本站先前對 AI Skills 可攜性的結論：可重用的核心不是一個 .md 檔，而是可執行的工作契約。Skill 可以幫忙把契約叫出來、套上既有格式；資料來源、正式決策、權限與驗收仍屬於 workflow 本身。
結語：產品流程的單位，是可被拒絕的產出
21 個 Skill 可以讓一個人更快地把調研、原型、PRD、預審與埋點串起來。真正值得複用的不是「產品經理 Agent」這個標籤，而是每次 handoff 都留下了什麼證據、誰可以拒絕，以及不通過時回到哪一站。
先把一條需求跑成有來源、有 gate、有 owner 的 artifact pipeline；等重複的 handoff 已被證明值得自動化，再新增下一個 Skill。這樣 Agent 不只幫你更快產生內容，也幫團隊更早發現什麼還不能進下一步。