規格是寫給人看的，描述是給生成器用的

昨天那份規格寫得沒問題，問題在於它的讀者不一樣。

寫給人看的規格可以留一點脈絡讓對方自己接，「緊急的定義如下」後面接三個條件，人讀得懂那三個是 or 的關係。生成器不會接脈絡，它只會做一件事：把你沒明講的部分補成合理的預設值，然後不告訴你它補了什麼。

這不是猜測，官方文件自己就寫著：目前版本中，即使你在描述裡提供了參數，AI 也可能不會自動把它填進去。換句話說，你寫了但沒被採用，是一個已知且預期內的行為，不是你的描述寫壞了。

所以「把規格貼進去」這個動作本身就不成立。規格要先翻譯成一段生成器吃得下的描述，而翻譯過程中會掉的東西，正是你接下來要親手補回去的清單。

描述要寫成什麼形狀

官方給的建議只有幾條，但每一條都對應到一種失敗。

寫成「當 X 發生，就做 Y」的句型，因為生成器要先辨識出觸發程序，才有東西可以往下掛。描述裡指名服務，Outlook、Teams、SharePoint，不指名它就得猜，猜錯的連線在後面那一步會變成紅色驚嘆號。具體到不能再具體，「我要處理郵件」這種描述得到的東西不會比空白好多少。

另外再加三條。一句話只講一個節點，不要把「判斷是否緊急並通知組長」寫成一句，那是兩個節點。條件要寫成可以判斷真假的句子，「重要的信」不行，「主旨或內文含某兩個字串」才行。一句話裡不要放兩個分支，分支拆成獨立的句子，生成器才接得住。

還有一件事比句型更重要：用講的建出來的是骨架，不是成品。

昨天七欄規格裡，Trigger、Action、Decision 這三欄適合寫進描述，因為它們直接對應生成器認得的觸發程序、動作與條件。Input 的缺漏處理、Action 的成功判準、Review Gate，這三樣描述表達不了，生成之後要自己進設計工具補。而 Day 14 講過的那些確定性需求，唯一識別碼、重試前先確認上一次有沒有成功、部分成功怎麼算，更是完全不在生成範圍內。

這個分界不是工具的缺陷。描述負責把骨架立起來，讓你省下找連接器和排版面的時間；剩下那些需要「每次都必須是同一個答案」的東西，本來就不該由一段可以有多種解讀的話來決定。

今天可以做的一件事

最省事的做法是這一句：

把昨天那份規格整段貼進 Power Automate，讓它生成。

這就是開頭那條流程的來歷。下面兩段 prompt 換一個順序：先把規格翻譯成描述，生成之後再逐格比對。

第一段：把規格翻成生成器吃得下的描述

以下是一份流程規格。請把它翻譯成一段要貼進 Power Automate 的描述。

【流程規格】
Goal：客服信箱收到的客戶來信，自動整理成 Jira 工單
Trigger：客服信箱收到新信，且未被信箱既有過濾規則擋掉
Input：寄件信箱、主旨、內文、附件；沒有附件不擋，標註「無附件」
Decision 1：信中有描述問題或提出要求才建票；單純道謝、行銷訂閱不建
Decision 2：內文含「無法上課」或「已付款但無法使用」，
  或同一寄件信箱 24 小時內第三次來信，標為緊急
Decision 3：寄件信箱比對不到客戶名單時，標為「未知客戶」，仍然建票
Action 1：建立 Jira issue，成功判準是取得 issue key
Action 2：緊急案件即時通知客服組長，成功判準是通知送達
Output：一張 Jira issue，含客戶、分類、是否緊急、原信連結
Review Gate：標為緊急、或標為未知客戶的，建票後由人確認

請輸出三個部分：

一、描述本文（用英文撰寫，因為這項功能對英文以外的語言不保證支援）
   規則：
   - 用 When X happens, do Y 的句型開頭
   - 一句話只描述一個節點
   - 指名服務名稱（Outlook、Jira、Teams）
   - 條件寫成可以判斷真假的句子，不要用形容詞
   - 一句話裡不要放兩個分支

二、對照表
   三欄：規格的哪一項、對應描述裡的哪一句、這一句如果被忽略會怎樣

三、這段描述表達不了的項目
   列出規格裡無法靠描述傳達、必須在生成之後手動補的部分，
   並說明各自該補在哪一類設定上。不要提供替代寫法，我只要清單。

第三個部分才是這段的重點。它應該至少指出成功判準、Review Gate、以及 24 小時內第三次來信的計數這三項。這份清單先印出來，等一下要拿來對照。

第二段：生成之後逐格比對

生成完之後，把畫面上那條流程的觸發程序與每一個動作的名稱，照順序抄下來，連同你看到的條件設定，一起貼進下面這段：

以下是我用那段描述生成出來的流程節點，依照畫面上的順序抄錄。

（貼上節點名稱與條件設定）

請對照上面那份【流程規格】，逐項回答：

1. 規格裡的哪幾項在生成結果中找不到對應節點
2. 哪幾項有對應節點，但條件或參數被簡化了，簡化成什麼
3. 哪幾個節點是規格裡沒有、生成器自己加上去的

不要提供修正建議，也不要重寫描述。我要的是一張差異清單。

第三題最容易被跳過，而它往往最值得看。生成器補上去的節點通常是合理的，問題在於那是它替你做的決定，你沒有參與過。

至於前兩題的答案數量，實際跑過的那幾次，掉的項目大致落在昨天第三段留下的【尚未確定】那一欄，加上今天第一段 prompt 列出的「描述表達不了」清單。兩份清單如果能覆蓋掉大部分差異，代表規格這一步做對了；如果差異裡出現兩份清單都沒提到的東西，那是規格本身也沒想到的地方，值得記下來。

留到明天的問題

用講的把東西建出來，最迷人的地方在於它把「我到底有沒有想清楚」這個問題往後挪了。以前不會做就是不會做，畫面上一片空白，那份空白誠實得讓人不舒服。現在不會做也能先看到一條流程在跑，而它看起來的完成度，跟你想清楚的程度沒有關係。

這條流程已經在畫面上，接下來它會跑、會出錯、會被別人接手。出事的那天，你還讀得懂它嗎？

畫面上那條流程是照你說的話長出來的，包括你沒有說的那些。