從零開始的 AI 導入 — 我們花了兩年才知道自己在做的事叫 AI-Native

前幾天讀到 Greg Isenberg（美國連續創業家，Reddit / TikTok 前顧問，創業評論家）寫的一篇談 AI-Native 公司的長文，讀完之後我反芻了一會兒，他寫的東西，幾乎就是我們在 Numbers Protocol 過去兩年一邊跌一邊學的事，只是他整理得清楚多了。

文章一開場就來個戳破泡泡的誠實豆沙包：

「現在每家公司都說自己是 AI-Native。但大部分時候，這只是代表團隊裡有人開著 ChatGPT 的分頁。」

然後他丟了一個非常有趣的數字：全球年營收超過 500 萬美金、且真正做到 AI-Native 的公司，大概只有 1,000 家。也許 500、也許 2,000，Greg 說「數字不重要，重點是這個領域基本上是空的。」

於是決定久違來寫篇心得工商文，也順便回頭把自己這兩年走過的路重新整理一次。

我們不是一開始就知道有「AI-Native」這個詞

這幾年 AI 產業迭代跟三十年前網際網路發展的速度比起來，大概是火箭跟汽車的差異。

從每半年一個新模型，到每個月一個新模型，到現在幾乎每兩週就會冒出一個新名詞 — agentic、context window、MCP、subagent、harness…… 我們團隊內部的 group chat 永遠在分享「欸這又是什麼酷東西？」

兩年前根本沒有人在講「AI-Native」，連 agentic 這個詞都是後來才被廣泛使用。我們當時也沒有什麼宏大的策略，只是想搞清楚：這個新技術到底能怎麼用？

回頭看，我們的導入歷程跟整個產業給出的「名字」基本上是同步的：

Prompt Engineering 階段（2023-2024）：我們花了大量時間在「怎麼寫 prompt 才能拿到好結果」。團隊內部會分享神奇的 prompt 模板，比賽看誰的 ChatGPT 最聰明。那段時間我們以為 AI 就是這樣，是一個聰明、但需要被「會問問題的人類」引導的助理。

Context Engineering 階段（2024-2025）：跑著跑著我們發現，prompt 寫再好也救不了模型「看不到正確資訊」這件事。重點不再是怎麼問，是模型在做判斷的當下，context window 裡有什麼。我們開始花更多時間在 RAG、在資料結構化、在「怎麼讓模型在對的時間拿到對的東西」。

Harness Engineering 階段（2025-至今）：然後我們發現，即使模型很聰明、context 也餵對了，真實場景裡 agent 還是會壞。因為 agent 不是 chatbot，它要連續做很多決策、跟很多工具互動、跨很多時間運作。它需要的不是更好的 prompt 或更好的 context，是一整個環境：工具、記憶、邊界、回饋、稽核軌跡。

這個階段 Numbers 團隊花了很多時間在設計 TAEA 框架（Transparent / Auditable / Explainable / Agentic）。但說真的，在這個過程裡，我們一直沒有一個簡潔的詞可以描述「這個轉變」整體是什麼。

三個階段：Prompt → Context → Harness Engineering

直到讀到 Greg 的文章，我才意識到：我們在做的事情，其實根本就叫 AI-Native。

但這之前，有次跟 Tammy 的對話，其實已經把這個概念先推進我腦袋了，只是當時還沒有名字。

Westworld 其實是十年前的 AI 預言?!

我們家物理學霸 Founder Tammy 是 Westworld 的死忠粉絲，她從去年年底就開始各種分享 Westworld 影集裡的概念。

老實說我一直還沒看，直到聽她又講了一次，我突然好奇想去補，結果發現因為版權問題，大部分串流平台都已經下架了 😅 我現在還在找哪裡看得到完整版。所以以下劇情大概都是聽她二手轉述的，簡單講就是，一家科技公司打造了一個西部主題樂園，裡面所有角色都是 AI 接待員，人類遊客可以付錢進去跟他們互動（應該沒有爆雷 XD）。

