# Nomi 长片场景压力测试

日期：2026-05-24
作者：产品策略组
状态：思考文档 (非 PRD)

> 用户提问：以"做一部 1 小时以上 AI-native 影片"的视角，从头到尾走一遍 Nomi 的用户路径。沿途发现的真实问题和需求是什么？我们之前的 PRD 是否覆盖了？

---

## 0. 为什么要做这个练习

之前所有 PRD 隐含的目标用户场景：

- "AI 漫剧短片：30 镜头、3 角色、5 场景、5 分钟成片"
- "产品 Demo：60 秒、单镜头、单角色"

**这些场景太友善了**。它们让我误以为"30 个分类节点"是天花板，让我设计了一个为短片优化的产品架构。

但 Nomi 的护城河是"端到端、本地、长项目记忆" — 这些属性的价值要在**长片**场景才会真正显现。

如果 Nomi 只能做短片，那它就只是另一个 Krea。
如果 Nomi 能做 1 小时长片，那它就**不可能**有竞品 — 没人能做。

所以本文档的目的：以"做 1 小时 AI 长片"的视角走一遍工作流，**诚实列出会撞到的墙**，再回头检视之前的 PRD 哪些是对的、哪些是错的、哪些缺位。

---

## 1. 数量级换算

| 维度 | 30 镜头短片 | 1 小时长片 | 倍数 |
|---|---|---|---|
| 镜头数 | 30 | 500-1200 | **30x** |
| 主要角色 | 3 | 8-15 | 4x |
| 次要角色 | 0 | 20-50 | ∞ |
| 场景数 | 5 | 20-60 | 8x |
| 分镜稿 / 缩略 | 30 | 500-1200 | 30x |
| 单镜头生成尝试 | 1-3 | 5-15 | 5x |
| 总生成次数 | ~100 | **5000-15000** | **100x** |
| 项目素材文件 | ~200MB | **30-100GB** | **150x** |
| 文档字数 (剧本) | 1000 字 | **60000-100000 字** | **80x** |
| 项目时长 (开发周期) | 1-2 周 | **3-6 月** | **20x** |
| 单 API 项目花费 | <$50 | **$1k-20k** | **200x** |
| 时间轴长度 | 5 分钟 = 9000 帧 | 60 分钟 = **108000 帧** | 12x |
| 音轨数 | 1-2 | **5-10** (dialog/music/SFX/foley/ambient) | 5x |

**数量级换算后，至少 3 个维度 (生成次数、文件体积、项目周期) 进入了"系统级别问题"区域 — 不是 UI 优化能解决的。**

---

## 2. 真实走一遍：长片工作流的 7 个阶段

### 阶段 1: 剧本与世界观 (Week 1-4)

**真实流程**：
- 写 3 页大纲
- 拆 30-50 个 beat（"开场"，"激励事件"，"第二幕转折"…)
- 扩展到 60-100 页剧本
- 10+ 个角色 bible (每个 500-1000 字)
- 世界观文档：种族、地理、历史、文化

**撞到的墙**：

🧱 **墙 1：编辑器扛不住 6 万字**
TipTap 在 1000+ 段时开始卡。光是滚动就肉眼可见的延迟。

🧱 **墙 2：分支版本管理空白**
"我把第三幕的结局改一下试试" — 你怎么对比新旧两版？你怎么对比"如果让 A 角色死了" vs "如果让 B 角色死了"两条线？

🧱 **墙 3：跨章节一致性失控**
第 30 页角色描述说"小苏总穿白衬衫"，第 60 页台词里写"她今天换了红裙子"。50 页的距离我自己都不记得。

🧱 **墙 4：AI 协作者的上下文窗口**
你想让 AI 帮你改第 80 页的对白，让它读全本（6 万字）。但：
- Claude 200k 上下文够用但每次调用贵
- GPT 128k 可能不够（剧本+角色+设定）
- 大部分本地模型 32k 还远远不够

🧱 **墙 5：角色 voice 一致性**
小苏说话方式：内向、爱用"嗯…"、句子短。但第 50 页 AI 给她写了一句莎士比亚式独白。怎么自动检测？

**对应需求**：
- 大文档高性能编辑（虚拟化渲染）
- 剧本版本控制 (Git-like branching) 内建
- 一致性检查器 (角色外观/动作/口癖)
- 分层上下文窗口策略 (act → scene → shot 的 hierarchical summarization)
- "Voice 指纹"：基于已有对白生成 voice profile，新对白对比打分

### 阶段 2: 视觉设计 (Week 4-8)

**真实流程**：
- 主角设计：5-10 个 character turnaround（正、侧、背、3/4、表情、动作）
- 主角变种：年轻版/老年版/受伤版/盛装版 → 4-8 个
- 配角设计：每个 3-5 张参考
- 场景设计：每个场景 5-10 个角度+时段
- 风格 bible：master 色板、灯光规范、艺术方向文档
- 总计 200-500 张设计图

