Kilo 與 Google 開發工具：AI 自動化開發的現在與未來

AI Coding 正在進入 Agentic Development 時代

傳統 AI 編碼工具主要聚焦於程式碼補全與即時建議，能有效減少重複輸入，但開發者仍需親自負責架構設計、任務拆解、測試撰寫與流程管理。

Agent Workflow 讓 AI 能執行多步驟操作，包括讀取專案檔案、運行終端指令、進行驗證，並根據結果迭代。Agentic Development（代理式開發）則代表更進一步的演進：AI 代理成為開發流程的主動參與者，具備規劃、分解任務、平行執行與自我驗證的能力。開發者轉向更高階的工作——定義願景、設定規則與審核最終成果。

根據目前公開的官方文件與開發社群共識，這一轉變能幫助團隊處理更複雜的專案，並提升整體開發效率。

Kilo Code 是什麼？

Kilo Code 是一款開源 AI Coding Agent，可在 VS Code、JetBrains IDE、CLI、Cloud 與 Slack 等多種環境中運行。它強調模型中立性、代理協調能力與透明度。

主要特性（依官方網站描述）：

• Model Agnostic：支援數百種模型，包含 Google Gemini 系列、OpenAI、Anthropic 等。透過 BYOK（Bring Your Own Key）方式直接連接供應商 API，無額外加價。
• Multi Agent 與 Parallel Agents：支援同時運行多個代理，可在不同工作區獨立作業。
• Multi Mode：內建 Architect（架構規劃）、Code（實作）、Debug（除錯）、Ask（查詢）、Orchestrator（協調）等模式，並允許自訂。
• 平台支援：VS Code 擴充、JetBrains 外掛、CLI（終端介面）、Cloud Agents 與 GitHub 整合。
• MCP（Model Context Protocol）：用於擴充代理工具能力。
• AGENTS.md 支援：這是逐漸在多個 Agent 工具中形成共識的專案規範方式，Kilo 也提供良好支援。
• 其他功能：Sessions 跨裝置同步、自動化程式碼審核等。Browser Automation 等進階功能則視代理權限與工具設定而定。

與其他工具定位差異： 相較於 Cursor（強調流暢 IDE 體驗）、Claude Code（聚焦特定模型的強大推理）或終端導向的 CLI 工具，Kilo 在跨平台代理編排與開源彈性上提供更多選擇，特別適合需要靈活整合多種模型與工具的開發團隊。

Google AI 開發工具生態

Google 持續投入 Agentic 開發工具，主要圍繞 Gemini 模型與相關平台展開。

• Gemini 系列模型：包含 Gemini Flash 系列（適合高效率、低成本工作負載）與 Gemini Pro 系列（適合需要較強推理能力的大型或複雜任務）。
• Gemini API：提供程式化介面，讓開發者將模型與代理能力整合至自有系統。
• Google AI Studio：適合快速原型開發，可從自然語言描述生成應用初步架構，並與 Firebase 等服務整合。
• Antigravity：Google 推動 Agent Workflow 的重要平台之一，包含桌面應用、CLI 與 SDK 等形式，支援代理協調與驗證機制。根據公開資訊，它是 Google 在 Agent-first 開發方向上的重點投入。
• 相關 CLI 工具：Gemini CLI 已逐步朝向更整合的 Agent 體驗演進（具體以官方最新公告為準）。

角色分工（依官方定位）：

• Prototype：AI Studio 適合快速驗證想法。
• Production 與 Agent Workflow：Antigravity 等平台提供更完整的代理管理與企業級支援。

Kilo + Google 開發工具為什麼是好的組合？

Kilo 的開放架構與 Google 的 Gemini 模型可形成互補：

• Gemini Flash / Pro 系列在上下文處理與推理上具備優勢，Kilo 則能有效載入專案全貌與 AGENTS.md 規範。
• Kilo 的 Multi Mode 與 Parallel Agents 可發揮模型在規劃、Debug、Refactor 與測試上的能力。
• BYOK 模式讓開發者能按官方費率使用 Gemini，搭配 Kilo 的 Auto Model 等機制優化成本。
• Git 相關工作流（如 Commit 與 PR）可在 Kilo 中結合 Gemini 推理完成。

此組合特別適合希望同時享有模型效能與工具彈性的團隊。

新增章節：為什麼 Kilo 比 Cursor 更適合大型專案？

許多工程師在評估工具時，會將 Cursor 與 Kilo 放在一起比較。兩者定位有明顯差異：

面向	Cursor（典型）	Kilo（典型）	對大型專案的影響
核心定位	AI 幫你寫程式	AI 幫你完成專案	Kilo 更強調端到端
Agent 模式	單 Agent 為主	Multi Agent + Orchestrator	大型專案易平行處理
開發流程	Prompt 驅動 + Chat	Spec + Rule Driven Workflow	更易維持一致性
模型選擇	較集中	數百種模型 + BYOK	成本與效能更靈活
平台整合	強 IDE 體驗	IDE + CLI + Cloud + GitHub	跨團隊、跨裝置優勢
規則系統	有限支援	AGENTS.md + 完整 Rules	大型團隊規範管理佳

結論：Cursor 在日常快速編碼上體驗優秀，而 Kilo 在大型專案的架構一致性、多代理協作與規則驅動開發上提供更多支援。兩者可依專案規模與團隊習慣選擇或結合使用。

Agent Workflow 範例（Laravel + Vue 專案）

需求：為電商後台新增訂單管理功能。

此流程可在 Kilo Orchestrator Mode 中啟動，開發者主要負責審核 Spec 與最終成果。

Spec Driven Development

單純的 Prompt 在複雜專案中容易導致不一致或遺漏。Spec Driven Development 強調先產生結構化的規格文件，再讓代理依據 Spec 執行。

Kilo 透過 AGENTS.md 與 Rules 系統支援此做法；Google Antigravity 等平台也有類似機制（如 Hooks 與專案規則）。Spec 比 Prompt 更易驗證與維護，是大型專案的重要實踐。

Rule System

推薦專案結構：

text

.project-root/
├── AGENTS.md
├── .kilo/
│   └── rules/
│       ├── coding-style.md
│       ├── api-standards.md
│       └── testing.md
└── .specs/

Laravel 規則範例（coding-style.md 片段）：

Markdown

## Laravel 開發規範
- 遵循 Repository Pattern
- Service Layer 負責業務邏輯
- 使用 Form Request 作為 DTO
- API 回應統一使用 Resource 類別
- Git Commit Message 遵循 Conventional Commits

Rule System 對大型團隊特別重要，能確保程式碼風格、架構決策與安全規範的一致性，減少審核負擔並加速新人融入。

與其他工具比較

（已依回饋調整為更保守描述）

工具	開源	多模型支援	Agent 能力	Multi Agent	Rule System	BYOK	GitHub 整合	MCP	CLI	IDE 支援	適合情境
Kilo	是	是	是	是	完整支援	是	是	是	是	VS Code / JetBrains	大型專案、靈活代理編排
Cursor	否	有限	是	有限	有限支援	是	是	是	否	Cursor IDE	快速日常開發
Claude Code	有限	否	是	有限	部分支援 (CLAUDE.md 等)	否	有限	是	是	多平台	強推理單任務
Antigravity (Google)	部分	Gemini 為主	是	是	是 (Hooks 等)	是	是	是	是	桌面 / CLI	Google 生態 Production

真實案例與社群反饋

官方目前尚未公布具體採用統計或企業案例。社群討論（GitHub、Reddit 等）顯示，開發者常用 Kilo 處理端到端功能開發與規則驅動工作流。Google Antigravity 則在官方展示中強調複雜代理任務。建議直接參考官方 Blog 獲取最新 Showcase。

2026 趨勢

• Agent First Development：平台從輔助工具轉向代理指揮中心。
• Multi Agent Collaboration：平行子代理與人類審核的混合模式。
• Rule / Spec Driven 開發：成為大型專案標準。
• Self-improving 與 Auto Review 機制逐漸成熟。
• 跨平台無縫體驗（IDE + CLI + Cloud）。

如何開始使用

1. 安裝 Kilo：前往 Kilo 官方網站 下載 VS Code 擴充或執行 CLI 安裝指令。
2. 設定模型：加入 Google Gemini API Key（或其他供應商），利用 BYOK 功能。
3. 建立 Rules：在專案根目錄新增 AGENTS.md 與 .kilo/rules/ 目錄。
4. 產生 Spec：使用 Architect Mode 讓代理協助建立規格文件。
5. 執行第一個 Workflow：在 Orchestrator Mode 描述高階需求，觀察代理執行並進行審核。

FAQ

• Kilo 是否一定要使用 Gemini？ 不需要。它支援 Claude、OpenAI、Ollama、本地模型、DeepSeek、Qwen 以及 OpenRouter 等，這是 Kilo 的重要優勢之一。
• 安全性如何確保？ 建議使用 Sandbox 模式、明確權限設定，並人工審核重要變更。
• 適合大型團隊嗎？ 是的，Rules 系統與 Cloud Agents 有助於標準化與協作。

---

參考資料（優先官方來源）：

• Kilo 官方網站 與 文件
• Kilo GitHub 儲存庫（包含 AGENTS.md 相關討論）
• Google AI 官方文件、Google Developers Blog 與 Antigravity 相關公告
• 其他工具比較參考各官方網站公開資訊

SEO Title（5 組）：

1. Kilo 與 Google 開發工具：Agentic Development 實務指南
2. Kilo Code + Gemini：大型專案 AI 自動化開發完整解析
3. Spec Driven Development 與 Kilo Rules 系統實戰
4. 2026 AI Coding 趨勢：Kilo vs Cursor 定位比較
5. 從 AGENTS.md 到 Multi Agent：Kilo 與 Google Antigravity 應用