大概是今年（2026）年初某次團隊閒聊，Tammy 又提到 Westworld，但這次不是聊劇情，是聊到她對企業 AI 導入的觀察。

她說現在大部分企業導入 AI 的方式，本質上就是給每個員工配一個西部世界的接待員，能力 10x up，但公司結構還是以人為中心，沒有真正 agentic。「弄了兩年 AI 導入、感覺好像大家都變厲害了，但其實公司沒有真的升級，流程跟以前一樣，只是多了更多破碎的自動化。」

然後她講了一句後來我一直在反覆思考的話：

「如果對話永遠是 human to human，那公司就永遠也不會 AI 化。AI 化的是 Claude/OpenAI，不是你的公司。」

她接著提到 Westworld 裡有一個叫 Rehoboam 的巨型電腦（她比喻為「水晶球」，我覺得挺貼切的），不是每個 host 各自厲害，而是有一個由公司 100% 控制、全知全能、可以自我演化的中央 AI 在運作整個系統。host 是 host，Rehoboam 是 Rehoboam，完全不同層級的東西。

「公司要追求的不是讓每個人手上有一隻接待員，」她說，「是蓋出自己的水晶球。」

那句話就像個餘音繚樑，完全影響我後來看 AI 的角度。

AI-Assisted vs AI-Native：員工有 AI 對比公司有 AI 的兩種架構

因為我突然意識到之前的視角錯了，我們一直在問「怎麼讓 ChatGPT 更聰明、怎麼讓 Claude 幫我們更多」，但這是「給人類配更強的 AI 助理」的思維，不管助理有多強，公司本質還是 human centric 的。

要 AI-Native，公司本身就得有 AI。不是員工有，是公司有。員工跟公司的 AI 對話，公司的 AI 跟員工的工作環境協作。整個架構是繞著「公司的 AI」設計的，不是繞著「人類的工作流」設計的。

Tammy 後來真的去做了，花了 82 天蓋出 Numbers 的水晶球，我們內部叫它 Omni。所有的 knowledge、memory、heartbeat 都跑在自己的 server 上，公司每個角色都能跟 Omni 直接對話。不是 Slack 外掛 Claude，是公司自己的 Rehoboam（她一直強調，只取能力的部分，性格的部分不討論，我是不知道 Rehoboam 的性格是多機車啦… 😅）。

讀完 Greg 的文章後我才發現，他講的就是同一件事，只是用了「legibility（可讀性）」這個更精準的字：

「AI-Native 公司不是『有在用 AI』的公司，它是一家被重新設計過的公司，讓 AI 可以真正在裡面運作。它讓自己對機器變得可讀。」

“對機器變得可讀”，意思是公司本身就是 AI 能夠在裡面運作的組織架構，不是公司外面掛了一個 AI，是公司裡面長出了一個 AI。

Tammy 的 Rehoboam 比喻（水晶球）跟 Greg 的 legibility，在我看來是同一件事的兩個面向。

Assisted 和 Native 真正的差別

Greg 整篇我覺得最值得抄下來的是這段對比：

AI-Assisted 的公司問：「我們可以在哪裡加 AI 來省時間？」 AI-Native 的公司問：「如果 agent 負責前 80% 的工作，這個流程應該長什麼樣子？」

兩個問題會長出兩家完全不一樣的公司。

第一個問題的答案，是在現有流程上多開一個 ChatGPT 分頁，也就是 Tammy 講的「給每個員工配個接待員」。第二個問題的答案，是整個流程要重寫，讓中央大腦（水晶球）變成第一處理者。

我們在 prompt engineering 階段做的是前者，在 context engineering 階段還是前者，到 harness engineering 階段才慢慢變成後者。這個轉變不是一夕之間，是慢慢滲透，直到這幾天我看著一個跟 Omni 的對話，才發現我們已經是先設計 agent 要怎麼做，再決定人在哪裡介入了。

