Google Antigravity 中的 Claude：Opus 5.5 與 Sonnet 5.5 擴展企業模型選擇

Google 已為 Google Cloud 客戶在 Antigravity 加入 Claude Opus 5.5 及 Claude Sonnet 5.5，讓 Anthropic 與 Gemini 一同進入企業開發工作流程。Google Antigravity 中的 Claude 為開發人員在 Google 的編程環境內提供另一個模型家族選擇，也讓模型選擇、支出及生成工作責任納入同一決策流程。

眼前的好處很實際：團隊可評估不同模型，而毋須把每次比較變成獨立的工具專案。當中的張力在於開發人員選擇與企業管控之間。模型出現在選單中，並不代表已解決誰可授權使用、用量如何計費，或哪個系統負責處理支援工作。

Anthropic 獲得另一個分發渠道，而 Google 即使客戶選用競爭模型，仍保留開發人員介面。對工程主管而言，實際問題是這種安排能否改善已完成的工作。可用性開啟比較；可靠的程式碼、可管理的審查工作量，以及可理解的支出，才決定其價值。

Google Antigravity 中的 Claude 擴展企業模型選單

已確認的改變，是可在 Google 的企業開發環境中存取 Anthropic 最新的 Opus 與 Sonnet 模型。Google 的 Antigravity 模型公告 指出，管理員授權是開發人員選用模型的先決條件。

Google 列出 Antigravity 2.0、其命令列介面，以及適用於 VS Code、JetBrains IntelliJ 和 Visual Studio 的擴充功能，作為受支援的使用介面。命令列介面讓開發人員可透過終端機指令互動。IDE 擴充功能則將服務帶進整合式開發環境，即用於建立軟件的編輯器及相關工具。

這種覆蓋範圍相當重要，因為開發團隊很少只透過單一介面工作。調查失敗建置的工程師可能偏好終端機；修改應用程式行為的人則可能留在編輯器中。在這些環境中都能存取模型選項，可減少評估期間其中一種摩擦。

公告亦將 Gemini 3.8 Flash 及 Gemini 4 Argon 列為 Google 可用模型。這讓比較可直接在開發工作流程中進行。開發人員可在繼續使用 Antigravity 的同時，檢視另一個模型是否更有效處理特定問題。

這個範圍需要審慎解讀。Google 的公告針對 Google Cloud 客戶，而企業存取權限取決於機構設定。不應將其理解為保證每個 Antigravity 帳戶均會獲得相同的可用性、限制或商業安排。

存取與採用亦有分別。新啟用的模型可以一直未被使用、成為專門選項，或成為團隊慣常的起點。公告確立了第一個條件，卻未有為其餘情況提供證據。

設想一項示例維護工作：工程師需要修改驗證規則並更新相關測試。團隊可按同一要求比較模型。有意義的結果，在於每項建議改動是否保留既有行為並符合新規則。

另一項遷移工作則帶來不同要求。工程師必須識別相依關係、安排變更次序，並說明相容性決策。驗證修正上的成功，並不能證明其能勝任這項更廣泛的工作。

這個區別帶出此次發布的實際意義。Antigravity 現在提供另一種方式，可在既有環境內比較任務適配度。其價值在於，讓這些比較足以影響工程決策。

對買家而言，這比泛泛承諾提供模型選擇更具體。新增選項必須有助回答一個營運問題：在此程式庫及此團隊的限制下，哪個模型能產出可接受的工作成果？

工程主管承擔模型選擇決策

更多選擇會將責任移向批准、資助及審查 AI 輔助開發的團隊。Google 的整合為工程主管提供另一項可評估的選擇，也令單憑熟悉程度來合理化預設模型變得更困難。

開發人員的偏好固然重要，但只是決策的一部分。即使模型回應迅速，仍可能產生需要大量審查的改動。另一個模型或能清楚說明其推理，卻忽略藏在內部文件中的要求。

壓力首先落在維護共用開發工具及實務的平台工程團隊身上。他們需要有理據支持啟用額外供應商。這個理據應把模型存取與實際工作連結起來，而非把更長的模型清單視為成果。

安全審查人員面對相關決策。他們需要理解請求包含哪些資訊，以及由哪項服務處理。熟悉的介面可令新供應商看似例行做法，即使機構仍須檢視該安排。

