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

前幾篇我們一路從 Prompt ➔ Agent ➔ Rules ➔ Plugin ➔ Sidecar ➔ Subagent ➔ Plan ➔ Google AI Studio ➔ Structured Output ➔ Function Calling ➔ Google Sheets，一路「養」到現在。

但一個極度現實的問題浮現了：我們到底養出什麼東西？

如果最後只是「AI 幫我產生了一堆 Code，畫面很漂亮但不能用」，那還是挺空虛的。所以今天不談大道理，我們直接來做一個真的——🐷 小豬健康紀錄網頁。

我要它不只是一張 Mockup，而是能真正運行：輸入資料 ➔ 按下儲存 ➔ 寫入 Google Sheets ➔ 讀取歷史紀錄。

       [ 使用者輸入 ]
             │
             ▼
      ┌──────────────┐
      │ 小豬紀錄網頁  │
      └──────┬───────┘
             │ (POST JSON)
             ▼
     [ Apps Script API ]
             │ (appendRow)
             ▼
     [ Google Sheets ] ──> [ 歷史數據 / AI 分析 ]

這一刻，AI 就不再只是個「聊天機器人」，而是開始幫我們把需求變成一個真的能工作的軟體。

一、先不要蓋大型養豬場：MVP 優先原則

如果今天真的要幫表姊夫做系統，我當然可以開出很炫砲的 Spec：
React + Next.js + PostgreSQL + Authentication + Docker + Kubernetes + IoT MQTT + Microservices……

然後三個月後：

🧑‍💻 工程師：「表姊夫，系統架構快完成了，現在有完整的 CI/CD 跟 K8s 呢！」

👨‍🌾 表姊夫：「那我现在可以記小豬體重了嗎？」

🧑‍💻 工程師：「還不行，驗證模組跟 DB Migration 還在修……」

👨‍🌾 表姊夫：「……」😂

所以這次我們反過來走 MVP（最小可行性產品） 路線：先證明「這個資料流程真的能跑通」。

二、第一步：先定義資料，再叫 AI 寫 Code

在叫 AI 生成任何一行 Code 之前，我會先定義資料架構（Data Contract）：

{
  "pig_id": "P001",
  "weight": 82,
  "temperature": 38.5,
  "health": "normal"
}

這一步至關重要。沒有先定義 Schema，AI 很容易自由發揮，今天命名 pigId、明天變 pig_id、後天又變成 pigNumber。最後養豬場沒亂，Google Sheets 欄位先亂成一團。

三、第二步：讓 AI 快速產生 Responsive UI

我們直接把需求明確丟給 AI 工具（如 Copilot / Gemini）：

請幫我建立一個「小豬健康紀錄」網頁：
1. 採用 Mobile-first 的 Responsive Design，卡片式 UI。
2. 包含欄位：小豬編號 (pig_id)、體重 (weight)、體溫 (temperature)。
3. 健康狀態可選：正常 (normal)、需要觀察 (warning)、異常 (critical)。
4. 包含「儲存紀錄」按鈕與「最近 10 筆紀錄」清單展示。
5. 當體溫異常 (≥40.0°C) 時，介面需有明顯警告色。

工程提示：AI 生成的第一版只是 Prototype。不要因為畫面好看就覺得大功告成，我們真正要驗證的是 「畫面 ➔ 資料 ➔ API ➔ Google Sheets ➔ 讀回畫面」 這條連線是否暢通。

四、第三步：Apps Script API 與前端資料對接

1. Apps Script 端（資料入口）

在上一篇建立的 Google Sheet 中，掛載這段 Apps Script：

function doPost(e) {
  try {
    const data = JSON.parse(e.postData.contents);
    const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName("pigs");

    sheet.appendRow([
      new Date(),
      data.pig_id,
      data.weight,
      data.temperature,
      data.health
    ]);

    return ContentService
      .createTextOutput(JSON.stringify({ success: true }))
      .setMimeType(ContentService.MimeType.JSON);
  } catch (err) {
    return ContentService
      .createTextOutput(JSON.stringify({ success: false, error: err.toString() }))
      .setMimeType(ContentService.MimeType.JSON);
  }
}

