譯者 | 核子可樂

審校 | 重樓

Claude 4甫一亮相，市場就被其強大的推理和編程能力折服。但在連續使用數月之后，我意識到大模型真正的革命不在于生成更好的代碼片段，而是其中蘊藏的自主性潛力。

很多人更多關注AI編程的語法正確性、基準測試得分和代碼有效率，但我在對Claude 4的實際測試中體會到：能夠全面理解開發目標、持續尋求解決方案并自主克服障礙的AI系統正在出現。

不同于常規的基準測試，我通過一項真實開發任務來評估Claude 4的自主能力：構建一款與OpenAI API集成的OmniFocus功能插件。這項任務不僅需要編寫代碼，還要求理解文檔、處理錯誤、提供連續的用戶體驗并切實解決問題。這里考察的不只是語法正確性，更需要主動探索與持續推進。

正是這種對自主能力的感受，讓我意識到開發者與AI系統的協作方式即將徹底改變。

三種模型，三種自主方式

Opus 4：不止于代碼生成，走向合作開發

在使用Opus 4的過程中，我意識到與之前擅長根據特定指令生成代碼片段的AI系統不同，Opus 4表現出真正的開發自主性——獨立推動開發進程，最終找到可行的解決方案。

在遇到數據庫錯誤時，Opus 4不僅修復了相應代碼，還主動給出根本原因：

“我發現問題了——OmniFocus插件需要使用Preferences API進行持久存儲，而非直接訪問數據庫。我可以協助解決這個問題。”

之后它用OmniFocus的Preferences API實現了一套完整的解決方案。

這就是代碼生成和智能體間的核心差異。代碼生成器只是輸出代碼形式的文本，而智能體可以理解開發環境、發現問題，并在更廣泛的應用需求框架內解決現實問題。

最讓我印象深刻的，則是Opus 4如何在需求之外自主增強以下功能：

• 用于API設置的配置界面；
• 用于調試的詳細錯誤消息；
• 用于防止無效請求的輸入驗證；
• API調用期間的進度指示器。

Opus 4對于良好開發者體驗明顯有自己的理解，這是傳統代碼生成工具所不可能實現的。

Sonnet 4：謹慎的協作者

Sonnet 4同樣展現出強大能力，但需要指引才能進一步發揮潛力。它的交互感受像是一位能力出眾但謹慎的開發者，需要我定期檢查。它對任務需求的理解效果不錯，但在API集成中犯了一些小錯誤。對此，Sonnet 4提出了一些需要澄清的問題：

“我注意到OmniFocus采取一種特殊的HTTP請求處理方式，能否向我提供它的URL獲取功能說明文檔？”

在收到提示后，它成功修復了問題，不過仍經歷了七到八次迭代才給出完全可行的解決方案。

有趣的是，Sonnet 4曾做出意想不到的判斷——在與OpenAI集成遇到困難時，它建議暫時移除該功能，轉而使用本地分析。這體現出它完成任務的強烈意愿，甚至不惜為此調整對原始需求的遵循。

體驗Sonnet 3.7：響應式工具

Sonnet 3.7給我的感覺像是一款編程助手。它需要明確的指令，且很難與我正在構建的內容保持更廣泛的上下文關聯。

典型的交流過程如下：

• 我：“此插件需要將任務轉換為TaskPaper格式，再將結果發送至OpenAI。”
• Sonnet 3.7: “我將建立一條將任務轉換為TaskPaper格式的函數。” [實現基本功能，但未提供錯誤處理。]
• 我：“現在我們需要實現Open API集成。”
• Sonnet 3.7: [實現基本API調用，但未提供錯誤處理或用戶反饋機制
• 在遇到錯誤時，Sonnet 3.7也很難獨立完成錯誤診斷：
• 我：“我收到「文件為目錄」的錯誤。”
• Sonnet 3.7: “很奇怪，但提供完整的錯誤信息嗎？”
• [我給出錯誤詳情。]
• Sonnet 3.7: “這可能與文件路徑有關。我來檢查一下插件的保存位置。”

經過10多次交互后，我仍未得到功能完備的插件成果。

智能體光譜：不止于高質量代碼

AI編程系統間的差異，已經不只體現在其生成正確代碼的能力，而更多表現為智能體水平——即在極少指導下理解并實現開發目標的能力。

根據我的測試，我整理出以下智能體光譜：

• 代碼生成器：根據特定提示詞生成有效代碼，但缺乏持久性和上下文理解能力。
• 響應式助手：生成可用代碼，但在開發各階段須明確指引，專注于即時指令而非整體目標。
• 協作型智能體：擁有較均衡的指令執行與主動性水平，可在定期指引下半自主工作，但可能需要隨時調整方向。
• 開發合作伙伴：將開發目標內化并堅持朝著目標努力，無需明確指引即可主動識別并解決問題。

由此可見，對AI編程系統的評估方式將發生徹底轉變——不只是代碼質量，而是其在實際開發環境中自主解決問題的能力。

對開發實踐有何影響？

具備智能體水平的AI系統對于開發工作流程有著深遠影響：

從微指令到開發目標

代理式AI系統的有效協作，標志著從分步提示轉化為更高層次的開發目標和背景。我給Opus 4的指令如下：

“構建一款插件，將OmniFocus任務發送給OpenAI進行分析和匯總。此插件應可優雅處理錯誤并提供良好的用戶體驗。”

只需這種宏觀指引，它就能構建起完整的解決方案——早期代碼生成系統則完全不具備此等能力。

超越token計數：一種新的經濟模式

Claude 4模型的智能體模式為成本效益分析開辟了新的維度。雖然Opus 4的單token成本更高（輸入/輸出分別為15/75美元，Sonnet 4則為3/15美元），但其自主尋求解決方案的能力顯著減少了實際交互次數。

Opus 4需要3到4次交互的任務，在Sonnet 3.7上往往需要10次以上，效率的提升抵消了相對更高的每token成本。更重要的是，這節約了開發者的時間和認知負擔，大大改善了工作體驗。

調整開發流程，適應AI智能體

隨著AI系統展現出真正的智能體能力，開發流程也將隨之演變。也許未來的AI系統不僅能生成代碼，還能處理實施規劃、錯誤診斷和質量保證，確保開發者集中精力應對：

• 架構與系統設計；
• 目標與質量標準制定；
• 對AI生成方案進行批判性評估；
• 軟件開發的人性化與倫理問題。

AI并不是要取代開發者，而是幫助開發者邁向更高層次的指導和監督角色。

未來之路：超越現有一切

AI智能體的快速發展呈現出以下幾大趨勢：

• 智能體專用開發系統：未來的AI系統可能專門針對開發需求而生，為不同開發領域建立專門的合作伙伴。
• 新的協作界面：現有聊天界面尚未針對開發協作做出優化。未來AI系統或將擁有更強調其自主性的工具，可探索代碼庫、運行測試并提出一致的解決方案。
• 持續發展的評估框架：智能體的成熟要求以新的方法評估AI系統，更多關注其理解和實現開發目標的能力。
• 組織適應：開發團隊需要重新審視如何整合AI智能體，創造出專注于指導和評估AI貢獻的全新職能角色。

智能體：新的前沿

大模型的發展代表著AI編程系統迎來重要里程碑，特別是其對于人機開發關系的顛覆。

我個人從測試中得到的重要啟示在于，AI前沿已經從“能否編寫出正確代碼”轉為“能否理解開發者的實現意圖”。新模型表明，我們正邁入AI系統成為真正開發伙伴、而非復雜代碼生成工具的偉大時代。

原文標題：The shift from AI code generation to true development partnership，作者：Jenil Shah