ArtCraft 2026 路线图刷屏：从创作 IDE 到『开放的 OpenAI』，野心有多大

过去一周，开源社区最不缺讨论度的 AI 创作项目里，ArtCraft 一定排得上号。社区流传的报道口径相当抓人：开发者账号 storytold 在两天内连开七个仓库，分别对标 Photoshop、Illustrator、Premiere 等 Adobe 全家桶成员；随后 CSDN、头条等平台出现了一整批深度拆解文——从 62 模型目录、Rust Cookie 存储与 Cloudflare 防护库，到 Omni API 的调用指南。热度背后真正值得读的，其实是项目根目录那份 ROADMAP.md：它不满足于做"AI 版 Adobe"，而是把目标写成了四个字——Build an Open OpenAI。

本文不做复读机，而是把这份路线图逐条拆开，结合仓库源码验证"开放的 OpenAI"到底有多少工程支撑，最后聊聊它对开源创作生态与闭源大厂的可能冲击。

一、2026 路线图：四条主线 + 一条"更远的目标"

ROADMAP.md 的结构很清晰：2026 年目标（非穷尽）分四条线，再往下是"更远的目标"（Loftier Goals）。

产品线的核心是三条硬承诺：

• "Make ArtCraft better and more useful than model aggregation websites"，即产品定位明确对标模型聚合站，要做"比聚合站更有用"的东西；
• "Add every model and provider into ArtCraft so you can build your own crafting IDE. Nothing will be left out"——模型与供应商覆盖是明确的产品 KPI；
• 为场景定制专用图像模型（场景重打光 relighting、角色/道具重新摆姿 reposing）。

工作室线最像内容公司的宣言：年内产出一部院线发行级别的长片 AI 电影（至少一部），并主办线下聚会、放映与竞赛——注意它的措辞是 "We are creators, and we want to employ more creators!"。

架构线只有三句话，但分量极重：

• Remove dependence on ArtCraft hosted services.（消除对 ArtCraft 托管服务的依赖）
• More Rust, more speed.
• Code cleanup, more/better tests, CI.

社区线则明确要建一个"没有反 AI 污名"的创作者社区——这句话在如今 AI 艺术争议激烈的环境里，本身就是立场。

而 Loftier Goals 原文值得逐字引用：

Build an Open OpenAI / Google / Anthropic. Open models, open platforms, open hardware. Why? Because the future could be bleak without it.

后面还缀着一条戏谑的 "Don't Be Evil™"。注意这里的措辞：不是 "open-source OpenAI"，而是 "Open OpenAI / Google / Anthropic"——开放模型、开放平台、开放硬件。这是一个比"开源模型"大得多的命题，也是全网刷屏的焦点。

二、"开放的 OpenAI"凭什么敢提：源码里的三条证据链

口号可以喊，但 ArtCraft 的底气藏在仓库结构里。根目录 Cargo.toml 的 workspace 有 43 个成员，其中 crates/api_clients/ 下挂着 12 个独立的供应商客户端：ArtCraft 自家（artcraft_api_defs/artcraft_client/artcraft_router）、fal、GMI Cloud、Grok、Grok Consumer、Kinovi、Midjourney、OpenAI Sora、World Labs（API + Consumer）。再加上 crates/lib/ 里一整套支撑库——cloudflare_errors、cloudflare_mitigation、cookie_store、cookie_store_wrapper、jwt_light、browser_emulation——这套组合拳指向一个明确结论：ArtCraft 把"接入任意生成服务"当成了一等公民能力，而不是事后补丁。这与"Add every model and provider"的路线图承诺完全咬合。

证据链一：第三方登录不是"填个 Key"，是原生级的身份桥

很多人以为接入 Midjourney、Grok 就是调个公开 API。但 crates/api_clients/midjourney_client 里藏着真正硬核的部分：credentials/cookie_store_has_auth_cookies.rs 检查 Cookie 存储中是否同时存在认证 Cookie（AUTH_COOKIE_NAME_I 与 AUTH_COOKIE_NAME_R），各端点通过 cloudflare_errors::filter_cloudflare_errors 识别并过滤 Cloudflare 拦截页——也就是说，ArtCraft 需要用 Rust 原生 Cookie 存储 + Cloudflare 规避库去"扮演"一个真实登录态，才能在官方没有开放 API 的平台上替用户跑生成。

