Google Jules 將於 12 月 31 日結束：11 月 11 日前處理任務，如何保留開發紀錄？
Google Jules 將於 2026 年 12 月 31 日結束，11 月 11 日後先轉唯讀。解析工作收尾、官方匯出內容、敏感設定保護與接到其他代理的限制。
把修錯、測試與維護交給 Jules 之後，專案留下的不只有程式碼，還有它如何安裝環境、理解需求與走到最後一步的紀錄。
如果服務即將結束，這些紀錄能不能帶走，就會比下一個模型多強更急迫。
Google 在 2026 年 10 月 29 日公告 Jules 將於 12 月 31 日結束服務，並先在 11 月 11 日後轉為唯讀。
GitHub 上的程式、分支與 pull request 會留在原處，但 Jules 裡的設定、記憶、排程與工作歷史，仍需要另外匯出。
Google 表示將把學習成果帶進 Antigravity 等產品，卻沒有把這個方向寫成完整的一鍵搬家承諾。因此，目前可先保留讓下一套工具接手的資料。
對正在使用 Jules 的人，第一件事是按兩個期限安排工作，才不會把年底結束誤認為還能一路執行任務到年底。
Jules 的 11 月 11 日與 12 月 31 日，分別代表什麼？
Jules 的退場分成停止繼續工作與服務結束兩個階段。官方更新紀錄把日期寫得很清楚，使用者有到 2026 年 11 月 11 日的時間繼續完成工作階段，之後轉為唯讀，直到年底結束。
唯讀代表主要用途會變成查看既有內容，因此正在等待代理修改、跑測試或處理回饋的工作，應優先在轉換前收尾。不能只看十二月底這個日期，便假設還能繼續交付任務。
公告沒有給出明確時區與切換時刻，所以團隊排程不適合壓到截止當天的最後一刻。若最後一個測試失敗，還需要留時間修正與確認，才不會遇到服務已轉唯讀卻仍有工作未完成。
可以先把手上工作分成已交付、仍在執行與尚未開始。已交付的重點是保留結果與歷史，仍在執行的要先確認進度，尚未開始的則可評估是否改由後續工具承接。
這個分類也能避免重複工作。例如代理已經開出修改請求，只差人工審查，直接在新工具再寫一次相同功能，反而可能產生兩份互相衝突的修改。
因此任務收尾要以十一月的切換為界，資料保存也不能只等到年底才開始。哪些資料已在外部，哪些仍只在 Jules 裡，是整理時最先要分清楚的問題。
程式留在 GitHub，為何仍要另外匯出 Jules？
GitHub 保留程式成果，原服務則保存讓代理理解這些成果的工作脈絡。分支是程式的不同修改版本，pull request 則是把一組修改交給人審查、再決定是否合併的紀錄。
Google 明確表示，程式、分支與修改請求原本就在 GitHub，所以仍留在那裡。完整匯出針對的是 Jules 內部的設定與歷史，兩邊各有不同用途。
例如一份修改可能已經在 GitHub，但安裝環境時用過的設定、代理為什麼選這個方法，以及哪一項測試尚未完成，仍只出現在 Jules 的工作階段裡。
若接手者只有最後的程式差異，就可能看見「改了什麼」，卻不知道「為什麼改」與「已驗證到哪裡」。這會讓原本接近完成的工作，再花時間重新調查。
官方完整匯出包含帳號設定、環境變數、排程、連接的程式庫、記憶與初始化腳本，也涵蓋每次工作的提示、計畫、完整活動紀錄與程式修補檔。
環境變數是提供程式執行設定的一種方式，其中也可能放存取金鑰等敏感值。它有助於重建環境，卻不能像一般說明文件那樣任意公開分享。
因此，「程式還在 GitHub」與「已保存所有接手資訊」應分別確認。若希望另一個工具接著做，就要把兩邊資料對照，而不是只複製最後一份修改。
官方匯出方法能帶走哪些資料，哪裡需要本人操作？
Google 提供的匯出流程先透過 Jules Tools 登入，再把設定與各次工作整理到本機。Jules Tools 是用命令操作服務的官方工具，安裝方式為 npm install -g @google/jules。
接著由使用者執行 jules login，完成互動式瀏覽器登入。官方指引也要求在需要重新登入時停下等待使用者處理，沒有要求把存取權杖貼進對話。
登入完成後，官方提供一段給命令列代理使用的匯出提示，讓代理檢查設定並執行匯出。讀者應從當日官方更新紀錄取得完整指引，因為其中使用的介面可能隨服務變動。
這份匯出會把資料放到本機 ~/jules-export 目錄。這裡的波浪號代表使用者家目錄，整理結果存在哪裡，應以工具最後回報的完整路徑為準。
設定、程式庫與每次工作分別保存
輸出中的 sources.json 保存連接的程式庫清單。每個程式庫另有自己的目錄，放初始化腳本、測試命令與記憶，方便接手時知道環境如何準備。
每次工作也會有獨立資料夾，包含可讀摘要、完整工作資料、活動紀錄與修補檔。因此可以先用摘要判斷內容，再在需要時回看較細的過程。若摘要與活動紀錄對不上，就先釐清缺少哪個階段，不把最後一句完成回報當成全部證據。
這種分層比只保存一張成功畫面更有用。當新工具安裝依賴失敗時，可以回到原本的初始化腳本，確認差別來自環境還是程式修改。
不過官方流程也有條件。若需要匯出 GitHub 相關程式庫資料，帳號必須先與 GitHub 連接，否則其他設定可能成功，程式庫這一部分卻沒有包含。
因此，匯出能保留脈絡，但要確認是否完整，還得看每類資料的計數與錯誤。目錄出現本身，尚不能證明所有工作都已帶走。
如何確認匯出完整，又不把敏感設定放進程式庫？
匯出目錄可能含環境變數實際值，所以保存方式和檢查內容同樣重要。官方特別提醒，不要印出存取權杖或環境變數內容，也不要把匯出目錄放進程式庫。
可以先核對工具回報的程式庫、工作階段、修補檔與錯誤數量，再抽查自己知道的重要工作。這種檢查只需看檔案結構與必要內容，沒有理由為了證明備份成功而公開整份設定。
對一項已完成的修錯，可以對照摘要中的目標、修補檔與 GitHub 修改請求。若三者對得上，就能確認匯出指向的是同一件工作，而非名稱相似的另一個工作階段。
對尚未完成的工作，則要保留最後一次失敗與下一步計畫。因為最後一份修補檔可能只是中間狀態，直接套用不代表已通過原本要求的測試。
錯誤要按資料類型處理
官方說明指出，部分設定透過未文件化介面取得。若出現四百或四百零四錯誤，應確認是哪個呼叫失敗，而不能假設換一個猜測網址就能補齊資料。
四百零一通常需要先確認登入或 GitHub 連接狀態。若所有呼叫都失敗，可能要重新登入，若只有程式庫資料有問題，就應先核對帳號連接，避免把已成功的部分一起重做。
官方還說明，匯出介面有時會列出比命令列清單更多的舊工作階段。因此數量不同不必立刻當成資料重複，可以先對照工作識別碼、時間與標題，分清楚是舊資料被找回，還是真的匯出兩次。
初始化腳本與測試命令也可能從每次工作的輸出還原，而不是直接存在程式庫清單裡。若一個專案曾經換過安裝方式，接手時就要配合最近相關工作的程式版本檢查，避免把舊環境照抄到新分支。
同樣地，修補檔代表某次工作的修改內容，GitHub 分支則可能已繼續往前走。保存兩者能協助重建過程，但直接重複套用舊修補，可能把已完成的修改再做一次，所以應先核對程式狀態。
這些差異也提醒，備份結果應記下成功與失敗的範圍。若設定有了、工作歷史沒有，就仍缺少接手線索，不能只因某一個檔案可以開啟而結案。
先把內容完整性與存放範圍確認好，接手工具才有可靠且適當的輸入。接下來需要做的，是把保存的資料轉成新的工作起點。
接到其他代理前，哪些工作資訊要先重建？
可接手的工作應同時說清楚目標、環境、測試方式與尚未完成的決定。這是依匯出內容安排交接的建議，並不代表 Google 已提供可把整份目錄自動還原到所有代理的功能。
可以先選一項範圍小、成果明確的工作。例如原任務是修復某個表單送出時的錯誤，就一起保留觸發方式、預期結果、已改檔案與原測試命令。
新代理取得這些資訊後，先確認專案能否以相同條件執行，再判斷舊修補是否仍適用。因為接手時程式可能已在其他分支更新，原本正確的修改也可能需要調整。
若工作依賴敏感環境變數，應由適當帳號與設定途徑提供，避免把值複製到一般提示詞。交接說明可以保留變數名稱與用途，讓人知道缺哪項設定，而不揭露內容。
歷史記憶中的團隊習慣也需要判讀。有些是穩定的專案規則，有些可能只對應過去的一次問題，所以不宜把所有歷史記憶直接當成新工具必須永久遵守的指令。
排程則要逐項確認是否還需要。保存排程設定能說明原本何時做什麼，但不能推論新工具已經代為建立，尤其服務入口、執行權限與通知方式可能不同。
如果舊工作仍有開放中的修改請求，也要決定由哪一個工具繼續處理。清楚指定接手範圍，可以避免兩個代理同時回應同一份審查意見，產生難以合併的版本。
因此能在新環境重現一次小任務，才有理由把更大的維護工作交出去。這種接手證據，比工具名稱相近或都能登入同一個帳號更直接。
Antigravity 的統一方向，現在能推論到哪裡？
Google 確認的是代理開發工作將逐步整合的方向。Jules 官方原貼提到，將把非同步、遠端背景工作的經驗帶到 Antigravity，結合代理優先的開發環境。
這讓人看得出產品方向，但當日公告並沒有列出完整功能對照、匯入支援或訂閱處理方式。因此使用者仍需依接手產品當時的文件確認，不能把整合方向當成資料已自動搬移。
對現有使用者，較急迫的決定是哪些任務應在十一月前完成，哪些可以帶著完整紀錄換工具。這個決定取決於工作的剩餘風險，而不是只看新產品的宣傳能力。
對還尚未採用的人，這則消息也提供一個選工具的角度：除了能不能完成任務，還要看設定、操作過程與成果是否能保存在可接手的位置。
如果一項工作只能在特定服務內看懂，換工具的成本就可能高於表面上的月費。把工作目標、程式版本與驗收結果留在團隊掌握的資料中，會減少對單一服務介面的依賴。
把目前可保留的工作帶走，並等具體接入方式確認，比預先假設自動遷移更能保住進度。十一月前的重點是完成能完成的工作，年底前則要確認保留下來的內容確實能讀懂與接手。
延伸閱讀：【Vibe Coding】Jules 教學｜Google 最新 AI 程式碼助理實測：一句話補出完整後端 + API（附操作步驟）
延伸閱讀：Claude Code 2.1.314 加入寫入目錄限制：讓代理改檔前，先畫清楚工作範圍
常見問題
Jules 是 11 月 11 日還是 12 月 31 日結束？
兩個日期對應不同階段。官方公告十一月十一日後轉唯讀，十二月三十一日結束服務，所以需要代理繼續執行的工作應提早收尾，保留資料則不宜等到年底才開始。
匯出 Jules 之後，GitHub 的修改請求會消失嗎？
Google 表示，程式、分支與修改請求原本就在 GitHub，仍留在原處。匯出補的是 Jules 裡的設定與歷史，使用者仍應對照兩邊紀錄，確認自己保留的是同一項工作。
可以把匯出目錄直接給所有接手者嗎？
不適合直接整包公開分享，因為裡面可能包含環境變數實際值。應先按接手需要整理可分享內容，把敏感設定留在適當的存取範圍，並保留完整備份的原始副本。
想持續追蹤 AI 開發工具的變動與交接方法，歡迎免費訂閱 AI 郵報。
