ClearForge
重點：AI 取代不了 PO/BA，但能補強「需求分析完成、進開發前」那段灰色地帶——讓需求不在交付時才失真。
這半年，我開始有意識地把 AI 拉進「日常產品開發流程」。
不是拿來寫幾段程式碼，也不是當搜尋引擎，而是嘗試把它放進那些原本就存在、但長期卡關的工作節點裡。
一開始其實很保守
我並不認為「寫幾段 prompt」就能解決所有事情。尤其在真實的產品開發現場——需求模糊、規格反覆、跨角色溝通成本高——這些問題本來就需要流程、角色與經驗一起處理，而不是靠單一技術單點突破。
但隨著實際用在工作裡，我慢慢意識到一件事：
AI 真正改變的，不是你「多會用它」，而是你怎麼重新看待一個工作流程。
產品開發最耗能的，往往不是 coding
回頭看，最耗能的是那兩段灰色地帶：
- 還沒開始寫 code 之前
- 寫完 code 之後
其中一段常被低估、卻非常關鍵的階段是——需求已經分析完成，但還沒正式進入開發之前。
在需求分析這一段，我一直傾向用「實例化需求」
意思不是把需求寫得更長，而是盡可能用具體的情境與例子，讓團隊可以清楚知道：
- 什麼情況下會發生
- 系統預期怎麼回應
- 哪些情境是刻意不支援的
這樣的需求，重點不是描述得多漂亮，也不只是為了讓「對錯」可以被驗證。
實例化需求更重要的目的，是在進入開發之前，先幫團隊建立對需求的共識。 當大家對「要做什麼、不做什麼」有一致理解，後面的溝通成本、誤解與重工，才有機會真正被壓下來。
但真正的挑戰，往往不是「有沒有實例」
而是——不同人寫出來的實例，品質落差其實很大。
即使格式一樣，有人寫的是可直接拿來討論與落實的情境，也有人寫的比較像「腦中想法的轉述」。這在需求量小的時候影響不大，但一旦進入多人協作，或需求需要長期維護，問題就會開始累積。
當需求要真正交付給團隊，中間有很多瑣碎、但不能出錯的事
例如：
- 在 Jira 建立正確的 ticket 與關聯關係
- 確保需求文件、描述與附件是最新版本
- 把關鍵的邊界條件與假設寫清楚，而不是只存在腦中
- 在 GitLab 建立對應的 MR，或標示後續開發的切入點
這些事情單看都不難，但只要漏了其中一環，後面就很容易開始補說明、補文件、補理解，最後變成反覆溝通與返工。
真正的問題不是「有沒有做」，而是每個人的「交付門檻」不一致
我以前也以為這一段只是「細心一點就好」的行政工作。但實際帶過幾輪團隊後才發現：每個人心中，對「做到什麼程度才算可以交付」並不一致。
AI 在這一段扮演的角色：交付前的品質檢查與對齊工具
它不是幫你想需求，而是針對這些已經實例化的需求，協助檢查：
- 情境是否足夠具體、可被理解
- 是否隱含只有作者才知道的前提假設
- 不同實例之間是否存在衝突或重疊
- 描述方式是否前後一致、容易被接手
它幫助的不是速度，而是讓「實例化需求」的品質，在不同人之間可以被拉齊。
實作：我怎麼帶團隊把 AI 接進需求流程
在跟團隊 TL 一開始協作時，他曾經這樣說：
「不就是開 ChatGPT，整理好 prompt 去問不就好了？」
我回他：
「當然，這是一種用法，在某些情境下也確實會有幫助，但這樣做，並沒有真的降低你們在剪剪貼貼上的瑣碎工作。」
我相信大多數在管產品 / 專案 / 需求的 PO / PM / BA / SA，其實都不是工程背景出身。因此你很可能會遇到一個狀況：你知道 AI 能幫忙，卻不太確定該怎麼把它跟原本的工作流程接起來。
一開始就把 AI 的角色講清楚
我其實很刻意沒有讓 AI「負責產出需求」。一開始就先講清楚：
- 業務邏輯，還是人負責
- 需求怎麼取捨，也還是人決定
- AI 不是拿來背鍋的
最需要 AI 介入的是兩個時間點
- 需求已經分析完，準備交付給 RD / QA 進行 refinement 前
- Refinement 完成，準備正式進入開發前
這兩段平常其實很容易被忽略。需求分析結束後，負責需求的成員還會做很多事情：整理 Jira ticket、補文件描述、同步 refinement 後的修正、檢查實例有沒有互相打架、回頭確認是不是有些前提其實只有自己腦中有。這一段如果沒處理好，後面開發一定會一直回來補討論、補確認。
流程沒有變，只是小步驟調整
需求照樣由 PO / BA 自己分析，實例照樣由人寫，或由團隊成員一起補齊。
寫完之後，不是立刻丟出來討論，而是先用 Codex（你要用 Claude Code 也行）跑一次「交付前的自我檢查」。
我目前指導的團隊，需求規格都放在 GitLab，而且都是純文字檔。所以只需要把準備好的 AGENTS.md 放在 repo 指定的位置。寫好的 Gherkin 實例，本來就在 repo 裡，直接請 Codex 依照設定好的指令進行審查與最佳化建議。
換句話說，我是請 AI 站在 RD / QA 的角度，協助驗證這份需求規格現在能不能被接手。
Refinement 完成後的收尾工作，也交給 AI 自動跑
當過完 Refinement 後，需求規格與實例大致上都釐清得差不多了。
接下來 BA 還需要完成一些收尾工作，例如提交 MR、更新 Jira 等等。這些事情本身不難，但非常零碎。這一段我同樣透過事先準備好的指令，讓 Codex 協助自動完成。
AI 回來的，是一份問題清單，不是替你改稿
它不會幫你重寫需求，比較像是在提醒幾件事：
- 這個 Then 到底要怎麼驗證
- 這個 Given 是前置狀態，還是其實是流程的一部分
- 這個 Scenario 裡，是不是藏了一個只有作者自己知道的假設
BA 只需要修關鍵的地方就好，其他不動。
跑一段時間後，BA team 給我的回饋
- Refinement 開會比較不會一直糾結文字
- 原本只有資深 BA 才寫得出的規格品質，開始比較平均
- 瑣碎的動作變少了，更能專注在交付內容
當規格文件的地板被拉高之後，討論的內容真的會不一樣。大家比較少卡在「這句話什麼意思」，也比較少花時間確認基本前提，反而能把注意力放在需求的價值，以及可能的解法上。
一句話總結
AI 比較像一個放大器，而不是替代品。
流程混亂時，它只會更快放大混亂； 流程清楚時，它會幫你把原本容易漏掉的地方補齊。
我現在不太會急著問「AI 能不能幫我做什麼？」，反而會先問自己：
「這個流程裡，哪一段最容易因為人而失真？」
那裡，通常就是 AI 最值得介入的地方。