**撞到的墙**：

🧱 **墙 6：扁平画布看不过来**
500 张参考图全堆在画布上 = 视觉灾难。zoom out 看不清，zoom in 找不到。

🧱 **墙 7：版本管理**
小苏 V1 → V2 → V3 → V4 → V5。哪个是被批准的？V3 是因为什么否决的？我两周后还记得吗？

🧱 **墙 8：批准与锁定**
"小苏 V4 是 final"，我不希望 AI agent 不小心给我重新生成覆盖。但当前 Nomi 任何节点都能 regen。

🧱 **墙 9：变种批量生成**
小苏 final 已定，我想"基于这个生成 12 种表情" — 需要批量、需要保持 LoRA、需要并发控制（API 限流）。

🧱 **墙 10：风格 vs 个性**
全片要统一"宫崎骏风格"，但每个场景的光线又不同。需要"global 风格 × per-scene 细节"的叠加机制。

**对应需求**：
- 资产库视图（不是画布）：网格、列表、卡片三种密度
- 多维筛选：角色/场景/版本/状态/日期/cost
- 版本树 (V1, V2, V3) 显式展示，可点击切换
- 批准/锁定状态机：草稿 → 候选 → 批准 → 锁定
- 锁定资产的 regen 必须二次确认
- 全局 LoRA + 局部 LoRA 的优先级规则
- 批量变种生成 (queue + 进度跟踪)

### 阶段 3: 故事板 (Week 8-12)

**真实流程**：
- 剧本拆成 500-1200 个分镜
- 每个分镜：粗略草图 + 角色姿态 + 对白 + 动作描述 + 时长
- 按 act → scene → shot 三层组织
- Animatic：把粗稿排到时间轴，加 scratch audio (临时配音 + 临时音乐)，看节奏对不对
- 反复打磨：删镜头、加镜头、重排

**撞到的墙**：

🧱 **墙 11：1200 个节点画布根本打不开**
即使分类了，每个子画布几百个节点也不行。需要**虚拟化渲染**（只渲染视口内的）。

🧱 **墙 12：导航**
"跳到 scene 12 shot 7" — Cmd+G 一样的快速跳转。当前完全没有。

🧱 **墙 13：上下文不可见**
我在编辑 shot 437，但想看 shot 436 和 438 是什么样的。怎么不切换页面就看到？

🧱 **墙 14：Animatic mode**
我想拖入"占位粗稿"先排时间轴看节奏，确认后再生成真正的画面。当前 Nomi 没有"占位 vs 成片"的概念区分。

🧱 **墙 15：批量重排**
"在 shot 47 和 48 之间插一个新镜头" — 后面所有镜号要更新，引用关系要更新。当前是手动。

🧱 **墙 16：分镜稿的"草图"画不出**
我想画个简笔人 + 箭头表示"小苏从左向右走"，再给 AI。当前画布没有钢笔/手绘工具。

🧱 **墙 17：scene 7 整段重写**
"scene 7 改成黄昏" — 涉及 12 个分镜，每个的 prompt 都要改一遍。当前是 12 次手动。

**对应需求**：
- 虚拟化画布渲染（react-window 类似机制）
- 三层导航：act / scene / shot（与剧本结构同步）
- 全局快速跳转命令（Cmd+G）
- 上下文 ribbon：当前镜头旁边永远显示前/后 2-3 个镜头
- "占位 placeholder" 节点类型 vs "成片 final" 节点类型
- 批量重新编号 + 引用自动更新
- 简易手绘工具（在分镜稿上画指引线、箭头）
- 批量改 prompt（"把这 12 个镜头的 prompt 后缀都加上 'sunset light'"）

### 阶段 4: 生成 (Week 12-20) — 最大瓶颈

这是长片项目最长、最贵、最容易翻车的阶段。

**真实流程**：
- 1000 镜头 × 5-10 次尝试 = **5000-10000 次生成调用**
- 每次 $0.10 - $2.00 = **$500 - $20000 总成本**
- 跨多个 provider (Chatfire 主、备用 Replicate、本地 ComfyUI)
- 周期 6-8 周（你不可能一晚上跑 10000 次）

**撞到的墙**：

🧱 **墙 18：成本失控**
"我到底花了多少钱在这个项目上了？" — 当前 Nomi 不告诉你。Provider 自己的 dashboard 也只显示总账单，不区分项目。

🧱 **墙 19：API 限流**
ChatFire 限你 60 req/min。你想 batch 跑 200 个，撞墙了。当前 Nomi 没有 rate limit aware queueing。

