有人用 Rust 重做 Adobe 七件套：PhotoCraft、FilmCraft 到 EffectCraft，開源創作工具開始挑戰 Creative Cloud

如果只是做一個「長得像 Photoshop」的軟體，2026 年其實已經不是特別稀奇的事情。

真正困難的是另一件事：

你能不能打開使用者十年前留下來的 PSD？能不能正確處理 CMYK、Lab、ICC Profile？Premiere 類軟體剪了一個兩小時專案後，時間軸會不會逐漸 drift？PDF 裡面的日文直排、透明度、字型與表單還能不能活著？

最近在 Reddit、GitHub 與開源社群中受到注意的 Crafting Apps，野心恰好放在這一層。

這不是單一 Photoshop clone，而是一整組試圖重新建立 Adobe Creative Cloud 核心工作流程的開源專案。目前公開的家族包括 PhotoCraft、VectorCraft、FilmCraft、LightCraft、PrintCraft、EffectCraft 與 DesignCraft，分別對應影像編輯、向量繪圖、影片剪輯、RAW 相片處理、PDF、Motion Graphics / VFX 與桌面出版。

更特殊的是，它們共同選擇了同一條技術路線：Rust、Native、Clean-room implementation，以及 Agent-ready architecture。

這讓 Crafting Apps 不只是另一批免費 Adobe 替代品，而更像是一場很大的軟體工程實驗。

從 Photoshop 到 After Effects，這次不是只做一套

以目前各專案公開的 GitHub 資訊來看，Crafting Apps 家族大致可以這樣理解：

PhotoCraft：Photoshop 類型的影像編輯器，包含 Layer、Mask、Adjustment Layer、Layer Style、Type、Vector、Brush，以及 PSD / PSB 讀寫。

VectorCraft：Illustrator 類型的向量繪圖工具，包含 Bézier Path、Pen Tool、Pathfinder、Gradient Mesh、Artboard 等工作流程。

FilmCraft：Premiere Pro 類型的 NLE，也就是 Non-linear Editing 非線性影片剪輯器，包含多軌 Timeline、Source / Program Monitor、Color、Audio、Effects 與 Export。

LightCraft：Lightroom 類型的相片管理與 RAW Developer，主打非破壞式處理、wide-gamut 與 32-bit float pipeline。

PrintCraft：Acrobat 類型的 PDF workbench，可以閱讀、整理、合併、分割與保護 PDF。

EffectCraft：After Effects 類型的 Motion Graphics / VFX compositor，包含 Composition、Layer、Keyframe、Expression、3D Camera、Light 與 Render Queue。

DesignCraft：桌面出版與 Page Layout，定位接近 InDesign 工作流程。

有趣的是，Crafting Apps 官方總覽頁目前仍主要展示五套工具，但 GitHub repositories 與個別產品頁已經能看到 EffectCraft 與 DesignCraft，顯示整個專案仍處在快速擴張階段。這也代表讀者不應把現在看到的產品清單當成完全固定的成熟產品線。

最大特色之一：不是 Electron，而是 Rust Native

近年很多新創桌面軟體其實是一個 Web App 加 Electron 外殼。

這條路的優點很明顯：React、JavaScript、CSS 都能快速開發，而且跨平台成本低。但影像、影片、VFX 與 RAW 處理不是一般生產力 App。

當畫面進入：

• 數百個圖層
• 16-bit / 32-bit 浮點影像
• 4K、8K 影片
• 即時 GPU compositor
• 數百 MB 到數 GB 的 PSD
• RAW sensor data
• color transform
• timeline playback

CPU、記憶體配置與 GPU 資料搬移成本就開始變成非常實際的問題。

PhotoCraft 因此使用 Rust 建立 native application，並以 wgpu 對接 Metal、Vulkan、DirectX 12 與 WebGPU。開發團隊還使用 256 × 256 sparse tiles、Copy-on-write，以及 multithreaded filters，目的就是避免每次修改圖片時複製整張高解析度 canvas。

這是一個很典型的影像軟體問題。

假設你正在編輯一張 12000 × 8000、32-bit RGBA 圖片，如果所有操作都粗暴地複製完整 framebuffer，Undo Stack 很快就可以把記憶體吃到令人開始懷疑人生。

Tile-based architecture 則把影像拆成許多小區塊，只儲存真正變化的 tile。Copy-on-write 進一步讓不同 document state 可以共享沒有改變的資料。

