隨機分組產生器的 API 替代方案，是一種把任何名單拆成均衡小組的方式，無需呼叫託管端點、管理 API 金鑰，或受限於速率限制。它能得到相同的結果——將一份姓名清單公平地分成你所指定數量的小組——只是這次是由 JavaScript 在你目前的瀏覽器分頁中完全執行，而不是由遠端服務完成。因為資料完全沒有離開頁面，這個工作流程非常適合班級名單、工作坊與會者、志工團體，以及任何你不想上傳的姓名集合。代價是你必須放棄 API 通常會附帶的功能:跨裝置共享結果、伺服器端的歷史紀錄、與帳號綁定的配額，以及 webhook 整合。對大多數教室、遊戲夜和團隊建立的情境而言，這些功能其實並不需要，因為唯一需要分組結果的人，就是站在房間前面的那位。這正是瀏覽器本機隨機分組產生器所填補的缺口，而「Random Team Generator」正是為這個缺口而打造的。
隨機分組產生器的 API 替代方案究竟代表什麼
大多數分組 API 都遵循一個熟悉的流程:註冊帳號、產生 API 金鑰、以 POST 請求送出姓名清單和小組數量、為超出免費額度的呼叫付費，然後把回應寫入你自己的應用程式。當一款應用程式本來就需要後端、必須讓多位使用者看到相同的分組，或是必須把結果記錄下來供日後查看時，這個流程運作得很好。
瀏覽器式的替代方案則移除了真正分組之前的所有步驟。你打開一個頁面，把名單貼上去，選擇想要幾組，然後在同一個視窗中讀取結果。Random Team Generator 採取的就是這種做法:沒有任何資料被上傳、不需要帳號，也沒有任何已記錄的速率上限，因為根本沒有一個共享服務可以被塞爆。有趣的問題不在於這個替代方案能否取代 API——在許多真實的工作流程中它確實可以——而在於在你的特定情境裡，你真正在意的是哪些權衡取捨。如果你從分組產生器想要的，只是把一份姓名清單公平地分組，那麼 API 就是多餘的負擔。
如何在沒有 API 的情況下產生均衡小組
從打開頁面到大聲唸出分組結果，完整流程不到一分鐘。
- 在名單欄位中，每行貼上一個姓名，或用逗號分隔姓名。
- 輸入一個正整數的小組數，不得超過名單的大小。
- 點選「Generate teams」(產生小組)，然後檢視並分享這些均衡的小組。
名單欄位可以直接接受從試算表或電子郵件簽名檔複製而來的文字。頭尾的空白會被去除，空行和多餘的逗號會被忽略，而重複的姓名會保持重複，因此如果休閒活動需要刻意保留重複項目，你可以直接留著。小組數欄位只接受正整數，而且表單會拒絕大於非空項目數量的數字，以避免產生空小組。如果在第一次分組之後出席情況有變動，請編輯名單並再次點選「Generate teams」，而不是手動在不同小組之間搬動人員。
為何本機瀏覽器工具可以取代 API 呼叫
當託管式 API 是替代選項時，有三個特性值得關注。
隱私。許多名單包含你不希望離開筆電的姓名:學生、客戶、未成年者、員工，或是封閉活動的參與者。Random Team Generator 的每一步都在目前的瀏覽器中執行，因此姓名不會被送到伺服器、不會被存進帳號，也不會被一個你無法掌控的組織者看見。對一般教室和遊戲夜的使用情境來說，這通常就是決定性的因素。
簡便。API 的路線要求你閱讀文件、安裝用戶端函式庫、處理驗證標頭、捕捉 HTTP 錯誤，並解析 JSON。瀏覽器的路線只要求你貼上並點擊。當分組結果的唯一消費者就是房間裡的一個人時，API 的彈性是一種負擔，而不是價值。一份關於在本機產生均衡隨機小組的姊妹指南，從略為不同的角度說明了相同的邏輯，如果你想在轉換工作流程之前聽聽另一種看法可以參考。
成本與可靠性。託管式分組端點通常會在提供一個小小的免費額度後，把這項服務綁進付費方案，而這個額度會以你無法控制的行事曆週期重置。瀏覽器工具沒有額度可以觸頂、不需要輪換 API 金鑰，也沒有狀態頁需要監控。頁面要嘛載入，要嘛不載入，而你可以一直重新整理直到它載入，完全不會影響任何第三方的帳單儀表板。
底層運作:本機隨機性與公平性
對非託管式隨機工具最常見的疑慮就是偏差:洗牌真的公平嗎?Random Team Generator 以三種具體方式回應這個問題。
在執行任何隨機化之前，空白的項目會先被移除，因此草率的貼上動作不會讓小組失衡。剩下的姓名接著以一個無偏誤的 Fisher-Yates 過程進行洗牌，它會走訪陣列一次，把每個位置和一個隨機選出的較後位置交換。這個演算法就是教科書上的洗牌法:輸入的每一種排列出現的機率完全相等，而且不會從前一次的執行留下任何隱藏的規律。隨機值取自瀏覽器的 Crypto.getRandomValues 來源，這是同一個也用於密碼產生器和 session token 的 Web Crypto 原生機制，而不是部分較舊工具仍在使用的較弱 Math.random 來源。洗牌演算法本身在 Fisher-Yates 洗牌法概觀中有詳細說明，如果你想驗證其中的數學可以參考。
洗牌之後，腳本會隨機挑選哪些小組標籤獲得額外的一個名額，然後把洗好的陣列切成長度最多相差一的小組。一個計算過的例子:七個人分成三組。七除以三餘數為一，代表會有兩組各拿到兩個人，一組拿到三個人。工具會把較大的那一組指派給隨機選出的標籤，讓不平衡的結果不會總是落在 Team 1。每個非空項目都會被放到剛好一個小組裡，而且再次點選「Generate teams」會產生一個全新的獨立分組。
API 服務 vs. 瀏覽器工具:功能比較
| 能力 | 託管式分組 API | 瀏覽器本機工具 |
|---|---|---|
| 帳號或註冊 | 需要才能取得 API 金鑰 | 無 |
| 名單的處理位置 | 遠端伺服器 | 目前的瀏覽器分頁 |
| 免費層級之後的成本 | 按次計費或月費方案 | 免費，沒有名額限制 |
| 隨機性來源 | 伺服器端的種子或函式庫 | Web Crypto 的 getRandomValues |
| 輸出可跨裝置可見 | 可以，透過儲存在任何地方的 API 回應 | 只能在目前分頁中 |
| 伺服器端的歷史或紀錄 | 啟用時會有 | 無 |
| 需要網路往返 | 每次分組都需要 | 只需要載入頁面 |
| Webhook 或回呼支援 | 通常會有 | 無 |
| 一次性分組的設定時間 | 數分鐘(驗證、payload、解析) | 數秒 |
在會議室裡進行單次分組時，右邊那一欄在每一項都勝出，除了跨裝置可見性與 webhook 支援——而這兩項功能正好是現場分組不需要的。
什麼時候 API 仍然是較好的選擇(以及什麼時候不是)
瀏覽器工具並不是萬能的替代方案。當分組結果必須同時送到多個裝置，而且你不想分享畫面;當分組是更大自動化流程的一部分(例如每晚從校務系統抽取的班級名單);當你的組織需要一份誰在哪個小組、何時的稽核紀錄;或是你受限於只能從後端服務而非瀏覽器讀取結果時，託管式 API 仍然是正確的選擇。
除此之外——破冰活動、課堂練習小組、讀書會、臨時運動比賽、工作坊分場、志工輪班分配——API 的成本、隱私和設定負擔都殺雞用牛刀。Random Team Generator 正是為這種日常情境而生:不需要帳號、頁面載入之後無需任何網路呼叫、你這邊也不需要寫一行程式碼。對一般的遊戲和非正式工作坊來說，均衡的隨機小組往往能消除手動挑人的尷尬，而一個透明、於瀏覽器本機完成的抽籤，就是抵達那裡最簡單的方式。
想看更深入的說明，請參考 簽名產生器 API 替代方案:瀏覽器選項。