🧱 **墙 20：失败重试**
跑到第 678 个的时候 provider 5xx 了。当前要怎么恢复？现在没有"任务队列"概念。

🧱 **墙 21：素材洪流**
10000 张 PNG 在文件系统里。每张 5MB。**总 50GB**。Finder 卡，搜索慢，备份痛。

🧱 **墙 22：找不到东西**
"shot 437 的最佳生成结果是哪个？" — 是 V3 吧？还是 V7？我记不清。当前 Nomi 没有"per-shot 生成历史"视图。

🧱 **墙 23：可复现性**
3 个月后客户要求"把 shot 437 改一改"。你要怎么用一模一样的 model + prompt + seed 重跑？当前 Nomi 不保证记录所有这些。

🧱 **墙 24：长任务不可见**
batch 跑 200 个，估计 40 分钟。你不能盯着屏幕。需要后台跑、桌面通知、可在锁屏时继续。

🧱 **墙 25：磁盘空间**
50GB 项目 × 5 个项目 = 250GB。我的 256GB MacBook 哭了。需要 archive / cloud offload / 删除变种等策略。

🧱 **墙 26：质量难评估**
10 个变种谁好？要肉眼一个个看。当前没有"美学评分"、没有"和参考的相似度"、没有"和角色 bible 的一致度"。

**对应需求**：
- **Cost tracking 系统**：每次生成记录 cost，per-shot / per-project / per-provider 聚合
- **Budget alerts**：项目超过 X% 时弹通知，硬上限时拒绝
- **Rate-limit aware queue**：检测 provider 限流，自动 backoff
- **持久化任务队列**：跨重启可恢复，dead-letter 队列
- **生成历史**：per-shot 显示所有尝试，标注 picked / rejected / dead
- **完整 provenance**：每张图保存 prompt + model + seed + 完整参数
- **后台执行**：长任务不依赖前端在线，桌面通知
- **存储分层**：hot (project root) / warm (compressed in cache) / cold (offload to cloud or external drive)
- **AI 辅助筛选**：批量生成后 LLM 给变种打分，自动推荐 top 3
- **审查队列**：未审查的变种用红点标记，避免遗漏

### 阶段 5: 编辑 (Week 20-24)

**真实流程**：
- 1000 镜头按时序排上时间轴 = **60 分钟时间轴**
- 多轨道：视频 × 3 (主、背景、叠加) + 音频 × 5 (对白、音乐、环境、SFX、foley)
- 镜头之间转场 (cut / fade / dissolve)
- 速度斜坡 (speed ramp)
- 色彩分级（每镜头微调 + 全片统一）
- 配音对位 (lip sync 如果是动画就要做)
- 字幕（可能多语言）
- 片头片尾标题卡

**撞到的墙**：

🧱 **墙 27：60 分钟时间轴根本撑不动**
当前 Nomi 时间轴是为 30 秒短片设计的。1000 clips 加载时卡死。

🧱 **墙 28：多音轨缺失**
当前只有图片轨 + 视频轨。dialog/music/SFX/foley/ambient 5 轨完全没有。

🧱 **墙 29：调色工具**
当前完全没有。色彩分级需要：曲线、LUTs、3-way color、批量应用。

🧱 **墙 30：字幕系统**
60 分钟字幕，多语言版本（中/英/日），SRT 导入导出，字幕样式（位置、字体、阴影）。完全空白。

🧱 **墙 31：对白与口型同步**
动画的话，AI 配音 + AI 口型对位是巨大挑战。即使非动画，配音时长不准也会拖累时间轴。

🧱 **墙 32：渲染时间**
60 分钟 1080p 渲染 = 1-3 小时（含转场和音轨）。**渲染中能不能继续工作**？

🧱 **墙 33：增量保存**
60 分钟时间轴每改一下就重新写整个 project.json？文件 100MB 每次写一下太慢。需要 incremental save。

**对应需求**：
- 时间轴虚拟化渲染（不在视口的 clip 不渲染缩略图）
- 多音轨架构（设计上至少 5-8 个 audio lanes）
- 集成基础调色（curves、LUTs、batch 应用 LUT）
- 字幕系统（SRT 导入导出、样式、多语言）
- AI 配音集成 (ElevenLabs / Suno) 作为 provider
- 口型同步工具（基于 Sadtalker、Wav2Lip 等）
- 后台渲染：渲染中可以继续编辑下一段
- 增量项目保存：只写改了的部分

### 阶段 6: 后期制作 (Week 24-26)

**真实流程**：
- 最终渲染：4K 母版 + 1080p 发布版 + 9:16 短视频版 + 1:1 推广版
- 每个版本可能需要不同的字幕、不同的剪辑长度
- 色彩最终校准
- 母带制作（音频压缩、归一化）
- 多语言版本（不同的字幕和配音）
- Delivery: YouTube / Bilibili / 电影节投递

