Notion 共同創辦人：「去年夏天之後，我再也沒打過一行程式碼」

本文整理自《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" >}}

---

Notion 共同創辦人賽門·拉斯特（Simon Last）最近在 AI Podcast《No Priors》上說了一句讓人停下來想的話：「去年夏天之後，我就沒有再打過程式碼了。」這不是一個轉管理職的前工程師在感慨往事。拉斯特是 2013 年就和 Ivan Zhao 一起從零打造 Notion 的技術核心人物，至今仍然每天深度參與產品開發。差別在於，他現在做的事情已經完全不一樣了。他給自己的新頭銜是「Agent Manager」，一個管理 AI agent 的人。

他的日常是這樣的：用 Claude Code 或 Codex 這類命令列工具，同時開好幾個 coding agent 跑任務。每天睡前，他會確認手上的 agent 都有足夠的工作量，「我要確保給它們夠多的事做，這樣到我早上醒來的時候，它們還沒做完。」他的個人紀錄是讓一個 coding agent 連續執行了 13 天，不間斷地逐一處理任務清單。這不是炫技，而是一種新的工作節奏。

從 Tab Complete 到 Agent Manager：三次角色轉換

拉斯特把過去幾年工程師使用 AI 工具的演變分成三個階段。第一個階段是 tab autocomplete，也就是寫程式寫到一半，AI 幫你補完下一行。這個階段的本質沒有改變工程師的角色，你還是那個打字的人，只是打得快了一點。第二個階段開始出現可以對話的 agent，你告訴它要做什麼，它幫你完成小任務，但工程師仍然在「外層迴圈」裡，隨時介入、隨時修正。這階段的感覺比較像有了一個很聽話但需要盯著的助手。

真正的斷裂點發生在 2025 年初。拉斯特大概在去年四月開始使用 Claude Code，他形容那次經驗是「一個巨大的解鎖」。從那時起，工作方式徹底翻轉。現在他做的事情是：設計一個端到端（end-to-end）的任務，包括要做什麼改動、怎麼驗證改動是正確的，然後把整個任務交給 agent 執行。他自己只負責最後的外層驗證，確認結果正不正確，以及在 agent 跑偏的時候介入監控。「所以現在完全反過來了，我現在就是那個 agent manager。」

這種工作方式有一個嚴格的前提：你必須對任務架構想得非常清楚。驗證迴圈怎麼設計、怎麼確保結果是可靠的、出錯的時候怎麼回復，這些都需要工程師花大量心思去規劃。拉斯特對此給了一個很精準的評價：如果做得好，你可以比以前大膽得多，蓋出比純人寫還穩健的東西。但如果做得差，「全部都是 slop（劣質品）。」工具的天花板很高，但地板也可以很低。決定你在哪裡的，是你對任務的設計能力，不是你的打字速度。

100 倍工程師不是傳說，差距正在被工具拉開

主持人 Sarah Guo 問到 AI 工具對工程團隊結構的影響時，拉斯特給了一個直接的判斷：「如果你現在把工具用好，你可以是 100 倍甚至 1000 倍的工程師。」他接著補充了一個微妙但重要的區分：最低門檻沒有變，但最高天花板大幅提升了。換言之，不是每個人都變強了，而是願意且善於使用工具的人，產出跟其他人之間的差距被急劇放大。你的產出越來越取決於你使用工具的能力和意願。

這種變化在 Notion 內部的體感是「更混亂、更吵雜」。拉斯特說他其實挺喜歡這種感覺。原型變多了，到處都有人在試新東西。他舉了一個例子：Notion 的設計團隊自己建了一個 Git repo，叫做「Design Playground」。那是一個簡化版的 Notion，裡面裝了一堆 UI 元件，還內建了一個 agent。所有設計師都可以用它快速做出高保真原型，而且是真正部署上線、可以點擊互動的那種。以前設計師指著靜態的設計稿說「效果大概是這樣」，現在他們直接丟一個原型網址給你看。拉斯特說，這種現象在整個公司從上到下都在發生，所有的 PR（pull request）都變得更有野心了。

