前面幾天我們把 Heimdall 的 Dashboard、Step Timeline、Context 與 Insights 功能實作完了，當中有提到一個部分，就是我們在 Day 23 Dashboard 頁面 有大約計算我們可能花了多少錢在哪些 Model 上，加總後又是多少。但問題就來了，這些模型的定價規格從哪裡來？假設有新模型或價格調整，誰來維護？

在 Heimdall 裡面，為了計算每次推論花了多少美金、Prompt Caching 又省了多少錢，我們在程式碼中維護了一份模型目錄與定價字典。但大家都知道，各大廠商的模型更新速度非常快，價格也時常在調整。如果每次價格變動都要開發者手動查文件、改程式碼、跑測試再發 PR，不是不行，但就有點麻煩，想像上應該有更優雅的解決方案。

今天想來單純分享一下我在這個專案用到的一個小工具：Google 推出的 Jules。

一、一個真實的維護小困境

我們在 Heimdall 定義了每個模型的 Input / Output 價格，以及 Prompt Caching 的折扣比例。這份資料的特性是：

1. 邏輯不複雜：基本上就是單純的數值更新與單元測試比對。
2. 需要時效性：一旦官方降價或推出新模型，如果字典沒更新，Heimdall 算出來的帳單就會失準。
3. 容易遺忘：Daniel 平時有自己的工作，不太可能每天去刷各家官方定價頁面來更新。

這些任務通常很瑣碎且單純，就非常適合交給 AI 自動化工具來處理，包含「爬資料、更新程式碼、寫測試、發 PR」等。

二、什麼是 Google Jules？

Google Jules 是 Google 推出的雲端非同步 Coding Agent。如果拿它跟我們前面幾天常用的 Antigravity CLI 來比較，兩者的工作型態其實不太一樣：

簡單來說，Antigravity CLI 像是開發上的助手；而 Jules 更像是外包，你發一個 Issue 給它，它自己看到就會在 Github 開 Branch、改程式碼、跑測試，改好了丟一個 PR 到 GitHub 等你審核。講到這裡，我認為 Jules 有一點做得蠻棒的是跟 Github 整合還不錯！

在使用前需要先將 Jules 跟 Github 做連結，並把權限給 Jules，這樣他才能讀完修改然後發 PR。在具體使用上，Jules 有支援幾種操作方式（我所知道的）：

1. GitHub Issue 驅動

在 GitHub 直接開一個 Issue，把想要修改的需求、Bug 描述或規格寫清楚，並指派或標記 Jules。Jules 偵測到後就會自動接單，在背景開始任務並產生對應的 PR。像這樣：

開好後 Jules 會在這個 Issue 底下留言，可以透過這段留言來確認 Jules 有收到 Issue。

這裡是 Jules 平台上執行那個 Issue Task 的 AI Agent 所執行的過程，可以看到下面有對話框，如果針對它做的有意見你也可以直接跟他說。

做完後它就會開一個 PR，這裡因為我只有叫它 say hello，所以沒有任何 Change。比較可愛的是如果你留 Comment 給它，它還會用眼睛的 Emoji 來表示它看過了！

2. 排程自動觸發（Scheduled Tasks）

在 Jules 控制台預先寫好一段任務描述（Prompt），並設定定時執行的排程（例如每天或每週一次）。Jules 就會在指定時間醒來執行，完成後若有異動一樣會發 PR 給我們審查。我更新模型定價就是採用這種做法，做法是在這個 Repo 底下寫一個更新模型定價的 Skill，這個 Skill 主要會說明去哪些網站找目前的定價資訊，然後找到後去哪些檔案更新哪些資訊。對於 Jules，我就是請它定時去使用這個 Skill 來更新模型定價。

3. 主動掃描與建議（Repository Suggestions）

這功能我當初使用的時候好像還是 Beta 功能。Jules 會自動分析與掃描我們的 Repo，主動提出一些潛在的優化建議，例如：發現可以補強的測試、相依套件升級、安全疑慮等等。當我們在 Jules 平台看到這些建議覺得合適時，就可以手動點擊 Trigger 讓它開始執行並產出 PR。我靠這項功能做了蠻多測試補齊跟檢查。

我是去年知道 Jules 這個平台的，當時就蠻看好的，也想說找個機會用看看，但就想想而已哈哈。它的討論度沒有那麼高這件事讓我蠻訝異的，今天再登入時又默默多了很多功能，酷喔！值得注意的是，Jules 所使用的 Token 額度，似乎是跟 Gemini 和 Antigravity 分開來的，所以不用擔心因為用太多導致 Antigravity 的用量變少。試用了一陣子之後，我覺得這種非同步 Coding Agent 帶來了幾個很實際的體會：

1. 維護心態的轉變：
   以前寫完一個小工具，最怕的就是「後續維護很麻煩」。但當有了雲端 Agent 就可以幫忙處理這種規律、瑣碎但又必須嚴謹的任務，維護專案的負擔減輕了不少，而且我相信這類平台工具會越做越成熟。
2. 邊界依然很重要：
   我們不會讓 Jules 直接去重構核心架構或改動太抽象的業務邏輯。越是定義明確、有單元測試做防護網的修改（例如：列表清單、Protobuf 欄位擴充），我想它會做得越好。
3. Review 仍是重要的：
   日常工作中，我們確實可以不用花太多時間去當複製貼上工程師，但我們仍然需要把精力放在「確認 PR 的內容是否合理」上，我認為這是對於產品最基本負責任的態度。當然我這種對世界沒什麼太大幫助的小工具，不太會有什麼人用，所以應該不用在意這麼多哈哈。

一個好用的 Google AI 工具分享給大家，至今我還是很看好這個平台的哈哈～