Notion AI 負責人 Sarah Sachs：做最好的協作場所，而非最好的 AI Harness

本文整理自 Latent Space Podcast 2026 年 4 月播出的單集。

{{< youtube ATt7QJgt-2k >}}

{{< spotify "episode/0pI3rxITA2D1HPUKpPb8Kv" >}}

{{< apple-podcast "tw/podcast/notions-token-town-5-rebuilds-100-tools-mcp-vs-clis/id1674008350?i=1000761419695" >}}

---

因為 Simon Last 需要去度假

Sarah Sachs 加入 Notion AI 團隊的原因非常務實：Simon Last 需要一個人管團隊，這樣他才能去度假。

這個輕描淡寫的開場白，其實透露了 Notion AI 早期的組織狀態。在 Sarah Sachs 到任之前，AI 團隊的運作方式更像一個研究實驗室：Simon Last 一個人既做技術方向判斷、又管專案優先序、又親自寫程式碼。這在團隊規模小的時候可以運作，但 Notion 需要的不只是一個能寫出概念驗證的技術領袖，還需要一個能把實驗室規模的東西變成產品級服務的管理者。

Sarah Sachs 的背景讓她對這種轉換有獨特的感受。她之前在 Robinhood 工作了好幾年，一家因為合規問題付出過沉痛代價的金融科技公司。她在 Latent Space Podcast 上坦言，自己把那段經歷帶來的紀律意識注入了 Notion AI 團隊。比如，當被問到安全審查是不是上線前最後才做的事，她的回答很直接：「不，安全審查是最先帶進來的人。這不只是公關標準答案，這是傷疤換來的經驗。」

她現在管理的「核心 AI 能力與基礎設施」團隊約 50 人。另外還有 30 到 40 人負責把 AI 能力包裝成不同的產品形態，例如角落的對話 Agent、Custom Agents、會議紀錄。再加上 Notion 所有的產品工程團隊都被要求讓自己的服務同時服務人類和 Agent。用 Sarah Sachs 的話說：「隨著時間推移，我們大多數的流量會來自 Agent 而非人類。所以整個產品組織都在為 Agent 而建。」

做 demo 勝過寫文件

Notion AI 團隊有一個文化口號：「demos over memos」（做 demo 勝過寫文件）。這是設計師 Brian Loven 推廣的概念，但 Sarah Sachs 認為它帶來了意想不到的壓力。

當任何東西都可以快速做出 demo 的時候，過濾機制反而變得更重要。如果團隊只是不斷做出很酷的展示，卻沒有聚焦在特定的使用者旅程上，結果就是「蓋了一座很平的小丘，而不是一座塔」。Sarah Sachs 觀察到，團隊速度最慢的時候，往往是過度追求「很酷的工具」的時候。反過來，當他們鎖定一個具體的使用者旅程，比如「郵件分類要能用」「PDF 匯出要能做」，然後從旅程反推需要什麼工具時，速度最快。

Simon Last 補充了另一個觀察：Notion 團隊的工程師幾乎都有足夠的「品味」來判斷一個原型到底有沒有意義。他很少看到完全離譜的原型。問題通常不是品質，而是優先序，這麼多好的想法，先做哪一個？

設計團隊的做法更極端。他們在 GitHub 上建了一個獨立的「Design Playground」repo，裡面有一堆預製元件，甚至內建了 Agent。設計師不再做靜態的模型圖（mockup），而是直接做出可互動的原型，給工程師一個 URL 說「就長這樣」。工程師的工作變成把這個原型的邏輯搬進正式的程式碼庫，而不是從零開始猜設計師要什麼。

但「demos over memos」帶來的另一個挑戰是維護。如果每個原型都很快就做出來，但沒有人負責後續的評估和維護，系統就會變成一堆半成品的集合。Sarah Sachs 的對策是建立了一個叫做「Agent 開發速度」（Agent Dev Velocity）的平台團隊，專門負責評估框架和維護工具，讓每個功能團隊可以快速建立自己的評估、自己維護品質，而不是全部丟給一個中央團隊。

