29 個月年營收破億美金，在 AI 時代打造產品：HeyGen 的聖經心法

在 AI 影片生成領域的獨角獸公司 HeyGen 達成「年營收一億美元」的里程碑之際，其創辦人兼 CEO Joshua Xu 分享了這份文件背後的故事：

「在內部，我們稱之為我們的『聖經』——這個系統指引我們從一百萬美元成長到一億美元的營收。它源自無數次的團隊討論、實驗以及一路走來的經驗教訓… 我們分享它，不是因為它完美，而是因為它確實有效。這就是我們如何交付客戶價值、以比世界變化更快的速度學習，並持續駕馭浪潮的方式。」

在人工智慧（AI）浪潮席捲全球的今天，遊戲規則已經徹底改變。過去那種穩紮穩打、耗時數年的軟體開發模式已然失效，因為技術的根基每隔幾個月就會發生顛覆性的變化。如果你感覺追不上、感到焦慮，或是想知道頂尖團隊如何在這樣的混亂中脫穎而出，那麼這篇文章就是為你準備的。

這不只是一份開發指南，更像是一本經過實戰驗證的「戰時宣言」。它詳細闡述了 HeyGen 如何擁抱不確定性、將其轉化為競爭優勢，並以驚人的速度學習、交付和迭代，在短短 29 個月內將年營收從一百萬美元推升至一億美元。

無論你是產品經理、工程師、設計師，還是任何想在 AI 時代打造卓越產品的創造者，本文提供的思維框架、團隊結構和決策原則，都將帶給你極大的啟發。

原文連結在此：https://x.com/joshua_xu_/status/1978837502787219578

我們如何在不穩定的世界中乘浪而行、快速交付並贏得勝利

目錄

• 我們正在打造什麼
• 前言
• 第一部分：核心哲學
• 第二部分：我們的節奏
• 第三部分：營運原則
• 第四部分：團隊結構與通用原則
• 第五部分：核心產品團隊
• 第六部分：成長產品團隊
• 第七部分：溝通協議
• 第八部分：應避免的反模式
• 第九部分：在戰時取勝
• 結論

簡介

我們正在打造什麼：為每個人實現視覺化敘事

我們的使命是：讓所有人都能輕鬆進行視覺化敘事。

我們將影片分為兩種類型：

1. 溝通型影片 (Communication Videos) — 用於商業簡報、教學、訪談、Podcast、解說影片等。這類影片旨在解釋、告知或溝通。（最適合基於腳本的編輯模式。）
2. 電影級影片 (Cinematic Videos) — 用於高製作水平的廣告、電影、MV、預告片、高端品牌內容等。這類影片旨在感動、啟發或娛樂。（最適合基於時間軸的編輯模式。）

我們的重點是讓溝通型影片的製作普及到每一個人。當我們說「每一個人」，指的是從新手到專家的所有技能水平。我們的產品足夠簡單，任何人都能在幾分鐘內製作出高品質的影片。

前言

為何會有這本文件

傳統的軟體開發模式已死。昔日穩固的基礎如今在我們腳下不斷變動。在 AI 時代，突破性進展每幾個月就會出現一次，昨天的極限變成了明天的標配。

在 HeyGen，我們不對抗這種不穩定性，而是乘浪而行。我們整個開發哲學都建立在駕馭 AI 的進步浪潮之上，而不是去尋找那早已不復存在的穩定技術基礎。

這本書記錄了我們如何思考、打造產品並取得勝利。它為每一位 HeyGen 的團隊成員——工程師、設計師、產品經理——而寫，也為那些想加入我們的人而寫。這就是當基礎不斷變動時我們的工作方式，以及我們如何將這種不穩定性轉化為我們的競爭優勢。

第一部分：核心哲學

我們的核心哲學

「快速行動，並成為絕對的頂尖。駕馭 AI 浪潮，擁抱研究的不確定性，為未來六個月佈局，打造能隨著模型進步而自我升級的彈性產品，且絕不犧牲品質。」

