跳到內容
Imbrace SDK

讓它等一個人做決定

這一課要讓教學課程裡的退貨櫃台等一個人做決定。每一筆新的退貨，都會寄一封附有「核准」與「拒絕」兩個按鈕的電子郵件給值班主管；在對方答覆之前，不會向顧客承諾任何事。對方答覆之後，同一次工作流的執行會接續下去：它在該列寫入決定、審核者的姓名與時間，然後通知顧客。

這是第二次實作。請從已經完成的櫃台開始；你在教學課程中建置的東西，一樣都不會丟掉。

你將建置的內容

一筆會先等一個人、之後才有任何東西送到顧客手上的退貨。你要從自己的收件匣，扮演審核者 Jordan Vance——Harbor Bicycle Co. 的值班主管。

  1. 一筆新的退貨進入數據表，退款金額和先前一樣自動算出。
  2. 櫃台把這筆退貨的事實，連同「核准」與「拒絕」兩個按鈕，用電子郵件寄給審核者，然後暫停。等待期間，不會有任何東西送給顧客。
  3. 每個按鈕都會開啟一個顯示所選結果的頁面。打開頁面不會決定任何事；只有頁面上的「確認」（Confirm）按鈕才會。
  4. 審核者一確認，同一次執行就會接續下去：它在該列寫入 Decision、Decided by 和 Decided at，再寄電子郵件給顧客——如果核准，內容是退款金額；如果沒有，就是一段不含金額的簡單致歉。

沒有人需要在儲存格裡打字來做決定。這裡的一切都不是 Harbor Bicycle Co. 的真實系統——在把成果展示給任何人看之前，記得把公司、審核者和用語換成你自己的內容。

你需要準備的東西

  • 你在教學課程中完成的櫃台，位於同一個測試組織：Return Requests 與 Refund Rules 兩張數據表、Calculate refund amount 工作流（新增的一列會自動得到它的 Refund amount），以及 Return Desk Assistant。
  • 同一個 AI 程式碼工具，如同教學課程中一樣，透過 MCP 連接到該組織，並具備寫入權限。
  • 兩個你能讀取的電子郵件地址：一個用來扮演審核者，一個用來扮演顧客。兩個指向同一個收件匣的地址也可以，例如你郵件帳號的別名。只使用你自己的地址——絕不使用真實顧客的地址，也不使用同事的地址。
  • 組織裡一個名為 Gmail 的電子郵件連線，或是一位能登入來建立它的人。步驟 1 會說明去哪裡查看。

這一頁會用到幾個詞：「執行」是工作流跑一次；「已暫停」的執行，是停在它的等待步驟，等有人答覆之後，再從同一個位置接續下去。「審核者」是收到電子郵件的人；Decided by 記錄的就是他的姓名。「一次性連結」是只能用來回答一次、結尾帶有隨機代碼的位址；櫃台只保留這個代碼的「指紋」——一種單向打亂的結果，可以用來核對代碼，卻無法還原出代碼。答覆之後，這個連結會告訴你這筆退貨已經做出決定。「確認頁面」是電子郵件裡的按鈕所開啟的頁面：它顯示所選的結果，而且只有頁面上的「確認」按鈕才會記錄它。「核准任務」是執行建立出來、並等待答覆的項目，有「核准」與「拒絕」兩個答案；作答的人不需要看到它。「決定連結」是核准任務針對某一個答案自己附帶的連結：一打開它就會做出決定，所以它只留在私有數據表（步驟 2 會建置），絕不放進電子郵件。「程式碼步驟」是你的工具寫出來的小步驟，相對於平台內建的原生步驟。

操作步驟

在下面的提示詞裡，方括號標示的是要填入的值，由你的工具填入。其中只有兩個要由你自己提供：你能讀取的那兩個電子郵件地址，審核者的地址在步驟 3，顧客的地址在步驟 4 和 5。

1. 把櫃台準備好

先做兩件小事：留一個位置放顧客的地址，以及設定電子郵件連線。

你輸入的內容：

在 Return Requests 新增一個 Customer email 欄位（純文字）。其他每一列都保持原樣。

