第三篇繼 AI 與語言學習 跟 寫作 後，今年最後一個大量使用 AI 的領域是我的志業 - 產品工作。寫作中雖然很少提到產品，因為就如寫作之於我有很多糾結，產品工作亦如是，畢竟產品是我謀生、專業跟關懷的展現。但因為這些糾結，在工作方法上我一直沒有什麼記錄可以回溯自己的改變。

所以這篇文是第一次嘗試，試圖拿捏自己在產品工作中的浪漫跟紀錄的平衡，來撰寫這篇文章。

背景

正因產品經理是變異性極大的工作，如果背景稍有不同文章就變得毫無意義，所以在描述對我而言 AI 與產品的關係前，要先聊聊我認為的產品是什麼：

產品是可持續創造價值的系統，具體到買回一個鬧鐘，每天叫你起床，或一台手機他有軟硬體整合的系統與背後的軟體生態系，到讓藝術品得以交易的拍賣會所提供的代理服務，這些都是一種「產品」。其中產品經理，負責發現跟定義價值並實現價值系統。這兩項受產業、商業模式、分工、規模就可以有截然不同的技能樹，甚至即便在上述條件甚至職能都一樣的人，可能也會因產品經理的背景不同，以截然不同的方式，達成一樣的目標。

而產品經理不是什麼？產品經理「終究」不是背負風險的人，這不是指零風險，即便產品經理得要思考的一切跟公司負責人接近，但現實是除非股東，否則不背負財務風險。我認為在「可持續」這個目標下，理解與重視商業風險跟限制無比重要，但理解與真實背負是有不同的，想起早年聽曼報 Podcast 曾說過的：「終究一名員工還是與老闆是不同的。」

以我自己來說，工作經驗中絕大多數要處理的是：

• 在軟體系統或使用者的商業邏輯中，探索跟定義問題，並確認問題價值設定目標。

• 平衡技術、設計、商業與使用者知識，思考解決方案並實驗與評估價值成效。

• 槓桿團隊資源來實現可持續創造價值的系統，並持續跟內、組織、外部使用者對齊，並持續改善產品開發流程。

個人比較熟悉於需求探索跟系統分析、並執行產品設計與開發，以進行產品實驗，但不擅長品牌、行銷跟業務開發。換句話說，我更接近於 Product Builder 而非 Marketing / Sales 導向的環境，而目前公司也處於有明確的產品行銷路線，且足夠多與深的需求變動環境，可以讓我密集的打磨產品打造的工作流程。

如果你也是類似狀態中的產品工作者，下文摸索的結果可以參考看看。

AI 摸索現況

流程中使用的工具是 Heptabase（組織思考）+ Cursor（寫程式） + Notion（整理規格細節）。相比過去，有更多時間可以釋放在探索需求跟分解定義問題，而雖然整個工作大量使用 AI 輔助，但是：

• 我還是不會用 AI 來探索問題在哪裡：我會閱讀「第一手跟文獻資料」，熟悉資料樣貌後，才用 AI 來定位可能我想要的資料在哪裡，並收斂問題點跟影響力。

• 我還是不會用 AI 來想解決方案初稿：我會畫圖、寫一個從需求分析到概念提案的草稿，並進一步再拆解成一個個 UML 跟 Epic & User Story 後，才讓 AI 來補一些可能需要的細節，幫助我跟不同職能核對，也會基於此初稿產生 Prototype。

同樣的，因為 AI 日新月異、場景流程也持續迭代中，所以現在看到的版本謹代表 2025.12 此時此刻的作法，有可能明天又大改，再也不一樣。

產品工作流程

跟寫作同樣的，怎麼摸索 AI 也會跟我產品工作流程息息相關，而現在的工作跑的是 IPD 產品開發 + Scrum，會經歷：探索需求 → 分解與定義問題 → 可行性驗證與規格制訂 → 運行產品開發 → 追蹤成效等階段，且每個轉折點都會因為 IPD 的 TR （Technical Review）機制，有面對不同利害關係人或產品團隊的會報，把控能不能進到下一階段。

現在產品工作中對我來說最重要的是「決策」跟「對齊」，而以下工作流程都是在：「改善決策流程的品質」與「減少對齊所需成本」在努力。

探索需求

浸泡在「所有」資料中，建立對全貌的理解，而 AI 輔助我找到細節。

