bgxiong-ai-story) 项目的整体代码量如下：这是一个中大型桌面应用项目，采用 Tauri 2 框架构建，具备完整的 AI 故事创作功能（包括角色管理、剧集/场次/分镜管线、文生图/图生图/视频生成等）。
「全部场次 + 点场次」与「选集 + 点同一场次」读写同一 storyboard_graph_state 键：(project_id, episode_id=剧集节点 id, chapter_id=场次节点 id)。
不需要兜底、不考虑历史兼容：可删除/收紧依赖 __all__ / STORYBOARD_SCOPE_ALL 的故事板前端路径；遗留库中仅 __all__ 键下的 graph 行可视为可丢弃（不迁移）。
以项目最优解落地：单一解析函数 + 全链路同一 episodeId，避免双轨。
场次节点已有 chapter_id（剧集 id）：list_nodes_by_type scene 分支 LEFT JOIN edges ... contains → source_node_id as chapter_id。
当前缺口：StoryboardTab 中 sceneGraphEpisodeId 在未选集时落到 STORYBOARD_SCOPE_ALL，与「选集」下的真实 episode_id 分裂。
新增小工具（例如 ui/src/domain/storyboardEpisodeScope.ts）或内联 useMemo：
// 语义：显式选集 > App 传入的 chapter > 当前场次所属剧集
resolvedStoryboardEpisodeId =
(activeChapterId?.trim() ||
chapter?.id?.trim() ||
activeScene?.chapter_id?.trim() ||
"");StoryboardTab：sceneGraphEpisodeId 改为上述 resolvedStoryboardEpisodeId（不再 || STORYBOARD_SCOPE_ALL）。
无场次：不加载 graph（现有逻辑已处理）。
有场次但 resolved 为空：视为数据损坏/孤儿场次 — 不兜底：toast 固定文案（如「场次未关联剧集，无法加载故事板画布」），loadStoryboardGraph / save 不调用；与「不要兼容」一致。
以下必须使用同一 resolvedStoryboardEpisodeId（从 StoryboardTab 下传或从 App 用相同公式计算，避免分叉）：
位置 | 调整 |
|---|---|
|
|
|
|
|
|
| |
与垫图/场次上下文一致：传 | |
|
[sceneStoryboardChildNodes.ts](d:/00Dev/bgxiong-ai-story/ui/src/domain/sceneStoryboardChildNodes.ts)删除 episodeId 默认值 STORYBOARD_SCOPE_ALL；改为调用方必传 已解析 的剧集 id。
若 episodeId 为空：直接返回 [] 或 throw（二选一；推荐返回 [] + 上层 toast，避免未处理异常）。
[storyboardGraph.ts](d:/00Dev/bgxiong-ai-story/ui/src/domain/storyboardGraph.ts)：STORYBOARD_SCOPE_ALL 若仅故事板 graph 使用，可删除并全量替换；若 片段画布等仍用 __all__（见 [types.ts](d:/00Dev/bgxiong-ai-story/ui/src/components/segment-canvas/types.ts)、App Clips），则保留常量但 故事板模块禁止再引用。
[useStoryboardSceneGraph](d:/00Dev/bgxiong-ai-story/ui/src/components/storyboard/hooks/useStoryboardSceneGraph.ts)：移除仅用于 __all__ 回退的 import/拼接。
[storyboard_graph::normalize_scope_id](d:/00Dev/bgxiong-ai-story/src-tauri/src/storyboard_graph.rs)：对 load_storyboard_graph_state / upsert_storyboard_graph_state 的入口，若 trim 为空则 Err 而非写入/读取 __all__（需同步改 [commands/storyboard.rs](d:/00Dev/bgxiong-ai-story/src-tauri/src/commands/storyboard.rs) 三处 normalize_scope_id）。
风险：仅当保证前端永远传非空剧集 id 时安全；否则 Tauri 命令会报错（符合「严格」）。
文档注释：chapter_scene_board_pipeline.rs 1388 行附近 更新为「episode_scope_id 必须为剧集节点 id，与前端一致」。
不编写迁移合并 __all__ → 真实剧集：旧行自然废弃。
可选（本地开发）：手动删 storyboard_graph_state 中 episode_id='__all__' 的行；不作为代码交付必选项。
选集 A → 选场次 S → 改画布 → 切「全部场次」→ 再点 S：布局与节点与选集时一致。
从未选集路径进入：仅点 S（activeScene.chapter_id 有值）：同上。
清除场次或孤儿场次：resolved 为空时行为符合预期（不静默读 __all__）。
引入 resolvedStoryboardEpisodeId 解析并接入 StoryboardTab + 所有子 hook / API 参数。
更新 App.refreshStoryboardShots 与 sceneStoryboardChildNodes（去默认 __all__）。
删除故事板路径上对 STORYBOARD_SCOPE_ALL 的依赖；保留或收缩常量定义。
（可选）后端 normalize_scope_id 对空串改为 Err + cargo check。
手动回归两条路径 + npm run build / 相关 ReadLints。
基于 Rust + WebGPU 的技术栈是目前高性能跨平台开发（Native + Web）的最前沿方案。对于追求性能和系统稳定性的开发者来说，这套组合几乎是“终极形态”。
以下是这套技术栈的核心构成及入门路径：
在 Rust 社区中，wgpu 是 WebGPU 规范的旗舰级实现。它不仅能让代码运行在浏览器中，还能直接调用 Windows (Direct3D 12)、macOS (Metal) 和 Linux (Vulkan) 的原生驱动。
wgpu-rs (核心库)： 提供安全的 Rust 绑定。
WGSL (WebGPU Shading Language)： 官方指定的着色器语言，语法类似 Rust，易于上手，且避开了 GLSL 的历史包袱。
naga (着色器翻译器)： 负责将 WGSL 翻译为底层 API 能理解的指令。
这套方案之所以强大，是因为它解决了两个痛点：内存安全与跨平台统一性。
如果你准备从零开始构建一个高性能工具（例如 AI 图像处理或视频滤镜引擎），可以参考以下配置：
UI 层： egui 或 iced。这两个库在 Rust 生态中非常流行，且都完美支持 wgpu 后端，适合快速构建跨平台工具界面。
窗口管理： winit。这是 Rust 处理窗口、输入事件的事实标准。
数学运算： nalgebra 或 glam。后者专门为图形学优化，性能极佳。
Web 部署： wasm-bindgen。将你的 Rust 逻辑打包成 WebAssembly。
对于本地 AI 推理，你可以利用 WebGPU 的计算着色器 (Compute Shader) 直接对张量进行并行运算。
模型转换： 将模型权重的二进制数据映射到 GPU 的 Storage Buffer。
并行计算： 在 WGSL 中编写计算内核（Kernel），实现类似矩阵乘法 (GEMM) 的操作。
零拷贝： 借助 Rust 的高效内存布局，减少 CPU 与 GPU 之间的数据交换延迟。
环境配置： 确保 Rust 环境已更新，安装 cargo。
克隆 Demo： 到 GitHub 搜索 gfx-rs/wgpu 仓库，查看其 examples 文件夹。里面有从简单的三角形渲染到复杂的计算着色器应用。
学习 WGSL： 如果你熟悉 Rust，你会发现 WGSL 的语法非常亲切。
小贴士： 由于你可能处理大量资源或追求极高性能，建议在开发时开启
wgpu的验证层（Validation Layers），它能帮你捕捉到 90% 以上的非法显存访问错误。
以下是 WebGPU 当前发展的关键维度：
WebGPU 1.0 在 2023 年发布后，经历了两年的高速迭代。
引擎全面转向： Three.js 和 Babylon.js 等主流 Web 图形引擎已经将 WebGPU 作为首选后端。相比 WebGL，WebGPU 在处理复杂场景（如数万个独立对象的渲染）时，CPU 开销降低了约 80%。
原生级性能： 借助 WebAssembly (Wasm) 和 WebGPU 的深度集成，现在的 Web 应用可以实现接近原生桌面软件的图形表现。这使得云端视频剪辑、高级调色工具和复杂的 3D 设计软件（如 Web 版 CAD）在性能上几乎没有短板。
WebGPU 与 WebGL 最大的区别在于其强大的通用计算能力。
端侧 AI (On-device AI)： 这是 WebGPU 发展最迅猛的领域。由于其提供了对现代 GPU 特性（如共享内存、原子操作）的访问，诸如 WebLLM 和 Transformers.js 等项目可以让大语言模型（LLM）和 Stable Diffusion 直接在用户的本地 GPU 上运行，无需上传数据到服务器。
视频处理加速： 对于视频后期从业者而言，WebGPU 允许在浏览器内进行实时的 4K 视频滤镜处理、AI 降噪和自动抠图，其效率是传统 JavaScript 或 WebGL 无法比拟的。
多端统一： 截至 2026 年，Chrome、Edge、Safari 和 Firefox 的稳定版均已全面支持 WebGPU。它在底层完美映射了系统的原生 API（如 Windows 的 Direct3D 12、macOS 的 Metal、Linux 的 Vulkan）。
移动端爆发： 随着高性能移动芯片的普及，手机端的 WebGPU 支持也已趋于成熟，网页端手游的品质已经开始向主机级画质靠拢。
FP16 与精度优化： 现在的 WebGPU 已经广泛支持 半精度浮点数 (FP16)，这对 AI 推理至关重要，能在减少显存占用的同时提升一倍的运算速度。
子组操作 (Subgroups)： 这一高级特性的加入，使得开发者可以更精细地控制 GPU 线程间的通信，进一步压榨硬件性能。
对于开发者（尤其是熟悉 Rust 或 C++ 这种底层语言的人）来说，WebGPU 极大地拓宽了 Web 的边界。你不再受限于简单的网页交互，而是可以直接开发高性能的跨平台桌面应用（通过 Electron 加速）或高性能的 Web AI 工具。