一個用於編碼與 AI 應用的統一控制台：有哪些變更以及如何使用它

當程式開發助手模式與 AI 應用程式模式合併為同一個工作介面後，TokenLab Console 對我們而言就不再僅僅是一個儀表板。在我們的流程中，請求、回覆以及與其相關的帳戶狀態現在都整合在一起。這消除了每次工作階段中的上下文切換，並改變了我們解讀緩慢回覆的方式。

重點摘要

• 程式開發助手模式與 AI 應用程式模式現在皆位於 TokenLab Console 中；兩個舊的進入點已合併至此。
• 現有的連結仍然有效，之前的對話也依然存在。無需手動進行任何遷移。
• 回覆會隨著模型生成即時串流顯示，而非僅在結束時才出現。介面會顯示首個 token 的時間。
• 首個 token 的延遲時間是記錄在請求日誌中的訊號（請求日誌中的 ttft_ms），而不僅僅是介面上的裝飾。
• 當對話中途餘額不足時，儲值入口就在對話旁邊，無需前往獨立的帳單頁面。
• 控制台的模型選擇遵循公開目錄；請查看模型目錄以獲取當前選項。目前的目錄範例包括 Claude Sonnet 5 和 DeepSeek V4 Pro。

TokenLab Console 的變更與未變更之處

此項變更透過兩次變更日誌發布。控制台整合（2026-08-04）將兩個舊的進入點合併為一個控制台。控制台聊天串流（2026-08-18）則為聊天功能增加了串流顯示。這兩次變更相隔一個月，因此錯過第一次更新的團隊仍可免費獲得第二次更新。

這是一次介面上的變更，而非行為上的變更。模型呼叫、金鑰和計費方式皆維持不變。舊連結持續有效，現有的對話在合併過程中也已完整保留。無需進行任何手動遷移步驟。

整合步驟旨在調整進入點，而非模型存取權。串流步驟旨在改變回覆的呈現方式，而非計費的 token 內容。這一點很重要，因為產品介面的變更可能會隱藏行為上的變更，而這次更新並未如此。程式開發助手模式與 AI 應用程式模式現在共享同一個位置，因此工作階段的第一個決策不再是選擇要開啟哪個進入點。

如果您的團隊有指向舊進入點的執行手冊（runbooks），請在有空時更新標籤。舊連結仍然有效，因此執行手冊不會中斷。控制台是您進行新工作時應加入書籤的地方。當您在任一模式中選擇模型時，該選擇會遵循公開目錄，因此請查看模型目錄。目前的目錄範例包括 Claude Sonnet 5 和 DeepSeek V4 Pro。

TokenLab Console 中的串流功能如何改變您閱讀工作階段的方式

串流功能改變了您感知處理進度的時刻。在我們的流程中，控制台閘道用戶端會建立串流聊天請求，回覆則會逐步渲染。介面會顯示首個 token 的時間，讓您能看到模型何時開始回應。控制台也會將該訊號記錄為 ttft_ms，這是請求日誌中的一個選用欄位。

首個 token 的時間告訴您第一個 token 何時到達，而總延遲時間則告訴您整個回覆何時完成。這是兩個不同的問題，因此當回覆感覺緩慢時，請先檢查 ttft_ms。如果第一個 token 很晚才出現，則延遲發生在生成之前。如果第一個 token 出現得早但回覆過程緩慢，則延遲發生在串流的後續部分。

當我們觀察緩慢的工作階段時，我們會比較 ttft_ms 與請求的其他證據，而不是僅從載入圖示猜測。請求層級的證據範圍涵蓋整個組織，並包含路由、計費狀態、快取狀態，以及請求背後的模型與金鑰上下文。控制台會顯示您原本需要從日誌中挖掘的相同請求記錄。

解讀首個 token 訊號的操作範例：

# 控制台請求日誌將 `ttft_ms` 作為選用欄位公開。
# 1. 將請求日誌篩選至您正在檢查的請求。
# 2. 讀取 `ttft_ms`。
# 3. 將 `ttft_ms` 與同一列中的請求總延遲進行比較。

關於精確的串流請求格式，請使用最新的 TokenLab API 文件。複製一個包含虛構欄位的請求範例，其效用遠不如直接參考擁有這些名稱的文件頁面。

串流功能不會改變您的計費方式，因為產生的 token 數量相同，只是它們在到達時即可見。由於回覆現在以串流方式呈現，即使工作階段中斷，仍會顯示部分回覆而非一片空白。這改變了您診斷中途失敗的方式。對於聊天串流無法涵蓋的長時間執行作業，請參閱非同步影像生成任務指南。

