展示时间线与活动组件Skill：一套决策框架，把时间线、活动源、甘特图、日历一次性做对
- 它解决的问题很具体：凡是要「按时间顺序展示信息」的界面——社交动态、通知中心、审计日志、里程碑、项目进度、日程表——它都给出成体系的组件选型与实现模式，而不是让你从零摸索。
- 核心是一张「快速决策框架」表：社交活动→活动源、系统事件→审计日志、用户通知→通知源、历史事件→垂直时间线、项目规划→甘特图、调度→日历、交互式路线图→水平时间线，先选对类型，再谈实现。
- 不只有样式，还有工程细节：相对/绝对时间戳格式化、时区与本地化、WebSocket/SSE 实时更新与乐观更新、虚拟滚动性能阈值、WCAG/ARIA 可访问性、三种响应式策略，配套脚本可生成数据、模拟实时流、校验可访问性、跑性能基准。
- 落地成本低：提供 react-chrono、SVAR React Gantt、react-big-calendar 等库推荐与安装命令，附带 8 个可直接参考的示例文件（社交源、通知中心、审计日志、里程碑时间线、甘特图、日历、实时更新、响应式时间线）。
- 适合谁用：前端工程师、全栈开发者、设计系统维护者，以及需要快速交付「时间维度」界面的产品团队。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
技能中文名：展示时间线与活动组件Skill 技能英文名：displaying-timelines 技能ID：13427
它的定位可以一句话概括：把「按时间顺序排列的事件与活动怎么显示」这件事，从凭感觉写页面，变成按用例选组件、按模式写代码、按清单做验收的工程流程。 它覆盖的不只是「一条竖向时间线」这种简单需求，还包括活动源（无限滚动 + 反应）、通知源（分组 + 已读未读）、审计日志（可搜索可导出）、甘特图（依赖关系 + 拖拽重排）、日历（月/周/日/议程视图）等一整套时间类界面。
它到底解决什么问题
在没有这类技能时，开发者常见的困境有三个：
- 选型靠猜：面对「我们要做一个动态列表」的需求，到底该做活动源、通知源还是审计日志？三者的交互、分页、时间戳精度要求完全不同，选错就要返工。
- 细节反复踩坑：相对时间戳「3小时前」要不要自动刷新？时区怎么处理？1000 条以上事件卡顿怎么办？实时插入新项时列表跳动怎么解决？这些都不是「会不会写组件」的问题，而是经验问题。
- 可访问性与响应式被忽略：时间线天然是列表结构，但很多人写成了一堆
div，屏幕阅读器读不出来；移动端横向时间线直接溢出。
这个技能的做法是把上述经验沉淀为决策框架 + 实现模式 + 配套脚本 + 示例代码，让 AI 助手在你提出相关需求时，能按统一标准产出方案。
一键安装的思路与步骤
AI 技能的安装通常遵循「在支持的 AI 编程助手/技能市场中检索并启用」这一通用路径，本技能详情中未提供具体安装命令与下载链接，具体入口、命令与是否收费请以官方说明为准。通用流程如下：
第一步：确认安装前提
- 你使用的 AI 编程助手/客户端支持「技能（Skill）」机制；
- 项目为前端技术栈（技能中的示例与库推荐以 React/TypeScript 生态为主，含 TSX 示例文件）；
- 如需使用配套脚本，本地应具备 Node.js 与 Python 运行环境（脚本分别为
.js与.py）。
第二步：检索并启用技能
在技能市场或技能列表中，使用技能名「展示时间线与活动组件」或英文名 displaying-timelines、技能ID 13427 进行检索，找到后按界面提示启用/安装，具体按钮位置与命令以官方说明为准。
第三步：验证是否生效
启用后，向助手提出一个明确的触发型需求，例如：
「帮我做一个带已读/未读状态、按日期分组的通知中心，需要支持过滤和标记全部已读。」
若技能生效，回答应体现技能中的特征：会先按「快速决策框架」判断这属于通知源模式，提到按日期分组、已读/未读指示器、按类型过滤、操作按钮，并可能引用 references/notification-feeds.md 与 examples/notification-center.tsx，同时提醒可访问性（role="feed"、aria-busy 等）与性能策略。若回答完全没有这些结构化内容，说明技能未被正确加载。
该技能的主要功能和特点
- 一张覆盖七类场景的组件选型决策框架：社交活动、系统事件、用户通知、历史事件、项目规划、调度、交互式路线图，各自对应最合适的组件形态，避免「用日历做审计日志」这类错配。
- 三种活动源模式：社交源（头像 + 操作描述 + 相对时间 + 反应评论 + 无限滚动 + WebSocket 实时更新）、通知源（按日期分组 + 已读未读 + 批量已读 + 类型过滤 + 操作按钮）、审计日志（精确时间戳 + 用户操作追踪 + 可搜索 + 可导出 CSV/JSON + 安全导向展示）。
- 三种时间线可视化：垂直（堆叠 + 连接线 + 标记点 + 可选交替侧面）、水平（沿轴排列 + 缩放平移 + 密度随缩放变化）、交互式（点击查看详情 + 类别过滤 + 缩放控制），并明确各自最佳适用场景。
- 完整甘特图能力清单：任务条、依赖关系箭头、关键路径高亮、拖拽重新安排、进度指示器、菱形里程碑、资源分配、「今天」标记线、日/周/月/年缩放级别。
- 日历三视图：月视图（网格 + 颜色编码 + 多日历叠加）、周视图（时间槽 + 可拖拽块 + 调整时长）、日/议程视图（列表 + 时长 + 地点与参与者）。
- 时间戳格式化规范：相对时间（「刚刚」「5分钟前」「3小时前」「昨天下午3:42」）与绝对时间（「2025年1月15日」「2025年1月15日下午3:42」）的分界策略，API 使用 ISO 8601，含时区本地化、区域感知格式化、悬停显示精确时间、相对时间自动刷新。
- 实时更新的乐观更新四步法：立即显示用户操作 → 时间戳更新为「刚刚」→ 后台发送服务器 → 出错回滚；配合「X 个新项」横幅与平滑插入动画。
- 明确的性能阈值表：
<100事件客户端直渲染；100–1,000推荐虚拟滚动；1,000+虚拟滚动 + 服务器分页；实时场景防抖（每 500ms 批量）与批量插入。 - 可访问性硬性要求：语义
<ol>/<ul>、语义<time>元素、role="feed"、role="article"、aria-label时间戳、aria-busy加载态，Tab/方向键/Enter/Space 键盘操作，以及屏幕阅读器新项播报。 - 三种响应式策略：垂直堆叠（横向转纵向）、简化显示（必要信息 + 展开详情）、水平滚动（保持布局 + 触摸滚动 + 滚动指示器）。
- 设计令牌对接：
--timeline-line-color、--timeline-dot-color、--timeline-dot-active-color、--event-card-bg、--timestamp-color等专用令牌，支持浅色/深色/高对比度/自定义主题。 - 配套脚本工具链：
generate_timeline_data.py（造 500 条含实时标记的模拟数据）、generate_gantt_data.py（生成带依赖的任务数据）、format_timestamps.js（按 locale 与时区统一格式化）、simulate_realtime.js（模拟 5 条/秒、持续 60 秒的实时流）、validate_timeline_accessibility.js（可访问性校验）、benchmark_timeline.js（万级事件虚拟滚动基准）。
和普通做法比强在哪：普通做法是「给我一个时间线组件」然后拿到一段可运行但不知所以的代码；这个技能给的是判断依据 + 取舍理由 + 验收清单。它同时管住了三件常被漏掉的事——大数据量性能、可访问性合规、移动端适配。
如何使用该技能？
以下为分步骤使用指南，调用方式以你所使用客户端的实际交互形式为准（技能详情中未规定固定调用命令，请以官方说明为准）。
第 1 步：识别用例，锁定组件类型
先向助手描述业务场景而非直接要代码。例如：「这是内部风控后台，需要记录每一次权限变更，能按用户和时间筛选，还要能导出来给审计用。」助手会依据决策框架判定为审计日志模式，而不是普通活动源。
第 2 步：选择组件形态与库
技能提供库推荐与安装命令，可直接采用：
# 丰富内容的时间线（水平/垂直/交替布局，支持图像视频）
npm install react-chrono
# 甘特图（现代、无依赖、支持拖放与依赖关系）
npm install @svar/gantt
# 日历调度（月/周/日/议程视图、拖放事件）
npm install react-big-calendar
轻量垂直时间线可选 react-vertical-timeline-component（约 10KB）；复杂项目资源管理可考虑商业方案 Bryntum Gantt（需商业许可）。
第 3 步：从匹配示例起步
技能提供 8 个示例文件，按需求直接对号入座：
| 需求 | 参考示例 |
|---|---|
| 带反应的社交动态 | social-activity-feed.tsx |
| 带过滤的通知系统 | notification-center.tsx |
| 系统审计日志 | audit-log-viewer.tsx |
| 垂直里程碑时间线 | milestone-timeline.tsx |
| 带依赖的甘特图 | project-gantt.tsx |
| 全视图日历 | calendar-scheduler.tsx |
| WebSocket 实时更新 | realtime-activity.tsx |
| 移动优化时间线 | responsive-timeline.tsx |
第 4 步：准备测试数据
python scripts/generate_timeline_data.py --events 500 --realtime
python scripts/generate_gantt_data.py --tasks 50 --dependencies auto
第 5 步：统一时间戳格式
node scripts/format_timestamps.js --locale en-US --timezone auto
注意：技能示例中的 --locale en-US 仅表示参数用法，中文界面应传入对应区域参数（如中文区域标识），原则是按用户区域与时区自动显示本地时间，悬停展示精确时间戳。
第 6 步：实现实时更新（如需）
按乐观更新四步法实现：先本地插入并显示「刚刚」→ 后台请求 → 失败回滚 → 成功则以「X 个新项」横幅承接被动推送，防抖批量 500ms。可用脚本压测：
node scripts/simulate_realtime.js --rate 5/sec --duration 60s
第 7 步：性能与可访问性验收
node scripts/benchmark_timeline.js --events 10000 --virtual
node scripts/validate_timeline_accessibility.js
前者验证万级事件下的虚拟滚动表现，后者校验语义结构、ARIA 角色与键盘导航是否达标。
第 8 步：套用设计令牌并做响应式收尾
用 --timeline-line-color、--event-card-bg、--timestamp-color 等令牌统一主题，支持深浅色切换；再按移动端策略三选一（垂直堆叠 / 简化显示 / 水平滚动），完成交付。
输入输出示例
- 输入：「给我做一个项目进度页，任务之间有前后依赖，能拖动调整开始时间，标出今天的位置。」
- 期望输出：判定为甘特图场景 → 推荐
@svar/gantt或 Bryntum → 给出任务条、依赖箭头、拖拽重排、今天标记线、缩放级别（日/周/月/年）的实现要点 → 引用examples/project-gantt.tsx与references/gantt-patterns.md→ 提示 1000+ 任务需虚拟滚动与服务器分页。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 展示时间线与活动组件Skill（displaying-timelines） | 时间类界面的方法论 + 模式库 + 工具链 | 七类场景决策框架、三类活动源、三类时间线、甘特图、日历三视图、时间戳规范、实时更新、性能阈值、WCAG/ARIA、响应式策略、6 个脚本、8 个示例 | 需在支持技能机制的 AI 助手中启用；示例以 React/TS 为主；脚本需 Node.js 与 Python | 需要一次做对选型、性能与可访问性的中大型前端项目 | 优势：覆盖选型到验收全链路，含性能与无障碍硬指标，可复用为团队规范；不足：偏指导与模式，具体像素级样式仍需自行实现 |
| 单一 UI 库（如 react-chrono / react-vertical-timeline-component） | 现成时间线组件 | 水平/垂直/交替布局、图像视频、图标支持 | npm install 即用，学习成本低 |
简单历史事件展示、营销页时间线 | 优势：开箱即用、体积小、上手快；不足：不含选型框架、实时更新、性能策略与可访问性清单，复杂场景需自行补齐 |
| 商业甘特图方案（如 Bryntum Gantt） | 企业级项目管理可视化 | 复杂依赖、资源管理、高级交互 | 需商业许可，接入与授权成本较高 | 大型项目排期、资源密集型企业应用 | 优势：功能完备、复杂项目承载力强；不足：成本高、体积大，对小需求偏重 |
| 通用日历库（如 FullCalendar） | 多功能日程组件 | 多视图日历、事件拖放、多框架支持、文档完善 | npm install + 配置，部分高级功能需付费 |
预约、排班、会议日程 | 优势：多框架、文档好、生态成熟；不足：聚焦日历，缺乏审计日志、活动源、甘特图等复合形态的指导 |
怎么选：只做一个静态里程碑展示，直接用轻量组件库即可；一旦涉及「多种时间类界面并存 + 需要实时更新 + 有性能与无障碍验收要求」，用这套技能做上层规范、用具体库做底层实现，组合收益最大。本表中各库的授权与价格细节以官方说明为准。
该技能的典型应用场景与实际体验情况
场景一：社交产品的动态流
角色是前端工程师，痛点是新内容插入时列表跳动、加载更多卡顿、屏幕阅读器读不出新动态。使用方式：按社交源模式实现头像 + 操作描述 + 相对时间戳 + 反应评论，配合无限滚动分页与 WebSocket 增量推送，新项以「X 个新项」横幅提示而非强行插入。实际体验：上手难度中等，最省心的是「防抖 500ms 批量插入」和「记忆化时间线项组件」这两条直接给出了可执行参数；需注意相对时间要自动刷新（如每分钟更新一次「分钟前」文案），否则会停留在「刚刚」。
场景二：SaaS 后台的通知中心
角色是产品团队与全栈开发者，痛点是通知越堆越多、用户找不到重点、无法批量处理。使用方式：通知源模式，按日期分组，未读带指示器，提供「标记全部已读」与按类型过滤，每项带「查看 / 关闭」操作按钮，加载时用 aria-busy 标注。实际体验：效果最直观的一环，分组 + 已读态明显降低处理成本；注意筛选与分页需联动，避免「筛完只剩 3 条却还显示第 5 页」。
场景三：合规审计日志
角色是安全/运维视角的后端与前端协作方，痛点是事件量大、要精确到秒、要能导出取证。使用方式：审计日志模式，精确时间戳（不用「3小时前」这类相对表述）、用户操作追踪、高级搜索与过滤、CSV/JSON 导出、安全重点高亮。实际体验：这是最容易被低估的场景——很多团队用普通活动源的做法做审计日志，结果时间不准、无法导出。技能明确把「精确时间戳」和「可导出」列为该模式的必要项，避免方向性错误；注意 1000+ 事件务必启用虚拟滚动 + 服务器分页，并用 benchmark_timeline.js 实测。
场景四：项目排期甘特图
角色是项目经理与前端开发者，痛点是依赖关系画不出来、拖动重排后状态不同步。使用方式：用 generate_gantt_data.py 生成带依赖的任务数据做联调，接入甘特图库实现依赖箭头、关键路径高亮、拖拽重排、里程碑菱形标记与「今天」标记线，缩放支持日/周/月/年。实际体验：数据生成脚本对调试帮助极大，省去手工造依赖；需注意的是拖拽重排必须做乐观更新 + 失败回滚，否则网络异常会造成界面与真实排期不一致。移动端建议切换到简化显示或水平滚动策略，不要把完整甘特图硬塞进小屏。
该技能能为用户带来的价值
- 把选型成本前置消解：原先「做动态列表还是做时间线」的争论要开几次会，现在一张决策表 30 秒定案，减少返工。若一个中型项目因此少返工 1 次，节省的通常是数人日级别投入。
- 把隐性经验变成显性清单：性能阈值（100 / 1,000 三条线）、实时防抖 500ms、乐观更新四步、ARIA 角色清单、三种响应式策略——这些都是踩坑才总结出的参数，现在可以直接抄。
- 可访问性从「事后补救」变「默认产物」：语义
<ol>/<ul>、<time>元素、role="feed"、键盘导航与屏幕阅读器播报被写进核心要求，还配了validate_timeline_accessibility.js做校验，显著降低合规风险。 - 降低团队协作门槛：设计侧用时间线专用设计令牌（连接线、标记点、事件卡片、时间戳颜色）统一主题，开发侧用同一套模式与示例文件，设计与实现语言一致。
- 长期价值是可复用的团队资产：一次沉淀的选型框架、示例与脚本，会在后续每一个「时间维度」需求中反复生效，边际成本递减。
- 对个人开发者尤其实用：不必先做过十个动态列表才能知道 1000 条该上虚拟滚动，起点直接对齐成熟实践。
常见问题 FAQ
Q1：这个技能怎么安装？有没有一键命令？
它属于 AI 技能（Skill），安装路径是在支持技能机制的 AI 助手中检索技能名「展示时间线与活动组件」或英文名 displaying-timelines、技能ID 13427，然后按界面提示启用。技能详情中未提供具体的安装命令、下载链接或市场地址，请以官方说明为准。验证方式：提出一个「按日期分组、带已读未读的通知中心」需求，若回答中出现决策框架、通知源模式、role="feed" 等特征内容，即表示已生效。
Q2：收费吗？需要额外买库的授权吗？
技能本身的费用信息在所提供的技能详情中未说明，以官方说明为准。需要提醒的是：技能推荐的库中，react-chrono、react-vertical-timeline-component、@svar/gantt、react-big-calendar 属于开源生态方案，而 Bryntum Gantt 明确「需要商业许可」，FullCalendar 也提供付费高级功能。这些第三方库的授权与价格与技能本身独立，选型时需单独确认。
Q3：适合谁用？我只写 HTML/CSS，不用 React 能用吗？
最适合前端工程师、全栈开发者、设计系统维护者，以及需要交付时间类界面的产品团队。技能的示例文件为 .tsx，库推荐也以 React 生态为主，因此 React/TypeScript 用户收益最大。但技能中大量内容与技术栈无关——组件选型框架、时间戳相对/绝对策略、性能阈值（100 / 1,000 事件分界）、乐观更新四步法、WCAG/ARIA 要求、三种响应式策略——这些对 Vue、Svelte 或原生实现同样适用，可当作设计与实现规范来读。
Q4：和直接用 react-chrono、react-big-calendar 这类库相比，选哪个？
两者不是替代关系。库解决「有没有组件」，技能解决「该用哪种组件、怎么保证性能与可访问性」。如果你的需求只是一个静态历史事件展示，直接装组件库最快；如果涉及多类时间界面并存、实时更新、大数据量、无障碍合规验收，建议用技能做上层方案与验收清单、用具体库做实现。技能本身也正是这么设计的——它推荐库、给出安装命令，并提供对应示例文件（如 examples/react-chrono-timeline.tsx）。
Q5：数据量很大怎么办？实时更新会不会把界面卡死？
按技能给出的阈值处理：<100 条直接客户端渲染；100–1,000 条上虚拟滚动；1,000+ 条虚拟滚动叠加服务器分页。实时场景下做防抖批量插入（每 500ms 一批），并用「X 个新项」横幅而非强制插入，配合记忆化时间线项组件与事件详情延迟加载。上线前用 node scripts/benchmark_timeline.js --events 10000 --virtual 跑基准，用 node scripts/simulate_realtime.js --rate 5/sec --duration 60s 压测实时流。