把 Notebook 的流程搬到 Web 後，功能越來越多。
我開始不只看畫面能不能跑，而是回頭比對產出的結果：改了 A，為修改的 B 的輸出還一樣嗎？

Day 02 談的是 Vibe Coding 為什麼能讓 DAP 的第一批 Web 功能很快往前走：前後端先確認資料交換方式，部分資料規則已有 function 可以沿用，AI 協助把表單、畫面與串接做出來。

但功能從一個個頁面，慢慢累積到 12 項後，我開始遇到另一個問題：這次改的畫面看起來正常，怎麼知道其他功能沒有被改壞？

把 Notebook 的流程搬到 Web 後，一開始很有成就感。
畫面可以點、表單能填，申請資料也能整理成 JSON；原本一大段人工操作，開始有了 Web 流程。

可是功能逐漸增加後，我不敢再只看眼前這個按鈕有沒有反應。
少帶了一個申請欄位、拿錯一筆資料，或把 JSON 組錯位置，畫面未必會立刻告訴我。

回頭看第二代初版的程式，這個專案在申請流程後，有一個重要交付結果，也就是我的 JSON 檔。
使用者在 Web 填寫與選擇資料，前端依 API 規格送出；後端整理資料與既有 function 的結果，產出後續申請需要的 JSON。既然它是重要結果，驗證就有了目標。

畫面能跑，只能證明我看到了其中一段；它不能保證 JSON 還是我原本要的樣子。

我做的驗證很簡單：Notebook 和 Web 會不會產出一樣結果的 JSON？

我的做法不是建立一套很複雜的測試平台，而是自己手動操作固定情境：Notebook 和 Web 都選同樣的項目，再用 Python 比對兩邊產出的 JSON。

每個情境的操作都固定，所以我期待兩份 JSON 的所有欄位都一致。每次過版，我會把 12 項功能都跑一遍。

Python 會產出一份報表。先看每個情境是通過、失敗或執行錯誤；若有差異，再看是哪一個 JSON 路徑不同、Notebook 的值是什麼、Web 的值又是什麼。

我保存的報表會列出通過、失敗與執行錯誤，差異頁則把不同的 JSON 路徑逐一攤開。原始報表不能直接公開，因為其中有姓名、帳號、網址與內部功能名稱；這篇文章只使用匿名化後的示意。

我需要的不是 AI 說它做完了，而是兩個版本到底哪裡不同。

報表出現 FAIL，不一定代表 Web 寫壞了

一開始，我把「Notebook 與 Web 的 JSON 一致」當成預期。但實際看報表後，我發現不能只用 FAIL 直接判定 Web 就是有問題。

有些舊 JSON 原本沒有帶入某些申請資訊，Web 版卻帶入了值。這時候，我通常不會立刻把 Web 改回空值，而是先確認：這個資訊是不是本來就應該包含在申請內容裡，只是舊流程漏掉了？做近一步的優化

反過來，如果 Notebook 與 Web 都有值，卻是不同的內容，我通常會先把它視為 Web 可能有問題，再回頭檢查資料來源、欄位規則、組裝邏輯，或相關的 function。

這不是一套可以套用到所有系統的判讀演算法，而是在 DAP 這種固定輸出的申請流程裡形成的規則。要加哪個欄位、該呼叫哪支 API、畫面該怎麼呈現，常常是在實作、看到結果、再修改的過程中，才逐漸變得清楚。

報表負責指出差異；要修正、保留，或補進需求，最後仍由我判斷。

這是最小的驗證，不是完整測試

這份比對能回答一個很具體的問題：在固定申請情境下，Notebook 與 Web 的 JSON 有哪些不同？

它回答不了的事情更多。它不會告訴我畫面是否好用、使用者是否理解欄位、權限是否正確、郵件是否送達，或跨系統流程是否順暢。這些仍要靠頁面檢查、Scenario、UAT 與人工確認處理。

後來讀到 Anthropic 對 agent evaluation 的說明，我才找到一個貼近的概念：regression eval 關心的是系統原本會做的事，現在還會不會做。我的 JSON 比對比完整的 eval 小得多，也不是 agent evaluation 平台；但它替一個重要行為留下了可重複檢查的參照。

Anthropic 的 Claude Code 建議也提醒，當模型有清楚、可驗證的目標時，就能據此反覆調整產出。
對 DAP 而言，是有一份真的可以拿來比較的 JSON。

至少在每次過版時，這份報表讓我不必只靠經驗確認，也更知道該從哪裡開始檢查。

今天可以做的：替一個輸出留下 baseline

今天不需要先建測試平台。請從自己的功能中選一個你最怕改壞，而且可以固定下來比較的輸出。它可以是 JSON、API response 的關鍵欄位、CSV、報表，或一段固定的計算結果。

先寫下這張最小的 baseline 卡：

# Regression baseline｜功能名稱

- 固定輸入：
- 預期守住的行為：
- 預期輸出：
- 是否有動態欄位：
- 比較方式：
- 差異出現時先查哪裡：
- 差異可能代表回歸、資料不同，還是需求補齊？
- 這份比對驗證不到什麼：

Claude Code 在這一步可以協助你追查：輸入從哪裡進來、輸出在哪裡組出來、哪些檔案的改動可能影響結果。但什麼才是正確結果、某個差異該修正還是保留，仍然必須由熟悉業務的人決定。

小結：先讓驗證看得見

Day 03 不是在說我從此解決了驗證問題。我只是讓一部分驗證變得可看見，也讓一些藏在舊流程裡的遺漏浮出來。

不過，JSON 能產出、也能比對，仍沒有消除 DAP 當時最大的人工斷點：使用者還得下載結果，切換到外部單據平台開單、分派與追蹤。

下一篇，我會談這段 JSON 沒有解決的人工作業，以及它為什麼成為 DAP 從第二代走向第三代的起點。

參考資料

• Anthropic. (2025-04-18). Claude Code Best Practices.
• Anthropic. (2026-01-09). Demystifying evals for AI agents.