公司內部的 AI Portal 上，多了一張新卡片。

Incident Summary Skill
Version: 1.0
Status: Published

說明寫著：自動整理 Incident 資料，產生事件摘要。適用於維運、客服與產品團隊。

發布三天後，它被執行了四十多次。Dashboard 上的數字也很好看：新上架 Skill、執行次數、建立者人數，全都往上。

產品經理在週會上說，這就是共用的意義。

一個工程師整理好的 Prompt，不必讓每個團隊重新寫一次。貼進平台、取一個名字，其他人就能直接使用。

當天下午，客服營運團隊拿一筆重大客訴來試。

資料裡有 Ticket 對話、產品版本、處理時間軸，還有財務與客服來回確認退款狀態的紀錄。這是一筆重複扣款事件；問題不在服務部署，而在兩個系統對「退款完成」的定義不同。

Skill 很快產出摘要：

事件原因：部署後發生連線逾時

影響範圍：部分使用者無法正常登入

處理方式：回復前一版本後恢復服務

客服窗口重看一次原始資料。裡面沒有部署、沒有登入，也沒有回復版本。

她重新執行。第二次的結果換成「可能與付款服務同步延遲有關，建議確認相關 Log 與部署紀錄」。

她在頁面留言：輸入資料裡沒有部署，為什麼它一直提到部署？

建立者一小時後回覆：

這個 Prompt 原本是給 Incident Report 用的。請先依照標準格式整理後再輸入。

問題到這裡才清楚。

這張卡片上沒有標準格式，也沒有告訴使用者哪些資料不能放進來。它只寫了「Incident」。

原本那段 Prompt 確實有用

這個 Skill 最早是某位維運工程師存在個人筆記裡的 Prompt。

他每週要把正式的 Incident Report 整理成給管理層看的摘要。文件格式固定，通常包含：

Impact
Timeline
Root Cause
Recovery
Follow-up Action

在貼進 Prompt 前，他會先做幾件事：補上服務背景、確認原因是否已經調查完成、把不確定的說法標出來，再決定哪些內容可以寫進摘要。

Prompt 裡也有團隊習慣。例如：原因未確認時，優先檢查部署、設定變更與上游 Timeout；摘要不得超過三百字；後續行動必須列 Owner 與完成時間。

在他手上，這套做法一直很好用。

但那不是因為 Prompt 本身已經處理了所有事情。而是他知道輸入前要先做什麼，也知道產出後哪些句子不能直接送出去。

後來 AI 推動小組募集可共用的內容。他把 Prompt 貼進 Creator，填名稱、說明、分類，選一個圖示，再按下 Publish。

平台欄位都填完了。

只是原本由他自己補齊的那段工作，沒有跟著上架。

名字能被複製，工作不一定能

個人 Prompt 的目的很單純：在熟悉的人手上，幫他把某段重複處理做快一點。

但一個可被別人使用的 Skill，至少還要把工作邊界寫出來：

• 哪些資料可以進來
• 少了什麼資訊就不能做
• 輸出會交給誰使用
• 哪些結果仍然要人工確認
• 出現錯誤時，該由誰修正

這不是多加幾段說明文字而已。

如果輸入範圍沒有寫清楚，使用者只能用名稱猜。看到 Incident Summary Skill，客服自然會認為重大客訴也能使用；產品團隊也可能把品質異常、未整理的 Log 或即時對話紀錄貼進去。

模型不會因為資料不對就自動停止。它通常仍會生成一份看起來完整的摘要。

於是原本只適用於正式 Incident Report 的判斷習慣，被套到根本不是同一種工作的資料上。

輸出流暢，不代表結果可用。

這也是很多公司開始推 Skill 後，明明上架數量一直增加，卻沒有人敢把它放進正式流程的原因。大家共用了同一段文字，但沒有共用到同一份工作規格。

上架前，先把不能用的情況寫出來

推動小組後來沒有急著替更多 Prompt 加名稱，而是先把這張卡片退回 Draft。

他們找原作者與三位實際使用者，把這個 Skill 的範圍重新寫了一次：

這份內容不需要做成很厚的文件。

但至少要讓使用者在按下執行前知道：這是不是它該做的工作。

第一版的問題，不是 Prompt 寫得不夠長，也不是模型不會摘要。真正缺的是輸入不符合前提時，它該停在哪裡。

Version 1.1 沒有變得更聰明

新版保留了大部分原始 Prompt，但畫面多了幾個必要欄位：

Affected Service
Impact
Timeline
Cause Status
Recovery Action

其中 Cause Status 只能選：

Confirmed
Preliminary
Unknown

如果資料是 Customer Complaint Record，Skill 不再硬做一份 Incident 摘要。它會直接顯示：

Unsupported Input

This Skill accepts Production Incident Reports.
The submitted content appears to be a Customer Complaint Record.

同一位客服窗口再試一次時，沒有看到付款服務、部署或連線逾時的猜測。

她也沒有得到摘要。

但這次的結果反而是可用的，因為它沒有把一筆客訴偽裝成一場系統事故。

一段 Prompt 有了名字，不會自動變成 Skill。

它必須先連同原作者原本默默完成的工作，一起被交接出去。