**撞到的墙**：

🧱 **墙 34：多 deliverable 管理**
4K master + 1080p YouTube + 9:16 Shorts + 1:1 IG = 4 个版本。每个有不同剪辑、字幕、cover image。当前 Nomi 一个项目只能导出一种。

🧱 **墙 35：母带与 derivative 关系**
我希望"4K 是母版，其他三个从母版派生"。改了母版，其他三个自动更新（或至少警告）。

🧱 **墙 36：节目编排**
60 分钟的 + 30 秒精华版 + 5 分钟预告 = 三个 cut。如何不复制三个工程？

🧱 **墙 37：投递规范**
不同平台规范不同：YouTube 需要 H.264，Bilibili 需要特定 codec，电影节投递可能要 ProRes。

**对应需求**：
- 多 deliverable / multi-cut 项目结构
- "Master + derivatives" 工作流
- 平台预设（YouTube / Bilibili / Vimeo / Netflix proxy / FilmFreeway）
- 多语言 master（一个项目，多个字幕音轨）

### 阶段 7: 维护与迭代 (Week 26+)

**真实流程**：
- 发布后收用户反馈
- 客户要求改某个镜头
- "做个续集吧" — 用同一批角色和场景
- 半年后回头改一处

**撞到的墙**：

🧱 **墙 38：跨项目复用**
小苏这个角色，我做完第一部想做第二部。她的角色 bible + LoRA + 参考图怎么从 project A 复用到 project B？当前 Nomi 完全没有跨项目资产库。

🧱 **墙 39：项目归档**
30GB 项目，半年没动了。我硬盘要满了。能不能"归档"（保留剧本和元数据，压缩或卸载素材）然后未来"再水化"（restore）？

🧱 **墙 40：客户协作**
客户说"shot 437 的表情再温柔一点"。我能不能给他一个 share link 让他直接 mark up 这个镜头？而不是邮件来回十次？

🧱 **墙 41：知识沉淀**
做了一年 AI 创作，我学到了什么 prompt 风格 work？我用过什么模型？花了多少钱学到什么经验？当前完全无沉淀。

**对应需求**：
- 跨项目资产库 (Nomi 用户级，不只是项目级)
- 项目归档 / 水化机制
- 客户审阅 / 评论模式 (file-based 简单分享，不必上云)
- 用户级知识库：常用 prompt、cost trend、效果好的 LoRA

---

## 3. 我撞到的 41 堵墙，归纳为 12 大需求群

把上面的 41 堵墙归纳，得到 12 个需求群：

### G1: 规模化渲染 (Performance at scale)
- 虚拟化画布（react-window）
- 虚拟化时间轴（60min+ 不卡）
- 增量保存（不重写整个 project.json）
- 大文档编辑（剧本 6 万字不卡）

### G2: 资产管理 (Asset library at scale)
- 资产库视图（不只画布，还有 grid/list/card）
- 多维筛选（角色/场景/版本/状态/cost/日期）
- 搜索（全文 + 元数据）
- 跨项目资产库

### G3: 版本与批准 (Versioning & approval)
- 显式版本树 (V1, V2, V3)
- 批准状态机 (draft → candidate → approved → locked)
- 锁定后 regen 二次确认
- 项目级分支 ("what if" 探索)

### G4: 一致性 (Continuity)
- 角色外观一致性自动检查
- 场景灯光连续性
- 配音 voice 指纹
- 风格全局应用（global LoRA + per-shot override）

### G5: 成本管理 (Cost & resource management)
- per-生成 cost 记录
- per-shot / project / provider 聚合
- budget alerts (软警告 + 硬上限)
- 跨 provider 比价

### G6: 任务队列 (Reliable execution)
- 持久化任务队列（跨重启）
- Rate-limit aware（自动 backoff）
- 失败重试 / dead letter
- 后台执行 + 桌面通知
- 长任务进度可见

### G7: 完整 provenance (Reproducibility)
- 每生成保存 model + prompt + seed + 完整参数
- 3 个月后能 1-click 再现
- diff 工具（V3 vs V5 prompt 区别）

### G8: 存储管理 (Storage tiering)
- Hot (project root) / Warm (compressed cache) / Cold (cloud/external)
- 智能归档（半年没动的项目自动 warm）
- 项目级压缩 export

### G9: 长上下文 AI (Hierarchical context)
- 分层 summarization（act/scene/shot）
- 增量 context（只送相关部分给 LLM）
- Token 预算管理

### G10: 编辑器进阶 (Editing power)
- 多音轨（5+ lanes）
- 调色（曲线/LUT/3-way）
- 字幕系统（SRT + 多语言 + 样式）
- AI 配音 + 口型同步
- 后台渲染

