OiiOii以AI动画赛道黑马姿态杀出重围，10万内测申请背后的秘密何在？本文将深度拆解这款产品如何用7个Agent精准还原动画制作全流程，从商业定位到多Agent架构设计，揭示小团队在AIGC红海中实现差异化的方法论。

我第一次看到OiiOii这个产品的时候，第一反应是：凭什么？

市面上做AI视频的工具一抓一大把。即梦、可灵、可画，哪个背后没有大厂撑着？一个十来人的小团队，做的还是动画这个细分赛道，怎么就能让10万人追着要邀请码？

带着这个问题，我决定把它拆开看看。

我本职做工业AI产品，日常打交道的是工厂数据和MES系统。AIGC影视制作对我来说基本算一个全新领域。分镜、运镜、关键帧这些词我能认识，但要我说清楚一部动画短片从创意到成片经历了什么环节，说不出来。

但这恰好是我想写这篇文章的原因。

AI PM这个岗位有一个躲不掉的挑战：你永远在面对陌生领域。上个季度你在研究工业质检，这个季度可能就得搞懂AIGC内容生产。跳槽到新行业、接手陌生产品线、面试官让你现场拆一个你没用过的产品，这些场景隔三差五就来一次。

大多数人面对陌生产品的做法是：试用一下，点一点看一看，截几张图。再搜几篇测评文章，看看别人怎么评价。最后列一个功能清单，写上优缺点。

能交差，但仅限于交差。

你知道OiiOii有7个Agent协作，但不知道为什么是7个。你知道它用了Sora 2和Kling 2.1，但不知道什么场景调什么模型。你知道它有角色一致性方案，但不知道一致性的核心是上下文工程，跟模型能力关系没那么大。

功能清单只回答”是什么”，不回答”为什么”。

但面试官想听的、老板想看的、真正能帮你做产品决策的，全是”为什么”。

我用了一个下午拆透了OiiOii。从商业定位到多Agent架构，从全局上下文协议到单个Agent的提示词设计，从模型调度逻辑到底层数据资产。拆完之后，我对AIGC动画的理解比看十篇测评加起来都深。

这篇文章是完整的拆解记录，但我想传递的不只是OiiOii这个产品本身。更重要的是背后的方法：一套结构化的逆向工程框架，能让你在一个下午内对一个完全陌生的AI产品建立足够深的认知。

文章分三部分。先讲拆解框架，然后用OiiOii从头到尾走一遍，最后是我作为PM对这个产品的独立判断。

拆解一个产品的思路

在正式拆OiiOii之前，我想先讲讲我拆产品的方法。

很多人拆产品喜欢从功能入手。打开App，一个页面一个页面截图，把每个按钮的作用记下来，最后整理成一份功能清单。这种拆法不是不行，但它有一个致命的问题：你看到的全是结果，看不到原因。

一个按钮为什么放在这个位置、一个功能为什么做成这个交互、一个技术方案为什么选A不选B，功能清单里没有这些答案。

我拆产品的思路是反过来的：从决策出发，逐层还原。

我把一个AI产品拆成五层。从上往下分别是：商业层、用户层、技术层、模型层、基础层。每一层回答的问题不一样，需要的信息源也不一样。后面的拆解中，我会把重笔墨放在定位、架构和判断上，模型层和基础层点到为止。

商业层：这是一门什么生意？

看官网首页和创始人访谈就够了。一句话定位是什么、商业模式是什么、怎么收费、怎么获取第一批种子用户。这一层回答的核心问题是：这个产品为什么能存在？

用户层：用户到底在完成什么任务？

光看功能列表不行，你得自己走一遍完整流程。从输入到输出，每一步的体验是什么、哪里顺畅哪里卡壳、它替代了用户之前的什么工作流。这一层回答的核心问题是：用户付钱买的到底是什么？

技术层：它背后的架构是什么？

