把規格決策做成團隊問卷:選載體的三個條件
要讓 AI 幫忙收一份團隊問卷,載體由三個條件決定:AI 能不能建、能不能讀回結果、填答者要不要帳號。記四種載體(Artifact、Teams webhook、Google 表單、monday 表單)的真實限制,連接器與 API token 兩條獨立通道,以及排程建了又拆的取捨。
定義:要讓 AI 參與收一份團隊問卷(自動建題、自動回收答案),載體怎麼選由三個條件決定——AI 能不能建這份問卷、AI 能不能讀回結果、填答的人要不要有帳號。三個條件會直接把候選載體刷掉大半。
一套零件承認系統改版時,規格裡有 8 個設計決策要團隊拍板(例如:會簽被退回後要不要全部重簽、表格的某一列能不能刪)。目標很具體:讓成員點選作答而不是在聊天軟體打字回覆,並讓 AI 自動把答案收回來、彙整出大家意見分歧在哪。難點不在出題,而在「用什麼東西承載這份問卷」——這篇記的是選載體繞的路,以及每個候選的真實限制。
選載體的三個條件
把「AI 要參與收問卷」拆開,載體必須同時過三關:
- AI 建得出來嗎:AI 手上有沒有工具能直接把這份問卷做出來,還是得靠人手動建。
- AI 讀得回結果嗎:答案交出來以後,AI 有沒有辦法把提交結果撈回來彙整,還是得靠人複製貼上。
- 填答的人要不要帳號:團隊成員打開連結就能填,還是得先有某個平台的帳號才進得去。
四個候選各卡在不同關卡:
| 載體 | AI 建 | AI 讀回 | 免帳號填 | 卡在哪 |
|---|---|---|---|---|
| Claude Artifact 互動問卷 | 可 | 不可 | 否 | 答案傳不回來、觀看者要有帳號 |
| Teams webhook 卡片 | 可(發) | 不可 | 是 | 只能發不能收 |
| Google 表單 | 不可 | 不可 | 是 | 工作環境沒接 Google |
| monday 表單 | 可 | 可 | 是 | 三關全過,勝出 |
Artifact 為什麼出局
第一個嘗試是用 Claude Artifact 做互動問卷。它其實做得出來:單頁互動網頁、點選作答、還能產生摘要一鍵複製。出局是因為兩個硬限制。
一是 CSP 擋掉所有對外連線——答案傳不回來。就算頁面裡寫程式去呼叫一個 webhook 把答案送出,也會被瀏覽器擋掉。二是觀看者要有 Claude 帳號才打得開這個頁面。
轉彎是被一句追問帶出來的:使用者問「如果用 webhook 呢?不過這個問卷要有帳號的人才能讀對吧?」——這句話同時命中上面兩個限制(送不出去、要帳號),讓「Artifact 不是對的載體」變得清楚,才去找別的。
Teams 的 webhook 只能發不能收
順著 webhook 的念頭往下想,得先把它的角色講清楚:它只能發、不能收。當時 AI 手上的 Teams 工具只有讀訊息、沒有發訊息的能力,incoming webhook 恰好補上「往頻道發訊息」這個缺口。但反過來——webhook 發出去的卡片就算帶按鈕,使用者按了,答案也收不回來。要收得回,得另外架一個 bot 或一整套 Power Automate 流程,為了收 8 題答案做這些,工程不划算。
Google 表單為什麼直接出局
Google 表單本來很適合「點選作答、免帳號填」,但這個工作環境沒有接任何 Google 服務。結果是 AI 既建不了表單、也讀不回結果——兩頭都要人工,等於 AI 沒參與到,失去自動化的意義。這關卡的不是工具本身,是它沒接進這個環境。
monday 表單勝出的條件
monday 表單三關全過:AI 有 monday 的工具能直接建表單、也能撈回提交結果;團隊本來就在 monday 上工作(方案含表單模組 WorkForms);填答者用連結就能填,不用額外帳號。
值得記的是這個結論怎麼下的:AI 不是憑「monday 應該可以吧」的印象推薦,而是實際去查了使用者的 monday 帳號狀態——方案等級、成員數、Forms 模組有沒有開——確認條件都成立才建議。載體選擇建立在查證上,不是印象。
選定之後:
建表單:8 題單選,每題附上背景說明、並標出「規格推薦」的選項;每題再加一個備註欄讓人補充理由;姓名設為必填。
發送:使用者在 Teams 頻道自己建了一個 Power Automate「收到 Webhook 要求時張貼到頻道」的流程,把產生的網址給 AI;AI 用指令對那個網址發一張 Adaptive Card(標題、說明、一個「開始作答」按鈕)進頻道,得到 202 回應代表送達。
兩條獨立通道:連接器授權 vs API token
收答走的是 API token,而不是 連接器授權——這兩條是彼此獨立的通道。過程中有個插曲能佐證:使用者真的把 monday 連接器換到另一個帳號登入,而 API token 那條完全不受影響,收答照常。也就是說,「連接器 + token」等於兩個身分並行,動其中一條不會牽動另一條。日後若遇到「換了登入卻發現某條路還通(或還斷)」的困惑,先分清楚是哪條通道在作用。
排程建了又拆:自動化不是越多越好
AI 一度把自動化做滿:搭了定時自動收答(工作日一天收五次)、有新回覆就推播、答案收齊自動彙整。使用者看了以後拆掉排程、改成手動觸發,理由是「回覆時間不定、人數也不定,我自己說一聲去收就好」。
重點在於:觸發條件不穩定時,人主動叫一聲比機器照表空轉更合理。排程適合「固定節奏、可預期」的事;當「什麼時候該收」本身無法預測,把觸發權留在人手上反而省事。自動化的價值看觸發條件穩不穩,不是看鋪了多少。
兩個踩雷
備註欄被藏起來:monday 表單預設「一頁一題」,結果每題的備註欄被拆到「下一步」那一頁,填的人以為根本沒有備註欄,切換成一頁式(Classic)版面就解決。
選項加不進去:表單題目背後接的是 monday 的 status 欄位,而表單 API 不允許直接往這種欄位加選項(會回 Failed to patch board column)。繞路的做法是:先建一筆暫存資料、用 create_labels_if_missing 這個設定讓欄位在存資料時自動長出「其他做法」這個新標籤,再把那筆暫存資料刪掉——標籤(也就是表單選項)會留下來。想給每題多加一個「其他」選項時,就是用這招繞過 API 的限制。
人機分工
方向決策都是使用者訂定:選 monday 當載體、拆掉排程改手動、每題加一個「其他」選項。AI 負責的是把每個載體的限制攤開成一張對照表供判斷、實作建表發送收答、以及排除上面兩個踩雷。促成 Artifact 出局的那句追問也來自使用者;AI 提的方案(先試 Artifact、後改 monday)如實記為 AI 提出。