SEO Description（5 組）：

1. 專業技術文章，深入探討 Kilo Code 與 Google Gemini、Antigravity 的整合，包含 Workflow 範例、Rules 實務與大型專案比較。
2. 中高階工程師必讀：Agentic Development 時代的工具選擇與最佳實踐。
3. 提供 Mermaid 流程圖、Laravel 範例與保守客觀分析的 Kilo + Google 開發指南。
4. 了解 Kilo Multi Agent 優勢、Spec Driven 方法與 2026 開發趨勢。
5. 適合技術部落格或公司內部分享的 AI 自動化開發長文。

Meta Keywords：Kilo Code, Agentic Development, Google Gemini, Antigravity, Rules System, AGENTS.md, Spec Driven Development, AI Coding Workflow

Slug：kilo-google-agentic-development-guide-2026

AI 並沒有改變台灣企業重視成本的文化，它只是讓企業有了更強的成本控制工具

最近一年，幾乎所有軟體公司都開始導入 AI。

從 ChatGPT、GitHub Copilot、Cursor，到各種 AI Agent，工程師的開發效率確實提升了不少。

但是，我觀察到一個現象：

AI 並沒有改變台灣企業重視成本的文化，它只是讓企業有了更強的成本控制工具。

AI 提升的是生產力，不一定是薪資

很多人期待：

AI 能讓工程師更有價值，因此薪資也會提高。

但現實往往不是如此。

如果一位工程師以前一週完成 5 個功能，現在透過 AI 可以完成 8 個。

理論上，公司獲得了更多產值。

然而，在許多企業的思維裡，這並不代表工程師應該加薪，而是代表：

• KPI 可以提高。

• 工作量可以增加。

• 團隊規模可以縮小。

換句話說，AI 提升的是生產力，但生產力是否轉化為薪資，取決於企業如何分配這些成果，而不是 AI 本身。

AI 改變的是企業的成本模型

對許多企業而言，AI 最直接的價值並不是「打造下一個創新產品」。

而是：

• 少請一個人。

• 延後招募。

• 用現有人力完成更多工作。

• 降低外包成本。

• 縮短開發時程。

如果以前需要：

• 3 位 Junior

• 2 位 Senior

現在可能變成：

• 1 位 Junior

• 1 位 Mid-Level

• 2 位會使用 AI 的 Senior

總人數減少，但工作總量沒有減少。

AI 在這裡扮演的是槓桿，而不是福利。

AI 很快就會變成新的基準線

幾年前，如果一位工程師一週完成三個功能，大家會認為效率很好。

今天，公司可能會問：

「不是有 ChatGPT 嗎？怎麼還只完成三個？」

AI 並沒有讓大家更輕鬆。

反而讓原本的高效率，逐漸變成新的最低標準。

當所有人都擁有 AI 工具時，AI 不再是競爭優勢，而是基本配備。

就像 Git、Docker、CI/CD 一樣。

沒有人會因為會用 Git 而獲得加薪。

未來，也不會有人因為會使用 ChatGPT 而自動獲得更高待遇。

技術門檻正在下降，但商業門檻沒有

AI 可以快速產生：

• CRUD 程式碼

• API

• SQL

• Vue 元件

• Laravel Controller

• 單元測試

因此，許多原本需要幾年才能累積的開發能力，現在透過 AI 就能完成七、八成。

但是，公司真正需要解決的問題並沒有改變：

• 系統架構如何設計？

• 資料一致性如何維護？

• 高併發如何處理？

• 權限模型如何規劃？

• 如何降低長期維護成本？

• 如何讓系統支撐未來三到五年的成長？

這些問題仍然需要經驗、判斷與責任。

AI 可以提供建議，但最終仍需要有人承擔決策。

真正被放大的，是能力差距

AI 不會平均提升每一位工程師。

它更像是一個放大器。

會使用 AI 的人，可以更快完成工作。

懂得驗證 AI、修正 AI、整合 AI 的人，可以把效率再往上推。

但如果只是照單全收 AI 的輸出，而缺乏判斷能力，反而可能產生更多技術債。

因此，真正拉開差距的，不是「有沒有使用 AI」。

而是：

• 是否知道 AI 什麼時候是對的。

• 是否知道 AI 什麼時候是錯的。

• 是否有能力做最後的技術決策。

工程師真正需要思考的是什麼？

如果 AI 已經成為每位工程師都能使用的工具。

那麼，真正的競爭力就不再只是：

我會不會寫程式？

而是：

我能不能利用 AI，解決別人解決不了的問題？

包括：

• 系統架構能力

• 跨團隊協作能力

• 商業理解能力

• 技術決策能力

• AI Workflow 設計能力

• 系統整合能力

這些能力，才是真正難以被複製的部分。

結語

AI 的出現，確實改變了軟體開發的方式。

但它沒有改變企業追求效率與控制成本的本質。

對許多台灣企業而言，AI 首先是一種提升生產力、降低成本的工具，而不是重新定義人才價值的起點。

因此，對工程師來說，真正值得投資的，不只是學會使用 AI，而是培養那些 AI 難以取代的能力：判斷、整合、架構設計，以及把技術轉化為商業價值的能力。

因為工具會普及，效率會被追平，但能做出正確決策的人，始終是最稀缺的資源。

很多台灣企業談 AI，第一個想到的不是創新，而是降本增效。

這並不是因為企業有錯，而是市場競爭的結果。

在利潤有限、競爭激烈的環境下，企業最容易衡量的指標永遠是成本。

因此，當 AI 出現後，管理層最先想到的往往不是：

「我們可以做出哪些以前做不到的新產品？」

而是：

• 能不能少請一個人？

• 能不能把原本五人的工作交給三個人完成？

• 能不能縮短開發時程？

• 能不能降低外包成本？

• 能不能提高每位工程師的產出？

這就是「降本增效」的思維。

AI 在這樣的環境裡，首先是一項成本控制工具，其次才是創新工具。

因此，許多工程師感受到的，不是工作變輕鬆，而是工作要求變高；不是薪資因 AI 而同步成長，而是 AI 成為新的基本能力，企業期待用同樣甚至更少的人力完成更多工作。

這不是 AI 的問題，而是企業如何運用 AI 的問題。

補充說明：當公司不成長時，薪資本質上就是零和分配

需要補充一個更現實的底層前提：

當一家公司本身沒有營收成長、沒有新市場擴張、也沒有產品價格重估空間時，薪資調整本質上就會變成一種內部分配問題，而不是價值成長問題。

在這種結構下：

• 薪資不是「創造出來的」，而是「重新分配的」
• 加薪不代表價值增加，而是代表其他地方的資源被壓縮
• 人力成本提升，會直接擠壓公司利潤或其他預算

因此在多數成本導向企業中，即使導入 AI 提升了生產力，企業的第一反應通常仍然是：

用同樣的人做更多事，而不是用更多錢回饋同樣的人。

這不是管理思維的好或壞，而是商業結構的自然結果。

---

另一個更現實的結論

如果從個體角度看，這會導致一個很直接的現象：

薪資成長通常不取決於公司變得更好，而取決於個體是否離開原本的定價市場。

換句話說：

• 在單一公司內，你是在「等待分配」
• 在整個市場中，你是在「參與定價」

當公司沒有新增利潤時，薪資上升空間自然有限，這時候個體能做的選擇，通常只剩下：

• 接受內部分配邏輯（穩定但封頂）
• 或進入不同市場重新定價（但伴隨風險與變動）

從同步阻塞到事件驅動：一次外部 API 抽獎系統的架構重構實戰

 在這次系統重構中，我們面對了一個非常典型但容易被低估的問題：註冊流程中同步呼叫外部抽獎 API，導致整個 PHP-FPM 在高延遲情境下被拖垮。

表面上這只是一個「註冊後拿 QRCode」的流程，但在實際運行環境中，它是一個高度耦合、強依賴外部系統的同步鏈路。

---

一、原始架構：看似簡單，但隱含風險

原始流程如下：

使用者註冊
  → Laravel Controller
  → 呼叫 MIRA 抽獎 API（HTTP blocking）
  → 取得 QRCode
  → 回傳前端

這種設計在低流量下沒有問題，但它有一個致命特性：

HTTP request thread 被外部 API 的延遲完全綁死

---

二、真正的問題不是效能，而是失敗模式

這個架構的問題不在平均效能，而在「尾端延遲與不穩定性」。

當外部 API 出現以下情況：

• 回應時間從 50ms 上升到 500ms+
• 間歇性 timeout
• 網路抖動
• 瞬間流量壓力

Laravel PHP-FPM 會發生：

worker 被長時間占用 → thread pool 被耗盡 → 502 / 504 cascade failure

這種問題的特徵是：

• 平常完全正常
• 一旦出問題就是系統級崩潰

---

三、重構目標

這次重構的核心目標不是「加速」，而是：

將不可控的外部依賴從 request lifecycle 中移除

具體目標如下：

• API 回應時間 < 50ms
• 外部 API 延遲不影響使用者體驗
• 系統具備削峰能力（burst traffic handling）
• 支援失敗重試與最終一致性

---

四、新架構：事件驅動 + Queue 解耦

重構後的流程如下：

使用者註冊
  → 寫入 User / Redemption（pending）
  → dispatch Queue Job
  → 立即回傳前端

Queue Worker
  → 呼叫 MIRA API
  → 更新 Redemption 狀態

前端
  → polling / status query
  → 完成後顯示 QRCode

---

五、核心設計轉變