根本性的轉變：從穩固地基到洶湧浪潮

在 AI 時代，我們在沒有穩定技術基礎的情況下運作。每隔幾個月，AI 技術就會發生巨大演變。模型的能力是未知的，且變化迅速。

我們正處於一個世代難逢的技術窗口期。在接下來的 12 個月裡，AI 代表了我們這一代的戰時機遇。我們有機會打造下一個 Google 或 Facebook。機會正在此刻爆發。我們應該將強度調到最高。這就是每個人加入 HeyGen 的原因，也是我們在這裡的原因。

關鍵區別：當我們說「擁抱不穩定性」時，我們指的是底層的 AI 技術基礎——模型、能力、研究突破。我們絕不接受我們的服務正常運行時間、產品質量或用戶體驗出現任何不穩定。即使底層的 AI 技術基礎不斷變化，我們的產品也必須保持堅若磐石的可靠性。

這不是一個 bug，這是我們的機會。我們選擇乘浪而行，而不是逆流而上。

這與敏捷開發有何不同

傳統的敏捷開發假設技術相對穩定，能力可預測。而我們工作的環境中，基礎技術每幾個月就會改變一次。我們的方法擴展了敏捷原則，但優化的是應對技術的不穩定性，而非穩定的迭代週期。

乘浪者的優勢

競爭對手追求穩定的基礎，結果被下一次技術躍進打得措手不及。我們設計的產品能隨著模型進步而自動提升，我們選擇駕馭浪潮，而不是與之對抗。

理解什麼會變 vs. 什麼不變：對我們來說，理解哪些部分可能在短期內改變（模型、能力）以及哪些不太可能改變（用戶工作流程、核心問題）至關重要。我們圍繞著不變的事物來打造產品/系統，同時駕馭模型改進的浪潮。

乘浪機會的例子：

• 情境學習 (In-context learning) vs. 微調 (fine-tuning) vs. RAG 方法的選擇
• 語音模型後處理技術的改進
• 多供應商系統的優化

品質的悖論

我們快速行動的同時，也要成為絕對的頂尖。這看似矛盾，直到你明白：從長遠來看，快速行動讓我們能打造出更高品質的產品，並更快地為客戶創造價值。當競爭對手一個月發布一個功能時，我們已經發布了五個實驗。我們的學習速度是他們的五倍。這種學習的複利效應會轉化為卓越的產品。

快速行動不代表草率地推出功能——它意味著快速交付客戶價值（並快速學習）。速度是為了服務於成為絕對頂尖的最終目標。

特別是對於影片內容，品質是不可妥協的。用戶喜愛產品不是因為其華麗的介面——而是因為它以卓越的品質解決了他們的問題。我們的成功指標是：任何用戶在我們平台上能達到的平均影片品質。

第二部分：我們的節奏

我們的節奏：2 個月的浪潮週期

為什麼是 2 個月？這個週期與模型的升級週期相符，讓我們能夠在保持專注的同時，快速調整策略。

我們的節奏：

• 2 個月路線圖規劃 — 與 AI 進步週期同步。由領導層、技術主管和產品經理（鼓勵設計師參與）深入探討產品回顧與策略。理想情況下，面對面進行以最大化溝通效率，突破雜訊。對我們的表現保持完全透明和坦誠，並根據需要調整策略。
• 6-12 個月策略佈局 — 預測並為下一個重大突破做準備。
• 雙週承諾清單 — 產品和工程團隊共同決定並排定每個團隊承諾交付的具體項目。
• 每日交付 — 改進、功能或實驗每天都在上線。

背後哲學：短週期讓我們與 AI 的發展步伐保持一致。時間長度足以打造有意義的東西，又短到足以在技術格局轉變時迅速適應。

進行乘浪實驗

重要提示：此框架更適用於現有產品和成長領域，對於需要更長探索時間的新功能和研究領域則較不適用。

• 第 1 天：定義假設和成功指標。
• 第 2 天：打造 MVP（真正的最小可行性產品）。
• 第 3-5 天：向部分用戶發布。
• 第 2 週：分析、學習、決定下一步。

