minw logo

AI 與產品：2026 Q1

#sharing#AI

Previous Review: AI 與產品：我的產品工作流程

誠如前篇紀錄所言，AI 日新月異、場景流程也持續迭代中，之前看到的版本在一個季度後調整許多，所以現在看到的版本謹代表 2026.04 此時此刻的作法，有可能明天又大改，再也不一樣。

AI 摸索現況

流程中使用的工具是 Heptabase + Claude Code（少量搭配 Cursor）+ Claude + Notion。相比上一季，這一季主要流水線化了 Feature Request 的處理流程。

  • 我開始會用 AI 來探索問題在哪裡：現在我花更多時間 Shadowing & 訪談，以及打造 Prototype 直接測試，跟打造 Prototype 直接測試，而 AI 過去只做文獻索引，現在讓 AI 探索跟分析數據。

  • 我還是不會用 AI 來想解決方案初稿，但可以質詢：之前說的 PRD 依舊自行撰寫，但當解決方向有大框架時，可以用 AI 質問跟討論

產品工作流程

工作流程與上次相同，差異在於需要投入更多時間協調利害關係人導入，更多系統以外的事情需要處理，所以有很大的需求要自動化某些瑣碎的日常投入。

探索需求

在產品開發過程中，我習慣快速閱讀所有能閱讀的東西，但開始花更多時間在現場而非文件，文獻資料則大量透過 Heptabase 來摘要 e.g. 200 多頁的教育訓練手冊，透過分卡與 AI Chat 討論來閱讀。

近期多了更多數據需求，所以可以透過 Claude + SQL MCP 串接 Replica DB 設定 read only 權限，來探索跟分析數據。選擇 Claude 只是因為視覺化的結果很易讀。

在探索數據的過程中，特別留意的是對數據分析結果的交叉詰問 e.g. 如果要知道波動多大，除了標準差外也要看四分位圖，透過不同的視覺化來交叉比對是否分析合理。

分解與定義問題

AI 一樣幫不太上忙，但可以在提出第一版問題定義後，透過 Claude grill-me skill 來詰問，一個 PRD 草稿經過來回提問後再繼續精修，現在比較習慣的流程是 Heptabase MCP 將初版送到 Claude Code 進行，但要怎麼讀取文件中的圖片還是個問題。

可行性驗證與規格制訂

大的全新功能

這一段一樣將精修完的 PRD 放上 Notion 後，現在不會用 AI 來寫 PRD 細節，而是透過 Domain Story 整理完後，讓 AI 來分卡，分卡後再調整卡片內的敘述，再讓 AI 根據 Ticket 的撰寫流程來寫 Ticket。

而大的全新功能，不會依據 Ticket 來開發 Prototype，在釐清過程中，透過問答方式開發，同時探索自己對解決方案的想像，完成後提供給利害關係人測試。最終將 Prototype 放在原前端 Repo 中，一併交付給工程師。

相比於憑空的一個 html prototype，在 repo 中打造 Prototype 可以引用公司既有的元件庫，也讓 Agent 更容易參考原本的開發風格，交付工程師上手會更順利。

小的增補功能

現在流程是 Notion 中開一個 Database 追蹤所有 Feature Request，並設定 Zapier 同步到 Jira 中。Notion 是告示用的、Jira 是實際執行用。

這些 Jira Ticket 會依據顆粒度，手動標記 Agent Work 的 Label，有標代表顆粒度足夠小，只要 AI 來回 Refine 就可以了。而每隔一段時間定期透過自定義的 Claude Code command 將標有此 Label 的 Ticket 抓下來，比對哪些還未在 local 資料夾中建立 ticket 文件，並建立初版需求的 v1 文件在 local，接著啟用 Refine 流程：

  1. 第一階段：先釐清需求不清楚的段落。

  2. 第二階段：從 QA, Customer Success, Sr PM, UI/UX, Engineer 五個角度再提出更多不清楚的問題。

Refine 後會產生 v2 文件在相同資料夾中，當來回問答完成後，就會將產生出來的 Ticket 細節自動推上 Jira Comment。詳細可參考下圖的檔案結構：

/project 
  ../api_repo 
  ../web_repo
  ../worktree_repo
  ../tmp
    ../../{ticket no}_{ticket title}
    ../../{ticket no}_{ticket title}_{version no}.md

特別留意的是，在 Refine 的過程中，可以在 command 特別指定要使用 AskUserQuestion，以及強化 ASCII Wireframe 的表達形式，讓 Agent 能知道要使用哪一個元件。

透過這個流水線，每週會找一到兩個時段一口氣清完所有 Feature Request 的規格，最終再標記優先序。

運行產品開發

實測下來，需要來回釐清需求的 Ticket 與可以一次修正完畢的，在標記上可能還是要分開，大概只有一半的 Refine 流水線可以被 One Shot 修正。下一季會繼續攻克的是驗收，如何驗收自動化是還在努力的方向。

現行 Ticket 後續接續的是 OpenSpec 跑 SDD 流程，工程師收到 Ticket 後，可略過前期需求問答，直接執行 Plan，並將 Plan 文件留在 Repo 中進行開發。

選擇 OpenSpec 是因為比 Spec Kit 輕量許多，更適合我們已經有系統在跑的情境。

下一步：需求作為開發瓶頸

從大家每次報告的形式就看得出來（笑），AI 能在產品開發流程上做到的，每一季都在劇烈變化，現階段的瓶頸，確實是規格產出遠遠跟不上開發進化的速度。

但具體而言是哪裡跟不上：

  1. 需求方向有、解決方案有，但大量規格細節缺失: 落地總是有領域知識、UI、系統上的 Corner Case 等等。如果是系統細節，現在 Ticket 流水線算是初步解決了問題；但領域知識，像是法規、SOP 如果有文件還好一點，但更多是藏在現場的隱性知識，這一塊挖掘時間上的減少還是有限。

  2. 需求方向有，但解決方案未定：大至作業流程的變動、小至產品互動的設計，怎麼做才能解決使用者的問題？現在可以自行做 Prototype 給使用者測試，加速實驗方向，但時間不可控。

  3. 需求方向都還沒有：這一段一樣，AI 加速了研究速度，但找到答案的時間依舊不可控。

除了 1 是已知的未知，2 跟 3 都還是未知的未知，而怎麼加速消除未知，是下一季度想要嘗試的方向。

AI 成本

AI 已經變成每月固定成本了，也記錄一下 AI 花費：

  • Claude Code Max 5x：主力

  • Heptabase Premium：主力

  • Chat GPT Plus：個人用，練習英文口說用。

  • Google One：個人用，主要用 Google Drive & 相簿，但加減玩一下 Gemini。

返回上一頁