對大多數團隊來說,prompt engineering 就是不斷試錯。你調整一個系統提示詞,執行幾次,覺得「感覺好像有點改善」,然後就繼續下一步。沒有版本歷史紀錄、無法比較第 14 次迭代與第 11 次迭代的差異,也沒有系統化的回饋機制將生產環境的品質與提示詞變更連結起來。
我們開發了 Prompt Engineering Studio 來解決這個問題。這是一個直接內嵌在 recipe 編輯器中的可折疊面板——不是另一個獨立頁面,也不是另一個工具。五個頁籤就在提示詞文字框旁邊:Token Budget、Variables、Versions、Few-Shot 和 Optimizer。迭代在情境中進行,而非在互不相關的 workflow 中執行。
版本追蹤與差異比較
每次提示詞變更都會在 Firestore 子集合中建立一個版本。每個版本都會儲存:
| 欄位 | 說明 |
|---|---|
| 版本編號 | 自動遞增的整數 |
| 模板文字 | 當時的完整提示詞模板 |
| 相似度分數 | 透過正規化的 Levenshtein 距離與前一版本比較,得出 0-100 的分數 |
| 作者 | 進行變更的人員 |
| 變更日誌 | 自由格式的變更內容與原因描述 |
品質指標會按版本追蹤:總執行次數、成功次數、按讚次數、按踩次數、回饋比率,以及平均 token 使用量。這些指標會在 Redis 中快取 5 分鐘,讓 UI 保持回應速度,而不會在每次開啟面板時頻繁查詢 Firestore。
差異檢視器會逐行顯示任意兩個版本之間的比較。新增的內容以綠色呈現,刪除的內容以紅色呈現,並附帶統計資料摘要變更的行數。相似度分數會以顏色標示:綠色表示相似度 >= 90%(微幅調整)、琥珀色表示相似度 >= 50%(中等程度重寫)、紅色表示相似度 < 50%(大幅變更)。
**回復版本是非破壞性的。**還原到先前版本時會以舊內容建立新版本——它不會覆寫歷史紀錄。第 15 版可能與第 8 版完全相同,這沒問題。完整的變更鏈始終會被保留。
即時 Token 預算視覺化
Token Budget 頁籤會在您輸入時即時呈現條形圖,顯示上下文視窗的使用狀況。五個標示區段會細分 token 的使用分布:
| 區段 | 預算 |
|---|---|
| System | 200 token 開銷(系統提示詞框架) |
| Glossary | 500 token 上限 |
| Few-Shot | 2,000 token 上限 |
| RAG Context | 4,000 token 上限 |
| User Prompt | 根據文字長度 / 4 估算 |
視覺化會依據模型調整。選擇 Claude,條形圖會縮放至 200K token。切換到 GPT-4o,會重新縮放至 128K。切換到 Gemini,會延伸至 1M。比例會相應調整,讓您立即看出在某個模型的上下文視窗中綽綽有餘的提示詞,在另一個模型中可能會過於緊繃。
三個警告層級會自動觸發:
- 使用率 >80% ——琥珀色警告,建議您修剪上下文或 few-shot 範例
- 使用率 >90% ——紅色警告,表示有很高的截斷風險
- 剩餘輸出空間 <1,000 token ——明確警告模型沒有足夠空間產生有用的回應
按鍵輸入會延遲 500ms 更新,因此圖表保持回應速度,而不會在每個字元輸入時都重新計算。
變數檢查器
Variables 頁籤會在您編輯提示詞模板時即時偵測 {{variable}} 和 {{fragment:name}} 參考。每個偵測到的變數都會與 recipe 的 inputSchema 交叉比對,並指派四種狀態之一:
- Matched(綠色)——變數同時存在於模板和 schema 中。所有內容都正確連接。
- Orphan(琥珀色)——變數出現在模板中,但未在 schema 中定義。提示詞參考了在執行時不會有值的內容。
- Unused(紅色)——變數在 schema 中定義,但從未在模板中參考。您收集了無用的輸入。
- Fragment(藍色)——對可重複使用提示詞片段的
{{fragment:name}}參考。
對於已匹配的變數,檢查器會從歷史執行資料中提取範例值,讓您無需離開編輯器就能看到真實的輸入內容。這能找出一類常見的錯誤:schema 定義了 companyName 欄位,但模板卻參考 {{company_name}}。
Few-Shot 範例管理
Few-Shot 頁籤讓您可以將成功的執行結果釘選為精選範例。每個釘選的範例都有可編輯的輸出欄位——您可以修正或改進模型的原始回應,以建立黃金標準示範。
品質評分決定哪些範例會在執行時浮現。每個範例從基礎分數 50 開始。按讚加 40 分,按踩減 30 分。bakeoff 評估的評分也會加權計入。
在執行時,系統支援三種檢索策略:
| 策略 | 運作方式 |
|---|---|
| Feedback-based | 選擇獲得按讚的執行結果,並多樣化以避免重複範例 |
| Recent | 選擇最近的成功執行結果 |
| Similar | 透過 embedding 使用餘弦相似度尋找與當前輸入最接近的執行結果 |
釘選的精選範例永遠優先於動態檢索的範例。它們會先被注入,剩餘的預算則由策略選取的範例填充。
所有 few-shot 範例都會以 <few_shot_examples> XML 區塊的形式注入提示詞中,受限於 2,000 token 預算。如果您的精選範例超過預算,系統會從分數最低的範例開始截斷。
AI 驅動的優化器
Optimizer 頁籤提供三個層級的提示詞改進,從手動逐步升級到全自動。
第一層級:使用者觸發分析
點擊「分析」,優化器會提取該 recipe 最近 50 次成功執行的結果,將它們分成按讚和按踩兩組,並將分布情況傳送給 Claude Sonnet 4.6 進行結構化分析。模型會返回一系列建議,每個建議包含:
| 欄位 | 說明 |
|---|---|
| Section | 要變更的提示詞部分 |
| Original text | 該區段的當前提示詞文字 |
| Suggested text | 建議的替換文字 |
| Rationale | 為何此變更應能改善輸出品質 |
| Confidence | 0-100 分數,表示模型的確定程度 |
您可以審查每個建議,並選擇套用(在編輯器中內嵌替換)或 A/B 測試(建立 bakeoff,在生產環境中比較當前提示詞與建議)。
第二層級:自動觸發建議
當一個 recipe 累積了 5 個或更多按踩評價時,優化器會在無需使用者介入的情況下自動產生 1-3 個改進建議。這些建議會在 Optimizer 頁籤上顯示為通知徽章。
此層級的速率限制為每個 recipe 每小時一次,以防止建議疲勞。其意圖是溫和的提醒——「您的使用者對此 recipe 的輸出不滿意,這裡有一些想法」——而不是大量湧現的變更。
第三層級:品質漂移修正
此層級由 Quality Guard 系統在偵測到 recipe 輸出品質隨時間下降時觸發。優化器會分析漂移時段中排名前 5 與後 5 的執行結果,識別出品質下降的模式,並產生針對性的提示詞變更。
第三層級還可以自動觸發迷你 bakeoff——在當前提示詞與建議修訂版之間建立結構化 A/B 比較,導向真實的生產流量。這完全閉合了循環:品質下降,系統提出修正,對真實輸入進行測試,然後回報結果。
速率限制保持保守:修正建議限制為每 24 小時一次,自動觸發的 bakeoff 限制為每 7 天一次。提示詞優化應該是謹慎的,而不是失控的回饋迴圈。
為何它存在於編輯器中
Studio 是一個面板,而不是一個頁面。這是一個刻意的設計決策。Prompt engineering 是迭代性的——您變更一行,檢查 token 預算,瞥一眼差異,執行測試。在不同工具之間切換會打斷流程。
當 Studio 折疊時,您擁有一個乾淨的編輯器。當它展開時,您需要的每個訊號——token 使用率、變數健康狀況、版本歷史、few-shot 範例、優化建議——都在一個頁籤之外。無需導航,無需載入畫面,無需失去情境。
可用性
Prompt Engineering Studio 在 Pro 方案及以上提供。版本追蹤、token 預算管理和變數檢查包含在 Pro 方案中。Few-shot 管理與 AI 驅動的優化器(所有三個層級)在 Pro 和 Enterprise 方案中提供。