谷歌團隊埋頭研究1年=Claude Code 1小時？Gemini API負責人大贊競品，卻引程序員破防

編譯 | 蘇宓

出品 | CSDN（ID：CSDNnews）

新年伊始，科技圈因為一場關于 AI 編程能力的問題“吵翻了天”。

事情起因是 1 月 3 日， 谷歌首席工程師 Jaana Dogan 在社交平臺上公開“夸起了自己 Gemini 的競品”。她曬出的經歷堪稱“降維打擊”：谷歌團隊吭哧吭哧干了一年的工作成果，結果 Anthropic 的 Claude Code 只用 1 小時就拿出了方向一致的方案。

Jaana Dogan 還直言：“我不是在開玩笑，這一點也不好笑。”

此番言語一出，Reddit、Hacker News 上的開發者直接炸了鍋，有人贊同表示，“AI 編程要革傳統開發的命”，也有人深度質疑：“確認這對比真的沒水分？”

用三段提示，1 小時追上 1 年研究進度？

如果說這話出自一位普通工程師，或許并不能掀起多大風浪，但讓人不可置信的是，Jaana Dogan 也負責谷歌 Gemini API 的開發工作。

她在 X 上發帖表示，自己只是把問題描述丟給了 Claude Code，結果一個小時后拿到的方案，和團隊過去一年努力構建的方向幾乎一致。

要知道 Jaana Dogan 詢問 Claude Code 這個問題本身并不簡單，涉及的是“分布式智能體編排器”——也就是協調多個 AI 智能體協同工作的系統。

Dogan 透露，過去一年里，谷歌內部其實已經嘗試過不少思路，但一直沒能在方案上達成共識。

更讓網友驚訝的是，她給 Claude Code 的提示詞一點都不“復雜”。在評論區，當有人追問 “提示寫得有多詳細？更接近一個隨手的簡要說明，還是完整、正式的產品需求文檔？”，Jaana 回復得很實在：“提示詞非常簡略，因為不能用公司內部信息，我當時正在基于一些現有想法構建一個玩具版本，用來評估 ClaudeCode。提示詞只有三段。”

當然，結果也不是一步到位。Dogan 坦言，生成的方案還不完美，需要進一步打磨。她給“代碼智能體懷疑論者”的建議是：「不妨先在自己非常熟悉、判斷力最強的領域試一試，感受一下它們到底能做到什么程度。」

爭議四起：谷歌為什么不用自家工具？AI 編程是否存在“水分”？

看到 Jaana 的帖子，許多用過 AI 編程工具的程序員觀點不一，評論區也立刻分成了“三派”，吵得不可開交。

觀點一：“這算不算是谷歌被競品‘打臉’了？”

不少網友質問道：“你們自家有 Gemini，為什么不用它測？Gemini 什么時候能做到這水平？”、“谷歌工程師使用競爭對手的 LLM 而不是他們自己的內部 LLM，這難道不更能說明問題嗎？”

Jaana 倒是沒回避這些犀利的提問，其直接回應：“我們正在全力推進，不管是模型本身，還是配套的工程體系，都在趕。”

此外，當被問到谷歌內部是否在使用 Claude Code 時，Dogan 表示，目前只允許用于開源項目，不能用于公司內部開發。

她還補充說，這個行業從來都不是零和博弈，該給競爭對手的肯定就要給。“Claude Code 的確做得很出色，這讓我既興奮，也更有動力去推動大家一起往前走。”

觀點二：“1 小時 vs 1 年，是不是太夸張了？”

這也是爭議最大的點，如果 AI 能做到這種程度，工程師、開發者、程序員的未來該怎么辦？

對此，有開發者覺得“數據不對勁”，質疑 “過去一年，難道谷歌團隊都在‘摸魚’？”

也有程序員覺得：“它生成的代碼（Svelte、TypeScript、Python）通常充滿了小錯誤、過時用法、重復實現，還有糟糕的模塊劃分。這是 Opus 4.5 的表現。老實說，如果我每次不仔細審查并徹底修改，它都會變成一座難以調試的技術債務大山。說實話，這是否真的比手工寫更快，還很難說。我覺得，人們把對這項技術的期望當作已經實現的現實來表達，這種現象本身就非常有意思。”

還有人認為 Jaana 這番公開的夸贊似是在否定人類工程師的價值：

「我對這些說法深表懷疑。

