Threads 精華 · Claude Code 全自動開發看板（@ericchien21）

Claude Code 全自動開發看板 Workflow

作者：@ericchien21 平台：Threads 瀏覽：1.3 萬整理日期：2026-06-01

Agentic Dev Claude Code Worktree

工程師 @ericchien21 分享自製 Jira-like dev board，結合 Claude Code 實現「拖 story → AI 自動開 worktree 做完發 PR → 人只負責 review」的完整 agentic 開發閉環。走「傳統敏捷開發 + AI 自動實作」路線，夜間還有 Autopilot 模式讓 Claude 自己撈 ticket 做，早上只需 review。

⚙ 核心 Workflow — 從 PRD 到 Human Review

PRD 討論

與 AI 討論產品需求，確認功能範圍與驗收標準，輸出 PRD 文件。

技術規格分文件

AI 協助拆解技術實作細節，產出分模組的技術規格文件。

切 Story

Claude 根據技術規格，將功能切成可獨立執行的 story（類似 Jira ticket），每個 story 標明需重點讀取的相關檔案。

Dev Board 管理（Backlog → In Progress）

自製看板（類 Jira）可視化管理所有 story。

拖曳 story 從 Backlog 到 In Progress
自動 trigger Claude 在獨立 worktree 執行該 story
每個 story 有自己的 Git worktree，互不干擾

Claude 在 Worktree 執行

Claude Code agent 在獨立 worktree 實作 story，共享 memory system 理解 codebase context，story 內標明需重點讀的檔案清單。

自動發 PR + CI 監控

實作完成後自動發 PR，持續監控 PR 狀態：

CI 跑 test 結果
merge conflict 偵測
PR ready to merge → 自動移到 Human Review 區

Human Review & Merge

人工審查並 merge PR。目前仍為人工，是整個流程的最大 bottleneck。CI 有跑 test 但作者仍偏好人工看 code。

自動解鎖相依 Story

merge 後系統自動 unblock 依賴此 story 的後續 story，下一個工作項目自動進入 In Progress。

🌙 夜間 Autopilot

運作方式

睡前開啟 Autopilot 模式，系統自動從看板撈 ticket 分派給 Claude agent 執行，早上起床只需 review 已完成的 PR。

用量窗口保護機制

自動監控 claude -p 的 5 小時 usage window limit。快到上限時不再 dispatch 新 agent，讓當前執行中的 story 穩定做完，避免半途中斷留下爛尾。

注意：claude -p 計費政策 6/15 有變動，用此方案的工程師需提前評估新計費成本。

參考設計

做法參考 OpenAI Symphony，適合「想自己 review code、需要 safeguard」的工程師，而非完全放手給 AI。

🧠 Memory System + 行動控制

自製 Memory System

讓不同 worktree 的 agent 共享 codebase context
每個 story 內標明需要重點讀取的相關檔案
解決多 agent 並行時各自對 codebase 理解不一致的問題

Tailscale 遠端控制

接 Tailscale，手機出門也能連回 dev board
在外也可查看看板狀態、手動 dispatch 或調整優先序

Rule-based Dispatcher

目前用自己寫的 rule-based dispatcher（非 AI）決定分派邏輯
決定哪個 story 分派給哪個 agent
作者考慮若反響好則開源

💬 留言討論精華

@debuguy.dev

問：code review 驗收怎麼做？claude -p 計費問題如何處理？

作者回應：CI 有跑 test 但還是人工看；感謝提醒 6/15 claude -p 要改新 policy；目前用自己寫的 rule-based dispatcher。

debuguy 補充：Agent review 的目的是「讓 agent 寫出符合預期的 code，同時讓人 review 更快」，而不是取代人工 review。

@arumwu

跑 rule-based dispatcher 半年心得：角色拆出來後，最大瓶頸是「什麼交給 agent、什麼自己 review」的判斷標準怎麼定。這個邊界非常難自動化，也高度依賴個人對 codebase 的信任度。

@enskylin

建議先研究 Paperclip：有 kanban + dependency block + multi project + multi company + 多 agent + project worktree，功能對齊度很高，可以省不少自製工作。

@alanjy_huang

問是否做成 plugin，sub agent 有沒有 tag？
補充：通常拆四種 agent 角色 — 開發、測試、管理、研究
可讓「管理 agent」監督「開發 agent」，形成 agent hierarchy

@benxu.huang

也在做類似的事，用現成的 Hermes Kanban：讓 Hermes Agent 自己開 Ticket 並透過 Agent 認領獨立完成，最後發 PR 人工 review。做法與 @ericchien21 高度相似，但走現成工具路線。

💡 Takeaway — 對照 WT 的 Ralph Loop

@ericchien21 做到的

Jira-like 看板視覺化所有 story
拖曳觸發 → 自動開 worktree
Claude 在 worktree 自動實作
自動發 PR + CI 監控
PR 完成 → 自動解鎖相依 story
夜間 Autopilot 全自動跑
usage window 自動保護
Tailscale 手機遠端控制

WT 的 Ralph Loop 現況

task_queue.md 純文字任務佇列
checkpoint.md 斷點恢復機制
背景代理（nohup / run_in_background）
patrol.sh 定時巡檢
DC 訊息接任務
手動回報進度
沒有視覺看板
沒有自動開 worktree + PR

差距分析（可參考補強方向）

差距 1

看板視覺化：WT 靠 task_queue.md 純文字管理，缺乏 kanban 視覺化。@ericchien21 有完整 board，能一眼看到所有 story 狀態與依賴關係。

差距 2

自動開 Worktree → 發 PR 閉環：WT 的背景代理執行後沒有自動 PR 機制。@ericchien21 從「拖 story 到 in progress」到「PR ready to merge」是全自動的。

差距 3

相依解鎖：WT 的 task_queue 沒有 dependency tracking。@ericchien21 的 board 有 dependent story 在 merge 後自動解鎖的機制。

差距 4

用量保護機制：@ericchien21 有 5hr window 監控，快到上限不 dispatch 新 agent。WT 目前靠人工感知用量，沒有自動保護。

相同點

核心概念高度一致：任務佇列、背景 agent 執行、checkpoint 恢復、人工做最終 review。差在視覺化介面與 worktree → PR 閉環的自動化程度。

整體結論

「人只做 review，其餘全自動」的 agentic workflow 是可落地的，@ericchien21 做到了完整閉環。
最大瓶頸不是 AI 實作速度，而是 human review：「什麼該自己看」的判斷標準目前最難自動化（@arumwu 跑半年的心得）。
開源工具 Paperclip、Hermes Kanban 提供現成替代方案，不一定要全部自製。
claude -p 計費政策 6/15 有變動，驅動 agent 的成本結構需要重新評估。