如何驗證緩慢的工作階段而不需猜測

從請求日誌開始，而不是看載入圖示，因為 ttft_ms 欄位會告訴您第一個 token 何時到達。如果該數值很高，代表模型尚未開始回答。如果該數值很低，代表模型很早就開始了，而剩餘的串流過程耗費了時間。這種區分方式可避免您歸咎於路徑中錯誤的部分。

請求記錄的範圍涵蓋您的組織。它包含服務該請求的路由、計費狀態、快取狀態，以及模型與金鑰上下文。這些欄位整合在一起，讓您可以將工作階段視為單一事件來閱讀，而不必拼湊不同的頁面。相同的請求記錄也可在儀表板中取得，這有助於比較控制台檢視與帳戶層級的資料。請求控制台指南解釋了這些證據的存放位置。

例如，如果第一個 token 出現得早但回覆過程緩慢，則 ttft_ms 就不是主要訊號，因為問題在於串流的其餘部分。您可以在相同的請求記錄中查看路由和快取狀態。您可以檢查請求是命中快取還是發送至模型。您可以看到附加了哪些金鑰和模型上下文。

這些資訊單獨來看無法說明完整情況，但結合起來就能為您提供檢查方向。當我們觀察緩慢的工作階段時，請求日誌提供了我們所需的細節。我們會在得出結論前，將 ttft_ms 與其他請求層級的證據進行比較。

當請求因為餘額不足而失敗或暫停時，相同的工作流程也有幫助。請求記錄包含計費狀態，因此失敗的原因不再是謎。儲值入口就在對話旁邊，因此修復工作可以在同一個視窗內完成。您無需離開工作階段即可尋找下一步，因此您可以儲值後直接繼續。

如果餘額正常，您可以繼續檢查路由、快取狀態或模型選擇。重點是按順序閱讀請求層級的證據。先詢問第一個 token 何時到達，再詢問是哪個路由提供服務，最後詢問記錄中關於計費、快取、模型和金鑰上下文的其他資訊。這個順序很簡單，且與控制台呈現資料的方式一致。

限制

串流顯示的是進度而非吞吐量，因為串流可以快速開始但仍需很長時間才能完成。快速的首個 token 並不能證明整個請求都很快。首個 token 的時間也取決於模型和路由。請在同一個模型內進行比較，而非跨模型比較。

ttft_ms 的變更可能反映了路由、快取狀態或模型選擇，而不僅僅是提示詞本身。請將 ttft_ms 視為請求日誌中的一個訊號。在得出結論前，請將其與其他請求層級的證據搭配使用。這是一個用於閱讀工作階段的介面，而非用於模型排名的基準測試。

控制台不會將聊天串流變成任務執行器。如果您有長時間執行的影像任務，請使用非同步影像生成任務指南，而不是保持聊天串流開啟。串流介面適用於逐個 token 到達的回覆。非同步指南則適用於在聊天回覆之外執行的工作。

此外，請記住請求層級的證據範圍涵蓋整個組織，這將請求與其周圍的帳戶上下文連結起來。這也意味著您不應將單一請求視為全域基準。該記錄涵蓋了該請求的路由、計費狀態、快取狀態以及模型與金鑰上下文。這是開始診斷的絕佳起點，但它並非供應商或模型的排名。當我們比較工作階段時，我們會比較同一個模型和同一個路由系列，這能確保比較的公正性。

常見問題

我的舊控制台連結還能用嗎？

可以。舊連結持續有效，現有的對話在合併過程中也已完整保留。無需手動進行任何遷移。如果您為控制台頁面加入了書籤，它仍然有效。

首個 token 的時間實際上測量的是什麼？

它測量的是串流回覆中第一個 token 到達的時間，控制台會在介面上顯示它，並將其記錄為 ttft_ms（請求日誌中的選用欄位）。它不測量總延遲或吞吐量。

當對話餘額不足時，我該在哪裡儲值？

請使用對話旁邊的儲值入口，該入口會在對話中途餘額不足時出現，讓您無需離開工作階段即可處理餘額問題。儀表板中的帳單頁面仍然是處理更廣泛帳戶事務的地方。

我可以比較不同模型的首個 token 時間嗎？

不可以，這不是一個準確的比較方式。首個 token 的時間取決於模型和路由，因此請在同一個模型內進行比較，而非跨模型比較。請將 ttft_ms 作為請求層級的訊號，而非模型排名。

請在儀表板建立 API 金鑰並在新的控制台中執行一次工作階段。