Miora画布与Skills：可复用品牌工作流与团队资产

画布解决资产之间的关系，Skills 解决流程能否重复执行；两者都不能替代 brief、人工确认和版本管理。本文以 Miora 为例，把一项品牌任务拆成方向、核心资产、衍生物料和交付节点，再说明如何把成功步骤写成 Skill，避免一次性的灵感被误当成稳定流程。文中只讨论可复现的步骤，不把单次结果扩展成产品承诺；每个结论都标注前提、证据和无法覆盖的边界。读者可以先完成最小验证，再按自己的版本、权限和数据补充实验。

上一期我们讲了 Miora 的 Memory。

Memory 解决的是“结果像不像你”：它保存审美、品牌色、排版习惯和禁用项。

但只靠记忆，还不能保证一个团队稳定地完成一整套任务。你可能知道要做极简风，却仍然不知道先做 Logo 还是先定色板；今天做电商主图先出产品图，明天做同类项目却先写文案；同一套流程每个人都走一遍，效率和质量都不一样。

这就是画布和 Skills 的价值。

画布负责把图片、视频、3D、UI 和文字组织在一个可继续修改的工作台上；Skill 负责把“从 brief 到交付”的步骤保存下来，下一次不必从零开始。

项目入口：Miora

一、聊天是入口，画布才是工作区

传统 AI 工具通常把结果放在聊天记录里：上面一条指令，下面一张图片，再下一条指令又生成一张新图片。结果越多，越难比较版本和来源。

Miora 的画布把这些结果变成节点：

~~~text
创意 brief
|
方向 A ---- Logo 方案 ---- 社交媒体封面
|
方向 B ---- 主视觉海报 ---- 活动短视频
|
参考图 ---- 色板 ---- UI 页面 ---- 3D 资产
~~~

画布的意义不是让页面看起来更大，而是把创作对象和关系显性化。你可以看到：

• 哪个是最初的方向，哪个是后续迭代。
• 哪张图是主视觉，哪些是衍生物料。
• 哪个颜色、角色或 Logo 被多个资产共用。
• 哪些节点可以继续修改，哪些已经准备导出。

当你说“把这个标题改大”时，画布上下文能帮助 Agent 理解你指的是哪个资产和哪一块区域。对多资产任务来说，这比在几十轮聊天里反复描述“上一张右边第二个图”更直观。

二、一个品牌任务应该怎样铺到画布上

不要一上来就让 Miora 生成几十张图。先把画布分成四个区域：

~~~text
左侧：brief、受众、用途、限制和参考
中间：方向 A / B / C 的比较
右侧：确定后的主视觉和品牌核心资产
下方：衍生物料、尺寸变体和导出版本
~~~

以“青芽轻食”开业为例，可以按这个顺序：

1. Brief 节点

写清楚目标、受众、发布渠道、主文案、视觉方向和禁止项：

~~~text
项目：青芽轻食开业视觉
受众：城市白领和周末消费者
目标：让用户一眼知道品牌做什么，并记住开业优惠
渠道：小红书、公众号、门店立牌
主文案：开业第一周半价
风格：米白、深绿、浅棕，清爽、克制、有自然感
禁止：霓虹、二次元、复杂贴纸、密集小字
交付：1 张主海报、1 张方形封面、3 张卖点图
~~~

2. 方向节点

让 Agent 先给两个或三个方向，并说明每个方向适合的场景：

~~~text
请先生成三个视觉方向，不要直接完成全部物料。
每个方向说明：构图逻辑、颜色比例、主体选择、标题位置、适合的渠道。
请把三个方向放到画布上，方便我比较。
~~~

方向比较的重点不是哪张“更漂亮”，而是哪张能支撑后续整套资产。一个单张很惊艳但无法裁切、无法延展、文字不可读的方向，不一定适合品牌生产。

3. 核心资产节点

确定方向后，先做会被多个物料复用的资产：

~~~text
Logo 处理
主色和辅助色
字体或字体气质
主视觉构图
产品或角色形象
常用的标题和文案节奏
~~~

这些资产确认之后，再去做封面、卖点图和短视频，风格漂移会少很多。

4. 交付节点

最后把要发布的版本集中到交付区：

~~~text
小红书竖版
公众号头图
门店立牌
方形头像或封面
短视频首帧和结束帧
~~~

每个节点可以标记尺寸、文案版本、状态和负责人。Miora 的画布不是完整项目管理系统，团队仍然需要在外部工具里维护最终审批、文件命名和发布记录，但它可以成为创意探索和资产迭代的中心。

三、局部编辑：先圈区域，再写动作

Miora 的局部编辑是画布工作流里最实用的一环。它适合处理“整体方向已经对了，只需要修一块”的情况。

1. 修改文字

~~~text
只修改上方主标题：
将“春日新品”改为“开业第一周半价”。
保持标题大小、位置、背景、Logo 和主体图片不变。
~~~

如果文字是关键交付内容，生成后一定要人工放大检查。不要因为 Prompt 写对了，就默认生成图片里的每个字都准确。

2. 修改构图区域