在產品開發過程中，我習慣快速閱讀「所有」我所能閱讀到的東西：從競品、市場報告、使用者親自的操作、訪談、利害關係人、內部人員的教學文件、過去的規格跟 Ticket、對話紀錄到 DB 每一張 Table 以及現有的程式碼。過程中會有極大量的文件、逐字稿、錄影錄音等，這一階段會浸泡在資料中，保持耐心、建立感受、建立關係跟保持開放。

特別強調所有，是因為我相信系統的全貌，並不全然存放在某個視角中，上述任何一個物件都可以看到系統的一角：

• 競品會有 benchmark

• 市場報告會有趨勢跟大方向

• 程式碼會有精確連使用者有時都不清楚的商業邏輯

• 使用者會有完整的工作流程跟隱性知識

• 利害關係人會有營運、管理等不同視角

• 教學文件會有新人/新使用者的是角

• Table 會有資料流跟統計資料

同時間，也瞭解不可能在真正瞭解全貌的情況下做決策，所以淺而廣的閱讀資料，並為資料建立索引，會是探索階段的關鍵。而 AI 大量輔助我在這個過程中，搜尋跟為資料建立索引，例如：

• 在我對程式碼結構有認識前提下，我會在 Cursor 詢問一段商業邏輯的程式碼哪裡，並透過閱讀原始程式碼來瞭解商業邏輯，這特別適合產品有 Legacy Code 但沒有規格可以參考的情境。

• 我也會在 Heptabase 為每一份訪談逐字稿建立切片的 memo 卡片，並將手冊等文獻資料放在同一個白板，以便我後續詢問我的資料庫說「是不是有使用情境是怎樣怎樣？請幫我確認。」時可以找到原始資料。

上述的過程讓我省去很多過去 trace code 或要問開發人員、重新跟使用者確認的時間，也讓我能更專注在進一步收集釐清的更多第一跟第二手資料。

分解與定義問題

將資料重新組合標註，而 AI 在這一階段不太能幫我什麼。

當資料收集到心中有個模模糊糊的心智模型時，我就會開始在 Heptabase 整理，此時白板會非常亂，無論是：

• 大量現行工作流截圖的排列組合。

• 訪談中關鍵切片的 section grouping。

• 操作手冊分章節的畫線資料跟筆記整理。

• 可能可用的不同產品畫面截圖在其中。

• 市場、技術趨勢等報告的筆記。

這一段很難用結構化的方式說明怎麼進行，但在不停的排列、分組的整理過程中，心中會慢慢浮現出一個對系統的心智模型，會看到：系統槓桿在哪裡、可能可以用什麼方式解決的方向。而當模糊印象出來時，剛好對應到工作流的「會報」，我會以撰寫此會報為前提，將這份解決方案撰寫出來。

操作過程就像是寫作，左側留著白板、右側留著一張卡片，慢慢的寫出第一版解決方案。而大致的組織方式如下：

## Overview
最後總結下面三段寫下摘要。

## Background 
先寫這一段，將現行的流程完整敘述並陳列痛點。

## Proposed Solution
再寫這一段，包含解決方案的使用情境跟 ExcaliDraw Wireframe 截圖。

## Key Result 
預計達成的最終結果與商業目標。

這份解決方案完稿後（可以想像成 PRD alpha 版），會跟組織內外、使用者都同步過對齊驗證有沒有可能的潛在風險、是否符合使用者工作流程。雖然這麼比喻可能有點怪，但我認為這一步跟寫作過程極為類似，在這一段落我不會追求格式，而是盡可能的陳述我心中的背景與產品功能願景，然後跟最在乎的人（好比第一批讀者）確認。

可行性驗證與規格制訂

讓 AI 生出我能理解的細節，並進行審查打造 Prototype。

當對齊完成順利通過 TR 後，會進到準備開發的階段，此階段會再從頭撰寫 PRD，將故事翻譯為產品語言，讓文件成為能夠被團隊討論的內容。

翻譯過程會將上述的提案以 UML 重新陳述，並撰寫 User Stories 跟繪製 Wireframe，同時設定這次專案的 Success Criteria 跟需要追蹤的事件。另一端會繼續深挖資料，將更多商業邏輯細節跟產品規格在 Notion 中整理起來。例如：

## Overview
最後總結下列敘述寫摘要。

## Success Criteria 
說明專案成功指標的計算方式

## Use Cases
描述系統的使用案例

## Epics 
對不同的 Use Case 撰寫更詳細的 Workflow Chart，並進行說明