好的實驗是：

• 快速的（以天計，而非以週計）。
• 科學且數據驅動的。
• 提供明確信號：繼續、轉向或停止。
• 追求大膽嘗試而非微小調整（我們還沒成熟到需要做細微優化的階段）。

失敗的實驗：

• 大多數實驗都會失敗——這是預料之中的。
• 從失敗中學到東西 = 勝利。
• 失敗了卻沒學到東西 = 真正的失敗。
• 絕不讓實驗拖得太久以至於無法得出結論。

做出浪潮般速度的決策

決策框架：這是單向門還是雙向門？

• 單向門：需要審慎考慮（極少見）。
• 雙向門：由產品經理快速決定，立即測試（常見）。
• 當爭論不休時：問問自己「我們能測試這個嗎？」如果可以，就別再說了，動手實驗。

決策溝通：

• 立即透過 Slack 溝通，明確指定單一負責人及執行時間。
• 團隊間完全透明。
• 分享背景資訊（Context），而不僅僅是計劃。
• 清楚說明每項決策應告知哪些人。

6 個月的水晶球

雖然我們的實際規劃是 2 個月，但我們必須為策略佈局預測 6-12 個月後的未來。這需要：

• 追蹤 AI 研究的突破。
• 理解計算資源的趨勢。
• 預測模型的能力。
• 建立能從未來進步中受益的彈性架構。

在快速行動中管理技術債

核心原則：為彈性和可替換性而建構。

• 建立預期會變動的抽象層（注意：在時機未到時不要過度抽象化）。
• 記錄假設，而非實作細節。
• 積極地為所有東西加上版本控制。
• 設計能隨著模型升級而改進的系統。

技術債的時間分配：

我們的原則是：將償還技術債視為對未來速度的投資。我們鼓勵那些能顯著提升團隊生產力和系統可靠性的技術債償還工作。技術債務的工作應與業務成果和速度提升明確掛鉤。

第三部分：營運原則

1. 速度就是一切（絕不妥協）

新的現實：在 AI 時代，學得最快的團隊獲勝。就這麼簡單。

• 以「天」為單位交付，而非「週」。
• 若有疑問，就發布一個實驗。
• 動力比完美更重要。
• 行動緩慢是唯一不可饒恕的罪過。

實際應用：

• MVP 是用來測試想法的，不是最終產品。
• 「足夠好到可以驗證」勝過「完美但遲到」。
• 先發布不完美版，然後跟進：如果無效就下架，如果用戶在乎就持續改進直到最好。
• Bugs 比不完美的功能更糟（Bugs 會阻礙學習）。

速度是一種態度

速度不僅僅是執行力。它是一種心態。我們不會說「我們等到週一再發布比較安全。」這暴露了缺乏緊迫感、不想更快學習（浪費了 2-3 天的寶貴數據）、薄弱的責任感以及對執行能力的懷疑。這種心態讓我們無法獲勝。贏家會扛起責任、快速交付、學習和適應。

崇尚行動 > 追求完美

如果你總是為了確保自己是「對的」，那你的速度就太慢了。不要害怕犯錯，要害怕學得太慢。

2. 擁抱技術浪潮

別再追求技術的穩定性了，它根本不存在。AI 的基礎每 2 個月就會改變。設計你的產品，讓它能隨著模型的進步而自動提升。建立預期會變動的抽象層。讓你的產品體驗駕馭在 AI 的進步之上，而不是與之對抗。

3. 勇於諫言，決策後全力以赴 (Disagree and Commit)

我們正處於戰時，而非和平時期。每個人都可以貢獻想法和回饋，但決策必須迅速。一旦做出決定，我們就全力以赴，即使我們當初並不同意。因缺乏承諾而導致的策略失誤，比一個可以迅速修正的不完美決策更糟。

4. 透過創新實現用戶價值

