從對話發現 Skill 機會

你不需要「想」哪些工作該寫成 skill。讓你的對話歷史自己告訴你。

---

課程目標

• 學會 5 類「skill 候選訊號」——這些訊號每天都在你對話裡出現，只是沒注意到
• 認識部門 skill skill-spotter：每天下班前掃一次，自動撈候選
• 學會 score 公式：什麼是「值得寫」的 skill，什麼是「寫了會後悔」的

---

一、第 1 課的問題：你想不出 skill 候選

第 1 課最後一題請你列「重複工作」清單。如果你寫不出來——很正常。

原因：你的大腦不擅長記錄重複。

• 每次做的時候，你只專注在「把這件事完成」
• 做完就忘
• 一週後別人問你「最近在忙什麼」，你只記得最後 3 天

但對話歷史不會忘。git log 不會忘。memhall 不會忘。

這堂課就是教你怎麼從這些「不會忘的記錄」裡，讓重複自己浮現。

---

二、5 類 Skill 候選訊號

部門整理了 5 種訊號，按「skill 候選價值」由低到高排：

#	訊號類型	怎麼辨認	候選價值
1	重複指令	同類 Bash 命令出現 ≥ 3 次	中
2	多步 manual workflow	對話裡有「先 X 再 Y 再 Z」型敘述	高
3	抱怨型訊號	「每次都要⋯」「煩死了⋯」「拜託這個能不能⋯」	高
4	Correction Loops	LLM 答錯 → 你手動修正邏輯	最高
5	Context Reloading	反覆讀同一組檔案 / 重複貼相同背景	中

我們一個一個看。

訊號 1：重複指令

最直白的訊號。同樣或同類的 bash 命令在對話裡出現 ≥ 3 次。

例子：

• 你跟 Claude 講：「跑一下 ssh server docker ps」
• 過幾分鐘：「再 ssh 一次 server，看看 web 容器」
• 又過一陣：「server docker logs main-app」

→ 這 3 次都在「ssh server 看 docker 狀態」。可以寫一個 server-status skill。

怎麼找：翻你今天的 transcript，搜「ssh」「curl」「docker」「git」這類動詞。

訊號 2：多步 manual workflow

你跟 Claude 描述了「先 X 再 Y 再 Z」這種多步驟流程。

例子：

• 「我每次寫提案都先複製公司簡介那段，貼到新文件，改客戶名，加客戶 logo，再開始寫主體。」

→ 4 步驟、每次都這樣做、可以寫 proposal-init skill。

怎麼找：搜「先」「再」「然後」「接著」「最後」這些連接詞。

訊號 3：抱怨型訊號

最容易找——情緒詞自帶痛點。

例子：

• 「每次都要手動把 Slack 截圖貼進 Notion，煩死了」
• 「拜託這個能不能自己跑啊」
• 「每週五晚上整理週報，真的浪費時間」

→ 抱怨 = 高頻 + 痛點明確。skill 候選的金礦。

怎麼找：搜「每次」「每天」「每週」「煩」「浪費」「拜託」「自動」。

訊號 4：Correction Loops（最高價值）

這是最容易被忽略但最有價值的訊號。

定義：Claude / LLM 給了答案 → 你說「不對，應該是⋯」→ Claude 改 → 你又說「不對，應該再⋯」→ 最終你給了一段「正確邏輯」。

為什麼最有價值？

因為這段邏輯已經被你人工驗證過。你不需要再發明它，只要把它固化成 skill，下次同樣情境直接套用，不用再修一輪。

例子：

Claude：「這份財報的營收看起來增長 12%」 你：「不對，要扣掉外匯影響再算」 Claude：「OK，扣掉外匯後是 8%」 你：「不對，外匯影響的算法是用月平均匯率不是月底匯率」 Claude：「OK，用月平均後是 10%」 你：「對了。」

→ 你剛剛親手「教 Claude」一個業務邏輯。下次別人也要做這份報告時，他要不要再從頭教一遍？不要——把它寫成 revenue-fx-adjust skill。

怎麼找：搜「不對」「應該」「再修」「重新」這類修正詞。

訊號 5：Context Reloading

每次跟 Claude 對話，你是不是常常先貼一段背景才開始？

例子：

• 「先貼一下我們公司的客戶 segment 定義」
• 「先看一下這份 SQL schema」
• 「先讀一下我們的 brand guideline」

如果同一段背景你在不同對話貼了 3 次以上——這代表它應該變成一個永久背景，而不是每次手動貼。

→ 寫成 skill，把那段背景放進 SKILL.md body 或 references/。

怎麼找：你最近對話的「開場白」——是不是有重複的內容？

---

三、Score 公式：什麼候選值得寫

撈到候選不代表都該寫。部門用以下公式打分：

priority = (frequency × estimated_token_saved × stability) / implementation_cost

四個變數的意思：

frequency：當週出現次數

• 每週 1 次 → 1
• 每天 1 次 → 5
• 每天 ≥ 3 次 → 10

estimated_token_saved：每次省的 token

• 簡單一行命令 → 50-100
• 多步流程 → 500-1000
• 複雜分析 → 2000+

stability：流程穩定度（0.0–1.0，最關鍵）

