过去一年里，视觉类 AI 应用的开发者大概都有同一种体会：模型质量突飞猛进，业务落地却举步维艰。文生图、图生图、可控生成，demo 一个比一个惊艳，可一旦要放进真实产品，问题立刻暴露出来——生成结果不遵守约束、不能局部修改、多轮迭代后风格漂移、过程不可追溯。于是你会发现，真正挡住应用的并不是“模型不会生成”，而是“系统不能创作”。
“会生成”是模型能力，“能创作”是系统能力。单次推理输出一张漂亮的图，只能说明生成器本身质量高；但真实业务需要的往往是“按约束产出 → 自动或人工评审 → 局部修改 → 多轮迭代 → 结构化交付”这样一个完整流程。RabbitVis 这类项目之所以值得关注，正是因为它试图把视觉 AI 从“一个输出接口”变成“一个创作工作流”，探索的是 AI 应用的新范式。
这篇文章我会从三个层面展开。第一，讲清“会生成”和“能创作”的技术差异，帮你判断一个视觉应用到底缺在哪一层。第二，拆解视觉创作系统的核心模块，包括内容表征、可控生成、反馈评估和工程接入。第三，给出一个可以直接运行的最小视觉创作工作流，包含代码、配置、验证方式和常见问题排查。文章不承诺某一款工具能解决所有问题，但希望你看完能建立起适合自己的判断框架。
1. 为什么「会生成」不等于「能创作」
1.1 一个真实到让人焦虑的开发场景
假设你负责一个电商营销系统，业务方的需求是“每周自动生成一组品牌主图”。如果只是调用图像生成模型，你很快会遇到三个问题。
第一个问题，品牌元素经常变形。模型生成的图很惊艳，但 logo 的位置、品牌色的色值、产品的外形都不可控，生成十次可能只有两次能直接用。第二个问题，设计师想改某个局部时，模型不支持局部编辑，只能整张重新生成，而重新生成的图又会引入新的随机性。第三个问题，换一套提示词，整体风格就跑了，和品牌视觉规范完全对不上，评审环节反复打回。
这三个问题说明，你已经把“生成能力”接进来了，但没有把“创作能力”做出来。所谓创作能力，我把它理解为一种系统性能力：能按要求输入，能按约束生成，能对输出进行评估，能对不满意区域进行局部修改，能在多轮迭代中保持稳定的风格和语义，并且能把每一步的过程记录保留下来。单独拆开看，每一条都不算是大难题，难的是把它们组织成一个完整的工作流。
1.2 生成与创作的四个关键差异
要理解这两个概念的差异，可以看下面这张对比表。
| 对比维度 | 会生成 | 能创作 |
|---|---|---|
| 执行方式 | 一次提示词输入，一次推理输出 | 多阶段工作流，包含生成、评估、修改循环 |
| 约束处理 | 靠提示词硬试，约束满足率不稳定 | 通过条件控制、后处理、规则校验保证约束 |
| 局部修改 | 一般不支持，改动需要重新生成 | 通过分层表征或图像编辑能力局部修改 |
| 迭代一致性 | 风格和语义容易漂移 | 有固定锚点，在多轮修改中保持稳定 |
| 过程可追溯 | 只有原始提示和最终图片 | 保留中间结果、反馈记录、版本信息 |
| 工程对接 | 适合单点 API 调用 | 适合嵌入复杂业务流程 |
背后的原因在于，当前的视觉大模型本质上是一个“输入文本 → 输出图像”的映射器。它的优势是强大的泛化能力，弱点是缺乏可组合性。这种“可组合性”恰恰是创作系统的地基。创作系统需要把大模型当作一个生成内核，再围绕它搭建调度、控制、评估和编辑能力。
所以，判断一个视觉 AI 应用是否真正进化，不能只看“它生成的效果好不好”，而要看“它能否被纳入创作流程”。前者是模型选型问题，后者是系统架构问题。RabbitVis 探索的“AI 应用新范式”，更接近后者的思路。
2. RabbitVis 想做的「视觉创作系统」是什么
2.1 可编排、可控、可演进：三个关键词
RabbitVis 这个命名本身就传递了一个很有意思的判断：一个擅长“看”的视觉系统，可以不只是“生成一张图”，而是围绕视觉内容完成一整套可编排的创作任务。从范式角度拆解，它的关注点大概率会集中在三个关键词上：可编排、可控性、可演进。
“可编排”指的不是写几行 Python 调用模型接口，而是把生成模型、编辑模型、评估模型、规则引擎、人工
