Skip to content
產品

測試我的 Recipe:在上線前即時觀看結果串流回傳

JieGou 的「測試我的 Recipe」功能自動產生合成輸入,依序對每組輸入執行 recipe,並透過 NDJSON 即時串流結果——讓您在 recipe 接觸正式流量之前,就能確切掌握其表現。

JT
JieGou Team
··4 分鐘閱讀

JieGou has evolved.

Since this post was published, JieGou has pivoted from an AI automation platform to an AI-powered operations company delivering managed marketing and operations services. Learn about our managed services →

您建立了一個 recipe。提示詞看起來沒問題。您用一組精心撰寫的輸入執行了一次,輸出看起來很好。該部署了嗎?

且慢。一組輸入不等於一套測試。recipe 可能完美處理您精心編寫的範例,但在面對真實用戶發送的混亂、不完整、相互矛盾的輸入時卻崩潰。未經系統性測試就部署是一場賭注——而大多數團隊要到出了問題才意識到賠率有多差。

「測試我的 Recipe」消除了猜測。產生寫實的輸入、對每組輸入執行 recipe,並在您做出任何決定之前即時觀看結果串流回傳。

手動測試的問題

大多數團隊都用同樣的方式測試 recipe:輸入一組資料、按下執行、閱讀輸出、重複。這種方式有三個問題。

速度太慢。 手動輸入資料、等待每次結果、憑感覺評估品質,每次測試需要數分鐘。測試 20 種變化要花上一個小時——而您沒有這個時間。

存在偏見。 您根據自己認為用戶會發送的內容來撰寫輸入。但您對輸入分佈的心理模型是錯的——永遠是錯的。真實輸入包含打字錯誤、缺少欄位、矛盾的指令,以及您從未想像過的邊界情況。

無法重複。 沒有記錄您測試了什麼、結果是什麼,或者在上次修改提示詞後 recipe 是否有改善。每次測試循環都從零開始。

產生寫實的輸入

在任何 recipe 的詳細頁面點擊測試 Recipe按鈕,JieGou 就會為您產生合成測試輸入。產生過程會使用 recipe 的輸入架構——欄位名稱、類型、描述和您提供的任何範例——來生成 N 個寫實的變化版本(可設定 5 到 50 個)。

產生的輸入不是隨機雜訊。它們涵蓋了寫實的範圍:格式正確的輸入、資訊最少的邊界情況、包含衝突需求的輸入,以及挑戰 recipe 設計極限的輸入。把它想像成一位自動化 QA 工程師,閱讀您 recipe 的規格書然後撰寫測試案例。

您可以在執行開始前檢視產生的輸入。刪除任何不相關的、編輯其他輸入以針對特定場景,或者加入您自己的自訂輸入。目標是一套反映現實的測試套件,而非合成練習。

透過 NDJSON 即時串流

開始測試後,JieGou 會依序對每組輸入執行 recipe。結果透過 NDJSON(換行分隔 JSON)即時串流回您的瀏覽器——每一行都是一個完整的 JSON 物件,代表一個事件。

TestMyRecipeModal 會經歷四個階段:

  1. 閒置 — 準備好進行設定和啟動
  2. 產生中 — 正在建立合成輸入
  3. 執行中 — Recipe 正在對每組輸入執行,結果即時串流回傳
  4. 完成 — 所有測試結束,摘要可供檢視

在「執行中」階段,您會看到結果逐一出現。不用等待整個批次完成。沒有轉圈動畫把所有進度藏在單一載入狀態後面。每個結果在其執行完成後立即出現,讓您可以在後續測試仍在執行時就開始閱讀輸出。

這對長時間執行的 recipe 特別重要。如果您的 recipe 呼叫外部 API 或處理冗長文件,個別執行可能需要 10-30 秒。沒有串流的話,測試 20 組輸入意味著盯著轉圈動畫好幾分鐘。有了 NDJSON 串流,您在幾秒內就能看到第一個結果。

閱讀結果

測試執行完成後,結果檢視提供兩個層次的詳細資訊。

摘要統計讓您一眼看到全局:總測試數、成功數、失敗數、平均執行時間和平均 token 使用量。如果 20 個測試中有 18 個成功但 2 個失敗,您立刻就知道 recipe 有需要處理的缺口。

逐筆測試手風琴面板讓您深入查看每次個別執行。展開任何測試可以看到發送的輸入、回傳的完整輸出、執行時間、token 數量和任何錯誤訊息。輸入與輸出的並排比較讓您輕鬆判斷 recipe 是否理解了請求並產生了有用的結果。

這組合的運作方式就像程式碼測試套件:摘要告訴您是否有問題,詳細資訊告訴您問題是什麼、在哪裡。

稽核軌跡整合

每次測試都會記錄為 recipe.tested 稽核動作。稽核記錄會擷取誰執行了測試、何時執行、測試了哪個 recipe、產生了多少組輸入,以及成功/失敗的分布。

這有兩個用途。首先,它為有合規需求的團隊建立問責軌跡——您可以證明 recipe 在部署前經過了測試。其次,它提供測試活動的歷史記錄。當 recipe 在正式環境開始異常時,您可以檢查稽核日誌,查看它最後一次測試的時間和結果。

稽核記錄在 Operations Hub 中與其他系統活動一起顯示,因此測試與執行、審核和設定變更享有同等的營運可視性。

為什麼這對正式環境的信心至關重要

「我試過可以用」和「在大規模下可靠運作」之間的差距,正是大多數 AI 自動化失敗發生的地方。一個 recipe 可能完美處理 90% 的輸入,但對另外 10% 產生無意義的結果。沒有系統性測試,那 10% 的失敗率只會在真實用戶遇到時才被發現。

「測試我的 Recipe」通過讓您在每次部署前都能快速輕鬆地執行有意義的測試套件來彌合這個差距。產生輸入、觀看結果串流回傳、檢視摘要、修正任何問題,然後再次測試。整個循環只需幾分鐘,而非幾小時。

結合 Quality Guard 的持續監控和 bakeoff 的提示詞比較,「測試我的 Recipe」完善了品質生命週期:部署前測試、實驗時比較、上線後監控。

「測試我的 Recipe」適用於所有方案。立即試用

recipestestingstreamingqualitydeveloper-experience
分享這篇文章

喜歡這篇文章嗎?

在您的信箱中獲取工作流程技巧、產品更新和自動化指南。

No spam. Unsubscribe anytime.