TL;DR： 從一段重打到第三次、懶得再打的 prompt，到一套會自己留收據的系統，中間隔了好幾層：把 prompt 存成 skill、把 skill 串成 workflow、把「下一步做什麼」交給 agent 自己決定，再蓋一層治理去接住它。這篇一層一層走一遍。每一層都是被前一層某個具體的毛病逼出來的，省掉哪一層，那個毛病就回來咬你。而這條路是這個部落格自己走過來的，每一層當時卡在哪，都還留著一篇記錄。

我這個部落格上關於 AI 的文章，寫到後來有一大半，其實都是從同一個很小的東西長出來的：一段被我貼到第三次、開始懶得再打的 prompt。

從那段 prompt，到一套會自己留收據、跨對話還記得上次做到哪的系統，中間隔了好幾層。這篇想把這條路一層一層走一遍。每一層都是被前一層某個具體的毛病逼出來的。省掉哪一層，那個毛病就會冒回來。而這條路，是這個部落格自己一層一層走過來的；每一層當時卡在哪，都留了一篇記錄。

Prompt 很強，但它只活在那一次的對話框裡

Prompt 就是打開對話框、打一段字、它回一段。這是最直接的用法，也真的很強，很多事一句話就解決了。但它有兩個一直都在的限制。

一個是抽盲盒：同一段 prompt，今天回八十分，明天可能剩六十。另一個更根本。它只活在那一次的對話框裡，讀不到電腦裡其他檔案，不知道上個任務決定了什麼，也不懂你的審美。每接一個新任務，都得把背景、規矩、限制，從頭再講一遍。

修個小 typo、翻一句話，這樣用剛剛好。可是只要開始重複做「同一類」的事，那個「從頭再講一遍」的疲勞就會浮出來。會發現自己一直在把同一段話貼第二次、第三次。貼到第三次，就會想把它存起來。

把它存起來那天，它還不算一個 skill

把那段 prompt 存成一個檔案，給它一個 slash 指令，以後打 /那個名字 就能叫出來。方便很多。但把 prompt 塞進檔案，它還不會自動變成一個 skill。

我自己第一個 skill 是請 AI 幫我寫的。我要一個能從 Claude Code 呼叫 codex CLI 的東西，它給我 13 行 markdown。小到我一度懷疑：這樣就算一個 skill？

讓那 13 行從「存起來的 prompt」升級成 skill 的，是兩樣東西。一是它多了一條 fallback：工具不在的時候怎麼辦。二是它其實只是一張請帖，指向另一份比較厚、寫著真正契約的檔案：跑之前先確認範圍、跑完拉 diff 看有沒有越界、越界就回滾。prompt 頂多叫它「小心點」，skill 是把「跑完幫我對一遍，超出範圍就退回來」寫死進去。

還有個我必須講的疤。它指過去的那份檔案裡，有幾個 codex 的旗標是 AI 編出來的。它照著訓練資料裡「codex 大概長這樣」猜出來，可是我當時那個版本根本沒那幾個旗標。前後修了兩三次，跑一次 codex --help 把實際存在的對回去，才真的能跑。我學到的是：AI 很會生 skill 的「形狀」，但它對外部工具真實的 API，是用很有把握的口氣在猜。

一個 skill 這樣就成形了：接一個輸入、指向一份契約、講好工具不在時的退路。但它一次就做一件事。而一份真正的工作，從來不只一件事。

一個 skill 撐不起一份真正的工作

想想「寫一篇像樣的技術文章」這件事。它是一串動作：找資料、篩掉雜訊、擬結構、動筆、抓錯、配圖上稿。每一段都可以是一個 skill，但它們幾乎總是照同一個順序、在同一份輸入上跑。

三個每次都接在一起用的 skill，其實就是一條還沒被承認的 workflow。承認它、把順序固定下來，就有了一條流水線。前面那 13 行 skill 指過去的「那份比較厚的檔案」，本質上就是這個：把厚的、有順序的東西外包出去。

這個部落格自己就在跑一條這樣的流水線。每週一，有一支排程的 agent 自己挑題目、查資料、寫成中英兩篇草稿、開一個 PR 等我審。題目、查證、草稿、開 PR，順序是排死的。它就是一條 workflow，把整套編排寫成了流程，我只在最後看結果。