2. 前端 Fetch 發送請求

async function savePigRecord(pigData) {
  const APPS_SCRIPT_URL = "YOUR_DEPLOYED_WEB_APP_URL";
  
  const response = await fetch(APPS_SCRIPT_URL, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(pigData)
  });

  return await response.json();
}

// 觸發儲存
await savePigRecord({
  pig_id: "P001",
  weight: 82,
  temperature: 38.5,
  health: "normal"
});

這時候，我們就不只是在畫 UI，而是在建立一條完整的 Data Pipeline 了！

五、第四步：引入 Structured Output 讓 AI 參與健康判斷

既然資料已經結構化，我們就能讓 Gemini 參與決策，對小豬的狀態做出初步診斷：

// Prompt: 請根據體溫與體重數據分析小豬狀況
// Output Schema:
{
  "status": "normal | warning | critical",
  "reason": "體溫偏高，達到 40.2°C",
  "suggestion": "建議進行隔離觀察並量測第二次體溫"
}

前端接收到 Structured Output 後，即可直接根據 status 渲染不同顏色的 Warning Badge。

⚠️ 關鍵 Guardrail：AI 不是獸醫

在實際生產環境中，千萬不能把 Gemini 的建議直接當成專業醫療診斷。標準的工程架構應該是：

  [ 感測資料 / 輸入 ]
         │
         ▼
  [ 固定的安全規則 (Rule-based) ] ──(超標)──> 立即發起系統告警
         │
         ▼
  [ Gemini 輔助推理 / 分析建議 ]
         │
         ▼
  [ 人工確認 (Human-in-the-Loop) ]

六、最終的小豬紀錄 Web App 成果

這座 Minimal Web App 最終包含了完整互動邏輯與歷史資料回讀：

┌───────────────────────────────────────────┐
│ 🐷 小豬健康紀錄系統                        │
├───────────────────────────────────────────┤
│ 小豬編號 : [ P001                       ] │
│ 體重 (kg): [ 82                         ] │
│ 體溫 (°C): [ 38.5                       ] │
│ 健康狀態 : (🟢正常) (🟡觀察) (🔴異常)       │
│                                           │
│            [ 🐷 儲存健康紀錄 ]             │
├───────────────────────────────────────────┤
│ 📋 最近歷史紀錄 (Synced with Google Sheet) │
│ • P001 │ 82kg │ 38.5°C │ 🟢 正常          │
│ • P002 │ 75kg │ 38.2°C │ 🟢 正常          │
│ • P003 │ 91kg │ 40.1°C │ 🔴 體溫異常告警  │
└───────────────────────────────────────────┘

這不再只是一個展示用的 Demo，而是一個能切實解決現場問題的完整工具！

💡 結語：AI 時代工程師的思維轉變

以前拿到需求，工程師的第一反應是：

「要用 React 還是 Vue？API 要寫多美？要不要寫 Dockerfile？」

現在 AI 時代，第一個問題變成了：

「這個需求，我能用多小的架構把它跑通？」

 [ 傳統開發模式 ]：需求 ➔ 選型大型架構 ➔ 寫 Code ➔ 部署 ➔ 驗證 (耗時長)
 [ AI 雙刀流模式 ]：需求 ➔ Data Contract ➔ Prototype ➔ 跑通資料流 ➔ 漸進式升級

工程師的核心價值沒有消失，只是從「編寫基礎語法」往上搬移到了「定義需求、設計資料合約、挑選工具與建立安全防線」。

至於轉職養豬嘛……如果哪天 AI 真的把軟體開發全部自動化了，我再去養豬也不遲。至少豬應該不會突然跟我說：「幫我把這個按鈕改成圓角 12px。」😂

明天 Day 30，我們一起回顧我想像中未來小豬的模樣，以及我到底該不該現在轉職，我們明天見！🐷