幫表姊夫做系統別養爆　Agy 落地產線實踐

在前面的系列文章裡，我們一路從 Workflow 產線思維、AGENT.md 憲法、MCP 雙手、Hooks 自動清槽、Rules 規章制度，聊到了 Sidecar 背景巡場、Subagent 小豬機器人分工與 /boost 深度推理。

聽起來是不是熱血沸騰？
但這時候，一個極度現實且殘酷的工程問題浮現了：

「如果今天我直接把這些 Agent 塞進 Production 呢？」

例如直接下指令：「去，把線上這 1,000 隻豬的資料庫欄位全部改掉。」
相信我，今晚你大概不用睡覺了。XD

真正有經驗的架構師，絕不會盲目躁進。本文作為系列完結篇，我們將帶你一步步走過抗中斷的存檔點設計、沙盒驗證、輕量資料閉環，直到真正打造出「小豬健康紀錄系統」！

一、Implementation Plan：抗失憶的狀態機與存檔點

在實際開發（或大規模養豬）過程中，你一定遇過這種令人崩潰的場面：

1
2
3
4
5
6

你：幫我把 A 區豬舍改建，順便把排水溝跟自動餵食槽全換掉。
AI：沒問題！(開始拆牆 ➔ 挖溝 ➔ 搬磚 ➔ 改 A 檔 ➔ 創 B 檔...)
(過了一個小時，Context 爆滿或是 Session 中斷)
隔天重新開工...
AI：場長早！我們昨天挖到哪了？
你：..............（崩潰）

結果 AI 又要重新讀檔案、重新掃描專案、猜測昨天的進度。這不僅是極大的 Token 資源浪費，更讓整個專案陷入失控風險。

Implementation Plan（實作計畫 / 養豬日誌）不只是拿來「開工前畫藍圖」，更是拿來「中斷後恢復 Context」的 Checkpoint 存檔點！

flowchart TD
    Goal["人類場長給定目標 (Goal)"] --> Plan["產出 Implementation Plan 日誌"]
    Plan --> Exec["施工實作"]
    Exec --> Interrupt["(中斷 / 隔天開工)"]
    Interrupt --> Reload["讀取 Plan Checkpoint 存檔點"]
    Reload --> Next["精準繼續執行 Next Steps"]
    Exec --> Verify{"驗證 Inspection"}
    Verify -- 失敗 --> Plan
    Verify -- 通過 --> Done["交付完成 (Done)"]

一份能當作 Checkpoint 的標準 Plan，必須包含 5 大欄位：

1. 為什麼要動這區？（Goal & Scope / Non-goals）：明確劃定邊界，告訴 AI「今天只修 A 區門鎖，不要順便把 B 區的牆給拆了」。
2. 會拆到哪些豬舍？（Files to Change）：動手前列出受影響檔案清單，人類場長簽字後才許開工。
3. 怎麼知道豬有養好？（Verification Checklist）：客觀驗證指標（如 npm test、單元測試）。
4. 今天處理到哪？（Progress Checkpoint）：記載 [x] 進度，隔天開工一秒載入狀態。
5. 當時為什麼這樣決定？（Decisions & Notes）：記錄「為什麼選甲飼料不選乙飼料」，防止 AI 隔天失憶又選錯。

二、養豬第一原則：先在 AI Studio 養一隻試試看

真正有經驗的豬農，絕對不會一開始就：買地 ➔ 蓋 1,000 頭豬舍 ➔ 買 1,000 隻豬 ➔ 開始祈禱。
比較合理的做法是：先養一隻。

確認飼料配方對不對？通風好不好？流程真的養得活？
在把 Prompt、Tool 與 Logic 硬編碼進正式專案前，Google AI Studio 就是最完美的「實驗沙盒」：

