ux-activity-feed

Activity Feed 技能

此技能的工作方式（请先阅读）

这是一项生成式技能。信息流的作用是呈现重要内容，让杂音逐渐淡去——但默认设置恰恰相反：每条内容都塞满所有可用字段，时间戳精确刺眼，每一行都配上所有社交控件，通知未经分组、一条接一条地响起；而全新用户在决定是否留下的关键时刻，却只看到空白的信息流。此外，还有一个影响重大的前置选择——按时间排序还是按算法／排名排序——团队往往会在无意中做出决定。因此，此技能会按以下步骤进行：

1. 确定信息流类型及其用途——之后很难再更改按时间排序还是按排名排序的选择，而且这会重塑后续所有设计。
2. 落实始终适用的核心原则——精心筛选每条内容，确保文本易读，弱化时间戳，绝不显示空信息流，并显示刷新状态。
3. 呈现取决于情境的决策（通知聚合、关注推荐、单条内容控件）及其权衡。

随后，它会**移交给 ux-aesthetics-audit、ux-heuristics-audit、ux-accessibility-audit、ux-microcopy-audit、ux-dark-patterns-audit 和 ux-mobile-responsiveness-audit**进行验证。

范围与组合（依据 docs/orchestration-policy.md §9）：此技能覆盖信息流屏幕及其内容条目，并组合较小范围的技能，而非重新推导其内容。核心子技能（作为信息流的一部分构建）：通过 ux-cards 处理每条内容的卡片结构。**负责某个子部分的同级技能（交由其处理）：**通知组件的行为交给 ux-notifications-and-toasts，加载器／骨架屏交给 ux-loaders-and-progress（若涉及，它们负责相应子部分）。下游技能（提供选项，不自动构建）：通过 ux-empty-states 设计空信息流屏幕。**继承而非重新生成：**如果已有设计系统，就使用其设计令牌中的颜色、字体和间距——只有从头开始设计时才设置这些内容。

---

步骤 0 — 设计前确定上下文

如果尚不清楚，请先询问；若在没有答案的情况下继续，请说明所采用的假设：

• 按时间排序还是按排名排序？ 按时间排序（最新→最早）呈现真实时间线——适用于事件发生时间才是重点的场景（例如交易记录、团队活动历史）。按排名／算法排序则根据相关性、热度、赞助内容或编辑精选进行筛选——适用于值得查看的内容比新近程度更重要的场景。重要警告：不要先发布按时间排序的信息流，再打算以后用算法替换——这种切换会严重影响用户体验。现在就慎重选择。
• **信息流的用途是什么？**社交互动、交易／账户更新，还是通知摘要——这决定每条内容需要哪些控件和内容。
• **新账户或不活跃账户会看到什么？**没有联系人新用户，或活动暂时减少的账户，都会遇到空信息流——请从一开始就做好规划（应用安装后约有 3–7 天的时间窗口来吸引用户）。

---

始终适用的核心原则（几乎适用于所有信息流）

• 精心筛选每条内容——简约胜过面面俱到。 一条信息流内容背后可能有大量数据；只展示用户做出决定并继续操作所需的信息。过于拥挤的行、不匹配的字体和冗长的标签都会分散用户对任务的注意力。清晰的呈现能让用户快速浏览。
• 确保文本清晰易读。 信息流供用户快速浏览，因此应使用大而清晰的字体，并确保背景对比度足够；同时使用无障碍工具进行测试。这对视力障碍用户尤为重要。
• 弱化时间戳。 时间戳是 次要中的次要 信号，只需大致说明“多久之前”，而非精确时间。使用缩写（如“3h”“2d”），不要让它们与内容争夺注意力。
• 绝不显示空信息流。 首次运行时或内容暂时较少时，空白信息流会降低用户参与度。为信息流填充内容：在引导流程中推荐可关注的人、展示热门或趋势内容、提示邀请好友，或鼓励用户完善个人资料——任何能立即带来活动的内容都可以。
• 每条内容只显示必要的控件。 只包含重要的互动方式（例如，社交信息流中的点赞／评论／分享；只读更新信息流则可能无需任何控件），删去其余控件——每增加一个控件，都会增加负担并使内容行显得杂乱。
• 刷新时显示信息流状态。 用户下拉刷新或加载更多时，清晰的加载指示器（旋转图标／骨架屏）能让用户了解系统状态，而不是盯着冻结的屏幕。

---

取决于具体情境的决策（仅供参考，不要自动套用）