到这里开始需要一些技术判断力了。它是单Agent还是Multi-Agent？有没有接RAG？信息在Agent之间怎么流转？每个Agent具体在干什么？它的输入输出是什么、用了哪些工具、处理逻辑是什么？这一层回答的核心问题是：人类团队的分工是怎么映射成Agent的？能力边界在哪，瓶颈在哪？

模型层：它调了哪些模型、为什么这么选？

列出它用了哪些图片模型、视频模型、音频模型，更重要的是搞清楚路由逻辑。什么场景调什么模型，是写死的规则还是动态调度的？这一层回答的核心问题是：在这条流程里，哪些环节必须依赖强模型，哪些只是流程设计得聪明？

基础层：它沉淀了什么数据和知识？

风格库、视频知识库、影视专业知识、模型表现评分知识，这些底层资产才是长期竞争力的来源。这一层回答的核心问题是：模型和流程的优势，会不会随着数据积累越用越强？

这五层有一个拆解顺序的讲究。

从上往下拆，是理解产品。你先搞懂这门生意的逻辑，再看用户体验，再看技术实现。这样你每深入一层都有上一层的背景支撑，不会在技术细节里迷路。

从下往上拆，是复刻产品。如果你的目标是做一个类似的东西，那你得从基础层开始，搞清楚需要什么数据、什么模型、什么架构，一层一层往上搭。

对于AI PM来说，我建议先从上往下走一遍建立全局认知，再从下往上验证关键技术假设。

这个框架不是专门为OiiOii设计的，它适用于任何AI产品。但我会用OiiOii完整走一遍，让你看到每一层具体怎么拆、拆出什么。

OiiOii是什么

在正式拆之前，先花三分钟搞清楚OiiOii到底在做什么。

一句话总结：OiiOii把一整套动画制作团队，抽象成前台一个输入框加后台一个多智能体管线。

传统的动画制作流程是这样的：你需要一个编剧写剧本，一个角色设计师画人设，一个分镜师把剧本拆成镜头，一个动画师让画面动起来，一个剪辑师拼接成片，一个配乐师加音乐音效。一部30秒的动画短片，专业团队可能要干一到两周。

OiiOii做的事情就是把这个团队数字化。你只需要输入一段文字描述你想要的故事，后台的7个AI Agent分别扮演艺术总监、编剧、角色设计师、场景设计师、分镜师、产品设计师、音乐总监，按照真实动画制作的流程依次协作，最终输出一部完整的动画短片。

面向的用户主要是PUGC和PGC创作者。自媒体博主、动画爱好者、音乐人、教育工作者、IP运营者，这些人有内容创作需求但养不起一个动画团队的，就是它的目标用户。

核心场景覆盖剧情动画短片、音乐MV制作、知识科普动画、IP二创等等。其中剧情故事短片是最重的场景，因为它需要完整走通编剧→角色设计→分镜→成片的全链路，对多Agent协作的要求最高。

产品现状：成立不到半年，团队十来个人，还在内测阶段。

我的体验感受

光看介绍没用，得自己跑一遍。

我设计了一个测试case叫”茶馆奇遇”。三个分镜，30秒左右的古风武侠动画短片。选这个case是因为它同时考验几个关键能力：多角色管理（青衣少侠、小二、红衣神秘女子）、室内外场景切换、情绪对比（茶馆的静谧和窗外集市的喧闹）、以及音画配合。

选了国风水墨风格，用对话模式全程参与。整个流程大概是这样的：输入故事描述→艺术总监确认基本信息→选风格和情绪关键词→编剧生成剧本和分镜描述→出报价→角色设计师生成角色图和概念图→分镜师生成分镜视频→配乐→合成最终视频。

说说直观感受。

超出预期的地方：运镜控制。这是我没想到的。每个分镜的镜头语言处理得相当有电影感，大远景到中近景的切换、POV主观视角的运用，能看出来背后在运镜知识库上下了功夫。角色一致性在国风水墨风格下也表现不错，三个分镜里青衣少侠的形象没有崩。

