一次拍攝，同時出橫版和豎版：Duovid 的產品取捨

一條視頻，兩個平台的麻煩

上週我錄了一段東西，想同時發 B 站和抖音。問題立刻來了：B 站要橫的 16:9，抖音要豎的 9:16。

我手上只有一條橫版素材，於是打開剪輯軟件裁豎版。裁着裁着發現主體跑出了畫面——我説話時身子往右偏了一點，豎版框裏只剩下半張臉。重新調關鍵幀、跟焦點，折騰了二十分鐘。如果反過來先拍豎版再補橫版，左右兩邊又是空的，得重新補背景。

要麼拍兩遍，要麼裁兩遍。兩條路都費時，而且都容易顧此失彼。

這件事我遇到過不止一次，身邊做內容的人也都在重複同樣的動作。它不大，但它真實、高頻、煩人。於是我開始做 Duovid。

它只想做一件事

Duovid 的定位用一句話能説完：一次拍攝，同時產出橫版(16:9)和豎版(9:16)兩路視頻的移動端工具。

（它的前身、也是我並行探索的版本叫 DualViewX、doubleview，名字換過幾輪，想法是一條線下來的。）

不是剪輯軟件，不是創作平台，就是拍攝環節裏把「一次輸入、雙路輸出」這件事做順。橫豎兩個畫框在拍的時候就同時存在，主體始終在框裏，拍完兩個比例都拿到手，不用再回去裁第二遍。

為什麼是這個項目，而不是別的

我手裏能做的想法不止一個。選 Duovid，是因為它符合我給自己定的一條標準：小而可驗證、可變現的工具型產品。

平台型項目聽起來更性感，但對一個獨立開發者太重了——需求驗證週期長、冷啓動難、變現路徑模糊。工具型產品反過來：用户要解決的問題具體，價值能不能成立很快見分曉，付費意願也好測。

我不需要先建一個生態，我只需要回答一個問題：有沒有人願意為「橫豎同拍的結果」掏錢。

這是整件事的靈魂。不是「功能多不多」，是「有沒有人願意掏錢」。

最大的敵人是範圍擴張

獨立開發者最容易犯的錯，我自己也最容易犯的，就是把一個小工具做成大平台。

加濾鏡、加模板、加雲端協作、加賬號體系、加多平台一鍵分發……每一個單看都「有道理」，加完之後產品變重、週期變長，核心價值反而被稀釋，最後兩頭不到岸。

所以我給 Duovid 立了一條紀律：**先驗證核心，持續防止範圍擴張。**在「用户願意為雙路輸出付費」這件事被證明之前，任何平台化能力都先不做。哪怕憋得難受，也先不做。

剋制不是因為我做不出那些功能，是因為現在做它們等於用確定的成本去賭一個還沒驗證的方向。

技術選型：原生 iOS 不是負擔

很多人一聽「原生 iOS」就覺得成本高，默認轉向跨平台。對我不成立。

我在 Mac（Apple Silicon M4）上做 iOS 原生開發，阻力很低：Swift / SwiftUI 寫得順，AVFoundation 處理相機和視頻編解碼是第一方能力，真機調試和 TestFlight 分發鏈路完整。Duovid 的重活恰恰在相機採集和雙路視頻編解碼——這種活，原生鏈路反而最直、最穩，跨平台框架在這層往往要繞一圈、踩一堆坑。

所以原生 iOS 對我是一個真實可選、而且更省事的方案，不是「聽起來貴就放棄」的選項。技術選型要看自己手裏的牌，不看刻板印象。

已經落地的最小閉環

這不是隻停在概念圖上的想法。我已經把核心鏈路拆成幾個可以驗證的工程點：

• 相機預覽裏同時顯示橫版和豎版取景參考，而不是拍完再猜裁切區域；
• 拍照後直接導出橫版和豎版兩份結果，避免用户再進剪輯軟件二次裁；
• 錄像完成後用 AVFoundation 做兩路導出，儘量只做 crop / transform，保留音頻和原始質量；
• 相冊和系統 Photos 打通，結果能直接拿去發佈，而不是隻存在應用內部。

這些細節看起來瑣碎，但它們決定了產品是不是真的能替用户省掉那二十分鐘。Duovid 的驗證重點不是「界面像不像一個相機 App」，而是「從按下拍攝到拿到兩路可發佈素材，中間有沒有多餘動作」。

它還沒成，這些是我沒把握的地方

我不想假裝這事已經成了。它還在驗證期，以下幾點我沒有答案：

• **核心拍攝體驗是否穩定。**雙框同步取景、對焦、防抖，在真實手持場景下順不順，我還在打磨。
• **雙路輸出的質量和同步是否可靠。**兩路視頻在分辨率、幀、聲畫同步上能不能都達標，這是產品成立的底線，也是技術上最硬的一關。
• **最小付費場景能不能講清楚。**用户在哪一步、為什麼、願意付多少——如果我説不清這個，前面所有取捨都是空的。

這三個問題任何一個塌了，Duovid 都可能不成立。我接受這個結果。做工具型實驗的意義就在於此：用最小的成本，儘早換到一個明確的「行或不行」。

橫豎同拍這個痛點是真的，但「真痛點」不等於「真生意」。中間那一步，得用產品自己去問。