為什麼一支 30 秒影片是 OSS 上架最大的槓桿
本篇是「一個人做產品」系列的第 18 / 18 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。
OSS 99% 死於沒人看 —— 而影片是 README 最強的槓桿
不是 code 寫得不夠好——大部分被忽略的 OSS 其實 code 都不差。
是沒有任何元素能在訪客的 10 秒注意力裡傳達「這是什麼、為什麼我該關心」。
而在 README 所有可以放的元素裡，動態影片是最強的槓桿——一次傳達「能用」「使用體驗」「視覺品質」三件事，是其他任何元素都辦不到的。
但做 30 秒產品介紹影片如果不熟要花一整天，熟了也要半天。值得嗎？
這篇從三個角度拼出我的答案：值得。
角度 1：訊息密度的不對稱
README 上每個元素都有它的「訊息天花板」——也就是這個元素最多能傳達多少訊息。
| 元素 | 訊息天花板 |
|---|---|
| Tagline | 「給誰、解決什麼」（1 件） |
| Screenshot | 「視覺品質」（1 件） |
| Features list | 「能做什麼」（1 件，且要讀者逐條讀） |
| Quick Start | 「怎麼裝」（1 件） |
| Video / GIF | 「能用」+「使用體驗」+「視覺品質」（3 件，30 秒內同時） |
差別在訊息密度——影片用同樣的閱讀時間傳達 3 倍的訊息量。
但真正的槓桿不只在「密度高」。真正的槓桿在於：
影片能在讀者腦中產生「我在用這個工具」的具體想像。
Screenshot 是「別人在用」，Features 是「它能做」，影片是「我會怎麼用」。從心理學角度，「我會怎麼用」這個想像就是 star/clone 的最大驅動力——讀者不是因為 code 好而 star，是因為他想看見自己也在用。
角度 2：頂級 OSS 已經達成共識
打開這些 2025/2026 年紅得發紫的 OSS：
- Linear：landing page hero 是 30 秒 demo video（雖然不是 OSS，但行銷模式 OSS 都在抄）
- Cal.com：landing + README 都有 hero video
- Plane.so：README 第一個區塊就是動態 demo GIF
- Excalidraw：README hero 是動態使用 GIF
- Supabase：README 短 GIF + landing 完整 demo video
- Vercel：所有 OSS 工具 README（Next.js, AI SDK…）都有 video 或 high-fidelity GIF
對比那些沒有 hero visual 的 OSS（不點名了，看 GitHub trending 倒數區），普遍特徵：純文字 README、第一個區塊就是安裝指令、tagline 是 “X is a tool that uses Y…”。
這不是偶然——頂級 OSS 行銷團隊投入 N 個小時 A/B 測試的結果。如果你是 indie hacker / solo builder，可以直接抄結論：hero video 是必備，不是 nice-to-have。
角度 3：8 小時換 1 年的 ROI
假設你花一整天 8 小時做 30 秒影片。
這 8 小時的回報是什麼？
- 影片活在 README 至少 1 年（除非產品大改）
- 期間 README 每次被打開都有它——對活躍 OSS，這是上千到上萬次曝光
- 單獨可發：30 秒 MP4 可以發 Twitter / Threads / Reddit / Hacker News，跟 README link 完全不同的擴散管道
- conversion 提升：hero video 把 star / fork conversion 提升 2-5x
先講清楚這個 2-5x 的來歷：它是 OSS 行銷文章裡反覆出現的數字，不是我自己量到的，也不是哪份有對照組的研究——你就當成「常見傳說值」看，別當鐵律。更重要的是它有個前提：這個倍數是乘在「已經有人滑到並點開你 README」上的。對 0 star、0 流量的新專案，2-5x 乘以接近 0 還是接近 0。影片放大的是既有流量的轉換率，不是憑空生出流量。所以這數字對「已經有人來看」的專案才有意義，對還沒人知道你存在的專案，先解決的是怎麼讓人來，不是怎麼讓來的人多按 star。
對比另一個常見的時間投資：寫一篇 8 小時的技術部落格。文章可能拿到 1 次 Hacker News 曝光（如果幸運），3 天後沉底。影片是一年都還在替你工作的資產。
對 indie hacker：8 小時換 1 年的視覺資產 + 社群可分享 demo，是能拿到最高 ROI 的時間投資之一。
不在「能不能」做這件事，而在「想不想接受 8 小時的初期投入」。
但我得補一句，免得這段聽起來像穩賺：這 8 小時對 solo builder 不是免費的。它的真正成本不是「一天」，是「這天沒拿去修 bug、沒做使用者最想要的功能、沒回 issue」——對只有一個人的專案，這才是最稀缺的東西。所以有幾種情況我會勸你先別做影片：
- 產品還在 pre-PMF、核心功能還會大改：影片拍完三週就過時，等於白拍。
- 還沒有任何人在用、零回饋：這時花 8 小時做影片，只是把零曝光包裝得漂亮一點，ROI 很可能是負的。
我自己的門檻是：等 README 開始有一點自然流量、有陌生人真的 clone 來用、issue 區開始冒出不認識的人，再回頭投資影片。在那之前，先去把那個讓人留下來的功能做對。影片是放大器，不是救生圈。
「我的工具不適合做影片」——3 種反論
我聽過幾種版本：
反論 1：「我做的是 CLI 工具，沒什麼好看的」
CLI 工具更適合做 demo。終端機畫面 + 即時輸出有天然的節奏感。
- Asciinema — 錄製 terminal 事件流，純文字、檔案 KB 級別、觀眾可以從 demo 直接複製你打的指令
- VHS — Charm 出的工具，寫一份
.tape指令稿（就像寫 bash），自動產生 GIF/MP4，可重現可進 git - 純錄影：用 tmux + QuickTime 錄終端機畫面
反論 2：「我做的是 library，沒 UI」
讓 code 動起來：
- Carbon 或 ray.so — 美觀的 code 截圖
- Code Hike — 在 MDX 文章裡做 step-by-step code reveal 動畫
- 一個常見模式：用 Remotion 做「3 行 code 解決 X 問題」的動態 demo
反論 3：「我做的是純後端服務」
至少做一張流程圖 GIF：
- 動畫展示 request → process → response 的時間線
- 用 Excalidraw 畫好流程，匯出 SVG，CSS animate
- 用 Motion Canvas 或 Manim 程式化生成數學/系統動畫
簡單說：沒有「不適合做 demo」的工具，只有「沒花時間想 demo 怎麼做」的人。
30 秒影片該講什麼（如果你決定做）
只有 30 秒，講這 3 件事：
- 痛點（5 秒）— 把訪客拉進「我有這個煩惱」的情境
- 解法演示（20 秒）— 工具的關鍵 magic moment
- CTA / 品牌收尾（5 秒）— logo + tagline + GitHub URL
不要嘗試講完所有功能。一支 30 秒影片只能傳達「一個 main value」，其他靠 README 補。
工具選擇：
- 純螢幕錄製：Loom 或 Cap（OSS）
- 高品質敘事：Remotion（React 寫影片）或 HyperFrames（HTML + GSAP 寫影片）
- 純動畫：Motion Canvas 或 Manim
我做 TypeLate 這次用 HyperFrames：30 秒、5 個場景、雙語版（EN + 繁中），完整流程在 《把 30 秒產品介紹塞進 GitHub README 的最後一哩》——那篇也記錄了我做完之後踩到的 GitHub 嵌入雷。
我自己的觀察
老實說：我沒有 hard A/B data 證明 hero video 把 TypeLate 的 star 數推到哪。觀察期太短、變因太多。
但有兩個質的觀察值得寫：
1. 影片本身比 README 文字更有「擴散性」
我做完 30 秒影片後，可以單獨把它發 Twitter / Threads / 社群——這個動作的 reach 是發 README link 的數十倍。一份內容兩用：README hero + 社群 ammunition。
2. 「介紹自己做什麼」的成本大幅降低
之前在群組或 podcast 講 TypeLate，要花一分鐘鋪陳「它是一個 push-to-talk 聽寫工具」。有了 30 秒影片後，貼連結即可。聽眾在 30 秒內理解的程度，比我講一分鐘還深。
這兩個觀察就足以讓我下次也做。對 indie hacker / solo builder 來說，不一定要 A/B 數字證明，幾個質的觀察就夠決定。
TL;DR
OSS 99% 死於沒人看，不是 code 不好。
3 個角度說明為什麼動態影片是 README 最強槓桿：
- 訊息密度：影片同時傳達「能用 + 體驗 + 品質」，其他元素只能一件
- 頂級 OSS 共識：Linear、Cal.com、Plane、Excalidraw、Supabase 都有 hero video，可以直接抄
- ROI：8 小時換 1 年的視覺資產 + 社群可分享 demo
「不適合做影片」？
- CLI → Asciinema / VHS
- Library → Carbon / Code Hike
- 後端 → Excalidraw / Motion Canvas 流程圖
30 秒影片該講：痛點（5s）→ magic moment（20s）→ CTA（5s）。不要塞所有功能。
接下來
決定要做影片了？這個系列剩下兩篇是實作向：
👉 《GitHub README 排版術：把開源專案首頁變成 landing page》 — 影片以外的 5 個 README 元素怎麼排 👉 《GitHub README 動態 demo 的 5 種策略：從 GIF 到自架 CDN》 — 影片做完了，怎麼塞進 README？決策樹