明显不足的地方：分镜衔接。三个分镜单独看都还行，但拼在一起的时候，镜头之间的过渡不够流畅，有一种”三段独立视频硬拼”的感觉。音画同步也有问题，配乐的情绪拐点跟画面的场景切换没对上。另外分镜师Agent有一个很明显的bug：我确认不再修改之后，它连续重复了好几次”好的我明白了，既然您不再需要修改，我将为您执行此操作”，说明工具调用和状态更新之间有逻辑断档。

整体来说，OiiOii目前的能力处在一个很有意思的阶段：单点能力（运镜、角色一致性、风格还原）已经够惊艳，但端到端的串联能力还没跟上。它像一个乐队，每个乐手都不差，但合奏的时候节拍还没完全对上。

看完表面了，接下来拆里面。

产品定位拆解：它凭什么在一堆AIGC产品里杀出来

市面上能生成视频、图片的AI工具多到数不清。即梦、可灵、可画，每个背后都站着大厂，论模型能力、论资源投入，一个十来人的初创团队怎么看都没优势。

但OiiOii偏偏火了。近10万人排队申请内测，靠的不是模型更强，而是产品思路完全不一样。

我拆完之后总结出三个核心差异点。

垂直到只干一件事

即梦、可灵、可画走的路线是全模态、全场景。你想生成图片可以，生成视频可以，做海报可以，写文案也可以。什么都能做一点，但每个方向都不够深。

OiiOii反过来。它只做动画，所有的产品设计都围绕一个目标：交付一部完整的动画成片。

这个选择带来了一个很直接的体验差异。你打开即梦，看到的是一个通用的创作工作台，你得自己想清楚要用哪个功能、按什么顺序操作。你打开OiiOii，所有的交互都围绕角色、分镜、剧本、短片展开，界面上全是影视术语。

对专业创作者来说，这太友好了。你不需要去翻译”我想让镜头从远景推到特写”在通用工具里对应哪个参数，你直接跟分镜师Agent说”大远景转推镜头”，它就懂。

从产品策略的角度看，这不是因为团队能力不够所以被迫聚焦。恰恰相反，在AIGC工具同质化越来越严重的今天，垂直加交付导向可能是小团队唯一能打出差异化的路径。

大厂做通用平台有规模优势，什么场景都覆盖一点，用广度吸引用户。小团队没这个资源，但可以在一个垂直场景里做到极致深度。OiiOii的选择是把模型能力藏到底层（反正大家都能调API），把动画行业的工种知识提到最前台。

模型是底座，工种知识才是门面。这个优先级判断是对的。

把Agent做成动画专业角色

这一点初看觉得只是命名不同，仔细想会发现它影响了整个产品的交互逻辑。

大多数AI产品的模块命名是技术视角的：文本生成、图片生成、视频生成、音频生成。用户面对的是一堆工具，自己决定怎么组合。

OiiOii的命名是行业视角的：艺术总监、编剧、角色设计师、场景设计师、分镜师、产品设计师、音乐总监。用户面对的不是工具，是一个团队。

这个设计选择带来了三个效果。

第一，降门槛。你不需要懂AI，只需要懂基本的动画制作常识就能上手。剧情不满意？跟编剧说。角色形象不对？跟角色设计师说。镜头太平？跟分镜师说要加特写。每个人天然知道该找谁解决什么问题。

第二，建信任。专业创作者最怕的是”黑箱感”。一个通用工具出了问题，你不知道是哪个环节出了差错。但当你知道是分镜师的镜头逻辑不对、是编剧的节奏没处理好，你就能精准定位问题，而不是笼统地觉得”AI不行”。这种可归因性对专业用户来说非常重要。

第三，给未来留空间。每个Agent是一个独立的能力单元，可以单独升级。分镜师接入了更强的视频模型？对用户来说只是”我们的分镜师最近水平提升了”。这种升级对用户是无感的，不需要重新学习产品的使用方式。

托管模式和对话模式：同时服务两类用户

OiiOii有两种使用模式。

托管模式：你丢一句话或者一张图，全权交给系统跑完整个流程。适合想要即时满足感的用户，”我就想看看AI能把我的想法变成什么样”。

