关于VISALL改版的想法

之前的组件库承载了过多职责，导致维护成本和业务方的使用成本都居高不下。因此，我们计划对其进行彻底的简化——甚至在未来的规划中，我们将不再需要这个臃肿的组件库。

回溯过往，我们将所有用例（Case）的逻辑都堆砌在 iFinD 的 spec 主题下。例如，单份文件可能包含 5000 多行代码，其中充斥着大量的 if-else 判断。这些逻辑的本质，实际上就是针对不同 Case 进行差异化的主题配置。

现在的重构思路是：将 Case 直接“拍平”。模型推荐的内容本质上是针对 Case 的推荐，它会明确告知我们应使用哪一个 Case。随后，我们通过转换函数获取该 Case 对应的配置信息（即来源于 DataV 平台的配置数据）。

核心流程设计如下： 业务方提供绘图数据 → 模型输出推荐的 Case 信息及数据映射关系 → 进入数据处理模块（进行转换、校验、映射） → 经过 Case 召回模块获取对应配置 → 最终生成可用于 StandardChart 渲染的配置代码 → 交付业务方渲染。

这种架构变革带来了三个显著优势：

第一，按需加载，降低复杂度。 用户在使用组件时，不再需要像以前那样即使只用一个功能也要加载那 5000 多行包含所有 Case 的代码。现在的机制是“用到哪个 Case 就加载哪个”，业务方的代码体积不再随组件库总case数N增长，仅取决于其实际使用的case数量k，实现了按需加载，具有良好的横向扩展性。

第二，大幅降低维护成本，提升排查效率。 以前的架构中，VISALL存在不同层级的主题覆盖和叠加问题。一旦出现 Bug，我们需要在数千行混合业务代码和层层逻辑中抽丝剥茧，判断问题究竟出在底层、VISALL 层还是用户配置层。而新的架构不存在这个问题，所有的配置都收敛在当前 Case 中，我们只需排查特定 Case 的代码即可。

第三，为 AIGC 可视化奠定基础。 我们未来的目标是让大模型直接生成数据可视化图表的配置代码。新的架构极大地简化了模型的工作量——模型只需要关注如何生成 StandardChart 的配置即可。这显著提升了模型生成结果的可行性和稳定性，也能与团队其他同事的工作完美串联。

未来，我们需要维护的不再是那个层级叠加、臃肿不堪的组件库，而仅仅是 StandardChart 标准本身以及分散的 Case。我们将围绕 StandardChart 持续进行相关的组件、工具及平台 AI 化的建设。

接下来，我们需要重点推进以下几项工作：

第一，快速构建 Demo，验证全链路跑通。 我们需要尽快写一个 Demo，旨在打通从模型输出结果到 StandardChart 最终渲染的完整流程，确保技术路径的可行性。

第二，调研业务方依赖，确定 VISALL 兼容粒度。 需要与 iFinD、AIME等各业务方确认，排查他们是否使用了我们基于 DOM 编写的组件（例如 Legend 图例等）。这一调研结果至关重要，它将决定我们在新架构中需要对老的 VISALL 兼容到何种程度。

第三，抽离通用逻辑，复用于 AIGC。 将现有代码中关于数据校验和转换的部分抽离出来。这部分核心逻辑在后续的 AIGC流程中仍然会被高频复用，提前剥离能避免重复建设。

第四，全量迁移 Case，确保无缝切换。 将目前 VISALL 中的所有 Case 转换为 StandardChart 的 Case。这是保证业务方切换到新版组件后，业务能够保持正常运转的关键步骤。

此外，我们还需要深入排查现有架构中是否存在其他隐蔽功能，并在本次转换中一并考虑。必须杜绝因功能遗漏而导致业务缺失的情况发生。