當需求開始變複雜，我讓 Claude 開了三個 Subagent 分頭行動

在這一次接手的專案裡，進入正式開發前，我先使用了 Claude Design 完成了整體的視覺原型與 Dashboard 頁面規劃。設計確定後，我將產物匯出，正式交由 Claude Code 接手後續的工程實作。

當我準備讓 Claude Code 動手時，我面臨了一次相對複雜且多面向的需求——解析設計規範、重構 Layout 機制，還要將儀表板原型落地。

如果把這些龐大的任務通通塞給單一對話視窗，AI 通常會因為訊息量太大而上下文混亂，或是急著動手改程式，結果改到一半才發現規格根本沒對齊。

這一次，我試了一種協作方式——Claude Subagent（子代理人）。

我叫它「先開三個 Subagent 去規劃」

在這次的開發中，我對 Claude Code 提出了這樣一個需求：

「請協助我定義設計規範及版型……

以上請先定義及確認規格後再進行實作。」

這一段對話最有趣的改變，不是指令變長了，而是：

我把 AI 當成一個「專案經理（Main Agent）」，由它去發派任務給專門的工程師（Subagents）。

按下 Enter 之後，Claude Code 沒有急著去改程式碼，它在背景同時啟動了三個獨立執行的 Subagent，分別去解讀設計規範、評估 Layout 可行性，以及對照既有 API 確認資料落差。

而主對話視窗裡，Main Agent 只負責回報一件事：

「三個子代理已在背景並行執行，各自只產出規格文件、不動實作程式碼……三者完成後我會整理彙總給你確認。」

在 Subagent 的模式下，主對話視窗被「乾淨地留了下來」。

Subagent 在背景跑了幾分鐘後，各自產出了獨立的規格文件，並把遇到不確定的決策點丟回給 Main Agent 彙總，由它來到我面前提問。

AI 沒有代替我做決定，也沒有直接把程式碼改得面目全非。

它把複雜的任務拆開，在子環境裡跑完分析，最後拿著「清楚的待確認事項」來到我面前。當我確認完規格後，Main Agent 才正式接手，一次性地把需求精準寫完。

程式寫完，畫面看起來已經有模有樣了。

但我打開瀏覽器一看，總覺得哪裡怪怪的——畫面四周被一圈神祕的空白包圍著。我沒有自己開 F12 去查，而是直接把現象告訴它：

「長得滿美的。不過頁面有個問題，body 有個神秘的間距把畫面元素往內擠了，請幫我加 reset css。」

Claude Code 很快就查出了原因，解決了邊界貼齊的問題。

這又再一次印證了我的感受：
AI 可以幫我們把 80% 的架構與設計原型很快蓋好，但剩下那 20%「用起來順不順、看起來對不對」的細節，依然需要人類開發者親自去觀察與判斷。

從使用 Claude Design 設計原型，到讓 Claude Code 開 Subagent 進行工程落地，AI 並沒有讓我的工作消失。

它只是把我從繁瑣的細節中抽離出來，讓我能站在更高的維度去思考產品畫面順不順、判斷指標合不合理、決定哪些功能該第一版做。

AI 協作的工具和機制一直在進化，但那個「發現問題、下達判斷、負責驗收」的核心循環，始終沒有變過。

我依然在建立屬於自己的 AI 開發工作流，而這次，多了一群可以隨時分工的子代理人。