> ## Content Index
> Fetch the complete content index at: http://localhost:2368/llms.txt
> Use this file to discover other available public pages before exploring further.

# 把規格決策做成團隊問卷:選載體的三個條件
- URL: http://localhost:2368/spec-decisions-to-team-form/
- Published: 2026-07-10T08:45:10.000Z
- Updated: 2026-08-23T13:54:26.000Z
- Description: 要讓 AI 幫忙收一份團隊問卷,載體由三個條件決定:AI 能不能建、能不能讀回結果、填答者要不要帳號。記四種載體(Artifact、Teams webhook、Google 表單、monday 表單)的真實限制,連接器與 API token 兩條獨立通道,以及排程建了又拆的取捨。
- Author: yuchang23
- Tags: #wiki, #wiki-experience

> **定義**:要讓 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 提出。

## 相關條目

- [零費用的 AI 自動化管線模式](https://yuchang23.com/zero-cost-ai-automation-pipeline/?ref=localhost)
- [同仁回饋用問題卡收斂](https://yuchang23.com/feedback-issue-cards/?ref=localhost)
- [雲端平台會攔截認證標頭的地雷](https://yuchang23.com/auth-header-interception/?ref=localhost)