可视化能力构建

Prompt

作为数据可视化团队，我们计划构建一个官网，向业务方和用户介绍我们所具备的能力。因此，我希望基于以下信息，梳理我们应该将能力分为哪些类别、以何种形式展示，以及如何设计这个官网。

**第一部分是关于组件能力**。我们提供了许多可视化组件，主要落地在公司to B和to C的业务中。业务方通常在我们的平台上进行一站式的可视化配置，完成后以代码形式将这些组件应用到他们的项目中。此外，我们对这些组件进行了上层封装，提供不同主题以适配各业务线，比如海外业务线、首长的业务线、资讯业务线等；同时也针对不同终端做了主题适配，包括移动端、PC端、Web端等。

我们还实现了与大模型对接的技术方案：用户输入信息后，调用我们的可视化大模型进行分析，为其推荐合适的组件，再调用对应组件代码进行渲染。

这些组件包括常规的折线图等数据分析组件，也包括与业务相关的定制组件，比如资金流向、并购重组等。组件形式多种多样，如关系图；还包含一些非常规数据分析组件，比如时间轴组件、信息图组件，以及SparkWord等。

**关于组件展示和配置功能的扩展**，目前的功能我感觉不够完善，因此计划进行如下扩展：第一，为每个组件增加元信息，描述其特性和应用场景。这部分主要供模型使用，将信息提供给模型后，它就能向用户推荐适合场景的组件，或者根据用户输入的意图和数据推荐最合适的组件。第二，优化组件配置方式。之前在我们的平台上需要通过写代码来配置，门槛较高，需要掌握配置项的含义、范围以及关联、影响、冲突关系等，这使得组件使用人员很难完成配置。因此我计划加入自然语言配置功能：构建一个知识库提供给AI，用户可以在配置页面通过自然语言对话方式进行组件配置，比如修改组件的表现形式，调整X轴、Y轴样式，或处理一些简单事件等。

**第二部分是特定业务方向的可视化能力**，比如叙事可视化，这其中分成了多个子项目。

第一个子项目是资讯可视化，涵盖后端服务和前端服务。后端服务允许用户输入一段资讯文本，我们通过多Agent架构对文本进行处理，包括意图识别、数据增强、召回insight信息的提取等，然后将这些不同的insight或summary信息用可视化图表呈现。最终，一篇资讯原文经过加工后，会变成包含各种可视化效果、富含insight信息的资讯文章。

第二个子项目叫Redefine，属于文本可视化，也是叙事可视化的一部分。它允许用户上传小说文本，我们对文本进行智能切割、提取以及大模型加工，让用户可以从不同视角、不同维度分析小说的剧情脉络和主干逻辑，最终在前端以可视化形式呈现这些信息，并且前端交互支持宏观视图和微观视图，用户可以通过下滑查看更细粒度的内容。

这些叙事可视化里的后端服务，我觉得可以单独抽取出来作为独立能力，比如叙事逻辑的生成、文本的处理、insight信息的提取、可视化图表的推荐等。我感觉每个都可以作为一个独立能力开放给业务方，以应对他们不同的需求。同时这些能力也可以组合起来使用，编排形成一个工作流。

**目前我遇到的一个难点是：怎样去定义能力？什么算是能力，什么不算？哪些应该设计成独立能力，哪些不应该？这是我遇到的最大难点。**

我有一个不成熟的想法：将涉及后端服务的都定义成能力，比如前面提到的文本解析、可视化图表推荐、叙事大纲生成等，然后这些能力与我们前台的组件组合起来，形成一个端到端的数据可视化服务。我不知道这样设计是否合理，这只是一个初步建议。

Gemini

1. 背景与目标

随着公司To B与To C业务的快速发展，数据可视化团队已积累了大量底层资产。为了更高效地赋能业务方，降低接入门槛，并对外输出我们的技术影响力，我们计划构建统一的数据可视化能力官网。

本项目旨在完成从“单一组件库”向“智能化可视化服务平台”的转型，清晰定义我们的能力边界，并通过官网将这些能力以标准化的形式开放给业务方。

---

2. 核心能力架构设计 (Capability Architecture)

针对“什么是能力”的界定，我们将可视化能力重构为四层金字塔架构。这套架构将后台服务显性化，既支持独立调用，也支持端到端解决方案。

L1：视觉原子层 (Visual Infrastructure) —— “好看的皮囊”

这是我们最基础的渲染能力，业务方以代码（NPM包）或配置形式接入，强调多端适配与业务定制。

• 基础分析组件： 涵盖折线图、柱状图、饼图、散点图等常规统计图表。

