每六個月砍掉重練：Notion 的 AI 開發哲學

本文整理自《No Priors》2026 年 3 月播出的單集。

{{< youtube 1dYThQgOyZU >}}

{{< spotify "episode/33TEE8FPYupsQecWy6Tvqi" >}}

{{< apple-podcast "tw/podcast/from-coder-to-manager-navigating-the-shift-to-agentic/id1668002688?i=1000754826750" >}}

---

大部分公司搞砸 AI 整合的方式都一樣：做了一版，覺得不錯，然後就不動了。Notion 共同創辦人賽門·拉斯特（Simon Last）在《No Priors》Podcast 上直言，這是他看到最多團隊犯的錯。Notion 的做法完全相反，他們的 AI harness（包裝在模型外面的整套系統設計，從 prompt 架構到工具呼叫到檢索流程）大概每六個月就重寫一次。而且重寫的週期正在縮短，因為 AI 技術的進步速度在加快。

拉斯特說這句話的語氣不像在抱怨，反而帶著一種樂趣：「我覺得這挺好玩的，這就是過程的一部分。你可以重新開始、重新思考。」他透露受訪當下正在準備發布新一版的 harness，預計一兩週後上線，而且團隊已經在規劃再下一版了。在 Notion 內部，重寫 harness 幾乎已經變成一個固定的節奏，就像季度規劃一樣自然。

為什麼做一次就收工是最大的錯誤

拉斯特的解釋很直白：因為模型一直在變，你的系統設計必須深度配合當前模型的能力和特性。做了一版 harness，就算當下效果很好，半年後模型進步了，你的設計就不再是最佳方案。如果你不重新審視整個系統，就等於在用去年的假設跑今年的模型。他認為保持對模型和技術現狀的「敏銳覺察」是關鍵，然後要把這個覺察轉化成具體的系統設計決策，而不是停留在「好像模型又更新了」的模糊感覺。

這個觀點在 AI 工程圈並不新鮮，但 Notion 的執行力讓它有了說服力。大部分團隊嘴上說要持續迭代，實際上是因為重寫的成本太高而一直拖延。Notion 做得到六個月一次，有一個很重要的推手：coding agent。拉斯特自己從 2025 年初開始全面使用 coding agent，重寫系統的野心和可行性都大幅提升。agent 可以端到端地執行實作、驗證、維護，這意味著一個重大的系統重寫不再需要動員整個團隊花數月時間。它變成一個經過精心設計的任務，可以交給 agent 去跑。拉斯特的個人紀錄是讓一個 coding agent 連續執行 13 天不停，就在持續處理任務清單。

但 coding agent 不是魔法。拉斯特用了一個很精準的對比：如果你用得好，你可以比以前更有野心，成果更穩健。但如果用得差，產出就是純粹的 slop（劣質品）。重點不是有沒有用 agent，而是你對任務架構和驗證迴圈的設計有沒有到位。在這個脈絡下，「每六個月重寫一次」不是因為 Notion 喜歡推倒重來，而是因為他們有能力快速重建，同時清楚知道不重建的代價更高。

搜尋做不好，不是因為技術不夠

Notion 在建立 Q&A 功能的過程中，做了一件讓拉斯特自己都覺得意外的事：他們的搜尋索引品質，竟然比很多被搜尋的原生平台自己做的還好。Notion 不只索引了自家的內容，還擴展到 Slack 和 Google Drive。拉斯特說他們原本有點猶豫，畢竟「我們有什麼資格去索引別人的平台？」但做了之後發現，很多大公司的搜尋索引做得「出奇地差」，「老實說我們也有點困惑。」

他把原因歸結為兩件事。第一是需要一點「AI-pilled savviness」，也就是對 AI 技術有足夠深入的理解和直覺，知道什麼東西可行、什麼不可行。但他認為更重要的是第二點：手藝（craft）和對細節的執著。每一個資料來源都有自己的特性，你不能用同一套方法去查詢 Slack 訊息和 Google Drive 文件，因為它們是完全不同的資訊類型。要把檢索做好，你必須非常經驗主義地去做：實際試各種查詢、每天都在用、不斷重新調整檢索的方式和參數。