野心提高不代表品質失控。他們仍然對所有 pull request 做 code review。是的，現在每一個 PR 都是 agent 寫的，通常更大、更複雜，review 起來確實更費力。但另一面是，這些 PR 的測試覆蓋率也比過去好得多。拉斯特說他現在不會送出任何一個沒有經過完整端到端測試的 PR。關鍵的區別在這裡：你不能只是「vibe coding」，隨口跟 agent 說你想要什麼就結束。你需要認真想清楚，我要做什麼改動？怎麼驗證？怎麼安全部署？然後讓 agent 在這個框架裡幫你執行。

Email 分類、Bug 路由：Agent 如何接管日常瑣事

除了用 coding agent 開發產品之外，拉斯特也深度使用 Notion 自家的 Custom Agent 處理日常工作。他最喜歡的是一個 email triage agent。這個 agent 連接了他所有的工作和個人信箱，每天自動醒來，把他不需要看的郵件全部歸檔。他說自己收到的 email 裡，95% 是不需要他看的。有了這個 agent 之後，打開信箱就只剩下真正需要處理的東西，email 問題徹底解決。

訓練過程出乎意料地簡單。你建一個 Custom Agent，給它 email 存取權限，再建一張空白頁面當作它的「記憶」，讓它可以編輯那張頁面。然後你跟它說：去看我的信箱，然後來訪談我，問我哪些該歸檔、哪些不該。它會提出建議，你糾正，它就把這些規則寫進記憶頁面。頭幾天需要頻繁糾正，但大概兩週之後，拉斯特就完全放手了，不再需要核准，agent 自己就能做出正確的判斷。

他還建了另一個 agent 來處理 Notion 內部的產品回饋和 bug 報告。Notion 有一個 Slack 頻道，所有人都可以在裡面貼回饋和回報 bug。過去這些訊息有時會被回覆，有時就被淹沒了，因為太多團隊、太多訊息。這個 agent 的唯一工作就是把每一則回饋路由到正確的團隊，然後在那個團隊的資料庫裡建一筆任務。它用的也是同樣的「記憶模式」，隨著時間累積了數百條路由規則。例如看到行動 App 相關的 bug，就自動路由到行動團隊的資料庫裡。拉斯特一開始會去看那張記憶頁面，確認 agent 學到的規則合不合理，但後來就不看了，「如果它壞了，我再去修。」

從這兩個案例可以看出一個共通模式：先建原型、進入核准模式（你盯著它、隨時糾正）、累積足夠信任之後放手讓它全自動運作。偶爾壞掉就去修。這種從「有人監督」到「完全自主」的過程，其實跟你帶一個新進員工上手的邏輯一模一樣。只是這個「員工」不會累、不會忘記規則，而且 24 小時都在值班。

我的觀察

臺灣工程師社群這兩年最焦慮的問題大概就是「我會不會被 AI 取代」。拉斯特的觀察提供了一個具體的答案：不會被取代，但差距會被拉開到你可能還沒準備好的程度。他說最低門檻沒有變，意思是你還是需要懂程式、懂系統架構、懂怎麼設計驗證迴圈。但最高天花板「極度提升了」，而你在那條光譜上的位置，完全取決於你願不願意把工具用到極致。100 倍的差距不是在寫程式速度上，而是在「你敢不敢讓 agent 連跑 13 天」這種工作模式的根本性轉變。

最實際的收穫可能是這個：停止把 coding agent 當作進階版的 autocomplete。拉斯特描述的工作方式，核心不是「讓 AI 幫我打字」，而是「我負責設計任務、定義驗證標準、監控執行品質」。這其實更像一個技術主管在做的事。你需要想清楚：這個任務的邊界是什麼？成功的定義是什麼？agent 跑偏了怎麼辦？這些問題的答案，決定了你是在做「vibe coding」還是真正的 agent-augmented engineering。工程師的職稱沒有變，但工作內容已經從「寫程式碼」變成「設計讓 agent 能正確執行的框架」。這個轉變正在發生，不是在未來，是現在。