文字講得再清楚，還是會各想各的

功能定了、規格定了，區塊 5 要問「這個功能用起來的流程長怎樣」。

這裡會遇到一個常見狀況：需求方PM 讀文字流程時通常都覺得沒問題，等畫面實際做出來，才發現跟他想的不一樣。文字描述容易被雙方各自補上不同的細節，圖則會把差異直接暴露出來。所以區塊 5 不靠文字描述流程，而是跟使用者一起畫一張流程圖。

這也回應一個常見的質疑：既然要視覺化，為什麼不直接請 PM 去 vibe 一個 prototype？我的看法是這兩件事是接力關係。對話負責把意圖跟約束收斂清楚，流程圖負責把這份意圖視覺化、讓雙方校正，prototype 是再下一棒。連自己要什麼都還說不清楚就直接生 prototype，得到的會是一個精緻但由 AI 補完的錯誤畫面，跟前面講過的「通用 ChatGPT 自己補功能」是同一個問題。鼠勾以負責的是中間這張流程圖：比純文字多了視覺，又不需要 PM 具備設計能力。

只給兩種節點

共編流程圖最大的風險，是圖會複雜到只剩工程師看得懂。需求方PM 一旦開始畫，很容易加上「呼叫 API」「寫入資料庫」「發送通知」這類框，但他對這些框的內容並沒有把握，只是覺得流程圖應該要有。結果是一張連他自己都解釋不清楚的圖。

所以鼠勾以把節點類型限制成兩種：

1. 畫面節點（矩形）：使用者真的看得到的畫面，每一個都掛一個 UI-XX 編號，而且一定會進畫面清單。
2. 判斷節點（菱形）：會影響「使用者下一步看到哪個畫面」的條件，例如「符不符合資格」。

只有這兩種。「呼叫 API、驗證資料、寫資料庫」這類純後端動作一律不進圖，因為這張圖畫的是使用者看得到的流程。

這條限制同時也是分工的界線。「怎麼實作」是後端的專業，PRD 不替他們決定要怎麼接 API、怎麼存資料。需求方硬要在流程圖裡畫「這裡呼叫哪支 API」，一來畫不準，二來就算寫了也不一定對，之後還會跟後端自己的技術文件對不起來。到時候為了讓兩份文件一致，反而要花一堆功夫做同步維護，得不償失。

PRD 的職責，是把「功能要做成什麼樣、使用者會經歷什麼」講清楚；至於底層怎麼兜，是跟後端一起討論、交付給他們判斷的事。

那後端做的事去哪了？寫進功能需求（FR）跟驗收標準（AC），描述「要達到什麼」而不是「怎麼做」。例如：

FR-08：送出付款時呼叫金流，依回傳結果導向 UI-09，或留在 UI-08 顯示錯誤。

「要達到什麼」寫進規格，「具體怎麼做」留給後端判斷，圖與規格各自負責一段。

這個限制看起來很嚴格，但它正是需求方PM 畫得出流程圖的原因：只要分得出「這是一個畫面，還是一個判斷條件」就能參與，不需要任何技術背景。

按鈕畫在箭頭上，不另外開節點

這裡有個常見問題：同一個畫面上有好幾個按鈕，各自通往不同地方，要怎麼畫？

直覺是替每個按鈕加一個框，但那會讓節點數量快速膨脹。鼠勾以的規則是：按鈕不畫成節點，改成箭頭上的標籤。從同一個畫面拉出多條箭頭，每條箭頭標上動作：

flowchart LR
    UI01["UI-01 優惠券"] -- 點立即使用 --> UI02["UI-02 使用頁"]
    UI01 -- 點分享 --> UI03["UI-03 分享頁"]

這樣一樣只用到那兩種節點，圖的規模也不會失控。

填表的即時驗證：Self-loop

如果流程裡有表單，會多一個小技巧：self-loop。使用者在表單上漏填、格式錯了，畫面不會跳走，而是停在原地給提示。這在圖上就是一條「指回自己」的箭頭，或在送出前放一個「前端驗證」的判斷節點，驗證沒過就指回表單畫面。

一張帶 self-loop 的流程圖，長得大概像這樣：