1. 從「同步結果」變成「狀態機」

系統從：

request → response（必須立即得到 QRCode）

轉為：

pending → processing → completed / failed

這代表一個重要轉變：

系統從即時一致性，轉向最終一致性（eventual consistency）

---

2. Controller 不再做任何外部 I/O

重構後 Controller 僅負責：

• DB 寫入
• 狀態初始化
• Queue dispatch

完全移除：

• HTTP external call
• long latency operation
• external dependency blocking

---

3. Queue 成為系統的「緩衝層」

Queue 的角色不只是 background job，而是：

absorbing burst traffic + isolating external instability

它讓系統具備：

• 削峰能力
• 重試能力
• 故障隔離能力

---

4. 前端改為狀態驅動（Polling）

由於結果變為非同步，前端轉為：

POST /register
  → 200 OK (pending)

GET /redemption/status
  → completed → render QRCode

UI 的本質從：

「拿結果」

變成：

「觀察狀態變化」

---

六、可靠性設計：三層防護機制

為了確保不重複發券與系統穩定性，架構引入三層保護：

---

1. DB 層：唯一性約束

user_id UNIQUE

確保一個使用者只會產生一筆 redemption。

---

2. 狀態鎖：Optimistic Lock

UPDATE ... WHERE status = 'pending'

避免多個 worker 同時處理同一筆任務，防止 race condition。

---

3. 外部 API：Idempotency Key

使用：

redemption_id → request_id

確保：

• retry 不會重複扣庫存
• timeout 不會造成重複發券

---

七、失敗模式的轉變

原本系統失敗模式：

MIRA 慢 → request 卡住 → PHP worker 滿 → 全站 502

---

新系統失敗模式：

MIRA 慢 → queue backlog → 使用者等待變長，但系統不崩潰

---

八、Queue 設計與系統治理

1. Retry 策略

• exponential backoff
• retry limit
• jitter 避免 thundering herd

---

2. Dead Letter Queue（DLQ）

避免無限失敗任務卡住系統。

---

3. Reconciliation Job

定期掃描：

WHERE status = 'processing'
AND updated_at < NOW() - INTERVAL 5 MINUTE

避免 worker crash 導致狀態卡死。

---

九、Polling 的定位

Polling 在這個架構中不是最佳解，而是：

最穩定的 baseline solution

它的角色是：

• 簡單
• 可控
• 不依賴長連線基礎設施

未來可進一步升級為：

• SSE（中階）
• WebSocket（高互動）

但本質取捨是：

push 是連線成本，polling 是請求成本

---

十、這次重構的本質

這次架構改造不是效能優化，而是系統設計哲學的轉換：

從「同步獲取結果」
→ 轉為「非同步狀態演進」

---

結論

當系統開始依賴外部 API 時，真正重要的不是速度，而是：

• 是否可以隔離
• 是否可以重試
• 是否可以削峰
• 是否不會拖垮核心服務

這次重構的核心成果是：

將一個脆弱的同步鏈路，改造成可容錯的事件驅動系統

Vibe Coding 之後：為什麼 AI 時代真正重要的是 SDD（Spec-Driven Development）

 

生成式 AI 的出現，徹底改變了軟體開發方式。

從 GitHub Copilot、Cursor、Gemini、Claude Code 到 OpenAI Codex，現在的工程師只需要輸入自然語言，就能在幾分鐘內產生大量程式碼。

於是近兩年開始流行一個詞：

Vibe Coding

簡單來說，就是想到什麼需求，就直接交給 AI 實作。

流程看起來非常簡單：

想法
 ↓
AI
 ↓
程式碼
 ↓
上線

這種方式讓開發效率大幅提升，也讓許多非工程背景的人第一次能夠獨立完成產品原型（MVP）。

但當專案開始成長、功能開始增加、團隊開始協作時，問題也逐漸浮現。

而且問題往往不在程式碼本身。

---

Vibe Coding 最大的問題不是程式碼品質

許多人認為 AI 開發最大的風險是：

• 程式碼品質不佳

• 重複程式碼過多

• 架構混亂

• AI 幻覺（Hallucination）

這些問題確實存在。

但我認為它們都只是結果。

真正的根本原因其實是：

AI 沒有商業邊界（Business Boundary）。

AI 可以理解需求文字。

但它不理解：

• 哪些功能現在需要做

• 哪些功能未來再做

• 哪些功能根本不需要做

例如你告訴 AI：

我要一個 CMS 系統。

AI 很可能開始建立：

• 使用者管理

• 權限管理

• 文章系統

• 分類系統

• 標籤系統

• SEO 系統

• API

• Dashboard

• Activity Log

最後產生數百個檔案。

但實際商業需求可能只是：

希望飯店官網首頁內容可以透過後台修改。

這時候問題不是 AI 寫錯程式。

而是 AI 做了太多不需要的事情。

結果變成：

真正需求：3 天

AI 實作範圍：3 週

這種現象其實就是：

商業需求錯位（Business Misalignment）

而這也是許多 AI 專案後期開始失控的原因。

---

為什麼傳統軟體開發需要規格書？

很多人認為規格書是傳統軟體開發留下來的包袱。

但規格書存在的真正目的從來不是為了寫給主管看。

而是為了建立邊界。

成熟的軟體開發流程通常長這樣：

需求分析
 ↓
規格定義
 ↓
系統設計
 ↓
開發實作
 ↓
Code Review
 ↓
測試驗證
 ↓
部署上線

這個流程的價值在於：

• 有明確需求範圍

• 有設計依據

• 有驗證標準

• 有維護文件

然而在 AI 時代，許多團隊逐漸變成：

想法
 ↓
AI
 ↓
上線

中間所有工程管理環節全部消失。

短期看起來很快。

長期卻容易造成：

• 技術債累積

• 功能重疊

• 文件缺失

• 團隊無法接手

• 維護成本上升

---

SDD 是什麼？

SDD（Spec-Driven Development）中文通常翻譯為：

規格驅動開發

它的核心概念非常簡單：

先定義規格，再讓 AI 實作。

流程變成：

需求
 ↓
Spec
 ↓
設計
 ↓
實作
 ↓
驗證

很多人看到這裡會問：

這不就是以前的規格書嗎？

其實不完全一樣。

---

傳統規格書與 SDD 的差異

過去的規格書主要是給人類閱讀。

而 SDD 的規格，則同時服務人類與 AI。

傳統規格書	SDD
人類閱讀	人類 + AI 閱讀
偏文件管理	偏執行驅動
更新成本高	可持續同步
容易過期	持續演化
開發參考	開發依據

如果用一句話來形容：

PRD 是給工程師看的，而 Spec 是給 AI 執行的。

這也是 AI 時代最大的改變。

規格不再只是文件。

而是直接驅動開發。

---

OpenSpec：AI 與人類之間的契約層

目前常見的 SDD 工具有：

• Spec Kit

• OpenSpec

• PRD First Workflow

• AI Contract First

其中我認為最容易上手的是 OpenSpec。

很多人以為 OpenSpec 是文件工具。

其實更精確地說：

OpenSpec 是 AI 與人類之間的契約層（Contract Layer）。

在傳統開發中：

Product Owner
      ↓
工程師
      ↓
程式碼

而在 AI 開發中：

Product Owner
      ↓
Spec
      ↓
AI
      ↓
程式碼

Spec 成為了人與 AI 溝通的介面。

因此 OpenSpec 的真正價值不是產生文件。

而是幫 AI 建立需求邊界。

---

OpenSpec 的基本流程

OpenSpec 的工作流程非常接近真實軟體開發。

1. Explore

探索需求與問題。

/opsx-explore

例如：

/opsx-explore 認證系統越來越複雜，想重構

AI 先協助分析問題，而不是直接修改程式。

---

2. Propose

建立提案。

/opsx-propose add-user-auth

產生：

changes/
└── add-user-auth/
    ├── proposal.md
    ├── design.md
    └── tasks.md

此時需求被正式定義。

---

3. Apply

開始實作。

/opsx-apply

AI 根據規格逐步完成工作。

而不是自由發揮。

---

4. Verify

驗證結果。

/opsx-verify

確認：

• 是否符合需求

• 是否存在風險

• 是否遺漏規格

---

5. Archive

完成後歸檔。

/opsx-archive

同步更新規格與專案知識。

---

AI 的角色正在改變

這也是我認為 SDD 最重要的一點。

過去大家把 AI 當成：

Code Generator

需求進去。

程式碼出來。

但這種模式很容易造成失控。

未來 AI 更適合扮演：

Spec Executor

規格進去。

程式碼出來。

看似只有一個字的差異。

但本質完全不同。

因為：

Code Generator
→ AI 自己決定怎麼做

Spec Executor
→ AI 根據規格執行

而這正是 SDD 的核心價值。

---

SDD 不只提升 AI 品質，也提升團隊協作能力

很多人認為 SDD 只是為了提升 AI 生成品質。

其實更大的價值在團隊協作。

當每個功能都有：

proposal
design
tasks
archive

半年後接手專案的人可以清楚知道：

• 為什麼要做這個功能

• 當初的設計理由

• 修改過哪些規格

• 哪些方案被否決

而不是只能透過：

git blame
git log

猜測歷史決策。

這對團隊維護與知識傳承非常重要。

---

不只後端，前端更需要需求邊界

很多人以為這種問題只存在於後端。

其實前端更常發生。

例如：

需求：

建立一個產品介紹頁。

Vibe Coding：

建立 Design System
建立 CMS
建立 Dashboard
建立 API Layer
建立 Auth
建立 i18n

結果：

200 個檔案
只用到 3 個元件

而真正需求可能只是：

一個 Landing Page

