Holonic Asset 的产品取舍：我们优化的不是第一张图，而是第 20 个资产

如果只想生成一张好看的图，为什么还要做 Holonic Asset？

做过独立游戏或者小团队开发的人，大概都经历过类似的“AI 幻灭时刻”：

打开 ChatGPT 或各类 AI 生图工具，输入几句 Prompt，几十秒后蹦出一张精美绝伦的像素骑士。你兴奋地觉得“一个人做独立游戏的时代终于来了”。

但当你真正准备把素材塞进游戏引擎时，现实会立刻泼来一盆冷水：

• 你想让骑士跑起来，AI 却每一帧都画出一套新盔甲，比例忽大忽小；
• 你想做个匹配的小怪，结果画风完全对不上，一个带厚重黑边，一个泛着柔光；
• 你想生成一套地牢地砖，拿到的却是一整张无法无缝拼接、透视歪斜的背景插画；
• 你好不容易抠图切出几十张 PNG，改天想换个发色，只能把上面的痛苦流程从头再受一遍。

生成一张好看的图片只是玩具，能持续产出一整套风格统一、能放进引擎运行的游戏资产，才是生产力。

这两个目标并不对立，但资源有限时，它们会导向截然相反的产品优先级。

这篇文章记录的不是一份罗列功能的好消息清单，而是我们在做 Holonic Asset 过程中经历的真实权衡：我们决定把精力押在哪些地方、主动放弃了什么、为此承受了哪些代价，以及在什么情况下我们会承认当时的判断需要调整。

我们如何理解“真正的产品取舍”？

很多团队喜欢把产品原则写成“追求极致体验”、“简单易用”、“重视用户”。但这类口号在实际做决策时毫无指导意义——因为没有人会公开说自己“追求劣质体验”或“故意把产品做难用”。

在梳理这次复盘时，我们参考了几家优秀团队的做法：

• Intercom 提出了一个很犀利的检验标准：一条原则的反面，也必须能成为另一家成功公司的合理选择。如果反面没人会选，那它就只是一句废话。
• Figma 强调工程价值观必须写清为了这个选择，团队主动牺牲了什么。
• Basecamp (Shape Up) 坚持把不做的事情（Out of bounds）作为产品方案的第一等公民，写在明处，而不是藏在未来的饼里。
• Linear 宁可把早期切片做得极深极窄，也不做一堆看似完整却无法验证真实价值的半成品。

结合这些思考，我们对 Holonic Asset 的每一项取舍，都逼自己回答四个最实在的问题：

1. 面临的现实约束是什么？
2. 我们选择优先做好什么，放弃了什么？
3. 我们为此主动承受了什么代价？
4. 出现什么明确信号时，需要推翻这个决定？

取舍一：专供独立开发者与小团队，不做泛大众社区，也不做 3A 定制管线

在最初的立项讨论中，潜在用户看似非常广泛：像素画爱好者、独立游戏开发者、商业游戏美术团队、甚至纯粹想找乐子的网友。

但拆开来看，这几类人的诉求完全不在一个频道上：

• 泛大众 / 爱好者：要的是一键出图、随机惊喜、高赞分享，不在意尺寸是否对齐网格，也不在乎能不能切帧导出；
• 商业游戏团队：已有成熟的美术管线，最在意与 Photoshop、Aseprite 等既有工具流的集成、复杂的审批流与定制化流程；
• 独立开发者 / 2~5 人小团队：往往没有专职美术或美术资源极度吃紧，最头疼的是“怎么用有限的人力，在合理时间内拼出一套画风不崩、能跑通玩法的完整游戏素材”。

我们果断把所有筹码压在第三类人身上。

我们的选择

• 优先做跨资产的世界观一致性，不做单张图片的社交爆款属性；
• 优先做帧动画、图层分离、瓦片网格与引擎导出，不做通用的自由修图大杂烩；
• 优先压缩从构思到整个游戏原型跑通的总耗时，不卷单张图片秒级生成的极致速度。

付出的代价

