DEMO | 前剪映负责人创业融资近亿，替代Figma，给AI Coding们补补审美

作者｜黄小艺
微信 ｜H997Hbiu

一个把国民级创作工具从 0 做到 100 的人，正在尝试把“审美”拆解成一套 AI 可以执行的设计方法。

前剪映中国负责人 Kiki张琪智创办了一款叫 OJO 的 AI 产品原型设计工作台（https://ojo.art/）。用户只需要说出想做什么，一个由 Agent Team、Agent 和 Skills 三层构成的设计系统，就会在对话与画布中，完成调研、产品定义、界面设计，并输出交互原型。

此前，OJO完成了近亿元人民币的首轮融资，由顺为资本、联想创投联合投资。

2026 年 8 月 18 日，OJO 面向海外正式上线，截至目前，X上的首发帖已获得约 53 万次浏览，评论区很快将OJO和Figma放在一起比较，期待 AI 能把设计师从 Figma 工作流中“解救”出来。

所谓从 Figma 工作流中“解救”出来，并不只是换掉一款工具。随着代码生成变快，软件生产的瓶颈正在从“能不能做出来”，转向“做出来之后是否好用、好看，并形成辨识度”。

用户希望 AI 接手设计过程中那些依赖专业经验与判断的工作。

Claude Design、v0 Design Mode 等产品都在尝试填补这个缺口。它们从通用 Agent 或 Coding Agent 出发，向前补齐设计环节；而OJO 则把顺序倒了过来——先理解用户、定义问题，再组织产品结构、视觉语言与交互方式，页面和代码只是最后的执行结果。

这也延续了Kiki 在剪映时期熟悉的产品方法：把专业创作能力拆开、封装，再交给普通用户。剪映用模板封装视频的剪辑结果，OJO 则尝试封装设计师分析问题、做出判断和完成修改的方法。

最近，我们上手试用了 OJO，也和 Kiki 聊了聊，想弄清楚一件事：设计能否被 AI 组织成一条普通用户也能参与的工作流，审美又能否被工程化。

1

代码越来越普遍，但审美依然稀缺

AI Coding 给软件生产带来的第一轮改变，是扩大“实现”的供给。

过去，一个想法要经过需求、原型、设计和开发，才能变成可以运行的产品。Vibe Coding 压缩了这段过程，甚至当产品定位、用户需求和视觉方向仍然模糊时，更快的实现也能把模糊判断直接放大成一个可以运行的结果。

问题出现在后续的迭代修改中。

用户通常能一眼判断页面“丑”“不高级”，却很难说清问题究竟在哪里，像一个无力的甲方：知道自己不满意，但无法判断应该调整信息层级、交互路径、页面结构，还是字体、配色和视觉风格，更难写出精准的 Prompt。

OJO 认为，根源在于对Design 的定位上。

现有产品大多沿着 Coding 的工作流加入设计能力：先生成一个能够运行的应用，再通过画布、视觉编辑和设计系统改善结果。Design 在这条链路中承担的是补充和优化。

OJO 把顺序倒了过来。在 OJO 的定义里，Design 覆盖一款产品从构思到实现的完整过程。

它由两个紧密相连的部分组成。How it works 决定产品服务谁、解决什么问题、功能如何取舍、信息与交互怎样组织；How it looks 决定这些判断以什么方式呈现，包括字体、配色、版式、动效和视觉气质。

前者没有想清楚，后者很难准确；视觉方案发生变化，也可能反过来影响产品结构和交互方式。

OJO 的流程也因此从页面生成之前开始。它先帮助用户澄清需求、研究用户、判断产品方向，再进入结构、视觉和交互设计，最后将方案交给 Codex等Coding Agent 实现。产品进入开发以后，也可以回到 OJO 继续调整。

这个起点决定了 OJO 的产品形态，也解释了为什么一个剪映背景的团队，会把第一次创业放在 Design 上。

1

将剪映从 0 做到 100，先看到用户需求，再定义产品

过去几年，从字节离开创业的人很多。剪映系尤其受到关注。

剪映曾把一套复杂的专业创作流程，变成数亿普通用户能够使用的产品。它经历过工具冷启动、用户规模增长、全球化、商业化和 AI 转型，成为了观察中国 AI 应用创业者的重要样本。

因此，每当剪映背景的人开始创业，市场都会追问几个问题：他们在原来的成功中究竟承担了什么；从剪映带走了哪些可以复用的方法；离开大厂的流量、组织和资源后，这些经验还能否独立成立。

而Kiki 是这批创业者中，与剪映完整生命周期联系最紧密的一位。