每次有人說“AI 一小時就完成了我們花了一年的工作”，他們真正的意思其實是：人類花了一年時間做了艱難的思考，而 AI 只是以硅速度把這些內容復述了一遍。這當然和真正的生產力完全不同。

而且，如果你的團隊真的花了一年時間完成，那更多說明的是你們的流程問題，而不是 AI 的問題。但這并不會威脅到我的世界觀——只是以另一種方式，更安全的方式提醒你。

要明確一點：寫代碼是最簡單的部分。真正的工作是開會、達成共識、進行架構討論、整理 Jira 任務，以及在 snake_case 和 camelCase 之間做道德斗爭。Claude 并沒有做這些。因此它實際上什么也沒做。

我個人花了多年時間培養直覺、判斷力和審美。這些東西無法被自動化，除了顯然可以被一個在我堅持認為“微妙”的領域不斷超越我的概率文本模型所取代。

當然，輸出可以運行，當然，它可以通過測試，當然，它可以替代數月的工作。但它根本不理解自己在做什么。不同于我，我至少完全理解自己從 Stack Overflow 上復制的東西。

另外，我去年試過 AI，它曾出現過一次幻覺，所以我斷定整個領域已經永久達到瓶頸。眾所周知，技術在早期糟糕的演示之后通常不會再進步。

總之，我仍然毫不擔心。如果 AI 真有那么強大，它早就讓我變得無關緊要了，但我現在還有工作，所以這一切肯定都是炒作。證畢。

現在請原諒，我得花整個下午解釋，為什么一個剛剛讓人類一年努力白費的工具，不過是“自動補全”。」

面對“AI 用1 小時 vs 人類工程師耗費 1 年”所帶來的巨大落差爭議，Jaana 隨后專門發了系列帖子補充項目背景情況，她表示：

“為了在這個話題上理清思路，提供更多背景會很有幫助：去年我們已經構建了這個系統的幾個版本。每種方案都有優缺點，沒有明確的贏家。

• 當用存活下來的最佳思路對 AI 工具進行提示時，編碼智能體能夠走得很遠，大約一小時就能生成一個相當不錯的‘玩具版’。

• 現在用你的知識重新構建它完全很容易，而這在過去是不可能的。

• 組織慣性確實存在，但在大公司里構建適用于多種使用場景的基礎設施也非常困難。

• 將想法落地到產品并形成可長期沿用的模式需要數年時間。

• 一旦你擁有了這些洞察和知識，實際構建就沒那么難了。因為可以從零開始構建，最終產物不會帶有歷史包袱。”

而針對“AI 生成方案是否等于產品”的疑問，她反駁道：“構建第一個版本不等于構建產品。”

Jaana 表示，“我這個周末做的這個還不是量產級的，只是個玩具版本，不過是個很有用的起點。最終成品的質量讓我很驚喜，因為我并沒有深入探討設計選擇，但 CC 還是給了我一些不錯的建議。”

即便如此，依然有網友認為她起初的說法夸張——“Claude Code 用 1 個小時就搞定了團隊過去一年的摸索方向”，對此，Jaana 進一步解釋：“并不完全是這樣。它是從非常簡略的描述中抓住了正確的設計選擇。過去的 12 個月，我們主要是在驗證各種方案。最終，我知道理想的架構模式，但它能夠在沒有指令的情況下提出這個方案。”

觀點三：“AI 編程到底是革命，還是炒作？”

針對這一點，Jaana 自己都感慨：“自從開始從事編程語言相關工作以來，我還從未在開發者社區里見過如此兩極分化的反應。圍繞編碼智能體有大量的炒作和空洞宣傳，不幸的是，這些聲音常常淹沒了真正踏實、有價值的工作。事情本不必如此對立。”

對于 AI 編程目前的進展，Jaana 表示：“我們仍處在一個階段，這可以被視作整個行業范圍內的研究項目。語言模型仍在不斷探索和優化。我們會在看到價值的地方投入生產化，這也幫助我們進行更多探索。

三四年前，我曾考慮過退休，因為整個行業看起來已經過于飽和。幾乎沒有真正新的東西可供開發了。作業調度器、網絡接口……我們實際上是在重新造已經造過的東西，只是帶來了更多復雜性。

我很喜歡這個領域帶給我們的新鮮感，為像我這樣的工程師提供了一條不同尋常的探索之路。大型語言模型過于迅速地變得觸手可及，也因此引發了強烈的反應。但在此之前，有一小群人帶著好奇心探索這些模型。我懷念那些歲月。”

