ArtCraft 不止一个仓库：拆开 storytold 七件套家族，看开源版 Adobe 怎么分工

2026 年 9 月底，GitHub 上一周内涨势最猛的开源项目之一，是 storytold 账号下的一系列仓库。社区里流传的说法是"一个人、一周、七个对标 Adobe 的软件"——9 月 30 日到 10 月 1 日两天内一口气开了七个仓库，分别对标 Photoshop、Illustrator、Premiere、Lightroom 等桌面创作套件，甚至有人戏称这是"用 Opus 5.5 重写 Adobe 七件套"。但真正的主仓库只有一个：ArtCraft，README 首页上写着"The IDE for artists"。

这件事值得拆开看：家族化发布和单仓库深耕是两种截然不同的开源策略。storytold 的做法是把"全家桶"铺成七个仓库做声量，把真正的技术纵深全部押在 ArtCraft 这一个 Rust + Tauri 的 AI 创作 IDE 上。本文从社区情报出发，对照仓库源码，厘清七件套各自的分工边界，以及 ArtCraft 这个"总装车间"到底在做什么。

七件套家族：谁对标 Photoshop，谁对标 Premiere

先看命名规律。社区对 PhotoCraft 仓库的分析给出了一条重要线索：整个 Craft 系列采用统一的 {Function}Craft 命名，产品名一律 PascalCase（面向用户的 UI、窗口标题、安装包、文档），而 crate 名、二进制名、应用 ID 保持小写，例如 photocraft-* 与 ai.storyteller.photocraft。ArtCraft、DesignCraft、VectorCraft、PhotoCraft 属于同一命名家族，对应关系大致是：

家族仓库	对标对象	形态
PhotoCraft	Adobe Photoshop	纯 Rust 原生位图编辑器
DesignCraft	Adobe Illustrator	矢量设计（家族命名推断）
VideoCraft / 视频线	Adobe Premiere	非线性剪辑（由 ArtCraft 内时间线承接）
Lightroom 线	Adobe Lightroom	照片管理与调色
ArtCraft	全家桶之上的"总装车间"	AI 创作 IDE

关键设计在于，这些仓库不共享代码。PhotoCraft 的规范里明确写道：各 Craft 应用共享的标准与经验放在仓库外的兄弟目录 craftrules，只允许向那里贡献"可复用的经验"，绝不贡献代码。换句话说，家族靠的是约定统一、代码隔离——每个产品保持独立的技术栈演进，避免"全家桶"最常见的病：为了共用代码而互相拖累版本。

PhotoCraft 与 ArtCraft：两套完全不同的"编辑"哲学

这是整个家族里最值得对比的一对，因为它们代表着两种相反的实现路线。

PhotoCraft：纯 Rust、无 webview、Agent 可驱动。 社区情报确认，PhotoCraft 整个项目只用 Rust 编写，不含 JavaScript/TypeScript，不使用 Tauri、Electron 或任何 webview 壳：桌面端是原生 egui/eframe + wgpu，Web 端是同一份 Rust 编译到 WebAssembly（trunk + wasm-bindgen），唯一的 JavaScript 是 wasm-bindgen 生成的胶水。它的目标是 1:1 复刻 Photoshop——相同的菜单、快捷键、行为与文件保真度，同时性能更好。工程规范把"永不崩溃"列为最高优先级：工作区级 unsafe_code = "forbid"，非测试代码禁止 unwrap()/expect()/panic!，输入派生的数字一律视为敌意数据。更激进的是"一切皆命令"：所有用户可见行为都是引擎里的一条 CommandSpec，UI、CLI、控制通道与 MCP 服务器按同一命令 ID 分发——这保证了每个功能都能被 Agent 驱动。

ArtCraft：编排 62 个模型的 AI IDE。 它解决的问题和 PhotoCraft 完全不同。PhotoCraft 是"把已有的图像编辑能力做到极致"，ArtCraft 是"把分散在几十家厂商的生成能力收拢到一个可掌控的工作流里"。看 Cargo.toml 的 workspace 成员就能感受到集成规模：artcraft_api_defs、artcraft_client、artcraft_router、fal_client、gmicloud_client、grok_api_client、grok_consumer_client、kinovi_web_client、midjourney_client、openai_sora_client、worldlabs_api_client、worldlabs_consumer_client——每个 provider 一个独立 crate，外加 cookie 存储、Cloudflare 防护、浏览器仿真等支撑库，总计 40 多个 crate。

模型目录在 README.md 里有完整清单：图像 16 个（Nano Banana 系列、GPT Image 系列、FLUX、Seedream），视频 25 个（Seedance、Kling、Veo、Sora、Vidu、MiniMax、Flux），音乐与声音 5 个（Suno、Seed Audio），3D 网格 11 个（混元 3D、Tripo3D、Meshy、Rodin），世界与高斯泼溅 5 个（Marble、TripoSplat），合计 62 个模型。这背后是 GenerationProvider 枚举的扩展设计：目前枚举了 Artcraft、Fal、Grok、Midjourney、Sora、WorldLabs 等 14 个提供商，并预留了 Higgsfield、Krea、Leonardo、Runway 等未来成员——家族化的"总装车间"本身就是为持续吸纳新提供商而设计的。

两者的分工由此清晰：PhotoCraft 接管"专业像素编辑"这条线，ArtCraft 接管"AI 生成编排"这条线；前者重保真与工程纪律，后者重集成广度与交互密度。它们不竞争，而是覆盖创作链路的两端。

ArtCraft 的"编辑"到底长什么样：13 个 Tab 分支的总装车间

