Avoiding Death on the Yellow Brick Road (遠離黃磚路上的死亡陷阱)

原始來源與檔名：2026-05-29T081803+0800-Avoiding Death on the Yellow Brick Road.md

NAPKIN | 餐巾纸

餐巾纸公式

企業級 AI 價值 = (模型能力 × 0.2) + (垂直工作流工程 × 0.5) + (領域專有護欄與數據飛輪 × 0.3)

模型只是基礎，真正的商業護城河來自於深入特定行業的複雜工作流、資料積累與合規護欄。

一句话

AI 應用層新創要生存，不能走基礎模型巨頭的「黃磚路」(通用水平工具)，而必須深入「奧茲國的其餘地方」，建立解決複雜、垂直且需要深度領域知識的系統級工作流。

餐巾纸草图

    [ OpenAI / Anthropic ] 
             |
    +--------+--------+ (The Yellow Brick Road)
    |  Generic Tools  | -> High Risk of being eaten
    +--------+--------+
             |
             |
=============================== (The Rest of Oz)
    +-------------------+ -> Deep Vertical Workflows
    | Data Flywheel     | -> Multi-agent / Multi-step
    | Compliance/Guards | -> P&L Outcome Driven
    | Custom UI/UX      | -> High Moat
    +-------------------+

ROUND 1: SKELETON | 骨架掃描

“这本书在说什么”

核心问题: AI 應用層是否已死？新創公司如何在 OpenAI 和 Anthropic 等基礎模型巨頭的夾擊下生存？
核心答案: 應用層未死，但必須避開巨頭擅長的通用水平工具（黃磚路），轉向建立解決複雜垂直行業痛點的端到端工作流系統（奧茲國）。
论证结构: 對比型（通用水平 vs. 垂直深入）與案例型（Sales 和 Insurance 領域）。

章节骨架

引言: AI 應用層未死
黃磚路: 通用工具的危險
奧茲國: 垂直領域的機會
防禦機制: 數據、路由與護欄
銷售案例: 11x 的實戰經驗
保險案例: FurtherAI 的實戰經驗
評估標準: 如何判斷你的定位

ROUND 2: DISSECTION | 血肉解剖

“凭什么这么说”

论证链

通用工具依賴模型原始能力 --> 巨頭在模型能力上具備絕對優勢 --> 新創做通用工具會被巨頭吞噬
垂直領域依賴領域知識與複雜工作流 --> 巨頭無法專注於所有垂直領域的細節與合規 --> 新創在垂直領域建立深層系統可形成護城河

关键证据

巨頭行為: OpenAI 和 Anthropic 開始建立合資企業來為企業客製化模型，這表明即使是他們也承認通用模型無法解決所有企業問題。
11x 的經驗 (Sales): 透過整合非 Agent 任務（如 CRM 數據獲取）與 Agent 任務（如對話微調），成功將回覆率提升 4 倍，創造數億美元的 pipeline。
FurtherAI 的經驗 (Insurance): 保險業的核心邏輯不在於模型，而在於 SOP、經理審核、承保哲學等無法輕易被模型讀取的「工作流」中。

隐形假设与边界

隐形假设:
- 基礎模型巨頭（如 OpenAI）的策略將繼續保持橫向擴展，不會深入特定垂直領域（如律師事務所的具體工作流）。
- 企業客戶願意為「業務成果 (Outcomes)」支付高額費用，而不只是購買 AI 工具的使用權。
边界条件:
- 如果基礎模型進化到具備完美的「通用零樣本推理」和「動態環境探索」能力，以至於不需要任何人類工作流腳本，此理論可能失效。
- 如果垂直領域的資料被完全公開並被巨頭吸收進基礎模型，護城河將大幅削弱。

ROUND 3: SOUL | 靈魂提取

“还能怎么用”

作者盲点: 作者較少探討開源模型 (Open-source models) 在「奧茲國」策略中的角色，以及硬體算力成本下降後對垂直 SaaS 的長期影響。
知识连接: 與 SaaS 領域的「水平 SaaS (如 Excel) vs. 垂直 SaaS (如 Veeva)」發展史高度吻合。也與 Clayton Christensen 的《創新者的窘境》中「整合 vs. 模組化」理論相呼應。
行动触发: 審視當前的 AI 產品：我們是提供一個「工具 (Tool)」還是一個「系統 (System)」？客戶是因為我們的模型還是我們的護欄與工作流而買單？

跨域映射

在 SaaS 領域，这叫 Vertical SaaS (垂直軟體服務)
在 投資領域，這叫 Alpha (超額收益，基於專有資訊和策略)

STRUCTURE MAP | 全书结构图

AI Application Layer
|
|-- The Yellow Brick Road (Danger)
|   |-- High reliance on raw model capabilities
|   |-- Horizontal scope (Codex, Claude)
|   +-- Controlled by Labs (OpenAI, Anthropic)
|
+-- The Rest of Oz (Opportunity)
    |-- Deep Vertical Workflows
    |-- Defensibility Moats
    |   |-- Data & Learning Flywheels (Tribal knowledge)
    |   |-- Model Routing & Cost Optimization
    |   +-- Governance & Guardrails (HIPAA, SEC)
    |
    |-- Practical Examples
    |   |-- 11x (Sales): Focus on outcomes, mixed agentic/non-agentic
    |   +-- FurtherAI (Insurance): Workflow as operating memory
    |
    +-- Evaluation Tests
        |-- Tools-and-steps test
        |-- System vs. Tool test
        +-- P&L outcome test

Avoiding Death on the Yellow Brick Road (Architectural Deep Dive)

前言/背景