確認通知會寄到該列上的地址，所以櫃台需要這個欄位。電子郵件本身則是透過平台自己的連線寄出，絕不透過工作流裡的任何東西。請打開「行動模組」（Actions）>「流程營運模組」（FlowOps）>「更多」>「連線」：電子郵件憑證就在那裡，是一個有名稱的連線，名為 Gmail。如果沒有，就需要有人在每個組織裡各登入 Gmail 一次來建立它——請在步驟 3 之前完成。使用「連線」清單提供的新增連線按鈕，並以你能讀取的 Google 帳號登入；櫃台的電子郵件會從那個帳號寄出。

流程營運模組的「連線」清單，顯示一個名為 Gmail 的連線 1「流程營運模組」（FlowOps）>「更多」>「連線」。2 唯一一個名為 Gmail 的連線。

這一課是針對 Gmail 連線撰寫並檢查的。如果你使用其他種類的電子郵件連線，請在貼上之前，把步驟 3 第 9 點裡的 Gmail 這個詞換成它的名稱，並在信任這次執行之前，先確認兩封郵件都有送達。

這是教學課程第一個習慣「使用平台內建的東西」一路延續下來的結果：憑證屬於平台本身的連線儲存區，永遠不屬於某個工作流。如果之後你匯出工作流，請打開匯出的檔案，確認裡面沒有任何金鑰或密碼。

你現在應該會看到：Return Requests 有十個欄位，Customer email 是最後一個，每一列都是空的；「連線」清單中有一個名為 Gmail 的連線。

2. 建立確認決定的頁面

在請任何人做決定之前，先決定他們在哪裡作答。審核者會從一封附有兩個按鈕的電子郵件做決定，每個按鈕都會開啟 iMBrace 上的一個頁面，顯示所選的結果並請他們確認。這個步驟要建置那個頁面，以及它用來核對一次性連結的私有數據表。步驟 3 則建置寄出電子郵件的工作流。

請先讀提示詞下方的白話說明，再把整段提示詞貼上。它是寫給你的工具看的，所以你不需要看懂裡面的每一個技術用語。

你貼上的內容，放在同一則訊息裡：

建置一個用來確認決定的地方，分成兩個部分。

第一部分：一個名為 Return Decision Links 的私有數據表，包含這些純文字欄位：Fingerprint、Group、Action、Order reference、Decision link、Expires at、Used at、Used action、Created at。不要有 Link-type 欄位。Decision link 會存放核准任務中承載決定的連結，而核准任務由下一個步驟建立。這個數據表只有工作流會用，不要交給任何代理人。

第二部分：一個名為 Confirm a return decision 的工作流，以公開頁面的形式作答——不需要登入，也不需要金鑰。請使用會直接回應呼叫端的觸發條件，並以原始 HTML（content type 為 text/html）回覆。頁面位址帶有一個名為 t 的隨機代碼。運作方式如下：

  1. 從 t 取得代碼（一般造訪時取自位址；按下頁面自己的按鈕時，取自名為 t 的表單欄位）。算出它的單向指紋。只比對指紋；絕不儲存或顯示代碼。
  2. 在 Return Decision Links 上找出具有該指紋的那一列。沒有代碼，或找不到該列：顯示一個簡單的頁面，上面寫著「This link is not valid.」，沒有按鈕。
  3. 如果有這一列，就讀取與它同屬一個 Group 的每一列，並依 Order reference 讀取 Return Requests 上的那筆退貨。連結有三種狀態：有效（尚未使用、尚未過期）、已使用（Used at 已填入）或已過期（超過 Expires at）。
  4. 單純造訪只會顯示頁面，不會改變任何東西。有效：顯示「Approve return [order reference]?」（或「Reject return [order reference]?」）、顧客、商品與退款金額、一個把代碼回傳的 Confirm 按鈕，以及這一行字：「Nothing is decided until you press Confirm.」已使用：顯示「This return has already been decided.」已過期：顯示「This link has expired.」
  5. 只有在有效的連結上按下 Confirm 時：先使用 Decision link 裡的連結（一個不帶任何憑證的單純 GET；即使失敗也要繼續往下，這樣才能讀到它的狀態）。如果狀態是 200 到 299，就把該 Group 的兩列都標示為已使用（Used at 設為現在的時間，Used action 設為該動作），並顯示「Return [order reference] approved」（或「rejected」），再加一行說明正在寄電子郵件通知顧客。如果失敗，就不要改變任何東西，讓連結仍然可以使用，並顯示「Your decision was not recorded. Try the button again in a minute.」

