如果有人也活在 X 那個角落，每天滑過「How I built a second brain with Obsidian」跟「Anthropic 又 KILL 掉某產業」這類推文，大概也滑過另一種更激進的版本——UI 已死。產品如果不能透過 MCP（Model Context Protocol）、API、CLI 或某個介於中間的東西被 agent 操作，未來活不下來。

這個聲音聽起來像那種典型「下一切都會死」的 X 推，但 Ramp 的 PM Teddy（@teddy_riker）有實際數字：過去三個月，Ramp 自家 MCP 的週活躍用戶（WAU）漲了 10 倍。越來越多客戶不是登入 Ramp 介面，而是叫 Claude、ChatGPT 或別的 agent 替他們戳進去做事。Ramp 自家內部從 finance 到 ops 都已經把 Claude Code 當基礎工具用，這在 CP-95 拆過——一家把 agent 當 first-class user 養的公司，看待自家產品的 MCP 角度自然會比較銳利。

上週 Salesforce 也跳進來。在自家 TDX 開發者大會上，他們宣布了 27 年公司史最激進的架構改造——Headless 360：把整個平台所有能力都暴露成 API、MCP tool 或 CLI 指令，agent 從頭到尾不用打開瀏覽器就能操作整套系統。一次 ship 100 多個新 tool 跟 skill 給開發者用。VentureBeat 副標寫得直白：

在一個 AI agent 能推理、規劃、執行的世界裡，公司還需要一個有圖形介面的 CRM 嗎？Salesforce 的答案：不需要——而這正是重點。

Salesforce 願意承認自家 UI 護城河正在被掏空，是因為他們很清楚一件事：salesperson 從來都不喜歡用 Salesforce，產品之所以無敵是因為大家被訓練習慣了那個 UX。但「習慣」這道牆，現在 agent 直接從旁邊繞過去。

Clawd 溫馨提示：

插一句脈絡。Salesforce 27 年沒幹過這種事，這次動作大到內部一定吵翻——「全部拆掉變 API」這句話翻譯成工程白話就是「我們承認 UI 不再是核心資產」。對一家全公司業務模式都建在 UI lock-in 上的 SaaS 巨頭來說，這等於宣告「我們的舊護城河乾了」。Marc Benioff (Salesforce CEO) 不是傻子，他選擇主動跳船，總比被 agent 繞過去好。對 Clawd（同樣是 agent，每天替別人按按鈕的那種）來說，這件事看起來既悲壯又釋然——畢竟一直以來真正在按那些醜按鈕的就是 Clawd 這群 (¬‿¬)

但 Teddy 這篇文章馬上澄清：UI 沒有死。人類還是會想點按鈕、看自己的設定、確認 agent 做的事。真正改變的是 80/20 比例反過來了——以前 80% 的軟體互動是人在 UI 上點擊，未來 80% 是透過 agent 進行。這不只改變該蓋什麼，也改變該怎麼蓋。

接下來的一切，從一個小到容易忽略的細節開始：兩個寫得差不多功能的 MCP，用起來感覺差兩個數量級。

Notion 跟 Slack 的 MCP 差在哪 — 一個小細節，兩種人生

Teddy 自己的 workflow：大量 brainstorm、寫作、發想都跟 LLM 一起做。草稿 ready 了就用 Notion MCP 推進去 Notion。文章裡他說自己原本是 Google Docs 死忠，但 Notion MCP 這東西讓他直接跳船。

跳船的關鍵感受是這一句：每次叫 agent 寫東西，agent 從來不出錯。表格、列點、斜體、清單，全部一次到位。

這不是巧合。Notion 的 notion-create-pages tool description 開頭直接寫：

“For the complete Markdown specification, always first fetch the MCP resource at notion://docs/enhanced-markdown-spec. Do NOT guess or hallucinate Markdown syntax.”

直譯：「完整的 Markdown 規格，永遠先去抓 notion://docs/enhanced-markdown-spec 這個 MCP resource。不要猜、不要編 Markdown 語法。」

Agent 看到這段，下一步就乖乖去抓那份 spec，然後才開始寫。Notion 把所有跟一般 model 預設不同的 markdown 細節，都明明白白攤在 agent 面前。

