OpenClaw 的 AI 工程實習生工具箱：Tools、Context 與 Knowledge 設計
上一篇〈讓 AI 當我的工程實習生：在公司導入 OpenClaw（龍蝦）的實戰心得〉講了為什麼要 AI 實習生、怎麼落地、以及踩到的坑與建議。這篇會拆解 OpenClaw 的實際運作方式：我給龍蝦哪些工具、如何設計 MCP、knowledge 怎麼組織，以及為什麼「完全不為 AI 製作工具，其實是很高的成本」。
工具架構的重點：可用的指令 ＋ 使用的脈絡
工具架構的核心其實很簡單：可用的指令（Tools）＋ 使用的脈絡（Context）。
龍蝦透過工具操作系統（Jira、Git、Jenkins、Telegram），不直接改程式、不自己拍板。但光有工具還不夠——「脈絡」指的是讓龍蝦知道在什麼情境下用哪個指令、先讀什麼。實務上，沒有脈絡時它會修 A 漏 B、搞錯語意；有脈絡（knowledge ＋ Jira 留言）才能推進任務，所以 MCP 和 knowledge 是綁在一起的。
舉例：同一張 Jira 單「修正某 API 回傳格式」，有脈絡時我會在 Jira 留言寫「優先檢查 A 專案的 B 模組」「修完記得補單元測試」，龍蝦就會先讀 knowledge 裡該專案的結構、再依留言收斂範圍；沒脈絡時它可能亂試一堆 repo、或只改後端沒改前端，任務幾乎推不動。
AI 的執行工具：MCP、Skill、本地腳本
龍蝦（或廣義的 AI 工程實習生）實際執行任務時，用到的工具可以分成三類：
- MCP（Model Context Protocol） — 連接外部系統的介面。例如 Jira、Telegram、Jenkins：龍蝦透過 MCP 讀寫 Jira 單、收發 Telegram 訊息、觸發 Jenkins 部署，而不是直接碰資料庫或伺服器。好處是權限與邊界清楚，也方便擴充新系統。
- Skill — 定義「在什麼情境下、怎麼做」的流程與規則。例如「處理 Jira 單」這個 skill 會規定：先讀描述與留言、先寫修復計劃、改完要發訊息、不知道怎麼做就留言給人。Skill 讓龍蝦有固定的作業程序，不會每次自由發揮。
- 本地腳本（local scripts） — 我們事先寫好的 shell script 或小工具，龍蝦只負責「呼叫」，而不是自己解讀一整份 API 文件。例如部署時呼叫一支固定的 deploy script，傳入專案名或 branch，腳本內部再去打 Jenkins API。這樣可以減少龍蝦要理解的內容、降低 token 消耗，也減少呼叫錯誤。
這三類加起來，就是 AI 的執行工具箱：MCP 負責「連到哪裡」、Skill 負責「按什麼步驟做」、本地腳本負責「把複雜操作包成簡單指令」。
MCP：Jira、Jenkins、Telegram 的分工
MCP 在我們的流程中主要連接三個系統：
- Jira — 任務管理
- 指派任務給龍蝦，或龍蝦列任務發派給相關人／自己
- 龍蝦回報進度、記錄修復計劃與結果
- Jira 一定要搭配 knowledge，不然龍蝦根本不知道怎麼處理
- Telegram — 指令與回報
- 下達任務指令（例如
/assign JIRA-1234） - 查看龍蝦進度
- 接收通知（改完、遇到阻礙時）
- 下達任務指令（例如
- Jenkins — 部署
- 由龍蝦觸發部署流程
- Jenkins 負責實際執行（前文已寫）
這三者缺一不可，否則整個 workflow 接不起來。
在流程裡可以這樣對應：MCP 用在讀寫 Jira、收發 Telegram、觸發 Jenkins；Knowledge 用在龍蝦動手前先讀（專案結構、修復流程、架構文件），所以接單後會先查 knowledge，再決定看哪些 repo；Skill 規定「先讀描述與留言、先寫修復計劃、改完要發訊息、不知道就留言給人」等步驟，讓它照著做不亂跑；預先寫好的腳本 則在部署等固定操作時被呼叫，龍蝦只傳參數、不自己解讀 API。這樣 MCP、knowledge、skill、腳本各司其職，流程才穩。
為龍蝦製作工具與腳本
有些任務需要我們做工具和腳本給龍蝦用。例如部署：除了提供 Jenkins API，我和龍蝦一起做了本地 shell script 指令，把「要觸發哪個 job、傳什麼參數」包成固定指令，龍蝦只要呼叫這支 script，不用每次去讀 Jenkins 文件或理解一整串 API 參數，大幅降低 token 消耗與出錯機會。
實務上我發現：若不在 skill 裡寫死「部署就是用哪個腳本」，龍蝦會自己想一堆心路歷程、去讀專案文件、繞很多方法才成功，或最後告訴我辦不到。為了節省 token 與提高成功率，要避免讓它做過多思考——有些方法可以先用你慣用的語言模型（Codex、Claude、Gemini 等）試跑一次，確認可行後再寫進 skill、放到 repo 給 OpenClaw 用，龍蝦就可以少走很多歪路。
在 knowledge 裡，很多專案性質我做成.json 格式，例如：專案名稱、描述、用途、git 位置、對應的 tag 或 branch 慣例。這樣我下指令時可以很快指定「幫我處理 B 專案的那張單」，龍蝦也能從同一份 JSON 知道要去哪個 repo、預設從哪個分支拉。結構化之後，人和龍蝦都能利用這些資訊更快達到目的。
工具與腳本不是可選的，而是讓龍蝦能穩定運作的必要投資。
Skill Repo：讓 OpenClaw 可以「繁殖」
我和龍蝦一起維護另一份skill 專案（獨立 git repo），請它把現在用到的工具（不含敏感資訊）和 skill 寫進那一份 repo。雖然還沒實作，但我認為這樣很有機會可以繁殖第二隻 OpenClaw——下一隻龍蝦可以直接從這份 repo 長出來，不必從頭再教一遍。概念上就是：AI agent、self bootstrapping、reusable skill base。
Knowledge：放什麼、怎麼用
先用語言模型寫好教材，再給龍蝦用
經過一些試錯後我發現：一步一步教龍蝦的成本，遠高於自己先用語言模型寫好教材。你可以叫 OpenClaw 去讀你建好的文件，但不建議把「寫 knowledge」當作對它的訓練。原因是：以它的機制，每次都會送大量前後文給所接的語言模型，會燒爆 token。我的做法是先在機器上跑 Codex、Claude、Gemini 這類語言模型，把 Knowledge 建好，再給龍蝦用——成本遠低於讓龍蝦在對話裡一步一步學。
和它一起維護 knowledge 專案與 skill
Knowledge 和 skill 我都放在獨立的 repo，和龍蝦一起維護。這樣做的好處是：可複製——下一隻龍蝦或新環境只要 clone 同一份 knowledge 與 skill 就能沿用；可迭代——發現規則不足或寫錯時，直接改 repo，不用在對話裡重教；可審核——所有變更都進版控，誰改了什麼一目了然。長期來看，這些 repo 就是 AI 實習生的「教材庫」與「作業手冊」，養好一份，後面都能重用。
結語
若要用一句話收斂實戰心法，我會這樣說：
- 先想工作流程——希望它做到什麼、在什麼節點介入，想清楚再給工具。
- 再想它需要什麼資訊與工具——對應到 knowledge（專案結構、流程、文件）與 MCP、腳本，缺一不可。
- 用 skill 規範它專注——避免它亂想、亂試；規定步驟與邊界，讓它照著做，省 token 也提高成功率。
完全不為 AI 製作工具，其實是非常高的成本；每一次都靠長對話解釋流程，不但消耗 token，也容易讓它在任務中迷路。若你也在養自己的 AI 實習生，希望這三點心法能讓你少踩一點坑。