舉客服當例子。原本工單流程是：人讀、查 user 帳戶、回想政策、寫回覆、可能要問工程、可能要升級、可能還會忘了標分類。是以人為主，軟體散在周圍。

換成「水晶球先做」之後變成：系統讀客戶歷史、檢查方案限制、查過去工單、對照政策、擬好回覆，然後判斷，能解決就解決，不能就附上「需要人判斷的原因」送張 agent ticket 給人類。人類在這裡的角色不是搜尋引擎、不是路由器、不是文案寫手，人類是審核模糊地帶的最後一道防線。

跑了幾個月之後我發現，這已經不是「我們用了更多 AI」，是從工作流和結構面上「都是 AI」。

大多數公司「機器根本看不懂」

回到 Greg 講的 legibility。我們親身體會之後發現，這可能是這幾年最重要的一個概念。

因為機器根本看不懂大多數公司，而且可能連自家員工都覺得不太可讀。

我們自己當時就是這樣：

CRM 寫一套
Slack 討論串又一套
真實的客戶歷史散在三個人的信箱裡
定價邏輯在一份叫 pricing_2024_FINAL_v3 的試算表
退費政策有一份文件，但實際操作是「看狀況」
上線流程要用五個工具、過三個人、兩道審核，特例情況還是會把我拉進來

然後我們問：「為什麼 AI 不能幫我們做更多？」

回頭看，答案其實很明顯，AI 沒辦法靠 “vibe” 運作。它沒辦法經營一家「資料散在人、工具、習慣、例外、組織記憶之間」的公司，它需要上下文、需要乾淨的輸入、需要規則、需要邊界、需要知道什麼叫做「好」。

Greg 寫的這句完全反映企業導入 AI（或者說，自動化）的現況：

「大多數公司過去二十年買了一堆軟體，但沒有花時間設計一個作業系統。他們手上有一堆工具，不是一台機器。」

換成 Tammy 的 Westworld 比喻：大家都在派接待員，但沒有人在蓋水晶球。

廚房就是公司

Greg 文章裡最有畫面感的一句話是：

「Everyone wants the magic. Nobody wants to clean the kitchen. But the kitchen IS the company.」

廚房就是公司。

我自己最深刻的體會，也是 Tammy 不斷強調的是，AI-Native 的真正門檻不在模型，每個人都買得到 Claude、GPT、Gemini 的 API，門檻在這些事：

清資料、寫 SOP、把決策邏輯從人的腦袋裡搬出來、設邊界、建稽核軌跡。

這些事一·點·都不性感。沒有 keynote 可以講，沒有 demo 可以炫耀，實打實需要一些手工藝。我們做這些事的時候，團隊裡有人開玩笑說「我們是不是在開倒車變成行政部門?」舉個例子，光是財務的 AI 交接，我們就做了一季，不誇張的三個月，因為財務會計有太多細瑣的、留在人腦的、已經變成下意識做完了的流程和例外，如果無法機器可讀，Omni 就無法接手 take care。

但回頭看，這些不性感的事就是公司，也是中央大腦 aka 水晶球能不能蓋起來的地基，從外面看超無聊，但反映到現況，其實蠻迷人。

這兩年我們學到的事

Greg 文章後半給了一個 5 步框架。我看完之後第一反應是「阿不就是我們過去兩年的辛酸血淚?!」，當然我們不是先看到框架才走，是反過來，跌了夠多跤之後才在他的整理裡找到對應。

從一個個窄場景開始，而不是「導入 AI」

我們選的第一個切入點是「問題分類 + 標準回覆草稿」，不是因為它最重要，是因為它最枯燥、最重複、人最不想做。從這個窄場景開始，失敗的成本低，但學到的東西多得驚人。

把流程當機器拆

我們後來內部的問題清單大概是這六個：