对话模式：每一步都可以插手。改分镜、换角色、调色调、重新生成某个镜头。适合对产出质量有要求的专业创作者。

这两个模式单独看都不稀奇，但OiiOii聪明的地方在于它们可以串联。

你可以先用托管模式快速出一个版本，看个大概。觉得方向对了，切到对话模式逐镜、逐角色精修。精修满意后，再回到托管模式做批量衍生，比如同一个IP出一系列短片。

这个设计解决了AIGC产品的一个经典矛盾：自动化程度越高，专业用户的控制感越低。

纯自动化的产品，小白爱用但专业用户嫌弃。纯手动控制的产品，专业用户觉得灵活但小白根本上不了手。双模式串联让两端用户都不拧巴。

而且从传播逻辑看，这个设计也是成立的。小白用托管模式出的成片虽然粗糙，但足够”哇塞”，会自发分享。这些分享带来流量和新用户。其中一部分有更高要求的用户会转向对话模式深度使用，成为付费用户。

托管模式拉新，对话模式留存。两个模式各司其职。

这里多说一点我自己的判断。

市面上做AI漫剧、AI动画的产品不少，很多走的是传统路线：给你一个分镜编辑器、一个脚本编辑器、一堆参数面板，界面复杂，学习成本高，但可控性确实强。从当前的生成效果看，这类产品的精细度可能还领先OiiOii一截。

但我更看好OiiOii的架构。

原因很简单：多Agent管线的产品，它的能力增长是跟着底层模型一起涨的。Sora迭代了一个大版本，分镜师Agent的输出质量直接上一个台阶，产品不需要做任何改动。但传统编辑器类产品的能力增长依赖的是功能堆砌，每提升一点可控性就要多加一层UI、多加一组参数。

一个是模型进步它就进步，一个是产品经理加班它才进步。长期看，谁的迭代速度更快，不言而喻。

当然，前提是OiiOii的Agent管线架构要设计得足够好，能承接住模型能力的跃升。这一点后面架构拆解那章会重点聊。

回头看这三个差异点，OiiOii的产品思路其实可以总结成一句话：

它的独特性不在模型，而在动画垂直加交付导向。模型是大家都能调API的公共资源，但如何把动画制作的工种知识映射成一条可自动化的Agent管线，如何用一个简单的界面承载背后所有的复杂性，让用户只感知到”有一个团队在给我干活”。这才是它真正在做的事。

架构拆解：它怎么把一个团队装进平台的

前面讲了OiiOii在产品定位上的差异化，但定位只是方向，真正决定这个产品能不能跑通的是底层架构。

一个十来人的团队，要让7个AI Agent像一个真实的动画制作团队一样协作，这件事的技术难度远比表面看起来大。

难在哪？不是单个Agent不够聪明。现在的大模型写剧本、生成图片、生成视频，单点能力都不差。真正难的是协作。编剧写的剧本里提到了”青衣少侠背负斗笠”，角色设计师生成的形象里有没有斗笠？分镜师拿到的角色参考图是不是角色设计师最终确认的那张？音乐总监配的BGM情绪跟编剧设定的情感基调对不对得上？

任何一个环节的信息丢失或错位，最终成片就会出问题。这跟真实团队协作的挑战一模一样：不是个人能力不行，是沟通出了问题。

OiiOii的解法有两个核心设计：一个管信息怎么流转，一个管任务怎么执行。

全局上下文：角色一致性问题的本质是上下文工程

角色一致性是所有AI动画产品的头号难题。你在第一个分镜里生成了一个穿青衣的少侠，到第三个分镜他可能就变成红衣了，脸型也对不上。

很多人觉得这是模型能力的问题，模型不够强所以记不住角色长什么样。这个理解不完全对。

模型确实在进步，但即使是目前最强的视频模型，你给它同一段角色描述，生成两次的结果也不会一模一样。纯靠模型的记忆力来保证一致性，至少在当前阶段是不可靠的。

OiiOii的做法是换一个思路：不依赖模型记住，而是让系统替模型记住。

