不需要會寫程式碼也能做 AI：Notion 為什麼發明了『模型行為工程師』這個職位

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

---

看 Google Sheets 說好壞的人

在 Notion 的 AI 團隊裡，有一群人每天的工作是盯著 Agent 的對話紀錄，判斷哪些回應是好的、哪些是壞的、為什麼壞。他們不寫產品程式碼，不訓練模型，不設計介面。但 Notion AI 工程負責人 Sarah Sachs 說，沒有這群人，Notion 的 Agent 品質根本撐不住。

這個角色叫做「模型行為工程師」（Model Behavior Engineer，簡稱 MBE）。它的起源很草根。Sarah Sachs 在 Latent Space Podcast 上回憶，MBE 最早的職稱叫「資料專家」（Data Specialist），是在她加入 Notion 之前就存在的。當時 Notion 共同創辦人 Simon Last 正在開發 AI 功能，需要有人幫忙看 Google Sheets 裡一大堆模型的輸出結果，逐一標記「這個好」「這個不好」。所以他們找了兩個人：一位是語言學博士中途輟學的研究者，另一位是史丹佛剛畢業的新鮮人。這兩個人的背景跟傳統軟體工程師完全不一樣，但他們有一個共同特質，就是對語言品質極其敏感。

隨著 Notion AI 的功能越來越複雜，從簡單的文字生成到多步驟的 Agent 工作流程，MBE 的角色也跟著演化。他們不再只是看試算表打勾，而是開始定義什麼叫做「好的 Agent 旅程」，建立評估框架，甚至用 coding Agent 來自動撰寫評估測試。Sarah Sachs 說，現在 MBE 團隊有專屬的主管，正在為 coding Agent 時代重新定義這個角色的內涵。

三層評估：從及格到天花板

Notion 的 Agent 評估系統分成三層，每一層的目的和標準都不同。Sarah Sachs 在節目裡說，當人們籠統地說「我們有做 evals」，就跟說「我們有做測試」一樣模糊，完全沒有說出什麼有意義的資訊。

第一層是類似單元測試的回歸測試，直接跑在 CI/CD 流水線裡。這些測試必須通過一定的比例（考慮到模型輸出的隨機性，不會要求百分之百），才能讓程式碼合併。每個產品團隊擁有自己的評估，因為每個工具的品質標準不同。當新的模型版本發布、或者某個工具定義被修改時，這些測試就會自動跑起來，如果出現重大退步，會有一個 Custom Agent 自動通知相關團隊去檢查。

第二層是「成績單」（report card）評估。這是產品上線前的品質關卡。團隊會定義一組使用者旅程（比如「郵件分類」「PDF 匯出」），然後要求 Agent 在這些旅程上達到 80% 到 90% 的通過率才能發布。這些評估比 CI 測試更貼近真實場景，也更費時，通常不會每次提交都跑，而是在重要的里程碑時執行。

第三層最特別，Notion 叫它「天花板評估」（headroom evals）或「前沿評估」（frontier evals）。這些評估的目標通過率是 30%。沒寫錯，就是只通過三成。為什麼？因為如果一組評估已經被現有模型通過了九成，那它就失去了指引方向的能力。天花板評估代表的是 Notion 對未來的想像：在理想世界裡，Agent 應該能做到什麼？它們的存在不是為了判斷現在的品質，而是為了追蹤進步的速度和方向。

Notion 的最終考試

Sarah Sachs 透露，大約在 2026 年初，Notion 的標準評估集遇到了飽和的問題。新模型發布時，團隊能給出的回饋只剩「沒有變差」，但無法說出「在哪些方面變好了」或「接下來應該往哪裡進步」。這對他們的模型供應商夥伴（主要是 Anthropic 和 OpenAI）來說用處不大，對 Notion 自己也沒有策略價值。

所以他們啟動了一個內部稱為「Notion 的最終考試」（Notion's Last Exam）的計畫。概念來自 AI 研究社群的「人類最終考試」（Humanity's Last Exam），但聚焦在企業知識工作的場景。這組評估刻意設計得很難，涵蓋了 Notion 對未來工作方式的願景：Agent 能不能在不同的資料庫之間交叉比對？能不能理解會議紀錄裡的隱含意圖？能不能在執行任務前主動確認模糊的指令？