用戶喜愛的是能解決問題的產品，而不是漂亮的介面。創新與用戶的喜愛緊密相連。我們創新人們用 AI 創作影片的方式，打造以前不可能實現的神奇體驗。但如果創新不能解決真實的問題，那就一文不值。

新手引導的挑戰：

• AI 產品的性能因用戶技能水平而有巨大差異。
• 我們的責任是：教用戶如何應用（use cases），而不僅僅是介紹功能。
• 成功 = 任何用戶能達到的平均品質。
• 衡量影片品質，而不僅僅是影片的創建數量。

5. 自建 vs. 購買：一個簡單的規則

無論哪種方式能提供最佳的用戶體驗，我們就選擇那種方式。

• 內部自建：虛擬人像影片模型（沒有外部供應商能達到我們的品質標準）。
• 外部供應商：語音（品質夠好，且受資源限制）。
• 沒有個人好惡，只看結果。

第四部分：團隊結構與通用原則

A. 通用團隊結構

所有團隊都遵循相同的核心結構：產品經理 (PM) + 工程師 + 設計師 + 資料科學家

B. 通用角色定義

產品經理 (PM)：總指揮

• 核心職責 (所有 PM)：
  • 決策和優先級設定的主要推動者。
  • 直接與領導層合作制定策略。
  • 掌握每個功能背後的「為什麼」。
  • 協調工程、數據、設計團隊。
• PM 能力：
  • 創建功能性 MVP 和 UX 原型。
  • 為用戶簡化技術的抽象概念。
  • 引領「原型優先」的方法。
• AI 時代的演進：
  • 打造功能性原型，跳過傳統的規格文件。
  • 使用 Figma 設計稿或 UX 原型作為文件。
  • 為尚不存在的能力進行規劃。
  • 非常熟悉市場上所有的 AI 工具，並每天使用它們。

工程師：快速建構者

• 核心職責：
  • 以最快速度建構並執行決策。
  • 提供 PM 可能忽略的技術見解。
  • 為彈性和快速迭代設計架構。
  • 深刻理解問題背後的「為什麼」。
• AI 時代的焦點：
  • 使用 AI 程式碼助理（Cursor, ChatGPT 等）來提升速度。我們行業過去常說「10 倍工程師」。我不確定是否有 10 倍，但有了 AI 程式碼輔助工具，現在每個人的生產力至少是 2 年前的 3 倍。
  • 打造可以演進為正式產品系統的原型。
  • 專注於建構，而非文件。
  • 與 PM 直接合作，進行快速原型開發。

設計師：化繁為簡者

• 主要角色：定義簡單卻卓越的體驗。
• 設計使命：作為一個影片創作工具，我們的設計必須是世界級的。任何低於這個標準的設計都無法讓我們實現「讓所有人都能使用」的目標。因此，我們設計的第一原則就是簡潔。在 AI 中讓某件事「可行」不難，但要讓它在保持高品質的同時又「易於使用」則極其困難。這就是我們設計團隊的主要使命。
• 核心職責：
  • 創建功能性 MVP 和 UX 原型。
  • 將原型精煉成消費級、令人愉悅的體驗。
  • 確保所有功能都與 HeyGen 的產品框架協調一致，建立並維護跨產品的設計標準。
  • 堅持我們的原則：簡單到連阿嬤都會用。
  • 引領簡化工作——如果阿嬤不會用，設計師就要標記出來並修正它。
  • 掌握設計系統，以實現未來開發的一致性和快速迭代。
  • 協助簡化產品行銷。
  • 在驗證後專注於視覺精緻度和體驗一致性。
• AI 時代的焦點：
  • 非常熟悉市場上所有的 AI 工具，並每天使用它們。
• 關鍵原則：設計師專注於驗證後的卓越體驗，而非早期探索，以保持開發速度。他們是「連阿嬤都會用」原則的主要守護者——這是一個根本性的設計挑戰，需要在驗證後應用真正的專業知識。

資料科學家 & PM：分析夥伴