這種架構比「畫面看起來像 Photoshop」重要得多。

PhotoCraft 最重要的東西，其實是 PSD

對專業影像工具而言，最可怕的敵人往往不是 Filter，而是檔案格式。

PSD 已經累積了數十年的歷史包袱。

Layer、Mask、Text、Smart Object、Blend Mode、ICC Profile、Adjustment Layer、16-bit、32-bit、CMYK、Lab……一個真正的 Photoshop 替代品必須面對大量 legacy behavior。

PhotoCraft 官方目前宣稱，它能夠讀寫 PSD 與 PSB，並支援 RGB、Grayscale、CMYK、Lab，以及 8、16、32 bits per channel。

更值得注意的是，它還自己實作了 ICC color management，包括 Assign Profile、Convert to Profile、rendering intent、black point compensation、soft proofing 與 GPU gamut warning。

這些功能不是普通使用者每天都會摸到，但對印刷、攝影與專業設計工作而言極為重要。

PhotoCraft 開發團隊甚至宣稱，在 135 個真實 PSD 測試檔中，有 134 個可以做到 byte-for-byte round trip。

這個數字非常亮眼，但必須特別強調：

這是專案開發者自行公布的測試結果，目前不應直接當成第三方獨立驗證。

真正的測試仍然會是：把它丟進全球設計師累積二十年的 PSD 墳場，看究竟有多少檔案不會長出奇怪的幽靈圖層。

FilmCraft 更瘋：連 Codec 都想自己做

FilmCraft 的方向甚至更激進。

一般影片剪輯器很常直接依賴 FFmpeg 處理 Codec，這很合理，因為 H.264、HEVC、AAC、ProRes 這些影音格式的實作難度極高。

然而 FilmCraft 公開資料宣稱，它的 H.264、HEVC、ProRes 與 AAC codec 是從公開規格重新以 Rust 實作，而不是內嵌 FFmpeg。

它同時使用 GPU compositor，而且 timeline frame math 採用 exact integer time。

這個小細節其實非常重要。

影片不是單純的「時間 = 3.14159 秒」。

你可能遇到：

23.976 fps、24 fps、25 fps、29.97 fps、59.94 fps，以及 Drop-frame timecode。

如果內部時間系統長期使用不恰當的 floating-point representation，不斷切割、重新定位與累積之後可能產生 rounding error。

因此專業影音系統常把時間建模成整數 tick 或 rational representation，而不是單純拿 float 表示秒數。

FilmCraft 特別強調 exact integer time，代表開發者確實注意到了真正 NLE 才會遇到的工程問題。

EffectCraft 則直接碰 After Effects 的地獄級問題

如果 Photoshop clone 已經很難，那 After Effects 類軟體又是另外一個次元。

EffectCraft 目前公開的功能包含 Composition、Shape、Text、Footage、Nested Composition、Null、Adjustment Layer、Camera、Light、Parenting、Track Matte、Motion Blur、38 種 Blend Modes，以及多種類型 Keyframe interpolation。

官方資料目前甚至列出 306 種 effects。

它還支援 Lottie import / export，並將 project 儲存為可讀的 versioned JSON .ecproj。

這個設計其實很有意思。

Adobe 專業軟體長期存在一個典型問題：project file 通常不是非常適合 Git diff 的資料格式。

如果 EffectCraft 真正把專案內容完整結構化成 deterministic JSON，那麼 Motion Design workflow 理論上可以出現：

Git commit
↓
查看 keyframe / property 修改
↓
branch
↓
merge
↓
CI render

這會讓影像創作工作第一次更接近傳統 Software Engineering workflow。

當然，JSON 可 diff 不代表動畫專案就突然變得很好 merge。兩個人同時修改同一個 Composition，還是可能製造非常漂亮的 Git 地獄。

但至少資料不再完全是一個 opaque binary blob。

真正有趣的伏筆：MCP

Crafting Apps 還有另一個非常 2026 年的特色：它們不是先做好 GUI，再想辦法補 AI。

相反地，許多核心操作一開始就被設計成 Command。

例如 PhotoCraft 的操作可以透過 UI、CLI、JSON control channel，甚至 MCP server 控制。

EffectCraft 也採用類似架構。

因此：

Human UI
      │
CLI ──┼── Command Engine
      │
MCP ──┘

AI Agent 並不是用 Computer Vision 猜『這顆按鈕可能是 Blur』，而可以直接執行真正的 command。

例如未來一個 Agent 可以做：

