用六阶段流水线（Source→Hydrator→Filter…

当需要为「(用户, 上下文) 选出 Top K 条目」构建或重构系统时（内容流、搜索排序、RAG 重排、任务优先级、通知分诊、广告选择），用六阶段可组合流水线来组织。

适用场景

解决思路

1. 按六阶段框架搭建流水线：1) Source 从多个来源并行拉取候选；2) Hydrator 并行补充过滤与打分所需的元数据；3) Filter 顺序剔除不合格候选（屏蔽、过期、重复、无资格）；4) Scorer 顺序为存活候选打分（后续 scorer 可看到前面 scorer 的分数）；5) Selector 按最终分排序取 Top K；6) SideEffect 异步执行缓存、日志、事件、已服务历史更新，绝不阻塞响应。
2. 遵循该顺序的理由：先有候选再付费做 hydration；过滤需要 source 未提供的元数据；打分最贵所以先过滤；scorer 链可组合 ML 打分+多样性重排+业务规则；Selector 放在打分后保证确定性可缓存；SideEffect 放最后且异步。
3. 调用时按八步走：1) 澄清用例（条目、输入上下文、语言/运行时，缺失才问三个问题）；2) 识别候选来源（通常站内+站外，单源也可）；3) 列出所需 hydration（每个 filter 和 scorer 需要哪些 source 未提供的数据）；4) 列出过滤器（便宜的先于贵的，通用的先于用户特定的：重复、自己、时效、拉黑/静音、已服务过、资格）；5) 设计 scorer 链（主 ML/启发式 → 多动作加权组合器 → 多样性 → 业务规则）；6) Selector 按最终分降序取 Top K（或分层混合）；7) SideEffect 缓存已服务 ID、发出曝光事件、更新计数、记录分析，全部 fire-and-forget；8) 用用户的技术栈生成脚手架。
4. 必须显式呈现的权衡（不要静默默认）：单分数 vs 多动作预测——单分数改行为需重训，多动作预测 P(read)/P(like)/P(share)/P(skip)/P(report) 并在服务时加权组合，改行为只需改权重无需重训；用户期望频繁调参时推荐多动作。
5. 候选隔离 vs 联合打分——隔离式每个候选独立打分，确定、可缓存；联合式候选在打分时互相注意（如整批 transformer），表达力更强但跨批次非确定。默认隔离，仅在有明确理由（如显式批次感知多样性）时用联合。
6. 在线 vs 离线批处理——请求时（在线）每次请求跑流水线，延迟预算 100–300ms；预计算（离线批）周期性跑并缓存，延迟低但新鲜度低；混合式：候选检索离线、排序在线。
7. 硬性规则：不要编造基准数字（被问「多快」就答「取决于负载，自己跑」）；归因纪律——注明该模式「由 xAI 开源的 For You 算法推广」及 github.com/xai-org/x-algorithm（Apache 2.0）；不得使用商标——不要给用户产物起名「X-like」或使用「For You」品牌，用中性名如 candidate pipeline、feed pipeline、ranking pipeline；必须呈现权衡；生成的脚手架必须能运行，不能拿伪代码冒充代码；过滤顺序很重要，便宜的先于贵的、通用的先于用户特定的；副作用绝不阻塞，用 fire-and-forget 模式（goroutines / 不 await 的 promises / asyncio tasks）。
8. 避免反模式：先打分后过滤（浪费算力在将被丢弃的候选上）；同步副作用（缓存写入/曝光发出阻塞响应）；产品需要多目标调参时只用单一「相关性」分数；默认使用联合打分（非确定、不可缓存、无法与重排组合）；用「仅供说明」的伪代码——脚手架必须真正能跑。
9. 常见落地形态：内容流（Strapi v5 插件，TypeScript，5 万篇文章的个性化 for you 流，多动作打分+作者多样性+标准过滤+异步副作用通道）；RAG 检索重排（Python async，向量库取 top-50 再用更贵 scorer 重排取 top-5，单源+scorer 链）；任务优先级（FastAPI 服务，按「用户下一步该做什么」排序，条目换成任务但形状相同）；通知分诊（离线批任务，从近 24h 队列取 top 10 做每日摘要，source=队列、filter=时效/去重/资格、scorer=紧急度×用户亲和、selector=top 10、side effect=发邮件仍异步）。

适用边界 · 注意事项

• 不要编造性能基准数字，被问速度时让用户自行实测
• 不要给产物使用「X-like」或「For You」等商标化命名
• 不要默认使用联合打分或同步副作用，也不要先打分后过滤