這種過度設計在 React、Next.js、Vue、Astro 生態系中非常常見。

因此需求邊界其實是所有技術棧共同面對的問題。

---

未來工程師最重要的能力可能不是寫程式

AI 正在快速降低程式碼生產成本。

未來工程師的價值，可能不再是：

寫更多程式

而是：

定義需求
+
建立規格
+
架構設計
+
AI 協作

程式碼本身會越來越容易產生。

但商業邏輯、領域知識與系統邊界仍然需要人類決策。

因此未來的工程師角色可能變成：

Junior
→ 撰寫程式

AI
→ 執行規格

Senior
→ 定義規格與架構

---

結語

Vibe Coding 並沒有錯。

它讓更多人能夠快速將想法變成產品。

但當專案規模開始成長時，

真正重要的已經不是：

如何讓 AI 寫更多程式。

而是：

如何讓 AI 在正確的邊界內寫程式。

這也是 SDD（Spec-Driven Development）存在的價值。

AI 不缺寫程式能力。

缺的是需求邊界。

而未來工程師最重要的能力，也許不再是程式碼產生者，而是規格定義者。

VS Code AI 已進入 Agent 時代：豆包、MiMo 與現代 AI Coding 工具演進解析

 

前言

近年 VS Code 的 AI 開發工具快速演進，已從早期的「程式碼補全工具」逐步轉變為能夠理解整個專案並執行任務的 Agent 系統。

傳統 AI 工具僅能提供單段程式碼建議，但新一代工具已具備：

• 專案檔案搜尋能力

• 多檔案修改能力

• 自動規劃與任務拆解能力

• Terminal 指令執行能力

此類能力使 AI 不再只是輔助工具，而逐漸成為開發流程中的「虛擬工程成員」。

---

一、VS Code AI 工具的兩種世代

1. Chat 型 AI（第一代）

代表工具：

• GitHub Copilot Chat（早期模式）

• 基礎 LLM 外掛

• 部分 MiMo VS Code Extension

特徵如下：

• 以對話方式提供程式碼建議

• 無法直接操作專案檔案

• 無法理解整體架構

• 無法執行任務流程

此類工具本質仍屬於：

程式碼輔助生成工具（Code Assistant）

---

2. Agent 型 AI（第二代）

代表工具：

• 豆包 MarsCode

• Cline

• Claude Code

• Codex CLI

• Roo Code（已停止原 VS Code 擴充套件維護，轉向新產品 Roomote；社群多數使用其開源分支 Cline 延續使用）

特徵如下：

• 可掃描整個專案

• 支援跨檔案修改

• 可執行 Terminal 指令

• 具備任務拆解能力

• 可進行自動化工作流程

此類工具本質為：

自動化程式開發代理（AI Software Engineer）

---

二、豆包 MarsCode 的實際能力定位

以 VS Code 中的豆包（MarsCode）為例，其能力已超越傳統 Chat 型 AI，接近 Agent 架構。

主要能力包含：

1. 專案索引與檔案搜尋

可分析整個 Workspace，建立專案結構理解。

2. 程式碼理解與推理

可根據上下文理解函式呼叫與依賴關係。

3. 多檔案修改能力

可同步修改 Controller、Service、Model 等多層架構。

4. 任務執行能力（部分情境）

可輔助執行測試或 CLI 指令。

---

三、MiMo VS Code 外掛的定位

MiMo 在 VS Code 中的整合方式屬於「Chat + IDE 插件型態」。

主要功能包含：

• 側邊欄對話介面

• API Key 設定整合

• 程式碼問答與生成

• 基礎 Debug 支援

但其能力仍主要集中於：

單點程式碼輔助，而非完整任務執行

相較於 Agent 型工具，其差異在於：

• 無完整任務規劃能力

• 無跨檔案自動修改流程

• 無持續性專案記憶機制（依實作而定）

---

四、Agent 型工具與 Chat 型工具差異比較

能力	Chat 型 AI	Agent 型 AI
程式碼生成	✔	✔
理解單檔內容	✔	✔
專案結構理解	✘	✔
多檔案修改	✘	✔
Terminal 執行	✘	✔
任務拆解	✘	✔
自動完成工作流程	✘	✔

---

五、實務應用差異（以 Laravel 專案為例）

以新增 Filament Resource 並整合多語系 SEO 為例：

Chat 型 AI 行為：

• 提供單一 Resource 範例

• 提供 SEO 欄位設計建議

• 開發者需自行整合至專案

---

Agent 型 AI 行為：

• 掃描既有 Resource 結構

• 分析專案架構（Service / Model / Action）

• 自動生成 Migration

• 自動建立 Resource

• 更新 Validation 與 Translation

• 檢查一致性

---

六、AI 開發工具的核心轉變：從模型到上下文

現代 AI Coding 工具的關鍵不再是模型本身，而是：

Context Engineering（上下文工程）

核心問題轉變為：

• AI 是否理解專案架構

• 是否具備長期記憶能力

• 是否能跨檔案維持一致性

• 是否能依規範生成程式碼

因此工具競爭焦點已從模型能力轉向：

專案理解能力與工作流整合能力

---

七、開發工具選擇趨勢

目前主流工具大致可分為三類：

1. Copilot 類（補全型）

• 適合輕量開發

• 以提示與補全為主

2. IDE Agent 類（半自動）

• Roo Code（社群分支使用為主）

• Cline

• 豆包 MarsCode

適合日常開發與中型專案

3. CLI Agent 類（全自動）

• Claude Code

• Codex CLI

• MiMo Code（新興）

適合大型重構與自動化任務

---

八、結論

VS Code AI 工具已進入明確的 Agent 化階段。

豆包、Cline 等工具已不再只是程式碼輔助工具，而是能夠實際參與專案開發流程的自動化代理。

MiMo VS Code 外掛則仍屬於過渡型產品，其真正值得關注的方向在於 Agent 化的 MiMo Code 生態。

未來 AI Coding 的競爭重點將不再是模型能力，而是：

AI 是否能持續理解並操作完整開發專案。

AI 時代工程師面試攻略：資深工程師如何駕馭 AI，而不是被 AI 取代

 近兩年，幾乎每一場技術面試都會被問到這個問題：

「你平常怎麼使用 AI 開發？」

很多工程師的回答還停留在：「我每天用 Cursor」、「70% 程式碼是 AI 寫的」、「我 Prompt 寫得很好」。這些答案現在已經毫無鑑別度，因為大家都在用 AI。

技術主管真正想聽的，不是你用了哪些工具，而是你如何駕馭 AI，以及當 AI 出錯時，你是否有能力發現並守住系統底線。

以下內容全部來自我實際開發 多租戶 SaaS、租貸/金融流程、狀態機與金流系統，以及 legacy 重構、高壓 deadline 專案的真實經驗。

一、AI 在複雜系統中有明確的天花板

在簡單 CRUD 專案中，AI 看起來幾乎無所不能。 但在真正的 Production 系統（尤其是 SaaS + Multi-tenant + Financial Domain）中，它會明顯失效：

1. Multi-tenant 邊界問題（AI 最常犯錯）

• Background job 沒有帶 tenant context
• Cache key 未做 tenant 隔離
• ORM Global Scope 被 bypass
• Eager Loading 導致跨租戶資料外洩

這不是語法問題，而是系統邊界設計問題。

2. 金流 / 租貸狀態機複雜度 典型租貸流程：

text

申請 → 審核 → 撥款 → 還款 → 違約 → 追償

AI 常見問題：

• State transition 缺少 invariant 檢查
• Retry 沒有 idempotency key
• 缺少 compensation / rollback 流程
• Event ordering 無法保證

AI 寫出來的東西「看起來合理」，但放到 Production 會出大事。

3. 系統一致性與分散式問題

• Eventual consistency 的 race condition
• Queue 重試導致 double execution
• Transaction boundary 不明確
• Partial failure 的恢復策略缺失

這些都是 architecture 層級 的問題，而非單純 coding。

二、我的核心定位：AI 是能力很強的 Junior Engineer

我把 AI 明確定位為「能力很強，但缺乏 domain context 的 Junior Engineer」。 因此我的開發方式不是「讓 AI 寫 code」，而是我先設好約束，AI 在約束內全力加速。

三、實務開發流程（面試時可直接分享）

Step 1：人類先定義 Domain Boundary（最重要） 獨立完成：

• Tenant isolation strategy
• Domain model（Loan、Repayment、Ledger、Risk）
• State machine 與不可逆轉規則
• Consistency boundary（Transaction vs Event）

這一步 AI 完全不參與。

Step 2：設計系統 Invariant（防 AI 犯錯的關鍵） 明確定義系統安全規則，例如：

• 同一筆 loan 不可重複撥款
• Tenant 資料不可跨 query 污染
• Ledger 必須 double-entry 平衡
• 所有 event 必須 idempotent

Step 3：AI 加速 Implementation 讓 AI 負責：

• CRUD API
• Service layer boilerplate
• Migration / Schema
• Validation / DTO
• Unit Test 初稿
• 重構建議

實際效果：開發效率提升約 2～3 倍。

Step 4：人工嚴格 Review（Architecture Review） 重點檢查：

• Tenant boundary 是否被破壞
• State machine 是否 drift
• Idempotency / Compensation 是否完整
• Failure scenario 是否涵蓋
• Async job 是否安全

Step 5：Production 驗證 Integration Test、Sandbox Replay、Shadow Traffic、Feature Flag 逐步 rollout（AI 幾乎不參與）。

四、面試推薦回答（建議直接背或微調）

當面試官問：「你平常怎麼使用 AI 開發？」可以這樣回答：

