AI 輔助開發的原理
AI 能夠輔助開發的原理，在於 AI 透過與你的對話及你提供的上下文來理解需求，進而產出你想要的結果。因此，除了解讀你下的指令外，AI 還必須進入你的專案目錄，將所有 Source Code 讀進來，才能理解專案的架構與邏輯，進而做出正確的修改。 然而，每次的讀（你餵的資料）與寫（處理、回覆你的內容）都需要消耗額度或 Token。單次 Token 有其上限，也代表著使用成本，因此你需要學會如何有效率地餵資料給 AI，讓它能在有限的 Token 內理解你的專案並產出想要的結果——這就是所謂的提示詞工程（Prompt Engineering）。
重點：組織提示詞絕對不該由你來下，而是請 AI 幫你組織提示詞，這才是有效率的做法。你不可能自己想出一大堆提示詞來餵給 AI，那樣根本沒有效率。
實際案例
藉由 23年11月 Antigravity（以下簡稱 AG）的問世，我在很短的時間內完成了幾個專案：
- 一個是我先選好框架、設計好核心程式，然後讓 AG 接手優化架構及後續開發
- 一個是從 0 開始讓 AG 幫我選框架並開發所有網站系統功能
- 另一個也是從 0 開始但不使用既有框架，而是請 AI 選擇合適的架構自行開發，並在過程中加入許多客製化需求，持續維護該網站系統
這些案子在初期開發都很順利，每次告訴 AI 我要什麼功能，AI 就能幫我完成初始程式碼生成。但後續維護就不那麼順利了—— 我發現能使用 AG 的時間變少，處理時間也變慢，原因就是 AI 每次都要重新讀一次專案目錄，再去修改我想要的功能。因此，我開始學習如何有效率地餵資料給 AI，讓它在有限的 Token 內理解專案並產出想要的結果。
為什麼 Claude Code 改程式碼完整度較好？
一般人會覺得 Claude Code（以下簡稱 CC）改程式碼的完整度較好，是因為 CC 有專門設計的提示詞引擎，能讓 AI 更有效率地理解專案需求。但我認為核心還是在 LLM 的能力——AG 使用 Claude Opus 4.5 Model 也能做到一樣的事。
我的提示詞工程流程
如果你希望打造 24 小時不間斷自動改進的 AI，你也得會這個：
- 整體結構：先讓 AI 讀取專案目錄的結構與檔案清單，並請 AI 幫你組織出一份專案結構說明文件（通常是 markdown 格式）。這份文件包含目錄結構說明、各檔案的用途說明，讓 AI 每次都能用最少的成本理解專案。這裡說的 AI 不僅限於 AG 或 CC。
- 模組功能：除了整體架構外，你往後開發的模組有哪些功能，也必須請 AI 幫你記錄在模組功能說明文件中（可分開多份）。這樣每次你要讓 AI 修改某個模組時，它就能快速理解該模組的用途與功能需求。
- 使用前的理解：每次讓 AI 修改程式碼前，先請 AI 幫你整理出修改需求的提示詞，確保 AI 每次都能理解你的修改範圍，並在有限的 Token 內完成修改工作。
- 開發後的維護：每次 AI 完成修改後，請 AI 幫你整理出程式碼變更說明文件，讓你清楚了解每次修改的內容，方便日後維護。
兩大好處
使用少量的 Token 來讓 AI 理解專案有兩大好處：
- 大量節省費用
- 大量節省 AI 處理時間
原則上就是重複進行上述 1 – 4 步驟。當然，你還能在這基礎上加入更多細緻的提示詞工程技巧，讓 AI 更精準地完成需求。但切記，請用 AI 來幫你組織提示詞，而不是自己來想，這樣才是有效率的做法。 其實這個概念跟 SKILLS 的知識管理很像——你要讓 AI 幫你管理專案知識，再用這些知識來引導 AI 完成開發工作，才能達到事半功倍的效果。
讓 AI 自己寫一份 ReadMe.md 他就會在每次執行前，自行來讀取，並且會在裡面交辦 AI 必須怎麼按需讀取文件，以及完成後如何更新回寫相關文件。最終你只需要在 IDE Rules 寫上：每次開啟新對話後如果需要開發就先去讀取 ReadMe 文件就完全做到自動了。
Tip 小技巧
在 Antigravity 中 Gemini 3 pro (High) 很擅長讀長文，因此我會用它來跑第一次產生給AI看的文件，然後再請 Claude Opus 4.5 (Thinking) 來檢視，並作調整。