一次拍摄，同时出横版和竖版：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 都可能不成立。我接受这个结果。做工具型实验的意义就在于此：用最小的成本，尽早换到一个明确的「行或不行」。

横竖同拍这个痛点是真的，但「真痛点」不等于「真生意」。中间那一步，得用产品自己去问。