OpenCut 是一個開源影片編輯器，目標覆蓋瀏覽器、桌面和移動端，經常被稱為開源版 CapCut。但當前主倉庫正在從頭重寫，直接克隆 main 得到的是開發中的新架構，並不等於已經穩定可用的正式版。
專案地址：OpenCut-app/OpenCut
快速答案
如果只是想現在剪影片，優先使用官方仍在執行的 Classic 版本；如果想研究新版的 Rust 核心、外掛架構、MCP 和無頭渲染，再搭建主倉庫開發環境。
新版規劃包含：
- 編輯器 API；
- 第三方外掛；
- Web、桌面和移動端共用 Rust 核心；
- 面向 AI Agent 的 MCP Server；
- 自動化批次渲染的 Headless 模式；
- 編輯器內指令碼面板。
這些是正在推進的方向，不應當全部視為當前穩定功能。
本地開發環境
官方使用 moonrepo 的 proto 管理固定版本的開發工具。安裝 proto 後，在倉庫根目錄執行：
|
|
Web 開發服務預設使用 localhost:5173，API 開發服務預設使用 localhost:8787。桌面端使用：
|
|
桌面構建還要參考 apps/desktop/README.md 中的平臺依賴。Windows 使用者尤其要先確認 Rust、系統編譯工具和 WebView 執行環境是否齊全。
為什麼不建議直接拿新版做生產工具
主倉庫 README 明確說明架構仍在設計，暫時沒有準備好接受外部貢獻。對普通使用者而言，可能遇到三類問題：
- 功能入口存在，但儲存、匯出或時間軸行為還會變化；
- 文件和命令隨重寫快速調整；
- 瀏覽器演示能執行，不代表桌面端和移動端已經達到同等穩定性。
因此不要把唯一的影片工程交給開發版本。測試前先備份素材，匯出後重新播放檢查音畫同步、解析度和幀率。
OpenCut 適合誰
| 需求 | 建議 |
|---|---|
| 立即替代日常剪輯軟體 | 先試 Classic 或其他成熟工具 |
| 學習開源影片編輯器架構 | 使用新版主倉庫 |
| 開發影片外掛或自動化 | 關注外掛 API 與 Headless 模式 |
| 讓 AI Agent 自動剪輯 | 等 MCP 和編輯器 API 穩定後再評估 |
Classic 和重寫版怎麼選擇
OpenCut 當前最容易產生的誤解，是把官網能用的 Classic、主倉庫的重寫版和未來規劃混為一談。可以按目標選擇：
只想剪影片
先開啟官方 Classic 版本，用一段可公開的短素材測試匯入、裁切、音訊、字幕和匯出。不要先搭建主倉庫，也不要把唯一工程檔案交給開發版。
想研究原始碼
使用主倉庫，重點閱讀 apps/、Rust 核心和 Moon 任務配置。開發服務可以分別啟動，更適合定位問題，但各模組介面仍可能調整。
想參與外掛或自動化
持續關注 Editor API、外掛架構、Headless 模式與 MCP Server 的實際實現。README 中列出的方向不等於介面已經凍結，正式開發前應檢視對應程式碼、Issue 和 Release。
開發環境準備
執行 proto use 前，應確認以下基礎條件：
- Git 能正常檢出倉庫；
- 作業系統具有編譯 Rust 依賴的工具鏈；
proto命令已加入PATH；- 埠
5173和8787未被佔用； - 桌面端所需 WebView 和系統 SDK 已安裝；
- 磁碟有足夠空間存放依賴和構建快取。
proto use 會按照倉庫中的 .prototools 安裝固定版本工具。不要看到自己已經安裝 Node.js 或 Rust 就跳過，它的目的正是減少開發者之間的版本差異。
分別啟動服務有什麼好處
OpenCut 把 Web、API 和桌面端拆成不同任務：
|
|
排錯時建議開三個終端，分別保留日誌。若頁面打不開，先看 Web 服務；頁面能開啟但專案或素材操作失敗，再檢查 API；只有桌面視窗異常時，最後排查桌面端執行環境。
Web 服務檢查
訪問 http://localhost:5173，開啟瀏覽器開發者工具，檢查控制檯錯誤和發往 localhost:8787 的請求。若請求地址不對，先查本地環境變數與倉庫文件，不要直接把 CORS 關閉。
API 服務檢查
確認 8787 正在監聽，並觀察 API 終端是否有啟動失敗、資料庫初始化或許可權錯誤。埠衝突時先找佔用程序，不要隨意改埠後只重啟其中一個服務。
桌面端檢查
桌面模式通常比瀏覽器多一層原生依賴。Web 版正常而桌面版失敗時，問題多半在系統 SDK、WebView、檔案許可權或打包配置，而不是編輯器介面本身。
測試影片編輯器要看哪些專案
匯入
準備不同編碼和解析度的短素材，至少包含橫屏、豎屏、可變幀率和單獨音訊。記錄哪些格式可以匯入，哪些只是能顯示縮圖但無法播放。
時間軸
測試切割、拖動、撤銷、重做和多軌同步。開發版最容易出現的問題不是按鈕消失，而是操作後時間軸狀態與預覽不一致。
匯出
檢查輸出解析度、幀率、時長、音畫同步和檔案大小。匯出完成並不代表結果正確，應使用播放器完整播放，並用媒體資訊工具核對編碼引數。
專案恢復
關閉頁面或桌面程式後重新開啟，驗證專案是否儲存、素材路徑是否仍有效、撤銷歷史是否符合預期。沒有透過恢復測試前，不要處理長專案。
自託管時的邊界
瀏覽器端影片編輯會消耗 CPU、GPU、記憶體和本地儲存。即使部署在自己的伺服器上，渲染工作也可能發生在客戶端。評估自託管方案時要確認：
- 素材究竟上傳到伺服器還是隻停留在瀏覽器；
- 專案檔案儲存在哪裡；
- 匯出由瀏覽器、桌面核心還是服務端完成；
- 是否存在臨時檔案清理機制；
- 多使用者是否會看到彼此的專案或素材。
不要僅憑“開源”推斷資料一定不離開裝置，仍應讀取實際網路請求和部署配置。
與成熟剪輯軟體比較時不要只看功能表
| 維度 | 實際要驗證的內容 |
|---|---|
| 穩定性 | 長時間編輯、撤銷、崩潰恢復 |
| 格式支援 | 實際匯入與匯出編碼 |
| 效能 | 預覽卡頓、代理媒體、渲染時間 |
| 字幕 | 匯入、編輯、樣式和匯出 |
| 自動化 | API、Headless、批次任務成熟度 |
| 生態 | 外掛、模板、教程和維護速度 |
OpenCut 的未來路線很吸引人，但遷移決策應建立在當前可驗證能力上。
排錯速查
| 問題 | 優先檢查 |
|---|---|
proto 找不到 |
安裝是否完成、終端是否重開、PATH |
moon run 失敗 |
.prototools 是否安裝成功、倉庫分支是否匹配 |
| 5173 無法訪問 | Web 任務日誌和埠占用 |
| 頁面能開但操作報錯 | API 服務、8787 請求和環境變數 |
| 桌面端失敗 | apps/desktop/README.md 與系統依賴 |
| 匯出結果異常 | 素材編碼、渲染日誌和輸出引數 |
常見問題
OpenCut 可以完全替代 CapCut 嗎？
目前不能簡單下結論。基礎剪輯場景可以嘗試，但模板、特效、字幕、素材生態和跨裝置工作流仍需逐項比較。
為什麼倉庫能啟動但不能正常匯出？
先確認使用的是 Classic 還是重寫版，並檢視對應分支和文件。主倉庫的開發服務啟動成功，只說明前後端能執行，不代表所有編輯功能已經完成。
可以用 Docker 一鍵部署新版嗎？
是否存在可用映象和 Compose 配置應以當前倉庫文件為準。開發服務涉及瀏覽器、API 和桌面端，不應把第三方未經維護的映象當作官方穩定部署方式。
OpenCut 的 MCP 現在就能用於批次剪輯嗎？
README 把 MCP 列為重寫方向之一。真正接入前要確認當前程式碼和 Release 已提供可用 Server、工具列表和許可權說明，不能只依據規劃文字配置生產任務。
如何跟蹤重寫進度
OpenCut 主倉庫變化快，判斷某個功能是否可用時，按這個順序查證：
- README 當前狀態說明；
- Releases 中是否有對應版本；
- 程式碼中是否存在實際實現；
- Issue 是否標記限制或已知故障；
- 新版演示站能否完成相同操作；
- 本地檢出版本與文件提交是否一致。
不要只看截圖、路線圖或第三方影片。尤其是 MCP、Headless 和外掛 API，只有出現穩定介面、許可權說明和可重複示例後，才適合圍繞它開發生產自動化。
開發版升級與回退
升級前先記錄當前 Git 提交和 .prototools 解析出的工具版本。若本地有改動，先建立分支並提交，不要直接拉取後讓依賴升級與業務修改混在一起。
推薦步驟：
|
|
隨後分別啟動 Web、API 和桌面任務，重新跑匯入、時間軸、匯出和恢復測試。若新版無法使用，可以回到記錄的提交進行對比，但不要用破壞性 Git 命令丟棄未儲存素材或程式碼。
素材與隱私檢查
測試開發版時使用可公開的短素材，避免客戶影片、人臉、未釋出產品和帶定位資訊的原片。開啟瀏覽器網路面板確認上傳請求和第三方域名；桌面端還要檢查快取、臨時檔案和崩潰日誌是否包含素材路徑。
如果未來啟用 MCP 或指令碼功能，應把編輯器專案、素材目錄和匯出目錄分別授權，不要讓 Agent 預設讀取整個使用者主目錄。
總結
OpenCut 值得關注，但最重要的資訊是“當前正在重寫”。普通使用者應把 Classic 當作現階段入口，開發者則可以用 proto 和 moon 研究新版。等編輯器 API、外掛和 Headless 渲染穩定後，它才更適合進入自動化生產流程。