把表單資料交給程式：Query、Summary 與 CSV 工作流

存下提交只是半個後端。決定資料有沒有用的，是把它取回來的那一半——給人翻、給腳本算、給儀表板畫、給 Agent 讀。

一個 FormLM 端點給你三個出口，選對出口大致就完成了設計。下面把整套工具攤開講：哪些迴圈和排程，能讓「積著的資料」變成「幹活的資料」。

三個出口

• 資料後台——每個發佈後的表單自帶：翻提交、看記錄、匯出 CSV。適合人，適合臨時取數。
• 查詢端點——GET /query?page=1&size=20，把存下的記錄按分頁 JSON 回傳，一頁最多 1,000 筆。適合腳本和同步。
• 彙整端點——GET /summary 直接回答總量問題：計數、分布、整體統計。適合不需要原始資料列的儀表板。

同一份資料，三種形態。週一早上「工作坊迴響怎麼樣」是一次 CSV 開啟；每晚同步進表格存檔的是一個查詢迴圈；常駐的結果小元件則是一次 summary 呼叫加一張雷達圖。

安全地把所有記錄翻完

查詢端點是分頁的，所以正確姿態是一個「短頁即停」的迴圈，而不是硬編碼「取第 5 頁碰運氣」。兩行 bash 加 jq，就能把全量歷史拉到本機檔案：

page=1; out=all.jsonl; : > $out
while :; do
  resp=$(curl -s "https://formlm.me/api/v3/share/<your-token>/query?page=$page&size=1000")
  echo $resp | jq -c '.records[]?' >> $out
  n=$(echo $resp | jq '.records | length')
  [$n -lt 1000 ] && break
  page=$((page+1))
done

換成 Python 或平台腳本，也只多幾行，思路相同。批次拉取就把 size=1000 用頂；互動看板則把它調小，別讓一條慢記錄卡住視圖。如果只要計數和分布，連迴圈都省了——/summary 早在伺服器端把這筆帳算好了。

不動原始資料列，先拿彙整

儀表板很少真的需要每筆提交——它要的是「本週 342 份，三個構面均值 3.8 / 2.9 / 4.1，分檔占比 12% / 41% / 47%」。summary 端點賣的就是這個取捨：一次 GET，不分頁、不用串接。低刷新率的小元件直接對準它，整層報表就值一次 fetch 加一張圖。

欄位漂移是特性——讀出防禦性

因為 payload 裡的陌生鍵會自動建欄，一個線上端點的欄位集是隨頁面演進成長的。舊記錄對新鍵沒有值，這不是髒資料，是歷史。三個習慣讓管線穩著跑：

• 缺失的鍵一律當 null——遍歷欄位全集，而不是第一筆記錄恰好有哪些欄位。
• 從端點重讀 schema——?help 回傳目前欄位的 Markdown 清單；在同步腳本裡做一次 diff，新欄落地時你會第一時間知道。
• 鍵名要起得講究——打錯的鍵不會報錯，它會安靜地長成一欄；?help 的 diff 就是你的那根絆線。

排程匯出：關聯式表格和 BI 都要吃

對住在表格裡的工作團隊，把查詢迴圈掛進每晚的 cron，寫成 CSV 或往表格追列，讓表單退化成無聊的基礎建設。小需求還有個更簡單的檔次——資料後台裡手動匯出 CSV——所以量真的到了才值得自動化。至於能直連 HTTP 資料源的 BI 工具，查詢端點跟它們說的是同一種語言：帶穩定記錄 ID 的 JSON。

把結果餵回給 Agent

最讓人意外的那個出口：Agent 也能消費 Agent 產出的東西。把一個端點的 ?help 貼進對話，它就有了 schema；灌一份 /summary 的 JSON，它能把這週的結果講成人話；把查詢迴圈的輸出給它，它就能寫報告。存放不再是表單生命的終點，而是一個分析閉環的起點——當初收資料的那個 URL，現在負責解釋資料。