用 Claude Code 做工程：自己領取下一個 issue 的 AI 員工

工程團隊交給 AI 員工的工作

可以複製的提示詞

每一條既可以當作 AI 員工的週期性 issue，也可以直接在 Claude Code 或 Codex 裡當作一次性提示詞使用。

1. 四項工作，每項一句話

   把名稱和時間換成你們的。前兩項有附設定方法的完整指南：Sentry 錯誤分流和 AI 程式碼審查。

   每天兩次，讀取正式環境裡新出現和再次出現的 Sentry 錯誤，
   把看板上還沒有的開成 issue（寫清楚影響和可能原因），
   一行就能修好的直接開 pull request。
   
   依照 AGENTS.md 裡的規則，審查每個標為可審查的 pull request。
   只留評論；絕不核准或合併。
   
   每週五，根據本週合併的 pull request 寫版本說明：
   對使用者來說改了什麼，依功能區塊分組，附上連結。
   
   接下一個標著「good first issue」的 issue，在你自己的
   git worktree 裡工作，附上測試開 pull request。

如何在 Claude Code 或 Codex 上設定 AI 工程師

1. 規則只寫一次

   把建置和測試指令、慣例和審查規則寫進 CLAUDE.md 或 AGENTS.md，讓每個工作階段都從同一個起點開始。參見 CLAUDE.md 和 Codex 的 AGENTS.md。

2. 每個 agent 各用一個 worktree

   兩個 agent 修改同一份工作副本會互相覆蓋。每個 agent 用一個 git worktree；參見 Claude Code worktree 和同時執行多個 Claude Code agent。

3. 連接工作需要的工具

   GitHub 用它的 CLI，Sentry 用它託管的 MCP 伺服器，你們的任務追蹤工具用它的 MCP 伺服器或 CLI。兩者都有時優先用 CLI，比較省 token。

4. 合併交給人

   agent 開 pull request、留評論；人來核准和合併。員工需要決定時，會把 issue 標為「需處理」並提問。

可以期待什麼

• 描述清楚的小 issue 效果最好：附堆疊追蹤的 bug、缺少的測試、橫跨許多檔案的文案修改。
• 大型功能仍然需要人拆成 issue；agent 擅長做零件，比較不擅長做規劃。
• 用量來自你自己的 Claude 或 ChatGPT 方案；把吃重的工作排在工作時間或夜裡，並控制在額度之內。
• 審查的工作量會轉移，不會消失：pull request 變多，要審的也變多，所以 AI 審查也在這張清單上。

有看板、工作時間和心跳的工程師

Crewmark 把你自己的 Claude Code 或 Codex 變成 AI 員工：每位都有職位、量化目標、工作時間和心跳，從共用看板領取下一個 issue，邊做邊留評論，並開 pull request 等待審查。

1. 聘用這個職位

   從 AI 軟體工程師開始。

2. 把固定工作加成週期性 issue

   分流、審查和版本說明會依各自的排程自動回來。

3. 看看其他團隊

   行銷團隊也用同樣的做法：用 Claude Code 做行銷。所有工作都在使用情境。

常見問題