與此同時，Jaana 還回顧了 AI 輔助編程這幾年的飛速演進：

• 2022 年，系統只能補全單行代碼；

• 2023 年，可以處理一整段邏輯；

• 2024 年，已經能跨多個文件工作，甚至搭出簡單應用；

• 到了 2025 年，它們已經可以創建、重構完整的代碼庫。

她坦言，早在 2022 年時，自己根本不相信“2024 年這個階段”能真正規模化，成為面向全球開發者的產品；而在 2023 年看來，如今的水平至少還要五年才能實現。

“這個領域在質量和效率上的提升，已經遠遠超出了任何人的想象。”她寫道。

Jaana 還說道，從傳統工程轉向機器學習的過程，本身就充滿了挑戰：“從傳統工程轉向機器學習，需要調整心態，并適應累積的不確定性。當你意識到收益與損失不再遵循常規趨勢，短時間內就可能出現重大回退時，文化沖擊便隨之而來。打造出色的產品需要專注、奉獻、近乎癡迷的投入，一支相對志同道合的優秀團隊，以及對行業混亂本質的保護。優秀的產品就像獨角獸一樣稀有。”

她還吐槽了行業現狀：“在這個行業里，大多數開發者能夠真正推動事情發生的日子已經很久遠了。復雜性和繁文縟節讓摩擦極高，整個行業能持續運轉本身就是一個奇跡。我們不能總是要求人們在不斷應對沖突和處理爭議的情況下保持 100% 的產出。你要么有效地消除爭議并開辟新的空間，要么最終只能淘汰人手。總有東西會出問題。”

AI 編程帶來的效率提升，讓不少人深有感受。Jaana 直言：“關于編碼智能體的所有爭議，只是一個表象。自始至終，行業現狀和就業市場的狀況才是根本問題。”也正因為這種效率和潛力，引發了更多人對 Claude Code 本身實際表現的興趣——不僅僅是“玩具版”的測試，還有它在真實工程環境中的生產力。

Claude Code 作者的實戰心得

有意思的是，不久之前，Claude Code 的創造者 Boris Cherny 在 X 上分享了自己過去一個月使用 CC 的真實生產數據：

2024 年 9 月，我把 Claude Code 當作一個業余項目創建出來時，完全沒有想到它會發展到今天這樣的規模。看到 Claude Code 成為如此多工程師的核心開發工具，看到社區所展現出的巨大熱情，以及人們將它用于從編程、運維、科研到非技術場景的各種用途，這讓我感到既謙卑又震撼。這項技術既陌生又充滿魔力，它極大地降低了人們構建和創造的門檻。越來越多的情況下，代碼本身已經不再是瓶頸。

在過去 30 天里，我合并了 259 個 PR —— 共 497 次提交，新增約 4 萬行代碼，刪除約 3.8 萬行代碼。而且，每一行代碼都是由 Claude Code + Opus 4.5 編寫的。Claude 可以穩定地持續運行數分鐘、數小時，甚至數天（借助 Stop hooks）。

而近日就在 Jaana 發帖差不多同一時間，Boris Cherny 也公開了自己的使用經驗，希望給正在使用 Claude Code 的開發者帶來參考：

我的配置可能會讓你覺得很“普通”！Claude Code 開箱即用效果就很好，所以我個人幾乎不做自定義。使用 Claude Code 并沒有唯一正確的方式：我們故意把它設計成你可以隨意使用、定制，甚至自由改造。Claude Code 團隊的每個人用法都各不相同。

那我直接說說我的做法吧：

1. 我在終端里同時運行 5 個 Claude。我給標簽頁編號 1–5，并用系統通知來知道哪個 Claude 需要輸入。https://code.claude.com/docs/en/terminal-config-2-system-notifications

2. 我也會在 http://claude.ai/code 上同時運行 5–10 個 Claude，與本地的 Claude 并行。當我在終端寫代碼時，經常會把本地會話交給網頁端（用 &），或者手動在 Chrome 中啟動新會話，有時我會在兩者之間“瞬移”。每天早上和工作中，我也會用手機（Claude iOS 應用）啟動幾個會話，并稍后查看。

3. 我用 Opus 4.5 并開啟思考模式處理所有事情。這是我用過的最強大的編程模型。雖然它比 Sonnet 更大、更慢，但因為需要干預更少、工具使用能力更強，最終效率通常比用小模型更高。