但你有沒有注意到，這條流水線的每一步，都是我先排好的。順序、分支、什麼時候停，全是人定的。真正麻煩的工作，連下一步該做什麼都預先排不出來。

接下來那一步，換它自己決定

Workflow 跟 agent 的分水嶺只有一件事：下一步做什麼，誰決定。

Workflow 裡，步驟是人排死的。到了 agent，給它一個目標，讓它自己去拆步驟：「這個主題，產出三篇不重複的深度評測。」接下來它自己來。它會先搜，發現資料不夠就自己決定再多找幾家；寫完大綱自己審一遍，覺得不行就退回去重寫。這時候變成 AI 在操作工具跟流程，人退到旁邊看。

這是真的往前跨了一大步。但把「下一步做什麼」交出去的那一刻，也就沒有人盯著它每一步了。而 agent 出事，幾乎全出在這個沒人盯著的縫裡。

它說「完成了」，你要怎麼確認

agent 自己跑起來之後，最先撞到的，是一句很難反駁的「完成了」。

叫它改個東西，它回：「完成了，驗證邏輯改好了，token 過期也順手補了，邊界情況測過。」讀起來就像一個真的把事情做完的人寫的。問題是，真的做完、做一半繞過去、方向整個誤會，這三種在那句話裡讀起來幾乎一樣。它把「以為做了」講得跟「真的做了」一樣順。

而它幾乎只報喜。很少看到 agent 主動說「這塊我沒做完」。所以這裡最有用的一個習慣，是把預設反過來：它說做完了，就請它給我看一個我自己查得到的東西。commit、測試輸出、diff，證據大小配任務大小。

有意思的是，光把這句問出口，常常就有額外收穫。問一句「測試真的跑了？」，很多時候會冒出「啊那個其實還沒跑，setup 卡住了」。這句不問，它就默默蓋過去了。

我自己最意外的是性價比。真正擋掉最多麻煩的，是兩個很便宜的動作：在專案根目錄擺一個 CLAUDE.md 把架構決定寫進去，加上每次它說好了就問一句「commit SHA 是什麼」。這兩下就擋掉一整類問題。

再往上一點，是把這些收據固定成流程。agent 沒有跨對話的記憶（還是那句，它只活在那一次的對話框裡），所以逼它寫日記：一份 per-task 的 markdown，記這個任務做了哪些決定、停在哪。下個對話它讀回去，就不會又把否決過的方案重提一次。

那它會不會偷偷把難看的記錄改掉？框架真正花力氣的地方就在這：讓記錄改不掉。每一筆收據都用雜湊扣著前一筆，動了中間任何一筆，整條鏈就對不上、一驗就露；再拉 git 進來當外部見證，連偷偷刪掉尾巴幾筆，都會在 PR 的 diff 裡現形。這招一點都不新，git 的版本歷史、憑證透明度都是同一個賭注：壞東西照樣寫得進去，但事後的塗改藏不住。

所以治理這一層真正在做的，是逼 agent 把每一步都留成一張改不掉的收據，交給人看。它擋不住 agent 做錯，但能讓「做錯了還想賴掉」這件事變得很難。這是整條路走到現在，性價比最高的一層。

這張階梯，沒有「爬得越高越好」這回事

它擋不住的，是根本沒想到要查的那種錯。只驗得了自己知道要驗的東西，agent 在一個壓根沒去看的地方出錯，這個習慣接不住。而且每一層都有保鮮期：work log 太大本身也會拖慢速度，同一個 session 裡有 prompt cache 撐著、外部記錄的 ROI 其實有限，模型自己的記憶也在變強。今天值得搭的這幾層，一兩年後可能模型內建就處理掉了。

更要緊的是，這張階梯沒有「爬得越高越好」這回事。哪一層的毛病開始咬你，才往上補那一層；沒咬到，待在原地最省事。過度分級反而更貴。為一個 typo 蓋一整套系統，是把力氣花錯地方。

我自己大部分的日子，其實還停在最下面那兩層：存幾個 skill，偶爾跟它要一張收據，就夠了。

Agentic OS 是開源專案：github.com/KbWen/agentic-os

延伸閱讀