手指停在「建立流程」上面

停下來的原因不是想通了什麼，是想到上一條流程的下場。

那條流程建好的第三週開始沒人敢改，因為沒有人說得清楚它到底在做什麼、哪些條件會讓它走另一條路、當初為什麼那一步要放在那裡。它還在跑，但它變成一個沒人想碰的東西。

建置變便宜之後，稀缺的東西換位置

以前建一條 flow，難的是建置本身：找對的連接器、搞懂觸發條件的設定、處理陣列跟迴圈。現在自然語言就能協助生成大半，建置成本持續往下掉。

成本掉下去之後，稀缺的能力往上移到規格思維。直接請 AI 生成一條 flow、跑壞了再回來修，修的是實作；那些從來沒想清楚的決定不會因為多修幾次就自己浮出來。

自動化的第一個產物是規格，不是流程

拿一個具體需求走一次：收到客戶需求後整理內容、建立 Jira、通知相關人員。第一步不是生成 flow，是讓 AI 陪你把它拆成七個欄位。

Goal 要寫到能回答「拿掉它會怎樣」。Trigger 要寫清楚判斷依據，「收到客戶來信」不夠，「來自客戶網域、主旨不含 RE: 的信」才是。Input 是需要哪些輸入才能開始，以及缺一項的時候怎麼辦。Decision 是每一個需要判斷的位置，附上依據與分支。Action 的每一步都要能回答成功的判準。Output 是做完之後長什麼樣子，這一欄最常被寫得草率，而它後面接的是所有驗收爭議。Review Gate 直接沿用 Day 10 的三個原則。

七欄填完還有第二次拆分，這一次決定整條流程的體質：

這張表的用處在於，它會逼你面對一件事：想交給模型的那些節點裡，有幾個其實是在賭它每次都給同樣的答案。

規格算不算完成，有五個問題可以檢查：什麼事件啟動、需要哪些輸入、哪些位置需要判斷、什麼情況必須停下來等人、什麼結果才代表這一次真的成功。五個都答得出來，Power Automate 才登場，而這時候建置通常比想像中快，因為難的決定都做完了。

今天可以做的一件事

拿到需求之後，最順手的一句是這個：

幫我根據這個需求做一條 Power Automate 流程。

它會給你一條跑得起來的 flow，而需求裡那些沒講清楚的地方，會被它用合理的預設值悄悄填掉。你不會看到它填了什麼，直到某天跑出你沒預期的結果。

下面三段 prompt 可以直接複製，都在對話裡跑完。第三段的產物明天會直接用到。

第一段：生成今天主題的測試資料

請幫我寫一封虛構的內部需求信，直接輸出在對話裡，約 250 字。
寄件者是客服組的林佩宜，收件者是我。

情境：一家線上教育平台公司，她希望客服信箱收到的信可以自動整理成
Jira 工單，減少人工轉貼的時間。

信裡要藏進下面這些問題，但整封信要寫得像真的工作信件，
不要標示、不要條列、不要在信末補充說明：
- 沒有說明什麼樣的信才算「需要建票」
- 同時寫了「所有客戶來信都要建票」和「垃圾信不用建」
- 提到「緊急的要馬上通知我」，但沒有定義什麼算緊急
- 假設系統知道每一封信對應哪一個客戶，但沒有說依據什麼判斷
- 結尾寫「其他的就比照我們現在的做法」

第二段：把今天的主題跑在這批資料上

以下是那封需求信。先不要生成任何流程，也不要提供解法或建議做法。

第一步：列出信中所有模糊、矛盾或缺少依據的地方。每一項標明屬於
「模糊」「矛盾」還是「缺少依據」，並附上信裡對應的原句。

第二步：把這些問題分成兩類，一類是我自己就能決定的，另一類是必須
回去問林佩宜才能決定的。

第三步：針對必須問的那些，寫成三到五個可以直接貼給她的問題，
每個問題都要能用一句話回答。

第三步結束就停，不要往下拆流程節點。

它應該至少抓到五項。「所有來信都要建票」跟「垃圾信不用建」是矛盾，「緊急」是缺少依據，「比照現在的做法」是模糊，而那句「系統知道是哪個客戶」則是一個沒有被說出來的假設。

真正值得注意的是第二步的比例。多數人以為只有一兩題需要回去問，實際跑出來，必須問的那一類幾乎都比預期多。那些題目如果不問，答案還是會被填上，只是由模型代填，而不是由林佩宜決定。

第三步的限制也刻意寫死。問題還沒問完就往下拆節點，拆出來的規格是建立在猜測上的，跟直接生成一條 flow 差別不大。

第三段：把答案補回去，產出明天要用的規格

問題問完、答案回來了，才輪到前面那七欄。為了讓這段能直接跑，林佩宜的回覆一併附在 prompt 裡：

林佩宜針對那幾個問題回覆如下：
- 需要建票的定義：客戶在信中描述問題或提出要求才建票。單純道謝、
  確認收到、行銷訂閱不建。
- 垃圾信交給信箱現有的過濾規則處理，被過濾掉的不會進到這條流程。
- 緊急的定義：信中提到「無法上課」或「已付款但無法使用」，
  或同一位客戶 24 小時內第三次來信。
- 客戶對應：用寄件信箱比對客戶名單，比對不到就標成「未知客戶」，
  仍然建票，指派給客服組長。
- 「比照現在的做法」指的是建票後由客服組長每天早上分派。

請根據原始需求信加上這些答案，輸出一份流程規格。
只輸出下列格式的內容，不要加任何說明、前言或結語。

【流程規格】
Goal：
Trigger：（寫出判斷依據，不要只寫事件名稱）
Input：（每一項標明缺漏時怎麼處理）
Decision：（每一項標明判斷依據與分支）
Action：（每一項標明成功的判準）
Output：
Review Gate：（哪些節點需要人停下來，以及停下來看什麼）

【節點分工】
交給 AI Skill：
交給確定性 Workflow：

【尚未確定】
（任何仍然無法從上述資訊判斷的項目列在這裡。不要自行補上預設值，
也不要為了讓規格看起來完整而略過。）

跑完把這份規格存起來，這樣的操作模式會從自然語言的敘述搭配 plugins 的後就會直接在 Power Automate 建置流程。

最值得看的是【尚未確定】那一欄。它如果是空的，多半不是規格真的完整了，而是它替你決定了幾件事；追問一句「上面有哪幾項是你自己推論出來的」，通常會冒出兩三項。

這一欄也是明天的起點。用自然語言加上 plugin 去建 flow，能被正確建出來的只有規格裡已經寫死的部分；尚未確定的那幾格，工具一樣會填，只是它用的是預設值，而且填完不會告訴你。今天把它們留在紙上，明天才看得見它們被填成什麼。

留到明天的問題

手上這份規格明天就要拿去建 flow。建出來的東西會跟規格長得一樣嗎？如果不一樣，是實作走偏，還是規格本來就寫錯了？

再往下想一層，先想清楚再動手，這個道理沒有人不知道，難的是建置成本低到一定程度之後，動手比想清楚舒服太多。先做出一條 flow，至少看得見東西在跑；先寫一份規格，則要一直面對自己其實還沒想清楚的那些地方。工具愈好用，這個誘惑愈大。

AI 可以幫你把想清楚的事情做出來，但它沒辦法替你經歷想清楚的那段過程。