它设计了一套全局上下文协议，本质上就是整个项目的共享数据库。所有Agent读写同一套数据，任何一个Agent产出的资产都会立刻写回这个数据库，供下游Agent调用。

这套上下文里存了四类核心信息：

项目元数据。影片比例、目标时长、帧率这些技术参数。听起来简单，但它确保了所有Agent在同一套技术规格下工作，不会出现编剧按16:9写分镜、角色设计师按9:16出图的低级错误。

核心剧本字段。编剧产出的剧本摘要、用户选定的情感基调、风格标签、分镜总数。这些信息是艺术总监定调后写入的，后续所有Agent都以此为创作约束。

角色字典。这是一致性的关键。每个角色有唯一ID、名称、文字描述、确认后的主图链接、三视图链接。角色设计师生成主图后，立刻把图片URI写回角色字典。分镜师在生成视频时，直接读取这个URI作为角色参考。不是靠文字描述重新生成，而是靠同一张参考图约束生成结果。

分镜资产流水线。每个分镜有独立的编号、描述、场景图、时长、台词、音乐。台词跟角色ID关联，音乐跟分镜时长关联。这种强引用关系确保了每个资产之间不会脱节。

用一句话概括这套设计的核心思想：上下文工程的重点不是存在哪，而是存什么、怎么存、什么时候取。

存什么：不是存原始的用户输入，而是存每个环节加工后的结构化资产（比如角色图的URI，而不是角色的文字描述）。

怎么存：用强引用关系把资产串起来（分镜里的角色引用角色字典的ID，不是重新写一遍角色描述）。

什么时候取：每个Agent在开始工作前，先从上下文里拉取它需要的所有上游资产，而不是依赖上一个Agent在对话里传递的信息。

这套机制让7个Agent虽然各自独立运行，但始终在同一套信息基础上协作。就像一个真实的动画团队，虽然编剧和分镜师不坐在一起，但他们共享同一份项目文档。

深度拆解：艺术总监Agent

前面讲了全局架构，现在缩小到单个Agent的粒度，看看一个具体的Agent是怎么设计的。

我选艺术总监来拆，因为它是整个管线的主控Agent。其他6个Agent都是在它的调度下工作的，拆透它就等于理解了整个系统的调度逻辑。

先说它的定位：艺术总监是唯一直接面对用户的Agent。用户输入需求后，第一个接手的就是它。它负责理解需求、澄清需求、拆解需求，然后把任务分发给对应的子Agent。同时它还要定下整个项目的世界观、目标受众、时长、风格边界，这些约束会写入全局上下文，成为所有后续Agent的创作框架。

换句话说，艺术总监的输出质量决定了整条管线的上限。它理解错了需求，后面的Agent再强也白搭。

处理逻辑

我通过反复测试和观察它的行为模式，还原出了它的大致处理流程：

第一步，需求解析和初判。拿到用户输入后，它先判断这个需求里有没有包含分镜、剧情、角色设定这三个关键要素。如果有，激活故事短片创作主流程。如果缺了某个要素，它不会自己脑补，而是调用追问工具向用户确认。

这个设计很关键。很多Agent产品的问题是”太自作主张”，用户说了一句模糊的话，它直接按自己的理解往下跑，跑完用户发现完全不是想要的。OiiOii的艺术总监在信息不足时会主动拦截，先把需求搞清楚再动手。

第二步，IP识别。它会判断用户描述中有没有特定的IP角色（比如火影忍者、原神角色）。如果有，会推一个模型选择卡片给用户，让用户选择是否使用专门的IP还原模型。这个分支说明系统在IP版权和生成质量之间做了有意识的区分处理。

第三步，项目初始化。推送一系列UI卡片让用户确认基础设置：影片时长、画面比例、对白语言。这些信息确认后立刻写入全局上下文的项目元数据。

第四步，风格和情绪定调。调用RAG风格库做语义检索，匹配推荐的视觉风格（比如国风水墨、3D动画、2D漫画），推卡片让用户选择。然后分析文本的情感倾向，生成情绪关键词（悬念、优雅、日落、寻找、宁静等），同样推卡片让用户确认。

