Day 03｜先別急著做 Tool，我把活動網站自己走了一遍

本文同步自 2026 iThome 鐵人賽原文 。完整系列可見 iThome 系列頁 。

安安～我是ChiYu～

昨天把專案切到固定 tag，Web、API、測試和 build 也都跑起來了。照這個進度，今天最容易做 的事情，就是立刻替網站加上第一支 WebMCP Tool。

但我先把 Inspector 關掉。

不是它做錯了什麼，只是今天還輪不到它上班。我想先用一般使用者的身分，從活動列表開始， 親手搜尋、看詳情、收藏，再一路走到報名與取消。如果連我自己都說不清楚任務從哪裡開始、 改了什麼狀態，以及哪一步必須停下來，Agent 只會很有效率地把混亂重播一次。

按鈕也不能直接等於 Tool。把「搜尋活動」「收藏活動」「確認報名」翻成三個英文名稱，catalog 確實會立刻變熱鬧，產品邊界卻還是一團霧。今天真正要整理的是 Human-first Journey：使用者 想完成什麼、網站回了什麼，以及決定權最後留在誰手上。

活動網站剛好能放進不同風險的操作：搜尋與查看詳情是唯讀；收藏會改變 session 狀態，但還能 Undo；報名與取消會影響使用者權益，送出前應該讓人看清楚內容。這些已經足夠，不需要為了讓 Demo 看起來更豪華，再搬來付款、OAuth 和管理後台。

今天固定使用同一筆公開活動：

活動資料固定後，搜尋結果、route、測試斷言與後面的 Inspector trace 才能互相核對。文章若 寫「前端高峰會」，程式卻回傳「WebMCP 入門工作坊」，兩邊就算都亮綠燈，也只是各自成功， 拼不起同一條證據鏈。

圖 1：三條 Journey 都先由人類走過一次。後面加入 Agent 時，才知道它可以協助到哪裡，又該在哪裡停下來。

用可見表單完成搜尋，沒有 WebMCP 也要能用

開啟 http://127.0.0.1:5173/events，設定：

• 地點：台北
• 費用：免費
• 程度：入門

按下「搜尋活動」後，結果只留下 evt-webmcp-intro，也就是「WebMCP 入門工作坊」。卡片顯示 日期與摘要，接著由「查看詳情」進入下一步。

圖 2：人類使用可見表單完成搜尋；右下方 audit trail 記錄的是 human 操作。

我刻意確認這條流程在沒有 document.modelContext 時仍能使用。WebMCP 在這個專案裡扮演 progressive enhancement；瀏覽器不支援，使用者照樣可以填表單、按搜尋、讀取結果。若加完 Agent 能力後，人類反而不能用了，那比較像換了一扇新門，順手把原本的門封起來。

搜尋找到活動後，下一個問題也跟著出現：網站要怎麼知道使用者目前正在看哪一場？答案不能 靠 Agent 猜 current 或 active，而是交給詳情 route。

詳情 route 決定目前活動，收藏狀態交給 Server

按「查看詳情」後，route 變成：

/events/evt-webmcp-intro

詳情頁列出 2027 年 1 月 23 日 10:00–12:00、台北前端共學空間與剩餘 8 名。使用者可以收藏 活動，也可以前往報名。收藏成功後，按鈕與狀態訊息會同步更新；再按一次只會得到冪等結果， 不會多塞一筆相同資料。

圖 3：詳情 route 提供完整活動上下文；收藏是低風險寫入，報名則進入另一個流程。

route 在這裡不只是拿來顯示網址。它直接回答「目前是哪一場活動」，讓畫面、API 與後續 Tool 共用 evt-webmcp-intro。等 Agent 進場後，也不必拿看似合理、其實查無此人的字串代替活動 ID。