~~~text
我框选的是右侧产品区域。
请把产品主体向左移动，为右侧标题留出空间。
保持产品外观、光线、背景颜色和画面比例不变。
~~~

3. 删除和替换元素

~~~text
删除我圈出的装饰贴纸和右下角的小图标。
不要增加新的装饰，保持背景留白和主色不变。
~~~

4. 扩图和统一尺寸

~~~text
请把这张横版主视觉扩展为竖版海报。
保留主体和标题层级，把新增空间用于留白，不要在边缘随机增加人物或产品。
~~~

如果需要把多张图放到同一套活动物料里，先统一画布比例和视觉安全区，再让系统生成不同版本。否则每张图都可能有不同的标题位置和主体大小，后续很难排版。

四、Memory 和 Skills 到底有什么区别

两者会一起影响结果，但解决的不是同一个问题：

可以用三个问题判断该放在哪里：

~~~text
这是换项目后仍然成立的规则吗？ -> Memory
这是一个项目中重复执行的步骤吗？ -> Skill
这是本次任务的图、视频或版本吗？ -> Canvas
~~~

例如：

• “默认使用低饱和配色”是 Memory。
• “先做 Logo，再做主色，最后生成 3 张卖点图”是 Skill。
• “青芽轻食 2026 年开业海报”是当前 Canvas。

如果把所有东西都写进 Memory，长期规则会越来越乱；如果只存 Skill 而没有品牌 Memory，流程虽然快，作品却可能不像同一个品牌。

五、从一次项目创建自己的 Skill

不要一开始就写一个“万能设计 Skill”。先选一个每周都会重复的任务，例如：

• 小红书封面批量制作。
• 电商商品卖点图。
• 新产品发布视觉。
• 品牌活动海报。
• 影视项目分镜概念图。

第一步：记录真实流程

先不用追求漂亮的名字，把自己实际会做的步骤记下来：

~~~text

1. 读取品牌定位和本次活动 brief
2. 确认受众、渠道和交付尺寸
3. 生成两个主视觉方向
4. 选择一个方向并固定核心资产
5. 生成主图和三张卖点图
6. 检查文字、Logo、尺寸和禁用项
7. 导出并命名文件

~~~

第二步：补上每一步的输入和输出

只有步骤没有输入输出，Skill 仍然很难复用。可以继续写：

第三步：把确认点写进去

一个好的 Skill 不会让 Agent 一路自动跑到最后才让你看。它应该在关键节点停下来：

~~~text
方向确认：等待用户选择 A、B 或 C
核心资产确认：等待用户确认 Logo 和主色
交付前检查：列出文字、尺寸、版权和禁用项问题
~~~

在创意工作里，Ask 模式不是降低自动化程度，而是把人工判断放在最值得判断的地方。完全自动执行适合重复、确定性高的步骤；方向和品牌核心资产仍然应该保留人工确认。

第四步：保存并命名

Skill 名称应该能让团队一眼知道用途：

~~~text
品牌-小红书封面-竖版
电商-新品卖点图-三张套件
影视-短片分镜-六镜头
个人IP-栏目头图-极简留白
~~~

名称里包含场景、交付物和关键变体，比“我的设计流程 v2”更容易被别人正确调用。

素材显示，保存 Skill 时，当前的记忆规则还可能一起被打包。这个能力很方便，但也带来一个管理要求：保存前检查 Memory，确认里面没有临时活动文案、私人偏好或不应该共享的项目资料。

六、把 Skill 变成团队资产

一个人使用 Skill，重点是节省重复劳动；团队使用 Skill，重点是减少交付差异。

1. 先做团队版输入模板

要求所有人提交至少这些信息：

~~~text
品牌或项目名称
产品 / 活动目标
目标用户
发布渠道和尺寸
必须出现的文案
必须保留的资产
禁用元素
截止时间和审批人
~~~

输入质量不一致时，即使使用同一个 Skill，最终结果也会差很多。

2. 再划分 Skill 的可修改范围

团队 Skill 里有些规则可以开放，有些应该固定：

Miora 的 Skill 分享可以帮助团队复用流程，但企业仍需要在外部保存正式品牌规范和审批记录。社区 Skill 可以作为灵感和起点，不能自动等同于公司已批准的生产流程。

3. 版本不要覆盖式保存

当品牌规范变更时，不要直接覆盖正在使用的 Skill。可以保留：

~~~text
品牌-电商主图-v1
品牌-电商主图-v2
生效日期：2026-08-01
变更：主色从深绿调整为橄榄绿，标题由居中改为左对齐
适用项目：新品系列 B 及以后
~~~

这样出现视觉差异时，团队能回答“为什么变了”，而不是把问题归因于模型随机性。

七、从画布到交付，不要忽略最后 10%

AI 工具很擅长快速给你多个方向，但真正进入发布环节前，还需要一轮人工验收。

1. 文字检查

• 品牌名是否拼写正确。
• 价格、日期和活动规则是否准确。
• 小字在手机上是否可读。
• 标题和副标题有没有被裁切。
• 同一套物料的文案是否一致。