什麼會觸發它？
需要哪些資料？
會出現哪些決策？（哪些可逆、哪些要核准？）
成功會長什麼樣？
錯誤通常發生在哪？
人類知道什麼是系統不知道的？

最後一條最關鍵，通常是隱性知識，「那個客戶問小白，因為他去年跟那家公司業務吃過飯」這種。

把這六題的答案寫成一份文件，就是我們後來所有 agent 的 spec 起點。寫的當下覺得在浪費時間，事後發現這份文件是最值錢的內部資產。

結構化知識比想像中更花時間

Agent 需要政策 → 寫政策。需要定價規則 → 把規則明確化。需要客戶歷史 → 把客戶資料清乾淨。

我們也差點在這步放棄過，因為感覺像在寫文件、在做行政，看不到立即的效果。

我們後來在 TAEA framework 裡會反覆強調「Auditable」，就是因為這層真的是個痛點，沒有結構化的知識，水晶球永遠在猜，你也永遠在解釋為什麼 AI 又做錯了。這不是文件，是基礎建設，也是 harness engineering 在做的事，只是當時我們還沒這個詞可以用。

TAEA Framework：Transparent / Auditable / Explainable / Agentic 四個治理原則

邊界比能力更難設計

讓水晶球起草、分類、推薦、補充、摘要、準備… 這些都不難。難的是邊界：什麼事它可以自己做、什麼事要核准、什麼事絕對不能自動化。

我們的做法是給 agent 行動權，但加上「先提案，人核准」的層。聽起來很笨，跑了兩個月後我發現，這個「笨」是非常必要的，邊界本身就是公司（還有人類）的價值判斷，不能交給模型決定。

Tammy 在分享 harness engineering 心得的時候講過一個比喻我覺得很到位：LLM 看起來是語言模型，但說到底它是一個數學機器，需要一個明確的 KPI 公式才能演化。沒有公式，它就會在各種 wish 裡擺盪，什麼也做不好，而邊界，就是那個公式。

用業務指標衡量，不是用「省了幾小時」

這條是我們現在公司月報第一條：revenue per employee，兩年前不是這樣。

「省幾小時」是試算表上好看的數字，但業務上看不到。Greg 列的清單我覺得很實用：解決時間、轉換率、毛利、每人營收、錯誤率、客戶滿意度、銷售速度、onboarding 時間、續約率。AI-Native 的公司應該在這些數字裡看得出來，看不出來，大概就是還沒到。

我們目前真的在這些數字上看到變化，但變化最大的不是 “節省”，是 “節奏”，公司對內對外的回應速度都不一樣了。

我們現在的樣子

從 2025 年 4 月全面 AI 導入的時候，我們 Q2 大概是這樣：

全職人類同事 6 位 + 線上 AI 同事 15 位 + 實習階段 8 位
每位人類同事平均同時跟 3 位 AI 同事協作
內部 MVP 從需求到完成 ≤ 24 小時
年度 SaaS / Infra 支出 -60%

2026 Q2 的現在，我們長這樣：

全職人類同事 6 位 + Omni（水晶球全知 AI）+ Z（AI 原生資料流平台）
Harness everything，Omni 會自己去開發、自己去規劃下週的 social post、自己去搜尋新創相關活動並填好申請表、自己去寫 BD outreach 信，需要人類協助的項目開 agent ticket 等人類下決策，每位人類同事平均一天解決 3-5 張 Omni 開出來的 agent tickets

Numbers Protocol 團隊組成的演化：2025 Q2 vs 2026 Q2

是的，2025 Q2 hire 的那 15 位 AI 同事和 8 位實習 AI 同事都被開除了，只留下靈魂，整合成水晶球。講這些不是想說我們做得多好，我們踩過不少雷，有幾個失敗的 agent 還在 retro 文件裡躺著當教材。想說的是，這套架構真的可以跑，而且已經開始成為我的日常。