### G11: 多 deliverable (Multi-output)
- 同项目多 cut (60min + 5min + 30s)
- 多分辨率自动派生
- 多语言版本
- 平台预设投递规范

### G12: 协作与归档 (Collaboration & archive)
- 客户审阅模式（file-based 简单分享）
- 项目归档 / 水化
- 跨项目知识沉淀
- 跨项目资产复用

---

## 4. 诚实自我批评：之前 PRD 哪些是对的、哪些是错的

### 之前对的部分 ✅

1. **本地优先 + 开源**：长片场景下，30-100GB 的项目数据**不可能**让用户接受云端
2. **项目记忆 + Agent + Production Graph 三层架构**：方向是对的
3. **结构化创作 (Nomi Script)**：长片 6 万字剧本和 10+ 角色管理的核心
4. **目录树 + 子画布**：30 镜头时是 UX 优化，1000 镜头时是**生死攸关**

### 之前错的或缺失的部分 ❌

1. **"30 镜头"作为默认场景**：天然限制了思考。长片场景下"分类" 30 → 1000 镜头需要的不是 UI 调整，而是架构级虚拟化。

2. **缺失"规模化渲染"维度**：我之前的 PRD 把节点画布当作"无限的"，但实际上 1000 节点 React 渲染会爆。**必须从 Phase E 第一天就考虑虚拟化**。

3. **缺失成本与资源管理**：长片项目可能花费 $20000，**这是任何家庭式创作者最大的痛点**。Nomi 不告诉你成本 = 你随时可能"破产"。这个功能**应该是 v0.5 必须有**，不是后期附加。

4. **缺失任务队列**：之前的 PRD 假设生成是"即时"的。长片场景下生成是"批次 + 异步 + 可恢复"的。这是基础设施级缺失。

5. **缺失版本管理**：Nomi Script 假设单一 source of truth。但创作者会想"两个结尾试试" — 项目级 git-like 分支必须内建。

6. **缺失资产库视图**：所有 PRD 把"资产"等同于"画布节点"。但长片场景下用户大部分时间不在画布而是在**资产库**里 (Bridge / DaVinci Media Pool 模式)。

7. **缺失跨项目复用**：续集场景被完全忽略。用户级资产库是 v1.0+ 的关键。

8. **时间轴假设短片**：60 分钟时间轴 + 5 音轨 + 调色 + 字幕 — 这是一个**完整 NLE (non-linear editor)** 的工程量。当前 Nomi 时间轴只是个粗胚。

9. **AI Agent 的上下文窗口**：之前 PRD 没考虑过"剧本 6 万字怎么塞进 Agent"。需要分层 summarization 和增量 context 策略。

10. **存储与归档**：30-100GB 项目谁来管？我的 PRD 假设硬盘无限。

---

## 5. 关键的产品认知升级

走完这条路后，我对 Nomi 的认知升级了：

### 升级 1：Nomi 不是"AI 创作 IDE"，是"AI Creator OS"

**IDE** 类比指向 VSCode — 一个文本编辑器壳。

**OS** 类比指向像 DaVinci Resolve + Figma + Notion + Lightroom + GitHub 的**复合体**：
- 资产管理 (DAM)
- 工作流编排 (Workflow)
- 项目版本控制 (Git)
- 多 deliverable 输出 (Render)
- 知识沉淀 (Knowledge)

**Nomi 真正卖的不是工具，是"AI 创作者的整个操作环境"**。

### 升级 2：长片是定义产品上限的场景

**短片场景下，Nomi 和 Krea/TapNow 区别不大**。
**长片场景下，Nomi 是唯一选择**。

竞品的不可能：
- Krea 不可能存 30GB 本地项目
- ComfyUI 不可能管理 10+ 角色 bible
- Figma 不可能做 60 分钟时间轴
- Final Draft 不可能生成视觉资产
- DaVinci 不可能写剧本

**用户的长片需求把 Nomi 推到一个"无人区"**。

### 升级 3：Cost & Reliability 是新的差异化轴

之前的 PRD 强调"差异化 = 本地 + 开源 + AI-native"。
长片场景揭示新的差异化轴：**成本透明 + 任务可靠**。

云端工具的成本是黑箱（一个月看一次账单震惊一次），任务也不可靠（API 出错就丢）。
**Nomi 给用户"成本主权 + 任务可靠性"** 是云端工具天生做不到的。

这进一步强化"本地"的价值 —— 不仅仅是数据本地，还是**控制本地**。

### 升级 4：从"短片闭环"到"长片闭环"的产品分阶段