### User Stories 
拆解 Epic 到 User Stories，並補上可能需要的 State Machine、關鍵 Wireframe的互動說明跟需要追蹤的事件

而直到這裡，我稱為是 PRD beta 版，能夠讓 AI 理解、也可以讓資深開發跟設計者理解的 PRD 版本。但過去此一版本的內容還不夠，因為各個專業角色有自己關注的面向跟語言，以前要不是 PM 繼續補充細節、又或者要資深開發者通靈持續溝通。需要耗費大量時間來換句話說，跟團隊磨合出最終的 PRD Public 版。如今，我會讓 AI 來協助補充各專業領域的可能提案，為的是幫助在交付開發團隊時，有討論基礎：

### User Stories

user stories 敘述、state machine、wireframe、商業邏輯的規格細節與要追蹤的事件

**Accpetance Criteria:**

團隊一起在 Refinement 時撰寫

**Appendix:** 讓 AI 先生一版再刪改後，與團隊一起討論，完全可以大推翻。

- SLA
- Data Model 
- Test Cases
- API Endpoints
- UX Spec
...

請注意，這一版本是為了讓大家有快速討論的基礎，並不是定案的細節。例如：完全可以想見 AI 所設想的資料結構時常 Over Design。但比起從零開始討論，有稍微堪用的一版大家一起討論可以加速許多。

那這份細節是如何產生的呢？目前是在 Cursor 中以 SDD 的形式產生，我定義了一個專門用來產生 Prototype 的專案，設定好習慣的 Constitution & Template。通過將 Beta PRD 放入 Memory 後，再用 Spec Kit 產生細節、逐行 Review Apply，接著以此為基礎開發 Prototype。

雖用了 Spec Kit，但我並沒有落實 SDD。使用 Spec Kit 只是因為他的 template + 憲章機制、clarify 釐清細節跟 tasks 分段的機制很好用，並沒有實測過其他類似工具 e.g. Kiro。而且奠基於 Spec Kit 產生出來，在 Editor 中要 Review 規格或要修改 Prototype 的程式碼都很方便。有時偷懶也會請他直接開 Brower 操作給我看，就不用自己點 Prototype XD

而以上最終從 PRD Public 版 + Prototype，除了拿去給使用者跟利害關係人實驗，另外一面可以在 Refinement 時與工程同步。誠如前述，細節完全是可以推翻、甚至沒有用到的，不過這是良好的溝通基礎，可以對齊不同專業的想像。

運行產品開發

為開發團隊打造一個 AI 友善的環境。

到了產品開發階段執行跟衝刺了，這個階段最重要的任務就是在排除所有會 Block 住開發團隊的事情，例如：

• 以前有大量的設定資料 e.g. Tracking Event 只能透過一份表格提供給工程師，現在可以透過小工具開發一個臨時編輯介面來提供 Raw JSON, YAML 給工程師。

• 可以在規劃上，多保留讓 AI 輔助開發可以順利的技術任務。好比讓產品頁面有定義良好的元件庫、提供給工程師的資料都有 MCP 可供串接。

• 利用前面的 SDD，提供一份可以讓工程師以 AI 輔助開發的方式，產出預期結果的規格。

以前沒有 AI，任何稍微比較複雜的操作都會歸類在開發團隊、其他是 PM，現在這條線 PM 可以更多的來輔助開發團隊，讓工程師專注在解決困難的技術問題。

小結

後續釋出的成效追蹤，目前還用不太到 AI，因為已經很習慣下 SQL 或是寫腳本計算資料，除了少數複雜的視覺化，會同前一步讓 AI 開發視覺化小工具來呈現。除此之外，釋出後有一些我預期用 AI 很方便但還沒有落實成功的有：

• 撰寫使用者看的 Change Log（時常被我拿來當成驗收確認的小文件）

• 產品教學文件（AI 寫不出一個顧客好懂的，還是需要很多圖文輔助）

這些是我希望 AI 可以輔助，但現在還沒有自動化的流程。只能說這一階段的 AI 協作還很陌生，持續研究中。

今年探索了三個面向大量使用 AI 輔助，除了讓我從 AI 冷漠變得對 AI 燃起興趣，同時也因為更明確 AI 在我生活中的定位，讓我從焦慮超 > 興奮的遽增心情，變成焦慮略 < 興奮的狀態。也趁著工具的典範轉移，一個機會重新審視自己的工作方法。