决策	适用情形	避免／调整的情形	默认建议
信息流类型：按时间顺序排列还是排名排列	当时效性 本身 就是价值所在时，按时间顺序排列（日志、历史记录、团队实时动态）；当相关性／内容量使单纯按时间排序显得嘈杂时，按排名排列	如果之后会改用算法，不要选择纯按时间顺序排列（这种变化会令用户不满）；如果用户期待的是严格按时间顺序排列的时间线，则不要使用排名排列	根据“何时”还是“什么”更重要来选择，并坚持下去，不要事后再改
汇总／分组通知	面向通知量大或高阶用户时，按时间、类型或互动情况合并相似提醒（“今天有 256 人关注了你”）	通知量较少、每条事件都有独立意义的信息流	当通知量大到会造成轰炸时，再将相似更新分组
个性化关注推荐	社交／发现类产品可根据关系网络、共同兴趣或有影响力的账号推荐个人资料，激发探索欲	避免推荐逐渐形成过滤气泡	提供推荐，同时有意识地混入多元化／跨兴趣内容
每条内容的控件组合	社交信息流：点赞／评论／分享；交易类信息流：可能只需一个“查看”控件，也可能无需控件	不要把社交控件照搬到不需要它们的信息流中	控件应与信息流的用途相匹配；通常越少越好
插入赞助／编辑内容（仅限排名排列）	商业模式需要推广内容时	不要将广告伪装成自然活动	清楚标注赞助／推广内容（→ 暗黑模式）

---

验证结果（编排）

交接时使用各个审查视角对应的可安装技能 name。只有在已安装该技能时才调用；如果未安装，此技能的核心内容已包含这些规则，请继续操作，不要因此受阻。

生成或修订后，将结果交给审查视角进行审核，而不是直接宣布完成。这些是候选审查视角——具体原则由 docs/orchestration-policy.md 设定，也可以将整个内容交由 ux-design-review 审核。此处，heuristics、microcopy 和 dark-patterns 属于 A 级（自动运行）；accessibility、aesthetics 和 mobile-responsiveness 属于 B 级（可选）——在现有设计系统下，aesthetics 不予启用，accessibility 的范围缩小为使用体验；mobile-responsiveness 仅适用于移动端。如果用户调用此技能是为了处理某个特定事项，请遵循其指定范围。

• ux-aesthetics-audit（B 级——可选；在设计系统下不予启用）——信息密度与可扫读性、各条目样式一致、时间戳弱化显示、布局整洁。
• ux-heuristics-audit（A 级）——系统状态可见性（刷新／加载）、优先识别而非回忆、信息流顺序是否符合用户预期（尤其是排序信息流）。
• ux-accessibility-audit（B 级——可选；在设计系统下缩小范围）——便于快速阅读的字号与对比度、控件标签与触控目标、信息流条目的屏幕阅读器朗读顺序。
• ux-microcopy-audit（A 级）——精简时间戳、聚合通知文案（“今天有 256 人关注了你”）、条目标签、空信息流提示。
• ux-dark-patterns-audit（A 级）——信息流特有的陷阱：将赞助内容伪装成自然内容而不予披露、以最大化互动为目的的操纵，以及不断缩小用户视野的过滤气泡。排序应服务于用户，而不只是延长应用使用时间。
• ux-mobile-responsiveness-audit（B 级——可选）——下拉刷新与无限滚动行为、每个条目控件的触控目标、小屏幕上的易读性与单手操作便利性。

如果审查发现存在冲突（例如，业务希望增加推广条目，而用户需要可信的信息流），应以首要任务为准：用户打开信息流是为了了解重要动态——要保证有效信息多于噪声。

---

常见的正确与错误做法

❌ 不要	✅ 应当
默认选择按时间顺序或排序	根据重要的是何时发生还是发生了什么，有意识地选择并坚持
先按时间顺序排列，再改为算法排序	提前决定；突然切换会让用户不适
把所有可用字段都塞进每个条目	精选用户做出判断并继续浏览所需的信息
突兀显示精确时间戳	使用精简、相对的时间显示，并在视觉上弱化
每位关注者／每个赞都单独提醒	聚合类似通知（“今天有 256 人关注了你”）
让新用户面对空白信息流	提供初始内容：关注建议、热门内容、邀请／个人资料提示
每一行都放上所有社交控件	只保留符合信息流用途的控件
把推广内容伪装成自然内容	明确标注赞助／编辑精选条目（→ dark-patterns）
刷新时屏幕冻结	显示加载指示器／骨架屏
未经检查就发布	交由 aesthetics + heuristics + accessibility + microcopy + dark-patterns + mobile-responsiveness 审查

---

参考课程（Uxcel）

• 如何设计引人入胜的活动信息流