嵌入（embedding）技術改變了工作空間組織的邏輯。拉斯特觀察到，有了 embedding 之後，資料的樹狀結構其實不太重要了。AI 不在乎你的資料夾層級怎麼排列，它在乎的是某一段文字裡有沒有包含它需要的上下文。所以 Notion 現在給使用者的建議反而是：不要太執著於組織方式，重要的是把所有資訊都丟進來。但在技術端，chunking 策略（文本分塊方式）仍然極其關鍵，只是這對使用者來說是透明的。分塊的大小怎麼決定、檢索流程的各個步驟怎麼串接、多階段檢索的架構怎麼設計，每一個環節都需要大量的迭代和微調。拉斯特說 Notion 花了很長時間才把這套東西打磨到位，而且他們還在持續調整。

設計師也在建 Git Repo：全公司的建造能力都在膨脹

Coding agent 帶來的變化不只發生在工程團隊。拉斯特舉了 Notion 設計團隊的例子：他們自己建了一個 Git repo，取名叫「Design Playground」。這是一個簡化版的 Notion，內建了一組 UI 基礎元件和一個 agent。設計師可以用它快速產出高保真度的原型，而且是真正可以部署、可以點擊互動的原型，不是 Figma 裡的靜態畫面。拉斯特很明顯對這件事感到驕傲：以前設計評審是指著靜態稿說「想像一下這個效果」，現在是丟一個跑起來的原型網址給你看。

這種現象在整間公司的各個層級都在發生。所有的 PR 都變得更有野心，更多人在嘗試以前不敢嘗試的東西。整體氣氛變得「更混亂、更吵雜」，但拉斯特覺得那是好事。更多的原型代表更多的實驗，更多的實驗代表更快找到正確的方向。當然，混亂也帶來風險。拉斯特提到他們仍然對每一個 PR 做 code review，而且現在的 PR 都是 agent 寫的，通常更大、更複雜。review 的負擔確實增加了。但另一面是，這些 PR 的測試覆蓋率比過去好得多。拉斯特說他現在不會送出任何一個沒有經過完整端到端測試的 PR。

寫程式的門檻降低之後，受惠的不只是工程師。設計師以前想做互動原型，要不就是自學前端，要不就是排隊等工程師幫忙，兩條路都很慢。現在有了 agent，他們可以用自然語言描述想要的效果，agent 把程式碼寫出來。拉斯特觀察到，一旦非技術人員越過「什麼是 prompt、agent 怎麼觸發」這些初始門檻，agent 的互動方式其實非常自然。他的說法是：「這本質上是一個非常像人類的介面。」在 Notion 內部，他會定期辦工作坊和 hackathon 來降低這個門檻，而且效果比他預期的好。人資團隊已經是 Custom Agents 的最高採用者，因為他們原本就有大量在 Slack 和 Notion 之間來回搬運資訊的手動工作。

我的觀察

臺灣有不少團隊在 2024、2025 年做過一輪 AI 功能整合：串了一條 RAG pipeline、寫了一組 prompt、可能接了個 chatbot，然後就進入維護模式。拉斯特的「每六個月砍掉重練」哲學對這些團隊來說是一個警訊。你半年前建的那套系統、你對模型能力的那些假設，到今天很可能已經不是最佳解了。模型每隔幾個月就有一次能力跳升，如果你的 harness 沒有跟著重新設計，你就是在用舊版的假設去操作新版的引擎，白白浪費了新模型帶來的改進空間。

「重寫」聽起來很嚇人，所以大部分團隊選擇不動。但 Notion 能做到這件事的關鍵，不是因為人多或錢多，而是因為 coding agent 讓重寫的成本大幅下降。拉斯特一個人就可以設計端到端的任務、交給 agent 執行、隔天早上驗收成果。這對臺灣的中小型團隊其實是好消息：如果你能善用 coding agent，你的迭代速度可以比你以為的快得多。至於搜尋索引的部分，「手藝和細節」這個答案可能不是大家想聽的，但它確實是事實。好的 AI 產品不是靠一個聰明的 prompt 就能撐起來的，而是靠無數次嘗試、測試、調整所累積的工程品質。沒有捷徑，但這種品質本身就是護城河。