開啟素材
↓
建立 Composition
↓
建立 Text Layer
↓
設定 Position Keyframe
↓
套用 easing
↓
加入 Glow
↓
輸出 H.264

而不是拿滑鼠在 GUI 上進行一場機器版大家來找碴。

這種 architecture 對 AI workflow 的意義甚至可能比「免費 Photoshop」還大。

因為 Adobe、Blender、Figma、3D DCC、CAD 與遊戲引擎接下來都會面對同一個問題：

軟體到底應該讓 AI 操作 GUI，還是直接把內部能力變成 machine-readable commands？

後者顯然穩定得多。

LightCraft：RAW 開發真正難的是顏色

LightCraft 則暴露另一個常被忽略的專業軟體問題：Color Science。

RAW 不等於一張還沒壓縮的 JPEG。

相機感光元件輸出的 Bayer / X-Trans 資料，需要經過 demosaic、white balance、color matrix、tone mapping、noise processing、highlight reconstruction，以及輸出色彩空間轉換。

LightCraft 宣稱整套 develop pipeline 採用 scene-referred、wide-gamut、32-bit floating point processing。

Scene-referred 的概念，可以理解成盡量讓內部數值描述「場景光線本身」，而不是一開始就把資料壓成螢幕最終顯示的樣子。

這能保留更大的 highlight 與 grading 空間，也是近代 HDR 與高階色彩工作流程常見的概念。

官方也宣稱整套工具完全以 Rust 建構，而且明確禁止直接閱讀 Adobe binary 或從 darktable、RawTherapee、LibRaw、rawspeed、dcraw 等 GPL 或既有 RAW 專案複製程式碼。

這正好進入 Crafting Apps 最關鍵的一個詞：Clean Room。

Clean-room implementation 到底是什麼？

Clean-room implementation 並不是：

「把 Photoshop decompile，看看裡面怎麼寫，然後換變數名稱。」

正好相反。

其基本思想是：

公開規格
+
公開文件
+
外部可觀察行為
↓
重新設計
↓
全新 implementation

開發者避免接觸 proprietary source code、shader、asset、preset 或其他受保護的內部實作。

EffectCraft 例如明確表示，其行為依據 After Effects 公開文件與軟體可觀察行為建立，不使用 Adobe code、icon、preset 或 asset。

PrintCraft 則主要依據 ISO 32000 PDF specification 與 black-box observation。

這種方法在軟體史上並不陌生。

真正困難的是，『相容』往往不是照規格做完就結束。

成熟軟體經過十幾、二十年發展後，會累積大量：

• undocumented behavior
• legacy behavior
• bug compatibility
• historical file quirks
• third-party plugin assumptions

有時候一個 bug 活得夠久，就會進化成 specification。

所以 clean-room 專案最大的挑戰，往往不是第一年，而是接下來五年不斷遇到世界各地使用者丟進來的奇怪檔案。

PrintCraft 就已經開始用 corpus 打仗

這也是 PrintCraft 最有趣的一點。

它不是只用幾個自己建立的 PDF 做 demo。

專案目前宣稱會跑 pdf.js 的測試 corpus，983 個測試 PDF 中有 963 個能正常開啟與 render，而且沒有 crash；其中 958 個可以完成 open、edit、save round trip。

輸出另外會使用 hayro、qpdf 與 poppler 進行驗證。

這仍然是專案方自行公布的測試結果，但這種 corpus-driven engineering 才是建立 document compatibility 比較可靠的方法。

因為 PDF 世界非常髒。

你真正要處理的不是：

Hello World.pdf

而是：

1998 年某政府機關建立
↓
2007 年被重新儲存
↓
2013 年加入表單
↓
2020 年數位簽章
↓
內嵌一個早已消失的字型
↓
然後使用者問：為什麼你打不開？

這才是 document software 的真實世界。

為什麼 Rust 很適合這種軟體？

Rust 並不會神奇地讓 Photoshop clone 自動變快。

Algorithm 錯了，Rust 一樣可以寫出一台很高速的垃圾車。

但它確實有幾個特性非常適合 Creative Software。

第一是 Memory Safety。

Image、Video、Codec、Parser 都需要大量處理不可信 binary data。傳統 C / C++ 專案中，buffer overflow、use-after-free 與 pointer error 長期都是安全風險來源。

Rust 的 ownership 與 borrow checker 可以消除大量這類錯誤。

第二是 Native Performance。