• 資料科學家職責：
  • 指標解釋與驗證：邏輯和定義的真理來源。
  • 統計分析：相關性、因果關係、因果推斷。
  • 建立 PostHog 無法實現的進階實驗指標。
  • 為已確立的產品功能建立機構級儀表板。
  • 需要高階 SQL/Python 的複雜分析。
  • 輕量級資料工程與建模（數據管道、轉換）。
  • 分享資料科學原則和術語字典。
• PM 職責：
  • 熟悉自己領域的頂層指標，能夠識別異常模式並啟動調查。
  • 利用 PostHog 分析工具監控趨勢和使用情況（產品分析、用戶群組、行為）。
  • 從 Hex 主表中提取簡單數據。
  • 主動管理實驗生命週期，包括預測試/回測和清理。
  • 定義實驗設置——曝光、分組、成功指標。
  • 確定衡量所需的額外事件。
  • 進行初步實驗審查，以識別勝出的變體。
  • 理解領域頂層指標與公司策略的聯繫，能夠在發布決策中做出高判斷力的決策。
  • 期望能在 PostHog 中自行進行數據分析，並在 Hex 中編寫簡單的查詢。
• 共同職責 (DS & PM)：
  • 實驗影響分析——就結果和解釋達成一致。
  • KPI 定義（例如 AER、留存率、轉化率）。
  • 需要深入分析時共同審查實驗。
  • 調查異常模式。

C. 平等夥伴，各司其職

• PM 協助定義「做什麼 (what)」：
  • 界定問題。
  • 定義目標。
  • 帶來清晰度和背景資訊。
• 工程師塑造「怎麼做 (how)」：
  • 與 PM 和設計師共同設計解決方案。
  • 掌握可行性、權衡和執行。
• 設計師確保「簡潔性 (simplicity)」：
  • 讓複雜的 AI 人人可用。
  • 守護「阿嬤測試」原則。
  • 創造愉悅的體驗。
• 資料科學家提供「真相 (truth)」：
  • 用數據驗證假設。
  • 科學地衡量影響。
  • 指導實驗方法論。
• 所有人就「為什麼 (why)」達成共識：
  • 為什麼這件事值得做？
  • 我們在為誰解決什麼問題？
  • 為什麼是現在？為什麼用這種方法而不是其他方法？
  • 這如何推動業務向前發展？

D. 打造原型的流程

哲學：在傳統軟體中，PM + 設計師 + 工程師組成了神聖的鐵三角。在快節奏的 AI 開發中，我們優先考慮速度和學習，而非完美的流程。

彈性夥伴模型：PM 和設計師的合作關係因團隊而異。有些 PM 在 UX 方面經驗更豐富，應全程推動原型；有些設計師深刻理解 AI 的運作方式，可以介入領導原型。

兩人規則：原則上，由一名 PM/設計師加上一名工程師（共 2 人）來打造原型。我們不為了照顧每個人的感受而去追求共識。我們在這裡是為了加速驗證市場上的想法，以便我們團隊能打造出更好的產品。

人人都有機會為新想法打造原型。在 AI 時代，可以打造的東西幾乎是無限的（就像我們在黑客松中所做的，真的很了不起）。關鍵是要有一個高效的小組來推動快速決策。

通用方法：

1. 原型優先：PM/設計師 + 工程師直接合作，快速建構和測試想法。
2. 證明其可行：在投入大量設計資源之前，用真實用戶驗證概念。
3. 設計打磨：一旦被證明可行，設計師會將體驗精煉，使其符合我們整體的產品框架並保持簡潔。
4. 準備上線：每個從原型畢業到正式產品的功能都必須經過精心設計。

為何這樣有效：AI 功能存在巨大的不確定性。大多數原型都行不通。為未經驗證的概念過度投入設計是浪費時間。但所有送到用戶手中的東西都必須達到我們的品質標準。

第五部分：核心產品團隊

焦點：打造和精煉核心產品功能

核心產品團隊專注於基礎的產品體驗——打造定義 HeyGen 是什麼以及能做什麼的功能。他們優化用戶體驗品質、功能完整性和長期產品願景。

