从审美评分到垂直领域专家：AI 视觉评价该怎么做

最近在带新同事做可视化需求时，遇到了一个问题：他们可以结合 AI 把功能做出来，但很难判断做出来的东西好不好。

新同事还没有积累足够的数据可视化专业知识。面对一个明确、有成熟参考的需求，尚且可以通过对照来检查；但遇到探索性需求，连最后应该长什么样都需要研究时，这个问题就比较明显了。

AI 给出一个方案，他们不知道是否合理；AI 生成一个效果，他们也很难判断是否应该继续修改。最后只能被动地跟着 AI 的思路走。

有些结果看起来有图、有交互，也能运行，但实际根本不可用。还有一些效果做得挺复杂，却连最基本的问题都没有解决：这张图到底想说明什么，用户能不能看明白？

开发工具帮助他们更快地生成了结果，判断这些结果的能力却没有同步建立起来。

这让我想做一个工具，把可视化专家的经验整理进去，帮助新同事检查方案、发现问题，也让他们逐渐理解为什么这样做更合适。

一开始，我们把这个工具想得太大了。

先踩的一个坑：想做一个通用系统

最初设想的是一个能够解决各种可视化评价问题的系统。信息图、数据大屏、分析型 Dashboard、资讯卡片，最好都能交给它判断。

底层都是可视化，看起来应该有很多共通的知识。只要把专家经验收集得足够全面，再整理出一套评价标准，似乎就可以覆盖这些场景。

继续往下推，才发现这种“通用”很难落到具体判断上。

数据大屏、新闻信息图和分析工具，用户的目的不同，使用方式不同，评价标准也不一样。即使都在金融领域，行情界面、财报可视化和金融资讯卡片，也不能拿同一把尺子来衡量。

高信息密度放在专业分析界面里可能是合理的，放在手机资讯卡片里就可能难以阅读。醒目的大标题可以帮助新闻信息图传达重点，却可能占掉分析工具里宝贵的操作空间。

这些差别会直接影响字体、颜色、布局和交互的取舍。只说“层次清晰”“配色协调”“信息完整”，还不足以指导修改。

回头看，我们踩的坑就是过早地把范围定成了“所有可视化问题”。范围越大，评价越容易停留在泛泛的建议上。对于那些本来就缺乏判断经验的新同事，这种建议没有多少帮助。

所以，后面我开始倾向于把领域拆开。每个领域单独积累案例，明确自己的评价依据，再共用底层工具和流程。

专家点评里，应该留下什么

有了这个调整，再来看专家数据，关注点也会不一样。

我们希望收集的材料包括一张作品、专家认为哪里好或不好、为什么，以及他会怎么修改。这些可以看作专家标注，但只保存结论还不够。

比如专家说“颜色太多了”。如果直接把这句话交给 AI，很容易被整理成一条规则：减少颜色。

真正需要记录的是，这些颜色分别承担什么作用，为什么会干扰阅读，哪些颜色应该保留。换一个场景之后，这个判断是否还成立？

用多种颜色区分必要的类别，和为了装饰而添加颜色，评价依据就不同。

对新同事来说，这部分解释尤其重要。如果工具只告诉他“配色不合理”，他仍然不知道该怎么办，很可能再把这个结论丢给 AI，让 AI 自己决定怎么改。

工具需要把问题落到作品上：哪些元素争抢注意力，什么信息因此被淹没，修改之后希望用户先看到什么。

我暂时把这件事叫作“专家决策蒸馏”。这里的“蒸馏”描述的是目标：把专家在具体场景里的判断经验，整理成 AI 可以使用和检验的材料。实现上先用案例检索、提示词，还是进一步训练模型，可以后面再决定。

专家写下来的解释，也需要和他的实际选择、修改记录放在一起看。仅仅收集一批说得很有道理的点评，还不能证明我们已经掌握了他的判断方式。

专家意见不一致怎么办

一个专家能提供的材料有限，我们自然会想到收集更多设计师、课程、论文和设计社区里的点评。

但数据多了，马上会遇到意见不一致的问题。

有人强调极简，有人重视表现力；有人觉得信息太密，有人认为这些信息都应该保留。直接把这些结论放在一起，AI 应该按哪个标准执行？

这里先要弄清楚，专家们是不是在评价同一个任务。

如果一个面向快速浏览的普通读者，另一个面向需要反复查询的专业用户，他们对信息密度的要求不同，很正常。这类分歧其实包含了使用条件，不能简单当成相互矛盾的意见。

