新的 AI Operations Portal 上線後，首頁只剩一個輸入框。

工程師不必再記工具名稱與參數，只要輸入：

幫我檢查 payment-service 昨晚 23:00 到 01:00 的部署與錯誤紀錄。

Agent 會自己找 Tool、查資料，再整理成統一格式。原本十幾頁的 CLI 文件被縮成三個範例問題。

Demo 時，值班主管很滿意。

「這樣新人不用再背 command 了。」

上線第一週，一位資深 SRE 使用得最多。第一天十七次，第二天九次，第三天四次；第四天起，Portal 裡再也沒有他的紀錄。

週會上，產品經理把 Dashboard 投到螢幕。

Power User engagement dropped significantly after initial trial.

SRE 看了一眼，打開終端機。

opsctl incident collect \
  --service payment-service \
  --from 23:47 \
  --to 00:12 \
  --env prod \
  --exclude health-check \
  --dependency-depth 1 \
  --raw

「我一直都有用。」他說。

只是沒有再從 Portal 進去。

Portal 也查得到，但他不知道它實際查了什麼

平台工程師請他示範差別。

SRE 只取錯誤發生前後二十五分鐘，排除 Health Check，Dependency 只看一層，最後保留原始結果。他用這組條件快速確認一個故障假設。

Portal 輸入同樣意思的問題後，回傳三次部署、五種 Error Pattern，還列出四個可能相關服務。

看起來內容更多，卻不是他需要的範圍。

工程師打開執行紀錄，Agent 實際使用的條件是：兩小時區間、三層 Dependency、包含 Health Check，而且不顯示 Raw Output。

「可以在問題裡講得更清楚。」平台工程師說。

SRE 沒有反駁。他只問：「我在查錯時，怎麼分辨是 Tool 找錯資料，還是 Agent 整理錯？」

Portal 把開始使用變簡單，也把原本可見的控制點藏起來了。

對新人是學習成本，對熟手是控制權

--dependency-depth、--exclude、--raw 對新使用者確實有門檻。自然語言入口的價值，就是讓他先描述問題，再由系統補上大部分預設值。

但資深 SRE 已經知道哪些 Log 是雜訊、時間該縮到多小、Dependency 查幾層才有意義，以及什麼時候一定要看原始資料。

對他而言，參數不是要記憶的負擔，而是工作的一部分。

要求他把精確條件翻成一長串自然語言，不一定更快。更大的問題是，他失去對執行範圍的確認方式；錯誤結果出現時，也少了能往回追的線索。

因此 Portal 的低門檻不該被理解為唯一正確入口。

它適合讓新人開始；CLI 適合讓熟練者快速、精確地工作。兩者服務的是同一項能力的不同使用方式。

統一能力，不等於統一畫面

平台後來沒有把 CLI 關掉，而是讓它成為正式支援的 Client。

Portal、CLI 與其他 Workflow 都使用同一套權限、版本、執行紀錄與輸出格式。CLI 可以直接指定參數，但不能繞過授權或 Audit；Portal 則保留簡化入口，並增加 Execution Detail，讓需要的人看得到 Tool、參數、來源、原始結果與轉換過程。

這樣真正被統一的是底下的能力，而不是每個人必須按同一個按鈕。

下個月的 Adoption Review，Portal MAU 少了幾個人，其中就包含那位 SRE。若只看這張圖，平台像是退步了。

但團隊把資料拉到能力層後，看到的是：

SRE 不再是 Portal Active User，卻透過 CLI 執行了八十多次同一套 Incident Evidence Collector。每次都有相同權限檢查與 Audit Log，結果也都被 Incident 系統保存。

他離開的是介面，不是平台提供的能力。

平台若把 Portal 使用量直接當成採用率，就會錯把最熟練的使用者判成流失。真正該看的，是那項工作是否被完成，以及使用者能否依自己的熟練程度，從合適的入口完成它。