flowchart TD
    A[進入功能頁面] --> UI01["UI-01 服務列表"]
    UI01 -- 點選項目 --> UI02["UI-02 填寫申請表單"]
    UI02 --> D{前端驗證}
    D -- 通過 --> UI03["UI-03 確認彈窗"]
    D -- 未通過·顯示錯誤 --> UI02
    UI03 -- 確認送出 --> UI04["UI-04 申請成功頁"]

矩形是畫面、菱形是判斷、按鈕在箭頭上、驗證失敗用 self-loop 指回去。整張圖沒有一個後端框，需求方PM 看得懂，工程師也接得住。

畫完同時生一張畫面清單

每次產出或更新流程圖，鼠勾以會同步生一張「畫面清單總覽」表，把圖上每個 UI 編號攤成一覽：

「新增／修改／沿用」這一欄是後來才補的。有一次在跟使用者確認錯誤畫面時，對方問了一句：「這個失敗彈窗我們系統本來就有，不用再請設計師畫一個吧？」畫面清單上每一格其實都隱含這個問題：要從零做，還是沿用現成的。所以我補了這一欄。

它的用途是讓工程師跟設計師直接看出哪些畫面要從零做、哪些只是改現有的、哪些直接沿用。同一個畫面標「沿用」或標「新增」，設計加開發的工時可能差好幾倍。這跟 Day 16 的「沿用還是新建」是同一件事，只是落在畫面層級。

同一個畫面的三種狀態，要拆成三列嗎

畫面清單開始被實際使用之後，第一個把我問倒的是狀態。

那次是一份請假申請的需求。申請紀錄頁上每一筆都會顯示目前狀態，待審核、核准、未核准，三種文案不一樣，顏色也不一樣。使用者問我：這要不要拆成 UI-07a、UI-07b、UI-07c 三列？

不用。判斷句只有一句：版面有沒有變？只有文字跟顏色變，那就是同一個畫面。前端實作的時候是一個狀態徽章元件配三個變體，清單上拆成三列，反而讓工程師以為要切三個版、讓設計師以為要畫三張稿。

真的要拆是另一種情況：版面長得不一樣。核准之後整頁改版、或是多出一顆「下載核准單」的按鈕，那就是另一個畫面，至少也要在備註欄記成子狀態。

不過有個東西不能因為「不拆」就跟著消失。那三種狀態的文案跟顏色，前端切版真的需要，而以前這段資訊都是會議上口頭講一講，PRD 完全沒寫，等於留給前端自己猜，或是開發到一半再回頭問一輪。

所以現在只要畫面上有狀態欄位，那個 Feature 的畫面內容規格底下會多附一張表：

而且是鼠勾以主動問。偵測到畫面上有狀態欄位，它會自己把這張表帶出來，一格一格問文案跟顏色，不等使用者想到要講。這種事使用者幾乎不會主動提，因為在他腦中那些狀態本來就長那樣。

共編的紀律：每次都重畫整張

最後一個實作細節：使用者每改一次流程，鼠勾以都重新輸出完整的 Mermaid，而不是只說「把第三步改成這樣」。

原因是流程圖最怕口頭補丁。改到第五次的時候，雙方對「現在這張圖長什麼樣」的認知通常已經不同。每次都重畫完整版，兩邊看到的就會是同一份最新版本。輸出比較久，但省掉後續對版本的爭議。

小結

區塊 5 把「使用流程」轉成一張只有兩種節點的 Mermaid 流程圖：畫面（矩形掛 UI 編號）與判斷（菱形），後端動作一律寫進 FR/AC，按鈕改成箭頭標籤，表單驗證用 self-loop。畫圖的同時產出一張標好「新增／修改／沿用」的畫面清單，畫面有狀態就補一張狀態樣式表、但不拆成多個 UI，每次修改都重畫完整版。這張圖補上純文字缺少的視覺對齊，也不需要需求方PM 具備設計能力，位置剛好在 prototype 的前一棒。

Day 18 進到一個可選的進階機制：當流程牽涉到好幾個角色（使用者、客服、主管、外部系統）來回交手時，怎麼用「參與者協作圖」把誰在什麼時候做什麼、資料在誰之間流動，畫成一張循序圖。

這是 iThome 鐵人賽系列文章。明天見。