工程經理必須評估對交付的影響。較快生成只有在縮短產出可接受改動所需時間時才有幫助。若審查人員需要花更長時間找出錯誤，表面上的速度優勢便會較不實用。

財務團隊另有一項關注：用量能否連繫至可辨識的活動。與遷移工作相關的帳單，跟開發專案中無法解釋的用量有不同含義。可見性有助就價值展開有用討論。

這些責任雖有重疊，卻不應合併為單一批准核取方塊。供應商可符合機構的資料要求，卻在其程式碼上交出較弱結果。技術能力高的模型亦可能難以編列預算。

對已使用 Antigravity 的團隊而言，Claude Opus 5.5 與 Sonnet 5.5 提供機會重新檢視既有假設。相關比較包括 Gemini 及團隊現時的開發流程，也應包括審查及修正每項結果所需的工作。

因此，評估需要具代表性的任務。具有嚴格相容性要求的程式庫，面對的挑戰與實驗性應用程式不同。模型能寫出看似合理的程式碼，並不能回答它是否遵守那些本地限制。

組織層面的影響亦延伸至文件紀錄。若一名工程師發現有用的模型選擇，這些知識需要在聊天工作階段以外保留下來。可搜尋的 工程知識庫 可保存要求、評估筆記及獲接受的決策。

結果是採購邏輯出現改變。團隊可把開發環境及其可用模型視為相互關聯的決策來評估。若 Google 的環境令這些決策更易一併管理，便會更具吸引力。

Opus 與 Sonnet 針對不同類型的工程工作

Opus 與 Sonnet 之間有用的比較，關乎任務形態、審查負擔及判斷能力。它們的名稱建立產品家族，卻不能決定特定工程團隊應接受哪一個結果。

Anthropic 將 Opus 定位為適合需要持續判斷的複雜工作。其 Opus 5.5 功能 公告描述了在高難度編程任務上的改進。這些仍屬供應商聲稱及示例，而非對 Antigravity 客戶程式庫作出的保證。

Anthropic 將 Sonnet 描述為更明確界定工作的一項互補選擇。其 Sonnet 5.5 功能 公告強調日常任務及迭代。公司亦提醒，基準測試結果只能反映能力的一部分。

這個區別支持一項合理的評估假設。界定清楚的錯誤修正，可測試模型是否遵從狹窄要求而不引入無關改動。開放式遷移工作，則可測試模型能否識別缺失資訊並作出可辯護的取捨。

這些是假設，應加以檢驗，並非每個團隊都應自動採用的任務分配。小改動可包含棘手的相容性陷阱；大改動亦可能主要由具有明確驗收標準的重複編輯構成。

開發人員對任務的描述也會影響比較。精確要求令模型需要解決的不確定性較少；不完整的簡報則迫使它推斷意圖、提出問題，或按假設繼續進行。

因此，有用的比較會保留相同的起始材料。每個模型都應獲得相關要求及程式庫背景。否則，準備工作上的差異可能看似能力差異。

審查應檢視最終改動以及其說明。具說服力的摘要可以掩蓋不完整的實作；簡短的回答亦可配合只需少量修改的正確工作。兩種寫作風格都不能決定工程結果。

Claude Opus 5.5 與 Sonnet 5.5 亦引出關於升級處理的決策。團隊可先使用適合界定明確任務的模型，並在不確定性增加時切換。這項政策只有在開發人員能識別觸發條件時才有用。

一個示例觸發條件，是應用程式元件之間存在互相衝突的要求。另一個是建議的修正改變了已報告錯誤以外的行為。兩種情況的問題都是未解決的判斷，而非生成答案的長度。

Gemini 仍是同一環境內的競爭選項。其存在讓團隊可檢視不同模型家族在可比較條件下能否得出更佳結果。這項整合並未確立普遍的勝出者。

更大的含義是，模型選擇可成為工程實務的一部分。團隊已會按風險選擇測試工具及審查方法；按工作性質選擇模型，便引入另一種同類決策。

這種做法需要紀律。若沒有記錄結果，按任務選擇模型可能變成個人偏好的集合。有了證據，它便可成為可重複的方式，用以分配困難工作並避免不必要的投入。