每一條路徑都以一個頁面作結。頁面請用一個小的程式碼步驟來建置，它只負責把值轉成文字，並對它插入的每一個值做跳脫處理：不能有網路呼叫，也不能有憑證。數據表的讀取與寫入、那次呼叫以及各個回應，請使用原生步驟。發布之後，請告訴我頁面位址。

白話說明。 先是私有數據表。每一列存放一個按鈕的一次性連結（以指紋的形式保存，絕不保存代碼本身），以及那個按鈕的決定連結，由步驟 3 填入。Group 把一筆退貨的兩個按鈕綁在一起。只有工作流會用這個數據表，所以不會交給任何代理人。接著是頁面，逐點說明：

  1. 頁面從連結中讀取代碼，只保留它的指紋，所以代碼本身不會被儲存在任何地方。
  2. 對不上任何一列的連結，會得到一個簡單的「無效」頁面，沒有按鈕。
  3. 對得上的連結，會依私有數據表判斷是有效、已使用還是已過期；頁面顯示的事實，則取自那筆退貨自己的那一列。
  4. 單純造訪只會顯示事實與一個「確認」按鈕。郵件掃描程式和預覽功能會打開它們找到的每一個連結，所以打開連結絕不能決定任何事。
  5. 只有「確認」會做出決定。頁面先記錄答案，再讓兩個按鈕一起失效，所以一筆退貨只會被決定一次；如果記錄失敗，就不會有任何改變，頁面也會如實說明。

大部分步驟都是原生步驟。其餘是小的程式碼步驟，只根據拿到的值做運算；沒有任何一個會發出網路呼叫或持有憑證。

你現在應該會看到：在「知識模組」（Knowledge）>「數據表」（DataIQ）裡，多了一個新的數據表 Return Decision Links，有九個欄位，沒有任何列。在「行動模組」（Actions）>「流程營運模組」（FlowOps）裡，有一個已發布的工作流 Confirm a return decision；打開這個工作流，就能進入它的執行紀錄。請向你的工具索取頁面的位址，在無痕視窗中打開它：先是位址後面什麼都不加，接著只加上 ?t=（後面不接任何東西），最後加上 ?t=notacode。每一次你都會看到同一個簡單的頁面，上面寫著「This link is not valid.」，沒有按鈕。在執行紀錄裡，每一次造訪都顯示為一次已完成的執行，而且沒有任何數據表被改變。

以沒有連結的方式打開確認頁面：只有一句簡單的話，沒有按鈕 以沒有連結的方式打開的頁面：只有一句簡單的話，沒有按鈕。

這個簡單的頁面就是正確的第一個答案：沒有連結，就沒有東西可決定，也沒有按鈕可按。你會在步驟 4 看到帶著真實連結的頁面。

如果你看到的不是那一句話，請把你看到的內容原原本本告訴你的工具，請它讓工作流以一個不需要登入的網頁作答，然後再打開一次位址，確認之後再繼續。

這個頁面背後的規則：電子郵件裡的連結不是決定。打開連結只會顯示一個頁面；只有「確認」才會做出決定。隨機代碼絕不儲存，只儲存它的指紋，而存放指紋的數據表是私有的。人工核准說明了原因。

3. 以電子郵件詢問、等候答覆，再通知顧客

櫃台就是在這個步驟開始等待。一個工作流以電子郵件詢問一個人，然後停在等待步驟，只有在對方確認之後，同一次執行才會把決定寫到該列，並通知顧客。請把整段提示詞放在同一則訊息交給你的工具——詢問的那一半和完成的那一半是一體的——並且在它說工作流已發布之前，先不要新增任何退貨。你在這裡要提供的值只有審核者的地址。和步驟 2 一樣，請先讀提示詞下方的白話說明：提示詞是寫給你的工具看的。

你貼上的內容，放在同一則訊息裡：

