账号记录
如何为 watchlist 归一化 Twitter account record，让来源复核始终保持一致
当每条 workflow 用不同方式保存账号上下文时，watchlist 很快就会失控。归一化后的 account record，可以让 founder tracking、competitor review 和 source validation 用同一套方式解释“为什么这个账号重要”。
1. 先搭一个稳定 identity layer
一条 watchlist record 通常至少需要一个稳定账号标识、一个给人看的 display layer，以及一个能追溯最近 profile context 的位置。
先有这个 anchor，再叠团队自己的标签，会稳很多。
- 保留一个稳定 account identifier。
- 把当前 display handle 分开保存。
- 让最近 profile context 可追溯。
2. 把 watchlist 含义保存成 workflow metadata
真正最有用的 watchlist 字段，往往是在解释“这个账号为什么在这里”：competitor、founder、partner、escalation source 或 recurring research source。
这层含义更适合保存成 workflow metadata，而不是混进 raw profile facts。
- 显式保存 watchlist reason。
- 把 review priority 和 raw profile data 分开。
- 跨 workflow 复用同一套 source-type label。
3. 把 timeline review state 接进 account record
当 account record 能显示上次何时复核、发生了什么变化、以及是否需要下一次 timeline check 时，watchlist 才真正开始变得可运营。
否则它很容易退化成一份静态名单。
- 保存 last-review timing。
- 保留一条“为什么这个账号仍然重要”的短说明。
- 记录是否需要下一次 timeline review。
4. 尽量让不同团队共用同一套 account shape
product、research 和 growth 可能会以不同方式使用同一个来源账号，但底层结构通常更适合保持稳定。
共享的 account structure 会减少很多下游翻译成本。
- 跨 watchlist 复用同一套 base account schema。
- 团队特有注释单独加，不要改 core shape。
- account schema 含义变化时记得 version。
接口已经能跑，但流程还不稳时，团队通常会问这些问题
这些问题通常会在团队开始重复运行同一条 Twitter / X 任务之后出现。
什么样的 account record 才算适合 watchlist？
有稳定 identity layer，再加上解释它为什么重要、什么时候该复核的 workflow 字段。
watchlist label 应该混进 raw account field 吗？
通常不该。competitor、founder 或 escalation source 这类标签更适合单独保存。
为什么 watchlist 也需要归一化？
因为 timeline review、alerting 和 analyst note 都会因为读取同一套 account shape 而变得更顺。
这一环通常会一起看的页面
如果你想看 watchlist 实际怎么跑，可以继续看这页。
如果你想先看哪些 account field 值得进入归一化层，可以继续看这页。
如果 source review 还在决定哪一步先跑，可以继续看这页。
如果你想回到 account lookup 能力页本身，可以继续看这里。
把 Twitter / X 公开帖子做成团队能反复运行的流程
如果这些问题已经开始频繁出现在你的流程里，可以去验证 tweet search、账号复核或 timeline 接入路径，并把输出接进稳定团队循环。