在上一個發布週期中，我們進行了一系列變更，這些變更都指向同一個方向：讓 BillionVerify 更容易信任、更容易監控，也更容易整合。
其中一些變更在產品中立即可見。Bulk Verify 體驗在檔案提交後變得更乾淨。驗證歷史頁面在工作仍在執行時更加實用。進度指標現在反映使用者實際關心的內容，而不是暴露內部隊列機制。
有些變更更深層。UI 後面的驗證狀態契約更豐富、更明確。資料模型現在區分電子郵件級進度和後端執行進度，這為用戶端提供了更好的基礎來呈現誠實的即時狀態。
某些變更直接影響開發人員。BillionVerify MCP 現已完全放棄較舊的 ?api_key= 設定形狀，轉向以 OAuth、受保護資源發現和現代用戶端相容性為基礎的托管遠端 MCP 模型。我們更新了產品、文件、行銷頁面和驗證介面以符合該現實。
本文章將這些更新整合為一個敘述，以便客戶、開發人員和內部團隊能看到它們如何相適應。
如果你想要簡短版本，這裡是：
- Bulk 驗證現在有更乾淨的上傳後流程。
- 非同步工作監控更具資訊性，也更誠實。
- 後端狀態介面對分佈式工作的結構更好。
- BillionVerify MCP 現在有更清晰的長期形狀：遠端端點加上 OAuth，而不是 URL 嵌入的 API 金鑰。
如果你想要完整故事，請繼續閱讀。
快速連結
為什麼這些更新應該一起推出
乍一看，這個版本看起來像是幾個不同的主題：
- 批量驗證頁面的前端清理
- 更豐富的歷史詳情螢幕
- 後端狀態合約升級
- MCP 身份驗證和文件清理
但所有這些的根本主題是相同的：消除歧義。
歧義在軟體產品中以不同方式出現。
有時它看起來像檔案上傳後的重複 UI。使用者不確定哪個按鈕重要、最佳下一步在哪裡，或系統是否仍在後台運作。
有時它看起來像進度條顯示「29% 完成」，但周圍的數字沒有解釋該百分比代表什麼。是 29% 的電子郵件已處理？29% 的工作者任務完成？29% 的結果已合併？大多數使用者不想解碼佇列架構來監控工作。
有時歧義出現在開發人員入職中。產品可能已在生產環境中支援一種架構，而其公開文件的部分仍建議較舊的連接模型。這會導致設定失敗、混淆和不必要的不信任。
這個版本是我們對這些問題的回應。
我們圍繞使用者實際需要了解的內容加強了產品 UX。我們圍繞客戶端實際需要呈現的內容加強了後端介面。我們也圍繞平台今天實際運作方式加強了開發人員面向的 MCP 故事。
1. Bulk Verify 現在提供更清潔的上傳後體驗
本版本的第一部分專注於檔案提交後的那一刻。
那一刻比看起來更重要。
當有人上傳大型 CSV 進行驗證時，他們並未完成。他們剛剛從輸入狀態轉移到監控狀態。介面必須幫助他們回答幾個立即的問題：
- 我的檔案是否成功提交？
- 處理是否已經在進行中？
- 我去哪裡監控這個特定的工作？
- 我可以相信系統會在完成時通知我嗎？
之前的流程回答了那些問題，但用了太多重複。成功卡片、周圍的狀態文字和可用的按鈕都以略微不同的方向吸引注意力。
我們清理了這個。
頁面上改變了什麼
提交成功狀態現在更緊湊，更容易掃描。成功圖標和標題佔用的垂直空間更少，這為使用者真正關心的詳細資訊提供了更多空間：檔案名稱、電子郵件計數、估計處理時間和下一個動作。
提交後預設也會顯示實時進度。使用者不再需要採取額外步驟來揭示該資訊。如果工作正在進行，頁面應該立即顯示。
主提交後 CTA 也以重要方式改變。不是將使用者發送到通用歷史記錄索引，主要動作現在直接連結到確切的工作詳細資訊頁面。這聽起來像是一個小改變，但它消除了不必要的跳轉，使工作流程感覺更加刻意。
我們也移除了在技術上起作用但沒有實質用處的元素：
- 上傳區域中的重複狀態文字
- 成功卡片中額外的「上傳另一個檔案」按鈕
使用者仍然可以從主上傳表面上傳另一個檔案。區別在於介面不再與自身競爭。
為什麼這在實踐中很重要
大量驗證通常用於重複的操作工作流程。使用者可能每天上傳多個檔案，在工作階段中監控多個工作，並稍後返回以下載篩選結果。在那種環境中，即使是很小的 UI 重複也會累積。
清理提交後狀態在三個方面有所幫助：
- 它減少了提交後立即需要的螢幕解析量。
- 它使下一步顯而易見。
- 它使 UI 與使用者的心理模型保持一致：「我的檔案已進入。現在我想追蹤這個工作。」
這是一種改進，很少會自己製造出炫目的螢幕截圖，但它每天都使產品感覺更加平靜和更加一致。
示例：新的提交後路徑
這是現在的預期使用者旅程：
- 在大量驗證流程中上傳 CSV。
- 查看帶有檔案名稱、列計數和 ETA 的立即成功狀態。
- 查看實時進度，無需手動揭示它。
- 按一下一個主要按鈕以開啟該工作的確切歷史記錄詳細資訊頁面。
- 稍後通過電子郵件或歷史記錄返回以檢查結果和匯出。
這比以下路徑要簡單：
- 上傳檔案。
- 解析重複的狀態區域。
- 按一下到通用歷史記錄。
- 尋找正確的列。
- 重新開啟目標工作。
在單個工作階段中的努力減少很小，在重複使用中則很顯著。
2. 驗證歷史現在的表現就像一個真正的監控介面
第二個重大改進是在非同步驗證歷史頁面上。
這個頁面過去是可用的，但功能有限。它可以顯示工作存在以及工作正在進行中，但還不像一個為主動監控而設計的介面。
這對於長時間執行的驗證工作來說是不匹配的。
當客戶在檔案仍在處理時打開歷史詳細頁面，他們不只是在尋找一個百分比數字。他們試圖理解：
- 這個工作涉及哪個檔案
- 工作量有多大
- 已經完成了多少工作
- 早期結果組合看起來如何
- 工作可能需要多長時間
我們圍繞這個現實重新設計了該頁面。
穩定的中繼資料現在首先出現
更新後的歷史頁面現在以穩定的摘要卡片開始。該卡片匯聚了最重要的工作中繼資料：
- 原始檔案名稱
- 總行數
- 唯一電子郵件計數
- 估計處理時間
- 開始時間
此資訊不取決於即時輪詢迴圈。這很重要，因為穩定的上下文應盡快出現，即使動態狀態負載仍在變動或更新。
當使用者進入頁面時，他們可以立即定位自己，而不是等待即時狀態回應來完成所有工作。
即時進度區域要豐富得多
在摘要下方，執行中狀態的體驗現在明顯更好。
除了有限上下文的裸進度條，頁面現在呈現：
- 已處理的工作量
- 剩餘工作量
- 各狀態的結果分佈
- 與主要大量驗證流程相符的語言和 ETA 語意
同樣重要的是，它移除了應該保持內部的內部指標。我們有意停止在使用者面向的介面中公開背景工作任務和區塊計數。這些值在操作上可能很有用，但當客戶問「我的工作進行到哪裡了？」時，這不是他們試圖衡量的。
正確的問題幾乎總是以電子郵件為中心，而不是以佇列為中心。
已完成狀態工具保持不變
此項工作的設計約束之一是我們不想失去已完成工作頁面的分析深度。
所以我們保留了現有的結果分佈圖表和匯出工具。此更新不是關於取代已完成狀態體驗。它是關於加強頁面頂部並使執行中狀態體驗配得上工作流程。
這意味著頁面現在可以更好地完成兩項工作：
- 在處理期間，它作為監控介面工作
- 完成後，它仍然作為分析和匯出介面工作
範例：使用者現在可以一眼理解的內容
執行中的工作頁面現在可以快速回答所有這些問題：
- 「這是我之前上傳的 19,293 行檔案。」
- 「其中有 19,010 個唯一電子郵件。」
- 「系統估計大約需要 33 分鐘。」
- 「已經驗證了 499 個電子郵件。」
- 「目前已完成的集合中大多數是有效的，無效和未知部分較少。」
這是一個遠比單一百分比數字（語意不清楚）更有用的心智模型。
3. 進度語義現在更加誠實
非同步產品中最大的教訓之一是「進度」不是一個單一的概念。
在分散式系統中，有幾件事可以獨立進行：
- worker 任務可以完成
- chunks 可以合併
- email 級別的結果可以累積
- 最終檔案可以變得可下載
如果客戶端只收到一個通用的 progress 欄位，它必須猜測該數字代表的是哪一個意思。這就是你最後得到在技術上一致但在體驗上令人困惑的 UI 狀態的方式。
我們想在合約層級修復這個問題。
核心轉變
更新的介面使得可以區分：
email_progresschunk_progressprogress_source
這種區分為客戶端提供了一個更強大的基礎，以便以符合使用者意圖的方式呈現進度。
例如：
- 大型面向使用者的進度條現在可以優先考慮
email_progress - 操作或診斷檢視仍然可以使用
chunk_progress - 如果需要備用方案，
progress_source可以使其明確
這是一個比假裝所有進度百分比都表示相同意思更健康的模型。
範例 payload
以下是這啟用的那種形狀：
{
"task_id": "36f68e67-ddcb-441a-a407-22f826e72443",
"status": "processing",
"total_emails": 19010,
"processed_emails": 499,
"valid_emails": 496,
"invalid_emails": 2,
"unknown_emails": 1,
"catchall_emails": 0,
"risky_emails": 0,
"role_emails": 0,
"disposable_emails": 0,
"email_progress": 3,
"chunk_progress": 7,
"progress_source": "email_progress"
}
即使不了解底層佇列系統的任何資訊，客戶端也可以從這個回應做出良好的決定。
這很重要，因為 API 不只是回傳資料。它們定義意義。
為什麼這對客戶更好
客戶不在乎 worker 是否完成了 96 個內部任務中的 7 個，如果只有 19,010 個 email 中的 499 個實際上已被處理。暴露錯誤的進度抽象會造成困惑，而不是安心。
透過將主要 UI 轉向 email_progress，產品現在反映了使用者實際關心的工作單位。
為什麼這對前端團隊更好
UI 不再需要從單一模稜兩可的百分比欄位推斷太多。
這減少了整個產品 bug 類別：
- 看起來進度太快的進度條
- 落後於主要百分比的摘要塊
- 試圖向終端使用者解釋後端實現細節的尷尬狀態副本
它也為前端團隊提供了一個更清潔的方式來分離穩定的工作中繼資料和不斷變化的執行資料，這直接導致發布的下一部分。
4. 後端狀態合約現在更好地架構用於分散式工作
前端變更無法在沒有後端合約改進的情況下保持一致性。
我們在這裡做出了兩項重要的結構決策。
首先，我們將穩定的中繼資料與即時狀態分離
某些欄位在建立工作後幾乎不會改變，或根本不會改變：
- 檔案名稱
- 建立時間
- 總列數
- 唯一電子郵件計數
- 預估處理時間
其他欄位本質上是動態的：
- 目前狀態
- 已處理的電子郵件計數
- 即時結果混合
- 進度百分比
試圖將兩類資料都強制通過相同的輪詢路徑是 UI 尷尬的常見來源。前端最終會等待應該立即可用的資料，同時也會比所需更頻繁地重新請求穩定資料。
新模型更簡潔：
- 穩定的工作中繼資料被視為中繼資料
- 即時工作狀態被視為狀態
當以簡明方式編寫時，這聽起來很明顯，但在實現品質中有實質意義。
歷史詳細頁面現在可以快速呈現穩定摘要資訊、僅輪詢需要變更的內容，並在工作執行時保持 UI 平靜。
其次，我們擴展了狀態承載本身
即時狀態介面現在更適合分散式非同步處理，因為它提供了迄今為止發生情況的更豐富圖景。
這包括計數器，例如：
- 已處理
- 有效
- 無效
- 未知
- 風險
- 全面捕獲
- 角色
- 一次性
- 已使用的點數
這些值使介面不僅對人工進度介面很有用，而且對自動化和下游工作流程也很有用。理解目前結果混合的客戶端可以對警示、通知、匯出和後處理做出更好的決定。
範例：為什麼除了 UI 之外這很重要
想像一個建立在 BillionVerify 之上的客戶面向應用程式想要：
- 在清單執行時顯示即時品質分佈
- 如果工作產生異常高的無效率，通知使用者
- 一旦存在有用的結果集，就提供篩選匯出
- 在不需要工程人員檢查原始工作者狀態的情況下為支援或營運儀表板提供動力
當後端狀態合約足夠明確且豐富時，所有這些使用案例都變得更加容易。
這就是為什麼後端介面工作很重要，即使第一個可見的變更是「進度條看起來更好」。更好的進度條通常是更好合約的症狀。
5. MCP 現已完全進入其遠端 OAuth 時代
此次更新的最後一個主要部分是面向開發者的，但它是此版本中最重要的長期產品修正之一。
BillionVerify MCP 現在以其應有的現代遠端客戶端形式呈現和記錄：
- 託管的遠端端點
- 基於 OAuth 的授權
- 受保護資源探索
- 標準 Bearer token 存取
端點為：
https://mcp.billionverify.com/mcp
這很重要，因為舊的設定模式在平台內部已經轉變後，仍會在公開資料中持續存在很久。在我們的情況下，某些文件和行銷界面仍然暗示 MCP 可以透過 URL 嵌入式 API 金鑰和 curl --stdio 包裝器進行連接。
這不再是 BillionVerify MCP 的正確形式。
舊的心智模型
較舊的模式大致如下：
curl --stdio "https://mcp.billionverify.com/mcp?api_key=YOUR_API_KEY"
該模型將多個關注點壓縮成一個尷尬的設定步驟：
- 傳輸
- 身份驗證
- 密鑰處理
- 本地包裝器行為
它也向如何透過現代客戶端使用託管遠端 MCP 伺服器傳達了錯誤的信號。
新的心智模型
目前的模型更簡潔。
對於 Claude Code，建議的設定是：
claude mcp add --transport http billionverify https://mcp.billionverify.com/mcp
然後在 Claude Code 中：
/mcp
從那裡開始，客戶端在瀏覽器中完成 OAuth 流程。
對於 ChatGPT 和其他相容的遠端 MCP 客戶端，正確的起點就是端點本身：
https://mcp.billionverify.com/mcp
客戶端發現受保護資源中繼資料，遵循授權流程，然後使用 Bearer 存取 token 進行已驗證的呼叫。
最重要的區別：MCP 身份驗證不是 REST 身份驗證
舊文件需要清理的原因之一是 API 金鑰在 BillionVerify 中仍然很重要。但它們不再屬於 MCP 啟動故事。
乾淨的分割是：
- REST API 使用 API 金鑰
- 遠端 MCP 使用 OAuth
現在該區別在產品表面上更加清楚。
如果開發者正在使用：
- ChatGPT
- Claude Code
- 另一個支援 OAuth 的遠端 MCP 客戶端
他們應該使用遠端 MCP 路徑。
如果他們正在構建：
- 後端對後端的自動化
- API 金鑰驅動的指令碼
- 僅支援本地 stdio 加 API 金鑰的客戶端
他們應該改用 API 參考和 REST 流程。
這不是表面上的區別。它是產品邊界，文件應該讓它顯而易見。
6. 公開文檔和行銷現已與產品一致
架構升級只能解決部分問題，如果公開資料仍然講述不同的故事。
這就是為什麼我們將 MCP 文檔和行銷清理工作視為同一版本發佈的一部分。
我們更新了：
- 公開 MCP 頁面
- MCP 指南
- Claude Code 指南
- AI 指南入口點
- 多語言文檔變體
- 本地化行銷常見問題文本
目標很簡單：應該有一個明確的答案來回答「我如何連接 BillionVerify MCP？」這個問題。
現在有了。
為什麼這對開發人員很重要
當公開文檔滯後於實現現實時，開發人員會在三個方面付出代價：
- 設定嘗試失敗
- 對平臺的信心喪失
- 額外的支援負擔來澄清本應顯而易見的事項
通過將公開介面與實際的遠端 OAuth 模型保持一致，我們在問題成為支援問題之前減少不必要的摩擦。
為什麼這對平臺定位很重要
MCP 生態系統發展迅速。隨著越來越多的團隊通過 ChatGPT、Claude Code 和其他 AI 用戶端評估工具，第一次整合體驗的品質變得更加重要。
一個在協議層看起來現代，但在公開設定指南中顯得過時的產品會在應該建立信任的地方造成猶豫。
這就是為什麼我們還通過更清晰的條款、隱私和支援聯絡資訊可見性來加強登入和同意介面。審查者、開發人員和企業評估者在信任信號明確時都會受益。
7. 此版本發布的實際前後對比視圖
了解此版本發布的一個有用方式是比較發布前後的使用者和開發人員體驗。
前
- 大量驗證檔案可以成功提交，但提交後的狀態仍然有重複的 UI 和較不明顯的後續步驟。
- 歷史詳細頁面顯示活動，但還不像一個完整的監控介面。
- 百分比完成值可能存在，但未能清楚告訴使用者它代表已處理的電子郵件還是內部工作完成。
- MCP 公開資料仍然部分反映了舊版的
?api_key=設定故事。
後
- 提交後的體驗更簡潔、更緊湊、更直接。
- 即時進度預設在大量流程中顯示。
- 提交後的主要 CTA 將使用者直接帶到確切的工作詳細頁面。
- 歷史詳細頁面顯示穩定的摘要中繼資料加上更豐富的即時結果可見性。
- 面向使用者的進度現在以電子郵件層級的進度語義為中心。
- 內部工作計數不再作為面向客戶的指標公開。
- 後端狀態介面對於即時客戶端和分散式工作更好地構建。
- MCP 公開資料現在一致地反映遠端 OAuth 架構。
這不是單一功能。這是對整個工作流程進行的有意義的品質檢查。
8. 這對不同受眾的意義
針對營運和成長團隊
您可以獲得更順暢的批量驗證工作流程，減少 UI 摩擦，在工作執行期間獲得更好的可見性，以及更清楚地存取您剛啟動的確切工作。
針對產品和前端團隊
您現在擁有更強大的進度語義和更清晰的中繼資料與即時狀態之間的分離，這使得進度繁重的螢幕更易於建置和解釋。
針對後端和平台團隊
您對分散式驗證有更強大的狀態契約，以及對不同進度值實際含義的更清晰說明。
針對整合 MCP 的開發人員
您現在對設定問題有更清楚的答案：針對 MCP 用戶端使用遠端 MCP 加上 OAuth，以及在該模型適當的地方對 REST API 使用 API 金鑰。
9. 從何開始
如果您想探索更新的體驗或整合路徑，請從這裡開始：
- 深入瞭解產品：電子郵件驗證
- 執行更大規模的工作流程：批量電子郵件驗證
- 瞭解基礎知識：什麼是電子郵件驗證？
- 從支援的用戶端連接 MCP：MCP 概觀
- 深入瞭解設定：MCP 指南
- 特別設定 Claude Code：Claude Code 指南
- 改用 API 金鑰型整合：API 參考
結束語
此版本的重點不在於一個宏大閃亮的表面。而是在模糊之處收緊產品。
我們讓大量驗證流程更加清晰。我們讓非同步監控更加實用。我們讓進度報告更加真實。我們讓 MCP 故事與我們實際構建的平台相符。
這些改進相互強化。
當使用者介面少說但意義深遠時，產品變得更容易信任。當文件描述真實的架構時，產品變得更容易整合。當體驗下的介面具有更清晰的語義時，產品變得更容易演進。
這是我們持續推動 BillionVerify 的方向。
如果您已經在使用 BillionVerify，這些變更應該會讓您的日常工作流程感覺更加直接、更加可預測。
如果您現在正在評估此平台，此更新是我們如何看待產品品質的一個好快照：頂層的使用者面向清晰度、下層的明確合約，以及與現實相符的文件。