• 每次步驟完全一樣 → 1.0（其實該寫 hook）
• 每次大致一樣，細節變 → 0.7-0.9 ✅ 完美 skill
• 步驟會變但骨架穩定 → 0.5-0.7
• 每次都不一樣 → 0.0-0.4 ❌ 不要寫

stability < 0.5 一律不建議寫成 skill——強迫固化會變成維護地獄。

implementation_cost：寫起來的難度（1-5）

• 純 prompt 引導 → 1
• 含 1-2 個簡單 bash → 2
• 含 reference files / decision tree → 3
• 含 Python script → 4
• 含 MCP 整合 / 跨服務 → 5

公式直覺

priority 高 = 高頻 + 高 token 節省 + 穩定 + 寫起來不貴。

如果你拿到一個候選，stability 算 0.4 → 直接淘汰，不用算其他變數。 如果你拿到一個候選，implementation_cost 是 5 但 frequency 只有 1 → 也淘汰，太貴。

---

四、認識 skill-spotter

部門有一個 skill 專門做這件事：

/skill-spotter

它的工作就是：

1. 讀你今天的 session transcript
2. 撈當日 git log + memhall episode
3. 用上面 5 類訊號 + score 公式找 top 候選
4. 對每個候選用「三門診斷法」（下一課教）告訴你該寫 Hook / Skill / Agent
5. 產出可直接交給 skill-creator 的 spec
6. 強制做 PII scrubbing（避免公司路徑 / token 進 spec）

什麼時候跑？

部門慣例：下班前 5 分鐘。

• 跑完 /team-wrap-up 把今天決策寫進部門記憶
• 跑 /skill-spotter 看「今天有沒有東西值得固化」
• 如果撈到 0 個——沒關係，那就是訊號（今天沒有重複到值得固化）
• 如果撈到 1-3 個——挑一個最容易的開始

不要硬湊

skill-spotter 有一個重要原則：撈不到夠穩定的候選，就講實話「今天沒料」，不會硬湊 top 3。

不要因為跑了 /skill-spotter 就強迫自己每天寫 1 個 skill——那會產生一次性垃圾 skill，3 個月後沒人記得它存在，目錄膨脹。

---

五、實際 Mining 範例

假設今天你的對話有以下片段：

[09:30] 我：跑 ssh server docker ps
[09:35] Claude：（執行）
[10:15] 我：再 ssh server，這次看 main-app logs
[10:18] Claude：（執行）
[11:00] 我：每次部署完都要手動 ssh 看狀態，煩死了
[14:20] 我：server disk 還有多少？
[14:22] Claude：（執行）
[16:00] 我：先貼一下我們的 API schema⋯（貼了 200 行）
[16:30] 我：再貼一次⋯API schema（同一段）

你的 mining 應該抓到：

候選	訊號類型	frequency	stability	priority
server-status（ssh server 狀態檢查）	重複指令 + 抱怨	每天 3 次	0.9	高
api-schema-context（自動載入 schema）	Context Reloading	每天 1-2 次	1.0	中

兩個都值得寫，但 server-status 優先（更高頻 + 有抱怨痛點）。

---

六、Mining 的進階技巧

1. 看你的 git log

git log --since='1 week ago' --all --oneline | sort | uniq -c | sort -rn

如果同類 commit message 出現多次（例如「fix: typo」5 次），這代表你重複犯同類錯——可能該寫 hook 而不是 skill。

2. 看你的 memhall episode

curl -s http://100.122.171.74:9100/v1/memory/search \
  -H "Authorization: Bearer $MH_API_TOKEN" \
  -d '{"query":"重複","mode":"hybrid","limit":20}'

搜「重複」「煩」「每次」「自動化」這些關鍵字。歷史 wrap-up 會記錄你過去的痛點。

3. 跟同事比對

你以為你才有的痛點，可能 5 個同事都有。 部門 standup / Slack 雜談裡，看別人說「我每次⋯」的時候，那也是 skill 候選。

寫成 skill 上 PR 到 team-skill-lab → 全部門受惠。

---

七、結論

• 5 類訊號：重複指令 / 多步 workflow / 抱怨 / Correction Loop / Context Reloading
• Correction Loop 最有價值——已經被你人工驗證過的邏輯
• Score 公式：(freq × token × stability) / cost，stability < 0.5 直接淘汰
• 部門 skill skill-spotter 自動跑這個 mining
• 撈到 0 個是正常訊號，不要硬湊
• 下一課學「三門診斷法」——拿到候選後，怎麼判斷該寫 Hook / Skill / Agent

---

AI 協作：學了這個，跟 AI 怎麼配合？

Mining 是 AI 的強項——它能耐心掃 1000 行 transcript 不會累。但判斷哪個訊號是真痛點是你的事。

你的人類優勢：

• AI 找到的「重複指令」可能是一次性 debug，不是長期痛點——你看一眼就知道
• Stability 0.7 還是 0.4 要靠你的業務直覺，不能只看表面

可以這樣跟 AI 說：

掃我今天的 session transcript [貼上 / 給檔案路徑]，找出 5 類訊號（重複指令 / 多步 workflow / 抱怨型 / Correction Loop / Context Reloading）。每個訊號用 score 公式打分，但 stability 欄位先填「待確認」——我看完之後自己填，因為穩定度要靠我判斷。

---

練習題