如果说过去十年，可视化解决的是“画出来”的问题——从基础统计图到复杂语法，从matplotlib到ECharts，核心是把数据变成看得见的图形。

不知道有多少人曾为了让数据图表既“好看”又“好懂”，而在设计软件与代码编辑器之间反复横跳，熬到“头秃”。

如果说过去十年，数据可视化解决的是“画出来”的问题——把数据变成图表；那么今天，我们卡住的地方已经分裂成两个更深层的挑战：

1. 如何让数据有“画面感”和“高级感”？

2. 如何让数据“动”起来，讲出好故事？

如果说过去十年，可视化解决的是“画出来”的问题——从基础统计图到复杂语法，从matplotlib到ECharts，核心是把数据变成看得见的图形；那么今天，我们真正卡住的，其实是“画得活”——

说得更直接些：静态的视觉表现力和动态的叙事能力，正在成为新的刚需。下面这两类“痛点”，你是否也正在经历？

1. 想让数据有“画面感”，却总在“手工作坊”里耗尽心力

想把抽象数字转化为让人一眼看懂、过目不忘的信息图、主题插画或符号系统。

但现实是，每一张具有感染力的图表，几乎都需要在Adobe套件里手动拼贴素材、反复调整版式与配色。

从图标对齐到风格统一，全部依赖人力一像素一像素地打磨，过程繁琐且极难复用，大量时间被消耗在重复的基础劳动上。

2. 想让数据“动”起来，却总被动画的实现门槛劝退

一旦想让图表“活”过来，展示趋势、揭示过程或引导叙事，挑战就立刻升级。无论是用代码精细控制时间轴和缓动效果，还是试图在模板中实现自定义动画，你都可能发现：

代码驱动：需要深入动画原理与编程，调试复杂；

模板驱动：灵活性差，创意受限。

3. 想做交互，却总在“重复造轮子”的循环里打转

鼠标悬停提示、框选高亮、拖拽排序、视图联动、撤销/重做……这些看似基础的交互功能，一旦换个图表类型、换个可视化库，甚至只是升级版本，整套逻辑就得几乎从头写一遍。

更令人沮丧的是，这些代码往往高度定制、难以复用，即使你是熟练工，也逃不过在不同项目中重复解决相同问题的循环。交互，本应让数据“可探索”，却常常因为实现成本太高，最终变成了“可远观”。

真正的瓶颈：从“有图表”到“好体验”的最后一公里

可视化正从“呈现结果”走向“驱动思考与沟通”。而最大的阻力，往往不在于想法，而在于实现：

• 视觉设计难以高效、批量且保持高质量。
• 动画叙事的开发成本高、门槛陡峭。
• 交互逻辑缺乏标准化、可复用的解决方案。

如果这些“卡点”也是你的日常，那么或许我们共同期待的是一个更根本的解决方案：一个能同时解放“视觉设计”、“动画叙事”与“交互实现”生产力，让创意不再受限于繁琐实现的下一代工具。

围绕这个问题，中国人民大学IDEAS Lab团队与山东大学交叉研究中心最近做了三件事：

PiCCL：让图表真正“长”进图像和视觉设计里。

CAST：让动画不再只靠模版或者硬编码；

Libra：让交互不再每次都从零写起。

它们看似分散，背后其实指向同一个关键词：把那些难以复用、难以迁移的能力，做成可以自由组合的系统。

PiCCL：重新定义静态图表创作的新范式

项目链接：https://piccl.github.io/

在多数人的认知里，可视化图表的创作路径大致只有三种：

在Excel里套模板，数据分析师写一大段复杂代码，或者设计师在Photoshop里反复拼贴、微调。

这些方法当然能用，但问题也很明显：模板的表达能力有限；代码门槛高、调试成本大；而专业设计软件虽然灵活，却高度依赖人工经验，一张复杂图表往往要反复细调参数，既耗时又难以复用和修改。

即便具备扎实的可视化设计能力，创作复杂的“图像化图表”依然困难重重。 原因在于，主流可视化库大多建立在Grammar of Graphics理论之上——它以数据变换为核心，将可视化拆解为一系列映射与规则。

这一范式非常适合统计图，但当创作目标转向高度图形化的表达时，问题就暴露出来：大量细粒度的图形操作（组合、裁剪、对齐、缩放、遮罩等）很难通过抽象的数学描述完成。

而转向图像编辑软件？灵活性是有了，但代价是巨量的手工劳动，数据一变，图几乎要重做一遍。

当然，你可能想到了，能不能把需求告诉大模型，然后让它直接生成一张图？

遗憾的是，生成的结果往往只是看起来正确，实际图形并不能精确地和数据对应，还无法修改。

PiCCL正是在这个断层中提出了一种全新的解法。

它不再以数据变换为中心，而是将图形本身作为创作的第一公民。

为此，PiCCL引入了“图形运算符”：运算直接作用于图形元素，可以完成融合、切割、复制等操作；再配合约束（constraint）定义图形之间的空间关系，实现自动对齐；以及布局（layout）机制，对图形进行批量排列与组织。

在“以图形为中心”的同时，PiCCL并未放弃数据驱动能力。通过编码运算符（Encoding），数据可以绑定到图形的视觉通道上，如尺寸、位置、颜色等；同时，图形运算本身也可以与数据关联，让数据参与图形合成过程，避免重复、冗余的手工操作。

更进一步，PiCCL将图形与运算符之间的关系抽象为一种结构化表示——图形化对象树（Pictorial Object Tree，POT）。在POT中，数据与设计被解耦存储，使得图表不仅可以被封装为可复用模板，还能实现模块级拼接，甚至“嫁接”不同图表结构，生成全新的设计方案。

换句话说，PiCCL在“模板的易用性”和“自由设计的表达力”之间，以及“数据驱动的严谨性”和“图像编辑的灵活性”之间，重新划出一条新的道路。

从Canis到CAST+：对可视化动画底层模型的系统性重构

在可视化研究中，动画长期被视为一种“表现层”技术：它用于提升叙事性、吸引力或过渡的平滑性，却很少被当作一个需要系统建模的问题来对待。

现有方法要么将动画嵌入到通用可视化库的实现细节中（如D3），要么完全交由通用动画工具处理（如After Effects），二者都缺乏对数据—视觉编码—时间结构之间内在关系的显式建模。

团队的一系列工作正是针对这一长期缺失展开的：将动画提升为可视化系统中的一等公民，并围绕其表示、编译与交互方式构建了一套完整的底层方法体系。

项目链接：https://canisstudio.github.io/CASTPlus/

Canis：一种面向可视化动画的声明式表示与编译模型

项目链接：https://chartanimation.github.io/canis/

团队首先提出了Canis，一种专为可视化动画设计的领域特定语言（DSL）。与将动画视为“对视觉属性做插值”的传统做法不同，Canis从一开始就将动画建模为由数据驱动的时序结构。

Canis的核心设计思想在于：

1. 以数据对应的图元（marks）作为动画操作的基本单位；
2. 显式描述选择（selection）—分组（grouping）—时序（timing）—过渡（transition）之间的关系；
3. 将动画的语义层（做什么）与实现层（如何渲染）彻底解耦。

为此，团队引入了dSVG这一扩展格式，使每个图元不仅携带几何信息，还显式绑定其数据语义（通过id、class与datum）。

在这一框架下，用户即可在不修改任何动画代码的情况下，将同一动画从“按类别依次出现”切换为“按时间顺序展开”。

这种声明式、数据感知的动画建模方式，为后续的自动编译与交互式创作奠定了基础。

CAST/CAST+：将动画语言转化为可操作的视觉系统

尽管Canis在表达层面大幅降低了动画创作的复杂度，但团队很快意识到：语言本身仍然是一种门槛。

因此，团队进一步提出了CAST（Canis Studio），将Canis的抽象动画模型转化为一个可直接操作的图形化系统，旨在实现动画的可视化结构编辑。

该系统将动画中的选择、分组与时序等结构映射为界面元素，并基于动画逻辑（而非最终像素）自动生成关键帧，使用户的每次交互都在修改动画的结构化描述，系统则确保语义与时序一致性。

随着应用深入，团队发现复杂动画常涉及多类标记交错的时序关系，为此提出CAST+（Canis Studio Plus）系统，在结构与交互层面实现双重突破：

1.表示层面：引入嵌套选择机制，支持描述跨标记类型的结构关系；

2.交互层面：重构关键帧与自动补全系统，确保多时序场景下的可预测性。

这一突破使以往只能逐帧手工调整的复杂动画（如坐标轴与数据点的交替呈现）首次实现系统化生成。用户通过高层级选择与少量决策即可完成专业动画设计，推动动画创作从代码编写迈向结构化交互的新范式。

在此基础上，CAST+将动画时序纳入数据映射体系，使动画的开始时间、持续时间与过渡方式直接绑定到数据属性之上，成为数据表达的组成部分。

例如，在甘特图场景中，动画时间结构可由任务的begin与duration字段推导，从而保证动画与数据在语义与节奏上的一致性。这一设计推动动画从像素级调控转向结构化、数据驱动的交互范式。

交互为什么这么难复用？——因为它一直在“跟着图跑”

项目链接：https://libra-js.github.io/

已获 ACM CHI 2025 最佳论文奖提名

今天很多可视化交互，本质上还是回调函数堆出来的：事件来了，写一段逻辑；想要更复杂的“状态机+反馈+历史”，就继续加分支判断。你能做出一个demo，但很难把它变成组件，更难跨图表、跨库复用。

IDEASLab提出的Libra的思路很直接：把交互当成一等公民（即可以直接操作的对象），拆成一套可组合的部件——Instrument（交互工具）、Layer（图层）、Interactor（交互子/状态机）、Service（服务）、Command（命令/历史）。

事件进入后，Instrument在多层语义中解释事件，用Interactor把低层事件翻译成高层动作，再由Service执行，最终用Command把动作封装起来，天然支持撤销/重做，并把feedforward/feedback（对应视觉上的预反馈，例如拖动时的虚影；以及反馈，例如选中之后的高亮）显示在对应层上。

Libra把“撤销/重做”这个在可视化里长期缺位的能力，在服务层面内置实现——因为如果服务不掌握内部状态，undo/redo在工程上几乎无从谈起。

通过利用Libra的能力，交互从“写在图里的技巧”升级成“可复用、可扩展、可组合的组件系统”。

在PiCCL、CAST、Libra等可视化语言的基础上，未来，团队还在探索利用大模型生成更高效的可视化。