用"六层拆解框架"逆向推导任意 AI 产品的完整架构，掌握从用户旅程到多 Agent 提示词设计的全链路能力，最终能够独立复刻一个 AIGC 产品。
产品拆解不是"看看别人做了什么"，而是一项核心生产力技能，直接解决三个场景的问题。
评估某个产品时，摆脱"还挺好用的"式判断，用有框架、有层次的方式把它拆透。
项目要快速出成果时，通过拆解竞品，快速复刻出最低可用产品，避免从零摸索。
想做一个产品但不知道架构怎么设计，逆向推导成熟产品，避免重复踩坑。
核心方法论——任何 AI 产品都可以用这六层来拆解和构建。
市场层和商业层不是产品本身，但产品具体怎么设计，一定是根据这两层推导出来的。深入理解这两层，才能把后面四层的设计讲透。
拆解的时候，具体产品案例不是主角，六层框架才是重点。这个框架可以带入到任意一个 AI 产品上，是一个万能框架。
以某 AIGC 短剧平台为例，用户层拆解的核心就是梳理操作流程，从中推导出 Agent 之间的协作关系。
| 功能模块 | 作用 |
|---|---|
| 项目创作 | 通过多 Agent 协作生成短剧视频 |
| 我的项目 | 管理所有个人项目 |
| 角色库 | 管理个人创作的所有角色 |
三个功能串成完整流程：创作角色 → 存入角色库 → 项目创作生成视频 → 存入我的项目。
用户使用该平台生成一个短剧视频的完整流程：
在正向流程基础上，每个关键节点都有 用户确认环节（Human-in-the-loop）：
| 场景 | 流程 |
|---|---|
| 标准清晰剧本 | 输入 → 判断是否符合短片需求 → 注入用户需求 → human 介入（时长/比例/语言）→ 需求分析 → 情绪词生成 → 风格搜索(RAG) → human 介入 → 输出 |
| 涉及 IP 角色剧本 | 输入 → 判断 → 识别IP角色 → 推荐模型（如 Sora 2）→ human 介入 → 需求分析 → 情绪词生成 → 风格搜索 → human 介入 → 输出 |
技术层是整个拆解的核心重点——它回答了"用户看到的每一步交互，背后对应一个 Agent 在做什么"。
单 Agent 的三大局限：
单 Agent 升级为多 Agent 的唯一原因——场景复杂到单个 Agent 解决不了了。就像你自己做不过来了，才需要再招一个人。
一个 Agent 不一定要"加入群聊"，可以作为工具被调用：
一个工具里面可以封装 Agent，也可以封装外部接口，也可以封装一个单独的大模型。Agent 的核心就是提示词——你写多细，它就按多细的方式执行；你写得粗，它就自由发挥。
| 对比维度 | 串行 | 并行 |
|---|---|---|
| 速度 | 慢（逐个生成） | 快（同时生成） |
| 成本 | 低（占用少量资源） | 高（占用多个 Agent 资源） |
| 适用场景 | 短视频 < 5 分钟，分镜少 | 长视频，分镜数量多（如 100 个） |
| 质量控制 | 可逐个确认 | 需批量确认 |
所有你喂给大模型的，都是它的上下文。上下文工程是多 Agent 能否协作成功的关键基础设施。
| 概念 | 含义 |
|---|---|
| 上下文 | 喂给大模型的所有信息（系统提示词、用户输入、历史对话、知识库、文件等） |
| 上下文工程 | 设计上下文何时用、何时不用、如何存取的工程方案 |
| 提示词工程 | 如何让提示词发挥更好效果的工程方案（是上下文工程的子集） |
一个 AIGC 产品要做得好，40% 的关键点都在上下文工程里。上下文工程为什么加"工程"两个字？因为不只是写一个提示词，而是要系统地设计什么时候用、什么时候不用——这叫工程。
该平台的多 Agent 共享一个全局上下文数据表，每个 Agent 都可以读取和更新。产品中反复出现的"更新字段信息"操作，本质就是在写这张表。
全局上下文中的 URI、版本号等都是变量——一个可以被任意替换的占位符。
类比：奶茶店计算日营收，单价 = 15 元。老板说改成 16 元时，有了变量只需改一处，所有引用自动更新。
| 版本 | 含义 |
|---|---|
| 1.0 | 初始版本（从 0 到 1） |
| 1.1 | 小改动（修改某角色/分镜） |
| 2.0 | 推翻重来 |
支持用户说"帮我回退到上一个版本"。就像游戏存档，到点了就存档一下。
一个 Agent = 一份系统提示词。以艺术总监为例，拆解真实的提示词结构。
| 步骤 | 动作 | 细节 |
|---|---|---|
| 1. 需求获取 | 解析用户输入 | 判断关键信息是否齐全；缺失则调用追问工具；齐全则激活主流程 |
| 2. IP 识别 | 识别 IP 角色 | 存在 IP → 推送 UI 卡片让用户选模型（如 Sora 2）；不存在 → 进入下一步 |
| 3. 项目初始化 | 填槽 + 更新全局上下文 | 将时长/比例/语言等存入数据表；调用表单工具推送确认项 |
| 4. 视觉与情绪构建 | RAG 风格库 + 情绪词 | 语义检索 → 用户确认 → 分析文本情感 → 用户确认 → 存入上下文 |
| 5. 输出 | 格式化结构化 Brief | 输出完整结构化需求文档，交给编剧 Agent |
| 工具 | 功能 | 触发条件 |
|---|---|---|
| RAG 风格库 | 语义检索匹配艺术风格 | 需要推荐视觉风格时 |
| 表单工具 | 推送 UI 卡片让用户选择/确认 | 需要用户确认时长/比例/语言/风格/情绪词时 |
| 字段更新工具 | 更新全局上下文数据表 | 每次收集到新信息或用户确认后 |
| 追问工具 | 向用户澄清需求 | 关键信息缺失时 |
执行每一步前，必须陈述当前操作（用户看到的"思考过程"）。
字段未更新成功前，禁止向用户承诺进度。
用户修改建议优先级高于 AI 预设。
用户不满意时，支持回退到某一步重新执行。
如果你直接让 AI "写一个艺术总监 Agent 的提示词"，生成的东西和你用逆向推导出来的绝对不一样。逆向推导的优势在于：你已经知道了真实的输入/输出和处理逻辑。
模型路由（Model Routing）= 什么场景用什么模型的逻辑规则。写在 Agent 提示词中。
未明确公开 · 负责需求理解、剧本生成等环节
1. 产品"思考过程"中泄露的工具名称（如 SEEDREAM 4.5）
2. 产品官方的宣传和访谈资料
3. 通用模型评测结果 + 产品经理自己的理解和审美
产品底层依赖的数据与知识——决定了产品能否随数据积累越用越强（数据飞轮）。
| 数据类型 | 内容 | 作用 |
|---|---|---|
| 风格库 | 162 种视觉风格，每种有完整文字描述（不只是"国风水墨"四个字） | 通过 RAG 语义检索匹配用户需求 |
| 视频知识库 | 参考视频（文字描述 + 视频链接存储召回） | 作为 Few-shot 示例提升生成质量 |
| 内置影视专业知识 | 镜头运镜、构图规则、分镜设计规范 | 写入 Agent 提示词，确保专业度 |
| 模型表现得分阈值 | 各模型在不同场景下的质量评分 | 用于模型路由决策 |
| 剧本数据 | 优质剧本示例 | 提升生成质量 |
| 用户反馈 | 用户使用过程中的反馈数据 | 迭代优化产品（数据飞轮） |
该平台的护城河不在模型上（模型大家都能调），而在于：
① 提示词工程；② 工作流设计；③ 底层知识数据（风格库、影视专业知识等）。
这些是别人一下子抄不来的。
把前面所有层整合成一张图——这就是"值钱的"产品架构图。
一个真实落地的项目案例——看产品经理的提示词长什么样。
电商场景视频生成 + 社媒推广投流
Canvas（画板 Agent 交互）+ Editor（类剪映）
1 主 Agent + 3 子 Agent + 工具
上线十几天下架——效果不错但营销不足
AI 时代产品经理的底层技能正在转换——从"画原型"到"设计 Agent"。
| 对比维度 | 传统产品拆解 | AI 产品拆解 |
|---|---|---|
| 测试重点 | 功能流程是否跑通 | 功能流程 + AI 生成质量评测 |
| 评测方式 | 功能测试 | 需要构建评测集（多场景、多维度打分） |
| 关注核心 | 交互设计、信息架构 | Agent 架构、提示词设计、上下文工程、模型选型 |
| 护城河判断 | 用户量、品牌、网络效应 | 提示词工程 + 工作流设计 + 知识数据 |
AI 产品的"黑话库"——用准确术语表达比用通俗说法更显专业。
| 术语 | 英文 | 释义 |
|---|---|---|
| 多 Agent 架构 | Multi-Agent Architecture | 多个专业化 Agent 协作完成复杂任务的系统设计 |
| 主-子 Agent | Master-Sub Agent | 一个主 Agent 统筹调度，多个子 Agent 专项执行 |
| 上下文工程 | Context Engineering | 设计所有喂给大模型信息的存取、使用规则的工程方案 |
| 提示词工程 | Prompt Engineering | 设计和优化提示词以获得更好输出的工程方案 |
| 模型路由 | Model Routing | 根据不同场景自动选择最合适模型的逻辑规则 |
| 全局上下文 | Global Context | 所有 Agent 共享的数据表，存储项目关键信息 |
| 填槽 | Slot Filling | 将收集到的关键信息填入对应变量位置 |
| 人在环路 | Human-in-the-loop | 在 AI 处理流程中加入人工确认/修改节点 |
| Function Call | 函数调用 | Agent 调用外部工具/其他 Agent 的方式 |
| MCP | Model Context Protocol | 另一种 Agent 调用外部工具的协议 |
| RAG | Retrieval-Augmented Generation | 检索增强生成，从知识库检索相关信息辅助生成 |
| 结构化 Brief | Structured Brief | 格式化的需求文档，作为 Agent 之间传递的标准输入 |
| 三视图 | Three-view Drawing | 角色的正面/侧面/背面图，用于保持角色一致性 |
| POC 验证 | Proof of Concept | 在 Dify 等平台搭建原型，验证 Agent 流程可行性 |
| ReAct | Reasoning + Acting | Agent 的一种架构模式：推理后行动 |
| 数据飞轮 | Data Flywheel | 产品随数据积累持续优化的正循环 |
把六层框架转化为可动手的实践步骤、可复用的应用思路。
当需要从零设计一个 Agent 产品时——可以用这个框架来推演：
什么场景、什么用户、解决什么痛点？
关键流程节点、每个节点怎么实现（单 Agent / 多 Agent）？
输入/输出是什么？提示词怎么设计？
调用什么模型支撑需求？
依赖什么数据？