【菜鳥 PM 學習日記】EP 12｜不只是叫 AI 幫忙寫文件：我們如何重新設計 PM 的工作流程
PM AI Workflow 終於試行約一個月啦！分享我們最後建立的「文件撰寫五步驟」，以及這些日子的觀察和心得。
【菜鳥 PM 學習日記】EP 12｜不只是叫 AI 幫忙寫文件：我們如何重新設計 PM 的工作流程
Designed by Lina
之前提到的 PM AI Workflow 專案，我們團隊已經全面試行約一個月了，目前所有新需求也都採用新的 Spec 格式來撰寫文件，開發團隊的 AI Workflow 也慢慢建立起來、跟我們的銜接上。
這段時間真的試行，才發現實際的使用情境、需求還是跟原先想像的有不少出入，因此不斷滾動式修正、逐漸優化成現在比較穩定的版本，團隊成員也習慣了使用 GitLab 來管理所有文件，於是想著整理成文章，跟大家分享這段時間努力打造的 AI Workflow 成果，或許能給其他團隊借鏡！
前言
實際設計整體流程、撰寫 skill 後才發現，這個專案真正困難的部分在於：如何把原本模糊、仰賴個人經驗（甚至因人而異）的流程，拆成一個個清楚的步驟，並定義每一步要由 AI 做什麼、人類又要在哪裡介入確認。
註：skill 就像 AI agent 的「員工 SOP 手冊」（通常是文字檔案），說明在哪些情況下要調用哪些資料、執行哪些動作，AI agent 收到需求後就能讀這份手冊、照步驟執行，藉此確保產出品質。
我們把 PM 整體工作流程拆成兩部分：「文件撰寫」與「設計產出」。
- 文件撰寫：主要包含把模糊需求落地成需求文件、撰寫更細節具體的 Spec 文件，並且處理所有 i18n key 的命名、標註及翻譯。
- 設計產出：主要包含所有示意畫面的繪製、新增元件（Component）的製作與設計稿管理；前陣子開始減少設計師在 UI 設計的支援，目前已改成由 PM 與 AI 協作產出所有設計稿。
這篇文章會著重在我負責的「文件撰寫」的部分，「設計產出」由另一位 PM 負責，因為使用頻率沒那麼高、對開發團隊影響也不大，所以目前處於大家視情況使用、但不特別精雕細琢的自由試用階段！
設計核心概念：如何兼顧彈性、效率、成本與品質？
Photo by Lizzi Sassman on Unsplash
原本對 skill 沒什麼概念的我，以為那就是一份巨大的使用說明文件，只要把所有相關規則塞進去就好。但後來深入研究才發現，如果把所有流程都寫在同一份文件裡，長期下來會遇到幾個問題：
01. 使用彈性不足
當所有步驟被綁在同一個 skill 裡，AI 容易假設流程必須從頭跑到尾。但實際情況是，我們常常只想做其中一段：有時只是要 review 既有 spec、修改某幾個區塊，或是補幾個 i18n key。如果 skill 太大，就會很難根據當下狀態切換流程。
02. 效率可能下降
全部寫成一份巨大的 skill 文件，可能導致 AI 一次載入太多與當前任務無關的規則，它需要在大量指令中判斷現在該做哪件事，反而增加出錯機率；相較之下，如果把流程拆成任務邊界清楚的 skill，可以讓 AI 在每個節點只專注處理當下的任務。
03. Token 成本變高
Anthropic 的 Claude Skill guide 提到，Skills 採用 progressive disclosure：先用 frontmatter（文件開頭的 Skill 簡介）讓 Claude 判斷何時需要載入 skill，只有在相關時才載入完整指令，更多細節也可以放在另一個檔案裡按需求讀取，藉此降低 token 使用量。因此，如果把所有說明都塞在同一份 skill 裡，AI 每次執行小任務時都要消耗很多 token 在讀取不需要的內容，佔用 token 額度。
Photo by Jakub Żerdzicki on Unsplash
於是，我們後來設計流程的核心概念是：
- 把流程拆成多個可以接力組合使用的 skill，每個 skill 只負責一段相對明確的任務
- 前一步驟的輸出成果有固定格式，可以被下一步驟的 skill 精準解析，藉此確保產出品質
- 在關鍵節點加入人類審核步驟，避免 AI 一口氣按照錯誤資訊跑完所有流程、無法及時修正導致 token 消耗過多
另外，像「前期探索」這種高度發散、仰賴個人判斷的階段，目前暫無設計統一的 skill，因為如果把探索流程寫得太線性，反而可能讓 PM 太早收斂、限縮了可能性，而且大家習慣的做法也不同。相較之下，其他規則明確、重複性高、格式固定的任務，就全都被我們整理成不同 skill。
我想，這也是這次設計 PM AI Workflow 時最讓我掙扎的：雖然我們追求的不是「完全自動」，但要兼顧彈性、效率、成本與品質，比想像中要困難得多，因為要納入考量的因素真的太多了！
實際流程：五步驟完成文件撰寫
以下流程所用到的文件，都只列出 skill 相關的部分，為求產出的精準度和穩定性，我們其實還建立了一整個「產品知識資料庫」，把目前產品的邏輯、架構、權限管理、行為模式（UX Pattern）等通用原則，都整理在 GitLab 上讓 AI 能依照需求讀取，以便在足夠脈絡（Context）下執行任務！
文件撰寫五步驟（圖片來源：自行繪製）
STEP 01. 釐清需求
- 使用文件：
requirement-brainstorming/SKILL、business-requirement-template - 主要用途：產出 Business Requirement，用來說明：需求核心概念、主要改動邏輯、產品目標、預期流程，並以這份文件為基礎，先跟開發團隊開會對齊，確認此次規劃方向。
- 關鍵節點：產出 Business Requirement 後，AI 會先停下來讓 PM 確認內容，目前實際使用還是會在這個階段來回修改，可見如果讓 AI 一口氣寫完所有 spec，屆時要修改應該會是個大工程。
這個 skill 也會根據 PM 提供的內容，判斷需求的模糊程度，若過於模糊，就會先透過提問協助 PM 釐清，確認後才產出 Business Requirement。
STEP 02. 盤點範圍
- 使用文件：
story-splitting/SKILL - 主要用途：根據 Business Requirement 判斷會影響哪些頁面，並盤點出所有需要新增、修改的 spec。
- 關鍵節點：盤點影響範圍後，AI 會先停下來讓 PM 確認內容，並根據不同頁面之間的相依性，提供撰寫 / 修改順序的建議。
這個步驟尤其重要，因為我們現在不再每個需求都新增一份獨立 spec，而是要回到對應 URL 的 living spec 裡更新內容。因此在開始寫 spec 前，若無確認這次需求的影響範圍，後面很容易寫錯位置或漏掉連帶影響。
STEP 03. 撰寫文件
- 使用文件：
spec-creation/SKILL（撰寫新增 Spec）、spec-editing/SKILL（修改既有 Spec）、spec-template - 主要用途：如果 Business Requirement 內容不足，會先針對關鍵細節提問讓 PM 釐清才開工，否則就直接根據既有資訊及 Spec 模板撰寫或修改 Spec 內容。
- 關鍵節點：真的真的開始寫之前，AI 還是會先列出撰寫 / 修改的計畫讓 PM 確認內容！
STEP 04. 格式檢查
- 使用文件：
spec-review/SKILL、spec-review-checklist - 主要用途：根據我們列的檢查清單（主要是針對比較明確的格式，如：是否符合模板格式、必要區塊是否缺漏等），列出需要 PM 判斷 / 補充資訊的部分，並且自動修正其他小細節。
我的主管另外自己寫了一個檢查「邏輯、一致性」的 skill，但並不是在這個步驟使用，而是當 PM 把 spec 推上 GitLab 並發 MR 給主管審核時，他會跑一次那個 skill，將結果作為他自己 review 的參考。
STEP 05. i18n 標示
- 使用文件：
i18n-key-mapper/SKILL、i18n-key-list（i18n key & value 總表）、i18n-naming-rule（i18n key 命名規則） - 主要用途：在 spec 上標出所有 i18n key 並編號，若是已經存在的 key，就對應 i18n key & value 總表填上；若是此次新增的 key，則會根據 i18n key 命名規則提案新的 i18n key。一旦 spec 推上 GitLab，就會自動把新增或修改過的 key 更新到 i18n key & value 總表，並產生各國語言翻譯 value，待各國語言夥伴確認後就可以給前端開發使用。
目前我們團隊已經把 Lokalise 的 i18n key & value 全部搬到 GitLab 上管理，並經過一輪整理與重新命名，七月開始停止使用 Lokalise。
之後就不必使用 Lokalise 來管理 i18n 相關資源了（圖片來源：Lokalise）
其他輔助用的小功能
- 自動加入 Mockup：根據 spec 裡的 User story & AC，自動到 Figma 抓相對應設計稿，輸出成圖檔後圈出 User story 描述的區塊並標示 User story 編號、加到 spec 文件裡（方便前端工程師快速了解內容）並且同時放上 GitLab 一起管理。
- 自動發 GitLab MR：根據本次修改的內容，以固定格式撰寫並發出 MR 草稿，讓 PM 省去很多手動撰寫的時間，同時又能確保 MR 描述足夠具體清楚，團隊夥伴看一眼就知道做過哪些改動。
未來還希望可以繼續新增「自動根據 spec 清單建立 Jira Story」、「自動根據 living spec 草擬使用手冊」等不同 skill！
AI Workflow 真的解決所有問題了嗎？
雖然現在所有需求都已經改用新流程，但因為才試行一個月，我們也還在觀察實際成效如何，再加上不斷根據各方回饋滾動式調整，現在我也不敢斷言 AI Workflow 真的幫助我們達成了當初的目標、解決了所有問題，而是需要再繼續在實際使用的過程中觀察：
Photo by Alan Aprilio on Unsplash
01. 產出品質穩定性
因為 skill 和產品知識資料庫都還在頻繁迭代，初期的產出內容還是常出現細節不一致的情況（例如：Spec 模板更新了，但之前產出的 Spec 忘記一起更新），再加上我們把既有 Spec 一口氣轉成新格式，這樣的大工程難免會有疏漏，根據這些 Spec 所產出的新 Spec 也可能繼承到原本的錯誤。
此外，skill 的執行穩定度也是需要再觀察的，例如：story-splitting 是否真能完整盤點出影響範圍？spec-creation / editing 的輸出是否足夠完整清楚？i18n skill 是否能標註出所有 Spec 裡的 i18n key？
02. 人類審核的效率
建立 AI Workflow 的初衷就是希望能節省時間與精力，但現在改為「AI 產出內容、人類審核」的模式後，因為 markdown 格式與當前 spec 寫法不一定好閱讀，PM 是否花更多時間在檢視產出、挑出錯誤？或甚至因為表達不夠清晰，反而花費更多時間在跟 AI 來回溝通？
03. 各方串接順暢度
開發、測試團隊都在逐漸建立自己的 AI Workflow，目前尚未串起成一條完整順暢的流程，光是在 i18n 與前端開發串接的過程中就遇到不少問題，以及 Spec 格式裡的 error code 標示方式也有根據後端開發的回饋進行修改。這些都需要時間慢慢磨合、優化，才能更符合各方需求，讓整條流程順利銜接！
當前這個版本的 AI Workflow 完全稱不上完美，但至少讓我們開始從之前「單點使用 AI 協助」，逐漸往「系統性與 AI 協作、維持穩定產出品質」的目標前進。期待未來能繼續優化、擴充，讓 PM 與開發、測試團隊的流程全部順利串起！
如果你喜歡我的文章，歡迎替我拍手 👏 或分享給身邊可能感興趣的人！ （小提醒：長按拍手按鈕可以拍 50 下唷）
메타데이터
- post_id
- 3b514d67c8b8
- slug
- 菜鳥-pm-學習日記-ep-11-不只是叫-ai-幫忙寫文件-我們如何重新設計-pm-的工作流程-3b514d67c8b8
- url
- https://medium.com/@chengyl0112/%E8%8F%9C%E9%B3%A5-pm-%E5%AD%B8%E7%BF%92%E6%97%A5%E8%A8%98-ep-11-%E4%B8%8D%E5%8F%AA%E6%98%AF%E5%8F%AB-ai-%E5%B9%AB%E5%BF%99%E5%AF%AB%E6%96%87%E4%BB%B6-%E6%88%91%E5%80%91%E5%A6%82%E4%BD%95%E9%87%8D%E6%96%B0%E8%A8%AD%E8%A8%88-pm-%E7%9A%84%E5%B7%A5%E4%BD%9C%E6%B5%81%E7%A8%8B-3b514d67c8b8
- canonical_url
- https://medium.com/@chengyl0112/%E8%8F%9C%E9%B3%A5-pm-%E5%AD%B8%E7%BF%92%E6%97%A5%E8%A8%98-ep-11-%E4%B8%8D%E5%8F%AA%E6%98%AF%E5%8F%AB-ai-%E5%B9%AB%E5%BF%99%E5%AF%AB%E6%96%87%E4%BB%B6-%E6%88%91%E5%80%91%E5%A6%82%E4%BD%95%E9%87%8D%E6%96%B0%E8%A8%AD%E8%A8%88-pm-%E7%9A%84%E5%B7%A5%E4%BD%9C%E6%B5%81%E7%A8%8B-3b514d67c8b8
- author_url
- https://medium.com/@chengyl0112
- status
- ok
- fetched_at
- 2026-07-07 19:05:46