建置一個名為 Apply return decision 的工作流，以電子郵件請一個人做決定，等候答覆，然後把工作完成。它在 Return Requests 某一列的 Refund amount 被寫入時啟動——是 Refund amount 上的「column updated」（欄位更新）自動化，而不是「row created」（新增資料列）。審核者是 Jordan Vance，地址為 [你自己的地址]。請依序執行：

  1. 讀取該列。除非 Order reference 與 Refund amount 都已填入，而且 Decision 是空的，否則什麼都不做。
  2. 依這個 Order reference 讀取 Return Decision Links，依 Created at 由新到舊排序，只取一列。如果有傳回一列而且它的 Used at 是空的，或是讀取失敗，就表示已經有人正在被詢問：到此為止。不建立第二個任務，也不寄第二封電子郵件。
  3. 用平台自己的日期步驟取得目前的時間（UTC）。
  4. 用一個小的程式碼步驟把該列變成決定卡片：標題「Return [order reference] needs a decision」、一行摘要，以及一張列出 Customer、Order reference、Item、Condition、Price 和 Refund amount 的表格。上面不要有決定期限。
  5. 用平台自己的任務步驟建立一個核准任務：以那張卡片作為它的說明，並設兩個選項，Approve（綠色）和 Reject（紅色）。把它指派給我的 API 金鑰所代表的使用者。絕不要讓受指派者留空，也絕不要指派給同事。
  6. 用一個小的程式碼步驟產生兩個隨機代碼，一個給 Approve、一個給 Reject，並為每一個代碼算出單向指紋——方法與確認頁面所用的相同。每一個一次性連結，就是 Confirm a return decision 頁面的位址，加上 ?t= 和它的代碼，有效期限為七天。核准任務也為每一個答案附帶自己的決定連結，也就是承載決定的那個連結：只在這一點讀取它們，其他地方都不要讀取，也絕不要把它們放進電子郵件、頁面、Return Requests 的資料列或任何回覆裡。
  7. 用原生的數據表步驟，在 Return Decision Links 寫入兩列，每個按鈕一列：指紋、Group（任務的 id，兩列相同）、Action、Order reference、Decision link（核准任務中那個答案的決定連結，以純文字存放）、Expires at 和 Created at。Used at 與 Used action 保持空白。絕不儲存代碼。
  8. 用一個小的程式碼步驟，把同一張卡片轉成附有兩個按鈕的 HTML 電子郵件，Approve（綠色）和 Reject（紅色），每個按鈕都只指向第 6 點產生的一次性連結，絕不指向決定連結，另外加上這一行：「Each button opens a page where you confirm. Nothing is decided by opening a link.」
  9. 用平台自己針對 Gmail 的 Send Email 步驟寄出，透過組織的 Gmail 連線，並使用組織所提供的該步驟最新版本。如果還沒有電子郵件連線，就停下來告訴我：需要有人登入才能建立它。寄件者名稱為「Harbor Bicycle Returns Desk」，名稱中不要有逗號。主旨為「Return [order reference] needs your decision」。
  10. 等待核准任務（也就是等候答覆的那個任務步驟）。第 5 到第 10 點必須連續執行：中間不能有任何東西，而且在第 10 點之前的任何地方，都不能有會暫停或休眠的步驟。

當答覆回來、執行接續下去時：

  1. 再依 Order reference 讀取一次那筆退貨。
  2. 依答覆處理。只有在 Decision 仍然是空的、而且你剛讀到的那一列就是啟動這次執行的那一列時，Approve 或 Reject 才算數；其他情況一律不寫入任何東西。Approve：取得時間（UTC）；在該列寫入 Decision「Approved」、Decided by「Jordan Vance (confirmed by email)」以及 Decided at；然後才寄電子郵件給 Customer email 上的顧客地址，主旨為「Your Harbor Bicycle return is approved」，內容是純文字，寫明退款金額。Reject：做法相同，但 Decision 寫入「Rejected」，主旨為「Your Harbor Bicycle return was not approved」，內容是一段簡單的致歉，不寫任何退款金額，並請對方聯絡退貨櫃台。

每一次數據表的讀取與寫入、任務、等待、時鐘以及電子郵件，都請使用原生步驟。小的程式碼步驟只用在第 4、6 和 8 點。