第五步，输出结构化Brief。把前面所有步骤收集到的信息汇总成一份创作Brief，包括剧本摘要、角色列表、技术规格、风格词、情绪词，写入全局上下文，然后把任务下发给编剧Agent。

设计亮点

拆完这个流程，有三个设计细节让我印象深刻。

每一步都有“人类拦截点”。不管是基础设置、风格选择还是情绪关键词，艺术总监都不会自己做决定，而是推UI卡片让用户确认。这些卡片就是人机协作的接口。系统有自己的判断，但最终决策权在用户手上。

风格匹配用RAG而不是硬编码。OiiOii目前有143种风格可选。如果用硬编码的匹配规则（比如”古风”关键词→国风水墨），每加一种风格就得写一条规则。用RAG做语义检索，系统能理解”武侠奇遇”和”国风水墨”之间的语义关联，扩展性强得多。

状态管理机制。艺术总监维护着一个状态变量，记录当前处于哪个阶段（初始化/分析中/已确认等）。当用户提出修改意见时，它能把状态回置到上一个稳定节点，而不是在错误的基础上继续往前走。这就是Planner-Executor的断点续传能力在具体Agent上的体现。

可用工具

从行为观察中，我推导出艺术总监大概配备了这些工具：

• RAG风格库：进行风格语义检索
• 上下文管理工具：读写全局上下文字段
• 状态管理工具：记录和回置任务阶段
• 表单工具（多个）：推送基础设置、模型选择、风格选择、情绪关键词等UI卡片
• 追问工具：当用户信息不足时主动追问
• Agent调度工具：向下游Agent下发任务

这些工具的组合方式说明了一件事：艺术总监本身不生成任何内容资产（不写剧本、不画图、不做视频），它的全部工作就是理解需求、管理状态、调度团队。这跟真实动画团队里艺术总监的角色完全一致。

其他Agent一览

剩下6个Agent我不逐个展开了，列一张职责表让你快速了解整个团队的分工：

这7个Agent的协作顺序基本是：艺术总监定调→编剧写本→角色设计师出人设→场景设计师出背景→分镜师出视频→音乐总监配乐→最终合成。每个Agent完成自己的工作后，都会把产出的资产写回全局上下文，供下游Agent读取。

整条管线下来，用户感知到的是”一个团队在帮我做动画”，但底层跑的是一套严格的状态机：每个节点有明确的输入、处理、输出，节点之间通过全局上下文传递信息，通过Planner-Executor控制执行顺序。

我的判断：如果我是OiiOii的PM

拆解完一个产品之后，我习惯多做一步：站在它的PM视角想想，如果这个产品是我在做，我会关注什么问题。这不一定对，但这个思考过程本身能帮你把拆解中看到的信息串起来。

这一章我跳出拆解者的视角，聊三个我觉得最值得思考的问题。

定价逻辑：为什么月度订阅加积分制是当前最优解

OiiOii目前的定价方案是月度订阅制，分四个档位。每个档位包含一定数量的”盒饭”（积分），从BASE的1000盒饭/月到APEX的18000盒饭/月，价格从16美元到169美元不等。冷启动阶段对新用户赠送一定的免费积分。

这个定价设计看起来简单，背后其实在解决AIGC产品定价的一个核心矛盾：边际成本不为零。

传统SaaS产品，比如Notion、Figma，用户多点一个按钮、多创建一个文档，服务器成本几乎可以忽略不计。所以它们可以放心做纯订阅制，用户随便用，反正边际成本趋近于零。

但AIGC产品不一样。用户每生成一次图片、每生成一次视频，后台都在调用GPU算力、调用模型API。OiiOii一个完整的动画短片走下来，要调图片模型生成角色图和场景图，调视频模型生成分镜视频，调音频模型生成配乐和音效，每一步都是实打实的成本。

如果做纯订阅不限量，用户使劲用，平台直接亏死。如果做纯按量付费，用户每次点生成之前都在心里算账”这一次要花多少钱”，创作的流畅感就没了。