核心產品團隊的特點：

• 複雜功能的開發週期較長。
• 專注於產品體驗和用戶旅程。
• 強調設計系統和一致性。
• 與整個產品生態系統整合。
• 我們正在打造一個商業工具，但對於一個創意工具來說，愉悅的產品體驗至關重要，也是 HeyGen 達到 1 億用戶的關鍵。

核心產品的標準

標準很簡單：在每一個體驗上都成為絕對的頂尖。任何低於這個標準的都算不夠好。如何做到？以比競爭對手快 5 倍的速度行動和迭代。

零 Bug 的願景

我們應該以零 Bug 為目標。我們還沒做到，但這是我們的北極星。當你使用最好的創意工具——Canva、Figma 或 CapCut——你很少會遇到 Bug，因為準確性對創意工作至關重要。作為一個創意工具，可靠性不僅僅是錦上添花——它對用戶信任和工作流程的連續性至關重要。

第六部分：成長產品團隊

實驗引擎的哲學

成長團隊的運作方式與核心產品團隊不同。我們是實驗引擎。我們為速度、學習和影響力而生。每一條原則都服務於一個目標：提升我們的速度。

核心成長原則

工程是工具，影響力才是目標

我們不只是交付程式碼，我們交付的是成果。在 AI 時代，程式碼很廉價，影響力才寶貴。不要為了追求優雅或過度設計沒人要的解決方案而優化。要為**「達成影響力的速度」**而優化：交付重要的事（20% 的投入，80% 的產出），證明可行後再迭代，價值被證實後再精煉。

實驗是為了學習，不是為了贏

安全的實驗不是真正的實驗。目標是透過承擔聰明的風險、押注大膽的假設，並願意快速犯錯，以便我們能更快地做對，從而學得更快。

成長團隊的焦點

成長 PM：實驗的總指揮

• 與團隊集體做決策。
• 掌握指標和學習循環。
• 深刻理解用戶問題和業務影響。
• 以清晰和背景資訊來界定問題和定義目標。
• 定義「做什麼 (what)」——界定問題、定義目標、帶來清晰度。
• 與工程師就「為什麼 (why)」達成共識——為什麼這值得做？為什麼是現在？
• 以行動至上的偏見快速啟動實驗。
• 為成果負責，而不僅僅是產出。

成長工程師：速度機器

• 與 PM 和設計師共同設計解決方案。
• 掌握可行性、權衡和執行，以更好、更快、更聰明的方式建構。
• 在與「為什麼 (why)」對齊的同時，塑造「怎麼做 (how)」。
• 以最快速度啟動實驗。
• 執著於學習循環和數據。
• 深刻理解問題，而不僅僅是「告訴我該做什麼」。
• 有了「為什麼」，成為積極的參與者，用更少的迭代交付更多價值。
• 專注於達成影響力的速度，而非完美的架構。
• 打造能改變公司軌跡的實驗引擎。

成長團隊的不同之處

成長團隊玩的遊戲與核心產品團隊不同。核心產品專注於打造和精煉功能，而成長團隊專注於快速實驗和學習。我們在玩的是一場速度致勝的遊戲，每一條原則都為此服務。

第七部分：溝通協議

直接、非同步、高效

核心原則：

• 非同步優先：由於辦公室分佈各地，盡可能利用非同步溝通。
• 會議警訊：如果任何團隊成員每週有超過 3 次超過 5 人的同步會議，就要亮起紅燈。
• 時間焦點：我們的時間應該用來打造產品，而不是開會。
• 為影響力而面對面：利用面對面的時間來實現最高的溝通效率和團隊建設。

決策：立即透過 Slack 溝通，明確指定單一負責人及執行時間。團隊間完全透明。分享背景資訊，而不僅僅是計劃。清楚說明每項決策應告知哪些人。

回饋：直接了當——做得好就是好，做得不好就是不好。對事不對人。當收到回饋時：這是關於工作，不是關於你。每個人都可以進步。

第八部分：應避免的反模式