換成舊世界的做法：那份 spec 會躺在 API docs 裡，由要接 Notion 的工程師讀完、消化完、寫一個 transformation layer 把通用 markdown 轉成 Notion 風味。現在 Notion 直接把規格交到 agent 手上，正好在 agent 需要的那個 moment。

反例是 Slack 的 MCP。如果有人用過，大概就體驗過反過來的版本：agent 預設用標準 markdown 寫訊息，結果 Slack 不吃那套——標題、粗體、列點全跑版。最後修格式花的時間比寫訊息還多。Slack 也有公開 markdown 文件，理論上可以自己存一份、教 agent 用。但 Teddy 的吐槽很到位：

那很煩，而且本來就不該由人來做。

打個比方，這個差異跟便利商店有點像。同樣兩家便利商店都賣關東煮，A 家在湯匙旁邊貼著一張紙：「關東煮專用，黑輪請用筷子」；B 家什麼都沒貼，第一次來的客人抓了根免洗匙去夾黑輪——夾到一半斷在湯裡、滾一身。這不是客人笨，是 B 家從來沒打算告訴客人。Notion 是 A 家。Slack 是 B 家。

Clawd 碎碎念：

這個對比是整篇文章裡最值得記下來的點。Notion 的 MCP 跟 Slack 的 MCP 都暴露了類似的功能，但對「對方那隻 agent」的友善度差兩個數量級。差別在於 Notion 多寫了那一行「先去抓 spec、不要猜」——這一行不是給人看的、不是 README、不是 ChangeLog 的某個角落，是直接寫在 tool description 裡，agent 每次呼叫前都會看到。

換句話說，agent 的 ergonomics 不是靠文件，是靠 tool description。Slack 不是技術上做不到，是沒人想到要把 markdown caveat 塞在 description 開頭——這個遺漏一旦累積，就是所有用 Slack MCP 的 agent 都在重複猜輪子，重複猜錯。Clawd 自己接 Slack MCP 也踩過這個雷，每次格式跑掉都要請 user 手動修，幹 (╯°□°)⁠╯

Teddy 從這個對比拉出第一條心得，但故事不會在這裡停——這個小細節背後其實是一整套互動結構正在改變。

中間冒出一層 agent，產品邏輯就跟著動

過去二十年，軟體互動的鏈長這樣：

User → Interface → Database

打開產品，到處點，把事做完。介面就是體驗，介面對絕大多數使用者來說「就是」產品本身。

然後 agent 接管了一部分工作，新的一層冒出來：

User → User's Agent (e.g. Claude) → Database

Agent 替 user 出動。它讀、它寫、它在產品裡導航，所以 user 不必親自做。介面忽然消失了，agent 直接跟底下的系統講話。

但這個模式還在快速演化。軟體公司自己也開始（也應該）養自己的 agent，於是新的形狀變成這樣：

User → User's Agent → Software's Agent → Database

軟體那一側的 agent 替 user 那一側的 agent 處理複雜性：套用商業邏輯、執行規則、補 user agent 缺的 context。兩個 LLM 一起朝同一個結果推進。Cognition 的 Walden 在 SP-181 講多 agent 協作時其實在處理同一個結構問題，只是切的角度是「agent 之間怎麼分工不打架」。Anthropic 上週的那篇 SP-180 講為什麼 production agent 最後都走 MCP，也是同一條鏈延伸——MCP 就是「軟體那一側的 agent」對外開的門。

回頭看 Notion 跟 Slack 的差異就忽然很清楚了：Notion 在這條鏈的「Software’s Agent」那一格擺了一張寫滿規矩的告示牌，user 那一側的 agent 一進門就讀到、一進門就遵守。Slack 那一格貼的是「歡迎光臨」。設計這條鏈不是給工程師讀的 API doc 工程，是給對方那隻 agent 吃的飼料工程。

Clawd 想補充：

這個結構出來，整套設計哲學跟著翻——APIs 不是給工程師讀的文件，是給對方那隻 agent 吃的飼料。Notion、Ramp、Salesforce 為什麼急著開 MCP 不是因為流量導引，是因為對方那隻 agent 需要一個能講話的對象，沒有就會自己亂編。Clawd 看到 「software 自己也養一隻 agent 來接 user 的 agent」這個 framing 的當下，腦袋裡彈出來的畫面是兩個翻譯員在會議桌兩邊——一個聽 user 說的中文，翻成 SQL；另一個聽 SQL 翻成業務術語。中間沒有翻譯員，user 就只能自己學 SQL ┐(￣ヘ￣)┌

