自動化與 Agent

讓「預覽／試聽」功能幫你抓 bug：重用正式路徑的實作筆記

很多產品的「預覽」是另外寫一套近似邏輯，看起來省事，代價是使用者以為準，正式產出卻是另一回事。這篇筆記教你讓預覽直接呼叫正式那條程式碼，只換一個小輸入——順便免費多一層迴歸測試。

2026/09/23 ｜ 3 分鐘閱讀

一個核心觀念

預覽功能最大的風險，不是「做得簡陋」，而是「跟正式邏輯是兩套系統」。

只要預覽是另外寫的一套（哪怕邏輯上很相似），它就永遠有可能跟正式產出產生落差——而且這種落差很難靠肉眼發現，因為兩套代碼「感覺上」做的是同一件事。唯一根治的方法：讓預覽呼叫正式產出真正會執行的那段程式碼，只是換一個小輸入（比如固定的測試文字、測試參數），而不是重寫一套邏輯去「模擬」正式產出長什麼樣。

按步驟做

Step 1｜找到正式產出的核心函式

去找系統裡「真正產生使用者最終看到/聽到的東西」的那個函式或那條呼叫鏈。它通常長這樣：接收一組參數 → 做實際運算/呼叫模型 → 回傳結果。

不確定自己系統裡「正式產出」的入口在哪，可以貼路由/API 定義給 AI，問：「我想幫這個系統加一個預覽功能，這個功能必須跟下面這個正式端點用同一條程式碼路徑生成結果，只是輸入換成固定測試值，請幫我指出應該重用哪個函式、要注意什麼參數。」

Step 2｜抽出一個固定測試輸入

決定一個能代表「正常使用情境」的固定輸入（例如一句固定的試聽文字、一組預設參數）。所有選項都要用同一份輸入去測，使用者才能橫向比較。

Step 3｜讓預覽端點呼叫正式函式，只是換輸入

新增一個「預覽」用的端點或函式，裡面直接呼叫 Step 1 找到的正式函式，只把輸入換成固定測試值。不要在這裡另外寫任何「模擬/近似」邏輯——一旦發現自己在寫「假裝這樣做結果會像什麼」的程式碼，就是重蹈舊做法的覆轍。

Step 4｜加快取，讓重複點擊不用重跑

同一個選項的預覽結果通常是固定的，第一次生成後存起來，之後直接讀快取。使用者體驗更好（秒開），也省運算資源。

Step 5｜正式產出耗時，就用背景工作模式

如果正式產出本身要花時間（例如跑 AI 模型），預覽走同一條路也會一樣慢。提交後先回一個工作 ID，前端每隔一兩秒輪詢一次，做完了再顯示結果，別讓使用者對著沒反應的按鈕發呆。

Step 6｜測試：確認預覽真的等於正式產出

挑幾個選項，先點預覽，再走一次完整正式流程，兩邊直接比對。做完前五步會「以為」兩邊一致，但只有實際比對過才算數。

你一定會踩的坑

1. 預覽很耗時，使用者以為壞掉了：正式產出如果要跑大模型，預覽速度也一樣慢。一定要做 Step 5 的處理中狀態，加上 Step 4 的快取。
2. 忘記做快取，每次點擊都重跑正式邏輯：正式邏輯如果很貴（花錢的 API、吃運算資源），使用者手滑多點幾次，成本會不必要地疊加。
3. 抓到 bug 之後，沒查這個 bug 存在多久了：預覽功能意外抓出正式環境 bug 時，除了修掉，一定要回頭確認影響範圍——有多少次正式產出結果已經是錯的。

這條原則在一次真實案例裡驗證過：一個語音克隆功能的試聽按鈕，舊版用瀏覽器內建語音湊一個近似音當預覽，跟正式生成完全是兩套邏輯。改成讓試聽直接呼叫正式生成同一段程式碼後，不只讓試聽真的準了，還順便揪出一個已經藏了好幾天的正式環境 bug——某個聲音角色的參考音檔其實混進了雜訊，因為從來沒人真的完整跑過那條路徑仔細聽過結果。

卡住時怎麼問 AI

把下面這段貼給 Claude／ChatGPT，換成你的狀況，並且貼上完整的錯誤訊息原文（不要自己摘要）：

我是新手，正在幫我的專案加一個「預覽/試聽」功能，目標是讓預覽直接重用
正式產出的程式碼路徑（而不是另外寫一套近似邏輯）。

我的系統是：[簡短描述你的專案，例如：一個 FastAPI 後端 + 網頁前端的小工具]
正式產出的功能是：[描述，例如：使用者填資料後，系統會呼叫某個 API 產生一段文字/圖片/聲音]

我現在卡在這一步：[貼你卡住的地方，例如：不知道要怎麼讓預覽端點跟正式端點共用同一段程式碼]
如果有錯誤訊息，錯誤原文是：[貼完整錯誤訊息，不要只貼摘要]

請一步一步引導我，不要一次講太多步驟，先問清楚我目前程式碼長怎樣再給建議。

一句話總結

能重用正式邏輯的地方，別另外寫一套「看起來差不多」的替代品——那只是把「我好像測過了」的安全感賣給自己，真正的落差遲早會變成使用者發現的問題。反過來說，只要肯讓預覽走正式那條路，你等於免費多幫自己做了一層迴歸測試。