前端三分鐘 X 要轉職養豬還是做被取代的工程師？用 Google AI 打造我的 AI 雙刀流自動化工作流系列

在上篇我們介紹了 AGENT.md 作為養豬場的管理憲法。有了規則之後，下一個挑戰就是：規模化 (Scale)。

如果你問一個現代智慧養豬戶：「你一個人要怎麼管理 1,000 隻豬？」
他絕對不會回答你：「我就每天跑來跑去，一隻一隻手洗、一隻一隻拿飼料餵啊。」

如果這樣幹，豬沒長大，人就先累死了。

現代養殖業能做到一個人管理上千隻豬，核心就在於極致的任務拆解 (Task Decomposition)。

養豬場的任務拆解樹

養豬場的日常運作，絕不是一句「把我這 1000 隻豬顧好」那麼模糊，而是被拆解成高度專業且獨立的模組：

養豬場運營系統
│
├── 餵食模組 (Feeding)
│   ├── 早餐（高蛋白質飼料）
│   ├── 午餐（微量元素補充）
│   └── 晚餐（易消化飼料）
│
├── 環境控管模組 (Environment)
│   ├── 清潔（自動沖洗通道）
│   ├── 溫度（感測器動態調節排風）
│   └── 給水（自動水嘴運轉）
│
└── 健康監測模組 (Health)
    ├── 常規檢查（AI 視覺檢測）
    ├── 生物隔離（異常個體通報）
    └── 數據紀錄（寫入 Google Sheets / 系統）

軟體工程的災難：對 AI 給予「巨型模糊 Prompt」

許多工程師在叫 AI 寫 Code 時，最常犯的錯就是把整隻「1000 隻豬的巨大任務」直接丟給 Gemini：

❌ 錯誤示範：「幫我寫一個完整的會員管理系統，要包含登入、註冊、權限控管、資料庫設計跟前端 UI，要能直接跑起來。」

結果就是 Gemini 產出一堆寫到一半被截斷的程式碼、漏掉關鍵的權限判斷，或是產出一個包含 3,000 行的泥潭巨型元件。

關鍵質疑：AI 不是本來就會自己拆？為什麼還要寫成 JSON？

這是一個非常棒的工程問題：「讓 AI 回傳 Markdown 的 PLAN.md 讓人看不好嗎？為什麼一定要強迫輸出 Structured Output (JSON Schema)？」

答案取決於你的對象是**「人類」還是「自動化程式 (Pipeline)」**：

• Markdown Plan (PLAN.md)：適合**「給人看」**。自由度高、讀起來舒服，但結構容易隨 AI 發揮而改變（例如這次用清單、下次用標題），腳本極難解析（Parse）。
• Structured Output (JSON Schema)：適合**「給程式跑」**。強型別、結構完全固定，程式碼可以用 JSON.parse() 100% 穩定接管，直接進行自動化迴圈與 CI/CD 測試。

在自動化工作流中，我們採取的最佳實踐是：「用 JSON 當核心驅動資料，再由 Script 自動渲染出 PLAN.md 給人類 Review。」

用 Gemini + Structured Output 進行任務拆解

要讓 AI Agent 能精準執行巨型任務，工程師必須先扮演「架構師」，指導 Gemini 將大需求拆解為小任務，並透過 Structured Output (JSON Schema) 強制指定輸出的任務清單格式。

1. 定義任務拆解的 JSON Schema (TaskSchema)

在呼叫 Gemini API 時，我們可以強制要求的 JSON 輸出結構：

{
  "type": "OBJECT",
  "properties": {
    "feature_name": { "type": "STRING" },
    "subtasks": {
      "type": "ARRAY",
      "items": {
        "type": "OBJECT",
        "properties": {
          "step": { "type": "NUMBER" },
          "category": { "type": "STRING", "enum": ["DB", "API", "UI", "Test", "Deploy"] },
          "task_description": { "type": "STRING" },
          "expected_output": { "type": "STRING" }
        },
        "required": ["step", "category", "task_description", "expected_output"]
      }
    }
  }
}

2. 讓 Gemini 將「幫我做會員系統」自動拆解為流水線

當我們輸入「請幫我設計一個會員管理系統」，結合上述的 Structured Output，Gemini 就會精準輸出結構化的任務清單：

{
  "feature_name": "Member System Automation",
  "subtasks": [
    {
      "step": 1,
      "category": "DB",
      "task_description": "定義 Google Sheets 欄位 (user_id, email, password_hash, role, status)",
      "expected_output": "Google Sheets Data Schema Definition"
    },
    {
      "step": 2,
      "category": "API",
      "task_description": "撰寫 Google Apps Script 處理 POST /register 與 /login 請求",
      "expected_output": "GAS Apps Script 程式碼"
    },
    {
      "step": 3,
      "category": "UI",
      "task_description": "建立獨立的 <member-login-card> Web Component",
      "expected_output": "帶有 Shadow DOM 的 Custom Element 檔案"
    },
    {
      "step": 4,
      "category": "Test",
      "task_description": "撰寫 Vitest 驗證輸入格式與 API 錯誤處理狀態",
      "expected_output": "member-login-card.test.js"
    },
    {
      "step": 5,
      "category": "Deploy",
      "task_description": "透過 ESM URL Import 將元件掛載至主站點測試",
      "expected_output": "可執行的 index.html 展示頁"
    }
  ]
}

為什麼 Task Decomposition + Structured Output 這麼重要？

1. Context 零干擾：每個子任務（如僅處理 <member-login-card> UI）只吃它需要的脈絡，不會因為爆 Token 而產生幻想。
2. 自動化閉環 (Programmatic Loop)：你可以寫一個 Node.js 腳本走 subtasks.forEach()，讓 Gemini CLI 針對每一個小任務自動接力執行，執行完一個自動測一個。
3. 高可控性：如果 Step 2 API 壞掉，你只需要重跑 Step 2，不用整座養豬場重蓋。

結語：學會分工，你才是真正的架構師

現代工程師價值不在於你能「徒手搬多少磚」，而在於你能否將複雜問題拆解成機器與 AI 能夠穩定執行的單元任務。

📝 本日實作作業：

挑選一個你目前手邊正在做的功能，用今天的對照邏輯（需求 ➔ DB ➔ API ➔ UI ➔ Test ➔ Deploy），將它手動寫成一份 JSON 拆解清單。

養豬最怕豬生病，寫 Code 最怕 AI 生病，明天 Day 14，我們將拆解怎麼解決這個問題，明天見！