前言：Agent 最貴的不是推理，是每次都重新摸索

前幾天我們把 Company Brain 的資料層整理好：記憶放記憶，原始知識放 Obsidian，搜尋交給衍生索引。但即使資料找得到，Agent 每次接到相同類型的工作，仍可能重新嘗試工具、重新踩同一個坑。

這是另一種失憶：不是忘了事實，而是忘了做事的方法。

在 ZoneTech，這個問題很快變得具體。LINE@ 日報、Google Sheet 財務報告、網站追蹤、認證檢查，表面上都是不同任務，實際上都包含固定的登入前置、資料收集、去重、格式化、驗證與交付。若流程只存在某一次對話裡，下一次就得重新描述一次；若只存在某個人的腦中，換人或換 Bot 就會中斷。

所以我們把可重複的工作流程寫成 Skill。

Skill 不是提示詞收藏夾

一個好的 Skill 不是「請模型用專業方式完成某事」這種抽象指示，而是一份可執行的工作契約。它至少要回答：什麼情況要使用、輸入在哪裡、步驟怎麼走、哪些動作需要授權、怎麼驗證、失敗時停在哪裡。

我現在把 Skill 看成介於 SOP 與程式之間的層：比 SOP 更貼近工具操作，比程式更能處理需要判斷的情境。

例如，發布 iThome 文章的 Skill 不只寫「把文章貼上去」。它定義了 D1-D30 的有限編號、標題與正文分離、CodeMirror 與原生 textarea 必須同步、先存草稿再重新載入驗證，以及正式發布後要讀回公開頁面檢查繁中是否變成 ï¼ 或 æ。這些規則把一次踩雷，轉成下一次的護欄。

什麼工作值得變成 Skill

我使用三個條件判斷：

第一，工作是否會重複。只做一次的臨時分析，通常留在工作文件即可；每週或每天出現的任務，才值得固化。

第二，工作是否容易因細節出錯。若成功與失敗只差一個欄位、一個帳號或一次讀回驗證，就不應依賴記憶。

第三，工作是否能描述驗收標準。無法說明「什麼叫完成」的流程，先不要急著自動化，否則只是把模糊交給模型放大。

這三個條件也避免了 Skill 膨脹。不是每段對話都要保存；保存太多反而會讓 Agent 在不相關的任務載入一堆規則，增加上下文成本與衝突機率。

Skill 的基本結構

我們採用接近 README 的純 Markdown 結構，讓人能讀，也讓 Agent 能依段落執行。

這裡最重要的是邊界。像「寄信」與「產生信件草稿」不能共用同一個完成定義；前者是外部不可逆動作，後者是本機產物。Skill 必須明確區分，避免 Agent 把草稿寫好就誤認為已送出。

三個月長出一百多個 Skill 之後

當工作流程開始累積，新的問題出現了：Skill 本身也會重複、過期、互相矛盾。

我們曾經有不同版本的 LINE 操作流程，分別記錄個人 LINE、LINE@ 與舊的 opencli 路徑。若只看檔名，很難知道哪一份仍然有效。後來加上 ownership 與 scope，並定期做 Skill 盤點：誰負責、服務哪個 Profile、是否仍被 Cron 使用、是否有更權威的新流程。

盤點結果分成四類：

保留：仍在使用，且最近一次實測通過。

合併：不同名稱其實是同一流程，保留一份主 Skill，其餘留下轉址或淘汰說明。

修正：流程仍需要，但工具版本、欄位或驗證方式已經改變。

停用：沒有使用者、沒有 Cron 引用，或已被官方流程取代。

這裡有一個反直覺的原則：不要因為「看起來可以合併」就直接刪除。先盤點引用關係、產出報告，再確認 owner 與回滾方式。自動化系統最怕的不是少一份文件，而是刪掉仍在運作的依賴。

workflow-audit：從踩雷記錄找新 Skill

我們也建立 workflow-audit 的做法，定期讀取 Cron 執行記錄與對話，找出反覆出現的模式：相同的認證失敗、相同的資料清理、相同的外部驗證，或同一個人每次都要補充的隱藏前提。

候選流程要先通過一個小測試：把它交給另一個沒有看過原始對話的執行者，是否仍能完成？如果不行，通常不是模型不夠強，而是 Skill 缺少輸入、停止條件或證據要求。

這種方法讓 Skill 從「事後整理文件」變成「從事故與重工反推制度」。每一次失敗都不一定要增加更多文字；有時候真正的修正是補一個檢查命令，或把兩個模糊步驟拆成明確的階段。

實際驗證：不能只看檔案存在

Skill 寫完後，我們至少做三層驗證：

本機變更：檔案存在，frontmatter 可解析，路徑與引用沒有錯誤。

流程執行：用測試輸入跑一次，確認工具真的能取得資料，而不是只看模型說「已完成」。

外部效果：若流程會發訊息、建立文件或發布文章，必須讀回實際目標，確認內容、對象與狀態。

這個標準看似嚴格，卻直接降低了「假完成」。exit code 0 只能說程式結束，不代表資料正確；API 回傳成功，也不代表使用者看得到結果。

結語：把經驗變成團隊的第二次起點

Skill 的價值不是讓 Agent 變得更像魔法，而是讓成功不再只屬於第一次做對的人。

在 ZoneTech，我們希望把每個可重複的知識工作，逐步變成有 owner、有輸入、有輸出、有授權邊界、有驗收證據的流程。這才是從「我會用 AI」走向「公司有一套能複製的 AI 作業系統」。

下一篇會把這件事往更現實的地方推進：當文件開始承擔制度功能，工程 SOP、職位說明與 KPI 要怎麼寫，才不會只是漂亮但沒人照做的文件。

實際證據

本篇的流程原則已落地在 Hermes 的 Skill 管理：Skill 以 Markdown 保存，依觸發條件載入；重複工作透過 workflow-audit 找候選；正式外部動作要求讀回驗證。判定流程是否完成時，仍以實際工具結果與目標系統讀回為準，而不是以模型敘述代替證據。