內容目錄 顯示

從 Dropbox Dash 的真實開發過程與 Anthropic 的觀察，看評估機制為什麼要在初期建立

你和你的團隊是怎麼判斷一個 AI 產品的產出夠不夠好呢？

Dropbox 在打造自家產品 Dash （一個幫助團隊跨工具搜尋與整理工作資訊的 AI 助理）的早期就遇到了這個難題。當時，開發團隊稍微調整了背後的系統指令，使得輸出跟著改變，於是PM 和工程師開始用自己的標準爭論這個輸出好不好，但爭了也無法達成共識。就這樣，問題溜過了上線前的測試環節，直到真實用戶感受到產品變差，才知道出了事。

核心問題

Dropbox 的情況並非特例。Anthropic 在今年一月發表的文章中，描述了他們在協助多個企業團隊開發 AI 產品時反覆觀察到的模式：在沒有建立評估標準的情況下，團隊每次改動之後，很難判斷產品到底是變好還是變差了，導致除錯就會變得被動。因為需要等使用者投訴，才能手動重現問題、修 Bug，並祈禱沒有別的東西跟著壞掉。

除此之外，Anthropic 觀察到，沒有評估機制的團隊，光是確認一次模型升級有沒有影響產品品質，就要花上好幾週手動測試。這也意味著，在大家都在搶速度的市場裡，團隊的時間會耗在兩件事上：一是追趕市場迭代節奏，二是每次出事後修完還要確認有沒有新的漏洞。

然而，沒有評估標準，這個循環就很難打破。

關鍵洞察

那麼，出路在哪裡？

Anthropic 在文章裡指出，評估標準越早建立越好。原因很直接，因為開發初期，在產品需求剛被定義時，這些需求本身就能告訴團隊測試的方向；但隨著時間推移，產品越來越複雜，定義測試的方向也越來越難，最終只能從一個已經上線的系統裡，一邊摸索一邊逆推。

Dropbox 後來的做法，正是把這件事的順序反過來。他們不等產品上線後才逆推評估標準，反而在一開始就把評估機制建立起來，並把評估嵌入每一個開發步驟，包括每次改動都會自動跑一輪測試案例，且每一輪測試會在 10 分鐘內有結果。若有任何指標沒達標，改動就無法合併。這樣一來，那些原本會悄悄溜過上線前測試環節的問題，在改動送出的當下就會被攔下來。

回到一開始的問題：你和你的團隊是怎麼判斷一個 AI 產品的產出夠不夠好？Dropbox 的經驗告訴我們，這個問題沒有辦法靠感覺回答，它需要一套從開發初期就建立起來的評估機制，讓團隊對「好」有共同的標準。

金句啟發

「評估不是上線前的最後一關，是你在開發初期就要回答的問題：這個功能，做到什麼程度才算做好了？」

延伸閱讀

[1] 評估對話式 AI 的實戰藍圖｜A Practical Blueprint for Evaluating Conversational AI at Scale（Dropbox Tech Blog, 2025）

[2] Anthropic AI Agent 評估指南｜Demystifying Evals for AI Agents（Anthropic Engineering, 2026）

以上文章為【數創電子報 Vol.31】來自 Dropbox 的啟示：沒有評估標準，你永遠是最後一個知道 AI 出事的人

想收到更多 AI 相關學習與趨勢文章嗎？訂閱數創電子報

很多 AI 專案最尷尬的時刻，不是在開發前，而是在 PoC 或 Demo 之後。

許多 AI 專案並非技術問題，而是團隊從未在開發前對齊「什麼叫做成功」。
當工程師、PM、主管與使用單位對成效各有解讀，測試分數再漂亮，也難以成為共同接受的驗收依據。
上線後問題才浮現，時程延誤、反覆修改，沒人敢真正驗收。 這場公開體驗課將帶你從企業真實 AI 專案出發，拆解常見驗收盲點，
釐清團隊在驗收前真正需要對齊的核心問題。