「我把 AI 視為 production development 的加速工具，但不是 system design 的決策者。 在開發多租戶 SaaS 或租貸金融系統時，我會先自己定義 domain model、tenant isolation 邊界、state machine 與一致性規則，這些是系統正確性的核心。 AI 則專注在 implementation layer，例如 CRUD、API skeleton、migration、validation 與 unit test，能讓效率提升大約 2～3 倍。 但 multi-tenant isolation、金流一致性、狀態機轉換與 retry/idempotency 等關鍵部分，我會全程主導設計與 review，因為這些錯誤在 production 是不可接受的。 AI 解決的是寫程式的效率，而工程師解決的是系統在 production 的正確性與風險控制。」

五、主管真正想評估什麼

1. 你是否做過真正的複雜系統（multi-tenant + finance + state machine）
2. 你是否有 System Thinking，而非僅限 function thinking
3. 你是否敢為 Production 結果負責

六、結論：一句話總結

可以寫 code ≠ 工程師 可以用 AI ≠ 資深工程師 能定義 AI 不該碰的邊界、掌控複雜 domain 風險、並對 Production 結果負責 = 真正的工程能力

AI 時代，程式碼產出速度已經被快速拉平。 未來企業真正需要的，是能駕馭 AI、守住系統底線、並為長期穩定負責的資深工程師。

這篇文章不僅是面試攻略，更是我在多租戶 SaaS 與金融系統實戰中的心得分享。希望對正在準備面試、或正在導入 AI 開發流程的工程師有幫助。

如果你有類似經驗，歡迎留言交流！ 也歡迎轉發給正在準備技術面試的朋友。

AI 時代的資訊檢索演進：從 SEO Ranking 到 LLM Retrieval / GEO

以下內容來自實際內容策略、系統設計與 AI 工具應用經驗，並非理想化理論。

AI 放大的是資訊獲取速度，但內容的本質仍是「被理解與信任」。

從系統設計角度來看，SEO 與 GEO 本質上都是資訊檢索（Information Retrieval）問題，只是優化目標從「ranking function」轉移到「LLM context selection / grounding」。

從工程角度來看，這是一個 retrieval pipeline 的演進問題：從 keyword-based retrieval → semantic retrieval → LLM-based grounded generation。

這就是 SEO → GEO（Generative Engine Optimization） 的本質轉變。

一、AI 時代下 SEO 的本質沒有消失，只是被重新定義

傳統 SEO 常見的失效做法：

• Keyword stuffing
• 內容農場式 SEO 文章
• 資訊密度低但格式正確的薄內容

這些內容在 AI 時代極易被跳過，因為 AI 的目標是資訊壓縮與合成，而非單純列出連結。

新 GEO 的核心三要素：

1. 可理解性（Understandability） AI 是否能快速、準確抽取語意，而非只抓關鍵字。
2. 可驗證性（Verifiability） 是否有明確來源、數據、引用與更新日期。
3. 可信任性（Trust） 是否符合 E-E-A-T（Experience、Expertise、Authoritativeness、Trustworthiness）。

二、SEO → GEO 的工程視角轉變

層級	SEO（傳統）	GEO（生成式）
系統目標	Index Ranking System	LLM Retrieval Selection
資訊單位	Page-level	Chunk / Entity-level
優化目標	Page-level Optimization	Chunk / Entity-level Optimization
成功指標	Search Engine Ranking	Grounded Response Inclusion

GEO 真正優化的是 Retrieval + LLM Grounding：

• SEO → 優化 Indexing
• GEO → 優化 Retrieval（被找到）與 Summarization / Grounding（被正確合成）

三、實務中的 GEO 做法（非理想化版）

1. 內容結構化 使用清晰標題階層、表格、bullet points、Inverted Pyramid（結論前置），並加入 Schema Markup，讓 AI 更容易解析。

2. 強化 E-E-A-T 信號

• 展示作者真實經驗與背景
• 提供可驗證數據與第一手案例
• 定期更新並標註日期
• 獲得外部權威引用

3. 現實取捨 不是所有頁面都要全力 GEO，優先處理高價值、常被查詢的 Pillar Content。在 deadline 壓力下，先確保核心內容具強結構與信任信號。

結論

SEO 沒有被淘汰，而是從「排名優化」進化成「LLM 檢索與引用優化」。

本質上，GEO 的核心不是內容優化，而是降低 AI 在 retrieval 與 grounding 時的不確定性。

在 AI 時代，贏家不是產出最多內容的人，而是能讓 AI 願意正確引用且放心 grounding 的人。

真正的核心競爭力，仍然是定義清晰、可驗證且值得信任的知識邊界。

AI 時代的軟體工程實務：資深工程師如何在不確定性中控制系統風險

 以下內容來自實際 production 環境經驗（包含 legacy 系統維護、重構專案與 deadline 壓力場景），並非理想化流程。

近年媒體不斷報導「AI 即將取代工程師」「會寫 Prompt 就能開發系統」，讓許多人嚴重誤解 AI 在軟體工程中的角色。

AI 放大的是產出速度，但工程本質是約束設計與風險控制。

在 AI 時代，軟體工程的核心不再是寫程式，而是定義與維持系統的約束邊界（Constraints）。 這包括業務規則、技術限制、風險邊界與長期可維護性。AI 能快速產出程式，但無法替你建立這些約束——這正是資深工程師真正的價值所在。

一、AI 時代的能力分層：產出能力 ≠ 工程能力

AI 讓「寫 code」的門檻大幅降低，卻也製造了一個危險的錯覺——好像只要會用 AI，就能成為工程師。

但在生產環境中，AI 只強化了產出速度，並沒有強化以下核心工程能力：

• 系統設計能力（System Design）
• 風險判斷與邊界控制（Risk & Boundary）
• 資料一致性與正確性把關
• 長期維護與技術債管理

初級使用者與資深工程師的真正差異：

初級使用者：

• 把 AI 當成解題工具
• 直接接受 AI 輸出結果
• 事後用測試驗證

資深工程師：

• 先定義系統的約束邊界與風險
• 再讓 AI 在嚴格限制內加速產出
• 所有輸出都經過架構一致性與業務正確性檢查

核心結論： 會用 AI → 可以寫 code 會控制 AI → 才是工程師 能定義與維持 AI 的約束邊界 → 才是資深工程師

現在真正的競爭差異，不是誰寫 code 比較快，而是誰能確保 AI 產出的東西在 production 是安全的。

二、實務方法：如何在約束邊界下安全使用 AI

理解能力分層之後，以下是具體的落地做法。這些方法不是理想流程，而是考慮 deadline、legacy code、團隊成熟度差異後的 80/20 打法。

1. 需求拆解：知道什麼時候該偷懶

現實中不可能每次都完整拆解。重點是依風險分級建立約束：

• 高風險部分（金流、權限、資料一致性、審計）必須人類親自定義邊界與風險。
• 一般 CRUD：讓 AI 協助整理規格 + 產出反向測試案例。
• Legacy 系統：用 AI 先分析呼叫鏈與資料流，再決定重構範圍。

關鍵在於知道什麼時候絕對不能妥協，這正是約束設計的起點。

2. 系統設計：先有人類框架，再讓 AI 滲透

設計永遠不能跳過，而是先由人類定義核心約束：

• 核心模組：寫簡短 ADR 或文字架構，明確定義邊界與限制。
• 次要功能或緊急修正：把既有架構風格與約束塞進 prompt，讓 AI 產生候選方案後人工調整。
• Deadline 極限：先做「夠用設計」，但一定要排後續技術債。

AI 在此階段只能當設計助手。你必須持續餵上下文，避免 context drift。

3. AI 的日常定位：能力強但極度不可預測的 Junior

AI 是滲透在整個開發循環的加速器，而非單一步驟。它的最大問題是不可預測性：

• Hallucination（幻覺）
• Silent Failure（隱藏錯誤）
• Overconfident Output（過度自信）

適合大量使用 AI 的場景（在明確約束下）： CRUD、boilerplate、DTO、validation、migration、單元測試生成、複雜 SQL、重構建議、legacy 轉現代骨架。

必須人類主導的場景（強約束）： 金流、權限模型、多租戶隔離、並發控制、高業務風險或法規邏輯。

4. 工程審查：把 AI 產出當「可能帶毒的草稿」

這一步最能體現維護約束邊界的能力：

• 檢查是否違反先前定義的架構約束
• 特別注意 silent failure 與 edge case
• 要求 AI 先自我列出「這段 code 可能出現的 5 個潛在問題」

定期進行「AI 技術債健診」，避免隱藏風險突破邊界。

5. 測試與驗證：壓力越大越不能省

AI 讓寫 code 變快，也讓 bug 出現更快。因此必須強化驗證約束：

• 核心路徑必須有 integration test
• 高風險功能強制 sandbox + shadow testing + feature flag
• AI 適合大量產生測試案例，但「哪些測試真正重要」永遠由人類判斷

結論

AI 放大的是產出速度，但工程本質是約束設計與風險控制。

在 AI 時代，軟體工程的核心不再是寫程式，而是定義與維持系統的約束邊界（Constraints）。

媒體看到的是 AI 寫 code 的速度，我們在 production 看到的是 AI 放大風險的速度。真正的資深工程師，不是 Prompt 寫得最好的人，而是最懂得在 deadline、legacy、團隊現實中，設計與守護系統約束邊界的人。

給團隊的務實建議：

1. 建立輕量《AI 使用守則》，明確高風險場景的約束邊界。
2. 區分探索模式（可放寬）與生產模式（必須嚴格）。
3. 每季進行 AI 技術債回顧。
4. 培養「對 AI 保持健康懷疑」的團隊文化。