白話說明，逐點來看。詢問的那一半：

  1. 除非這筆退貨已經準備好，否則什麼都不做：它有訂單編號和退款金額，而且還沒有人做出決定。
  2. 同一時間只詢問一次：如果這筆退貨已經在等待答覆，就到此為止，這樣對該列的第二次寫入就不會啟動第二次詢問。
  3. 讀取時鐘，讓連結有一個到期時間。
  4. 把審核者需要的事實放在同一張卡片上。
  5. 建立執行要等待的核准任務：一個有兩個答案（「核准」與「拒絕」）的項目，指派給你的 API 金鑰所代表的使用者。
  6. 產生兩個一次性連結，每個按鈕一個，並取得核准任務自己的決定連結。只有這一點會從核准任務取得它們；從那之後，它們只存在於私有數據表中，而且只有確認頁面會使用。
  7. 把每個按鈕的指紋和它的決定連結存到私有數據表，確認頁面會在那裡找到它們。
  8. 把卡片變成附有兩個按鈕的電子郵件。
  9. 透過組織的 Gmail 連線，把它寄給審核者。
  10. 等待。執行在這裡暫停，並保留它的位置，直到審核者作答。

完成的那一半，在答覆之後：

  1. 再讀取一次那筆退貨，讓執行依它現在的樣子作業。
  2. 先寫入 Decision、Decided by 和 Decided at，再寄電子郵件給顧客。只有同一列的第一個答覆才算數；其他一律不寫入任何東西。

第 4、6 和 8 點是小的程式碼步驟，和教學課程裡的計算步驟同一類：每一個都只根據拿到的值做運算，不發出網路呼叫，也不持有憑證。

你現在應該會看到：在「行動模組」（Actions）>「流程營運模組」（FlowOps）裡，Apply return decision 已發布，Calculate refund amount 則維持不變。打開 Apply return decision，從頭開始讀：建立核准任務的步驟、透過 Gmail 寄出電子郵件的步驟，以及等待的步驟，依這個順序出現，而且在等待之前沒有任何會暫停的東西。要檢查它，請你的工具依序列出 Apply return decision 的步驟（只要名稱），再拿這份清單和畫布上的步驟比對。也請它確認，這裡產生的指紋，用的是和 Confirm a return decision 裡相同的方法。先不要新增退貨；步驟 4 會做這件事。

如果你的工具提出問題，就回答它。如果它建置出來的東西和編號的各點不一致，請它把工作流改成符合這些要點，然後再讀一次步驟。

請依每個步驟的狀態來讀一次執行。步驟的內容可能含有會做出決定的連結，所以你完全不需要打開任何一個步驟。在真實的組織裡，只讓負責審查建置成果的人打開執行紀錄和 Return Decision Links 數據表，並清除舊的執行。

Apply return decision 工作流：寄信給審核者的步驟，接著是等待的步驟 1 側邊欄的「流程營運模組」（FlowOps）。2 寄信給審核者的步驟。3 等待決定的步驟。

4. 試試核准

現在照審核者會做的方式跑一遍。每一筆測試退貨都用一個新的訂單編號，也就是數據表上還沒有的編號：櫃台是靠訂單編號來追蹤每一筆退貨的。

你輸入的內容：

在 Return Requests 新增一列：Customer name 填 Morgan Ellery，Order reference 填 HB-3001，Item 填 helmet，Condition 填 unopened，Price 填 45，Customer email 填 [你用來扮演顧客的地址]。Refund amount、Decision、Decided by 和 Decided at 先留空。

你現在應該會看到，一個時刻接著一個時刻：

  1. 幾秒鐘之內，該列的 Refund amount 就會填入：45。Decision、Decided by 和 Decided at 仍然是空的。在「行動模組」（Actions）>「流程營運模組」（FlowOps）裡，Apply return decision 的執行紀錄多了一次新的執行，而這次執行已暫停。建立核准任務和寄出電子郵件的步驟標示為成功。在它等待期間，請你的工具只查詢核准任務的狀態和受指派者：它是開啟的，而且已指派。

Apply return decision 的執行紀錄：新的一次執行已暫停 1 側邊欄的「流程營運模組」（FlowOps）。2 Apply return decision 的新執行，已暫停。

  1. 審核者的收件匣裡有一封電子郵件，主旨就是你要求的那一個。它列出這筆退貨的事實——顧客、訂單編號、商品、狀況、價格和退款金額——以及兩個按鈕，「核准」與「拒絕」。Return Decision Links 現在有兩列，每個按鈕一列，Used at 都是空的。

