流程寫得很順：收到客戶來信、判斷是不是新需求、建一張 Jira、通知負責的人、更新到 Confluence、回信告知單號。不到兩百字，描述的是以前要點十幾次滑鼠的事。
然後客戶說附件在信裡，但信裡沒有附件。建 Jira 那一步 timeout，不知道到底建了沒有，重跑一次變成兩張一樣的票。同名專案有兩個，它挑了去年結案的那個。Confluence 更新成功但通知沒發出去，這種「部分成功」最麻煩，因為沒有錯誤訊息。最後客戶隔天說不用做了，而那張票已經排進下週的 sprint。
這些都不是罕見意外，是任何一條跨系統流程跑久了都會遇到的日常。而那兩百字對它們一個字都沒提。
自然語言很適合表達意圖，這也是它這兩年最大的價值：不必先學會一套流程設計語法，就能把想做的事說出來。但「能把流程說清楚」跟「這條流程能長期可靠運作」是兩件事，中間差的東西剛好是自然語言最不擅長表達的那一類。
Happy path 之所以容易，是因為它只有一條線，每一步都假設前一步成功了。
真實流程需要的是另一組東西：現在處於什麼狀態、哪些條件成立才能往下、這個動作用誰的身分執行、失敗算不算失敗、要不要重試、重試前要不要先確認上一次到底成功了沒、以及做到一半停下來時，已經做過的事要不要回復。
狀態、條件、權限、例外、重試、恢復——這六件事當然可以用自然語言描述，但描述跟保證是兩回事。模型每次執行都可能對同一句話做出略微不同的解讀，而「這張票到底建了沒有」不接受略微不同的解讀。
分工因此清楚起來。需要理解模糊語意的節點交給模型：這封信在講什麼、這段抱怨屬於哪一類、這個需求怎麼摘要成一句話。這些沒有標準答案，容得下變異，人來做也會有變異。涉及系統狀態、唯一識別碼、權限、交易結果、以及任何成立與否的條件判斷，交給規則、程式或 workflow engine。這張票的 ID 是多少、API 回 200 還是 500、這個人有沒有寫入權限，這些問題只有一個正確答案，而且每次都必須是同一個。
流程寫完之後，多數人會這樣檢查：
幫我看看這條流程有沒有什麼漏掉的地方。
它會補上一串建議：加上錯誤處理、加上重試機制、加上通知。每一條都對，也每一條都還停在「要加什麼」，沒有回答「現在到底在哪一步」。
下面兩段 prompt 可以直接複製，兩段都在對話裡跑完，不需要建到任何系統。
第一段：生成今天主題的測試資料
請幫我寫兩份虛構的東西，直接輸出在對話裡，不要建立到任何系統。
情境：一家線上教育平台公司，客服信箱收到客戶來信之後要開票處理。
第一份：一段 200 字以內的自然語言流程描述，涵蓋收到客戶來信、判斷
是不是新需求、建立 Jira、通知負責人、更新 Confluence、回信告知單號。
寫得順、讀起來沒有缺漏、像是一段可以直接交出去的說明。
不要提到任何例外處理、重試或狀態判斷。
第二份：這條流程連續執行 6 次的簡略紀錄，每次三到五行：
- 第 1、2、5 次完全成功
- 第 3 次在建立 Jira 時 timeout，之後沒有留下任何紀錄
- 第 4 次 Jira 建立成功，但通知沒有送出
- 第 6 次建立了兩張內容相同的 Jira
紀錄只寫發生了什麼，不要加上解釋、推測原因或改善建議。
第二段：把今天的主題跑在這批資料上
根據上面那段流程描述，逐一回答下面五個問題。
規則：只能用那段描述裡明確寫到的內容作答。描述裡沒有寫的，
一律回「描述沒有定義」，不要用常識或最佳實務補上。
1. 第 3 次執行結束的當下，那張 Jira 到底建立了沒有？流程怎麼知道？
2. 第 3 次如果要重跑，應該從哪一步開始？
3. 第 4 次算成功還是失敗？由誰判定？
4. 第 6 次那兩張重複的票，流程應該在哪一步就擋下來？
5. 如果客戶隔天說不用做了，這條流程有沒有往回走的路徑？
最後統計：五題裡有幾題是「描述沒有定義」。
五題通常會有四到五題落在「描述沒有定義」，那個數字就是一段讀起來很完整的流程描述，跟一條能長期運作的流程之間的距離。
值得注意的是第二題，它要的不是重跑而是重跑之前得先知道上一次跑到哪裡，而這件事描述裡永遠不會有，因為自然語言不記錄狀態。
搬回自己那條流程時，把第二段的五個問題原封不動換成你自己的六次執行紀錄，回答不出來的那幾題，就是還不能交給自動化的那幾段。
例外想清楚之後，這些東西該在打開自動化工具之前就寫好，還是邊建邊補？
再往下想一層，用一段話把整條流程講完，這件事對人有天然的吸引力。意圖是我們最擅長表達的東西，而狀態、失敗、恢復這些細節，向來是交給別人或交給系統去煩的部分。自然語言介面把表達意圖的成本壓到接近零，卻沒有一併把那些細節帶走，它們只是暫時退到看不見的地方。
說得出來跟跑得起來之間的那段距離一直都在，只是以前我們得自己走過去。
iThome鐵人賽
看影片追技術