产品的受众面明显变窄了。在给不懂游戏开发的人演示时，我们很难仅凭一张图让他们“哇”出来，因为 Holonic Asset 的价值藏在“生成第 20 个道具时画风依然不崩”和“一键导出即可在 Godot/Unity 播放动画”这些苦活累活里。此外，用户首次上手需要理解项目、透视和资产分类，教育门槛高于普通生图工具。

重审条件

如果核心独立开发者群体已经能顺畅地完成整套资产交付，但产品增长遇到了严重的天花板，我们会考虑向相邻场景拓展；但在核心生产闭环被充分验证前，绝不为了迎合泛大众用户而稀释游戏向功能。

取舍二：把 2D 像素垂直做穿，不做“表面全能”的空壳平台

如果要做一个“AI 游戏资产生成平台”，最容易让人兴奋的做法就是把所有热门概念都堆在首页：写实原画、二次元立绘、Live2D、UI、音效、BGM、技能特效……

我们克制住了这种冲动，第一阶段只做 2D 像素游戏资产，并且宁愿只把其中几条链路彻底打通，也不把每个分类都做成一个“只能点生成、不能落地用”的花架子。

为什么偏偏选 2D 像素？

最直接的原因，是当前 AI 生图在高清大图和写实风格上的表现，在游戏开发里很容易“见光死”：

• 浓重的“AI 塑料感”与浮空噪点：高分辨率下的生成图片极易出现杂乱噪点、边缘发虚、过度平滑的油腻阴影以及诡异细节，玩家和开发者隔着屏幕一眼就能看出“这是 AI 生成的廉价货”；
• 游戏质感瞬间崩塌：一旦在游戏里塞满这种高清但充满塑料感的 AI 图片，整个作品立刻会被打上“粗制滥造的 AI 换皮游戏”标签。

而 2D 像素画恰好避开了这些致命弱点，并具备两重巨大优势：

1. 通过确定性处理洗掉“AI 味”： 像素画的核心是离散网格与有限色板（Palette）。AI 生成的原始图像哪怕带有一些模糊渐变和噪点，经过后处理流水线的降采样抽帧、色板量化（Quantization）与点阵对齐后，浮空的杂色与油腻感会被程序确定性地清洗干净，呈现出干净、纯粹、带有手工质感的游戏素材。

2. 拥有严苛且可量化的工程交付约束： 像素艺术不是“像不像”的玄学主观判断，而是有一组非黑即白的工程标准：

   • 网格与尺寸：16x16 就是 16x16，边缘绝不允许半透明杂色抗锯齿；
   • 调色板（Palette）统一：全局素材必须共享有限色板，否则拼在同一屏幕上就会混乱；
   • 动作与安全区：4 方向/8 方向人物必须严格对齐重心锚点与包围盒，否则在引擎里播放时会疯狂抖动；
   • 瓦片（Tileset）规则：地砖必须能被程序切分并按 3x3 Auto-tile 规则无缝拼装。

在写实插画里，模型多画一笔线条你很难用代码自动判断对错；但在像素画里，多一个杂色像素或者边缘错位，素材在引擎里当场报废。像素画不仅能天然洗掉 AI 的廉价塑料感，更是检验 AI 生成能否成为严谨工程工具的绝佳试金石。

宁做纵向切片（Vertical Slice），不做横向空壳

在功能排期上，我们坚持“做穿一条，再开一条”：

• 我们优先把 Character（角色）、Object（物件）、Scenery（分层场景） 与 Tileset（瓦片集） 从“参数配置 -> AI 生成 -> 抽帧/去背/规格归一化 -> 画布微调 -> 打包导出”整条流水线跑通；
• 而像 UI Set（界面组件集）或 Audio（游戏音效），虽然在数据结构里已经占了位，但只要生成和交付质量还没达到可用标准，我们就老老实实在界面上标明“暂不可用”或“后续接入”，绝不为了凑一个整齐好看的功能矩阵，给用户放一个输入 Prompt 吐一张无用图片的空按钮。

付出的代价

在很长一段时间里，产品的界面看起来“不够全能”，甚至有些不对称。有新用户会问“为什么不能直接生成背景音乐？”或“为什么不支持写实立绘？”我们必须花精力向用户解释我们的能力边界，并坦然接受非目标用户的流失。