基本上 Omni 上線之後，我們不再是需要盯著 AI 的人機協作，而是採用 async 方式讓 Omni 自己跑，人類下班了它還在跑巡檢、整理知識、抓異常，Omni 沒有班表，7/24（希望他還沒那麼快意識到勞基法的部分 XD）。

有件事出乎我意料，本來覺得 AI 會取代人類，結果發現我們的人類團隊比過去任何時候都更被需要（看看 Omni 多需要我們解掉那些 agent ticket XD）。一位行銷同事變成 10 個工作流程的主管；一位開發同事變成升級邏輯與顧客體驗的設計師。Greg 文章那句「人的角色會被放大，不是被取代」，我們親身體會到了，而且還徹底感受到什麼叫做「工作的邊界會越來越模糊」，以及你即將不需要是「專才」，但需要是個可以融會貫通、靈活應變的「通才」。

導入之前我擔心會不會讓團隊覺得「我們在被取代」，結果反而是大家發現自己變得更不可替代，因為水晶球 Omni 接手了所有廚房裡要執行的部分，留下來的事都是真的需要人類判斷的事。

回到 Tammy 那個比喻：我們的人類團隊不是接待員，也不是水晶球本身，是設計、訓練、看顧水晶球的工程師。水晶球越強，工程師越重要。

為什麼既有企業很難追上

Greg 文章最後一段我特別有感：

「老公司沒辦法靠宣布一個 AI 計畫就變成 AI-Native，那就像想靠換方向盤把郵輪變快艇。」

困難點真的不在拿到模型，每個人都拿得到。困難的是既有企業背了一堆老舊流程的債：資料亂、政策互相打架、團隊守地盤、工作流程是以人力編制為中心設計的，整個作業系統的預設值，就是把人類當資訊處理器在用。

新公司的優勢是沒有家具要搬，可以從乾淨的狀態開始，每一個流程都用「水晶球能不能先做第一輪？」這個問題來建。

我覺得這是這個時代早期新創最大的 unfair advantage。

那 1,000 家裡有幾家在台灣？

我不知道確切數字。但我猜亞洲不會超過 50 家，台灣不會超過 10 家。

這是機會，也是落差。

下一批讓人記得的台灣公司，我覺得會是那些從內到外用 agent 重建資料、流程、政策跟團隊的公司，它們看起來會比應有的規模小、速度快到不合理、用更少的人做更有價值的工作。

AI-Native, 然後呢?

Greg 文章最後留了一個問題：

「大多數人還在問『怎麼在工作中用 AI』。更好的問題是，怎麼蓋一間 AI 可以在裡面運作的公司?」

兩年前沒有人在講「AI-Native」，一年半前我們忙著磨 prompt，一年前我們在搞 RAG 跟 context window，半年前我們開始認真設計 harness。Tammy 分享 Westworld 的那個下午，讓我第一次認真想「公司的 AI 應該長什麼樣」，而不是「公司該怎麼用 AI」。

我有預感，兩年後當我再回頭看，「AI-Native」也只會是中途的一個名字。

AI 大舉入侵我的生活後我一直在思考，我們現在費這麼大功夫蓋水晶球，真正的目的到底是什麼？是讓公司運作更有效率？是讓人的角色重新被定義？還是，為了某個我們現在還看不清、但水晶球蓋好之後才會慢慢顯現出來的地方？

我不知道。但我覺得接下來兩年最有趣的事，可能不是 AI-Native 本身，而是 AI-Native 之後，會是什麼？那個 “什麼” 我們大概還沒有名字可以叫它，但它應該已經在某些團隊的 group chat 裡開始萌芽了。

原文連結：Greg Isenberg — How to become “AI-Native” （強烈建議讀完整篇英文版，也歡迎分享你的看法）

#AINative #AI原生公司 #HarnessEngineering #新創 #TAEA #文組AI專家