即使任务相同，也可能存在不同的风格偏好。这些差异可以保留，但应该记录来源和理由，不能混成一条没有条件的通用规则。

因此，案例里除了图片和点评，还需要记录它服务谁、解决什么问题、在什么设备和场景下使用。

我们需要的是条件清楚、理由能够检查的数据。收集更多结论，不能替代这一步。

统一维度之后，仍然需要上下文

我也考虑过先制定统一的评价表，例如视觉层级、字体、颜色、布局、间距、信息密度，再给每个维度打分。

这些维度可以帮助我们检查遗漏，但它们不能自动回答“这个设计是否合适”。

留白达到多少才算好？标题应该占多大空间？一屏应该展示多少指标？脱离具体任务，很难给出有用的答案。

对于可视化，还要先检查它有没有把问题讲清楚。图形表达是否准确，重要关系能不能被看见，用户是否容易产生误解。视觉上整齐漂亮，并不意味着这些事情已经做好。

所以，评价之前需要先写清楚：用户来这里做什么，首先应该理解什么，哪些信息必须准确传达，以及有哪些空间和交互限制。

明确这些之后，再检查视觉层级和布局，评价才有落点。

先学会比较，再考虑打分

这也让我重新考虑了“评分”这件事。

一张图得到 83 分，对新同事意味着什么？他知道下一步应该改哪里吗？换一位专家，分数会不会完全不同？

相比之下，我更想先收集这样的判断：在同一个需求下，A 和 B 哪个更合适，为什么？

例如保留原版，再分别修改字体、颜色和布局，让专家比较这些版本。讨论就可以落在具体变化上：哪次修改改善了阅读，哪次修改反而掩盖了重点。

两两比较也需要约束。比较目标没说清楚，或者两个版本同时改了很多地方，仍然很难知道专家到底在偏好什么。有些方案各有取舍，也应该允许回答“差不多”或“取决于使用条件”。

但对这个项目来说，这是一个更值得先尝试的起点。我们可以检查专家的选择是否稳定，也可以观察 AI 在新案例上的判断是否接近专家。

分数可以后面再加。先让系统具备比较方案、定位问题和解释修改理由的能力，对实际工作更有帮助。

一套框架，多个垂直领域专家

范围拆开之后，底层能力仍然可以复用。

文字识别、布局理解、案例检索和评价流程，不必每个领域重新实现。但领域定义、专家案例、偏好数据、常见错误和适用条件，需要分别维护。

例如先做一个“金融 AI 资讯卡片专家”。它只负责这类卡片，知道需要传达哪些信息，哪些数字和文字应该突出，以及常见的设计错误是什么。行情界面和财报分析，可以交给其他领域的评价能力。

这就是我理解的 One Framework, Many Experts。

这里的多个专家，也不一定意味着一开始就训练很多模型。同一个基础模型可以承载不同的领域配置。需要先分清楚的是，每个专家负责什么问题，依据什么判断，遇到什么情况应该承认自己无法判断。

对于当前这个需求，领域内真实专家的选择和修改记录，我会放在数据收集的第一位。尤其是修改前后的对照，以及那些看起来不错、实际却没有讲清楚问题的失败案例。

同领域的外部数据可以补充覆盖，设计理论和论文可以帮助解释和检查。AI 合成数据则可以用来生成候选版本，再交给专家比较，不能让 AI 自己生成、自己评价，最后把这些结果全部当作专家经验。

先验证它能不能帮助新同事作出判断

这个系统最终应该帮助新同事回答工作中的具体问题：当前方案哪里有问题，为什么有问题，下一步可以怎么改。

更进一步，他看过几次评价之后，应该逐渐能够自己发现类似问题。如果只是从“听开发 AI 的”变成“听评价 AI 的”，判断能力的问题仍然没有解决。

因此，接下来我会先选一个足够窄的场景，整理专家案例和修改记录，再留出一批新作品做验证。

一方面检查系统能否发现专家在意的问题，它提出的修改是否有效；另一方面，也要看新同事能否理解这些反馈，并据此调整自己的方案。

之后可以尝试让系统参与生成、评价和修改的循环，但前提是先证明评价本身有用。否则，多运行几轮只是多改几次，未必越来越好。

这次方案调整让我更确定了一点：框架可以共用，判断依据必须在具体领域里建立。先把一个小领域做扎实，让新同事遇到探索性需求时有可靠的参照，再扩展到下一个领域。