ArtCraft（storytold/artcraft）：把「提示词抽卡」改造成可控的创作流水线——Rust/Tauri 桌面、62 模型目录与异步 Omni API 拆解

一、导读

当所有人都在比谁的模型更强时，ArtCraft 押的是另一个方向：把不可控的「提示词抽卡」变成可复现的「创作工程」。它用 Rust + Tauri 写了一个桌面创作 IDE，把 62 个图像/视频/音频/3D 模型收进同一个界面，再用一条异步 Omni API 把生成能力开放给外部流水线。当日涨星 2,510，是 2026-10-08 日榜中唯一合规且站内未发布的大模型应用项目。

二、项目速览

项目	详情
仓库	storytold/artcraft（GitHub API，数据获取日 2026-10-08）
主语言	Rust（桌面内核）+ TypeScript/React（前端）
Star / 当日涨星	7,621 / 2,510（GitHub Trending daily，2026-10-08）
Fork / Watch / Open Issues	1,046 / 46 / 73
License	NOASSERTION——实际为自定义「fair source」协议（见第八节）
首次创建 / 最新提交	2022-03-31 / 2026-10-07
最新版本	artcraft-v0.41.0（2026-09-26，共 8 个 Release）
仓库体量	文件树 7,237 个文件，约 1.3 GB
模型目录	62 个模型（图像 16 / 视频 25 / 音频 5 / 3D 网格 11 / 世界与高斯泼溅 5）
分发	getartcraft.com（Windows/macOS 预编译）；Linux 需源码构建

三、为什么是它：问题背景与定位

痛点：生成式视觉的瓶颈已经从「画得像」转移到「控得住」。 纯提示词工作流的致命伤是不可复现——同一个角色要在三个镜头里保持同一张脸、同一个房间要在不同机位下保持同一套光照，靠改提示词是做不到的。更现实的问题是模型碎片化：图像用 FLUX、视频用 Veo、3D 用 Hunyuan、音乐用 Suno，创作者被迫在四五个网站之间来回搬运素材，每个网站一套账号、一套计费、一套导出格式。

定位：不是模型，是「创作 IDE」。 官方措辞是「The IDE for artists」——把 prompting 变成 crafting。这个类比是认真的：IDE 提供的是结构、调试与精确操作，对应到视觉创作就是空间摆放、图层合成与场景调度。它把「先想清楚画面长什么样，再生成」当作核心主张，而不是生成完再祈祷。

涨星动因。 一是同门兄弟的虹吸效应：同一组织在 2026-09-30 至 10-01 集中放出 7 个「Adobe 替代品」仓库（PhotoCraft ★26,159、LightCraft ★5,323、FilmCraft ★5,119 等），整个 org 41 个仓库累计 60,165 星，ArtCraft 作为其中唯一的「生成式 AI」成员被顺带带火；二是多模型聚合的真实需求——把 62 个模型收进一个本地界面，直接命中「不想开五个网页」的痛点；三是Rust/Tauri 的技术叙事，在 Electron 泛滥的创作软件里显得稀缺。

四、【重点】架构原理

4.1 整体架构：桌面内核 + 云端生成服务，两仓分离

ArtCraft 是双仓库架构：storytold/artcraft 是 Tauri 桌面应用（Rust 内核 + React 前端），storytold/artcraft-services 是后端（HTTP API、后台 Worker、Web 前端）。桌面端负责创作、合成与本地状态，云端负责模型调用、计费与素材存储。