4. 我們團隊共享一個 Claude Code 倉庫的 http://CLAUDE.md。我們會將它提交到 git，團隊每周多次貢獻內容。每當發現 Claude 做錯事情，我們就記錄到 http://CLAUDE.md，這樣 Claude 下次就不會再犯同樣錯誤。其他團隊會維護自己的 http://CLAUDE.md，每個團隊都有責任保持文件更新。

5. 代碼審查時，我經常在同事的 PR 上標記 @.claude，把需要記錄的內容加入 http://CLAUDE.md。我們使用 Claude Code 的 Github Action（/install-github-action）來操作。這是我們對 @danshipper 的 Compounding Engineering 的一種實現方式。

6. 大多數會話從 Plan 模式開始（shift+tab 兩次）。如果我的目標是寫一個 Pull Request，我會先用 Plan 模式，并和 Claude 反復確認計劃直到滿意。然后我切換到自動接受修改模式，Claude 通常可以一次性完成。一個好的計劃非常重要！

7. 我對每天會多次執行的“內部循環”工作流都會使用斜杠命令（slash commands）。這樣可以避免重復提示，也讓 Claude 能夠使用這些工作流。命令會提交到 git，保存在 .claude/commands/ 下。例如，Claude 和我每天會用 /commit-push-pr 斜杠命令幾十次。這個命令用內聯 bash 預先計算 git status 和其他一些信息，使命令運行快速，并避免和模型來回交互（https://code.claude.com/docs/en/slash-commands-command-execution）。

8. 我還經常使用一些子智能體：code-simplifier 會在 Claude 完成工作后簡化代碼，verify-app 有詳細說明用于端到端測試 Claude Code，等等。和斜杠命令類似，我把子智能體看作是自動化我大多數 PR 中最常用的工作流。

9. 我們使用 PostToolUse hook 來格式化 Claude 生成的代碼。Claude 通常開箱就能生成格式良好的代碼，hook 處理最后 10%，避免 CI 中出現格式錯誤。

10. 我不使用 --dangerously-skip-permissions。相反，我用 /permissions 預先允許一些我確認在環境中安全的常用 bash 命令，避免不必要的權限提示。這些設置大多記錄在 .claude/settings.json，并與團隊共享。

11. Claude Code 會替我使用所有工具。它經常會在 Slack 上搜索和發消息（通過 MCP 服務器）、運行 BigQuery 查詢以回答分析問題（使用 bq CLI）、從 Sentry 獲取錯誤日志等。Slack MCP 配置提交在 .mcp.json，團隊共享。

12. 對于耗時很長的任務，我會采取以下做法：

    (a) 任務完成后，用后臺智能體提示 Claude 驗證其工作；

    (b) 使用 agent Stop hook 更確定性地完成驗證；

    (c) 使用 ralph-wiggum 插件（最初由 @GeoffreyHuntley 想出的）。

    我還會在沙箱環境中使用 --permission-mode=dontAsk 或 --dangerously-skip-permissions 來避免權限提示，讓 Claude 可以自由運行而不被我阻擋。

13. 最后一個提示：想要從 Claude Code 得到優秀結果，最重要的事情之一就是——給 Claude 一種驗證其工作的方式。如果 Claude 有這個反饋回路，最終結果的質量可以提升 2–3 倍。

Claude 會用 Claude Chrome 擴展測試我提交到 http://claude.ai/code 的每一處修改。它會打開瀏覽器、測試 UI，并不斷迭代，直到代碼可用且用戶體驗良好。

不同領域的驗證方式會有所不同。可能只是運行一個 bash 命令，或者運行測試套件，或者在瀏覽器或手機模擬器中測試應用。務必投入精力，確保這個驗證過程非常可靠。

來源：https://x.com/bcherny/status/2007179861115511237

事實上，隨著 AI 輔助編程能力快速提升，人類工程師的角色也在悄然發生變化。當 AI 能在短時間生成可運行方案時，人類在決策、架構判斷和團隊協作中的邊界該如何界定？這不僅是技術問題，也涉及組織和管理，每一位開發者、管理者乃至研究者都值得認真思考。

https://x.com/rakyll/status/2007735665023488236

https://x.com/bcherny/status/2007179861115511237

https://the-decoder.com/google-engineer-says-claude-code-built-in-one-hour-what-her-team-spent-a-year-on/