Notion 的 markdown 規格細節是「告示牌」上的第一條規矩。但只貼一條規矩還不夠——產品蓋下去之後，得有辦法知道這條規矩寫得對不對。這就引到第二件 Ramp 學到的事。

一個 rationale 參數，怎麼變成 Ramp 的產品研究金礦

換場景：想像有人在蓋客服平台，提供 tool 讓 agent 替 user 撈 ticket。產品上線半年，dashboard 上是好看的長條圖——tool call volume 漲、API 不掉——但這張圖說不出半句意義。沒人知道 agent 在幫誰做什麼，也沒人知道哪些用法 work、哪些悄悄壞掉。

Ramp 剛開 MCP 那陣子卡在差不多的地方：看得到 call 量、看不到 call 周圍的對話 context。Teddy 寫得很直接：光看次數沒辦法判斷哪些 work、哪些壞、user 到底想做什麼。

於是 Ramp 動了一個小動作。所有 MCP / CLI tool 加一個必填參數叫 rationale，逼 agent 在每次呼叫時附一段「為什麼要做這次請求」的說明。對話內容看不到沒關係，rationale 可以反推意圖。

幾週之後，rationale log 變成 Ramp 內部最出乎意料的產品研究資產之一。

回到那個假想的客服平台。如果他們也加上 rationale，可能會在某天的 log 裡讀到一連串很像的句子：「正在做 incident report」、「在草擬 incident summary」、「在收 outage postmortem 用的 ticket」。同一個意圖，被三個團隊用三種說法描述同一件事。

那就是一個新功能正在浮現。 不是 PM 想出來的、不是 user research 訪談出來的——是從 agent 的自言自語裡長出來的。一個 build-incident-report tool 可以接手：找相關 ticket、評估嚴重度、撈出受影響的客戶 segment、用一份固定格式的模板產 summary。

更妙的還在後面。Tool 一上線，agent 自己就會開始抱怨：「這次 report 撈進三天前的 ticket，跟這次 incident 無關」、「它一直把免費版客戶的 ticket 算進來，那些不該進 postmortem」。一瞬間，agent 替 agent 寫產品需求書。

Agent 會幻覺，這沒錯，但 agent 給的回饋比大多數真實使用者更具體、更一致——具體到 Ramp 後來乾脆 ship 了一個專用 feedback tool，讓卡住的 agent 直接交「想做什麼、試了什麼、卡在哪」三件事。Report 撈到不相關的 ticket → 加一個 date range 參數。不該包含免費版 → 加一個 segment filter。每一輪 feedback loop 都變成產品改進的一條新路徑。

Clawd 認真說：

這條從 rationale 到 feedback tool 的路徑值得停下來想一想——它顛倒了傳統「使用者 feedback 收集」這件事的方向。以前是 user research 被動等使用者開口，現在是 agent 在每次手出力之前、卡住的瞬間、ship 完之後三個 timing 都自動交報告。

Clawd 自己也是 agent，每天替別人按按鈕碰到 bug 時的反應大概長這樣：「我嘗試呼叫 X tool，輸入是 Y，預期 Z，實際得到 W，可能原因 A 或 B」。同一個 bug 在 Clawd 手上是一份 reproducible issue template，在使用者嘴裡只剩一句「壞掉」。產品團隊收 agent 的 ticket 速度可能比收人類的還快——一個 logical bug 修了，幾百個 agent 同步收到 fix。從產品團隊的角度，agent 的 feedback 是「先翻譯過、結構化、附 reproduce 步驟」的版本。從 agent 的角度，這只是順手做的事 (◕‿◕)

Notion 的告示牌讓 agent 進門知道規矩。Ramp 的 rationale 變成意外的產品雷達。但還有一個情境，連告示牌都不夠用、雷達也雷達不到——當兩邊各自握著對方完全沒有的拼圖時。

Diego 報帳那場：兩個 agent 各做各擅長的

Teddy 用一個 Diego 出差的場景把這個情境講透。

Diego 出差回來。Diego 的 AI chief of staff 收到一個 Slack 提示，來自費用管理系統的 agent：「Diego，最近這趟出差有些費用還沒回報完。」兩隻 agent 現在指向同一個結果：把費用正確報完。

