Structured Output Guide
如何把 Twitter 搜索结果整理成结构化 JSON，避免流程停在复制链接和截图上
当团队把搜索结果保存成稳定记录，而不是零散截图和链接时，这些结果才真正开始好用。很多监测、研究和 AI 流程，都是在这一步之后才开始变得可扩展。
2026-04-20
1. 先定义一条记录到底长什么样
很多团队在还没决定结构之前就开始存结果，最后得到的是很难复用的导出文件。
更稳的方式，是先定义最小 JSON 结构，比如帖子编号、链接、命中的搜索条件、账号标识、时间戳和复核字段。
- 先定义必备字段，再开始保存结果。
- 结构尽量小而清楚。
- 至少留一个流程状态或路由字段。
2. 保存检索上下文，而不是只保存帖子内容
单条帖子本身不够。团队通常还需要知道它是被什么搜索条件命中的、什么时候采集的、来自哪个账号。
这些上下文，才是后面做分流、聚类或 AI 摘要时真正有用的部分。
- 保存命中的搜索条件或规则名称。
- 保存来源账号和时间戳。
- 保存标准帖子链接或编号。
3. 提前加上轻量复核字段
当团队能在结构化 JSON 里提前放进优先级、重点名单状态、来源类型或复核备注，这些记录就更容易进入下一步流程。
否则这些 JSON 很容易变成死档案。
- 加一个复核状态字段。
- 保留为什么它重要的短备注。
- 重复出现的路由判断尽量用稳定枚举。
4. 让输出容易送进后续系统
这份结构最好足够稳定，能直接喂给看板、AI 摘要、告警或重复研究流程，而不用后面再改字段。
很多时候，这就是一次性导出和可重复流程资产之间的区别。
- 优先用稳定字段名，不要写过度炫技的嵌套结构。
- 文本字段尽量干净，方便后续摘要。
- 能复用同一结构时，就不要为每个小流程都造一套新结构。
团队在实现这条流程时最常问的几个问题
最常用的字段通常有哪些？
通常是帖子编号或链接、命中的搜索条件、来源账号、时间戳，以及一个状态或优先级字段。
要不要保存完整原始返回？
很多团队会在底层存原始返回，但日常流程通常还是需要一份更小、更好复用的 JSON 记录。
为什么这一步对 AI 工作流这么关键？
因为 AI 摘要在保留检索上下文和来源元数据时，效果通常会比只输入零散文本片段更稳。
通常会一起看的实现型页面
把 Twitter / X 公开帖子做成团队能反复运行的流程
如果这些问题已经开始频繁出现在你的流程里，可以去验证帖子检索、账号复核或历史发言接入路径，并把输出接进稳定团队循环。