昨天畫出工作流的全局圖,最前面那個判斷點是「有沒有流程說明文件?」。今天就來看這份文件該長什麼樣子。
先說我的理解:模板的價值不只在欄位本身,更在於它能協助 AI 判斷需要確認哪些問題。缺少模板時,提供哪些資訊往往取決於當下想到什麼;有了模板之後,AI 比較容易辨識尚未補齊的內容,並進一步提出問題。
模板的主體分成文件層與子流程層。文件層描述整個流程的輪廓,子流程層則整理每一段的細節,並依子流程數量重複使用。
# 流程名稱
# 流程目標
# 流程範圍
- 涵蓋:從哪裡開始、到哪裡結束
- 不涵蓋:明確排除的功能或後續流程
- 繪製方式:各子流程是否可單獨繪製、是否支援完整端到端流程圖
# 參與角色
# 涉及系統
# 子流程清單
1. <子流程名稱>
2. <依實際需要增加>
子流程層:
# 子流程 <編號>:<子流程名稱>
## 目標
## 觸發條件
## 前置條件
## 涉及角色
## 涉及系統
## 輸入
## 流程步驟
## 判斷點
- 判斷條件
- 是:
- 否:
## 成功結果
## 失敗結果
## 輸出
## 下一步
看起來欄位不少,不過多數欄位都能對應到圖上的特定元素。以下先挑幾個相對關鍵的欄位說明。
流程範圍是我認為容易被忽略,卻相當關鍵的欄位。它分成三個小項目:
為什麼需要寫「不涵蓋」?Day 17 曾提到一個情況:AI 未必能判斷流程圖應該畫到哪裡為止。假設流程文件寫到「進入退換貨意圖辨識」,後面的處理是否也要包含在圖中,仍有解讀空間。如果沒有明確寫出排除範圍,AI 就需要根據上下文推測,而每次產生的結果可能有所不同。
模板裡還特別註明一句:「不要與子流程清單重複,這裡寫邊界,不寫組成」。這是經過實際使用後補上的提醒,因為撰寫時很容易再次列出子流程,反而模糊了「範圍」與「組成」之間的差異。
子流程清單則像是文件的目錄,也能作為後續選擇繪圖範圍時的選單。清單順序最好與下方子流程區塊的編號、名稱保持一致,讓 AI 能較準確地辨識彼此的階層與對應關係。
在子流程的欄位中,判斷點尤其關鍵,因為它會直接影響圖上需要多少個菱形節點,以及流程會形成幾條分支。
模板規定的寫法是這樣:
## 判斷點
- 判斷條件
- 是:
- 否:
明確列出「是」與「否」兩條路,乍看之下有些繁瑣,卻有助於改善 Day 17 提到的第一個問題:使用口語描述流程時,部分分支可能被忽略。例如「再檢查一次」之後,連線成功與失敗分別會如何處理,都需要記錄下來;若少了其中一條,文件中便會留下空白,也比較容易在後續檢查時被發現。
其餘欄位的用途也都對應到圖:
| 欄位 | 在圖中的對應內容 |
|---|---|
| 流程步驟 | 節點的順序與內容 |
| 判斷點 | 菱形節點與分支連線 |
| 涉及角色、涉及系統 | 節點的分類(也就是後面規格要上的顏色) |
| 觸發條件、前置條件 | 圖的起點在哪裡 |
| 成功結果、失敗結果 | 圖的終點有幾個 |
| 輸入、輸出 | 跨子流程串接時的銜接資訊 |
| 下一步 | 這張圖畫完之後接到哪一張 |
用 Day 18 的說法來看:流程步驟與判斷點會影響要產生多少個 mxCell、value 裡要寫什麼,以及 edge 的 source 與 target 如何連接。當文件描述得越具體,AI 需要自行推測的部分也會相對減少。
模板結尾還有兩個性質稍微不同的區塊。它們主要不是用來描述流程,而是提供 AI 執行與檢查時可以參考的指引。
圖中必須呈現的元素
- 必須顯示的角色
- 必須顯示的系統
- 必須顯示的判斷點
- 必須顯示的成功 / 失敗分支
這個區塊可以作為驗收清單。Day 17 提到的第三個問題是「缺少基準時不容易驗收」,而這四項便提供了一組基本的核對依據,幫助我們確認產出的圖是否包含預期元素。
繪圖備註
這個區塊整理的是實際使用後累積的提醒,例如:
- 請使用 open_drawio_xml,直接生成 draw.io XML(mxGraphModel)
- 不要使用 Mermaid 作為中間格式
- 外部串接系統需明確標示
- 若流程步驟中有呼叫外部系統(含 MCP Server),請標注資料傳送方向
例如:「系統調用 MCP Server 查詢設備清單(回傳:設備清單)」
最後一項是實際繪圖後補上的細節。如果沒有特別要求標示資料方向,產生的連線可能缺少標籤,閱讀者也就不容易理解線條代表的資料內容。
回頭對照 Day 17 的三個問題:
不過,這份模板目前處理的主要是「流程內容」。至於節點該使用什麼顏色、判斷菱形適合套用哪個 style,以及整張圖如何排列,則屬於繪圖規格的範圍,後面幾天會再進一步整理。
明天會以「電商智慧退換貨流程」為例,實際套用這份模板,看看 AI 如何依照欄位逐步提問,並從討論範圍、拆分子流程到補齊判斷點,整理出一份完整的流程說明文件。