| 阶段 | 服务的场景 | 关键能力 | 时间 |
|---|---|---|---|
| **v0.5-v0.7** (当前 PRD) | 5 分钟 30 镜头短片 | 目录树 + Nomi Script + 故事板 demo | 3 个月 |
| **v0.8-v1.0** (新增) | 15 分钟 100 镜头微电影 | 资产库 + 成本系统 + 任务队列 | 3 个月 |
| **v1.x** (新增) | 60 分钟 1000 镜头长片 | NLE 编辑器 + 多 deliverable + 长上下文 AI | 6 个月 |
| **v2.x** (远期) | 完整工业级长片协作 | 跨项目知识库 + 协作模式 + 归档 | 1 年+ |

**v0.5-v0.7 是入门盘**。v0.8+ 才是真正建立壁垒的地方。

---

## 6. 对当前 12 周路线图的修正建议

之前 (`nomi-product-prd-v2-2026-05-23.md`) 的 Phase 1-3 路线图聚焦"项目目录 + Nomi Script + 关系图谱"。这是对的，但**缺少长片需要的 4 个关键基础设施**。建议补充：

### 修正 1：Phase E (v0.5) 增加"规模化基础"
原 Phase E：目录树 + 默认 8 分类 + 子画布
**新增**：从 day 1 就用 react-window 做虚拟化渲染。**未来后悔的成本是 10x，现在做的成本是 1.5x**。

### 修正 2：Phase E 增加"基础 cost tracking"
原 Phase E：无 cost 系统
**新增**：最简单的版本 — 每次生成调用后台记一笔 (model, provider, cost estimate)。项目页显示总花费。**这是创作者活下去的工具**。

### 修正 3：Phase F (v0.6) 增加"任务队列"
原 Phase F：Nomi Script + 双向绑定
**新增**：把生成调用全部走持久化队列。**Phase B 的 streamText 是即时的，但批量生成必须异步可恢复**。

### 修正 4：Phase G 之后插入 Phase H "资产库" (v0.8)
**新 Phase H**：脱离画布的资产库视图 + 跨项目资产共享 + 版本树。这是长片的入门门票。

### 修正 5：Phase I (v0.9) "完整 NLE 编辑器升级"
**新 Phase I**：5-8 音轨 + 字幕系统 + 调色基础 + 后台渲染。

### 修正 6：Phase J (v1.0) "多 deliverable + 长上下文 AI"
**新 Phase J**：同项目多 cut + 长 context 分层 + 平台预设。

---

## 7. 推荐立即调整的事情

不是说"全部重写"。是说**在不打乱当前 Phase A-D 已完成迁移的前提下**，做 4 个立即的调整：

### 立即调整 1：Phase E 的目录树 PRD 加上"规模化"段

在 `nomi-structured-creation-prd-2026-05-24.md` §6 每个子画布的能力描述里，**显式加 "节点 > 50 时必须虚拟化"**。给执行 agent 这个性能约束。

### 立即调整 2：Phase E 加一个 cost tracking 最小化原型

任何 generation 调用最后写一条 `cost-log.jsonl` 到项目目录。UI 端在项目页角落显示总花费。**这是 30 行代码的事，但对用户极其重要**。

### 立即调整 3：Phase F 重新审视任务队列

Phase B 已经有 `streamText` 流式 chat。但批量生成（C4 的 `runGenerationNodesBatch`）目前是**前端 Promise.all**，没有持久化。Phase F 应该把它升级为后端持久化队列（写到 `~/Documents/Nomi Projects/{id}/queue/`）。

### 立即调整 4：路线图加 Phase H/I/J

在 `nomi-product-prd-v2-2026-05-23.md` 的 §6 12 个月路线图后面，**加 3 个 Phase 描述**（H 资产库、I NLE 升级、J 多 deliverable），让团队和未来用户知道我们要去哪。

---

## 8. 长片场景对竞品差异化的影响

回到 v2 PRD §3 的竞品分析，长片场景下重新打分：

| 维度 | Krea | TapNow | Figma + AI | ComfyUI | Final Draft | DaVinci | **Nomi (长片 ready)** |
|---|---|---|---|---|---|---|---|
| 6 万字剧本管理 | ✗ | ✗ | ✗ | ✗ | ✓✓ | ✗ | **✓** |
| 1000 资产管理 | ✗ | ✗ | △ | ✗ | ✗ | ✓✓ | **✓✓** |
| 60min 时间轴 | ✗ | ✗ | ✗ | ✗ | ✗ | ✓✓ | **✓** |
| AI 生成集成 | ✓✓ | ✓ | △ | ✓✓ | ✗ | ✗ | **✓✓** |
| 成本管理 | △ | △ | ✗ | ✗ | ✗ | ✗ | **✓✓** |
| 本地 + 开源 | ✗ | ✗ | ✗ | ✓✓ | ✗ | ✗ | **✓✓** |
| 项目 6 个月归档 | ✗ | ✗ | △ | △ | △ | ✓ | **✓✓** (目标) |

