讓 AI 當我的工程實習生：在公司導入 OpenClaw（龍蝦）的實戰心得
有一段時間，我每天都在處理大量瑣碎、卻又不能隨便交給外包或新人做的工程任務：
修小 bug、改一點 CI 設定、幫產品補幾個欄位、追蹤 Jira
進度、幫忙部署。久而久之，我開始認真思考一個問題：
我可不可以讓 AI 真的變成「工程實習生」？
不是那種「幫我寫一段程式碼就丟著不管」的玩具，而是 能看 Jira、改程式、跑測試、發 PR、更新狀態，最後由工程師審核後幫忙部署 的那種，真正能減少我日常開發負擔的 Agent。
於是，我在公司導入了 OpenClaw（aka：龍蝦），我定義了一堆
Lobster workflow，把這個「AI 工程實習生」實際落地。在這篇文章，我會分享：
- 我為什麼想要一個 AI 實習生，以及選擇 OpenClaw 的原因
- 實際在公司內部，我是怎麼把 Jira、Git、測試、Jenkins 串起來的
- 這個 AI 實習生真的會做什麼？（含實際情境）
- 實作過程中遇到的幾個大坑：跨專案、記憶與 token 上限
- 最後我總結出來的幾個實戰建議：怎麼讓 AI 不暴走、又真的幫得上忙
為什麼我想要一個「AI 實習生」？
如果你也在團隊裡扮演「老屁股工程師」，大概會很有感：很多任務都介於「不難、但很花時間」和「丟給新人會很可怕」之間。
- 一兩個 route 要補 log、補 validation
- CI 有點紅，需要調整 pipeline 或修一兩個測試
- 某個小功能要補欄位、改一下 API schema
- Jira 上一堆小 bug 單，沒人想開 branch 一個一個修
這些事情如果都自己做，成本其實不是技術，而是心力與中斷。而這些工作又非常適合用「規則 + 流程」描述出來，交給一個穩定、聽話的 Agent 去跑。
所以我希望打造的是：
「一個可以自己接 Jira 任務、自己看規格、自己開發與測試，最後由我審核後幫忙部署的 AI 工程實習生。」
我怎麼用 OpenClaw 落地這個想法
OpenClaw 本身是一個自架的 AI Agent 平台，我用來整合各種工具（像是 Telegram、Jira、Git、Jenkins
等）。
在公司的落地版本裡，我大致做了幾件事：
- 讓龍蝦看得懂我們的專案：我先餵它專案的架構知識，讓它知道各個 repo 的角色、目錄結構、關鍵模組，並給予必要的
Git 權限。 - 幫它接上 Jira MCP：讓它不只是「看 Jira
單」，而是有能力直接用 API 開單、讀單、更新狀態與留言。 - 把 Jenkins 當作既有的部署馬達：我沒有重造輪子，而是讓 OpenClaw
在任務完成、PR 審核通過後，去觸發已經存在的 Jenkins pipeline。 - 用 Telegram 當作操作台：平常和龍蝦互動的地方都是在 Telegram
上，像在跟一個遠端實習生聊天，下指令、看進度、叫它開 PR 或部署。
這樣一來，我就有了一個架在公司環境裡、能碰 Jira / Git / Jenkins，又可以用 Telegram
控制的 AI 實習生。
一個實際案例：從 Jira 單到部署
下面用一個具體情境，示範我平常怎麼用這個 AI 實習生。
1. Jira：描述任務，順便給一點提示
首先，產品或同事在 Jira 上建立一張 issue，正常描述要修的 bug 或要加的小功能。
差別在於，我會特別在意：
- 描述裡有沒有包含關鍵線索（錯誤訊息、期望行為、相關模組）
- 我是否要在留言區補充一些「修復方向提示」
為了節省 token、避免龍蝦亂飆，我在它讀 Jira 的 skill 裡硬性規定一件事：
「看描述的同時，一定要看留言。」
所以我會在留言裡寫一些像是：
- 「優先檢查 A 專案的 B 模組。」
- 「這個 bug 很可能和 C service 的 cache 有關。」
- 「記得修完要補上單元測試。」
這樣一來，可以同時達成兩件事：
降低模型探索成本、也降低「走歪」的機率。
2. Telegram：指派任務給 AI 實習生
接著，我會在 Telegram 裡直接把這張 Jira 單交給龍蝦，例如打一個類似：
/assign JIRA-1234龍蝦會回報它打算怎麼做，例如：
- 會先看哪些 repo、哪些檔案
- 預計開哪一個 branch
- 預計新增 / 修改哪些測試
有時候我也會直接請它：「請你幫我處理這張 Jira，完成後發 PR。」
3. AI 實習生實際會做什麼？
在這個流程裡，龍蝦會自動做的事情包含：
- 讀 Jira 單與留言，理解需求與修復方向
- 打開對應 repo，開一個新的 branch
- 修改程式碼，嘗試修復或實作需求
- 執行測試（單元測試／整合測試，視專案而定）
- 發 PR，並在 Jira 上留言更新進度
- 更新 Jira 狀態（例如從「In Progress」改成「In Review」）
如果是一個全新的專案需求，流程還會更完整一點：
龍蝦會先讀規格書，評估需要開幾張 Jira 單，然後自己在 Jira
裡開出這些任務，assign 給自己執行，一路做到測試與回報完成。
4. 最後一步：由人類審核，再由 AI 部署
部署的部分，我刻意沒有自動化到底，而是保留了一個人工審核的 gate。
- PR 是由工程師 review、決定要不要 merge
- 通過 review 後，我才會在 Telegram 上指示龍蝦幫我部署
- 龍蝦會去觸發既有的 Jenkins job，跑完整套 pipeline
這樣的好處是：
AI 仍然是「執行者」，而不是「拍板的人」。決策權留在工程師手上，但實際重複性的操作，都可以丟給它。
跨專案修復的坑：AI 很容易卡在同一個 repo 裡
實務上，最大的坑之一其實不是工具串不起來，而是跨專案修復。
很多現代系統都不只有一個 mono repo，而是：
- 一個前端專案
- 一個或多個後端／微服務專案
- 外加一些共用 library 或 infra 專案
當一個 issue 其實需要同時修改兩個以上的專案時，我發現龍蝦很容易卡在同一個專案裡打轉：
- 例如它已經修好了後端，但一直在後端 repo 裡來回修改細節
- 卻遲遲沒有意識到「前端也要一起改欄位／更新 schema」
這種情況其實很難完全靠「多訓練幾次」就解決，因為牽涉到的是任務邊界與上下游關係。
我最後的做法比較務實：
- 在 Jira 設計上，盡量
把「跨專案」任務拆成多張單，明確標記每張單對應的系統 - 如果真的得由同一個 agent 處理跨專案任務，我會在
留言裡寫得更白一點，甚至一步一步列出：
先修 A 專案、再修 B 專案 - 實在不行，就
拆成多個 session，每個 session 專心處理一個專案，減少它在同一個對話裡「迷路」的機會
記憶與 token 上限：對話變長，任務就容易爆掉
龍蝦在和外部語言模型對話時，是靠一個「記憶檔」來維持任務的連貫性。這在實務上有兩個副作用：
- 任務對話越長，每次呼叫的 token 就會越來越驚人，成本高，而且延遲變長。
- 在極端情況下，甚至會一路堆到模型的使用上限，最後直接被丟
429，任務中斷。
這件事情對「工程實習生」的影響很直接：
- 任務一旦拖太久、對話太多，它就會變得遲鈍又昂貴
- 到最後甚至會因為 token 上限卡住，整個 workflow 被迫中斷
我後來採取了幾個做法來緩解：
1. 善用 knowledge，而不是硬靠長對話記憶
對於比較固定、可以文件化的東西（例如某類專案的架構說明、常見修復步驟、重要約定），我會丟進
knowledge 讓它在開始修之前先看文件，而不是靠「多輪對話慢慢講」。
這樣可以達到：
- token 消耗主要發生在「一開始載入知識」，而不是每一輪都疊加
- 對話中就只需要討論「這次任務的變化」，而不是每次都重講背景
2. 讓 AI 先寫「修復計劃書」與進度表
對於比較複雜的任務，我會先要求它：
「請先寫一份修復計劃書與進度表，再開始動手。」
這份計劃書通常包含：
- 這次任務要動到哪些模組／專案
- 預計會改哪些檔案、做哪些檢查
- 預計會執行哪些測試
一旦這份計劃穩定下來，後面就可以視情況
只保留計劃 + 目前進度，不需要把所有歷史對話都堆進 context。這對 token
消耗和任務穩定度，都有很大的幫助。
3. 每個獨立任務盡量用「一個 Agent Session」完成
最後一個實務上的結論是：
每一個獨立任務，儘量都用一個新的 agent session 來處理。
舉例來說，如果今天是三個互相獨立的 bug，與其讓同一個 session
在裡面來回穿梭，我更傾向讓它一次只專心處理一張 Jira，完成後關閉，再開下一個。
這樣有幾個好處：
- 每個 session 的對話長度可控，不容易爆 token
- 出問題時，容易追蹤：「這個 bug 是在哪一個 session 產生的」
- 不同任務之間的知識污染比較少，不會越修越偏
這樣的 AI 實習生，實際幫了我什麼？
現階段，這個 AI 工程實習生對我來說，已經可以穩定做幾件事：
- 處理一部分明確、邏輯清楚的小 bug 與日常維護
- 幫忙做簡單的功能開發，包含看規格書、拆 Jira 單、自行執行測試
- 維持 Jira 狀態與進度更新的整潔度（不會有「沒人更新狀態」的尷尬）
- 在 PR + 部署環節當一個聽話的「自動化操作手」
它不是完美的，也不是萬能的，但在我願意花時間設計流程與邊界之後，它確實開始幫我省下了一部分「本來就不該由資深工程師一直在做的重複勞務」。
給也想導入 AI 實習生的你幾個建議
如果你也想在團隊裡導入類似的東西，這是我目前的幾個實戰建議：
- 先把它當成「實習生」，而不是「資深工程師」：不要期待它做架構決策，反而要把流程、邊界、權限設計清楚。
- 善用 Jira、知識庫與留言當作「任務介面」：不要什麼都想在對話裡講清楚，能文件化或模板化的東西，盡量提前準備好。
- 把跨專案問題拆小：真的需要跨多個系統的任務，寧可拆成多張單、多個 session，也比讓 AI 在一個巨大任務裡迷路好多了。
- 保留人工審核 gate：讓 AI 盡量幫你做重複操作，但最後一哩路（PR approve、部署到正式環境），仍然應該由人來決定。
- 把「token 與記憶」當成系統設計的一部分：適時 reset session、用 knowledge 取代長對話，都是架構設計，而不是「模型自己會搞定」的事。
結語：OpenClaw 強大的可怕，但它理解力錯誤，或是出現資安弱點，會是可怕的隱憂
對我來說，OpenClaw不是一個「幫我寫程式碼的聊天機器人」，而是一個可以實際融入開發流程的
工程實習生。
它會犯錯、會卡住、會需要我幫它設計任務邊界，但只要我願意花時間教它、幫它把工具串好，它就能幫我省下越來越多的時間，讓我有餘裕去處理那些真的需要人判斷與經驗的問題。
如果你也正在思考「要不要在團隊裡養一隻 AI 龍蝦」，希望這篇實戰心得可以讓你少踩一些坑，或者，至少知道哪些坑是「正常的」，踩到了也不用太挫折。
我確信，它的實際應用有更多的想像空間，但我目前仍是讓它處理可承擔犯錯的後果的任務。並藉由人工審核做最後把關，主要還是在資安疑慮或是他在理解錯誤的狀況下導致無法挽回的後果。
