Compounding Data Moat

資料來源#

• The Founder's Playbook: Building an AI-Native Startup

摘要#

The Founder's Playbook: Building an AI-Native Startup 對它自己的論點所引出的生死問題給出的答案：如果任何人都能打造軟體，護城河是什麼？ Scale-stage 手冊開出的護城河，由三個會複利增長的組件組成 — (1) 來自真實使用者在你的產品中精煉自己 workflows 所產生的 proprietary behavioral data，(2) 將產業特定邊緣案例編碼進產品的 domain-knowledge encoding，這是通用 AI 追不上的東西，(3) 透過整合與客戶自建自動化形成的 workflow lock-in，讓切換變成營運專案，而不是產品決策。其機制是 time-locked 防禦力：一個資源充足、今天才起步的競爭者，就是無法複製數千名使用者花了數月在你特定產品中塑造 workflows 後留下的 behavioral fingerprint。

三個組件#

1. Behavioral fingerprint 作為專有資料#

「當使用者與你的產品互動時，他們會產生行為訊號（也就是他們接受哪些輸出、拒絕哪些輸出），這會影響產品路線圖……這就是我們所說的複利價值：每次改進都讓產品更有用，帶動更多使用，創造更多 feedback，再推動更多改進。」

「這份資料是 time-locked、脈絡特定，而且模仿者不可能重建：你就是買不到數千名使用者在你的產品中精煉 workflows 所留下的 behavioral fingerprint。」

data flywheel 這件事並不新鮮；手冊的具體框定強調的是它的 time-locked 本質。即使有無限資本，也無法加速使用者發展工作流程模式所需的日曆月份。較晚進場、帶著更好模型的競爭者，在這個軸線上結構性落後，與資源多寡無關。

2. 編碼進 AI context 的 domain knowledge#

「例如，通用 AI 醫療帳單工具會在 340B drug program 理賠上失效，但你的產品有針對它們的特定邏輯。」

創辦人的領域專業（產業黑話、法規邊緣案例、挫折點、「為什麼顯而易見的答案行不通」的原因）會被外化成：

• 延伸 Claude 對話 / 專案 / 記憶 → 結構化、可搜尋的 context
• Skills → 將重複 workflows 編碼起來的可重用 routines（「我如何審計商業租約」、「我如何分診病患收案表單」）
• MCP 整合，接上競爭者甚至沒聽過的小眾產業系統
• 針對實際經驗中辨識出的邊緣案例所做的 驗證邏輯與 prompt 精煉

數月之後，這會變成「通用 AI 無法匹敵的專有知識基底」。

手冊的練習是：「找出一個你所在垂直領域中，一般競爭者一定會做錯的邊緣案例。和 Claude Code 一起，根據你實際見過的場景，替它建立一個專用測試案例（不是單元測試）。每次類似邊緣案例浮現，就加進去。你的 test suite 會變成你的護城河地圖。」

這很有意義 — 它把護城河從敘事轉成 產物：test suite 就是 被文件化的垂直領域專屬知識。

3. 透過整合形成 workflow lock-in#

「使用者在日常營運中使用你的產品越久，它就越深地嵌入他們實際工作的方式。他們在它之上建立了自動化，訓練人員使用它，並把它連到自己的資料來源和其他工具。他們開發出的 prompts、精煉過的 workflows、標準化的輸出，都已經圍繞你的產品做什麼、以及它如何做到而成形。到這個時候，切換就從產品決策變成完整規模的營運專案。」

整合深度有三層，每一層都創造逐步更強的 lock-in：

1. 原生整合，連到資料管線與專案管理工具 — 使用者建立依賴你產品的 workflows
2. APIs, webhooks, SDKs — 客戶不只是使用你的產品，他們是在 它之上建構
3. 內部自動化與受訓人員 — 客戶的 組織 已經圍繞你的產品變形

最深層的 lock-in，是客戶在你的產品上建立了一個 平台，而不只是使用一項功能。

這和 Seven Powers Applied to AI 的關係#

Compounding Data Moat 位在 Boris Cherny 的七大力量分析中那些 持續性 power 裡，但它的具體機制是新的：

Seven Powers component	Compounding Data Moat 如何運作
Network effects	間接 — 每個使用者的工作流程精煉，透過路線圖訊號改善所有使用者的產品
Scale economies	間接 — 更多使用 → 更多資料 → 每單位改進成本更低
Cornered resource	直接相關 — behavioral fingerprint 確實被封住、time-locked、買不到
Switching costs	Workflow lock-in 是轉換成本的現代形式；手冊的框定是，即使 通用轉換成本侵蝕，這點在 AI 下仍會 持續
Process power	部分相關 — 被編碼的 domain knowledge 是 Process power，而且不容易被爬坡式優化，因為它需要生成這些知識的現場經驗

Boris 更廣的論點是，switching costs 會在 AI 下侵蝕，因為 agents 可以重建整合並移植資料。手冊的反制動作是：把整合深化到 agent 無法移植的程度。APIs、webhooks、SDKs，以及客戶在你的產品上建立的自動化，創造出能撐過移轉工具的作用面。

時間不對稱#

手冊最倚重的防禦屬性是 時間。幾個明確框定：

