內部 AI Portal 上線了一批新能力。

首頁很完整。

左邊是一排選項：

Knowledge Search
Issue Search
Source Search
Execution Supporter
Log Analysis
Action Tool

一位使用者進來，只想做一件事：

「幫我找今天失敗的 Case，看看第一個失敗點在哪。」

系統先問：

請選擇要使用的 Tool。

他停了一下。

選了 Log Analysis。

下一頁又問：

請選 Source。

他選了 Runtime Log。

結果系統回：

No case context provided.

他不知道自己少的是另一個 Search Skill，還是其實應該先選 Execution Supporter。

工具都有。

能力也都有。

只是使用者在真正開始工作前，先被要求理解底層架構。

Capability Catalog 不是使用者的 Workflow

當團隊把很多 Skill 做出來後，很容易用一種很工程化的方式暴露能力：

我們有 A
我們有 B
我們有 C

這對 Builder 很有用。

他需要知道有哪些 Component 可以組。

但一般工作入口真正收到的通常不是：

請呼叫 Log Analysis Skill。

而是：

幫我找出今天哪個 Case 先壞掉。

這也是 Source 裡 Intent-first Routing 的核心：

user intent
→ entry skill
→ specialist skill
→ source / mapping / case

使用者先說工作。

系統再決定能力路徑。

把 Complexity 丟回使用者，不叫「給他選擇」

有人會說：

讓使用者自己選 Tool 最透明。

問題是，如果選錯 Tool 才能知道自己選錯，那這個決策其實需要的是系統知識。

例如同一句：

幫我看這個 Requirement 能不能往下做。

底層可能需要：

state reconstruction
→ evidence check
→ rule lookup
→ recommendation

使用者不需要先知道每一步叫什麼。

真正該保留給人的，是那些需要權責或業務判斷的 Decision。

不是底層 Topology。

所以 Source 裡還補了一句限制：

Hide implementation complexity, not decision accountability.

複雜度可以藏在 Capability Layer。

決策責任不能一起藏掉。

Intent-first 不等於 Agent 自己隨便猜

如果使用者說：

「幫我處理那個問題。」

Target 根本不清楚，系統還是要問。

Intent-first 的意思不是：

不管多模糊都讓 AI 自己推。

而是不要要求使用者用 Internal Architecture 的語言描述需求。

應該問的是工作問題：

你指的是哪個 Case？

而不是：

你要選 Log Analysis 還是 Source Search？

首頁最後少了很多按鈕

Portal 後來沒有把那些 Tool 刪掉。

Builder 和維護者仍然看得到完整 Catalog。

只是一般入口改成一個輸入框：

你要完成什麼？

那位使用者再輸入：

「找今天失敗的 Case，告訴我第一個失敗點。」

系統先找到 Case。

再把 Runtime Evidence 交給 Log Analysis。

只有 Target 不明確時才回來問人。

使用者沒有選任何 Skill。

底下仍然走了好幾個。

工具數量沒有變少。

只是它們終於不用先存在使用者的腦子裡。