Structured Output Guide
如何把 Twitter 搜索结果整理成结构化 JSON，避免流程停在复制链接和截图上
当团队把 search result 保存成稳定记录，而不是零散截图和 URL 时，这些结果才真正开始好用。很多监测、研究和 AI 工作流，都是在这一步之后才开始变得可扩展。
1. 先定义一条记录到底长什么样
很多团队在还没决定结构之前就开始存结果，最后得到的是很难复用的 export。
更稳的方式，是先定义最小 JSON 结构，比如 post id、URL、query、account handle、timestamp 和 review 字段。
- 先定义必备字段，再开始保存结果。
- 结构尽量小而清楚。
- 至少留一个 workflow status 或 routing 字段。
2. 保存检索上下文，而不是只保存帖子内容
单条帖子本身不够。团队通常还需要知道它是被什么 query 命中的、什么时候采集的、来自哪个账号。
这些上下文，才是后面做 triage、聚类或 AI 摘要时真正有用的部分。
- 保存 matched query 或 rule name。
- 保存 source handle 和 timestamp。
- 保存 canonical post URL 或 id。
3. 提前加上轻量 review 字段
当团队能在结构化 JSON 里提前放进 priority、watchlist status、source type 或 review note，这些记录就更容易进入下一步工作流。
否则这些 JSON 很容易变成死档案。
- 加一个 review status 字段。
- 保留为什么它重要的短备注。
- 重复出现的路由判断尽量用稳定枚举。
4. 让输出容易送进后续系统
这份 schema 最好足够稳定，能直接喂给 dashboard、AI 摘要、告警或重复研究流程，而不用后面再改字段。
很多时候，这就是一次性导出和可重复工作流资产之间的区别。
- 优先用稳定字段名，不要过度炫技的嵌套结构。
- 文本字段尽量干净，方便后续摘要。
- 能复用同一结构时，就不要为每个小工作流都造一套新 schema。
团队在实现这条流程时最常问的几个问题
这些问题通常会在团队从单次测试走向可重复 Twitter / X 数据采集时冒出来。
最常用的字段通常有哪些？
通常是 post id 或 URL、matched query、source handle、timestamp，以及一个 status 或 priority 字段。
要不要保存完整 raw payload？
很多团队会在底层存 raw payload，但日常工作流通常还是需要一份更小、更好复用的 review-ready JSON。
为什么这一步对 AI 工作流这么关键？
因为 AI 摘要在保留检索上下文和来源元数据时，效果通常会比只输入零散文本片段更稳。
通常会一起看的实现型页面
如果下一步是决定 AI-ready record 该存哪些 metadata，可以继续看这页。
如果你想先从字段层看清楚哪些值得保留，可以继续看这页。
如果结构已经清楚，下一步是采集深度，可以继续看这页。
如果你想先看 search-first 工作流背后的能力页，可以继续看这页。
把 Twitter / X 公开帖子做成团队能反复运行的流程
如果这些问题已经开始频繁出现在你的流程里，可以去验证 tweet search、账号复核或 timeline 接入路径，并把输出接进稳定团队循环。