Field Selection Guide
哪些 Twitter API 返回字段最值得保留做监测，避免什么都存、但工作流还是不好用
很多监测系统越做越难维护，不是因为字段太少，而是因为什么都存，却没有围绕实际判断设计。更稳的方式，是只保留那些真正支持 query traceability、source review、priority 和 routing 的字段。
1. 先保留解释检索来源和 source 的字段
大多数 monitoring record 在保留 matched query、source account 和 collection time 时，会明显更好用。
没有这些字段，团队很快就会说不清一条结果为什么会进入工作流。
- 保存 matched query 或 rule name。
- 保存 source handle 或 account id。
- 保存 post id、URL 和 collection time。
2. 加上最少但必要的 routing 和 priority 字段
监测流程通常不只是拿到结果，还要决定哪些要 review、哪些要 escalate、哪些直接忽略。
这时候 priority、review status 和 source-type tag 往往最有价值。
- 至少有一个 review status 字段。
- 至少有一个 priority 或 severity 字段。
- 同一条流程覆盖多类账号时，最好加 source-type tag。
3. raw text 和 workflow interpretation 最好分开
帖子原文应该保持干净，方便后面做摘要或 audit；解释性字段应该单独存，方便团队以后重跑 review 时不污染源记录。
当同一批记录还要继续喂给 AI 时，这一点尤其重要。
- raw post text 和 note 分开存。
- 人工或 AI 标签用明确字段保存。
- 不要把 source content 和 review conclusion 混在一起。
4. 工作流变了，字段也要顺手复核
launch monitoring、support monitoring 和 founder watchlist 并不一定需要同一套 schema。
更稳的团队，通常会在工作流变化时一起复核字段，而不是把 schema 当成永远不动的东西。
- 监测任务变了，就顺手复核 schema。
- 把日常 review 根本不用的字段从 working schema 里拿掉。
- 即使 raw storage 很大，day-to-day schema 也尽量保持小而清楚。
团队在实现这条流程时最常问的几个问题
这些问题通常会在团队从单次测试走向可重复 Twitter / X 数据采集时冒出来。
大多数监测流程里最常用的字段有哪些？
通常是 matched query、post id 或 URL、source identity、timestamp、review status，再加一个 priority 字段。
是不是应该把所有字段都存下来？
底层 raw storage 可以大一些，但 review-ready 工作流通常会因为更小、更明确的工作 schema 而更好用。
字段选择为什么这么重要？
因为 schema 决定了这些记录以后到底能支持监测、路由和 AI review，还是只会变成没人再看的导出文件。
通常会一起看的实现型页面
如果下一步是围绕这些字段设计记录结构，可以继续看这页。
如果这些字段还要继续支持 AI 任务，可以继续看这页。
如果字段选择需要回到完整 mention 工作流里看，可以继续看这页。
如果你想把监测字段需求直接映射到 TwtAPI 返回结构，可以继续看文档。
把 Twitter / X 公开帖子做成团队能反复运行的流程
如果这些问题已经开始频繁出现在你的流程里，可以去验证 tweet search、账号复核或 timeline 接入路径，并把输出接进稳定团队循环。