2017 年研究生毕业后，Kiki 加入 Faceu，先后参与 Faceu 相机和轻颜相机，并将轻颜从 0 做到 1500 万 DAU。2019 年，她进入剪映，经历产品从早期工具走向全球化创作平台，职责也从工具产品扩展到全球工具业务。

2024 年剪映拆分国内外业务后，Kiki 开始以中国负责人的视角统筹产品。彼时，剪映已经接近用户规模的天花板，需要从存量中寻找增量，推动付费增长，也要把大模型能力真正接入已有的创作链路。

履历很字节，但Kiki判断问题的方式并不典型。

外界常用数据驱动、快速验证和解决当下问题来概括字节系产品人。Kiki 同样强调执行，但识别问题的起点，经常来自一个尚未进入数据看板的真实场景。

她会继续把这些具体场景向外推演，判断它们是否指向更大的用户与市场变化，再推导回产品的第一步。团队内部将这套路径概括为“先极小，再极大，再极小”。

在与 OJO 团队交流的过程中，他们提到了一个“长视频改短视频”的例子。在负责剪映期间，大家曾讨论过是否开发这项功能，当时竞品已经将这个功能做成了一个单独的产品。

但Kiki认为，如果只是调整画幅比例、截取若干片段，“长改短”不足以支撑一个独立的产品，功能本身还需要回答：用户从哪里获得这么多长视频，为什么需要把它们重新组织成短内容，以及这项需求为什么在北美更加突出。

直到一次在美国打车时，Kiki和司机聊到了当地人的通勤习惯。漫长的公路通勤形成了庞大的播客消费，创作者随后开始把播客录制成视频，上传到 YouTube；TikTok 兴起后，同一批长内容又需要被切成短片，进入新的分发渠道。

找到这条用户链路后，团队才将功能推进到开发阶段。

类似的方法后来也被 Kiki 带进了 OJO：先找到变化发生在哪里，再判断应该把哪一部分专业能力做成产品。

2025 年年底，一些剪映内部的产品经理和设计师开始直接使用 Gemini 制作可以运行的原型，再拿来和 Kiki 讨论。据她回忆，其中部分原型的视觉完成度，已经超过产品经理此前自己制作的 Figma 稿。

Kiki 最直接的反应是：“大家的岗位边界要发生变化了，这对应的是一个产业级的机会。”

当实现门槛下降，判断会成为新的缺口。小团队、独立开发者，以及来自市场、运营、硬件等不同领域的人，都可以直接参与产品生产；但产品服务谁、解决什么问题、功能如何取舍，以及视觉与交互是否适合具体场景，仍然需要专业经验。

完整的剪映履历，让 Kiki 熟悉一款创作工具如何从冷启动走向规模化；从小场景推演大变化的产品风格，又让她选择了一个当时尚未形成共识的方向。OJO 也成为了两部分的交点。

1

OJO 如何让 AI 组队做设计？

沿着这套思路，OJO 先面向非专业设计师群体，把 AI 放进需求澄清、产品定义、方案生成、细节修改和开发交付，试图形成一条完整的设计链路。

先追问，再生成，把设计过程展开

用户进入 OJO 后，可以从一句模糊需求开始。

比如输入“我想做一个电影资料库”，系统会继续追问：产品服务什么人？用户为什么需要它？内容应该按导演、演员还是类型组织？它更接近一个专业数据库，还是一个带有社区感的电影空间？

这些讨论会被整理成一份 Product Brief。接下来，OJO 给出多个产品与视觉方向，让用户先确认产品应该往哪里走。方向确定后，系统继续处理信息结构、Design DNA、UI、交互和动效，最终生成可以编辑的产品原型。

这套流程建立在一个基本判断之上：复杂的设计项目很难由一句 Prompt 完整定义。它更接近视频制作：脚本、分镜、素材、剪辑和动效存在先后关系，前面的判断会影响后面的结果。

这也是 OJO 同时保留对话和画布的原因。

左侧对话区负责追问需求、推进任务和记录修改；右侧无限画布用于放置 Product Brief、参考资料、原型页面和不同版本的设计结果。

用户可以同时看到过程与结果，也可以将多个方案并排比较，再返回前面的环节重新调整。

Agent Team 定方向，Agent 推进任务，Skill 提供专业约束

一条完整的设计链路，会同时涉及用户研究、产品定位、信息结构、视觉、交互和动效。所有任务如果都留在同一段对话里，模型需要不断切换角色，也要同时处理不同层级的信息。

OJO 因此将系统拆成 Agent Team、Agent 和 Skill 三层。

• Agent Team 先确定任务属于哪个方向。目前，OJO 提供需求分析、产品原型、设计优化和游戏设计四类 Agent Team。不同任务会进入不同流程，也会调用不同的角色与专业能力。