重审条件

当且仅当新的资产类型（如 UI 矢量切片或 8-bit 音效）不仅能调用模型 API，而且能被定义出一套清晰的“交付验收标准”，并融入统一的 Project 和导出规范时，我们才会正式开放它的生产链路。

取舍三：从 Project 开始，而不是每次都从 Prompt 开始

打开输入框直接打字（Prompt-first），是对新用户阻力最小的方式。但只要你尝试过用这种方式做游戏，就会发现 Prompt 最大的问题是没有记忆。

生成第 1 个小兵时，你在 Prompt 里写了“16-bit, top-down 45°, desert theme, nes palette”；到做第 10 个建筑时，你漏掉了两个词，结果出来的图透视完全歪了。你把所有精力都耗费在跟 Prompt 的字眼做拉锯战上。

我们的选择

Holonic Asset 强制以 Project（项目） 作为正式生产的起点。

用户在创建项目时，先固定下整个游戏的核心约束：

• 游戏类型（Game Type） 与 视角透视（Perspective）；
• 目标平台与分辨率基准；
• 项目级参考图（Project Reference）：奠定全局色调、像素密度与线条风格。

后续在项目里创建任何具体 Asset（比如“火法师”）时，用户只需要关注这个角色本身的特点（“红袍，手持法杖”）。系统会自动将 Project 的全局上下文与局部参数合并。

更进一步，我们把参考图的权责严格拆开，避免模型胡乱参考：

1. Project Reference：只负责锁定整个项目的画风、调色板和像素颗粒感；
2. Creating Reference：只负责当前这个资产的长相和身份特征；
3. Nexus Reference：允许从同项目的已有资产借用细节与系列感，但绝不能篡改当前资产的主体与动作。

付出的代价

从注册到拿到第一张图，用户需要先经历“建项目、选透视、传参考”的流程，首张图的等待时间从十几秒拉长到两三分钟。对于那些只想“随便玩玩”的用户，这一步会造成明显的流失。

重审条件

如果数据证明大量真实独立开发者在 Project 初始配置阶段就彻底放弃，我们会推出低门槛的“快速灵感试玩（Quick Generate）”模式；但即便如此，试玩产出的单张图片也必须能一键“无损收编”进某个 Project 中，而绝不能演变成一个游离在项目外的孤立图库。

取舍四：把结果建模为“游戏资产”，而不是当成扁平图片

在大多数系统里，一张图生成完就是一个 URL 或一个 PNG 文件。这种做法后端实现最轻松，但对于游戏开发来说，它把所有脏活都推给了下游。

游戏资产是有生命的结构化对象：

我们的选择

我们在系统里将 Asset 建模为拥有独立生命周期与内部结构的业务实体。

例如，我们把原本泛指的 UI 明确重构为 UI Set——它指代的绝不是一张静态截图，而是一组拥有切片和状态属性的独立组件集。虽然这要求我们为每种资产设计专属的 Schema、编辑器交互、状态机与转换算法，但它换来的是资产一生成就是“结构完整的半成品”，而不是“一张需要大量二次加工的死图”。

付出的代价

研发成本指数级上升。每新增一种 Asset 类型，前端要写专用画布与时间轴，后端要写专门的解析处理流水线，无法像普通云盘那样“加个文件后缀”就了事。

重审条件

如果某种游戏内容（比如游戏内的纯静态成就图标）并不需要分层、帧动画或网格切片，我们不会强行为它建立复杂的 Asset 实体，而是把它作为已有 Asset 的附件或轻量资源处理，避免过度设计。

取舍五：修改已有资产必须人工确认，新建资产可以直接落库

在人机协同（Human-in-the-Loop）的设计上，很容易走向两个极端：

• 极端一（过度自动化）：AI 生成完直接自动覆盖当前资产。
• 极端二（过度教条）：不管干什么都弹窗问用户“你确定要保存吗”。

在实际开发中，这两种极端都会把人逼疯。