🚨 AI 開發的七宗罪

1. 完美的架構
   • 花費數週時間為「規模化」進行設計。
   • 你的規模問題：只有 100 個用戶。
   • 真正的問題：還沒有用戶熱愛它。
2. 研究癱瘓
   • 「我們需要更多用戶研究。」
   • 幾個月的訪談，卻沒有任何交付。
   • 更好的方法：發布錯誤的版本，快速學習，再發布正確的版本。
3. 穩固基礎的幻想
   • 等待 AI「成熟」。
   • 用 2019 年的方式在開發。
   • 現實：它永遠不會穩定——乘浪而行吧。
4. 共識陷阱
   • 每個人都同意 = 沒人在乎。
   • 要有堅定的意見，但保持開放的心態。
   • 衝突意味著你觸及到了重要的事。
5. 以品質為藉口
   • 「這個還沒準備好。」
   • 「再打磨一下就好。」
   • 自信地發布，快速地改進。
6. 大爆炸式的發布
   • 秘密開發 6 個月。
   • 然後盛大揭幕。
   • 競爭對手早就發布並學到東西了。
7. 沉沒成本謬誤
   • 「我們已經投入這麼多了。」
   • 快速終結失敗的項目。
   • 慶祝學到的教訓，刪掉程式碼。

什麼時候才該放慢腳步

品質關卡（不可妥協）：

• 阻礙從實驗中學習的 Bugs。
• 安全漏洞。
• 明顯損害用戶體驗的功能。
• 影響客戶的破壞性變更。策略性暫停（罕見但重要）：
• 對業務有重大影響的「單向門」決策。
• 將影響未來 6 個月的技術架構。
• 當用戶回饋表明需要根本性的方向改變時。
• 法律或合規要求。

紅燈偵測器

如果你聽到這些話，就要亮起紅燈：

• 🚨 「我們再多想一下」 → 我們已經落後了。
• 🚨 「我們應該讓所有利益相關者都達成共識」 → 決策癱瘓即將到來。
• 🚨 「如果技術變了怎麼辦？」 → 它一定會變，照樣發布。
• 🚨 「我們等下一個模型出來再說」 → 我們的競爭對手可沒在等。
• 🚨 「我們需要一個更穩健的解決方案」 → 我們首先需要的是用戶。
• 🚨 「這個可以再打磨一下」 → 先發布，如果用戶在乎，再打磨。

第九部分：在戰時取勝

我們為何會贏

• 我們的交付速度比競爭對手快 5 倍：更多實驗 = 更多學習。
• 學習的複利效應會轉化為更好的產品：我們擁抱他人所迴避的事物。
• 不穩定性是我們的優勢：老派的競爭對手無法適應。
• 我們專注於真正重要的事：為用戶提供品質，為學習追求速度，為差異化而創新。

我們乘浪而行的七大原則（願景）

1. 快速行動，絕不妥協。
2. 打造絕對頂尖的產品體驗。
3. 品質至上（特別是影片的視覺品質）。
4. 勇於諫言，決策後全力以赴。
5. 若有疑問，就發布一個實驗。
6. 擁抱不穩定的 AI 開發——乘浪而行。
7. 透過整合促進創新。

結論

乘浪前行

三年前，我們無法想像現在的 AI 能力，那時連 ChatGPT 都還不存在。三年後，今天的尖端技術將顯得古雅。唯一不變的就是變化。唯一的策略就是乘浪而行。唯一的目標就是用戶價值。

我們沒有所有的答案，但我們有更好的東西：業界最快的學習循環。

每一天，我們都面臨一個選擇：尋求虛假的安全感，還是駕馭浪潮。我們選擇駕馭。我們選擇打造能隨著 AI 進步而神奇地變得更好的產品。我們選擇快速交付、更快地學習，並贏得勝利。

歡迎來到軟體開發的未來。讓我們一起創造一些不可思議的東西。

記住：速度與品質並行，創新與整合共存，目標明確地追求速度。

快速行動，絕不妥協，乘浪而行。