單一介面仍包含多個模型與計費路徑

共用介面簡化存取，但底層執行及計費安排仍需留意。這是將整合解讀為單一、統一服務時最明顯的限制。

Google 的 企業模型設定 將合作夥伴模型用量與已包含的 Gemini 點數區分開來。文件指出，第三方用量會透過機構的 Cloud Billing 帳戶，按用量計費。

這個區別會影響買家如何理解既有承諾。機構不應假設啟用 Claude 會從其已包含的 Gemini 用量中扣除。採購決策需要考慮實際的計費路徑。

執行亦涵蓋所選推理模型以外的部分，即負責理解任務並決定如何處理工作的模型。Google 的混合執行架構文件指出，主要工作由 Claude 負責，同時保留 Gemini 作背景協調。

實際含意比供應商獨立性的說法更為狹窄。開發者是在由 Google 管理的環境中選擇主要模型。工作流程仍可能涉及透過該環境運作的支援模型。

這種安排可以很有用。開發者通常希望在毋須管理每個支援元件的情況下，讓語境處理及協調工作順暢運作。不過，企業買家需要有足夠的可見度，才能了解系統正在做甚麼。

單靠模型標籤無法回答所有營運問題。團隊需要知道一次工作階段的活動如何連繫至用量紀錄及審核證據。否則，他們或會根據不完整的工作圖像作出評估。

例如，看似高效的編碼工作階段，可能涉及大量支援活動。所選模型的輸出只會呈現過程中的一部分。要了解整體消耗，必須檢視工作流程，而非只看最終回應。

同樣的推理亦適用於責任歸屬。當生成的程式碼失敗時，團隊需要分辨是誤解需求、缺乏語境，還是執行問題。這些原因需要不同的修正方法。

誤解需求意味著需要更好的任務界定，或改用其他模型。缺乏語境意味著準備工作有問題。執行失敗則意味著應檢視權限、工具或周邊環境。

把所有失敗都當作模型失敗，會掩蓋這些差異。把每次失敗都視為使用者錯誤，同樣沒有幫助。一個有用的企業整合方案，應讓相關證據足夠容易取得，以便調查。

這正是開發者便利性與企業管治交會之處。便利性可減少嘗試另一個模型所需的工作量。管治則決定組織能否理解及管理由此產生的活動。

因此，Google Antigravity 中的 Claude 代表現有平台內一項受管理的選擇。買家應連同模型的編碼成果，一併評估該平台的協調及用量核算能力。整體體驗決定這個額外選項是否實際可行。

跨模型審查增加檢視，但不代表正確性獲得證明

第二個模型可以質疑某項實作，但模型之間達成一致，並不代表軟件符合其需求。 這是 Google 建議的跨模型審查模式最核心的限制。

Google 描述由一個模型實作變更，再由另一個模型提出批評的做法。這項建議可以理解：另一個模型或能以不同傾向處理工作。然而，公告並未證實這能為客戶專案帶來可量度的可靠性提升。

不同觀點與獨立驗證之間的差別很重要。兩個模型都可能收到同一份不完整的簡述。兩者都可能忽略未有記錄的相容性需求。它們的結論可能一致，只因任務描述遺漏了同一項關鍵事實。

因此，一位有用的審查者需要的不只是實作者的說明。它還需要原始需求、實際變更，以及與行為相關的證據。否則，它有可能評判的是關於實作的敘述，而不是實作本身。

設想一個示例遷移，改變應用程式儲存日期的方式。實作在內部看來可能前後一致，卻會改變既有紀錄的行為。只聚焦於新程式碼的審查者，或會接受它。

關鍵問題是，遷移是否保留既有資料原本應有的含義。這需要明確的需求，以及涵蓋受影響行為的測試。充滿信心的模型回應無法補足缺失的產品意圖。

跨模型審查仍可協助找出值得調查的問題。它可以標示假設、指出缺少的測試，或建議被忽略的失敗情況。其價值取決於這些發現是否具體及有用。

審查流程亦需要有方法駁回薄弱的異議。模型可以提出不適用於該應用程式的假設性問題。調查每一項推測性的疑慮，只會增加工作量，卻未必改善變更。

有用的標準是證據。審查者應將異議連繫至需求、程式碼路徑或可重現的失敗。人類審查者其後可決定該疑慮是否值得修正。

