從 X 上的熱推：Google 使用 Claude Code 開發來看背後的故事

大家永遠只想看到自己想看到的點

謎之音：X 的短文本質上就是一種 compact ，所以 context 就會流失，所以才會造成這種接龍回文的方式解釋和筆戰

這是這幾天戰成一片的推文，Google 首席工程師 Jaana Dogan（網名 @rakyll）提到她使用 Anthropic 的開發工具「Claude Code」重現了團隊一年的工作成果。

「我們團隊去年整整一年都在開發一套『分散式 Agent 編排系統』，試了各種方案、歷經各種分歧，始終沒有定論。結果我把問題描述丟給 Claude Code，它竟然在一個小時內就生成了我們去年做出來的東西。」

這則推文瞬間引爆討論，有趣的是，每個人都從中看到了自己想看到的「真相」：

• 有人說是大公司病的鐵證：一年的工作量一小時就能做完，可見組織效率有多低落。

• 有人說是 Claude Code 的封神時刻：連 Google 自家的首席工程師都在用競品。

• 當然也有人恐慌：工程師要失業了，AI 已經能取代整個團隊。

這些解讀都只對了一半，卻漏掉了最關鍵的脈絡，所以 Janna 接著跳出來解釋...

首先團隊在這一年內其實建構了好幾個版本的系統，各有優優缺點，但一直無法達成內部共識。

然後所謂她餵給 Claude 的 Prompt，其實是濃縮了「最終存活下來的最佳構想」：這是一整年的探索、試錯、淘汰後，提煉出的精華，被壓縮進了三段話裡。

最後，Claude 生成的其實是一個「Toy Version」，並非可直接上線的生產級代碼，但作為一個起點已經相當驚人。 （謎之音：公關有交代還是要推廣自家的產品 ?)

所以這並不是 AI or Claude code 超強憑空創造奇蹟，而是一位專家帶著累積了一年的研究成果，利用 AI 快速將「想法」轉化為「代碼」。

那一年時間到底花去哪了？

我們習慣用「產出」來衡量工作價值：寫了幾行 Code、上了幾個功能、迭代了幾個版本。但如果這些產出能被一小時復現，那之前一年的工作難道都是虛工？

其實，團隊這一年主要在做三件事：

• 探索（Exploration）： 分散式 Agent 編排沒有標準答案。要嘗試不同的架構、通訊機制、容錯策略。絕大部分的嘗試會失敗，但這些失敗是必要的學費。

• 驗證（Verification）： 想法要落地，得跑起來看效果。有些極端狀況只有在真實負載下才會暴露。這個過程漫長、枯燥且充滿意外。

• 對齊（Alignment）： Jaana 提到 “not everyone is aligned”。

待過大廠的朋友都知道，在大公司裡，要讓不同團隊、不同利益方、不同技術偏好的人達成共識，往往比寫程式難上十倍。開會、寫文件、說服、妥協、再開會——這些過程不產生程式碼，卻消耗大量時間與精力。

（謎之音：對齊這才是最痛苦的！！）

Claude 負責的，只是最後那個「建造」的動作。而前期的認知勞動、探索、驗證與溝通對齊，其實都是人完成的。

這就像軟體專案，我們不能只盯著寫程式的那段時間。前期的需求分析、系統設計，後期的整合測試都佔據大量時間。只是因為以前「寫程式」成本高，大家容易忽略其他環節的隱形成本。現在 AI 讓寫程式變快了，才凸顯出其他工作的價值。

瓶頸轉移：從「怎麼做」到「要什麼」

Jaana 還說了一段話，我認為這才是整個故事最重要的部分：

「你需要花好幾年去學習、在真實產品中驗證想法、找到能長期適用的 Patterns。一旦你有了這些 Insight 和知識，構建本身就不難了。因為你可以從零開始建，最終產物反而沒有歷史包袱。」

最終你能不能把這個知識和 Insight 外顯成 prompt or Skill?

過去，瓶頸在於「怎麼實現」（How）。你想清楚要什麼了，但從想法到代碼之間隔著漫長的工程實作：招募（搶錢、搶糧、搶人）、分工、排程、開發、測試、串接。

有興趣可以參考以前文章，DevOps HandBooks - 第二章 The First Way 流程的原則 - 阿貝好威的實驗室 https://share.google/9Y8T2FDDH576bKPec

現在，這個瓶頸正在消失。新的瓶頸變成了「想清楚要什麼」（What）。你的 Prompt 能不能精準描述問題？能不能包含正確的約束條件？能不能符合你認知的 Trade-off 的判斷？

有人將此稱為從「實作」到「表達」的轉移。以前「會做這件事」的人值錢，現在「能說清楚要做什麼」的人更值錢。

Jaana 的 Prompt 之所以有效，是因為她確實懂這個領域。換一個不懂的人，給 Claude 同樣篇幅的三段話，大概率是跑不出能用的東西。AI 放大的是你已有的認知，而不是憑空給你認知。

當「執行」變便宜了，什麼東西反而變貴了？

• 判斷力： 面對十個可行方案，該選哪個？AI 能幫你生成方案，但決策需要對業務的理解、對用戶的洞察、對技術趨勢的預判，這些仍然高度依賴人。

（謎之音：現在真的會有種決策疲勞和癱瘓）

• 品味（Taste）： 同樣是能跑的程式，好 Code 和爛 Code 差距巨大。可維護性、擴充性、優雅程度——AI 能寫程式，但「什麼是好程式」的標準，需要人來定義與堅持。

• 對問題的深刻理解： 表面上是技術問題，底層往往是業務問題、組織問題，甚至是辦公室政治問題。能穿透表象看到本質的人，永遠稀缺。

AI 時代：個體與小團隊的機會

這個故事還有一個潛台詞：大公司的「對齊成本」被 AI 無情放大了，可以參考之前的文章「大規模敏捷開發？ 讓我們先來談談跨國大型軟體開發的日常挑戰 」 https://share.google/SeI944SqypJrr2zhS

跨國大公司通常靠人海戰術堆疊執行力，用流程保證品質。小團隊資源有限，很難在複雜專案上與之競爭。

前 Google 與 Meta Distinguished Engineer、Gemini 大模型的共同作者 Rohan Anil 也在底下留言：

「如果我當年能擁有 Coding Agent，特別是像 Opus 這種等級的模型，我不僅能省下職業生涯前 6 年的時間，甚至能把這些工作量壓縮到短短幾個月內完成。」

現在，執行力可以靠 AI 補齊。小團隊的優勢——決策快、包袱輕、方向調整靈活——反而變成了真正的護城河。一個人想清楚了，一小時就能出原型；一百個人沒想清楚，開一年會也對不齊。

這對個體來說是好消息。你的判斷力、學習能力、對問題的理解深度，正在成為 AI 時代真正的競爭力。

AI 沒有讓工程師貶值，但 AI 時代對工程師的要求，確實已經不一樣了。

謎之音：以前在大公司都說光是開會沒時間寫程式，現在有更多時間去吵架（對齊）