• Agent 负责推进方向下的具体工作。每个 Agent 保留自己对项目的理解，也能调用模型、工具和外部资源，分别完成分析、决策、执行和检查。角色分开后，每个 Agent 可以维持更聚焦的上下文，减少不同任务之间的干扰。

• Skill 则为具体环节加入更细的专业规则，这也是将审美品味工程化的最直接体现。

比如用户看到一张页面，往往只能说“字体太丑了”。真正的问题可能来自字体选择、字号层级、行距、中英文搭配，也可能来自字体气质与产品定位之间的偏差。中文字体 Skill 会进一步诊断问题、解释判断，再执行修改。

不同场景也会调用不同的 Skill。中文内容产品、海外工具和 To B 软件需要不同的字体与版式；移动端、桌面端、平面设计、交互原型和 3D 动效，也分别对应不同的专业要求。

据团队介绍，目前 OJO 已经积累了 200 多个 Skill，从需求分析、产品定义，一直覆盖到字体、视觉、交互、动效和开发。例如，“鲁迅”用于检查需求里的空话和真实问题，“达芬奇”从结构和创造性上审视方案。名字承担了用户理解能力的入口，底层仍然是一组提供给 Agent 的知识、方法、工具和约束。

Kiki 把 Skill 称为“LUI 时代的模板”。

Agent Team 限定任务方向，Agent 理解项目并调动资源，Skill 规定具体环节需要遵循的方法。三层架构共同把通用模型约束进专业设计流程。

200 个 Skill 之后，系统还要学会怎么匹配

建立 Skill 库，解决的是专业能力的供给问题。面对一个具体项目，系统还要知道该组织哪支 Agent Team，在什么环节调用哪些 Skill。

OJO 因此需要积累“任务 × Agent Team × Skill”的匹配关系。

这种匹配关系，只能从真实项目里长出来。

现阶段，一部分熟练用户仍然会主动选择字体、动画和视觉风格等 Skill。OJO 希望先从这些 Good Case 中理解不同任务与 Skill 的组合方式，再逐步把选择权交给系统。

理想状态下，Agent Team 和 Skill 会逐渐退到后台。用户只需要说出目的，系统像一位设计总监，判断任务方向、安排合适的 Agent，再为每个环节匹配相应的 Skill。

在这些核心信息之外，我们也和 Kiki 聊到基础模型、Coding Agent、Skill 匹配和成本问题。以下是更多信息，供大家参考。

硅星人：基础模型的 Coding 和设计能力一直在提高，应用层会被覆盖吗？

Kiki：模型的上限一定会继续提高，用户能否到达这个上限是另一个问题。一段 Prompt 很难精确控制越来越强的模型，应用需要通过 Tools、Skills、上下文和各种 Loop，把通用能力约束到具体专业领域里。模型能力越强，应用可以组织和调度的工作也会越多，应用应该帮助用户到达上限。

硅星人：目前，OJO 和 Coding Agent 的边界在哪里？

Kiki：边界会随流程变化。我们有用户先用 Coding Agent 搭建产品，再到 OJO 优化视觉，随后返回 Coding Agent 完成部署。我们相信的是，设计判断会在整个生产过程中反复出现。

硅星人：OJO 面向普通用户，现在仍需要用户选择 Skill，学习成本怎么解决？

Kiki：产品能做的是不断降低学习的门槛，但实际上任何工具都需要学习。现在有一部分熟练用户会自己选择，我们希望通过这些用户和 Good Case，理解什么项目适合什么 Skill。未来用户只需要带着目的进来，系统应该像设计总监一样，为任务安排合适的人。Agent、Multi-Agent 和 Skill 都会退到产品背后。

硅星人：你们怎么判断Skill 与项目的匹配呢？

Kiki：用户打分是信号之一。此外，用户和 AI 之间的对话、正向和负向表达也可以成为信号。比如用户围绕一件事反复与 AI 沟通，这本身就在说明结果存在问题。我们会结合这些过程，去积累任务与 Skill 的匹配。

硅星人：模型调用和积分消耗怎么优化？

Kiki：我们会同时优化上下文控制、模型路由和产品流程。不同复杂度的任务可以使用不同档位的模型，简单任务调用更轻量模型，从而降低积分消耗和等待的时间。更准确的 Skill 也有机会减少无效发散，但具体能降低多少 Token，我们还在系统验证。

从剪映到 OJO，Kiki 做的仍然是同一件事：降低专业创作的门槛。

OJO回应的是一个正在发生的变化，当AI让代码越来越容易获得，人们的生产方式发生改变，应用层如何在模型智能的基础上，把专业知识、方法和判断变成用户可以随时调用的新生产力，而不是让需求卡在一句无法说清楚的Prompt 上。

点个“爱心”，再走 吧