桌面端的凭据持久化在 crates/desktop/artcraft/src/core/providers/credentials/payload/web_login.rs：WebLoginData 以带 version 字段的 JSON 落盘，保存 cookies_header、additional_headers、用户名与邮箱。社区热传的"签名 Cookie 从不越过 IPC 边界"正是这套设计的另一面——会话凭据由 Rust 原生层持有与签发，前端 JS 拿到的只是无凭据的抽象结果。

更关键的是请求身份的分流逻辑。在 crates/lib/artcraft_client_identity/src/destination.rs 中，Destination::classify 会根据目标域名决定桌面应用如何自我介绍：打自家 API（api.storyteller.ai 等）时声明 Origin 为 https://desktop.getartcraft.com、User-Agent 为 storyteller-client/1.0；打第三方（Grok、Midjourney、Sora、World Labs、fal、GMI Cloud、Kinovi、Seedance 2 Pro）时则伪装成对应平台的官方站点 Origin。这就是一份可测试的"身份路由表"——它的单元测试甚至覆盖了 evilgrok.com 这类仿冒域名的拦截。开放的代价是工程复杂度，而 ArtCraft 选择用一套带测试的 Rust 层把它扛下来。

证据链二：Omni Gen 与 Omni API——把"全模态生成"变成公共接口

路线图里"所有模型进 IDE"的落地形态，是桌面端 crates/desktop/artcraft/src/core/commands/generate/omni/dispatch.rs 的 Omni 管线：图片、视频、网格、Splat、音频五种模态（Modality 枚举）统一走 /v1/omni_gen/generate/{modality}，响应中的 inference_job_token 与 all_job_tokens 被逐一写入本地 SQLite 任务库（任务表迁移 里的 provider_job_id 唯一索引正是为跨供应商任务去重设计的），并触发 GenerationEnqueueSuccessEvent 通知前端。这套设计意味着：无论背后是哪个模型厂商，对 IDE 而言都只是任务队列里的一个 provider 字段。

更值得注意的，是 _docs/artcraft_omni_api.md 展示的对外 Omni API——这是 ArtCraft 把自家生成管线"平台化"的直接证据：

• 认证方式为 Authorization: Bearer artcraft_api_…（53 字符，40 位 Crockford-base32 随机串），明确拒绝 Cookie，纯 API Key 驱动；
• 请求带 idempotency_token（UUID）防重复提交，支持 URL 直传（图片/视频/音频引用）与 media-token 两种输入形态；
• 生成异步化：inference_job_token 轮询，终态 complete_success 后返回 media_links.cdn_url 成品地址。

把"自家 IDE 里那套生成逻辑"原样开放成可编程接口，等于宣告：模型是插槽，平台是管线，而管线本身对外可编程。这离"开放平台"的宣言已经不远。

证据链三：架构上主动"去中心化"，性能上用 Rust 硬磕

路线图架构线的"Remove dependence on ArtCraft hosted services"不是空话。证据有三层：

1. 供应商矩阵本身就是去中心化：桌面端同时持有 Grok、Midjourney、Sora、World Labs、Kinovi、fal、GMI Cloud 等多个通道，用户可以在多个算力/模型市场之间切换，而非被单一托管方锁定；
2. 本地任务系统：sqlite_tasks crate 与迁移文件表明，任务状态、进度、失败原因全部落在本地 SQLite，重启后仍可恢复——前端订阅信息（frontend_subscriber_id、frontend_subscriber_payload）也一并持久化；
3. 性能工程：docs/performance.md 记录了一次真实优化：启动到首帧从 566.40ms 降到 350.60ms（降幅 38.1%），启动 JS 从 9.05MB 降到 6.47MB，靠的是 15 个编辑器页面改为 React.lazy 懒加载、Tab 切换时放弃整场景 JSON 序列化（零图片文件读取）。配合 AGENTS.md 里"Rust with no minimum supported version""更 Rust 更快速"的取向，这条线指向一个判断：ArtCraft 在为本地优先、可自托管的创作环境攒地基。

