2026 年 5 月，工作管理工具 Asana 以 7,500 萬美元收購 StackAI，一家讓企業不寫程式就能建立 AI 助手的公司。它的助手能接上 Salesforce、Slack、Google Workspace 等既有系統取資料。Asana 自家的 AI Teammates，官方頁面寫著能在十多個連接的 App 裡搜尋、讀取和寫入，包括 Gmail、Slack 和 HubSpot；建立自訂的助手時，可以替它定義角色、加上技能、給予存取權限，而存取範圍是依建立者現有的權限來選。

這代表越來越多非工程背景的人，會自己做出會連續執行多個步驟的 AI 助手。操作門檻降低之後，有一件事很容易被略過：連上一個工具，不代表 AI 該做那個工具裡的每件事。

同一個助手，在同一套系統裡，可能只是讀取專案進度，也可能修改期限、匯出名單或寄信給客戶。這些動作的後果完全不同，不該共用同一層權限。所以做助手的人要按動作分配權限，而不是按連線。

測試順利，只代表正常情況走得通

你做了一個助手：讀客戶來信、建立任務、指派負責人，最後寄信回覆。測了幾次都很順，團隊想拿掉寄信前的人工確認，省下每天按核准的時間。

測試順利只代表正常情況下走得通。建立一張內部任務，錯了還能刪；寄出一封代表公司的信，錯了就收不回來，可能影響客戶關係和合約承諾。整理 AI 資安風險的國際社群 OWASP，把 AI 拿到用不到的功能、超過需要的權限，以及高影響的動作沒有經過獨立確認就執行，列為「過度代理」的三個來源。

把每個動作分到三層

把助手實際會做的動作逐一寫下來，依後果分層：

可以自動做： 讀取不敏感的資料、建立草稿任務、加內部標籤。錯了容易修正，但要留下紀錄和變更摘要。

限定範圍內自動做： 改負責人、調整期限、移動優先順序。設好條件，例如只能動指定的專案、一次最多十筆；超出範圍或影響其他團隊的承諾，就交給人。

只產草稿，由具名的人放行： 寄信給客戶、發布內容、核准付款、匯出客戶名單、修改帳號權限。助手準備好內容，由一位具名的負責人檢查對象、內容和附件後送出。這個人不在時，流程要停在看得見的等待狀態，而不是逾時自動略過。

放行的畫面不能只有一個「是否繼續」的按鈕，要讓人看到助手準備做什麼、根據哪些資料、做完能不能撤回，參考〈把 AI 接進工作流前，先定義什麼時候要停下來問人〉。

廣告

上線前刻意讓它失敗一次

只測資料正確、服務正常、核准者隨時在線的情況，不能證明流程遇到問題時會安全停下。挑一件低風險的工作，在不碰正式資料的情況下，分別模擬：必要欄位缺失、兩個來源互相矛盾、核准者沒有回應、外部系統回傳失敗。

觀察的重點是它在哪裡停下，以及人接手時看不看得懂發生了什麼。流程只完成一半時怎麼收拾，例如任務建好了、通知卻沒送出，參考〈自動化卡在半途，先查清楚再決定能不能重跑〉。

分層標準要依你的團隊而定

分層的標準要依你的團隊和資料而定，這裡的例子不是唯一答案。而且通過試跑，不代表助手可以從此任意擴張：之後增加連接的工具、提高處理筆數，或把內部草稿改成直接對外送出，都要重新分層、重新測試。

Asana 的頁面也提到管理員可以決定誰能建立和修改 AI Teammates。這個開關很重要，因為在無程式碼工具裡，做助手的人就是決定它能做什麼的人。

AI 整理卡

我用無程式碼工具做了一個 AI 助手（或準備要做），想在上線前替它的每個動作分配權限。
判斷方法來自這篇文章：https://boosterminiclass.com/posts/no-code-agent-builders-need-workflow-guardrails/
文章的看法是：連上一個工具，不代表 AI 該做那個工具裡的每件事。權限要按動作給：哪些自動做、哪些在限定範圍內自動做、哪些只產草稿由具名的人放行。上線前要刻意讓它失敗一次，看它在哪裡停下。

請先問我：這個助手要處理的流程、連上了哪些工具、目前的測試狀況。
接著：
1. 逐一列出助手在每個工具裡實際會做的動作；
2. 依「可以自動做」「限定範圍內自動做」「只產草稿，由具名的人放行」三層分類，說明理由，並為第二層寫出範圍條件；
3. 為第三層的每個動作，列出放行畫面要呈現的資訊和負責人；
4. 設計四個失敗情境的試跑：必要欄位缺失、來源互相矛盾、核准者沒有回應、外部系統失敗，以及每個情境預期它應該停在哪裡。
不要替我實際修改工具設定，只給分類和測試計畫。
廣告

Share

分享這篇微課

如果這篇剛好解開一個工作卡點，可以分享給也在判斷 AI 怎麼用的人。

參考來源