在 AI 時代，資深工程師的價值不但沒有降低，反而更加重要。因為能駕馭 AI 並定義其邊界的人，和被 AI 帶著走的人，做出來的系統品質天差地遠。

從資深全端工程師轉型 Harness Engineering：完整教學指南

在台灣工程師薪資三層結構中，大多數全端工程師仍深陷 Commodity 層——靠 CRUD、接單與工時換取薪水，面對案源減少與薪資停滯的壓力。此時，Harness Engineering 提供了一條清晰且務實的升層路徑：把你從「寫程式的人」，轉變為「設計 AI 工作系統的人」，穩步從 Commodity 層走向 Product 層，乃至 Leverage 層。

什麼是 Harness Engineering？

Harness Engineering 是一種 AI-native 的工程方法論。它專注設計與管理 AI Agent 的執行環境，讓 AI 不再只是偶爾使用的聊天工具，而是能被結構化控制的系統性生產力單位。

它的核心不在 Prompt，而在於打造一個讓 AI 穩定運作、可觀測、可自動修正的工作系統——這就是 Harness。 工程師的角色也因此完成本質轉變：從 Execution（執行者）進化為 System Design（系統設計者）。

這正是全端工程師最自然的轉型優勢。你過去寫 API、管狀態、規劃架構、處理錯誤的經驗，幾乎可以直接對應到 AI Agent 的系統設計。

核心觀念轉移：從「實作」到「設計規則」

傳統全端工程師每天在寫 API、管狀態、修 Bug。這些能力在 AI 時代並沒有消失，而是被重新抽象到更高層次：

傳統能力	Harness 對應能力	價值層級提升
寫 API	Tool Schema 與能力接口設計	Commodity → Product
狀態管理	Agent Memory 與狀態機	Product → Leverage
系統設計 / CI/CD	Workflow 控制與 Evaluation Loop	Leverage 核心
Logging / Monitoring	Agent Observability	決定系統成敗

關鍵轉變在於：工程不再是「我來把功能做出來」，而是「我來設計 AI 如何可靠地完成工作」。

Harness 系統的三大核心模組

一個成熟的 Harness，通常建立在三個相互協作的層級上：

1. Memory（狀態層） 讓 AI 擁有持續性與長期上下文能力，包括短期 Context、向量資料庫長期記憶，以及任務狀態機。 重點不在記住多少，而在如何有效使用記憶。
2. Tools（能力層） 讓 AI 能安全地與真實世界互動——API 调用、程式執行、資料庫查詢等。 關鍵是把外部能力轉化為精心設計的接口，避免誤用。
3. Workflow（控制層） 定義 AI 的思考與行動規則，常見模式包含 ReAct、Plan-and-Execute、Reflection 與 Multi-Agent 協作。 這裡決定了系統的智商與穩定度。

Harness Engineer 的四項核心能力

真正區分高低階的，不是會不會用 LangGraph，而是能否設計好以下四件事：

• 狀態設計：如何避免上下文污染？如何從中斷中恢復？
• 工具抽象：如何讓 API 成為 AI 可安全使用的能力？
• 流程控制：何時該反思、何時該修正？如何防止錯誤擴散？
• 可觀測性：你必須清楚看見 AI 每一步在想什麼、為什麼這麼決定。

沒有可觀測性，就沒有 Harness。這句話幾乎是這個方法論的底線。

三階段轉型路徑（8–12 週可見成效）

Phase 1：Agent Awareness 先理解 AI 的行為模式，熟悉 ReAct、Plan、Reflection 等基本模式。每天用 Cursor + Claude 完成工作，並拆解失敗點。

Phase 2：System Construction 用 LangGraph 搭建完整 Harness，包含 Memory、Tool、Evaluator Loop。這階段你會開始感受到「機制大於提示」的威力。

Phase 3：Multi-Agent System Design 進入 Planner + Executor + Critic 的多 Agent 架構，處理更複雜、長期性的任務。這時你已真正站在 Leverage 層。

核心心法：決定你能走多遠

1. 機制優於提示：AI 出錯時，別急著改 Prompt，而是問：「我要設計什麼機制，讓這個錯誤永遠不再發生？」
2. 系統要薄：越簡潔、可控、可替換的 Harness，越可靠。過度工程化往往適得其反。
3. Human-in-the-Loop：人類永遠要在關鍵決策點上，逐步把自動化程度拉高。
4. 可觀測性至上：看不見的系統，就不是系統，只是黑盒。

從個人轉型到公司求生

對個人而言，Harness 可直接應用在 Code Review Agent、技術文章生成系統、個人第二大腦等實戰專案。

對接案公司來說，這更是翻身武器。傳統「賣時間」的 Commodity 模式已失效。Harness 能幫助你：

• 內部降本 50% 以上（1–2 人支撐原本 4 人工作）
• 快速產品化：打包「一鍵後台 Agent」「電商資料清洗 Agent」「SEO 內容生成 Agent」等模板對外販售
• 服務升級：以「自有 Harness 縮短 60% 開發時間」作為差異化賣點，重新吸引願意付費的中小企業客戶

起步建議：先花 7 天建立公司內部最小可用 Harness（Company-Survival-Harness），跑通真實任務後再對外推廣。

結語：AI 時代的結構性升層

Harness Engineering 的本質，是把 AI 從「工具」變成「可控的生產系統」。

它完美呼應了台灣工程師的薪資三層結構： 把 Commodity 層的線性工作交給 AI， 在 Product 層實現 ROI 導向的交付， 在 Leverage 層打造可重複、具乘數效應的系統。

AI 並未壓縮工程師的整體價值，而是壓縮了線性、可被商品化工作的空間。真正稀缺的，永遠是系統設計、流程控制與可觀測性設計的能力。

3 個月內，如果你能打造出屬於自己的 Harness 模板，就能在 AI 時代握有更強的議價力與收入主動權。

現在，就從你的第一個 LangGraph 專案開始。 把 AI 真正變成可信任的工作系統。

台灣低薪工程師的惡性循環：AI 如何加速「乖乖接單」文化下的困境

台灣工程師薪資分層：AI 時代的結構性重構

台灣科技業低薪現象早已不是新聞，但在 AI 時代卻變得更加清晰且刺眼。許多工程師月薪卡在 5-7 萬甚至更低，工作量與壓力未減，薪資成長卻近乎停滯。這不是單純的「個人不夠努力」，而是產業結構長期定價的結果。AI 並非造成低薪的元兇，而是加速了薪資市場的三層分化。

三層市場結構與判定標準

台灣工程師的薪資分布，本質上是一種三層市場結構。三個層級的差異，不在職稱或公司，而在於「價值是否與輸出綁定」以及價值計算單位的不同。

以下是簡單的判定表：

層級	價值來源	薪資決定因素	典型特徵
Commodity	工時 / 任務完成	市場供給價格	CRUD、外包、接單型、高度標準化
Product	產品成果 / ROI	業務成長貢獻	產品設計、系統規劃、用戶價值交付
Leverage	系統影響力 / multiplier	決策與槓桿效應	AI Infra、架構師、Domain Expert、跨域整合

判定方式：

• 如果你的工作主要被衡量「完成了多少 ticket / 工時」，且容易被其他人或工具替換，你多半處在 Commodity 層。
• 如果工作成果直接影響產品指標（留存、營收、效率提升），則進入 Product 層。
• 如果你的決策或設計能放大整個系統的效能、降低大規模成本，或開創新可能性，即屬 Leverage 層。

一個人可以跨層（例如同時處理 Commodity 任務但主導 Leverage 專案），但長期薪資主要由你主要價值貢獻的層級決定。

AI 改變價值密度分布

AI 不是單純的「壓低薪資工具」，而是改變價值密度分布的結構性力量。

• 過去：1 位工程師 ≈ 1 單位線性產出。
• 現在：1 位工程師 + AI ≈ N 倍 Commodity 產出（boilerplate、測試、簡單功能）。

AI 並未壓縮工程師整體價值，而是壓縮「線性價值工作」的存在空間。它讓可標準化任務的邊際成本大幅下降，導致 Commodity 層需求減少、競爭加劇；同時，Product 層的迭代速度加快，Leverage 層的乘數效應則被大幅放大。高階人才搭配 AI 後，一個人的影響範圍能從原本的幾倍擴大到數十倍。

這解釋了為何我們同時看到「初階職缺遇缺不補」與「AI 相關高階人才薪資持續上漲」的並存現象。

結構決定上限，行為決定位置

產業結構（代工型態、內需導向、供給過剩）決定了整體價格上限，尤其是 Commodity 層。工程師的風險規避行為（接受低薪、不敢跳槽），主要是維持了這個結構，而非根本造成它。市場上仍有外商進入、技術變遷等力量，但對高度商品化的工作而言，這些力量目前還不足以徹底改變定價邏輯。

不是「乖乖文化」，而是「風險結構問題」

低流動性的真正原因在於現實的風險結構：

• 高房貸與生活成本
• 跳槽失敗的非線性損失（家庭、年資、保險）
• 缺乏完善的安全網
• 薪資資訊不透明

這是理性選擇，而非性格缺陷。它讓 Commodity 層的供給持續充沛，進一步穩固了該層的定價區間。

如何在結構中升層？

關鍵不在努力程度，而在於你目前的工作是否仍具有不可商品化的價值。

具體路徑：

• 把 AI 當杠杆：用它快速處理 Commodity 任務，釋放時間投資 Product/Leverage 能力。
• 累積可量化的 Impact（ROI、成本節省、產品指標），而非僅描述工時。
• 提升流動性與透明度：定期評估市場、參與社群。
• 朝 Leverage 轉型：深化 AI 整合、系統架構、領域知識，或將專業變現（課程、SaaS、顧問）。

