> ## Content Index
> Fetch the complete content index at: http://localhost:2368/llms.txt
> Use this file to discover other available public pages before exploring further.

# 腳本是工具，skill 是流程說明書
- URL: http://localhost:2368/skill-vs-script-clarify/
- Published: 2026-07-24T07:54:48.000Z
- Updated: 2026-08-23T13:54:26.000Z
- Description: 把 Planner 巡檢包成 skill 的過程，用幾個問題釐清腳本與 skill 的分界，途中還修正了一個判斷規則的前提錯誤。
- Author: yuchang23
- Tags: #article

## 背景

公司的四個內部系統都用 Teams Planner 收同仁的問題：同仁在看板上開卡，或者我從通話與 Teams 郵件代他們整理成卡。原本有一支 `check-issues.py` 腳本，session 一開始會自動列出「待回覆」的卡片；抓下來之後怎麼修、怎麼部署、怎麼回覆，每次都靠 AI 臨場組流程。最近用了 /insight 指令讓 AI 分析我的使用紀錄後提議，把「抓問題、修復、部署、回卡片」整條包成一個叫 `planner-patrol` 的 skill。

## 問題一：是因為步驟都是我自己呼叫嗎？

動手前我先問了動機：要這樣做，是因為步驟原本都得我自己呼叫嗎？

AI 回答不是這個原因。抓卡片的腳本、回卡片的 skill 本來就在，它也能臨場把零件串起來。包成 skill 的價值在別處：把品質關卡寫死在流程裡（寫給同仁的根因必須附 diff 或 blame 證據、絕不自動把卡標完成、CI 綠燈之後才能說「已部署」）、讓四個系統共用同一套標準、把觸發成本降到一個詞，過去這些關卡靠 AI 當場記得。

## 糾正一：看板上明明有一張

skill 建好，AI 回報四個看板實測通過、都沒有待回覆卡。我記得 OEE 系統的需求貯體有一張還沒回，提了出來。

AI 查下去發現，規則的前提錯了。腳本定義「待回覆＝同仁最後修改的卡」，但我也會幫同仁建卡，這種卡的最後修改人是我自己，規則天生看不見它們。OEE 看板上五張未完成的卡全部隱形。問題出在規則的假設，跟掃描範圍無關；少檢查一個貯體只會漏一張，假設錯了是整批消失。

## 糾正二：已經回覆三張了

AI 接著提議一個修法：看卡片筆記裡有沒有「開發回覆」這個標題，有就算已回覆。我再指出其中三張早就回覆過了，只是還沒標完成。回覆的形式有「上線紀錄」「查證結果」「通話補充」好幾種，標題不固定，字串比對抓不到。

最後定案的分工：腳本只負責盤點，把未完成的問題卡與需求卡全部列出來；每張卡處於什麼狀態（已回覆待標完成、已決策待實作、還沒動），讓讀筆記的模型判斷。語意判斷寫死在程式裡，換一種寫法就誤判一次。

## 問題二：怎麼知道會呼叫哪個 skill？

之後我說「去抓有沒有 issue 或 bug 要處理」，AI 呼叫了 `planner-patrol`。我趁機問了機制：它怎麼知道要用哪個 skill？為什麼不是另一個「抓問題下來」的 skill？

AI 的釐清是：挑選靠每個 skill 描述欄的語意比對。session 開始時只載入所有 skill 的名稱和描述，我說一句話，它比對最吻合的那個才展開內文。而我以為存在的那個「抓問題的 skill」其實從來不存在——`check-issues.py` 只是住在另一個 skill（負責巡查Planner 看板腳本）目錄裡的工具腳本，不是觸發對象。

## 收斂

所以以前那句「到 Planner 抓要處理的問題」，實際發生的事是：AI 直接跑了 `check-issues.py`，之後的診斷、修復、部署、回覆全是即興。

對話裡 AI 給了一個說法，也成了這篇的標題：腳本是工具，skill 是流程說明書。工具在、說明書不在的時候，品質看當場發揮；說明書寫好之後，同一句話每次走同一條流程。這次連「哪些判斷不該寫死在程式裡」這條判斷原則，也一起寫了進去。