• 业务领域组件： 针对特定金融/商业场景封装的组件，如资金流向图、并购重组图、股权穿透图等。

• 创意与信息图组件： 适用于非标数据的展示，如时间轴（Timeline）、词云/微图表（Sparkword）、徽章图等。

• 多维主题系统：

  • 业务适配： 内置海外版、资讯版、金融版等预设主题。

  • 端侧适配： 完美兼容 PC Web、移动端（H5/Native）及大屏场景。

L2：智能服务层 (Intelligent Services) —— “有趣的灵魂”

我们将涉及后端处理的逻辑抽取为独立的 Headless API 能力。业务方可以只使用我们的算法能力，而不使用我们的渲染层。

• 智能推荐引擎 (Recommendation API)：

  • 输入：用户的数据源或自然语言意图。

  • 输出：推荐最合适的图表类型或可视化方案。

• 数据洞察服务 (Insight Mining API)：

  • 输入：原始数据。

  • 输出：数据中的显著趋势、异常点、关键摘要（Summary）。

• 文本结构化服务 (Text-to-Structure API)：

  • 输入：非结构化文本（小说、资讯）。

  • 输出：可用于渲染的结构化图数据或关系数据。

• 叙事逻辑生成 (Storyline API)：

  • 基于大模型生成起承转合的可视化叙事大纲。

L3：端到端解决方案 (Narrative Solutions) —— “完整的应用”

结合 L1 和 L2 能力，针对特定高频场景封装的“交钥匙”方案。

• 智能资讯可视化 (Smart News)：

  • 流程： 输入资讯文本 → 多Agent协同（意图识别/数据增强/Insight提取） → 自动图表生成 → 输出富媒体文章。

  • 价值： 自动化生产高质量的数据新闻内容。

• 深度文本可视分析 (Redefine/Deep Reading)：

  • 流程： 上传小说/长文 → 智能切割与脉络提取 → 生成宏观/微观视图。

  • 价值： 提供上帝视角（宏观剧情脉络）与微观视角（细粒度片段）的沉浸式阅读体验。

L4：开发者工坊 (Dev Studio) —— “提效的工具”

• 可视化配置平台： 现有的图形化配置工具。

• AI 辅助配置 (Copilot)： [本次新增] 基于自然语言的配置助手。

---

3. 重点功能升级计划

为了支撑上述架构，我们将对现有资产进行两项核心升级：

3.1 组件元信息增强 (Metadata Enhancement)

• 目标： 让机器“读懂”组件，实现精准推荐。

• 方案： 为每个组件增加标准化描述文件，包含：

  • 数据特征： 描述组件接受的数据形状（如：需1个维度+2个度量）。

  • 场景语义： 描述组件适用的分析意图（如：对比、分布、占比）。

  • 约束条件： 最佳展示的数据量级限制等。

3.2 自然语言配置 (Natural Language Configuration)

• 痛点： 传统代码配置门槛高，参数复杂，业务方难以理解参数间的依赖与冲突。

• 方案： 构建可视化领域的垂直知识库（RAG），结合 LLM 实现对话式配置。

  • 交互： 用户输入“把X轴标签改成红色，字号放大”，系统自动生成对应配置代码并实时渲染。

  • 价值： 极大降低非技术人员（如运营、产品）的制作门槛。

---

4. 官网体验设计策略

官网不仅是文档中心，更是能力的实时演示场。

• 首页：动态与互动

  • 拒绝静态图片堆砌。提供一个**”Try it out”**入口，用户输入一句话或一段数据，立刻演示“AI推荐 → 组件渲染”的全过程。

• 能力详情页：三段式工作流

  • 左侧配置区： 支持 Code 模式和 Chat 模式（自然语言）切换。

  • 右侧预览区： 实时响应配置变化，所见即所得。

  • 底部文档区： 展示API文档、元数据定义及适用场景。

• 解决方案页：滚动叙事 (Scrollytelling)

  • 针对“智能资讯”等复杂方案，采用滚动视差设计。随着用户滚动页面，动态演示后台数据如何一步步被加工成可视化图表的流水线过程。

---

5. 总结与下一步

本规划将数据可视化团队的定位从“前端组件库维护者”升级为“智能可视化服务提供商”。

通过将后端算法能力（Insight提取、文本分析）解耦并产品化，我们不仅能服务于前端开发者，更能直接赋能给业务侧的算法与数据团队，实现能力的原子化输出与灵活编排。

下一步行动：

1. 协议制定： 优先定义组件元数据（Metadata）的标准 Schema。

2. 原型开发： 完成官网核心页面的交互原型设计。

3. 知识库构建： 整理现有配置文档，启动配置助手的 RAG 语料构建。