本篇文章更新時間：2026/03/15
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
內容目錄
當工作流程被默默 A/B 測試：從「Please Do Not A/B Test My Workflow」談使用者透明度與操控權
編輯前言：這篇文章源自作者在使用 Claude Code 時的挫折——工作流程突然被改變、功能行為失常，而他甚至不知道自己被放進了 A/B 測試中。身為重度 AI 工具使用者，我覺得這個議題非常值得深究。
核心觀點 (Key Takeaways)
- A/B 測試本身不是問題，問題是缺乏透明度與使用者選擇權。
- 當 AI 是專業工作工具時，任意更動核心功能會直接破壞使用者效率。
- AI 工具有責任提供更高的可控性與可設定性，而不只是黑箱式更新。
深入解析
文章主軸非常清晰：作者付費使用 Claude Code（每月 200 美元），並依賴它完成專業工作。然而過去一週，他發現自己的 workflow 突然下降——尤其是 plan mode 的輸出變得「簡短、跳躍、缺乏脈絡」。
作者最震驚的部分來自於 Claude 本身的回答：
它表示自己正在遵循某些系統指令，例如將計畫限制在 40 行、禁止撰寫 context、以及「刪除敘述，不刪除檔案路徑」。
雖然作者後來刪除了驗證過程的細節，但核心訊息依然明確：他並不知道自己正在被測試，而這些測試直接降低了工具效能。
A/B 測試為何會變成問題？
如果是電商介面、按鈕顏色，A/B 測試當然沒問題。但對於一個每天倚賴 AI 生成計畫、修改程式碼的人來說，「AI 會怎麼反應」就是使用者的工作流程本身。
因此任何改動——尤其是核心 prompt 或行為邏輯——都會明顯影響結果品質。
工程師的回應：測試目的其實蠻合理
貼文後續提到一段 Hacker News 上的討論，指出 Claude Code 背後也有成本考量：
如果所有處理程序都開滿功率，200 美元的訂閱可能會變成 400 美元。
而負責這次測試的 Anthropic 工程師其實也出面說明：
他的假設是「更短的計畫可以減少 rate-limit 觸發，但結果卻沒有明顯提升，因此測試已經結束」。
換句話說，目的不是惡意，而是想讓流程更有效率。但問題依然存在：使用者完全不知情。
筆者心得與啟發
讀完後，我最大的感受是——AI 產品已經從「工具」變成「工作流程的一部分」。這意味著：
- 不透明的 A/B 測試會造成實質損失，而不是單純體驗下降。
- 專業使用者需要的不只是「好用」，而是「可控」與「可預期」。
- 開發者必須重新思考透明度：哪些行為、哪些 prompt 能被告知？哪些應開放設定？
身為 AI 使用者，我覺得有三件事值得倡議：
- A/B 測試應該要 opt-in，至少是對高強度專業用戶。
- 核心功能的行為應該公開說明，尤其是系統 prompt 這種決定性因素。
- 使用者需要可自訂的模型行為配置，以確保工作不中斷。
換句話說，這篇文章不只是一位重度使用者的不滿，而是一則提醒：
當 AI 開始參與我們的工作，它就不再只是產品，而是共同作業者。而共同作業者需要透明、可靠，並尊重使用者的流程。
本文靈感來源自原文： Please Do Not A/B Test My Workflow