flowchart TD
    Sandbox["Google AI Studio (實驗豬舍沙盒)"]
    Sandbox --> Step1["實驗 Prompt 與 System Instructions"]
    Step1 --> Step2["定義 JSON Schema (Structured Output)"]
    Step2 --> Step3["測試 Function Calling 工具呼叫"]
    Step3 --> Verify["驗證工作流成功 (原型豬存活)"]
    Verify --> Prod["搬入 Production 正式專案 (大規模養豬場)"]

⚠️ 關鍵工程警訊：Schema 正確 ≠ 業務內容正確

請千萬記住這個核心原則：

1
2
3
4
5

{
  "pig_id": "P001",
  "weight": 999,
  "health": "good"
}

這段 JSON 完全符合 Schema 定義，但如果 P001 實際上只有 82 公斤，這隻豬已經在 JSON 裡被 AI 養爆了！XD

真正的工程驗證防線應該是：
Gemini ➔ Structured Output ➔ Schema Validation ➔ Business Rule Validation ➔ 進入產線

三、Google Sheets：輕量 MVP 外部記憶與 Data Pipeline

很多工程師會想：「我要做 AI Agent，先來研究 PostgreSQL、API Gateway、Redis 還有 Kubernetes……」結果三個月過去了，Agent 連個影都沒看到。

養豬不能只靠 AI 記住：Context 不是 Database！
每天產生的數據需要持久化儲存。對於小型 Prototype 與內部驗證來說，Google Sheets + Google Apps Script (GAS) 是成本最低、速度最快的選擇：

flowchart LR
    Gemini["Gemini Agent<br>(Structured Output)"] -->|HTTP POST| GAS["Google Apps Script<br>(Web App)"]
    GAS -->|appendRow| Sheet["Google Sheets<br>(試算表資料庫)"]
    Sheet -->|讀取歷史紀錄| Analysis["歷史數據回讀 / 趨勢分析"]

撰寫 Apps Script 資料入口

在 Google Sheet 的擴充功能中掛載簡單的 Web App：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

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);
  }
}

AI 最重要的從來不是「回答得多漂亮」，而是它產生的結果能不能順暢進入下一個系統，形成資料閉環！

四、前端落地：真正做一個「小豬健康紀錄網頁」

如果今天真的要幫老家的表姊夫做系統，開出超炫砲規格：React + Docker + Kubernetes + IoT MQTT + Microservices……
三個月後：

• 🧑‍💻 工程師：「表姊夫，系統架構快完成了，現在有完整的 CI/CD 跟 K8s 呢！」
• 👨‍🌾 表姊夫：「那我現在可以記小豬體重了嗎？」
• 🧑‍💻 工程師：「還不行，驗證模組跟 DB Migration 還在修……」
• 👨‍🌾 表姊夫：「……」😂

所以這次我們反過來走 MVP 優先路線：先定義好 Data Contract，讓 AI 快速產生 Responsive 前端介面，並串聯 Apps Script API：

⚠️ 關鍵 Guardrail：AI 不是獸醫

在實際生產環境中，千萬不能把 Gemini 的建議直接當成專業醫療診斷。標準架構應具備分級防線：

flowchart TD
    Input["感測數據 / 使用者輸入"] --> Rules{"Rule-based 固定安全規則"}
    Rules -- 體溫 ≥ 40.0°C -- 立即觸發紅色告警
    Rules -- 數值正常 --> AI["Gemini 輔助推理與趨勢分析"]
    AI --> Human["人工確認處置 (Human-in-the-Loop)"]

五、如果這不是 Demo，而是一座真的 AI 智慧養豬場？

想像一下，早上 06:00，養豬場開始一天的工作。第一個起床的不是我，而是 Agent 團隊：