**长片场景的现实**：现在没有任何一个工具能在所有维度上都打勾。**Nomi 是唯一有机会做到的产品**。这是真正的护城河 — 不是某个 feature，而是这个**复合能力矩阵**。

---

## 9. 风险：你确定你能做这么大吗？

诚实的反问。

**风险 A：6-12 个月 v0.5-v0.7 都不够**
长片场景的完整闭环可能要 18-24 个月。早期用户耐心吗？

**对策**：分阶段交付价值
- v0.5-v0.7 服务短片，让短片创作者就能享受到 Nomi
- v0.8-v1.0 拓展中片，把短片用户转换成中片用户
- v1.x 才真正闭环长片，那时社区已经成型

**风险 B：12 个需求群每个都是 Adobe 一个产品的工程量**
Nomi 一个开源项目能扛吗？

**对策**：
- 每个需求群只做"刚好够用"的最小子集
- 复杂的让用户用其他工具配合 (Premiere export → Nomi import)
- 长尾让社区贡献 (skill pack 生态)

**风险 C：长片这件事可能太冷门**
1000 个 Nomi 用户里有几个真的做长片？

**对策**：长片是定义上限的场景，不是定义客户的场景。
- 90% 用户做短片，享受被长片设计影响的强健架构
- 10% 用户做长片，**他们就是 Nomi 的核心用户故事**（小苏案例升级到老王长片案例）
- 长片用户付费意愿 + 口碑放大效应远高于短片用户

---

## 10. 总结：3 件最重要的事

1. **Nomi 的产品定义需要升级**：从"AI 创作 IDE"到"AI Creator OS"。这影响下一年的路线图。

2. **当前 PRD 路线图缺失 4 个 Phase**：H (资产库)、I (NLE 升级)、J (多 deliverable)、跨项目 (v2.x)。**不补这 4 个，Nomi 永远做不到长片**。

3. **现在就要做的 4 件小事**：规模化渲染从 day 1、cost tracking 最小化原型、任务队列升级、路线图扩展。**不做这 4 件，等到长片用户来时已经晚了**。

---

## 11. 给下一份 PRD 的 4 个指导原则

写后续 PRD 时遵守：

### 原则 1：用长片场景压力测试每一个 feature
每写一个 feature，问"这个在 1000 镜头时还 work 吗？"如果不 work，要么改设计，要么显式声明"这是短片场景专属"。

### 原则 2：用户价值 > 功能完整性
长片有 12 个需求群。优先级排序：
- 用户最痛的 → 最先做（成本管理、任务队列、虚拟化）
- 用户最爽的 → 次先做（资产库、版本树）
- 用户最专业的 → 慢慢做（调色、口型同步）

### 原则 3：本地优先永远是底线
不要为了 cloud feature 引入云端依赖。所有云能力都是可选项。

### 原则 4：成本对用户透明
任何会消耗用户钱的操作 (API 调用、存储、带宽) 都必须在 UI 上显示成本估算。

---

## 12. 跨文档关系

| 文档 | 角色 |
|---|---|
| 本文档 | **长片场景压力测试**，§13 给出 12 需求群的 P0/P1/P2 分级 |
| `nomi-product-prd-v2-2026-05-23.md` | 战略大盘，§6 路线图已根据本文档扩展为 5 个 Phase (v0.4 → v1.0) |
| `nomi-structured-creation-prd-2026-05-24.md` | Phase E/F/G 详细设计 (v0.5-v0.7)，对应本文档 P0 |
| `nomi-agent-migration-plan-2026-05-23.md` | 已完成 (v0.4.0)，给后续提供 Agent + tool calling 基础 |
| `nomi-differentiation-prd-2026-05-23.md` | 早期差异化分析，仍然有效但需要在长片视角下重读 |

---

## 13. 12 个需求群的 P0 / P1 / P2 分级

判据：

- **P0**（满足任一即 P0）
  - 是架构地基（建错了未来重构成本 10x+）
  - 短片用户也需要（30-100 资产时就开始痛）
  - 实现成本远低于用户感知价值（如 cost log 30 行 vs 巨大用户价值）

- **P1**：中片场景（100-300 资产）必需，短片用户偶尔需要
- **P2**：长片场景（500+ 资产）才必需，或可用外部工具 workaround

### 13.1 P0 — 必须在 v0.5-v0.7 (Phase E/F/G) 完成