這亦引出比較模型時的另一項考量：它們能否提出可採取行動的批評。較長的審查不一定代表較好的審查。與實際缺陷相關的簡短發現，可能更有價值。

反覆交接亦有成本。每次審查都會增加活動，並要求下一位參與者理解任務。這些額外投入需要產生足夠有用的檢視，才值得付出。

對某些任務而言，常規測試及人手審查仍然足夠。對另一些任務而言，第二個模型的批評可以發現值得處理的問題。整合令實驗更容易進行；它不會免除評估結果的需要。

同樣的審慎亦適用於模型專業分工。將範圍明確的任務分配給一個模型，把需要大量判斷的任務交給另一個模型，聽來合理。實際效益取決於這些界線能否在實務上維持。

工程成果應始終是核心。獲接納的變更、發現的缺陷、審查者投入的工作，以及後續修正，都比模型一致性提供更有用的證據。這項標準可避免一種吸引人的工作流程模式，演變成沒有根據的可靠性聲稱。

接下來應關注採用情況、獲接納的工作及營運可見度

下一批有用證據，將顯示團隊如何使用新選項，以及其產出最終帶來甚麼結果。 公告確認了可用性。它更廣泛的重要性，取決於公告未能證實的成果。

首個訊號是管理員啟用存取權後的持續使用情況。偶爾的實驗顯示市場有興趣，但在日常專案上持續使用，才表示更強的適配度。公開的客戶案例應區分實驗與持續進行的開發工作。

使用模式與是否使用同樣重要。Opus 若成為專門處理遷移的選項，與 Sonnet 若成為維護工作的常用選擇，所支持的結論會不同。兩種結果都比籠統的採用說法更具資訊價值。

放棄使用的證據亦很重要。團隊可能因結果欠佳、審查開銷或營運阻力而停止使用某個選項。若沒有這些背景，用量數字本身無法清楚說明原因。

第二個訊號是有關獲接納工作的證據。有用的客戶報告應將模型使用情況，連繫至通過審查並符合需求的變更。它亦應描述修正及失敗，而不只是展示令人印象深刻的示範。

一個可信的案例會說明任務、起始條件及驗收標準。這些背景讓讀者判斷結果是否適用於自己的工作。缺少這些細節的成功故事，提供的指引有限。

比較亦應承認儲存庫之間的差異。能妥善處理熟悉框架的模型，可能難以應對內部慣例。當發布者說明這些限制時，證據會更有用。

若團隊記錄到透過有意識的模型選擇而取得更佳成果，這個訊號將強化多模型開發的理據。若切換模型主要只會增加活動，卻未能改善獲接納的工作，這個理據便會減弱。

第三個訊號是整個工作階段的營運可見度。買家需要能協助他們連繫所選模型、支援活動及消耗量的報告。更清晰的證據，會令這種企業安排更易評估及管理。

可見度亦支援技術決策。若某個工作流程反覆需要大量審查及修正，團隊便可調查原因。他們可以根據比偏好更具體的資訊，調整任務、模型或流程。

這些訊號應一併解讀。沒有可接受成果的持續使用，是價值薄弱的證據。來自孤立示範的強勁成果，對日常採用的說明有限。可理解的營運情況，令兩者都更易評估。

對 Google 而言，機會在於令 Antigravity 成為比較及協調模型的有用平台。對 Anthropic 而言，機會在於在另一家公司開發環境中爭取持續工作。整合本身不會自動帶來任何一種結果。

對開發者而言，實際機會更近在眼前。他們可以就自己已了解的工作，評估另一個模型系列。這項比較應保留需求，並以一致標準判斷產生的變更。

在團隊中擴大使用 Google Antigravity 的 Claude 前，先選擇一項驗收準則清晰的真實任務。記錄模型收到甚麼、它作出了甚麼變更，以及審查者修正了甚麼。將結果與現有做法比較，包括達到可接受成果所需的工作量。把需求及評估筆記放在團隊日後可取回的地方。當證據改變時重新檢視選擇，尤其是當模型在維護工作與開放式工作上的表現不同。帶入下一次評估的問題應當具體：哪一種組合能以最少不必要的工作，協助你的團隊交付正確、可審查的變更？