Chapter 01 / StoryCam Session
从一句私人念头，到可开发的 StoryCam 产品基线
本章记录 StoryCam 早期产品与设计 session：它把“私人小剧场相机”的概念，拆成可解释、可确认、可生成、可拼接的视频创作链路，并完成项目文档和设计参考的首个沉淀。
TL;DR
docs/，根目录保留 AGENTS.md，工具缓存不作为项目文档。aee450a Initialize StoryCam product docs；没有 PR、CI 或 deploy。本章学习目标
工具、参考图和可视化证据
使用到的技能与工具
gstack-office-hours：用于产品讨论和方向澄清。frontend-design：用于生成/约束设计交接和 UI 图表达。image_gen：用于生成 StoryCam 多步骤 UI flow board。git：初始化项目提交，记录文档和设计资产。
参考项目与模型假设
- 参考项目：
Shanyin-ai/shanyin-director-master。 - 定位：内部导演脑、分镜方法、质量检查参考。
- 模型假设：Seedance 2.0 作为第一版主打视频生成模型。
- 未确认：本 session 未产生真实视频调用或 provider payload。
可视化证据：用户指出“视频生成的各个环节不是在一个界面完成的”，因此最终生成的是按步骤排列的 UI 画板。它用于解释从输入、故事世界确认、核心分镜、扩展分镜、片段生成、片段确认到最终拼接的完整交互顺序。若图片在当前项目版本中不可见，请确认项目是否保留了 docs/design-docs/assets/storycam-ui-flow-board.png。
聊天中出现的截图/图片
- 用户提供的“分镜向四周扩散”截图：用于定义核心分镜扩展画布的交互模式。
- 用户提供的“剧本、人物资产、场景资产”截图：用于明确输入后的第一屏不应是视频预览，而应是故事世界确认。
- Codex 生成的 UI 图：先生成过单屏聚合版，随后按用户反馈改成多步骤画板。
沿时间排列的原始 Prompt
1. 项目记忆和技能边界
“现在 gstack 是全局的 skills，我看现在文件夹下有个 gstack 的文件夹是不是就可以不用了？……好，你处理下”
教师批注：这是一个项目卫生 prompt。它不是功能需求，却决定了项目长期可维护性：工具缓存、全局 skill、项目文档必须分开，后续才不会把临时状态误当成项目知识。
2. 启动产品讨论
“[$gstack-office-hours] 针对 product-vision.md 展开讨论，设计 storycam 这个产品”
教师批注：用户没有直接要求实现，而是要求用 office-hours 方法讨论产品。这体现了早期项目的正确节奏：先把需求、用户、约束和魔法点讲清楚，再写代码。
3. 锚定产品魔法
“输入一句‘我想把暗恋拍成韩剧雨夜’，它生成一段像你私人记忆一样的预告片”
教师批注：这是产品感觉的锚点。它把抽象的“AI 视频生成”变成一个可讲、可设计、可测试的样例。后续所有文档、UI 和生成链路都围绕这个例子展开。
4. 从单一 demo 扩展为更泛产品
“需要一个更泛的私人小剧场相机……希望第一版真的生成视频”
教师批注：这个 prompt 同时做了两件事：扩大品类边界，同时提高 MVP 验收标准。它避免产品变成单题材 demo，也避免产品退化成只生成脚本和图片的“半成品”。
5. 文档结构和 Web-first 约束
“所有文档要落到 docs 文件夹里……根目录要有 AGENTS.md……第一版做的是 web 端的产品”
教师批注：这是项目组织 prompt。它要求把产品、研发、部署和上下文沉淀到项目内，并明确第一版不是移动端。读者可以学习：早期约束越清晰，后续协作越少返工。
6. 引入 Shanyin 作为导演方法论
“你需要充分利用 https://github.com/Shanyin-ai/shanyin-director-master，因为后续整个视频生成过程关键的提示词或方法都会从这个参考项目中迭代改进出来”
教师批注：这是能力来源 prompt。用户指定了后续 prompt 和视频生成方法的参考源，但没有要求照搬 UI。关键做法是把参考项目转译成内部方法论。
7. 关键产品纠偏：从关键帧到核心分镜组
“用户输入后，应该会得到剧本、人物资产和场景资产……确认后，会进一步生成分镜脚本和 1-3 个分镜图……每个最初的分镜（带着它的拓展图）生成一个视频，然后……系统自动建议拼接这几个视频为最终作品”
教师批注：这是本 session 最大转折点。用户把生成链路重新切分成更合理的产品单位：核心分镜组。它解决了模型调用成本、用户确认、视频时长和交互意义之间的错位。
8. 设计交接的降维
“不用有这么内容，过于复杂，就有个一给实际的文档和一个用 gpt image 2 生成的 ui 图（包括各个交互）即可”
教师批注：这是协作效率 prompt。它提醒我们：对设计师有帮助的不是大量文档，而是一个清楚的 brief 和一张能讨论的图。早期原型交接要轻。
9. UI 图从单屏改为多步骤画板
“视频生成的各个环节不是在一个界面完成的，你需要有几步交互，就把每一步的图都生成出来，最好每个交互图最后按顺序罗列在一个画板上”
教师批注：这是交互表达 prompt。它指出了一个常见 AI UI 图错误：把完整流程塞进一个屏幕。真正的设计应该表达状态之间的转换，而不是只做一张漂亮总览。
时间线
docs/，把工具产物如 .gstack/ 从项目叙事里剥离。
docs/README.md 做索引，AGENTS.md 记录工作约束，产品、研究、设计都进入 docs/。
.DS_Store 和冗余临时导出，完成首个 commit。
关键时刻
转折点：5 个关键帧不是正确的 MVP 单位
- 问题
- 5 个关键帧如果各自生成视频，成本和等待会膨胀；如果只服务一次视频调用，扩展分镜交互又没有足够产品价值。
- 重要性
- AI 视频产品最怕“界面单位”和“生成成本单位”不一致，用户会觉得流程不透明，系统也难以控制成本。
- 处理
- 改为 1-3 个核心分镜组。每组可扩展，且每组生成一个短视频片段，再拼接为最终作品。
关键发现：用户需要先确认故事世界
- 问题
- 直接进入视频生成会让用户不知道系统是否理解自己的故事、人物和场景。
- 重要性
- 私人故事产品的信任感来自“这像我的记忆”，不是模型直接给结果。
- 处理
- 把输入后的第一阶段改为“剧本、人物资产、场景资产确认”，确认后才进入分镜和视频。
架构判断：Shanyin 是内部系统，不是前台产品
- 问题
- Shanyin 的九列分镜和专业流程对生成链路有价值，但普通用户不应操作这些表格。
- 重要性
- 这决定 StoryCam 面向普通用户，而不是专业生产团队。
- 处理
- 将 Shanyin 转译为内部 prompt、shot group、节奏规划和质量检查；前台只说“这一段会这样拍”。
协作判断：设计交接需要收敛，而不是铺满资料
- 问题
- 早期设计资料过多会造成阅读负担，设计师反而不知道从哪里开始。
- 重要性
- 原型阶段需要高信号输入：一页 brief、一个流程图、几个关键约束。
- 处理
- 删除多余线框和导出，保留单一设计文档和多步骤 UI flow board。
关键决策表
| 方案 | 当时看起来的好处 | 为什么放弃或保留 | 最终选择 |
|---|---|---|---|
| 单一“暗恋韩剧雨夜” demo | 容易讲清楚产品魔法，设计和视频样例集中。 | 过窄，无法支撑“私人小剧场相机”的泛化定位。 | 保留为固定样例，但产品定位扩展为更泛私人故事相机。 |
| 默认 5 个关键帧 | 直观，像视频生成前的导演锚点。 | 与视频调用次数、用户确认和片段边界不对齐。 | 放弃，改为 1-3 个核心分镜组。 |
| 一次视频调用生成完整 10-15 秒作品 | 流程简单，等待和状态管理较少。 | 用户无法逐段确认，也削弱扩展分镜的意义。 | 改为每个核心分镜组生成一个片段，再建议拼接。 |
| 暴露 Shanyin 九列分镜给用户 | 专业、结构完整，适合调试和内部生成。 | 普通用户理解成本高，会把产品变成生产后台。 | 作为内部数据和 prompt 方法，不作为主 UI。 |
| 完整设计交接包 | 信息全面，覆盖页面、状态、组件和参考图。 | 过重，不符合当前“拿去做详细原型”的启动需求。 | 收敛为一个实际文档和一张 UI flow board。 |
| 单屏 UI 总览图 | 视觉上完整，能一次展示很多模块。 | 误导真实交互，视频生成不是在一个界面完成。 | 改为按步骤排列的多屏画板。 |
可复用方法
AI 生成产品的“单位对齐”检查法
检查四个单位是否一致：用户理解的对象、UI 操作对象、模型调用对象、成本结算对象。StoryCam 中最终对齐到“核心分镜组”。
可迁移用法：做任何 AI 生成产品时，都问一句：用户点的东西，是否就是系统生成、计费、重试和确认的东西？
先确认世界，再生成结果
对于私人、创意、情绪类产品，不要直接让模型出最终结果。先给用户确认故事、人、场景或约束。
可迁移用法：把黑盒生成拆成“理解 -> 确认 -> 生成”，能显著降低用户对结果偏差的不适。
外部参考的“内部化”方法
不要把参考项目的 UI 和术语直接搬给用户。先提取方法，再翻译成适合当前产品的交互和文案。
可迁移用法：专业工具可以成为内部引擎，但前台语言必须服务目标用户。
设计交接的最小可行动包
早期设计交接只需要：一个清楚文档、一张流程图、一个固定样例、几个不可违反的约束。
可迁移用法：先给设计师一个能开工的北极星，再逐步补设计系统，不要一开始堆满资料。
用用户反馈纠正 AI 图表达
第一张 UI 图把多个阶段挤进一个界面，用户指出这不符合真实流程，于是改成多步骤画板。
可迁移用法：生成式视觉稿要验证“它解释的交互是否真实”，而不只是看起来高级。
项目记忆沉淀法
把产品结论、设计输入、外部参考和 agent 规则放到项目目录，而不是散落在聊天或工具缓存里。
可迁移用法：每个关键 session 结束时都问：哪些结论需要进 docs，哪些只是临时产物？
工程证据
Git / Commit
- Branch:
main - Commit:
aee450a Initialize StoryCam product docs - PR: 未创建
- Checks: 未运行 / 未记录
- Deploy: not run
文件变更
.gitignore：忽略.gstack/、.DS_Store。AGENTS.md：记录项目工作规则和生成链路。docs/README.md：文档索引。docs/product/storycam-film-machine-design.md：产品设计基线。docs/design/storycam-ui-design.md：单一设计输入文档。docs/design/assets/storycam-ui-flow-board.png：当时保存的 UI flow board 路径；当前项目可视化证据路径见上方图片。docs/research/shanyin-director-master/：Shanyin 参考快照。
命令证据
git init / git branch main git add .gitignore AGENTS.md docs git commit -m "Initialize StoryCam product docs" git log --oneline --decorate -1 # aee450a (HEAD -> main) Initialize StoryCam product docs
本 session 没有 API key、token、cookie、完整 DSN、签名 URL 或 provider 原始 payload；也没有真实线上部署结果。
后续事项
已完成
- StoryCam Web-first 产品方向确认。
- 核心生成链路从关键帧改为核心分镜组。
- Shanyin 参考项目落入项目研究资料。
- 单一设计文档和 UI flow board 形成。
- 首个产品文档 commit 完成。
待确认
- 默认生成 1、2 还是 3 个核心分镜组。
- 最终 UI 风格：深色电影工作台还是更轻的编辑台。
- 拼接第一版是否真实剪辑，还是先顺序合成。
- 主视觉海报是否独立生成，或由最佳分镜承担。
- 当前项目中 UI 图路径是否统一到最新 docs 目录。
后续开发
- 将 UI flow board 转成可点击 Web 原型。
- 定义
DirectorPacket、核心分镜、扩展分镜、clip prompt packet。 - 做 Seedance 2.0 生成 spike：从固定样例生成 1-3 个片段。
- 设计视频生成队列、失败重试、片段状态机和资产存储。
- 补充 CI、部署、监控和发布流程；本 session 尚未覆盖。