• 「為什麼一個資源充足、今天起步的競爭者，無法在兩年內複製它。」
• 「Time-locked、脈絡特定，而且模仿者不可能重建。」
• 「把數千個匹配過濾到少數值得追求的對象之後……」（Kindora — 數月精煉）

論證結構是：即使所有其他護城河都侵蝕，花費日曆時間累積複利 這件事買不到。Scale-stage 退出問題 — 「如果資金充足的既有業者今天複製你的產品，你的使用者會留下來嗎？」— 是檢驗這個護城河是否存在的營運測試。

這對創辦人的要求#

這種 moat 不會自動出現。它需要在多個點上刻意建構：

• MVP stage: 在 launch 之前 建立測量框架（讓 behavioral data 從第一個使用者開始就被捕捉）。
• Launch stage: 建立 feedback loops，把使用者訊號轉成系統性的模型改善。
• Scale stage:
• 稽核累積的互動資料，辨識最高訊號的行為模式，設計 feedback loops，把模式轉成模型改善。
• 建立垂直領域邊緣案例的 test suite 地圖。
• 依整合深度 mapping customers；找出創造最深 lock-in 的 patterns。
• 建立 APIs/webhooks/SDKs，讓客戶 build on top of you。

手冊的規定練習是：「把你的產品互動資料摘要餵給 Claude……請它辨識該資料中三個最高訊號的行為模式，並設計一個回饋迴路，把每個模式轉成系統性的模型改善。接著請它幫你起草一頁護城河敘事。」

護城河敘事會成為 Scale-stage 產物，用在投資人對話、GTM 素材與企業銷售。

手冊中的案例研究#

• Carta Healthcare — 橫跨每年 22,000 件手術案例的臨床摘要；將摘要時間降低 66%。護城河：多年臨床 context 模式被編碼進 workflows。
• Anything — 非技術創辦人建立招募平台；完整建置透過 Agent SDK 編排。護城河候選：創辦人塑造出的招募領域 workflows。
• Wordsmith — 律師轉 CTO；服務內部團隊的法律科技。護城河：通用法律 AI 無法匹敵、針對法律團隊的工作流程理解。
• Kindora — nonprofit、charity 與 funder 的配對；把數千個配對過濾到少數值得追求的對象。護城河：在實際 nonprofit-funder pairs 上花數月精煉配對邏輯。

四個案例共同的模式：在某個垂直領域中有深厚專業 context，隨時間編碼進產品，產生競爭者結構上無法快速複製的邊緣案例處理能力。

相關連結#

• The Verifiability Thesis — 可驗證領域讓資料護城河能透過可測量回饋複利成長
• AI-Native Startup Lifecycle — 核心 Scale-stage 目標
• Seven Powers Applied to AI — 這個概念延伸的框架；轉換成本與流程力量透過此機制被重新定位
• Printing Press Software Democratization — 創造 這種護城河需求的宏觀類比（生產成本崩塌，所以差異化必須來自別處）
• Founder as Agent Orchestrator — 讓深度垂直領域知識可被編碼的領域專家創辦人管線
• Claude Code / Cowork / Anthropic — Skills、MCP 整合與 APIs 是建構這種護城河的作用面
• Harness Shrinkage as Models Improve — 通用 harness 會縮小，但由邊緣案例組成的 垂直領域專屬 test suite，是一種不會向內遷移的 harness（因為模型沒有可從通用資料學到它的訊號）
• AI Employee Framing — moat-via-domain-encoding 是「AI 取代領域專業」敘事的解藥；創辦人的 domain knowledge 是不可取代的輸入
• MCP and Computer Use — Skills + MCP 整合與小眾產業系統，是建構這種護城河的技術基底；Kindora 的 MCP-distributed product 是典範案例
• The AI-Native Safe-Choice Inversion — 這個護城河防守的是反轉贏下 落地 之後的 擴張；一旦切換完成，AI-native 供應商會累積既有業者欠缺的資料/workflow lock-in
• Product Velocity as Moat — 速度是 落地（一台跑步機）；這個複利護城河是速度必須轉化成的持久 防守（Campfire）

衍生內容#

• Orchestration vs Employee Framing: Reconciling the Founder's Playbook with HBR's Accountability Evidence — 指出這個護城河與 HBR-compatible：它 關乎 把創辦人判斷編碼進基底；即使表層語言是擬人化，結構上仍是工具框架

開放問題#

• 「兩年複製窗口」這個主張在實證上站得住腳，還只是願景？手冊沒有引用測量。
• 當 foundation models 本身持續快速改善，這種護城河如何維持？如果 2027 年的通用模型已經內化足夠垂直領域 context，能原生處理 340B drug claims，垂直邊緣案例護城河是否會侵蝕？
• data-flywheel argument 已經在 SaaS 裡講了 15 年。AI-native 版本到底哪裡不同？可能是：資料不只改善產品，也改善 模型，但手冊沒有精確區分這件事。
• 「客戶在你之上建立 APIs」這種 lock-in，結構上類似平台玩法（Salesforce AppExchange、Shopify apps）。這種護城河類型真的新嗎，還是只是精實新創現在也能取得？

資料來源#

• The Founder's Playbook: Building an AI-Native Startup — Scale Stage 章節（「Claude 如何幫助 Scale stage 創辦人」、workflow lock-in、複利資料章節）+ 資源章節案例研究