審核者收到的電子郵件，附有「核准」與「拒絕」按鈕 審核者收到的電子郵件：這筆退貨的事實，以及「核准」與「拒絕」兩個按鈕。

  1. 打開「核准」。頁面會顯示所選的結果：顧客、商品和退款金額，並有一個「確認」按鈕。沒有任何東西改變。如果你想，可以再打開一次：執行仍然是暫停的，該列仍然沒有決定。

從「核准」按鈕開啟的確認頁面 確認頁面：這筆退貨的事實，以及一個「確認」按鈕。按下之前，不會決定任何事。

  1. 按下「確認」。頁面會說明這筆退貨已核准，並且正在寄電子郵件通知顧客。在「流程營運模組」裡，剛才暫停的那次執行就是完成的那一次，這筆退貨不會留下任何暫停的執行。在數據表上，該列現在顯示 Decision 為 Approved，Decided by 為 Jordan Vance (confirmed by email)，並有一個 Decided at 時間。顧客的收件匣裡有一封寫明退款金額的電子郵件，而 Return Decision Links 的兩列都已填入 Used at。

Return Requests 捲動至 Decision、Decided by 和 Decided at，由這次執行寫入 1「知識模組」（Knowledge）>「數據表」（DataIQ）。2 Decision、Decided by 和 Decided at，由這次執行寫入。

同一次 Apply return decision 執行，已完成，其兩個 Send Email (Gmail) 步驟標示為成功 1 側邊欄的「流程營運模組」（FlowOps）。2 同一次執行，已完成，其兩個 Send Email (Gmail) 步驟標示為成功。

  1. 回到審核者的電子郵件，打開「拒絕」。頁面會說明這筆退貨已經做出決定。兩個按鈕會一起失效，所以一筆退貨只會被決定一次。

這是第五個習慣：決定是由發出詢問的那次執行寫在資料列上的一個值——答案、審核者的姓名和時間——而不是有人在聊天室裡打「看起來沒問題」，也不是有人去編輯的儲存格。在有人作答之前，不會有任何東西送到顧客手上，執行就只是等待。

Decided by 顯示你指定的審核者姓名，後面接著「(confirmed by email)」：這項決定是從該審核者自己的電子郵件確認的，所以請把這封郵件留在自己手上，不要轉寄。

如果這個步驟裡有任何一項檢查不成立，請一個環節一個環節往回查。Refund amount 有填入嗎？Apply return decision 有沒有新的執行，它是已暫停，而不是失敗？建立任務和寄出電子郵件的步驟有標示為成功嗎？接著看看你的垃圾郵件匣。告訴你的工具是哪一項檢查卡住了，請它只修那一件事。

5. 試試拒絕

用相反的方式回答第二筆退貨。

你輸入的內容：

在 Return Requests 新增一列：Customer name 填 Riley Okafor，Order reference 填 HB-3002，Item 填 bike lock，Condition 填 used，Price 填 28，Customer email 填 [同一個顧客地址]。Refund amount、Decision、Decided by 和 Decided at 先留空。

你現在應該會看到：

  1. 開頭和先前一樣：幾秒鐘之內出現一次新的已暫停執行，審核者的收件匣裡有一封附有兩個按鈕的電子郵件。
  2. 打開「拒絕」，然後按下「確認」。頁面會說明這筆退貨已拒絕。同一次執行從已暫停變成已完成，該列顯示 Decision 為 Rejected，Decided by 和 Decided at 也已填入。
  3. 顧客的收件匣裡有一封郵件，說明這筆退貨未獲核准：一段簡單的致歉，以及一行請對方聯絡退貨櫃台的話，不含任何退款金額。
  4. 打開同一封郵件裡的「核准」：頁面會說明這筆退貨已經做出決定。這筆退貨沒有任何核准的電子郵件寄給顧客。

如何確認它真的可行

不要把程式碼工具對自己做了什麼的摘要說明當成證據。一段聽起來合理、描述建置成功的說法很容易寫出來，也很容易被誤認為真的成功——請親自去看。這些檢查大部分你已經在步驟 4 和 5 跑過了。額外多出來的，是按鈕位址的檢查、核准任務的回讀、同一時間只詢問一次、連線，以及助理。如果你要再跑一筆退貨，請用新的訂單編號。

