使用 Antigravity 大約一個星期了，有一些心得，以及尚未釐清的疑問，想把它們寫下來。
AI Agent 有三大要素：大腦、記憶、和工具。
Antigravity 把整個規劃和實作過程整理成文件，就像是「記憶」。有了清楚的記憶，agent 才能掌握以前到現在發生了甚麼事，以及如何接著進行新的任務（或上次未完成的工作）。
劃重點：奈米香蕉生成的圖真好看，中文字還都正確、沒有火星文!
Antigravity 把整個規劃和實作過程整理成文件，就像是「記憶」。有了清楚的記憶，agent 才能掌握以前到現在發生了甚麼事，以及如何接著進行新的任務（或上次未完成的工作）。
劃重點：奈米香蕉生成的圖真好看，中文字還都正確、沒有火星文!
評價兩極的原因？
我的疑問是：為什麼我用 Antigravity 來寫程式（和文件）覺得它超讚，卻也看到不少人說它很糟糕？
例如這兩個 Reddit 討論串：
有人說它很棒，有人則抱怨出很多錯誤。
不只論壇，身邊也有朋友反映類似的情形，故我很好奇為什麼會產生這樣兩極的評價。然而，我跟朋友線上討論了一下，仍無結論。
我聽到的是類似：「我叫它做 XX，結果它自己一直改來改去，改到最後還沒改好，免費 token 額度就用完了。我把程式碼丟給線上的 AI 網站，一步一步修，結果卻改好了。」
由於沒辦法看到對方完整的使用情境和過程，包括程式碼、以及他給 AI 下的每一道指示，所以我覺得還是很難判斷究竟是什麼原因產生這樣的情形。
朋友提到，程式碼有一千多行，故認為是因為沒付費訂閱 AI 平台，所以無法一次處理到位。我想這應該是個誤會。
我的體驗
最近處理的 .NET 專案有將近三萬行程式碼，而我交給 Antigravity 的每一項任務幾乎都處理得很好（其中一個案例：我與 AI 處理 .NET Null Reference Warnings 的心得），而且我也是沒有付費的情況。
可以確定沒有付費，是因為 Antigravity 目前還在預覽階段，根本沒辦法用到付費的方案。詳見官方文件：
雖然還不確定究竟是哪些原因造成不同人對 Antigravity 的不同感受，但我可以在這裡分享一些個人的粗淺心得，分為兩個方面：
- 工具的設定
- 使用 AI agent 的方法
工具的設定
初次啟動 Antigravity 時，應該會看到以下畫面，讓你選擇 AI 的工作模式：
我選擇的是它預設推薦的 Agent-assisted development。關於圖中四個選項的說明，可以參考官方教學文件：開始使用 Google Antigravity - 安裝。
這些選項可以事後在設定中修改，如下圖：
其中的 Review Policy 我沒改動，維持原本設定的 Request Review。Terminal Command Auto Execution 則改成了 Turbo，因為我後來發現它執行任務時，老是要我確認能不能執行外部 shell 命令，我覺得這樣很麻煩（不能專心看電影），所以就改成了 Turbo。
另外要注意的是 Agent 面板下方的提示方塊也有工作模式和 AI 模型，如下圖：
如果你也發現它寫程式一直反覆寫錯還直直往前衝，請確認這裡的工作模式為 Planning，而不是 Fast。
AI 模型的部分，我只用這兩種：
- Gemini 3 Pro (High)
- Claude 4.5 Sonnet (Thinking)
如果任務處理的時間太長、太多，導致免費 token 額度用完，我要麼休息去做別的事（五個小時之後再回來繼續），要麼改用 Gemini CLI 繼續處理（用 API Key 的方式付費）。
使用 AI agent 的方法
使用 AI agent 的方法，我認為有兩個重點：任務大小、提示詞是否精確。
任務大小
任務最好細切，避免一次給 AI 一個很大的任務，寄望它一次正確完成全部。
我通常是把要做的事情先開好 ticket，也就是先在 GitHub Issues 上面寫好問題描述、需求、預期結果等等。一張 ticket 就是給 AI 的一個小任務，每次就只讓它完成一個小任務。
Antigravity 收到任務之後，通常會先分析並制定一個實作計畫（Implementation Plan），列出工作清單（Task）。完成後，還會產出一份名為 Walkthrough 的工作報告，說明它剛才做了哪些事情。
我覺得 Antigravity 產生的實作計畫對日後有參考價值，所以在最近處理的 .NET 專案中，我會下提示給 Antigravity，叫它把實作計畫和 Walkthrough 保存起來，作為日後的參考。如下圖，我讓它按照文件的性質自動歸類保存於 Doc/planning 底下的資料夾。
這只是我的一個小習慣。每個人運用的巧妙之處各有不同吧。
提示詞是否精確
給 AI 的提示詞也是關鍵。我認為這個部分可能是令 AI agent 工作成果產生巨大差異的主要原因之一（但我沒有證據 XD）。
提示詞千變萬化，這裡只分享我曾紀錄下來的其中一則：
我想要保留 Txt2Brl 這個專案，以便將來依然可以用這個命令列工具來執行點字轉換工作。同時，主程式（EasyBrailleEdit.csproj）的組態檔（EasyBrailleEdit.Common.AppConfig 類別）要增加一個選項：是否執行外部工具來轉換點字。這樣就能利用組態檔來控制轉換點字的時候要使用主程式內建的能力，還是呼叫外部工具（Txt2Brl）來轉換。如此一來，萬一主程式內建的轉點字功能有效能問題而無法順利執行，使用者還可以 fallback 至另一種執行方式。
你覺得如何？
結果 AI 產生了一份很詳細的計畫，名稱還取得很好，叫做：「雙模式點字轉換架構實施」。這份計劃裏面包含了目標、策略優勢、階段一：研究與分析、階段二：制定計畫、階段三：實作整合、階段四：測試驗證、階段五：文件與部署，和最後的風險與注意事項。
如剛才說的，我有保存這些實作計畫的習慣，就順便截圖放上來：
結語
AI 如果一直出錯，我總視為一種常態。我前幾天處理 .NET 專案時的數百個編譯警告，也是 AI 弄到爆掉，我自己介入跟 AI 一起修 code，才比較順利。而且，我在 Antigravity 預覽版不支援付費方案的情況下，依然達成不少進度（用驚豔、驚喜來形容也不為過）。
若發現 AI 一直出錯，我會讓它停止，免得一直無謂地消耗 token。同時會去看看：
- 是否我的提示詞給得不夠精準、精確和詳細？
- 是否該把問題進一步拆分成更小塊，一個一個處理？
- 是否哪個地方由我自己修改可能更快些？
大概是這些。只是我個人的一些使用經驗，不代表一定符合每個人碰到的情況，也可能有其他因素和場景是我沒想到的。
Keep coding!
沒有留言: