AI时代的数据可视化生成方式

过去我们开发数据可视化，基本都是一个一个做。

有了新的业务需求，产品经理先整理需求点，大家讨论大致形式，设计师再出设计稿，最后交给开发编码，做成一个数据可视化组件，然后应用到具体业务里。

这个流程生产效率比较低。每做一个新的效果，都要重新走一遍需求、设计和开发流程。

另外一个问题是创新。

产品经理和设计师提出的方案，通常来自过去见过的图表、网页或者产品。人很难想象出自己完全没有见过的东西。如果一直依靠少数几个人思考方案，最后做出来的可视化很容易停留在已有经验里面。

最近我开始重新考虑这件事。

AI 已经可以理解需求、分析图片，也可以直接生成前端代码。如果我们只是让 AI 帮开发写几个组件，原来的生产流程其实没有发生太大变化。我们需要调整的，可能是整个可视化方案的产生方式。

过去是围绕一个需求，讨论并开发一个方案。现在可以先批量生成大量候选方案，再由人筛选、验证和完善。

这里记录一下我们正在尝试的两个方向。

第一条路线：把真实需求和可视化效果组合起来

这条路线有两类输入。

第一类输入是真实的用户问题。

用户在使用产品时，会提出大量问题。如果能收集几十万条用户问句，再从里面找出适合用数据可视化回答的问题，就可以形成一个比较大的需求池。

例如，有些问题只需要返回一个数字或者一段文字，没有必要做可视化。有些问题包含时间变化、数据对比、人物关系、产业关系或者事件过程，这些问题更适合用图形来表达。

除了用户问句，我们还可以收集抖音、小红书、财经榜单等公开渠道里的热门话题。用户问题反映真实需求，热门话题反映当前关注点。把两部分信息放在一起分析，可以帮助我们判断最近应该优先做什么内容。

第二类输入是可视化效果。

网上有很多做得不错的视频、网页和图片。我们可以收集这些内容，提取里面有价值的呈现方式，再让 AI 用代码还原其中的布局、动画和交互。

这样会逐渐形成一个可视化组件池。这里面的组件一开始不需要对应某个具体业务，先看效果本身是否有价值，能不能被代码稳定实现。

接下来，把需求池里的问题和组件池里的方案进行组合。

同一个问题可以尝试多种呈现方式，一个可视化组件也可以应用到不同内容上。AI 可以快速生成大量实验结果，我们再去判断哪些方案真正讲清楚了问题，哪些只是看起来比较炫。

这一步很重要。批量生成只解决数量问题，最后仍然要看数据是否可靠、表达是否清楚、交互有没有实际作用。否则生成得越多，后面的筛选成本也会越高。

另外一条路线更偏业务领域。

我们准备梳理金融投资领域里的概念、名词和业务关系，例如龙虎榜、产业链、并购重组、股权变更等。

只给 AI 一个名词还不够。还需要把概念背后的数据关系和业务规则整理清楚。以产业链为例，里面可能包含行业、公司、产品、上下游关系以及相关事件。如果数据结构都没有定义清楚，AI 生成的图形大概率只是一个看起来完整的 Demo。当然，初期我们可以让AI去生成这些数据结构。

业务概念之外，还要给 AI 一组基础约束，包括设计风格、组件规范、Token 机制、交互协议、数据接口等。这样生成出来的内容才能接入现有产品，不会每次都变成无法复用的一次性代码。

在具体生成时，我们还会尝试隔离不同 Agent 的上下文，避免所有方案沿着同一个思路展开。同时引入多 Agent 对抗分析，让不同 Agent 分别检查业务逻辑、视觉表达和实现问题。

然后再从大批量结果里挑选比较好的方案，继续补数据、改交互，最终变成可以应用到业务里的可视化组件。

这两个方向的入口不同。

第一条路线从用户问题和当前热点里找需求，再去匹配外部已有的优秀呈现方式。第二条路线先整理金融领域里的概念和规则，让 AI 在明确约束下批量探索。

它们有一个共同点：不再把第一个想到的方案直接拿去开发。

先让 AI 尽可能多地生成，再由人判断哪些值得继续投入。这样做可能产生一些过去没有见过的组合，也能减少产品、设计和开发在低价值方案上反复讨论的时间。

当然，目前这还是一个正在进行的实验。

批量生成能不能带来真正有用的创新，组件质量能不能达到业务要求，后面的筛选成本会不会太高，都需要用实际结果验证。生成数量本身没有意义，最后能留下多少可用组件才有意义。

我们已经开始沿着这两个方向尝试。接下来先把需求池、组件池和金融概念整理出来，跑完第一批生成结果，再看哪些判断是对的，哪些地方还要继续调整。

等结果出来以后，再做一次复盘。