Simon Vortex 和模糊的管理邊界

Notion 的工程組織有一個特色：管理邊界非常模糊。Sarah Sachs 說，在 Notion 招聘管理者時，一個重要的篩選條件是「這個人在不在乎自己的團隊成員暫時去別的專案工作」。因為 Notion 的做法是先出貨、再建組織，而不是先畫好組織圖再分配工作。

團隊內部有一個半開玩笑的名詞叫「Simon Vortex」（Simon 旋風）。這是一種高速原型開發的工作模式：Simon Last 帶著一小群資深工程師，快速嘗試各種方向，方向可能每天都在變。這個模式的速度極高，但產出的程式碼也很「hackathon」，需要後續的生產化工作。團隊會維持一批信任的資深工程師，隨時可以加入或離開 Simon Vortex，不需要走什麼正式的調動流程。

這種組織方式能運作的前提是文化。Sarah Sachs 把它歸功於 Notion 長久以來的工程文化：不計較誰的功勞、願意砍掉自己寫的程式碼、不會因為「那是我寫的」就堅持保留。她估計 Notion AI 的 harness（Agent 執行框架）已經被重建了四到五次。如果團隊裡有人在第三次重建時說「我不想再重寫了，上次的版本明明還能用」，整個組織的迭代速度就會崩潰。

Sarah Sachs 特別提到了圖片生成功能進入 Notion 的故事。這個功能長期被認為「可能有價值但不是優先」。結果資料庫集合團隊的一位工程師 Jimmy 主動說他想做封面圖片的 AI 生成功能。團隊的反應不是「等我們排進路線圖」，而是「你想做就做，我們給你資源」。他們讓 Jimmy 直接對接 Gemini 的 API、提供 token 用量追蹤、給他評估支援。這個原型後來變成了正式的功能。Sarah Sachs 說，如果領導者太在乎「這個想法是不是我提的」，這種由下而上的創新就不可能發生。

從一個 system prompt 到一百個工具定義

Notion AI 團隊經歷過一個關鍵的組織轉型：從中央集權到分散式工具管理。

在早期，整個 Agent 的行為是由一個巨大的 system prompt 控制的，裡面塞滿了 few-shot 範例。任何修改都要經過五、六個人的審核，因為改動的順序、措辭、範例的先後，都會影響模型的行為。有研究顯示，不是所有的上下文都平等，放在 prompt 越前面的範例，模型會越聽話。所以這五、六個人實際上是在打一場微妙的排序戰爭，每個人都想讓自己的功能排在前面。

這個模式在 Notion 規模小的時候可以撐住，但完全無法跟上公司的成長速度。轉捩點是模型能力的進化。當推理模型出現後，Notion 可以從 few-shot 範例轉向「目標導向的工具定義」。不再是給模型看一堆範例說「照這樣做」，而是用自然語言描述每個工具的目標和約束，讓模型自己判斷什麼時候該用什麼工具。

這個轉變的組織意義比技術意義更大。一旦工具定義變成獨立的單元，每個產品團隊就可以擁有自己的工具定義，自己維護、自己做評估。不再需要所有人擠在同一個 system prompt 裡互相打架。原本的中央「卓越中心」團隊也轉型成了平台團隊，負責提供工具定義的框架和評估基礎設施，而不是親自編寫每個工具的行為。

Sarah Sachs 回憶，這個轉型對 Agent 的開發速度影響最大，大過模型本身的進步。不是因為新模型不重要，而是因為就算你有最好的模型，如果你的組織結構讓十個團隊都要排隊等一個人批准他們的工具定義修改，速度照樣快不起來。分散式擁有權才是真正的加速器。

會議紀錄：被低估的資料飛輪