它沒有 garbage collector stop-the-world pause，對 frame rendering、video playback 與 interactive editing 很重要。

第三是 Concurrency。

影像 filter、tile rendering、video decoding、asset processing 天生非常適合平行化，而 Rust 的 type system 能降低 data race 風險。

第四是 WebAssembly。

Crafting Apps 多個專案同時宣稱可以將 engine 與 UI compile 到 WebAssembly。

這就產生一個很有趣的可能性：

同一個 engine
├── Windows
├── macOS
├── Linux
└── Browser / WASM

不用重新維護完全不同的 Web implementation。

但現在距離「Adobe Killer」還非常遠

看到這裡最容易出現的標題，大概是：

Adobe is doomed.

然而目前這樣寫並不合理。

PhotoCraft 官方自己就仍然把狀態標示為 Early Alpha。

Crafting Apps 其他工具也有不少還處於 early development。

真正的 Adobe 生態護城河也從來不只是『功能數量』。

Adobe 有：

• 數十年的檔案相容性
• Plugin ecosystem
• Font workflow
• Adobe Fonts
• Dynamic Link
• Camera profiles
• Color workflow
• Enterprise deployment
• Print industry integration
• Training ecosystem
• Agency workflow
• Template marketplace
• 第三方硬體與軟體整合

一間大型設計公司的問題不是：

『這個軟體有沒有 Pen Tool？』

而是：

『我把去年客戶留下來的 400GB project 打開，會不會爆？』

這是一個完全不同量級的 reliability requirement。

真正值得觀察的不是 Adobe，而是 Creative Software 架構

Crafting Apps 最值得注意的地方，可能反而不是它能不能擊敗 Adobe。

它展示了一種很新的桌面創作軟體 architecture：

Native Rust Engine
        ↓
Deterministic Command System
        ↓
GPU Rendering / Codec / Document Core
        ↓
GUI
CLI
JSON
MCP
WASM

傳統軟體通常是：

GUI
↓
Business Logic

AI 出現之後，這個模型開始反過來。

如果核心軟體本身就是 machine-controllable engine，那 GUI 只變成其中一種 client。

使用者可以操作它。

Script 可以操作它。

CI 可以操作它。

AI Agent 也可以操作它。

這可能才是 Crafting Apps 真正值得關注的地方。

開源創作工具正在進入第二階段

過去提到開源 Adobe 替代品，通常會想到 GIMP、Krita、Inkscape、Blender、Kdenlive、Darktable。

它們已經證明開源工具可以做到極為成熟。

Crafting Apps 則代表另一種方向。

它沒有試圖重新教育使用者一套完全不同的操作哲學，而是直接問：

如果保留大家熟悉的工作流程，但把底層重新用現代語言、GPU 架構、Command Engine 與 AI interface 做一遍，會發生什麼？

目前答案仍然只是 Alpha。

甚至可以說，最危險的戰鬥還完全沒有開始。

因為把介面做出來只是第一關。

真正的 Boss 是那些散落在全球硬碟裡、累積二十年歷史、沒有人知道裡面到底裝了什麼的 PSD、PDF、RAW、MOV 與專案檔。

如果 Crafting Apps 有一天真的能讓這些檔案安靜地打開、修改、儲存，再交還給 Adobe 軟體而什麼都沒有壞，那才是這場實驗真正開始變得危險的時候。

Tech English｜本文技術名詞

Clean-room Implementation｜潔淨室實作：不使用原始產品的專有程式碼，而依公開規格、文件與可觀察行為重新實作相容軟體的方法。

Copy-on-write, COW｜寫入時複製：多個狀態先共享相同資料，只有某份資料真正被修改時才複製，可大幅降低影像編輯與 Undo 所需的記憶體。

Scene-referred Pipeline｜場景參照處理管線：盡量以真實場景光線關係表示影像資料，而非過早壓縮成螢幕輸出值，常見於 RAW、HDR 與專業色彩處理。

GPU Compositor｜GPU 合成器：使用 GPU 將不同 Layer、Effect、Mask、Transform 與影像資料即時合成為最終畫面的引擎。

Round Trip Compatibility｜往返相容性：檔案在 A 軟體開啟、修改與儲存後，再由原軟體重新讀取，仍能保持原有結構與內容的能力。

Model Context Protocol, MCP｜模型上下文協定：讓 AI Agent 以結構化方式呼叫外部工具與軟體能力的協定，可避免只能靠模擬滑鼠與 GUI 操作應用程式。