从模块化走到生成式

从 Widget 到生成式软件

公司最近在做 Widget，也就是一些小的功能控件。看完之后我的第一反应是，这其实就是模块化、组件化思路的又一次形态变化。这个理念从软件开发早期就有，只是每过一个阶段，名字和形态会变一变，回到第一性原理上看，讲的还是同一件事。

再往前推一层，能看到老板很多年前就想要的东西：把产品功能打散成很多独立的小模块，各个模块可以自由组合、互相调用。这样做一是不用重复开发相似的功能，二是可以按用户的个性化需求去定制页面，做到真正的 KYC。这个设想在更早的时候受限于前端的组织和交付方式，一直没能完全落下去。

AI 进来以后，还能有更好的调度方式：让 AI 去调度这些模块，按用户的需要动态生成内容。

这段时间不少产品也在做同一类事情。Kimi 在做 Dashboard 和小控件的生成，WorkBuddy 在做一键生成小程序这类能力。豆包的对话里已经大量出现表格和各种可视化，用来辅助讲解问题；ChatGPT 最近也会在对话里实时生成 HTML 可视化做补充说明。

按这个方向看，未来的软件都会是生成式的，区别在于生成之后怎么用。

常驻的模块，和即抛即用的内容

现在能看到的生成式内容有两类，它们的边界其实挺清楚。

一类是常驻的。生成一次，之后长期留在页面上，用户会反复打开它。这类内容背后接的是稳定的数据源，数据一变跟着自动更新，比如跟行情数据相关的模块。用户会记住它长什么样、摆在哪个位置，用久了形成习惯，出了问题也会当成 bug 反馈过来。所以常驻内容的生成质量要能长期撑住，我们现在说的”生成效果差”，在它身上最容易被看出来。

另一类是即抛即用的。它跟着用户当前的问题走，问题讲明白了，它的任务也就结束了。这类内容不用持续更新，也不用谁去维护，用完就丢。对话工作流里的表格、可视化大多属于这一类，豆包里的那些讲解图，ChatGPT 在对话里实时生成的 HTML 可视化，都是现场生成、看完就过。

区分这两类，主要看两件事：有没有稳定的数据源，以及会不会被用户反复打开。接不上稳定数据源的，基本只能即抛即用；会被反复打开的，就得按产品的标准去做。

我们自己做的 Widget 两者都会涉及，所以它同时带着这两类内容的问题。

做的时候撞上的两个问题

我们最近一直在做的也是这块，主要是靠实时生成、AIGC 生成一些可视化效果，比如信息图、功能模块，Widget 也是其中一部分。遇到的问题很多主要有两个。

第一个，生成的内容并没有真正解决用户的问题，它没有理解用户的问题和意图。第二个，生成的效果很差，美观度和丰富度都不到位，跟那些精雕细琢过的前端产品、组件放在一起，差距一眼就能看出来，图表类的生成也一样。

缺的是领域经验

这两个问题的原因在一个地方：缺领域经验。

要真正解决用户的问题，得先有人懂用户的意图，同时对金融相关的概念、逻辑、策略有足够深的见解，这里缺的就是一个金融领域的专家。生成出来的组件、控件效果差，缺的是一个视觉设计方面的领域专家。

所以想把 AIGC 做好，想把产品做到深水区，核心是构建领域经验、定义设计规范。这是接下来一段时间要重点攻克的。

打算怎么做

公司里是有这方面专家的，设计有，业务也有。但他们不可能每个任务都介入一次。可行的做法是借他们的经验去构建一个 AI 领域专家，方式上偏”大力出奇迹”，把他们的判断变成数据，再让模型学进去。

第一块是意图识别和回答。我们打算从公司数据分析平台里真实的用户问句和我们当时给出的回答入手做数据挖掘，把有用的信息挖出来；再用 AI 做一轮评审，把难以决断的部分交给业务专家做标注、做排名。这批标注数据用来微调我们的 AI 领域专家。

第二块是视觉，思路类似。拿前面那批真实问句和我们解析出来的答案，调用现有的各种可视化生成能力，视频生成、信息图生成、HTML 生成、可视化组件生成，先给这些问题都生成一版可视化答案。AI 先出一轮，把明显不行的筛掉，剩下难以抉择的交给设计专家标注排名。基于这些排名，反过来微调可视化生成的 Agent 和设计规范，形成一套数据可视化的设计专家。

这条路能不能走通，现在还不知道。我们会尽快试一下。