在所有 Notion AI 的功能裡，Sarah Sachs 對會議紀錄（Meeting Notes）最為興奮。不是因為會議摘要的技術有多先進，而是因為它是一台持續運轉的資料擷取機器。

她用自己的例子來說明。每次跟主管的一對一會議都有 Meeting Notes。到了年底做自我考核時，她會告訴 Agent：「主要看我跟主管的所有對話記錄，寫出我今年做了什麼。」這個邏輯很簡單，如果你沒有在跟主管的一對一裡提到某件事，那件事大概就不值得放進績效考核裡。Meeting Notes 變成了一種優先序的信號。

Notion 內部團隊現在的運作流程是這樣的：開會前，一個 Custom Agent 會掃描 Slack 和 GitHub 的最新動態，自動產生一份「預讀」放進 Meeting Note 裡。開會時，大家圍繞預讀內容討論問題和下一步行動。開會後，另一個 Custom Agent 根據會議內容自動在任務資料庫裡建立待辦事項，發送需要跟進的 Slack 訊息。整個過程中，參與者不需要碰鍵盤，可以專注在問題的本質上，而不是會議的行政瑣事。

Simon Last 提到一個讓他驚喜的小功能：當 Meeting Notes 做摘要時，它會辨識文中提到的人名，然後通知那些人。所以如果有人在你不在的會議裡討論到你負責的專案，你會收到通知。這聽起來簡單，但背後的技術並不容易，Agent 需要判斷「Simon」是指哪個 Simon。Notion 為此建了人對人的相似度快取（similarity cache）和個人資料檔案（profile），讓 Agent 在做人名匹配時有更多脈絡可以參考。

Meeting Notes 也逼著 Notion 處理了幾個基礎設施的挑戰。會議逐字稿會產生大量的長文內容，對搜尋索引和 Agent 的上下文視窗都造成壓力。他們為此開發了內容壓縮（compaction）機制。Sarah Sachs 把 Meeting Notes 重新定義為一個「資料擷取」（data capture）問題，而不只是「會議摘要」問題，因為它的價值不在摘要本身，而在於它持續為 Notion 的知識庫注入新的信號。

所有人都在為 Agent 而建

Sarah Sachs 在訪談中反覆提到的一個概念是：Notion 正在從「為人類設計產品」轉向「同時為人類和 Agent 設計產品」。做 CRDT（無衝突複製資料型態）離線同步的團隊，同時也要處理兩個 Agent 同時編輯同一個區塊的問題。做 SQL 查詢引擎的團隊，同時也要確保 Agent 的查詢跑得夠快。這不是另開一條 Agent 專用的產品線，而是讓現有的每個服務都變成 Agent 友善的。

搜尋功能是一個典型的例子。Notion 的搜尋團隊現在同時在做兩件事：傳統的排序（ranking）最佳化，以及 Agent 專用的平行查詢策略。Sarah Sachs 透露，對 Agent 來說，向量嵌入（vector embedding）的重要性正在下降，反而是查詢多樣性（query diversity）變得更關鍵。Agent 會同時發出八個不同的搜尋查詢，盡可能涵蓋最大的搜尋空間。這跟人類的搜尋行為完全不同，需要不同的基礎設施最佳化。

這種「Agent 優先」的思維也延伸到外部夥伴關係。Sarah Sachs 提到，有穿戴裝置公司來找 Notion 合作，希望讓裝置蒐集到的資料能直接流入 Notion。她對此持開放態度，但也很清楚邊界：「我們的工作不是打造最好的穿戴裝置來擷取會議紀錄。我們的工作是打造會議紀錄最好的存放場所。」

這句話精準地總結了 Notion 在 AI 時代的策略。他們不需要贏在 Agent 的每一個技術維度上，他們需要贏在成為所有 Agent 產出的匯聚點。當每個團隊的文件、任務、會議紀錄、決策脈絡都在 Notion 裡時，Notion 的 Agent 自然比任何外部 Agent 更了解你的組織。這不是技術優勢，是資料飛輪。