收藏則示範低風險寫入該怎麼呈現。它會寫入目前 session，畫面立即顯示已收藏，也提供 Undo。 重新整理後，狀態仍由 Server 回傳，不靠按鈕文字自說自話。不過它依然只是 session Demo， 不能假裝成永久帳號收藏。

收藏做錯還能 Undo，報名就不能這麼隨便。接下來我把資料填好，但不讓任何自動化替人按下 最後送出。

報名與取消先準備，最後一步留給人類

從詳情頁前往：

/events/evt-webmcp-intro/register

報名頁顯示活動、姓名與 Email。表單可以先帶入資料，按鈕則明確寫著「我確認並送出報名」。 只有人類真的按下它，/registrations 才會出現一筆有效報名。

圖 4：填好欄位不等於已報名；正式 POST 發生在人類確認之後。

「我的報名」頁也沒有放一顆按下去就直接刪除的按鈕。使用者先選「準備取消」，看完活動名稱 與取消後果，再決定保留報名或確認取消。兩條高影響流程使用同一個原則：資料可以先準備， 影響要先說清楚，最後一步由人類完成。

這裡先把可見 UI 當成基線。之後 Agent 會協助準備報名與取消，但走到確認畫面就得停下來； 不能因為參數填對了，順便把使用者的決定也一起送出去。

用 Playwright 重播 Journey，準備階段必須維持零 POST

手動走過一次還不夠。今天把三條 Human-first Journey 交給 browser test 重播：

npx playwright test `
  tests/browser/events-human.spec.ts `
  tests/browser/saved-event.spec.ts `
  tests/browser/registration.spec.ts `
  tests/browser/cancellation.spec.ts

這一輪得到 8 passed。案例涵蓋鍵盤搜尋、沒有 modelContext 時的 fallback、收藏與 Undo、 報名準備階段零 POST，以及取消 dialog 的 human confirmation。

我最在意的不是畫面有沒有順利跳頁，而是「準備」和「送出」真的分開。報名頁可以先顯示姓名 與 Email，但 Network 在準備階段必須維持零 POST；只有人類確認後，Server 才能建立報名。 取消也是一樣，打開 dialog 不得改變狀態，確認按鈕才送出 mutation。

這條界線之後會原封不動交給 prepare Tool。Agent 可以省下填表和整理摘要的時間，不能省略 使用者本人。

功能先凍結，明天只把搜尋交給 Playwright

走完這一輪，活動網站已經有資訊讀取、可復原寫入與需要人類確認的操作。再加付款、OAuth、 資料庫或管理後台，專案會變大，今天的問題卻不會因此變清楚。功能就停在這裡。

三條 Journey 都會保留，但第一個交給機器重播的任務，我選搜尋。理由一點也不炫：它是唯讀， 條件與結果都看得見，腳本就算跌倒，也不會多收藏一筆或占掉一個名額。連這段都還沒拆清楚， 就急著自動報名，多少有點把屋頂扛在肩上找地基。

目前 Demo 使用 session 與 Server authority 驗證操作，但它不是正式會員系統。這個 non-goal 得寫清楚，否則 session Demo 很容易在文章裡被讀成完整 RBAC，責任突然膨脹得比功能還快。

活動案例還有一個實際優點：每個結果都能回到畫面檢查。搜尋後有卡片，收藏後有狀態，報名後 會出現在「我的報名」。Agent 之後真的參與其中，人類也不用只盯著聊天紀錄，猜它剛才是不是 偷偷做了什麼。

今天從頭走完以後，搜尋表單、詳情 route、收藏狀態與人類確認都有了可重播的基線。這也接住 昨天留下的問題：我們不只拿得到同一個網站，現在還知道它原本應該怎麼被人使用。

明天先把其中最安全的一小段交給 Playwright：仍然搜尋同一場活動，只把剛才的操作寫成 瀏覽器腳本。等程式開始找欄位、按按鈕，我們就能看見它究竟理解了「搜尋活動」，還是只 記住我今天按過哪一顆按鈕。