沒錯！您的直覺非常準確，這正是整個創建型模式（Creational Patterns）核心要解決的根本問題。
new 關鍵字來建立物件（例如 MyClass obj = new MyClass();）雖然直覺又方便，但在中大型系統或需要高度擴充性的架構中，直接使用 new 會帶來幾個致命的痛點。創建型模式的存在，就是為了將「物件的建立邏輯」與「物件的使用方式」徹底解耦。new 會遇到以下幾種不適合的狀況：GoF（Gang of Four）的《Design Patterns》將 23 種經典設計模式分為三大類（創建型、結構型、行為型）。軟體工程界與許多經典著作（如 Martin Fowler 的重構書籍、Refactoring.guru、以及各種架構指南）早已將每種模式歸納出明確的適用情境（Use Cases）與解決的問題。
Dependency Injection 一個很不錯用的 Design Pattern。
在系統程式或一般的應用程式開發中，只要遇到「需要切換實作」、「需要與外部系統/硬體互動」或「需要進行單元測試（Unit Test）」的情況，都是利用依賴注入（DI）的絕佳時機。
除了你提到的身分驗證（Authentication）外，以下為你整理出最常見且實用的 5 大 DI 應用場景，並依功能類型進行分組：
這是一份為你快速掌握 Dependency Injection (DI，依賴注入) 核心精髓的重點整理。不囉嗦、不搬大部頭理論，我們直接從「為什麼需要它」到「怎麼實作」一次看懂。
Car）需要另一個類別（例如 Engine）才能運作時，傳統作法是讓 Car 自己去 new 一個 Engine。這就像是一輛車把引擎直接焊接死在車體裡，壞了很難換，也沒辦法測試。IoC（Inversion of Control，控制反轉）嚴格來說「不是」一種設計模式（Design Pattern），而是一種「設計原則」或「架構思想」。
問：如果我請 agy 處理一件看起來很複雜應該很耗費 token 的工作，我是不是在做之前，先請 agy 幫我分析一下，是不是有比較省 token 的方法，再由它建議的方法，分批讓它做，這樣可以省下較多的token，我這樣想對不對？
答：
你的思路完全正確，這是一種非常聰明且專業的 Prompt Engineering（提示工程）與 Token 節省策略。
透過「先分析後執行」與「任務拆解（Chuniking）」，確實能大幅降低 Token 消耗，理由如下：
減少無謂重來（Retry Costs）： 如果直接讓 AI 處理龐大任務，萬一方向偏離或格式不符，重新產生的代價極高。先請它分析並確認執行計畫，能確保「一次做對」。
精準鎖定上下文（Context Window）： 將大任務拆解成小步驟（如 Step 1~3），每次執行只需餵入該步驟相關的 Context，避免每次對話都夾帶過長的历史紀錄或全貌資料。
縮短輸出長度（Completion Tokens）： AI 一次輸出長篇大論容易出現贅字、格式混亂甚至中斷；分批執行能讓 AI 專注於高濃度的重點輸出。
為了達到最佳的 Token 節省效果，建議分三個階段引導 AI：
第一階段：需求分析與結構化計畫（消耗極少 Token）
「我有一項複雜任務 [簡述任務內容]。請先不要執行，幫我分析這項任務，並提供一個最省 Token 且高效率的分批執行計畫（包含步驟拆解與建議的輸入/輸出格式）。」
第二階段：確認與微調
檢查 AI 給的計畫，若沒問題即可核准；若有需要調整的地方，在此階段以簡短指令修正。
第三階段：分批執行（Batch Execution）
「很好，我們依照計畫執行。請先處理 [步驟一]，輸出結果請維持精簡，直接提供核心內容即可。」
明確限制輸出格式： 要求 AI「使用列點（Bullet points）」、「表格」或「僅輸出 Markdown / 代碼，不需前導與總結客套話」，可省下大量不必要的文本。
適時開新對話（Reset Context）： 如果整個任務分為三個獨立子項目，完成步驟一並取得結果後，可以將步驟一的結果複製到新對話中繼續做步驟二。這樣能徹底清空舊對話積累的 Context Token。
agy(Antigravity CLI) 是 Google 的 AI 「代理優先（agent-first）」開發平台的一部分，具備以下特點：
gemini 指令，而是透過新的二進制檔案執行 agy 指令。這是一篇問題與答案的組合文章，是由我和 Gemini 對談的內容所構成。其實是有關一直以來我對於工作場合上遇到的，想不透的事情，所提出的問題。這些問題主要是針對 Docker 網路的基本概念，涉及的是 Macvlan 這個蠻重要的東西 (網路驅動程式)。
我要做一個範例，請 Claude 幫我生成。
很簡單，使用Docker，用 GO 語言，儘量用 1.25 版。然後 Docker 基底可以使用 alpine 或 Ubuntu。Docker 有一個 volume，可以放 SQLite 資料庫。
然後用 Gin 寫一個 Web 應用，曝露 port 是 8080。
程式很簡單，有一個簡單的首頁，讓你輸入帳號和密碼。資料庫也很簡單，三個欄位：1. id:自動新增的 int，2. name : varchar(20)，3. password：varchar，存加密後的密碼。
底下有一個 URL，跳到另一個畫面：新增帳號，有三個輸入方塊：帳帳和兩個密碼。
程式要讓兩個密碼相同才能接受，然後自動跳到首頁。
密碼要加密。
首頁只做一件事，從資料庫中查找帳號、密碼(不用解碼，也可像用 MD5 對照)是否在其中。符合就跳出一個畫面，上面只有四個字在正中央：歡迎光臨。
然後必須把 Docker file 也做好。如果有 Docker Compose File 更好了。
一般來說，我們在VMware建立一個VM，只須在VM中安裝VMware Tools，應該可以使用共享資料夾的功能。共享資料夾可以成為VM和Host OS之間共享檔案，這個功能很重要。但是，偶而就是會出怪事，即使你安裝了VMware Tools，在Virtual Machine Settings...也把Shared Folder加上了，但是就是連不上，這該怎麼辦呢？以下是Gemini的回答：
這是在 VMware 上使用 Linux 虛擬機（尤其是像 Kubuntu 這種基於 Ubuntu 的發行版）時非常常見的問題。雖然 VMware Tools 已經安裝，但現代 Linux 系統通常不會在開機時自動執行掛載指令，或者掛載點沒有被正確建立。
你可以按照以下步驟排查並解決：
首先，確認系統是否有偵測到 VMware 的共享資料夾功能。請在 Kubuntu 的終端機執行：
lsmod | grep vmw_gfshg
如果沒有輸出，表示模組沒載入。不過通常安裝好 open-vm-tools 後，關鍵在於掛載指令。
在自動化之前，我們先確認能不能手動掛載。請執行：
# 建立掛載點（如果還沒建立）
sudo mkdir -p /mnt/hgfs
# 執行掛載指令
sudo mount -t fuse.vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other
執行完後，檢查 /mnt/hgfs 資料夾。如果你看見了你在 Setting 中設定的資料夾名稱，那表示硬體與驅動層面是沒問題的，純粹是自動掛載失效。
要讓它每次開機都自動出現，最穩定的做法是修改 /etc/fstab：
使用編輯器開啟檔案：
sudo nano /etc/fstab
在檔案最後面加入這行：
.host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other,defaults 0 0
存檔離開（Nano 請按 Ctrl+O 再 Enter，然後 Ctrl+X）。
主要有幾個常見原因：
套件衝突： 現在大多數 Linux 發行版建議使用官方開源的 open-vm-tools-desktop，而不是 VMware 選單裡那個舊版的「Install VMware Tools」ISO。如果你是手動執行 .pl 安裝檔，有時會與系統內建的驅動衝突。
掛載點缺失： VMware Tools 預期掛載在 /mnt/hgfs，但 Ubuntu 體系的系統預設不會建立這個資料夾。
FUSE 權限： 共享資料夾是透過 FUSE 技術掛載的，如果沒有加上 allow_other 參數，有時候一般使用者權限會看不到內容。
如果你發現 /mnt/hgfs 裡面是空的，但指令都沒報錯，可以試著在進入桌面後執行 vmware-user-suid-wrapper，這有助於初始化桌面環境下的共享服務。
通常完成 /etc/fstab 的修改並重啟後，問題就能徹底解決。