AI 生图或生成动画往往需要 20~60 秒的异步等待。如果用户在等待期间正在编辑器里微调一个角色的披风像素，任务完成后后台直接静默覆盖，用户刚才花十分钟的手工修改就全泡汤了。

但反过来，如果用户点的是“新建一个骷髅兵”，这本来就是一个全新的独立任务，没有任何历史劳动成果需要保护，生成完了还要跳出来让用户确认一次“是否保存”，纯属制造无意义的点击摩擦。

我们的选择

我们按操作的破坏性风险来划分权限：

• 针对已有 Asset 的生成式编辑（如新增动作、重绘局部）：生成结果进入 awaiting_application 状态，编辑器会以对比/浮层形式展示候选内容，必须由用户手动点击 Apply 或 Discard；
• 针对全新 Asset 的首次创建：后端任务完成后直接创建并落库，用户刷新即见，不增加多余确认步骤。

付出的代价

系统必须在数据库和对象存储中妥善管理“待确认的候选内容”，要处理 Apply 时的并发版本校验，以及 Discard 后的垃圾资源清理。

重审条件

只有当某些操作具备“100% 毫秒级无损撤销（Undo）”能力，或者用户在配置中明确开启了针对特定批量任务的自动合并授权时，我们才会进一步精简审核流程。

取舍六：先立标准 ZIP 交付契约，不急于死绑特定引擎插件

在聊到交付时，很多人第一反应是：“赶紧做个 Unity 插件，或者搞个 Godot 一键导入，点一下直接在游戏里跑起来，Demo 录出来多酷炫！”

但冷静下来会发现：一旦在早期把系统和特定引擎绑死，Unity 的 Prefab 结构、Godot 的 .tscn 节点树、Unreal 的资产格式就会迅速倒灌污染核心的数据模型。今天 Unity 改个 API，明天 Godot 换个格式，团队的精力会被无休止的引擎兼容消耗殆尽。

我们的选择

我们选择先在系统边界处建立引擎无关、版本不可变、自包含的 ZIP 交付契约。

每次导出，都是对某个确定的不可变历史版本（Record）生成一个快照压缩包，内部包含：

• 规范化的 manifest.json 与 asset.json（明确标注资产类型、网格尺寸、动画帧率与切片信息）；
• 规整后的图片、图层或 Sprite Sheet 目录；
• 用于防篡改和校验完整性的 SHA-256 校验码。

无论用户是直接解压使用，还是通过我们后续提供的 CLI、SDK，甚至是社区自己写的 Godot/Unity 导入脚本，面对的都是同一份稳定、透明、自描述的数据格式。

付出的代价

在当前阶段，用户把资产包下载回去后，仍然需要手动拖入引擎并做基础的资源绑定，少了一点“一键直达”的魔术感。

重审条件

当跨类型的标准资产包契约已经极其稳定，且“解压后手动配置动画”确实成为了核心用户群交付效率的最大瓶颈时，我们才会着手为最主流的开源引擎（如 Godot）开发官方导入插件。插件只是消费契约的终端，绝不能反客为主。

产品决策矩阵：我们选择什么，又放弃了什么

结语：记录 Trade-off 不是为了证明自己永远正确

写产品设计或技术架构文章时，很容易陷入一种“事后诸葛亮”的自负：把每一个决定都包装成深谋远虑的必然选择，把没做的功能都粉饰成“战略放弃”。

真实的产品演进从来不是这样的。

我们选择 Project-first，确实有可能会高估用户的耐心；我们选择死磕像素结构化 Asset，确实在早期背负了极其沉重的研发负担；我们克制着不做一键引擎插件，也确实让初期的交互流程少了些视觉冲击力。这些都是真实存在的风险和代价。

记录这篇 Trade-off，不是为了向外界宣布我们找到了唯一正确的真理，而是为了给团队立下一面镜子：

我们清楚地知道自己在为谁解决什么问题，清楚地知道为了这个目标我们放弃了什么捷径，更清楚地知道在哪些条件发生变化时，我们应该毫不犹豫地推翻过去的假设。

做真正能放进游戏里的资产，而不是制造又一个供人把玩的生图玩具——这就是 Holonic Asset 当前所有取舍的出发点。