核准

  1. 它會等待。 新的 Apply return decision 執行在幾秒鐘之內就會暫停，其建立核准任務和寄出電子郵件的步驟標示為成功。在該列上，Refund amount 已填入，Decision、Decided by 和 Decided at 是空的。在它等待期間，請你的工具只查詢核准任務的狀態和受指派者：它是開啟的，而且已指派。
  2. 一封郵件，沒有捷徑。 這筆退貨恰好收到一封電子郵件，附有兩個按鈕。請你的工具把你收到的郵件中兩個按鈕的位址印出來，每個代碼都縮短顯示。每一個都是確認頁面的位址，後面接著 ?t= 和一個代碼，沒有其他任何東西。請把代碼留給自己。
  3. 造訪不會決定任何事。 打開「核准」兩次。你會得到一個只有一個按鈕的頁面，執行仍然是暫停的，而且 Return Decision Links 的兩列 Used at 仍然是空的。
  4. 「確認」才會做出決定。 按下「確認」。剛才暫停的那次執行會完成，這筆退貨不會留下任何暫停的執行。Decision 是 Approved，Decided by 是審核者的姓名，後面接著「(confirmed by email)」，Decided at 是一個時間，而且顧客的地址收到了寫明退款金額的電子郵件。Return Decision Links 的兩列都已填入 Used at。
  5. 另一個按鈕會失效。 從同一封郵件按「拒絕」，頁面會說明這筆退貨已經做出決定。
  6. 核准任務的狀態一致。 請你的工具只查詢它的狀態：現在顯示已回答為「Approve」。絕不要印出它的連結。

拒絕

  1. 開頭相同。 一次已暫停的執行，和一封附有兩個按鈕的電子郵件。
  2. 「拒絕」會做出決定。 按下「拒絕」，再按「確認」。同一次執行從已暫停變成已完成。Decision 是 Rejected，Decided by 和 Decided at 已填入，核准任務顯示已回答為「Reject」。
  3. 沒有任何金額送到顧客手上。 顧客收到的郵件說明這筆退貨未獲核准：一段簡單的致歉，以及一行請對方聯絡退貨櫃台的話。請檢查其中有沒有退款金額——裡面沒有提到退款金額，也沒有任何等於價格的金額。
  4. 沒有任何核准通知寄出。 顧客沒有收到這筆退貨的任何核准郵件，而且「核准」按鈕現在會說明這筆退貨已經做出決定。

同一時間只詢問一次、連線與助理

  • 再新增一筆退貨，並讓它保持等待。這筆退貨只用於這項檢查，並且不要對它作答。修改它的 Condition。不會有第二封電子郵件寄出，而且第一次執行仍然是暫停的。可能會出現第二次很短的執行並立刻結束：那是步驟 3 的第 2 點把它停下來。
  • 打開「行動模組」（Actions）>「流程營運模組」（FlowOps）>「更多」>「連線」，確認電子郵件憑證是一個有名稱的連線，Gmail，而不是寫在某個步驟裡的文字。
  • 請你的工具讀回 Return Desk Assistant 的設定：只有一項技能，Log return request，沒有任何數據表，所以連結和決定都留在工作流手上。

如果上面任何一項不成立，這其實比一個看起來沒問題、實際上卻不行的建置更有價值。修好失敗的那一項，然後再檢查一次。

接下來可以做的事

  • 讓一筆退貨一直沒有人作答。執行會維持暫停，等待期間不會有任何東西送到顧客手上。你在步驟 3 要求的連結，有效期限為七天。
  • 用一筆新編的退貨去跟 Return Desk Assistant 對話，並觀察 Apply return decision 的執行紀錄。在你決定助理所記錄的那筆退貨之前，先把顧客的地址填進該列的 Customer email。
  • 閱讀人工核准，了解這一課背後的方法：決定要放在哪裡、什麼讓關卡守得住，以及如何證明它從頭到尾都接上了線路。
  • 請見基本組成元件，了解櫃台的每個部分在畫面上的位置：數據表、工作流、代理人和電子郵件連線。
  • 關於 SDK、CLI 或 MCP 連線本身的任何內容，engineer.imbrace.co 是保持最新的權威來源——這一頁會比那裡更快過時。設定你的程式碼工具 有完整的設定說明。