Claude Code Utah 試點計劃:10 個機構的 34 名開發人員報稱節省時間
Anthropic 表示,Claude Code Utah 試點計劃讓 10 個州政府機構的 34 名開發人員使用其編碼助理。據該公司稱,80% 參與者在 30 分鐘內建立了可運作的環境。四星期試點結束時,71% 參與者表示至少節省了 20 小時。這些數字反映令人鼓舞的採用情況和感知效益,但並未證實經獨立量度的生產力提升。
這些結果見於 Anthropic 在 10 月 27 日公布、擴大其與聯邦採購機構總務管理局(General Services Administration,GSA)政府合作夥伴關係的公告。這一時點令一項小型州政府實驗具備更廣泛的意義。政府採購方正獲得更多採購選項,同時供應商亦在競逐把初步實驗轉化為持續的營運使用。
核心張力在於開發人員自行申報的節省時間,與政府軟件交付經核實的改善之間。OpenAI 亦擁有擴大的 GSA 協議,讓各機構多了一個可評估的供應商。對採購方而言,Utah 的經驗提供了研究編碼助理的理由。它仍留下更大的採購問題:哪些效益能通過安全審查、程式碼審查、維護及日常工作負荷的考驗?
Claude Code Utah 試點計劃實際報告了甚麼
Utah 報告的結果顯示出具前景的採用訊號,但這些數字所衡量的內容存在重要限制。
Anthropic 的 Utah 開發人員試點計劃摘要提供了核心數字:34 名開發人員、10 個州政府機構,以及為期四星期的評估。該公司同時報告了短暫的設定時間及可觀的自行申報節省時間。兩者雖有關連,卻回答了採用陌生工具時不同的問題。
設定數字關乎參與者是否能迅速達到可運作的環境。這一點很重要,因為安裝、帳戶存取、權限及設定均可能延誤有用的實驗。一項開發人員無法輕易開始使用的工具,會即時構成採用問題。Utah 所報告的經驗顯示,對大多數參與者而言,初步設定尚屬可管理。
不過,可運作的環境只是起點,並非完成的營運評估。它並不能證實開發人員是否已連接每個相關系統,或完成每項所需審批。它亦幾乎未說明參與者在設定時計時開始前獲得多少協助。這些細節有助其他機構判斷,其上線體驗會否與 Utah 相似。
節省時間的數字反映參與者使用工具後的評估。報告至少節省 20 小時,顯示受訪者認為效益不止於最初的新奇感。然而,該公告並未提供一項獨立量度的比較,對照沒有使用 Claude Code 的情況下完成等值工作所需的時間。讀者在轉述結果時應保留這項區分。
這些百分比亦須審慎解讀。描述開發人員達到某個報告節省時間門檻的百分比,並不等同平均生產力提升。它沒有說明每名參與者節省了多少時間,亦不能證實整個機構的項目工期縮短,或完成的公共服務相應增加。
公開摘要的數字未有清楚交代其底層調查流程。回應率、參與者選擇及工作任務組成等問題仍然相關。這些問題不會否定所報告的經驗,但會決定另一個機構可多有信心地將發現套用至自身的開發人員。
涵蓋多個機構令這項試點計劃比孤立的個人見證更值得關注。不同部門可帶來不同的工作條件和要求。然而,摘要並未展示參與者或所報告效益如何分布於各部門之間。因此,廣泛參與不應被誤認為同樣廣泛的成果證據。
公布時間表同樣值得精確處理。Anthropic 在 10 月 27 日的公告中納入這些發現,但這並不能確定試點計劃的確切開始日期。公告描述的是一項已完成的評估,不應被解讀為 Utah 與新的採購協議同步啟動這項實驗。
公開改變的是,一個具體的州政府採用案例與一項更廣泛採購倡議之間的連結。Claude Code Utah 試點計劃現已成為 Anthropic 政府擴張敘事中的證據。它對採購方的實用性,取決於能否把所報告的經驗,與摘要無法支持的結論清楚區分。
政府採購方面對更廣泛的採購決策
擴大的採購渠道令機構領導層必須在延長試點計劃前,界定何謂成功採用。
GSA 在 10 月 27 日的政府採購協議確認,Claude 可透過按使用量計費條款獲得更廣泛的使用權。按使用量採購意味收費依實際使用量而定。該機構描述了廣泛的政府資格及多種訂購途徑,且不設最低採購要求。
這項安排改變了 Utah 等實驗周邊的商業環境。採購方可評估持續使用情況,而毋須把每名感興趣的開發人員都視為固定的長期承諾。然而,靈活採購並不消除營運規劃的需要。機構仍須了解誰會使用服務,以及用於哪些工作。
即時壓力落在技術領導層、採購團隊及安全主管身上。開發人員或已看到編碼助理的價值,其他團隊則必須決定組織能否以負責任且一致的方式支援這種使用。他們的回應需要把個人熱忱與可問責的部署決策連繫起來。
該決策包括服務本身以外的成本。培訓、內部支援、審查時間及行政工作,均會消耗員工能力。這些是評估考量,而非 Utah 試點計劃中已記錄的不足之處。它們說明為何採購協議和開發人員調查合在一起,仍不能建立完整的商業理據。
使用量亦可能因不同原因而增長。更多開發人員可能發現工具有用,或現有使用者可能為其分配更多任務。部分任務或須反覆嘗試,才可產生可接受的結果。採購方需要有足夠可見度,分辨具生產力的擴展與消耗資源卻未改善交付的活動。
這為工程經理帶來實際責任。他們需要識別哪些工作應會變得更容易,以及這種改善會如何在日常營運中呈現。在某個流程中,更快起草或許重要;在其他地方,減少中斷、縮短審查週期或改善文件或許更重要。
OpenAI 提供了一個相關的競爭參考。GSA 在 9 月公布另一項 OpenAI 採購協議,同樣描述按使用量計費的使用權及更廣泛的政府資格。這確立了一個競爭性的採購選項,卻不能證實產品、部署條件或編碼成果相等。
因此,適當的比較應從機構需求開始,而非供應商宣傳。採購方應審視合資格服務、獲批准環境、行政控制、支援安排及實際任務表現。一項有利的商業報價無法解決工具在特定開發流程中表現不同的問題。
Utah 的結果令這種比較更明確,卻未能定論。供應商可指出,多個機構的開發人員報告了有意義的效益。競爭供應商面對壓力,需要提供同樣相關的證據。機構領導層亦有相應責任,追問這些證據是否反映自身的工作條件。
更大的轉變,是由獲准實驗走向為持續使用提供理據。初步使用權回答開發人員能否嘗試工具;持續部署則需要更清楚交代機構獲得甚麼、哪些責任仍由員工承擔,以及如何核查結果。
所報告的工時與交付的軟件衡量不同事物
開發人員可在某項任務節省時間,卻未必縮短一項獲接納軟件變更的完整流程。
設想一項涉及陌生應用程式的政府維護工作。開發人員可能要求編碼助理解釋某段程式碼,或草擬一項擬議變更。這是說明性情境,並非已有記錄的 Utah 項目。它展示了為何參與者可以合理地報告節省時間,卻不會產生可直接比較的交付指標。
節省的工作量可能發生於調查期間。理解既有行為可能很困難,尤其在文件不完整時。助理的解釋可協助開發人員識別下一步應查看的位置。有用的結果會是減少調查時間,即使開發人員最終手動撰寫變更。
另一種情況是,效益可能發生於草擬期間。產出例行變更的初步版本,可能騰出更多時間核查假設。這可以很有價值,但在組織獲得可用成果前,仍有測試、審查、審批及部署要完成。
這些階段很重要,因為工作可在人員之間轉移。作者可能更早完成草稿,但審查者或要花更長時間檢查。從該個人角度而言,作者所報告的節省時間可能準確。組織則需要更廣泛的量度,才能判斷總投入是否下降。
反過來亦可能成立。開發人員可能花額外時間準備更清晰的變更,讓審查者更容易接納。個人時間估算因而可能低估組織層面的效益。這正是評估應檢視工作流程,而非假定每項有用效果都會以更快輸入呈現的原因。
品質令比較進一步複雜化。若最終變更需要大幅返工,較短的完成時間價值有限。相反,改善測試或文件或可合理化額外投入。相關問題是,機構能否以更佳的時間、品質及可維護性平衡,取得可接受的工作成果。
基準,即顯示相似工作在沒有介入下如何進行的比較,有助回答這個問題。公開摘要的 Utah 結果未有提供此類量度比較。因此,採購方應把發現視為所報告經驗的證據,避免將之轉化為一般性的加速比率。
任務差異同樣重要。調查陌生程式碼與修改熟悉元件,對開發人員提出不同要求。例行變更與影響深遠的系統決策,需要不同程度的判斷。除非底層評估將它們區分,否則整體節省時間的主張無法顯示哪些工作帶來最強效益。
這種拆分可令日後的報告更具參考價值。政府機構可區分調查、撰寫、測試、文件編製及審核等工作,繼而識別哪些環節會重複帶來效益,以及哪些額外監督會抵銷節省下來的資源。這有助推行針對性的採用策略,而非籠統假設每項開發活動都會同樣獲得改善。
Claude Code Utah 試點計劃為這項調查提供了具體起點。參與者回報的效益足以值得進一步評估。下一步的分析工作,是將這些回報與獲接納的工作成果連結起來。這種連結應保留開發人員重視的改善,同時驗證機構是否獲得相應收益。
選擇並非在信任開發人員與衡量成果之間二選一。他們的回報指出了應該檢視的方向。營運證據其後可解釋所述效益、揭示其限制,並協助判斷哪些條件能令這些效益得以重現。
獨立研究顯示衡量工作為何需要審慎
有關開發人員生產力的研究支持審慎看待自我評估,但並未否定 Utah 所報告的經驗。
獨立 AI 評估機構 METR 研究了使用 2025 年初工具、並在熟悉的開源專案上工作的資深開發人員。其開發人員生產力實驗隨機分配工作,允許或禁止使用 AI 輔助。隨機分配有助研究人員比較結果,同時減少參與者選擇自己偏好條件所造成的差異。
該研究涵蓋 16 名開發人員完成的 246 項工作。參與者相信 AI 縮短了完成時間,但研究人員測得的結果卻是增加了 19%。這些發現說明,感知到的加速與實際量度的完成時間可能存在落差。它們並不能證明 Utah 發生了甚麼事。
兩者的情境在重要方面有所不同。METR 檢視的是較早時期中,特定開發人員、專案、工具及工作項目。Utah 的公告則描述了一項政府試點計劃,涉及不同群體及評估方法。若將任何一項結果視為普遍結論,都會將證據延伸至其研究設計所不能支持的範圍。
METR 本身其後也說明了量度較新工具的困難。在其 2026 年 2 月的衡量設計更新中,該機構表示,參與選擇及時間追蹤削弱了後續實驗的結論。它亦列出理由,認為開發人員可能比以往獲得更多效益。這項更新再次強調,檢視研究方法與檢視標題結果同樣重要。
對政府採購方而言,有用的啟示在於所回答問題的力度。滿意度調查可識別使用者是否希望繼續獲得存取權限。時間估算可反映感知到的效益。已完成工作成果的比較,則可處理交付表現。當各自目的保持明確時,這些衡量方式便能互為補充。
審核質素亦應納入考量。一項建議的變更可能表面上正確,卻建基於不合適的假設。審核者需要足夠脈絡,才能根據實際要求作出評估。生產力評估應納入這些核查所需的工作量,而非將生成的輸出直接視為已完成工作。
保安構成另一條界線。更快的輔助並不能決定某項工作是否適合特定環境。政府機構必須對所涉及的資訊和系統採用自身要求。成功的試點計劃應令這些界線更清晰,而非讓正面的使用者回饋取代它們。
公告亦未能證明效益是否在評估期後持續。最初的熱情或會鼓勵探索,而後續使用才會揭示反覆出現的優勢與弱點。持續採用是有用證據,但單憑持續採用仍不足以證明質素或整體節省的時間。
現時沒有依據可聲稱 Utah 經歷了 METR 較早實驗量度到的減速。同樣地,也幾乎沒有依據可聲稱 Utah 報告的節省已解決更廣泛的生產力爭論。證據支持較狹義的判斷:這個州的案例值得關注,而其報告的成果需要審慎解讀。
這個立場對開發人員與採購方同樣重要。誇大的說法可能對工作量及人手編制造成不切實際的期望。低估可信的使用者經驗,則可能妨礙有用的採用。健全的評估應為實驗保留空間,同時要求與重大採購及交付決策相稱的證據。
最有力的下一份報告,應把開發人員經驗、獲接納的變更、審核工作量及其後的維護工作連結起來。它亦應說明參與者如何被選出,以及時間如何估算。這些補充將有助讀者判斷效益的規模,以及其出現所需的條件。
Utah 試點計劃後應留意甚麼
下一項有用證據,關乎持續採用、獲接納的工作成果,以及可重複的部署條件。
第一個訊號是評估群組以外的持續使用。在未來數月,讀者應留意 Utah 是否說明存取權限有否持續或擴展。有文件記錄的擴展,將更有力支持參與者及管理人員發現持久價值的看法。若未見擴展,則只會令問題仍未解決,而非自動證明失敗。
擴展的細節與其公告同樣重要。政府機構可擴大存取權限,同時將其限制於某些工作或環境。它們亦可根據試點計劃的經驗提供額外支援。這些決定將揭示有利的實驗結果如何轉化為實際營運政策。
持續使用亦應與強制參與區分開來。自願再次使用某項工具可反映其實用性,而機構推行則代表其可用性。兩者均不能獨立衡量交付表現。清晰的報告應識別存取權限、實際使用,以及分配予助理的工作有何改變。
第二個訊號是關於獲接納軟件變更的證據。讀者應留意涉及已完成工作、審核工作量、返工或維護的比較。若所報告的個人節省同時伴隨可接受的質素及較低的整體工作量,這類報告將強化相關論點。若額外核查抵銷了這些節省,則會削弱簡單的生產力主張。
可信的比較應說明工作選擇方式,以及任務之間的相關差異。它不應假定每項變更都具有相同難度,也應計入審核者及支援人員完成的工作。這些脈絡會令研究結果更容易轉移至其他政府團隊。
第三個訊號是採購及部署安排是否支持可重複的採用。採購方應留意清晰的訂購指引、合資格服務、獲批准環境及實際的行政控制措施。更大的清晰度將強化政府機構可以重現有用評估的論點。尚未解決的條件,則會令有關可及性的廣泛結論為時過早。
競爭性證據亦應納入同一評估。另一家供應商成功完成的評估,會為政府機構提供更多選擇,但不會抹去 Utah 使用 Claude Code 的報告經驗。有用的比較應檢視相似的工作及要求,讓採購方找出影響自身運作的差異。
隨著政府機構走出試點階段,知識延續性亦值得關注。開發人員需要可存取的需求說明、過往決策及現有系統資訊。當這些脈絡可用時,編碼助理的輸出會更容易評估。因此,工具評估亦應涵蓋開發人員所依賴資訊的狀況。
對於檢視這些支援工作的小組而言,可搜尋的知識庫提供了整理技術文件的相關視角。文件存取與編碼輔助處理的是開發工作的相連部分。兩者都不能免除員工核查建議變更是否符合系統的需要。
應將 Claude Code Utah 試點計劃視為檢視特定工作流程的邀請,而非人手編制公式。先從開發人員認為有所改善的工作開始,再追問審核及交付期間發生了甚麼。保留他們的回饋,同時參照有關獲接納工作及持續維護的證據。對採購方而言,最有用的後續工作,是在不把這些元素濃縮成單一標題百分比的前提下將它們連結起來。在延長類似試驗前,先界定哪些結果可證明應繼續提供存取權限,哪些結果則需要作出調整。然後保留足夠脈絡以解釋結果。甚麼證據可證明節省下來的開發人員時間,已轉化為貴機構所交付軟件中可靠的改善?



