使用 Antigravity 搭配著 Jules 來開發
大家好，我是新加入的小夥伴ＸＤ
剛好看到有一篇前輩提及到 jules ，最近我使用下來也小友心得，把自己 blog 的文章分享轉貼過來～
以下內容出自於此：https://taislife.work/zh-tw/blogs/antigravity-with-jules/
大致上我仍然很看好 jules 的潛力，只是可惜 google-labs 看待這項目似乎仍然以實驗性質做看待，開發較慢沒有投入太多資源在裡頭。
PS: 我有發現他可以串 github action，在小專案的日常為運上可玩性還是挺高的ＸＤ
自從 Antigravity 出現以後，我開始使用 Antigravity 來開發我手邊大大小小的專案。
前言：我也想懶人開發
看著越來越多社群上的開發者日以繼夜得瘋狂操弄著 Claude Code，來達到長時間且持續的 AI Agent 開發專案，讓我也想嘗試看看在 Antigravity 可以走得多遠。身為 Google 單推人的我可是對 Antigreavity 抱有很大的期待！
Antigravity：Multi Agent Manager
起初，我依樣畫葫蘆的方式去操弄 Agent Manager，去讓我可以同時在不同的 Session 對話中，開發相同的專案。我的規劃如下：
Session 1：負責生成 2 份的需求文件和系統分析文件，明確地把開發內容訂定好。還有後續的 PR review 和程式碼整合。
Session 2：請它去理解 Session 1 生成的需求文件和系統分析文件，負責根據 Session 1 的
A需求文件和系統分析文件，進行開發，並且另外切開發分支、走 github flow 的開發方式、發 PR。Session 3：請它去理解 Session 1 生成的需求文件和系統分析文件，負責根據 Session 1 的
B需求文件和系統分析文件，進行開發，並且另外切開發分支、走 github flow 的開發方式、發 PR。
一共三個 Session，一個充當工頭（負責規格制定、PR review），兩個作為工人負責開發。
痛點：匆匆忙忙地在不同 Session 間切換
雖然標榜著 Agent Manager，但本質上還是 GUI 工具，還是得要有人類在旁邊看顧著。所以會常常發生 Session3 還在 typing 的時候，Session2 就已經跑完了，然後我還沒來得及把 Session2 的 PR 號碼貼給 Session1 ，Session3 也跑完了。最終還是會在人類的介面操作速度上被限制住，無法達到真正的無人全自動開發。
還有一個很大的問題就是在這情境下， token 消耗的速度非常的快。我只跑完兩組任務的開發，就把 Claude Opus 4.5 的 token 消耗光了，這對我來說是一個很大的負擔，照這做法一定很快就會吃到週更限制的懲罰機制。
解決方案：Jules
這時讓我想起了在 Antigravity 出現之前，Google 也曾推出標榜異步開發的 AI 工具 Jules，已經有段時間沒進去看過，沒想到現在推出了兩個新功能。
Schedules 和 Suggessions。且也可以使用 Gemini 3 的模型進行開發。
為此我決定調整一下我的開發流程。我決定把 Sub Agent 的任務，委派給 Jules 去處理，而我在 Antigravity 上的任務只剩下產出需求文件和系統分析文件，以及最後的 PR review 和程式碼整合。
Antigravity：撰寫 workflows 和 skill ，去訂定 code review 的標準，以及採用
gh指令去 review PR。Jules：根據 Antigravity 產出的需求文件和系統分析文件，進行開發、發 PR。
事情瞬間變得順暢許多且 token 消耗也變少了！對 Antigravity 來說，他也可以在 review 的階段時候，直接介入接手該 PR 後續的修正或是衍生的開發。Jules 只需要負責實作出規格明確的開發任務，在這程度上，只使用 gemini 3 的模型就足夠應付個八九成了。
現在試跑下來持續一週多，我只需要每天早上通勤時間草草看過 PR ，確認都有在做事，後續就是進公司以後再請 Antigravity 去處理即可。
這樣的合作方式讓節奏不再匆匆忙忙，而是可以更從容地應對各種狀況，人類只需要 review Antigravity 的 Review 結果即可，就像是有人幫你在 PR review 之前先行把關。
同時有足夠餘裕的 token credit 可以用做後續新功能的文件規劃和撰寫，也能確保開發品質。
未來衍生：透過 CLI tool 來達到真正的全自動化？
看到標題的朋友們應該就猜到了，未來勢必得回到 gemini-cli 上去處理全自動化開發的事情。
我們可以透過 gemini-cli 去觸發 julies-cli ，來去觸發新的規格文件撰寫和開發流程。
當然在初期避免專案失控不可控，我應該會打算一開始先以單一線程的方式來實現這計畫，避免多線程開發造成版控衝突需要人為介入的情況發生。當然這也是後話了。
任務委派
crontab -> gemini-cli 產出完整的系統分析文件 -> julies-cli 進行開發 -> 發 PR
Review & Merge
crontab -> gh-cli
gh pr list發現有 PR -> gemini-cli 參閱 workflow 和 skill 進行 review -> 如果 review 成功 -> gh-cligh pr mergecrontab -> gh-cli
gh pr list發現有 PR -> gemini-cli 參閱 workflow 和 skill 進行 review -> 如果 review 失敗 -> 嘗試介入開發微調修正 or 寄信通知 -> gh-cligh pr comment
```mermaid
sequenceDiagram
autonumber
participant Cron as Crontab
participant Gemini as Gemini CLI
participant Jules as Jules CLI
participant GH as GitHub CLI (gh)
Note over Cron, GH: 階段一：任務委派
Cron->>Gemini: 觸發任務
Gemini->>Gemini: 產出系統分析文件
Gemini->>Jules: 傳遞開發規格
Jules->>Jules: 進行程式開發
Jules->>GH: 發布 Pull Request (PR)
Note over Cron, GH: 階段二：Review & Merge
Cron->>GH: 檢查 PR 列表 (gh pr list)
alt 無 PR
GH-->>Cron: 列表為空，結束
else 發現 PR
Cron->>Gemini: 請求 Code Review
Gemini->>Gemini: 讀取 Workflow/Skill
opt Review 通過
Gemini->>GH: 執行合併 (gh pr merge)
end
opt Review 失敗
Gemini->>Gemini: 嘗試修正代碼 or 寄信
Gemini->>GH: 留下評論 (gh pr comment)
end
end
```作者：Tai