| 需求群 | 为什么 P0 | 落到哪个 Phase |
|---|---|---|
| **G1 规模化渲染** | 架构地基。Phase E 第一天不用 react-window，未来 1000 节点重构成本 10x | Phase E (v0.5) |
| **G2 资产库视图（项目内）** | 50+ 资产时画布已不好用；脱离画布的网格 / 列表视图是基础 | Phase E (v0.5) |
| **G3 版本与批准（per asset）** | 任何重复使用的角色都需要 lock；不锁就会被 regen 覆盖 | Phase F (v0.6) |
| **G4 角色一致性** | **AI 创作 today #1 痛点**，5 镜头时就出现，非长片专属 | Phase G (v0.7) |
| **G5 成本管理（基础版）** | 30 行 jsonl + 项目角落显示总额，巨大用户价值，技术风险 = 0 | Phase E (v0.5) |
| **G6 任务队列（持久化）** | 当前 Promise.all 在 batch 20 个时就脆弱；Phase C 批量生成需要持久化 | Phase F (v0.6) |
| **G7 完整 provenance** | 现有 `result.raw` 包含部分；只需正式化 + 加 seed 字段 | Phase E (v0.5)，轻量 |

**P0 = 7 项**，全部分布在 v0.5-v0.7。不做这些，Phase E/F/G 自身价值大打折扣。

### 13.2 P1 — v0.8-v0.9 (Phase 3-4) 完成

| 需求群 | 为什么 P1 | 落到哪个 Phase |
|---|---|---|
| **G2 跨项目资产库** | 单项目内是 P0；跨项目（续集场景）等用户群积累到一定规模再做 | Phase 3 (v0.8) |
| **G3 项目级 git-like 分支** | per-asset 版本是 P0；项目级"what if"分支更进阶 | Phase 3 (v0.8) |
| **G10 多音轨 + 字幕** | 5 分钟短片 1-2 轨够用；30 分钟中片必需 5 轨 | Phase 4 (v0.9) |
| **G11 多 deliverable** | 短片偶尔要 9:16；中片要 4K + 1080p + 9:16 全套 | Phase 4 (v0.9) |

**P1 = 4 项**，定义 Phase 3-4 (v0.8-v0.9) 的核心目标。

### 13.3 P2 — v1.0+ 或可外部工具 workaround

| 需求群 | 为什么 P2 | 落到哪个 Phase |
|---|---|---|
| **G8 存储管理（分层归档）** | 只在 10GB+ 项目才有问题；短中片 < 1GB | Phase 5 (v1.0) |
| **G9 长上下文 AI 分层** | 6 万字剧本才需要；短片 1000 字直接塞 | Phase 5 (v1.0) |
| **G10 色彩分级（曲线/LUT）** | 专业能力；可让用户先用 DaVinci 后再回 Nomi | Phase 5 (v1.0) |
| **G12 协作 + 跨项目知识库** | 长片专属；早期 1 个人 + file-based 分享够用 | Phase 5+ (v1.0+) |

**P2 = 4 项**，长片闭环的 finishing touch，短中片用户可完全不需要。

### 13.4 三档分布的内部逻辑

```
P0 (7 项) — v0.5-v0.7  →  服务 90% 用户（短片 + 中片入门）
P1 (4 项) — v0.8-v0.9  →  服务 30% 用户（中片完整 + 长片入门）
P2 (4 项) — v1.0+      →  服务 10% 用户（长片专业）
```

这个分布与"长片用户付费意愿高 + 口碑放大效应大"对齐 —— **我们用 v0.5-v0.7 服务大盘，用 v0.8+ 把核心用户转化为付费**。

### 13.5 4 个立即可做的"微调"

回到本文档 §7 的 4 个立即调整建议，全部归入 P0：

1. **Phase E day 1 强制虚拟化** — 在 `nomi-structured-creation-prd-2026-05-24.md` §6 每个子画布加 "节点 > 50 时必须虚拟化"
2. **Phase E 加 cost log 原型** — 30 行 jsonl + UI 角落显示，列为 E 阶段独立 task
3. **Phase F 升级任务队列** — `runGenerationNodesBatch` 从前端 Promise.all 改后端持久化
4. **路线图扩展** — 已驱动 `nomi-product-prd-v2-2026-05-23.md` §6 扩展为 5 Phase

---

## 14. 总结

**P0 7 项 / P1 4 项 / P2 4 项** 的三分给团队和未来 PRD 写作者一个清晰的优先级框架：

- 短期（3 个月内）：聚焦 P0 — 不做就让 Phase E/F/G 自身价值打折
- 中期（3-9 个月）：聚焦 P1 — 决定 Nomi 能不能从短片产品扩展到中片
- 长期（9 个月+）：聚焦 P2 — 把 Nomi 推到长片闭环的 finishing line

任何时候有新功能想做，先问"这是 P0/P1/P2 哪一档"。**P2 的功能在 P0/P1 没完成前不应该消耗任何资源**。