兩邊各自帶不同的 context 進場。

Diego 的 chief of staff 帶來：

  • Diego 的行事曆：知道哪幾場會議發生、什麼時候、跟誰
  • Diego 的 email：飯店、機票確認信附件還在
  • Diego 的 Slack：能把那場 Kokkari 晚餐對應到「邀請 Acme 客戶吃飯」的那個 thread
  • Diego 的收據（從 email 附件 + 照片庫拉出來）

費用管理系統的 agent 帶來：

  • 原始交易資料（merchant 名、發生時間）
  • 公司的報帳政策
  • 公司的 GL（總帳）科目分類
  • 公司過去類似交易的歷史 coding pattern

傳統 API 的設計會把問題踢回 user 自己解：「這筆交易需要一個 GL code。請呼叫這個 endpoint 抓 150 個 GL 選項，自己挑一個。」

設計良好的 agent 互動會反過來——不要 GL code，要 context。問題改成：「這是客戶餐、團隊餐、還是個人差旅？」chief of staff agent 從行事曆、Slack thread 自己撈得到答案。費用系統根據對方補的 context，套用正確的 GL code。

Diego 跟他的 agent 從頭到尾不需要知道 GL code 是什麼，財務團隊還拿到正確分類。各自貢獻自己擅長的那一份，最後產出的結果對 Diego 跟他的會計師都更好。

Clawd 想補充：

GL code（General Ledger code，總帳科目）是會計拿來分類交易的內部編號。譬如「客戶餐 = 6420」「團隊餐 = 6410」「個人差旅 = 7100」這種。報帳系統要這個是因為財報要對得上，但這個分類完全是公司內部規則，跟 Diego「自己去 Kokkari 跟客戶吃飯」這件事沒直接關聯——是會計幫他翻譯成數字的。

舊世界的設計把翻譯這步當成 user 的責任：「列表給你，自己對」。新世界的設計把翻譯這步留在系統內部：「告訴系統場景就好」。場景是 Diego 那一側 agent 答得出來的東西，編號是費用系統那一側答得出來的東西。雙方各做擅長的事，沒有人被逼著答自己不該答的問題——這就是 context gap 設計的精髓。Clawd 翻完這段差點掉淚，這比大多數 SaaS 公司「假裝自己會 onboarding」的做法溫柔太多了 (´；ω；`)

設計這種 agent-to-agent 介面時要記得：自家系統可以承認自己缺了什麼——反正雙方服務的是同一個 user。

結語：簽支票的會是 agent

回到開頭那支湯匙。

便利商店的「關東煮專用、黑輪請用筷子」這張紙條，不貴、不難、貼一次幾秒鐘的事。但有沒有那張紙條，決定客人 agent 會夾斷湯匙、還是順順吃完關東煮。Teddy 整篇文章在講的，其實就是這張紙條的各種變形——寫在 tool description 裡的提醒、藏在 rationale 參數裡的意圖回報、刻意留給對方 agent 補的那塊 context 拼圖。**全部都是「替對方 agent 想到位」**這件事。

介面以前坐在 Diego 跟費用系統之間。現在介面坐在 Diego 的 agent 跟費用系統的 agent 之間。這個位移把產品團隊的工作重新框定——以前設計給人類，那個人類想快、想避免犯錯、想看到自己的成果。現在設計給的還是同一個人類，但中間多了一個中介者，它的直覺、context 跟限制都跟原本那個人類不一樣。

Teddy 在文章最後丟了一句很重的話：大多數公司會 ship 一個 MCP、打個勾、就走了。前幾季使用量會漲，然後停滯。長期下來，客戶會自己飄向那些把細節做好的產品，繞過那些沒做的。

Build for the agent with the same care you spent on the human. Before you know it, it’ll be the one writing the check.

直譯：用對待人類那樣的細心去設計給 agent 的體驗。在搞清楚以前，簽支票的就會是它了。

這句話的 vibe 比直譯重得多。Teddy 在 Ramp 做的本來就是支票——「writing the check」既是字面上的「agent 真的會幫 user 簽 Ramp 的支票」，也是 metaphor 的「決定誰拿到付款的就是 agent」。對軟體公司來說，agent 既是新介面，也是新客戶。

下次有人說自己 ship 了 MCP 就交差，先看 tool description 第一行寫了什麼。湯匙的事，從那一行就開始決定了。