1. 06:00｜Sidecar 背景自動化啟動：實時採集溫度、濕度、自動電子秤體重、攝影機巡檢畫面與飼料投放量。
2. 06:05｜MCP 把真實世界接進 Agent：透過 MCP Protocol，AI 伸向實體感測器與控制設備。
3. 06:10｜Agent 自動巡場與數據分類：P001 正常、P002 增重停滯、P004 體溫過高。
4. 06:15｜Subagents 分工協作：主 Agent 自動指派任務給「健康分析小豬」、「成長數據小豬」與「環控小豬」。
5. 06:20｜人類角色登場 (Human-in-the-Loop)：手機響起推播——「今日巡檢完成。997 隻小豬健康正常；2 隻需觀察；1 隻體溫偏高需人工確認。」我喝一口手沖咖啡，走到特定豬舍前進行最後確認。

flowchart TD
    Goal["業務需求 (Goal)"] --> Boss["主 Agent (Farm Boss)"]
    Boss --> Plan["/plan 狀態機藍圖"]
    Plan --> Sub["Subagents 平行開發與審查"]
    Sub --> Hooks["Hooks & Rules 連鎖卡關"]
    Hooks --> Deploy["自動化驗證與部署"]
    Deploy --> Sidecar["Sidecar 24h 背景監控維運"]

Google AI 生態系大總結

結語：我到底要不要轉職養豬？

回到第 1 天我問自己的那個問題：「要轉職養豬，還是做被取代的工程師？」

寫完這系列，我的答案拆解為兩個層面：

1. 我要不要離開工程領域？
   不要。 因為這段旅程讓我深刻體會到：AI 越強大，能將模糊需求轉化為嚴謹 Data Contract、架構邊界與驗證防線的工程師就越不可或缺。工程師的價值從未消失，只是往上移到了架構層。
2. 我要不要去養豬？
   如果真要養豬，我也絕對不會是盲目買 100 隻豬的傳統豬農；而是選擇第三條路：工程能力 × AI × IoT × 養豬！

flowchart TD
    Boss["🧑‍🌾 我 (Farm Manager)"] --> TeamA["🤖 AI Agent 團隊 A 區"]
    Boss --> TeamB["🤖 AI Agent 團隊 B 區"]
    TeamA --> BarnA["🐷 智慧豬舍 A 區"]
    TeamB --> BarnB["🐷 智慧豬舍 B 區"]

或許未來的某一天，我真的會站在竹東老家附近的某座實體養豬場裡，身邊圍繞著一群高效運作的 Agent 團隊。

那時我打開手機預覽介面，畫面顯示：
🟢 今日 997 隻狀況良好 ｜ 🟡 2 隻追蹤 ｜ 🔴 1 隻需人工確認

我喝一口手沖咖啡，笑一笑：
「嗯……這套 AI 雙刀流工作流，好像還真有點搞頭！」 🐷☕

常見問題 FAQ

Q1：在小專案中導入這套流程會不會過度繁瑣？

可以採取漸進式導入：初期僅需 AGENT.md 與 /plan 指令即可獲得顯著的品質提升；當專案擴大或需要背景維運時，再逐步引入 Hooks、Subagent 與 Sidecar。

Q2：Google Sheets 當資料庫能支撐多久？

Google Sheets 僅作為 Prototype 與概念驗證（MVP）時期的輕量過渡方案。當資料量突破數萬筆或需要高併發交易時，應順暢切換為 Cloud SQL 或 PostgreSQL 等正式關聯式資料庫。

Q3：AI Software Factory 最終會完全取代人類嗎？

不會。AI 負責執行、計算與平行化雜活，而核心的需求定義、價值判斷、架構邊界設定與重大風險決策（Human-in-the-Loop），始終需要工程師的專業判斷。

系列導讀與延伸連結

• 上一篇：Agy 互動指令模式切換指南：串聯斜線命令與深度推理階層實踐
• 系列首篇：Agy 自動化工作流架構指南：從單次提示詞邁向任務拆解產線實踐
• 延伸閱讀：Figma 與 Web Component 開發實戰：結合 MCP 與 URL Import 的前端革命

• ← 上一篇