結語：結構定價的核心命題

台灣工程師的薪資分化，不是個人努力差異，而是產業結構對「可替代性工作」的重新定價結果。

AI 的出現沒有改變這個結構，只是加速了價值分布的極化：

• 可標準化工作被快速商品化
• 產品導向工作與 ROI 緊密綁定
• 槓桿型能力持續放大影響力

因此，薪資差距的本質不再是「薪水談判問題」，而是你所處價值層級的問題。

當你清楚自己在哪一層，並有意識地往上移動，AI 就會從威脅轉為強大的杠杆。市場不會主動拯救任何人，但結構性的理解，能幫助我們做出更精準的選擇。

你目前的工作，主要貢獻在哪一層？又準備如何移動？

🚀 AI 在軟體開發中的真實角色：把「寫 code 的問題」變成「審 code 的問題」

近年媒體不斷高喊「AI 即將取代程式員」，彷彿只要會用 Claude 或 Cursor，就能大幅提升生產力甚至完全取代人類開發者。但作為第一線開發者，我們必須保有清醒認知：AI 並沒有讓軟體工程變簡單，它只是把「寫 code 的問題」變成「審 code 的問題」。

AI 是強大的生產力工具，但遠非全能。它最擅長產生「看起來正確」的程式碼，卻在隱藏錯誤、系統性思考與長期維護上暴露出明顯局限。本文從 AI 本質限制出發，分析錯誤根源，最後說明頂尖開發者如何重新定位自己，打造有效的 AI 協作系統。

I. AI 的本質限制（Why it fails）

AI 在實際開發中存在幾個結構性弱點，這些限制不會因為模型參數增加而輕易消失：

1. 嚴重的上下文與記憶限制 AI 難以完整掌握大型專案的檔案依賴、歷史決策與團隊慣例，極易產生幻覺或前後矛盾。
2. 邊界條件與複雜邏輯處理薄弱 在並發、複雜業務規則、效能優化與邊緣案例上，錯誤率顯著上升。
3. 缺乏真正的商業理解與判斷力 AI 無法真正理解使用者痛點、公司戰略、長期維護成本與業務影響。
4. 大型系統整合與架構能力不足 跨模組、跨系統的整合仍是 AI 的明顯弱點。
5. 沒有責任感與最終把關能力 AI 不會為結果負責，最終的穩定性、安全性與可維護性，永遠落在開發者身上。

這些限制意味著：AI 目前最適合處理 Commodity 層的線性任務，而在 Product 與 Leverage 層的系統性工作上，仍高度依賴人類。

II. 為什麼這些錯誤這麼常發生？（Root Causes）

這些錯誤並非偶然，而是由 AI 的運作機制所必然導致：

• 上下文窗口限制：即使是 2026 年的最新模型，處理超大型 codebase 時仍會遺漏關鍵資訊。
• 訓練資料偏誤：大多數訓練資料來自公開程式碼，對於特定產業、內部系統或最新實務的理解相對薄弱。
• 過度自信的回答風格：AI 傾向以確定語氣輸出，即便不確定也很少主動標註風險。
• 缺少真正責任感：AI 沒有後續維護壓力，因此不會主動考慮長期可維護性與技術債。

結果就是常見的程式碼錯誤類型：幻覺（Hallucination）、安全性漏洞、邊界條件缺失、效能問題、與專案不一致，以及隱形錯誤。

III. 工程師的重新定位：從執行者到系統審計師與 Harness 設計者

因此，問題的核心不在於 AI 能不能寫 code，而在於人類如何重新設計協作方式。

認清限制後，真正具競爭力的開發者不會與 AI 競爭「誰寫得快」，而是轉向更高價值的位置——系統審計師、架構把關者，以及 Harness Engineering 的設計者。我把 AI 視為「高效率但需要嚴格監督的資深工程師」，自己則負責最終把關與系統設計。

核心實戰框架：AI Engineering Workflow

以下是我在實務中長期驗證的 AI 協作系統，而非單純的個人 SOP：

1. Context Engineering：給予充足、結構化的上下文（專案背景、既有程式碼、業務規則、非功能需求）。
2. 分步生成與迭代：不一次要求完整實作，而是逐步拆解任務。
3. Cross-model Validation：將相同需求丟給 Claude、GPT-4o、Gemini、Grok 等不同模型，比較輸出差異，找出各自盲點。
4. 嚴格 Code Review + 測試：人工審核、撰寫單元測試與整合測試。
5. 逐步整合與持續觀測：在真實環境中驗證，並建立可觀測機制。
6. Harness 機制設計：對於重複性任務，逐步打造包含 Memory、Tools 與 Workflow 的 Harness，讓 AI 能在受控環境中穩定運作。

這套框架把 AI 的速度優勢與人類的判斷力結合，既能快速原型與實驗，也能確保最終交付的穩定性、可維護性與商業價值。

結論：AI 時代真正的競爭力

AI 大幅降低了產生程式碼的門檻，但「做出正確、穩定、有商業價值且可長期維護的軟體」的難度並沒有降低。它反而對工程師的審核能力、系統思維與工具駕馭能力提出了更高要求。

在 AI 時代，真正的競爭力不在於「產出能力」，而在於「驗證與控制能力」。能夠設計 AI 協作系統的人，才真正具備從 Commodity 層走向 Leverage 層的結構性優勢。

保持理性認知，建立嚴謹的 AI Engineering Workflow，並持續精進 Harness Engineering 能力，這才是開發者在這個時代最堅固的護城河。

馴服 AI Agent：在中大型專案中建立「永不幻覺」的開發協議

在 AI Agent 已全面進入 production workflow 的開發環境中（如 Antigravity、Cursor Agent mode），真正的瓶頸不再是生成能力，而是上下文污染與系統一致性。AI-native 開發的核心，不是提升 AI 能力，而是設計 AI 的認知邊界（cognitive boundaries）。當專案使用 Astro 5 + Vue 3 + Laravel 12 + Filament v3 這樣複雜的全端技術棧時，AI 極易因記憶漂移而虛構 API 格式、破壞商業邏輯或使用錯誤套件語法。

Prompt Engineering 的時代已經結束。解決方案是建立一套結構化的 AI System Design Stack，讓 AI 從「容易幻覺的助手」轉變為「遵守明確邊界的可靠執行官」。

AI System Design Stack：三層控制架構

1. Execution Boundary Layer（行為控制層）—— Agent Runtime Governance

這一層定義「AI 能知道什麼、不能做什麼」，是防幻覺的基礎。

建立 AI Execution Control Plane（原 .antigravity 升級版）：

text

.ai-control-plane/
├── core/                  # 技術邊界
│   └── TECH_STACK.md
├── contracts/             # 介面合約
│   └── API_CONTRACT.md
├── domain/                # 商業規則
│   └── BUSINESS_LOGIC.md
├── guardrails/            # 禁止與防護
│   └── FORBIDDEN_PATTERNS.md
└── scoring/               # 評分機制
    └── SCORING_SYSTEM.md

核心文件範例：

• TECH_STACK.md：嚴格鎖定版本與禁止語法
• BUSINESS_LOGIC.md：使用字典 + Mermaid 流程圖定義訂單狀態機、權限規則等

實戰指令模板：

• Reference Discovery：要求 AI 先閱讀所有規則文件並找出相似參考
• Plan First：強制先輸出執行計畫，確認後才產生程式碼

2. Efficiency Layer（效率控制層）—— AI Development Efficiency Model (AIDEM)

AIDEM 定義了如何在 Context、Contract、Execution、Model 四個層面控制 AI 系統，最大化輸入/輸出比（I/O Ratio）。

Layer	Purpose	核心機制	預估節省
Context	輸入控制	.ai-control-planeignore + 精準 Pinning	20-40%
Contract	規則控制	模組化 Markdown + 精煉指令	10-25%
Execution	行為控制	Plan First + Diff Mode + One-Shot	15-30%
Model	算力分配	模型路由 + Clear History	30-50%

綜合應用可降低 40%~70% Token 消耗，讓中大型專案的 AI 開發從「燒錢」變成「可控」。

3. Schema Layer（資料控制層）—— Contract-first Architecture

AI 系統最大問題不是邏輯錯誤，而是 schema ambiguity（結構不確定性）。

spatie/laravel-data 正是 Schema Layer 的實戰參考實現。它提供單一真理來源（SSOT），讓 Model → DTO → API → 前端 TypeScript 形成嚴格一致的合約鏈。

PHP

#[TypeScript]
class OrderData extends Data
{
    public function __construct(
        public string $order_no,
        public int $amount_cents,  // 分為單位
        // ...
    ) {}
}

Controller 簡化為一行，AI 只需閱讀一個檔案即可完全理解輸出結構。搭配 laravel-typescript-transformer，前後端型別自動同步，大幅壓縮幻覺空間。

這是 Schema-level Control 的具體落地：AI 需要的是確定性，而不是模型自由度。

從 Prompt-Driven 到 Boundary-Driven

在 AI-native 開發時代，系統的穩定性不再主要來自 code quality，而是來自schema consistency（資料一致性） 與 execution boundary design（執行邊界設計）。

• Execution Boundary Layer 解決行為一致性
• Schema Layer 解決資料一致性
• Efficiency Layer 確保可規模化

三層結合，構成真正可控、可觀測、可維護的 AI 開發系統。這也正是全端工程師從 Commodity 層 升級到 Leverage 層 的結構性路徑。

立即行動：