2. 视觉检查

• Logo 比例和安全区是否正确。
• 主色是否超出品牌规范。
• 人物、产品和背景是否出现结构性错误。
• 主视觉在不同尺寸裁切后是否仍然成立。
• 同一组物料是否像来自一个项目。

3. 文件检查

• 导出格式符合发布平台要求。
• 文件尺寸和清晰度达到用途要求。
• 文件命名能对应项目、渠道和版本。
• 公开发布和内部留档使用不同目录。
• 资产是否包含不应外发的参考图或隐藏信息。

可以让 Miora 在导出前先列一份问题清单：

~~~text
请对当前画布中准备导出的资产做交付前检查。
按文字、Logo、布局、颜色、尺寸、版权风险和文件命名分类列出问题。
不要为了让清单好看而默认全部通过；无法确认的地方标记为“需要人工确认”。
~~~

这能帮助你发现问题，但不能替代人对最终文件的检查。

八、上游 API 如何接住 Miora 后面的生产链路

Miora 适合在前端完成创意探索、方案比较、画布迭代和资产导出。企业真正进入生产后，往往还需要把确认后的规则接到更多系统：

~~~text
Miora 画布
-> 已确认的品牌规范与资产
-> 企业内容系统 / Agent / SaaS / 客服 / 知识库
-> 上游 API 企业API网关
-> 文本、图片、视频、Embedding 等多模型
~~~

上游 API 的营销价值不在于替 Miora 假装提供一个未公开的插件，而在于把后续业务调用统一起来：

• 一个企业 API 入口接入多种模型。
• 按项目、环境、团队和角色拆分 API Key。
• 为文案、图片分析、视频脚本、知识库问答设置不同模型。
• 记录调用耗时、Token、错误、重试和费用。
• 对高成本视觉任务设置预算、额度和告警。
• 在模型不可用时做合规的路由切换和降级。

例如，Miora 确认了“青芽轻食”的品牌规则后，企业内容 Agent 可以通过 上游 API 调用文本模型生成商品文案，通过图像模型生成规格变体，再让审核系统检查禁用词和尺寸。Miora 负责创意源头，上游 API 负责企业生产链路的稳定接入和成本治理。

是否能把 上游 API 直接填入 Miora 的模型配置，需要以 Miora 当前页面和官方开放能力为准。文章只把 上游 API 放在企业自有工作流的明确位置，不把外部 API 网关能力冒充成 Miora 原生能力。

九、适合和不适合用 Skills 的任务

适合

• 每周重复的社交媒体封面。
• 固定结构的电商卖点图。
• 同一品牌不同主题的活动海报。
• 有明确镜头模板的分镜设计。
• 需要一套固定交付物的品牌小项目。

不适合直接固化

• 每次都完全不同的实验性创作。
• 尚未确定审美方向的早期探索。
• 需要大量人工判断的高风险客户项目。
• 依赖最新法规、价格或未经审核事实的内容。
• 还没有明确输入、输出和验收标准的工作。

Skill 的目标是减少重复判断，不是把所有创意都做成流水线。该停下来确认的地方，应该明确停下来。

十、画布与 Skills 验收清单

画布验收

• [ ] 能区分 brief、方向、核心资产、衍生物料和导出版本。
• [ ] 能在画布上找到某个资产的来源和后续版本。
• [ ] 能通过圈选或框选只修改目标区域。
• [ ] 主视觉、封面、卖点图和短视频首帧之间保持同一套规则。
• [ ] 画布中没有混入未经授权的客户或内部敏感素材。

Skill 验收

• [ ] Skill 有清晰的适用场景和名称。
• [ ] 输入、步骤、输出和人工确认点写清楚了。
• [ ] Memory 和 Skill 的职责没有混在一起。
• [ ] 保存和分享前检查了是否带入私人或项目敏感信息。
• [ ] 团队已用至少两个不同项目跑过同一 Skill。
• [ ] 版本变更有记录，没有直接覆盖生产中使用的旧版本。

交付验收

• [ ] 文字、Logo、颜色、尺寸和裁切已人工检查。
• [ ] 导出格式、文件名和目录符合团队约定。
• [ ] 不能确认的版权、商用授权和人物肖像问题已转人工处理。
• [ ] 需要接入企业内容或 Agent 系统时，已评估用 上游 API 做统一模型入口、Key 管理和成本治理。

总结

Miora 的画布和 Skills 组合起来，解决的是创意工作的两个重复问题：

~~~text
画布：让当前项目的资产、版本和关系看得见
Skill：让下一个同类项目不必从零走流程
Memory：让结果保持你的品牌和审美
~~~

真正高效的路径不是让 AI 一次生成所有东西，而是先确认方向，再固定核心资产，最后用 Skill 复用已经验证过的步骤。这样你得到的不只是几张图，而是一套可以继续迭代的创意生产流程。

结论

本文给出了问题定位、配置或创作流程的可执行路径。实际结果仍取决于当前版本、权限和运行环境，提交前应按官方文档复核可变字段，并保留失败证据和回滚边界。