OiiOii的积分制本质上是一个折中：订阅给你一个月度额度，框住成本上限；积分制让你有感知地消费，但不至于每次都心疼。

冷启动阶段赠送积分也是对的。这类产品的核心转化链路是：用户先看到成片效果被震撼到，产生”我也想做一个”的冲动，然后才愿意掏钱。如果一上来就要付费才能体验，大部分人在门口就走了。先让你免费做一部出来，看到效果了，后面的付费转化就自然了。

架构兼容性：紧耦合的当下优势和未来风险

前面在架构拆解里讲了OiiOii的全局上下文协议，所有Agent通过一套共享数据库传递信息，角色字典里有强引用关系。这套设计在当前阶段是对的，因为现在的模型能力还撑不起”一个模型搞定所有事”，必须靠精密的流程设计和Agent之间的强协作来弥补单一模型的不足。

但这里有一个隐忧。

Manus的创始人说过一句话：要为6个月后的模型设计产品。

我们假设6个月后发生了这些事情：视频模型原生支持角色一致性，你不需要传入角色参考图它就能在多个镜头间保持同一个角色形象。视频模型支持长镜头直接生成，一次出30秒完整视频，不需要分镜拼接。音频模型能直接理解画面内容自动配乐，不需要单独的音乐总监Agent来做匹配。

如果这些真的发生了，OiiOii现在精心设计的角色设计师Agent、分镜师Agent、音乐总监Agent，它们的大半工作就变成多余的了。更麻烦的是，因为全局上下文协议让Agent之间有很强的依赖关系（分镜师依赖角色设计师的URI、音乐总监依赖分镜师的时长），你想”裁掉”某个Agent还不容易，牵一发动全身。

这就是紧耦合架构的典型风险：当前越精密，未来越难改。

我不想给一个标准答案，因为这个问题没有标准答案。但如果是我在设计这个系统，我会思考几个方向：

每个Agent是不是应该有一个”能力评估层”？当底层模型的某项能力超过某个阈值时，对应的Agent自动简化流程甚至跳过。比如视频模型的角色一致性评分达到95分以上，角色设计师的三视图生成步骤就变成可选而非必选。

Agent之间的引用关系能不能做成”弱引用”？分镜师优先读取角色设计师的URI，但如果角色设计师这个环节被跳过了，分镜师也能退化到纯文字描述的模式继续工作。

全局上下文的Schema能不能做版本管理？当Agent管线发生裁剪时，旧版本的项目数据仍然能被正确解析。

这些问题没有标准答案，但值得每一个在做Multi-Agent产品的PM认真想一想。因为模型能力的跃升不是”会不会发生”的问题，是”什么时候发生”的问题。

审美即产品力：benchmark决定天花板

最后一个判断，也是我觉得最容易被忽视的一个。

在我测试OiiOii的过程中，运镜效果是最让我惊喜的部分。大远景推近景、POV主观视角切换、固定镜头转跟拍，这些电影语言的运用明显超出了”AI随机生成”的水平。

但分镜衔接和音画同步就差了一截。三个分镜单独看都还行，拼在一起就有”硬拼”感。配乐的情绪高点跟画面的转场节奏也没对上。

这两者的差距说明了一个问题：OiiOii在运镜维度上有清晰的质量标准（它的风格库和视频知识库里沉淀了大量运镜知识），但在分镜衔接和音画同步维度上，标准还不够高或者还没建立起来。

这让我想到一个更底层的判断：

对于AIGC产品，PM最重要的能力不是写PRD，而是定义什么叫好。

传统软件产品，功能好不好用、流程顺不顺畅，这些标准相对客观，PM凭经验就能判断。但AIGC产品的输出是内容，是图片、是视频、是音乐。什么样的运镜有电影感？什么样的分镜衔接叫流畅？什么样的音画配合叫同步？这些标准带有很强的主观性和审美判断。

你的benchmark设计水平，直接决定了产品的审美天花板。

