星期三下午，營運分析師 Daniel 寄出本週的 Service Review 報告，比 Deadline 早了快一天。

三個月前，這份報告通常要花他半天：從 Incident System 拉資料、確認重大 Ticket 的 Root Cause、整理 Change，再寫成固定格式。

現在他把前面的資料準備好，交給自己做的 Agent：

Weekly Service Review

1. Major Incidents
2. Repeated Failure Pattern
3. High-risk Change
4. Open Action
5. Owner / Due Date

Agent 先產出初稿，Daniel 再花四十分鐘確認。原本四小時的工作，通常一小時內完成。

隔壁團隊主管看到報告後問：「可以給我們用嗎？」

Daniel 沒多想，按下：

Share
→ Organization

兩天後，使用者變成二十七個。

第一個問題只花五分鐘

有人查不到 Incident。Daniel 看了一眼，發現他沒有讀取權限，回覆該申請哪個 Access。

五分鐘。

另一個團隊沒有 Change Record，想以 Jira Ticket 代替。Daniel順手加了一個判斷。

接著有人問，為什麼 Security Incident 沒被列出。不是 Agent 漏抓，而是原資料被標為 Platform。

然後有團隊要中文版本，要多一段 Customer Impact，也有人問同樣一批 Ticket 為何重跑後內容不同。

第七個問題比較麻煩。

有人把摘要直接貼進主管簡報：

Root cause confirmed as configuration error.

但原 Ticket 寫的是：

Configuration change suspected; investigation ongoing.

Daniel 花了四十分鐘追查，發現 Agent 把 Discussion 裡的推測寫成已確認結論。他改 Prompt、補測試案例，原本預定完成的分析只做了一半。

自己用時，他從未覺得它很難維護

Daniel 自己用了三個月，幾乎沒有大問題。

不是 Agent 對他特別準，而是他知道它哪裡不準。看到 Root cause confirmed，他會回 Ticket 看；某條產品線沒有資料，他知道先查權限；欄位突然空白，他知道最近 API Schema 可能改過。

結果有點偏，他直接手動修兩句就交了。

對他而言，這只是替自己先完成八成工作的工具。

但二十七個人開始使用後，標準改了。

其他人看不到 Daniel 腦中那些補丁。他們只看到：

Generate Report

按下去之後，合理地期待結果可以用。

於是文件、權限說明、錯誤回報、Prompt 修改、Regression Test、版本差異和第一線 Support 全部出現了。

Agent 沒有突然變複雜。

只是「自己能用」和「別人可以依賴」原本就是兩種不同的成本。

公司得到省下來的時間，作者得到維護工作

月底 1-on-1，主管看著 Daniel 的紀錄。

「你那個 Service Review 現在省很多時間吧？」

「我自己做，差不多省三小時。」

「那下個月兩份 Regional Report 也一起給你。」

從主管角度，這很合理。原本四小時，現在一小時，看起來多出三小時 Capacity。

但 Daniel 那週實際花在共享版本上的時間是：

User questions        1.5h
Prompt fixes           1.0h
Permission issue       0.5h
Output investigation   1.0h

自己省下的三小時，已被新增的四小時維護工作吃掉。

只是那些時間沒有出現在 Service Review 的工時裡。

報表上顯示的是：AI 替 Daniel 省了三小時。

實際上，組織得到三小時報告效率，同時新增了一份沒有名字、也沒有正式 Capacity 的共享能力維護工作。

下一版沒有發布

一個月後，Daniel 重做了新版，把結論先分成：

Confirmed
Suspected
Unknown

同事問：「新版更新了嗎？」

「還沒。我先自己跑一陣子。」

他把它放在：

My Workspace

不是他不願意幫別人。

個人版本只需要對自己有用；公開版本代表別人會拿它工作。後者若沒有文件、測試、權限與 Support 的時間，最理性的做法就是不要讓它變成後者。

於是很多真正有用的 Agent 沒有消失，只留在某些人的 Private Workspace。

「分享一下」其實是另一筆投資

平台團隊後來增加的不是新的 Publish Button。那個按鈕一直都在。

他們增加的是 Capability Conversion Budget。

Daniel 再提出 Service Review Agent 時，不再被要求「有空順便整理一下」，而是先估：

Conversion Budget: 24h

Documentation             6h
Regression Cases          8h
Permission / Access Setup 4h
Initial Support           6h

這二十四小時直接排進 Sprint。

如果工具不值得花二十四小時轉成共享能力，就繼續當個人工具；如果值得，公司就正式支付這筆轉換成本。

Daniel 把原本「看一眼就知道」的錯誤整理成測試。另一位同事承接權限說明與第一線問題。

三個月後，平台報告裡出現：

Shared Service Review Capability
Active Teams: 11

Daniel 的 Private Workspace 裡，還是有幾個只供自己使用的 Agent。

沒有人要求他全部交出來。

但那個曾被他藏回去的 Service Review Agent，重新出現在 Shared Space。

Share 按鈕還是只花一秒。

真正讓他願意再按一次的，是那二十四個小時終於被算進工作裡。