這個計畫有專職人力：一位資料科學家、一位模型行為工程師、一位全職的評估工程師，他們只做通過率 30% 的那些評估。Sarah Sachs 強調，這些評估不只是給 Notion 內部用的，也會分享給合作的前沿模型實驗室，幫助它們理解企業工作場景的需求。Notion 的回饋往往跟 coding Agent 場景不同，而模型實驗室在選擇最終要發布哪個模型快照（snapshot）時，確實會考慮這些來自 Notion 的測試結果。

Simon Last 更進一步，他最近在推動把整個評估系統變成一個 Agent 可以操作的 harness。理想狀態是：一個 Agent 可以端到端地下載資料集、跑評估、分析失敗案例、除錯、然後實作修正。人類的角色變成觀察和維護這個外層系統，而不是手動跑每一步。Sarah Sachs 補充，這就像你會讓 coding Agent 寫單元測試一樣，你也應該讓 Agent 寫 Agent 的評估。但她強調，這裡面仍然需要大量的人類監督，而這個監督不一定要來自軟體工程師。

品味、直覺和「好旅程」

MBE 角色最獨特的地方在於它的進入門檻。Sarah Sachs 反覆強調，這不是一個需要軟體工程背景的工作。

她用了一個詞來描述 MBE 最核心的能力：「品味」（taste）。這個詞聽起來模糊，但在 Agent 開發的脈絡裡有非常具體的意思。當你看一段 Agent 的執行軌跡，包含幾十個工具呼叫和幾千字的輸出，MBE 要能快速判斷：這個旅程是好的還是壞的？如果是壞的，是哪一步出了問題？是工具定義不夠清楚？是模型選錯了工具？還是任務本身就不該由 Agent 來做？

這種判斷需要的不是寫程式的能力，而是對使用者體驗的深度理解、對語言模型行為模式的直覺，以及定義「好」和「壞」的標準的能力。Sarah Sachs 回憶，在 MBE 團隊的早期，Simon Last 曾經花一個下午在白板上教他們怎麼用 GitHub，因為他覺得如果 MBE 能直接把修改提交到程式碼裡，效率會高很多。那是一年半前的事了。現在有了 coding Agent，寫程式碼的門檻大幅降低，MBE 可以直接用自然語言描述問題，讓 Agent 幫忙寫 LLM 評審（LLM judge）或者產生新的測試案例。

MBE 的工作內容介於資料科學家、產品經理和 prompt 工程師之間。分析面，要能從大量的 Agent 紀錄中找出模式和異常。策略面，要能判斷什麼改進方向值得投資。技術面，要能微調工具定義和系統指令來改善模型行為。但 MBE 不需要是任何一個領域的專家。真正關鍵的是跨領域的連結能力和對品質的執念。

不是每個人都要當工程師

Notion 對 MBE 的定位不只是「一個新職位」，而是「一條新的職涯路徑」。Sarah Sachs 明確表示，MBE 不是軟體工程師的替代品或入門版，它有自己的成長軌跡和晉升標準。

這個立場在科技業裡是少見的。大多數公司的 AI 相關職缺仍然要求電腦科學學位或多年的軟體開發經驗。Notion 的做法是刻意歡迎「不合常理的人」（misfits）。語言學背景的人能理解語言模型的輸出品質，心理學背景的人能定義什麼是好的使用者旅程，新聞學背景的人能快速判斷事實的正確性。這些能力在 Agent 品質管理中都極有價值，但在傳統的軟體工程招聘流程裡完全會被過濾掉。

整個 MBE 角色的演進，也折射出 AI 開發中一個更大的趨勢。Simon Last 觀察到，每個軟體工程師在 2026 年夏天都經歷了一場身份危機，就像每個管理者剛升管理職時經歷的那樣。工程師們突然發現，自己寫程式碼的能力變得不那麼重要了，更重要的是委派工作、切換脈絡、管理外層系統的能力。這種轉變不舒服，但不可避免。

MBE 的存在提供了一個不同的入口。如果你對語言敏感、對品質有執念、對 AI 的行為模式有好奇心，你不需要先花四年學電腦科學才能進入這個領域。你需要的是願意不斷學習、願意跟模型一起進化的心態。在一個模型能力每隔幾個月就大幅躍進的世界裡，過去的技術棧經驗反而可能是包袱，因為你會不自覺地用舊的方式解決新的問題。

Sarah Sachs 說得很直白：她的團隊需要的人，是那種看到一段 Agent 對話就能說出「這裡不對勁」的人，然後能解釋清楚為什麼不對勁、應該怎麼改。這種能力，你在任何學歷背景裡都可能找到。