如果你的评测维度只有”画面清晰度”和”生成速度”，团队只会朝着更清晰、更快的方向优化，产品永远不会有电影感。但如果你的benchmark包含”分镜间的情绪递进是否连贯””配乐的情绪拐点是否与画面转场同步””运镜节奏是否匹配叙事张力”这些维度，产品才有可能朝着真正的审美标准进化。

具体怎么落地？我想到三个可落地点。

提示词词库。把专业的影视术语（希区柯克变焦、环绕镜头、升格慢动作）系统性地整理成模型可以理解的提示词模板。这不只是给用户用的，更是给Agent用的。分镜师Agent在生成视频提示词时，能从词库里调取专业运镜描述，输出质量会比它自己临时编写高很多。

专业评审知识库。把影视行业的审美标准结构化。什么叫好的分镜节奏、什么叫合理的景别切换频率、对话场景的标准机位是什么。这些知识沉淀到RAG知识库里，Agent在生成和评估时都能参考。

量化评测体系。建立可量化的benchmark。运镜多样性评分、角色一致性评分、音画同步偏移量、分镜间色调跳变幅度。有了量化指标，团队才能有的放矢地优化，而不是靠PM肉眼一个个看。

说到底，AIGC产品的竞争最终会从模型能力的竞争，走向审美标准的竞争。谁能定义更高的”好”的标准，谁的产品天花板就更高。

总结

前面用OiiOii走了一遍完整的拆解流程，现在回到方法论本身。

如果你下周就要面对一个完全陌生的AI产品，不管它是做AI动画的、AI客服的、AI写作的，你可以按这个路径来：

第一步，花10分钟搞定商业层。打开产品官网，只看首页和首屏Slogan。搜一两篇创始人访谈或融资报道。回答：这个产品一句话定位是什么？它靠什么赚钱？它面向谁？

第二步，花30分钟体验用户层。自己注册账号，带着一个真实任务完整跑一遍核心流程。记录两类东西：哪里让你觉得”哇塞”（能力亮点），哪里让你觉得”不对劲”（能力边界）。

第三步，花两到三个小时拆技术层。这是最花时间的部分，也是最有价值的部分。信息来源：反复测试产品行为推导处理逻辑、创始人技术博客和访谈、相关论文、开源项目。核心不是列出它用了什么技术，而是回答为什么用这个技术。每一个”为什么”背后都是一个产品决策。

第四步，花30分钟扫模型层和基础层。看它调了哪些模型、路由逻辑是什么，重点关注”哪些环节必须依赖强模型，哪些只是流程设计得巧”。基础层看它沉淀了什么数据和知识资产，判断竞争优势是短期的还是长期的。

第五步，花30分钟写你自己的判断。逼自己回答三个问题：如果我是这个产品的PM，我接下来最该做什么？这个产品最大的风险是什么？它的做法对我自己的工作有什么启发？

照这个路径走一遍，大概一个下午。你得到的不是一份功能清单，而是对一个产品从商业逻辑到技术架构的完整认知。

有一点需要提醒：这个框架不是让你机械地填表。每个产品的侧重点不一样，有的产品商业模式是最值得拆的，有的产品技术架构才是精华。拆之前先快速扫一遍，判断哪一层最值得花时间，然后把精力集中在那里。

结尾

回到开头的问题。

我从对AIGC动画一无所知开始，用一个下午拆透了OiiOii的产品架构。拆完之后我知道了：为什么它选择只做动画而不是做通用AIGC工具，为什么它把Agent设计成动画行业的专业角色，为什么角色一致性的核心是上下文工程而不是模型能力，为什么它的架构在当前是对的但6个月后可能需要重新审视。

这些认知不是看十篇测评文章能得到的。它们来自于逐层拆解、逐步推导、不停追问”为什么”。

逆向工程的本质不是拆产品，是拆决策。你还原的不是功能列表，而是另一个产品经理的思考过程。当你能还原别人的决策逻辑，你自己做决策的时候也会更清醒。

拆解完你会发现自己对这个领域的理解，远比你预期的要深。