把表单数据交给程序：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，现在负责解释数据。