本文深入探討了 AI 應用層新創公司在面對 OpenAI、Anthropic 等基礎模型巨頭（Labs）時的生存與發展策略。核心問題在於：巨頭是否會吞噬所有應用層？文章給出的答案是：不要在巨頭擅長的通用水平領域（The Yellow Brick Road）競爭，而應深入特定垂直行業的複雜工作流（The Rest of Oz），透過構建包含專有資料飛輪、多模型路由、以及嚴格合規護欄的系統來建立護城河。

章節詳細總結

The Yellow Brick Road (黃磚路上的危機)

「黃磚路」指的是基礎模型巨頭投入巨量資源發展的通用能力路徑，如程式碼生成、寫作或圖像生成。這些領域的產品品質直接與模型的預訓練和後訓練成本掛鉤。

架構缺陷：許多新創公司採用「模型 + 現成連接器 (Google Drive, Slack, Salesforce) + 簡單 Agent 協調層」的架構。這種架構的致命傷在於，這正是巨頭們在做的。巨頭擁有模型控制權、更好的利潤率，以及決定產品架構方向的能力（例如 tool calls 模式）。
結論：沒有底層子 Agent (sub-agents) 配置、沒有分發渠道的薄殼 (thin wrapper) 應用注定會被淘汰。

The Rest of Oz (奧茲國的機會與防禦機制)

在通用領域之外，存在著需要多步驟、多角色協作的複雜垂直領域。新創可以透過以下四種架構機制建立護城河：

資料與學習飛輪 (Data and learning flywheels)
- 技術細節：企業內部存在大量未文檔化的「部落知識 (tribal knowledge)」。垂直應用的架構需要設計特定的 UX 介面來捕捉這些工作流中的例外和決策原因（例如，法律合約紅線批註、保險核保週期）。
- 架構意義：Eval 測試集、標記輸出和邊緣案例分類法可以組合成垂直領域專屬的資料飛輪，用於微調 (Fine-tuning) 模型。這是單純呼叫通用 API 無法複製的。
模型變異與複雜度管理 (Managing model variability and complexity)
- 技術細節：巨頭只能在自家模型間路由。垂直 SaaS 可以在整個市場（包括開源微調模型）進行跨供應商的任務級別路由 (Task-level routing across vendors)。
- 架構意義：架構師需要建立評估框架 (Evals) 來吸收模型升級帶來的震盪，確保在更換底層模型時，生產環境的提示詞和邊緣案例不會崩潰。
成本最佳化 (Cost optimization)
- 技術細節：將所有查詢發送給最頂級的模型（如 Opus 或 GPT-4）會導致嚴重的負毛利。
- 架構意義：設計分層路由架構：最難的任務使用前沿模型，多數任務使用中階模型，特定任務使用低成本的客製化微調模型。這能將單位經濟效益最大化。
治理與護欄 (Governance)
- 技術細節：成為企業 AI 的控制平面 (Control Plane)。整合權限控制、稽核日誌，並實施針對特定行業（如 HIPAA、SEC、FINRA）的嚴格護欄。
- 架構意義：系統必須提供確定性的結果 (Deterministic outcomes)。這需要將 AI 的隨機性限制在嚴格的軟體工程框架內，確保代理(Agent)的行為可被完全追蹤和控制。

實戰案例：Sales (11x) 與 Insurance (FurtherAI)

11x (Sales)：強調「結果導向」。架構上，一半的任務是非 Agentic 的傳統軟體工程（如從 CRM 獲取上下文、特定信號的潛在客戶探勘），另一半是 Agentic 的任務。護城河在於不斷適應市場動態（例如動態調整 AI 寫作風格以避免被識別）。
FurtherAI (Insurance)：保險業的智慧不只在模型，而在「工作流」中。架構設計不應採用純粹從頭推理的 Agent，而是Agentic Workflows：工作流提供可重複性、可稽核性和成本控制；Agent 處理變異和異常恢復；人類處理最終判斷。隨著時間推移，這個工作流系統會變成企業的「營運記憶 (Operating memory)」。

評估框架：你是否在「奧茲國」？

文章提供了三個測試架構定位的標準：

工具與步驟測試 (The tools-and-steps test)：是單一步驟、容錯率高的橫向搜尋，還是需要穿越多個系統、多步驟且容錯率極低的垂直工作流？
系統 vs. 工具測試 (The system test)：你是建立一個端到端管理資料擷取、治理和記錄的「系統」，還是一個只是附加在現有系統上的「工具」？如果巨頭推出類似功能客戶仍離不開你，那你就是系統。
損益表測試 (The P&L test)：客戶是為了通用的基準測試分數 (如 MMLU) 買單，還是為了具體的業務指標 (如成交率、合約正確率) 買單？

總結與結論

擁抱 Agentic Workflows，拒絕純 Agent：在企業級架構中，完全自主推理的 Agent 風險過高且不可控。應將 Agent 嵌入到傳統的、具有高度確定性的工作流軟體中，讓工作流負責主導 (Orchestration)，Agent 負責處理節點上的複雜度。
構建跨模型路由層 (Cross-Model Routing Layer)：為了利潤率和效能，系統架構必須具備任務級別的智慧路由能力，能根據任務難度動態切換 GPT-4、Claude 或開源的專精小模型。
將「合規與護欄」視為核心產品特徵：在垂直領域，安全、權限控制、稽核日誌和領域特定的合規檢查（Guardrails）往往比模型本身的推理能力更能說服 CIO 買單。
混合架構 (Hybrid Architecture) 是護城河：真正的防禦力來自於 50% 的傳統確定性軟體工程（與現有系統如 CRM、ERP 的深度整合與資料清理）加上 50% 的 AI 推理能力。不要試圖用 AI 解決所有問題。