所以"开放的 OpenAI"在 ArtCraft 语境里可以被精确翻译成一句话：先做一个不挑模型的开放接入层与可编程生成管线，把"谁家的模型"变成用户可替换的选择，再用本地优先的架构把依赖一点点抽走。它没有能力训练出对标 GPT/Claude 的开源权重（至少目前没有），但它正在搭建一个"模型中立"的创作 OS——这才是它敢对标 OpenAI 的地方，也是它与"开源模型社区"最真实的接驳点。

三、冲击波：开源创作生态与闭源大厂，谁会被动？

对 Adobe 系：被"重写"的不只是工具栏

社区报道里流传最广的说法是 storytold 两天开出七个仓库、用 Opus 5.5 重写 Adobe 七件套。抛开营销夸张，ArtCraft 的真实威胁在于它重新定义了"创作软件的入口"：传统 Adobe 工作流是"工具即流程"，而 ArtCraft 是"场景即流程"——2D 合成、3D 舞台调度（README 中的 Character Posing、Scene Blocking with Kitbashing、Image to Location）、把提示词变成可重复的工艺动作。当生成本身可以被摆姿、打光、分镜精确控制时，"Photoshop 图层"与"Premiere 时间轴"的价值主张就会被逐步稀释。这也是路线图"Build the best tangible computing surfaces where you can mold scenes and videos like clay"的潜台词。

对 OpenAI / Google / Anthropic：模型商品化与"反锁定"

"Open OpenAI / Google / Anthropic"最尖锐的地方在于：它不指望替代这些巨头，而是让它们变得可替换。ArtCraft 的 62 模型目录（16 个图像 + 25 个视频 + 5 个音乐音效 + 11 个 3D 网格 + 5 个世界/高斯溅射，详见 README.md）意味着：今天用 Veo 3.1，明天切 Sora 2，后天换 Kling 2.6，对用户的工作流几乎零成本——模型成了插拔式资源。加上 frontend/libs/model-list 里以 tauriId 归一化模型 ID 的 findModelByKey 机制（kling_1.6_pro 与 kling_1_6_pro 可互相解析），模型"可替换性"已经写进了代码层面。当所有模型在一个 IDE 里等价竞争，供应商的品牌溢价会被压向纯粹的推理成本与质量差异，这正是"开放"对闭源生态最直接的冲击。

对模型聚合站：正面开战

路线图第一条就把矛头指向"model aggregation websites"，并说"我们不喜欢这些网站，只是对自己要求高"。这是产品定位的直接宣战：聚合站只解决"一个入口调多家 API"，而 ArtCraft 要解决的是"在一个创作上下文里无缝调度多家模型"——前者是目录，后者是工作台。社区近期密集出现的"62 模型一网打尽""多供应商集成架构拆解"等文章，恰恰说明这套打法已经形成了认知势能。

必须泼的冷水

其一，Omni API 的"开放"目前仍托管在自家服务上：_docs/artcraft_omni_api.md 明确生产环境是 api.storyteller.ai，API Key 需要人工开通（"Contact the Artcraft team to enable it"）。"Remove dependence on ArtCraft hosted services"仍是路线图中的进行时承诺，而非既成事实。其二，"开放"不等于"开源"：模型权重依旧攥在各供应商手里，ArtCraft 开放的只是接入层与管线；对"Open hardware"（开放硬件）目前甚至没有可验证的工程产出。其三，跨平台登录依赖 Cookie 模拟与 Cloudflare 规避，这类"灰色接入"随时可能被供应商封堵，稳定性存疑（桌面会话回归文档 就记录了 Origin 被 API 拒绝的 400 事故与修复过程）。

结语：野心有多大，验证就有多难

ArtCraft 的 2026 路线图之所以刷屏，不是因为它发布了某个模型，而是因为它提出了一个行业级的命题：当创作 IDE 成为所有模型的公共入口，当生成管线成为可编程的公共 API，"AI 创作平台"的护城河就不再是模型，而是工作流与生态。从 43 个 Cargo workspace 成员、12 个供应商客户端、Omni API 与本地任务系统来看，这套工程骨架是真实存在且可验证的；但"开放的 OpenAI"最终要落到"消除托管依赖、开放模型与硬件"的兑现上。一年之内能不能走到，比口号本身更值得跟踪——而答案，会写在仓库的每次 commit 与每场社区放映里。