1. 建立 .ai-control-plane/ 並填入核心規則文件
2. 導入 spatie/laravel-data + TypeScript Transformer
3. 在最容易出錯的模組先建立 BUSINESS_LOGIC.md，並套用 AIDEM 流程

Prompt 時代已過，Boundary-Driven 時代才剛開始。當 AI 再次出現幻覺時，別急著在聊天視窗糾正它——去完善你的認知邊界設計。這才是生產級、規模化 AI 輔助開發的正確心法。

在 Google Antigravity 中大幅降低 Token 消耗的實戰指南

 在 Google Antigravity 中大幅降低 Token 消耗的實戰指南

—— Agent-First IDE 的上下文與成本優化技巧使用 Google Antigravity 這類 Agent-First IDE 時，Agent 會頻繁讀取專案上下文以維持邏輯連貫，因此 Token 消耗速度遠高於傳統 Chat 模式。一個不小心，複雜任務就可能燒掉數十萬 Token。本文整理出一套系統化的省 Token 策略，幫助你在 Astro + Vue 3 + Laravel 等全端專案中，既保持開發效率，又有效控制成本。

---

一、核心思維：精確的上下文控制（Context Control）Agent 不需要每次都看到整個專案。過大的上下文不僅貴，還容易造成記憶漂移和幻覺。1. 使用 .antigravityignore 精準排除無用檔案在專案根目錄建立 .antigravityignore 檔案，內容比 .gitignore 更嚴格：

ignore

# Antigravity 專用忽略清單
node_modules/
vendor/
dist/
build/
.git/
*.log
*.sqlite
*.png
*.jpg
*.jpeg
*.gif
*.webp
public/build/
storage/framework/cache/
storage/framework/sessions/

效果：避免 Agent 讀取大型依賴套件、編譯後檔案與圖片，大幅減少索引 Token。2. 精準選擇檔案（Targeted File Selection）

• 不要對整個專案提問
• 使用 Antigravity 的 @檔案路徑 或 Pin 功能，只選取當前任務相關檔案
  • 例如：同時 Pin app/Services/UserService.php + src/composables/useUser.ts + resources/views/filament/pages/user-settings.blade.php
• 任務結束後，立即清除對話歷史 或重置 Context，避免舊對話變成永久負擔

---

二、規則文件優化（Rule Compaction）規則文件雖然重要，但太長會每次都被讀取，造成嚴重 Token 浪費。最佳實踐：

1. 模組化拆分規則
   • LARAVEL_RULES.md（後端專用）
   • VUE_RULES.md（前端 Vue 專用）
   • ASTRO_RULES.md（Island 與 Client 指令專用）
   • FILAMENT_V3_RULES.md（Admin 面板專用）
   • 只在對應任務時才掛載相關規則
2. 精煉 Markdown 寫法
   • 減少敘述性段落，多使用結構化清單與表格
   • 使用粗體關鍵字突出重點
   • 每個規則控制在 1~2 行以內
   • 優先使用「禁止事項」與「強制做法」格式

---

三、流程優化：減少無效思考循環1. 強制「Plan & Approve」機制在重要任務的 Prompt 中加入：

「Before writing any code, first show me your execution plan in detail, including which files you will modify and why. Wait for my approval before proceeding.」

這一步能大幅減少 Agent 盲目嘗試所浪費的 Token，通常可省下 30%~50% 的無效消耗。2. 智慧模型切換策略

任務類型	推薦模型	理由
簡單修改、補註解、格式化	Gemini 1.5 Flash	速度快、價格極低
中等任務、單檔案調整	Gemini 1.5 Flash / Pro	平衡成本與能力
複雜重構、多檔案協作	Claude 3.5 Sonnet / Gemini 1.5 Pro	推理能力強
架構設計與審核	Claude 3.5 Sonnet	長上下文理解佳

---

四、減少幻覺糾正的 Token 浪費「跟 Agent 吵架修正錯誤」是最燒 Token 的行為之一。有效做法：

1. 提供精確片段
   直接貼上相關的 interface、function signature 或既有程式碼片段，讓 Agent 參考，而不是讓它自己掃描目錄。
2. 使用 One-Shot Prompt
   在提示詞中直接給一個「正確示範」的小範例：
   markdown

   正確範例（請嚴格遵循此風格）：
   ```ts
   export const useApi = <T>(endpoint: string) => { ... }

3. Reference Discovery 結合精準參考
   要求 Agent 先參考特定檔案，而不是整個目錄。

---

五、工具層面省錢技巧總表

技巧	說明	節省潛力
Clear History	每個功能完成後清空對話
Manual Indexing	關閉自動全專案索引，只手動觸發
.antigravityignore	排除無用大型檔案與目錄
模型切換	小任務用 Flash，大任務用 Pro/Sonnet
Local LLM	簡單補全使用 Ollama 本地模型
Pinned Files	只 Pin 當前任務相關的 3~5 個檔案

---

總結：最省 Token 的正確使用心法在 Antigravity 中，最有效的省錢行為是**「先思考，再提問」**。

• 每次提問前先整理好相關檔案
• 重要任務先要求 Agent 輸出 Plan
• 善用模組化規則與精準上下文
• 任務結束立即清理歷史

實測下來，妥善使用以上策略，通常能節省 40%~60% 的 Token 消耗，同時還能降低幻覺發生率，讓開發流程更順暢。

跨專案防幻覺指南：利用 Laravel-Data 打造 AI 時代的「高感度」全端架構

在前後端分離（Decoupled）的架構中，最燒 Token 的行為莫過於讓 AI Agent 在兩個獨立目錄間反覆橫跳、搜尋 API 欄位。透過 spatie/laravel-data，我們可以建立一個強大的「資訊地圖」，讓 AI Agent 讀取最少的檔案，精準寫出 100% 正確的代碼。

---

為什麼這是 AI 開發的最佳實踐？

傳統開發中，後端 API 資訊散落在 Controller、Resource 和 Model。對 AI 來說，這意味著要讀取數千個 Token 才能拼湊出一個 API 格式。

使用 Laravel-Data 後：

• 高壓縮比： 一個 200 Tokens 的 Data 類別，包含了驗證、DTO 與回應格式。

• 零幻覺： 強型別約束讓 Agent 沒有猜測空間。

• 跨專案解耦： 前端 Agent 只需「投影」後端的 Data 類別，無需理解後端實作細節。

---

第一階段：後端架構 —— 建立單一真理來源 (SSOT)

在 Laravel 12 中，我們廢棄傳統的 Resource，改用 Data 類別。

1. 安裝套件

Bash

composer require spatie/laravel-data

2. 定義資料合約 (Contract)

建立 app/Data/ProductData.php。這就是 AI 唯一需要閱讀的「合約」。

PHP

<?php

namespace App\Data;

use Spatie\LaravelData\Data;

class ProductData extends Data
{
    public function __construct(
        public int $id,
        public string $title,
        public int $price_cents, // 以分為單位，防止 AI 算錯浮點數
        public ?string $description,
        public bool $is_published,
        /** @var string[] */
        public array $tags,
    ) {}

    public static function fromModel($product): self
    {
        return new self(
            id: $product->id,
            title: $product->name,
            price_cents: $product->price,
            description: $product->desc,
            is_published: $product->active,
            tags: $product->tags->pluck('name')->toArray(),
        );
    }
}

---

第二階段：Antigravity 配置 —— 建立 AI 存取協議

要在前端目錄開發時不產生幻覺，我們必須在專案根目錄建立規則。

1. 建立 .antigravity/rules/API_RULES.md

Markdown

# API 溝通協議
1. **參考對象**：前端開發時，必須優先讀取後端目錄 `@backend/app/Data/` 下的對應 Data 類別。
2. **禁止自創欄位**：嚴禁根據猜測撰寫 Vue 組件中的變數名，所有欄位必須與 Data 類別屬性 100% 匹配。
3. **回應結構**：API 成功回傳統一為 `{ "data": T }`。

---

第三階段：實戰工作流 —— 如何省下 70% Token？

這是最核心的操作技巧，避免讓 Agent 漫無目的地搜尋。

Step 1: 精準 Pin (釘選)

當你需要開發「產品列表」前端功能時，不要讓 Agent 掃描整個後端。

指令範例：

「我要實作產品列表 UI（Vue 3）。請參考後端的 @backend/app/Data/ProductData.php，幫我產生對應的 TypeScript Interface，並完成列表渲染邏輯。」

Step 2: 檔案投影 (Projecting)

Agent 讀取 ProductData.php（約 200 Tokens）後，會在前端生成：

TypeScript

interface Product {
  id: number;
  title: string;
  price_cents: number;
  description: string | null;
  is_published: boolean;
  tags: string[];
}

一旦 Interface 生成完成，立刻解除釘選 (Unpin) 後端檔案。接下來的 UI 調整，Agent 只需要看這份 Interface，不再需要回頭讀取後端。

---

第四階段：總結 —— 效益對比

指標	傳統全端開發	Laravel-Data + Antigravity 模式
Token 消耗	高 (需掃描 Route, Controller, Model)	極低 (精準讀取單一 Data 檔)
AI 幻覺率	高 (常猜錯欄位名、忘了 nullable)	接近 0 (屬性即合約)
維護成本	高 (修改後端要手動改三處)	低 (只需修改 Data 類別)

架構師建議

在中大型網站中，AI 的效率取決於你給它的「資訊密度」。laravel-data 將原本混亂的 API 結構壓縮成一份乾淨的「說明書」。

當你讓 Antigravity 的 Agent 習慣於「先讀 Data 檔，後寫前端碼」的節奏時，你不但省下了大筆的 Token 費用，更獲得了一個永遠不會寫錯 API 欄位的完美隊友。