ArtCraft 前端的主入口 MainApp.tsx 是理解整个产品架构的最佳切片。文件注释里写着"The 3D editor (PageScene) is one of the 13 tab branches"——整个应用被拆成 13 个功能分支：

• PageScene：3D 舞台，角色的摆姿、镜头调度、kitbashing 场景搭建（对标影视分镜的导演工作台）；
• PageDraw：2D 画布，图层、抠背、画笔的合成编辑；
• TextToImage / ImageToVideo / CreateAudio：文生图、图生视频、音乐生成；
• Storyboard：分镜脚本；
• PageVideoEditor：时间线剪辑（video-editor 里有完整的 timeline、keyframes、animation 通道模块）；
• ImageTo3DObject / ImageTo3DWorld：图生 3D 对象与世界；
• RemoveBackground、去水印、Angles 等工具页。

这正好解释了"对标 Premiere/Lightroom"的说法为什么成立：Premiere 的能力以时间线剪辑器的形态内嵌在 ArtCraft 里，而不是单独发一个仓库。家族里的独立仓库做"深度对标"，ArtCraft 做"全流程编排"。

值得注意的工程细节：PageScene（3D 编辑器）作为共享库放在 pagescene，文件头注释明确写道"Lib-resident so artcraft Tauri and artcraft-website share the exact same 3D editor UX"——Tauri 桌面端和 Web 端共用同一套 3D 编辑器体验，只有平台适配器不同。这就是家族协同的正向例子：跨仓库不共享代码，但单仓库内部通过 lib 化最大化复用。

家族协同的底层基建：身份、任务、性能预算

一个"开源版 Adobe"家族要成立，除了产品分工，还需要几层共享基建。ArtCraft 仓库给出了三个具体答案：

1. 声明式客户端身份（身份层）。 artcraft_client_identity 定义了桌面端如何向不同目标"自我介绍"：访问自家 API（api.storyteller.ai 等）时，携带 https://desktop.getartcraft.com 的 Origin 与 storyteller-client/1.0 的 User-Agent；访问第三方提供商（Grok、Midjourney、Sora 等）时，则伪装成对方官网的 webview 身份——"known third-party providers get an identity close to their own website, and never ours"。这套身份路由是七件套未来接入外部服务时直接复用的基础设施。

2. SQLite 任务系统（任务层）。 迁移脚本 _database/sql/artcraft_migrations/20250708000000_create_tasks_table.sql 展示了桌面端任务队列的数据模型：tasks 表统一记录 task_status、task_type、model_type、provider 与 provider_job_id——即"哪个提供商、哪个模型、哪个外部任务"的完整映射。无论任务来自 ArtCraft 自家服务还是第三方提供商，都沉淀为同构的本地记录，这是多供应商架构能并行运转的底座。

3. 性能预算（质量层）。 docs/performance.md 记录了 2026 年 9 月 26 日的实测优化：通过把 15 个编辑器改为 React.lazy 懒加载、切换 Tab 时保留活着的 Zustand 场景 store（零图片文件读取）、移除启动期的 WebGL 上下文探测，启动到首帧从 566.40ms 降到 350.60ms（38.1%），启动 JavaScript 从 9.05MB 降到 6.47MB（28.6%）。这意味着把"13 个编辑器"装进一个壳里，必须把按需加载做到极致，否则家族化聚合就会变成启动灾难。

家族化战略的协同与风险

从仓库证据看，storytold 的家族化至少带来了三方面协同收益：

• 声量与注意力的杠杆：七仓库齐发制造了"开源 Adobe 全家桶"的传播叙事，而真正的技术资产集中在 ArtCraft 一个仓库，维护成本可控；
• 技术路线的试验田：PhotoCraft 的纯 Rust 路线（egui/eframe/wgpu + wasm）与 ArtCraft 的 Tauri + React 路线并行，分别验证"原生像素编辑"与"AI 编排"两种范式的极限，两者共享 {Function}Craft 命名与 craftrules 经验池，但互不拖累；
• AI Agent 友好是家族共识：PhotoCraft 的"一切皆命令 + MCP 服务器"与 ArtCraft 的 Omni API（artcraft_omni_api.md，API key 认证、POST /v1/omni_api/generate/video 端点）殊途同归——让创作流程可编程、可被 Agent 驱动。

风险同样真实存在。首先是多仓库心智负担：family 标准散落在仓库之外的 craftrules，新贡献者需要跨仓库理解约定；其次是依赖外部厂商的脆弱性：ArtCraft 的 62 个模型全部托管在第三方 API 上，而 ROADMAP.md 的 2026 架构目标赫然写着"Remove dependence on ArtCraft hosted services"——既要接入所有外部模型，又要摆脱对自家托管服务的依赖，这两件事同时推进本身就是高难度平衡；最后是家族承诺的兑现成本：七件套目前大多处于"在路上"状态，1:1 复刻 Photoshop 的 parity 下限、每个模型的接入质量、跨平台的打包发布，都是长期工程债。

回到开头的问题：开源版 Adobe 怎么分工？答案已经清晰——用七个仓库完成叙事与探索，用一个仓库完成集成与交付。PhotoCraft 们负责把传统创作工具的能力边界推到极限，ArtCraft 负责把 AI 时代的生成能力编排成一套可掌控的"手艺"。家族化能不能走通，最终不取决于开了几个仓库，而取决于 ArtCraft 这个总装车间能否兑现它自己的承诺：让艺术家像导演一样调度场景，让开发者用 API Key 驱动整个创作流水线。