┌── 桌面端 storytold/artcraft（Tauri 2）──────────────────────────┐
│  React/TS 前端（Nx + Vite）                                     │
│   ├─ 2D 画布 / 3D 场景 / 图层合成 / 角色摆姿                    │
│   ├─ frontend/libs/{omni-gen, model-list, state, components}    │
│   └─ 通过 Tauri IPC 调用 Rust 内核                              │
│  Rust 内核（crates/）                                           │
│   ├─ desktop/artcraft        应用主壳、任务库（SQLite）         │
│   ├─ api_clients/*           11 个 Provider 客户端              │
│   ├─ lib/*                   缓存、Cookie、文件、JWT、错误      │
│   └─ schema/*                SQLite 任务表、枚举、令牌          │
└──────────────┬──────────────────────────────────────────────────┘
               │ HTTPS（Omni API / 会话 API）
               ▼
┌── 云端 storytold/artcraft-services ─────────────────────────────┐
│  storyteller-web（Rust + Actix Web + Tokio）                    │
│   鉴权 → 校验 → 计费 → artcraft_router → 提交 Provider         │
│  artcraft_router  跨 Provider 适配请求与成本估算                │
│  Workers          轮询任务 / 拉回结果 / 生成视频缩略图          │
│  存储：MySQL+SQLx · Redis · Elasticsearch · S3/R2               │
└─────────────────────────────────────────────────────────────────┘

官方给出的后端数据流是：客户端 → storyteller-web → artcraft_router → 生成 Provider；完成通过 Provider webhook 或轮询 Worker 回收，结果下载进对象存储、注册为 media file 并关联任务；客户端轮询任务状态端点，再从 CDN URL 取素材。

4.2 分层模块拆解

层	职责与关键接口
前端表现层	Nx + Vite 工作区，frontend/libs 下 14 个库：omni-gen（生成逻辑）、model-list（模型目录）、state（Zustand 状态）、components（编辑器与生成控件）、tauri-api（原生命令绑定）
Rust 内核层	crates/desktop/artcraft 是应用主壳；crates/schema/database/sqlite_tasks 存本地任务库；.sqlx/ 缓存查询元数据，支持 SQLX_OFFLINE=true cargo check -p artcraft 无数据库编译
Provider 客户端层	crates/api_clients/ 下 11 个独立客户端：artcraft_*、fal_client、gmicloud_client、grok_api_client、grok_consumer_client、kinovi_web_client、midjourney_client、openai_sora_client、worldlabs_api_client、worldlabs_consumer_client——每个上游一个 crate，互不污染
路由与适配层	artcraft_router 是核心：把统一的生成请求翻译成各家 Provider 的私有格式，并做成本估算；这是「62 个模型一个界面」能成立的关键
服务层（云端）	storyteller-web 承担鉴权、账号、素材上传与库、生成请求、任务状态、点数与 Stripe 计费；crates/service/job 是后台 Worker
数据层	MySQL+SQLx（账号/素材元数据/推理任务/钱包/账单）、Redis（缓存/限流/进度）、Elasticsearch（搜索索引）、S3 兼容存储或 R2（上传素材与生成产物）

模型目录的组织方式也值得一看。 62 个模型按能力分五族：图像 16 个（Nano Banana 系 3 个、GPT Image 系 4 个、FLUX 系 4 个、Seedream 系 5 个）、视频 25 个（Seedance、Kling、Veo、Sora、Vidu、MiniMax、Flux 七族）、音频 5 个（Suno 系 4 个 + Seed Audio）、3D 网格 11 个（Hunyuan 3D 系 8 个、Tripo3D、Meshy、Rodin）、世界与高斯泼溅 5 个（Marble 系 4 个 + TripoSplat）。目录里还标了两种状态：† 表示当前禁用，‡ 表示受限模型（桌面端不可用）——把「不可用」显式写进目录，比让用户点了才发现失败要诚实得多。Provider 侧则是五种接入形态并存：ArtCraft 自有、Grok、Midjourney、Sora、World Labs；官方称 Kling、Google、Runway、Luma 在计划中，并有意支持 OpenArt、Freepik 这类聚合器以复用用户已有订阅。

4.3 核心机制：异步任务模型与双 API 面

ArtCraft 的生成接口分成两套语义：面向应用的 /v1/omni_gen/* 走用户会话，覆盖图像/视频/音频/网格/泼溅；面向程序的 /v1/omni_api 走 API Key，只开放图像与视频生成、素材上传与任务轮询。API Key 形如 artcraft_api_ + 40 位 Crockford base32（共 53 字符），认证头支持 Bearer / Key / 裸值三种写法，且明确忽略 Cookie。

生成是异步的，这是整个设计里最值得注意的取舍：

# 1) 提交任务，拿到 inference_job_token
curl -s -X POST https://api.storyteller.ai/v1/omni_api/generate/video \
  -H "Authorization: Bearer $ARTCRAFT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "seedance_2p0",
    "prompt": "An Atlantic puffin stands on a windy cliff edge...",
    "duration_seconds": 6,
    "aspect_ratio": "wide_sixteen_by_nine",
    "idempotency_token": "'"$(uuidgen)"'",
    "start_frame_image_url": "https://example.com/frame.jpg"
  }'

# 2) 轮询直到终态
curl -s https://api.storyteller.ai/v1/omni_api/job_status/job/$JOB_TOKEN \
  -H "Authorization: Bearer $ARTCRAFT_API_KEY"

几个硬性契约：idempotency_token 必填且每次必须是新 UUID，复用会被判重拒绝；URL 输入与 media-token 输入互斥，同时传会直接报错；参考视频只接受 mp4，传 .webm 返回 400；重定向最多跟随 10 跳。任务状态机里 pending/started/attempt_failed 需继续轮询，终态是 complete_success、complete_failure、dead、cancelled_by_user、cancelled_by_system；成功时成品地址在 state.maybe_result.media_links.cdn_url，视频任务额外提供静帧与动图预览。错误码语义也写得很直白：401 = Key 无效或持有者被封，402 = 点数不足。

为什么坚持异步？ 视频生成的耗时量级决定了同步接口不可行——官方文档示例里的任务从提交到完成跨越了约 11 分钟（created_at 04:06:14 → maybe_successfully_completed_at 04:17:30）。若做成同步 HTTP，客户端要么超时要么长时间占用连接。异步 + inference_job_token 的代价是调用方必须自己实现轮询循环与终态判断，官方为此提供了 bash / Python / JavaScript 三份可复制示例，并把「哪些状态要继续轮询、哪些是终态」列成明确清单。这个取舍与 ArtCraft 整体的产品哲学一致：把复杂度从交互层挪到契约层，用显式文档替代隐式魔法。

另一条主线是**「先摆场景，再生成」：Image-to-Location 建立可复用的物理环境，Character Posing 先定姿势与机位，Character Identity Transfer 用摆好姿势的人偶当作「简易 3D ControlNet」（官方原话），把姿态从「提示词解释问题」变成显式控制信号**。这是它区别于纯提示词工具的技术内核。

4.4 性能优化与设计取舍

官方在 docs/performance.md 里公开了一份可复现的前端性能实验（2026-09-26，Apple M4 Pro / macOS arm64 / Chrome 153.0.8010.53 / Node 24.13.0，每组 7 个样本取中位数）：

指标	优化前	优化后	降幅
启动到首帧	566.40 ms	350.60 ms	38.1%
刷新到首帧	248.60 ms	198.10 ms	20.3%
启动 JS 体积	9.05 MB	6.47 MB	28.6%
启动长任务合计	336.00 ms	184.00 ms	45.2%
首次打开绘图页到首帧	120.90 ms	118.20 ms	2.2%（视为未变）
绘图 → 首页 dispatch	23.40 ms	9.00 ms	61.5%
首页 → 绘图 dispatch	42.10 ms	18.80 ms	55.3%
首页 → 绘图到首帧	105.70 ms	86.50 ms	18.2%

三条改动带来这些数字：① MainApp.tsx 原本在启动时 import 所有编辑器，改为 15 个页面走 React.lazy + Suspense（绘图页仍保持 eager，因为实测延后它反而让首开更慢）；② TabState.ts 原本在离开时把绘图场景导出成 JSON、返回时再导入，现在直接保留存活的 Zustand store——实测往返零次图片文件读取，选中节点保留，撤销历史长度保持 1 而非涨到 2；③ 移除启动时调用 getGPUTier() 的无用 React state，省掉一次启动期 WebGL 上下文请求。

取舍也写得很诚实：外壳仍加载约 6.47 MB JS；返回已填充画布仍需约 86 ms；TaskQueue.tsx 每 5 秒轮询并重建任务数组（空队列下测不出成本）。文档还明确声明这些数字不包含原生进程启动、WKWebView/WebView2、Rust、磁盘启动与真实生成延迟，且「本地测量是前端工作量下降的证据，不是对每台机器相同百分比收益的预测」。

4.5 与其他架构路线的差异

与 ComfyUI 类节点图：ComfyUI 把模型与采样器暴露成图，能力上限更高但要求用户理解扩散管线；ArtCraft 把复杂度收进 3D 场景与图层，面向的是「会用 Photoshop 但不懂 CFG」的创作者。与模型聚合网站：聚合站只解决「一个入口调多个模型」，ArtCraft 的 ROADMAP 把「比聚合站更有用」列为第一目标，差异在于它同时提供合成、摆姿与本地状态。与闭源 SaaS：ArtCraft 桌面端是本地应用，但生成仍走云端——ROADMAP 里「移除对 ArtCraft 托管服务的依赖」被明确列为架构目标，说明当前架构是过渡态。

4.6 生态与商业化

商业模式是「工具免费、生成收费」。 Crafting Apps 系列本身不产生收入，ArtCraft 通过 AI 图像与视频生成所需的点数收费；同时明确允许用户自带算力或使用外部服务账号，不强制走官方通道。这种「软件免费 + 推理计费」的结构解释了为什么许可证要禁止「用其代码开发竞争性产品」——代码是获客入口，推理才是收入来源。

生态上走的是「一源多应用」路线。 同一 org 下 41 个仓库构成一个松散的创作套件：PhotoCraft（图像）、VectorCraft（矢量）、FilmCraft（视频剪辑）、LightCraft（RAW）、PdfCraft（PDF）、EffectCraft（特效）、DesignCraft（排版），2026-10-07 又新增 WordCraft、CadCraft、GridCraft、SoundCraft、DeckCraft。值得注意的是这些兄弟仓库多为 Apache-2.0，而 ArtCraft 本体是自定义协议——同一套件内许可证并不统一，选型时需逐个核对。

社区渠道齐全但深度有限：Discord、YouTube、X、LinkedIn 均有官方账号，README 提供多语言版本；但 Watch 仅 46、贡献者仅 3 人，说明社区目前更像「围观者众、共建者少」。ROADMAP 把「建一个没有负能量与反 AI 污名的安全社区」单列一节，也侧面反映出生成式创作工具面临的舆论环境。

五、【重点】应用场景

场景一：分镜预演与角色一致性（官方主场景）

痛点：导演要在一个室内场景里排三场戏，希望三个机位下房间光照一致、主角是同一张脸。纯提示词每次重生成环境，一致性无从保证。 做法：用 Image-to-Location 先把环境「钉死」，再用 Character Posing 摆好虚拟演员与机位，最后才生成。

# 桌面端：Windows/macOS 从 getartcraft.com 装稳定版
# Linux 需源码构建：
git clone https://github.com/storytold/artcraft.git && cd artcraft
./script/artcraft/unix_dev.sh        # 前端 + Rust/Tauri 一起起

收益与量化：一致性来自复用同一份场景状态而非重复提示词——环境与角色身份是显式资产，可跨镜头反复引用。 边界：官方自己标注 Scene Blocking、Canvas Editing、Scene Relighting 等仍处 preview 阶段；这套流程面向「产品级视觉产出」，不建议用于需要严格可审计的医疗影像或工程制图。

场景二：把生成能力接进自己的流水线（Omni API）

痛点：内容团队要批量产出短视频，人工在网页上一个个点不现实；而各家模型 API 格式、鉴权、轮询方式都不一样，接入成本极高。 做法：统一走 Omni API，用 idempotency_token 保证重试不重复扣费，用批量状态端点一次查多个任务。

import uuid, requests, time
BASE, KEY = "https://api.storyteller.ai", "artcraft_api_xxx"
H = {"Authorization": f"Bearer {KEY}"}

r = requests.post(f"{BASE}/v1/omni_api/generate/video", headers=H, json={
    "model": "seedance_2p0",
    "prompt": "A puffin on a windy cliff at sunrise",
    "duration_seconds": 6,
    "aspect_ratio": "wide_sixteen_by_nine",
    "idempotency_token": str(uuid.uuid4()),
    "reference_image_urls": ["https://example.com/a.jpg"],
}, timeout=240).json()

TERMINAL = {"complete_failure", "dead", "cancelled_by_user", "cancelled_by_system"}
while True:
    s = requests.get(f"{BASE}/v1/omni_api/job_status/job/{r['inference_job_token']}",
                     headers=H, timeout=30).json()["state"]
    st = s["status"]["status"]
    if st == "complete_success":
        print(s["maybe_result"]["media_links"]["cdn_url"]); break
    if st in TERMINAL:
        print("failed:", st); break
    time.sleep(5)

收益与量化：一次接入覆盖 62 个模型——换模型只改 model 字段，鉴权、轮询、素材托管全部复用。批量端点 GET /v1/omni_api/job_status/batch?tokens=... 支持一次查多任务。 边界：API Key 需向官方申请开通（账号默认没有 API Keys 分区）；生成必须联网，离线不可用；402 表示点数不足，需先充值。

场景三：让 AI Agent 直接操作创作软件（MCP）

痛点：Agent 能写代码却改不了一张图——它没有可调用的图形操作接口。 做法：Crafting Apps 系列支持命令自动化编辑，并提供 MCP 机制让 AI 与外部工具互通，Agent 可直接调用编辑功能（媒体口径，见 technews.tw 2026-10-07 报道）。

收益与量化：把「批处理」从脚本层提到语义层——Agent 可以按「把这三张图的背景都换掉」这种意图驱动，而不必逐个像素操作。 边界：MCP 支持的具体工具清单与协议细节未在 artcraft 主仓 README 中给出，属待确认；且相关能力主要在兄弟仓库（PhotoCraft 等）中，ArtCraft 本体定位是生成而非编辑。

场景四：多模型比价与成本控制

痛点：同一个镜头，Seedance 2.0 和 Veo 3.1 的报价可能差几倍，创作者缺乏统一比价手段。 做法：/v1/omni_gen/cost/* 与 /v1/omni_gen/models/* 无需用户会话即可查询模型发现与成本估算；artcraft_router 在服务端统一做成本计算与钱包扣费。

收益与量化：成本估算与模型发现免鉴权可查，便于在提交前先比价；计费在服务端统一，避免各家账单口径不一。 边界：点数由 ArtCraft 定价，具体单价未在公开文档中列出，属待确认；若坚持「零边际成本」，应改用自带算力或外部服务账号（官方明确支持这两种方式）。

场景五：本地创作、云端生成的数据边界

痛点：素材涉及未公开的商业企划，不想把原始工程文件交给第三方。 做法：桌面端是本地 Tauri 应用，创作工程、图层、3D 场景与本地任务库（SQLite）留在本机；只有提交生成时上传的素材与提示词会离开本地。

收益与量化：工程资产本地化——.sqlx 缓存与 _database/sql/artcraft_migrations/ 表明任务库是本地 SQLite，可离线打开与整理。 边界：生成环节仍走云端（api.storyteller.ai），并非全本地推理；ROADMAP 把「移除对托管服务的依赖」列为目标，说明当前版本做不到纯离线生成。

六、快速上手

环境：Rust 工具链、Node.js（官方文档称 v24.13.0 可用，要求 20+）、Tauri CLI（文档称 2.10.0 可用）。

# macOS / Linux：一条命令同时起前端与 Rust/Tauri
./script/artcraft/unix_dev.sh
ARTCRAFT_DEV_PORT=6200 ./script/artcraft/unix_dev.sh   # 换端口

# Windows
.\script\artcraft\windows_frontend_dev.ps1
.\script\artcraft\windows_rust_dev.ps1

# 只校验启动器，不编译 Rust
node --test frontend/scripts/unix-dev.test.mjs

启动器把 Vite 绑到 127.0.0.1，从 5193 端口起逐个试到可用，且不动已有监听；只有真实前端 socket 绑定成功后才用该 devUrl 启动 Tauri。Rust 改动走 cargo tauri dev 的重建并重启应用（不保留未保存的内存状态），前端改动走 Vite 热更新。

七、横向对比

维度	ArtCraft	ComfyUI	模型聚合网站	闭源 SaaS（Runway 类）
定位	创作 IDE（合成 + 生成）	节点式扩散管线	多模型统一入口	端到端生成服务
模型数	62 个（跨 5 家 Provider）	取决于自装模型	数十个	自有模型
控制手段	3D 场景 / 图层 / 人偶摆姿	节点图 + ControlNet	仅提示词与参数	机位与区域提示
上手门槛	中（面向设计师）	高（需懂管线）	低	低
本地工程资产	是（Tauri + SQLite）	是	否	否
生成位置	云端（ROADMAP 计划去依赖）	本地	云端	云端
开源	源码可见（自定义 fair source）	是	否	否
主要成本	点数计费，或自带算力/账号	自有 GPU 成本	各家订阅	按量付费

选型一句话：要可控且可复现的视觉产出 → ArtCraft；要极致自定义与本地推理 → ComfyUI；只想一个入口调多个模型 → 聚合站更轻；要最省心的成品 → 闭源 SaaS。

八、局限、风险与社区观察

一、许可证是最大的隐性风险。 GitHub 把 License 标为 NOASSERTION（无法归类）。实际 LICENSE.md 开头就写着「这不是一份真正的法律许可证，我们会尽快处理」——属于自定义「fair source」协议。允许免费使用、备份、修改、编译用于个人私密用途，且生成素材归你所有；但明确禁止：商业销售 ArtCraft 软件本身、用其代码开发竞争性业务或产品、fork 后移除社区/捐赠链接或付费模型服务、未经许可使用其名称/logo/吉祥物。这意味着它不是 OSI 开源协议，企业商用前必须逐条评估。

二、贡献高度集中，是典型的「单人/小团队」项目。 GitHub API 只列出 3 位贡献者（echelon 16、bflatastic 2、tanish2k09 1），Watch 数仅 46，与 7,621 星形成明显反差。社区讨论（Hacker News id=49958850）转述作者曾宣称「软件已死，我一击做完了整个 Photoshop」「一个月内达到 100% parity、11 月 5 日 7 个应用 99% 功能对齐」，随后又在 HN 上承认尚未准备好、需要社区贡献 bug 与 PR，被部分评论者批评为炒作与消耗社区热情。

三、实测口碑两极，且争议点不在功能清单而在「手感」。 HN 讨论中有人称发布版「非常破碎」——文本选择、文字编辑、面板展开折叠、快捷键、移动对象、性能等基础操作失败；也有人称较新版本基本可用，能打开照片、捏合缩放，菜单与部分功能接近 Photoshop/Photopea，但历史/图层面板仍不支持、Windows 图标不工作。评论的共识颇具参考价值：Photoshop 不是普通像素编辑器，而是包含手感、响应、笔刷动态、工作流、色彩管理与插件生态的「媒介」，像素级测试捕捉不到其核心体验；有评论估算 AI 能快速做出 95% 的外观与原型，但打磨细节需要数月到数年。

四、媒体转述的自评数字需谨慎对待。 有媒体（kocpc.com.tw）转述团队自评功能完成度 75%、「手感」仅 40%；另有媒体称 7 个应用一周内收获 22,044 星、代码约 55 万行、由 2 人在 4 周内完成、使用 Claude Opus 5.5 生成。以上均为媒体/社区口径，未经官方仓库文档确认，标注为待确认。

五、正面信号同样明确。 仓库当日（2026-10-07）仍在提交；docs/performance.md 提供了带原始 JSON、可一键复现命令、并主动声明测量边界的性能实验，这种工程透明度在同量级项目里少见；ROADMAP 把「移除对托管服务的依赖」「更多 Rust、更快」「更好的测试与 CI」写进架构目标；_docs/dev_setup.md 连「Rust 热重载是进程重启、不保留内存状态」这类细节都讲清楚。此外 IP 争议已有回应：团队强调 PhotoCraft/VectorCraft 是参考公开规格与实机行为自行实现，未使用 Adobe 源码或素材，与 Adobe 无合作关系。

六、平台覆盖与构建门槛不对称。 Windows 与 macOS 有预编译稳定版，Linux 必须源码构建，且官方 README 未给出系统依赖清单；构建需 Rust 工具链 + Node 20+ + Tauri CLI 三者齐备。此外官方文档明确提醒：npm run perf:desktop 需要启动浏览器并绑定回环端口的权限，且绝不使用你常用的浏览器配置、账号或原生应用数据——这类边界声明对评估「能否在受控 CI 环境跑基准」很关键。

九、小结与行动建议

一句话概括：ArtCraft 押注的不是「模型更强」，而是「创作更可控」——它把 62 个模型收进一个本地 IDE，用 3D 场景与图层把提示词抽卡变成可复现的工程流程，并用一条异步 Omni API 把生成能力开放给外部流水线。

1. 先分清你要的是「生成」还是「编辑」。 ArtCraft 本体是生成与合成工具；若目标是 PSD 图层编辑，应看同门的 PhotoCraft（★26,159，Apache-2.0），别买错方向。
2. 商用前必读 LICENSE.md 原文。 它是自定义 fair source 协议，不是 MIT/Apache；「禁止开发竞争性产品」这一条对做创作工具的公司是实质约束。
3. API 接入前先确认 Key 已开通。 账号默认没有 API Keys 分区，需联系官方启用；同时把 idempotency_token 做成每次新 UUID，否则重试会被判重拒绝。
4. 把「点数」当成本变量管理。 生成走云端且按点数计费，官方支持自带算力或外部服务账号；批量场景建议先用免鉴权的 /v1/omni_gen/cost/* 比价再提交。
5. 对「一个月对齐 Adobe」这类声明保持距离。 以 HN 实测反馈为准：早期 alpha 有潜力，但距离专业生产可用仍有明确差距，关键路径上的 preview 功能需自行验证。

资料来源（抓取日期 2026-10-08）：GitHub REST API（storytold/artcraft 元数据 ★7,621 / fork 1,046 / watch 46 / open issues 73 / NOASSERTION / created 2022-03-31 / pushed 2026-10-07 / 7,237 文件 / 8 个 Release，最新 artcraft-v0.41.0；storytold org 41 仓库累计 60,165 星；contributors 接口返回 3 人）；仓库 README.md、ROADMAP.md、LICENSE.md、Cargo.toml、_docs/dev_setup.md、_docs/artcraft_omni_api.md、docs/performance.md（含 performance/2026-09-26-before.json 与 -after.json）；后端仓库 storytold/artcraft-services 的 README.md；GitHub Trending daily（2026-10-08，2,510 stars today）；Hacker News 讨论 id=49958850；technews.tw《Adobe 掰掰？開源免費創作軟體「Crafting Apps」公開》（2026-10-07）；kocpc.com.tw、mydrivers、Yahoo 香港、brightcoding.dev 等媒体报道。「一周 22,044 星」「55 万行 / 2 人 / 4 周」「功能 75%、手感 40%」「使用 Claude Opus 5.5」均为媒体或社区口径，待确认。