編譯 | 蘇宓

出品 | CSDN（ID：CSDNnews）

新年伊始，科技圈因?yàn)橐粓?chǎng)關(guān)于 AI 編程能力的問(wèn)題“吵翻了天”。

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

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

此番言語(yǔ)一出，Reddit、Hacker News 上的開發(fā)者直接炸了鍋，有人贊同表示，“AI 編程要革傳統(tǒng)開發(fā)的命”，也有人深度質(zhì)疑：“確認(rèn)這對(duì)比真的沒(méi)水分？”

用三段提示，1 小時(shí)追上 1 年研究進(jìn)度？

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

她在 X 上發(fā)帖表示，自己只是把問(wèn)題描述丟給了 Claude Code，結(jié)果一個(gè)小時(shí)后拿到的方案，和團(tuán)隊(duì)過(guò)去一年努力構(gòu)建的方向幾乎一致。

要知道 Jaana Dogan 詢問(wèn) Claude Code 這個(gè)問(wèn)題本身并不簡(jiǎn)單，涉及的是“分布式智能體編排器”——也就是協(xié)調(diào)多個(gè) AI 智能體協(xié)同工作的系統(tǒng)。

Dogan 透露，過(guò)去一年里，谷歌內(nèi)部其實(shí)已經(jīng)嘗試過(guò)不少思路，但一直沒(méi)能在方案上達(dá)成共識(shí)。

更讓網(wǎng)友驚訝的是，她給 Claude Code 的提示詞一點(diǎn)都不“復(fù)雜”。在評(píng)論區(qū)，當(dāng)有人追問(wèn) “提示寫得有多詳細(xì)？更接近一個(gè)隨手的簡(jiǎn)要說(shuō)明，還是完整、正式的產(chǎn)品需求文檔？”，Jaana 回復(fù)得很實(shí)在：“提示詞非常簡(jiǎn)略，因?yàn)椴荒苡霉緝?nèi)部信息，我當(dāng)時(shí)正在基于一些現(xiàn)有想法構(gòu)建一個(gè)玩具版本，用來(lái)評(píng)估 ClaudeCode。提示詞只有三段?！?/p>

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

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

看到 Jaana 的帖子，許多用過(guò) AI 編程工具的程序員觀點(diǎn)不一，評(píng)論區(qū)也立刻分成了“三派”，吵得不可開交。

觀點(diǎn)一：“這算不算是谷歌被競(jìng)品‘打臉’了？”

不少網(wǎng)友質(zhì)問(wèn)道：“你們自家有 Gemini，為什么不用它測(cè)？Gemini 什么時(shí)候能做到這水平？”、“谷歌工程師使用競(jìng)爭(zhēng)對(duì)手的 LLM 而不是他們自己的內(nèi)部 LLM，這難道不更能說(shuō)明問(wèn)題嗎？”

Jaana 倒是沒(méi)回避這些犀利的提問(wèn)，其直接回應(yīng)：“我們正在全力推進(jìn)，不管是模型本身，還是配套的工程體系，都在趕?！?/p>

此外，當(dāng)被問(wèn)到谷歌內(nèi)部是否在使用 Claude Code 時(shí)，Dogan 表示，目前只允許用于開源項(xiàng)目，不能用于公司內(nèi)部開發(fā)。

她還補(bǔ)充說(shuō)，這個(gè)行業(yè)從來(lái)都不是零和博弈，該給競(jìng)爭(zhēng)對(duì)手的肯定就要給?！癈laude Code 的確做得很出色，這讓我既興奮，也更有動(dòng)力去推動(dòng)大家一起往前走?！?/p>

觀點(diǎn)二：“1 小時(shí) vs 1 年，是不是太夸張了？”

這也是爭(zhēng)議最大的點(diǎn)，如果 AI 能做到這種程度，工程師、開發(fā)者、程序員的未來(lái)該怎么辦？

對(duì)此，有開發(fā)者覺(jué)得“數(shù)據(jù)不對(duì)勁”，質(zhì)疑 “過(guò)去一年，難道谷歌團(tuán)隊(duì)都在‘摸魚’？”

也有程序員覺(jué)得：“它生成的代碼（Svelte、TypeScript、Python）通常充滿了小錯(cuò)誤、過(guò)時(shí)用法、重復(fù)實(shí)現(xiàn)，還有糟糕的模塊劃分。這是 Opus 4.5 的表現(xiàn)。老實(shí)說(shuō)，如果我每次不仔細(xì)審查并徹底修改，它都會(huì)變成一座難以調(diào)試的技術(shù)債務(wù)大山。說(shuō)實(shí)話，這是否真的比手工寫更快，還很難說(shuō)。我覺(jué)得，人們把對(duì)這項(xiàng)技術(shù)的期望當(dāng)作已經(jīng)實(shí)現(xiàn)的現(xiàn)實(shí)來(lái)表達(dá)，這種現(xiàn)象本身就非常有意思。”

還有人認(rèn)為 Jaana 這番公開的夸贊似是在否定人類工程師的價(jià)值：

「我對(duì)這些說(shuō)法深表懷疑。

每次有人說(shuō)“AI 一小時(shí)就完成了我們花了一年的工作”，他們真正的意思其實(shí)是：人類花了一年時(shí)間做了艱難的思考，而 AI 只是以硅速度把這些內(nèi)容復(fù)述了一遍。這當(dāng)然和真正的生產(chǎn)力完全不同。

而且，如果你的團(tuán)隊(duì)真的花了一年時(shí)間完成，那更多說(shuō)明的是你們的流程問(wèn)題，而不是 AI 的問(wèn)題。但這并不會(huì)威脅到我的世界觀——只是以另一種方式，更安全的方式提醒你。

要明確一點(diǎn)：寫代碼是最簡(jiǎn)單的部分。真正的工作是開會(huì)、達(dá)成共識(shí)、進(jìn)行架構(gòu)討論、整理 Jira 任務(wù)，以及在 snake_case 和 camelCase 之間做道德斗爭(zhēng)。Claude 并沒(méi)有做這些。因此它實(shí)際上什么也沒(méi)做。

我個(gè)人花了多年時(shí)間培養(yǎng)直覺(jué)、判斷力和審美。這些東西無(wú)法被自動(dòng)化，除了顯然可以被一個(gè)在我堅(jiān)持認(rèn)為“微妙”的領(lǐng)域不斷超越我的概率文本模型所取代。

當(dāng)然，輸出可以運(yùn)行，當(dāng)然，它可以通過(guò)測(cè)試，當(dāng)然，它可以替代數(shù)月的工作。但它根本不理解自己在做什么。不同于我，我至少完全理解自己從 Stack Overflow 上復(fù)制的東西。

另外，我去年試過(guò) AI，它曾出現(xiàn)過(guò)一次幻覺(jué)，所以我斷定整個(gè)領(lǐng)域已經(jīng)永久達(dá)到瓶頸。眾所周知，技術(shù)在早期糟糕的演示之后通常不會(huì)再進(jìn)步。

總之，我仍然毫不擔(dān)心。如果 AI 真有那么強(qiáng)大，它早就讓我變得無(wú)關(guān)緊要了，但我現(xiàn)在還有工作，所以這一切肯定都是炒作。證畢。

現(xiàn)在請(qǐng)?jiān)?，我得花整個(gè)下午解釋，為什么一個(gè)剛剛讓人類一年努力白費(fèi)的工具，不過(guò)是“自動(dòng)補(bǔ)全”?！?/p>

面對(duì)“AI 用1 小時(shí) vs 人類工程師耗費(fèi) 1 年”所帶來(lái)的巨大落差爭(zhēng)議，Jaana 隨后專門發(fā)了系列帖子補(bǔ)充項(xiàng)目背景情況，她表示：

“為了在這個(gè)話題上理清思路，提供更多背景會(huì)很有幫助：去年我們已經(jīng)構(gòu)建了這個(gè)系統(tǒng)的幾個(gè)版本。每種方案都有優(yōu)缺點(diǎn)，沒(méi)有明確的贏家。

• 當(dāng)用存活下來(lái)的最佳思路對(duì) AI 工具進(jìn)行提示時(shí)，編碼智能體能夠走得很遠(yuǎn)，大約一小時(shí)就能生成一個(gè)相當(dāng)不錯(cuò)的‘玩具版’。

• 現(xiàn)在用你的知識(shí)重新構(gòu)建它完全很容易，而這在過(guò)去是不可能的。

• 組織慣性確實(shí)存在，但在大公司里構(gòu)建適用于多種使用場(chǎng)景的基礎(chǔ)設(shè)施也非常困難。

• 將想法落地到產(chǎn)品并形成可長(zhǎng)期沿用的模式需要數(shù)年時(shí)間。

• 一旦你擁有了這些洞察和知識(shí)，實(shí)際構(gòu)建就沒(méi)那么難了。因?yàn)榭梢詮牧汩_始構(gòu)建，最終產(chǎn)物不會(huì)帶有歷史包袱?！?/p>

而針對(duì)“AI 生成方案是否等于產(chǎn)品”的疑問(wèn)，她反駁道：“構(gòu)建第一個(gè)版本不等于構(gòu)建產(chǎn)品。”

Jaana 表示，“我這個(gè)周末做的這個(gè)還不是量產(chǎn)級(jí)的，只是個(gè)玩具版本，不過(guò)是個(gè)很有用的起點(diǎn)。最終成品的質(zhì)量讓我很驚喜，因?yàn)槲也](méi)有深入探討設(shè)計(jì)選擇，但 CC 還是給了我一些不錯(cuò)的建議?！?/p>

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

觀點(diǎn)三：“AI 編程到底是革命，還是炒作？”

針對(duì)這一點(diǎn)，Jaana 自己都感慨：“自從開始從事編程語(yǔ)言相關(guān)工作以來(lái)，我還從未在開發(fā)者社區(qū)里見(jiàn)過(guò)如此兩極分化的反應(yīng)。圍繞編碼智能體有大量的炒作和空洞宣傳，不幸的是，這些聲音常常淹沒(méi)了真正踏實(shí)、有價(jià)值的工作。事情本不必如此對(duì)立?！?/p>

對(duì)于 AI 編程目前的進(jìn)展，Jaana 表示：“我們?nèi)蕴幵谝粋€(gè)階段，這可以被視作整個(gè)行業(yè)范圍內(nèi)的研究項(xiàng)目。語(yǔ)言模型仍在不斷探索和優(yōu)化。我們會(huì)在看到價(jià)值的地方投入生產(chǎn)化，這也幫助我們進(jìn)行更多探索。

三四年前，我曾考慮過(guò)退休，因?yàn)檎麄€(gè)行業(yè)看起來(lái)已經(jīng)過(guò)于飽和。幾乎沒(méi)有真正新的東西可供開發(fā)了。作業(yè)調(diào)度器、網(wǎng)絡(luò)接口……我們實(shí)際上是在重新造已經(jīng)造過(guò)的東西，只是帶來(lái)了更多復(fù)雜性。

我很喜歡這個(gè)領(lǐng)域帶給我們的新鮮感，為像我這樣的工程師提供了一條不同尋常的探索之路。大型語(yǔ)言模型過(guò)于迅速地變得觸手可及，也因此引發(fā)了強(qiáng)烈的反應(yīng)。但在此之前，有一小群人帶著好奇心探索這些模型。我懷念那些歲月?！?/p>

與此同時(shí)，Jaana 還回顧了 AI 輔助編程這幾年的飛速演進(jìn)：

• 2022 年，系統(tǒng)只能補(bǔ)全單行代碼；

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

• 2024 年，已經(jīng)能跨多個(gè)文件工作，甚至搭出簡(jiǎn)單應(yīng)用；

• 到了 2025 年，它們已經(jīng)可以創(chuàng)建、重構(gòu)完整的代碼庫(kù)。

她坦言，早在 2022 年時(shí)，自己根本不相信“2024 年這個(gè)階段”能真正規(guī)?；?，成為面向全球開發(fā)者的產(chǎn)品；而在 2023 年看來(lái)，如今的水平至少還要五年才能實(shí)現(xiàn)。

“這個(gè)領(lǐng)域在質(zhì)量和效率上的提升，已經(jīng)遠(yuǎn)遠(yuǎn)超出了任何人的想象?！彼龑懙馈?/p>

Jaana 還說(shuō)道，從傳統(tǒng)工程轉(zhuǎn)向機(jī)器學(xué)習(xí)的過(guò)程，本身就充滿了挑戰(zhàn)：“從傳統(tǒng)工程轉(zhuǎn)向機(jī)器學(xué)習(xí)，需要調(diào)整心態(tài)，并適應(yīng)累積的不確定性。當(dāng)你意識(shí)到收益與損失不再遵循常規(guī)趨勢(shì)，短時(shí)間內(nèi)就可能出現(xiàn)重大回退時(shí)，文化沖擊便隨之而來(lái)。打造出色的產(chǎn)品需要專注、奉獻(xiàn)、近乎癡迷的投入，一支相對(duì)志同道合的優(yōu)秀團(tuán)隊(duì)，以及對(duì)行業(yè)混亂本質(zhì)的保護(hù)。優(yōu)秀的產(chǎn)品就像獨(dú)角獸一樣稀有?！?/p>

她還吐槽了行業(yè)現(xiàn)狀：“在這個(gè)行業(yè)里，大多數(shù)開發(fā)者能夠真正推動(dòng)事情發(fā)生的日子已經(jīng)很久遠(yuǎn)了。復(fù)雜性和繁文縟節(jié)讓摩擦極高，整個(gè)行業(yè)能持續(xù)運(yùn)轉(zhuǎn)本身就是一個(gè)奇跡。我們不能總是要求人們?cè)诓粩鄳?yīng)對(duì)沖突和處理爭(zhēng)議的情況下保持 100% 的產(chǎn)出。你要么有效地消除爭(zhēng)議并開辟新的空間，要么最終只能淘汰人手?？傆袞|西會(huì)出問(wèn)題?！?/p>

AI 編程帶來(lái)的效率提升，讓不少人深有感受。Jaana 直言：“關(guān)于編碼智能體的所有爭(zhēng)議，只是一個(gè)表象。自始至終，行業(yè)現(xiàn)狀和就業(yè)市場(chǎng)的狀況才是根本問(wèn)題。”也正因?yàn)檫@種效率和潛力，引發(fā)了更多人對(duì) Claude Code 本身實(shí)際表現(xiàn)的興趣——不僅僅是“玩具版”的測(cè)試，還有它在真實(shí)工程環(huán)境中的生產(chǎn)力。

Claude Code 作者的實(shí)戰(zhàn)心得

有意思的是，不久之前，Claude Code 的創(chuàng)造者 Boris Cherny 在 X 上分享了自己過(guò)去一個(gè)月使用 CC 的真實(shí)生產(chǎn)數(shù)據(jù)：

2024 年 9 月，我把 Claude Code 當(dāng)作一個(gè)業(yè)余項(xiàng)目創(chuàng)建出來(lái)時(shí)，完全沒(méi)有想到它會(huì)發(fā)展到今天這樣的規(guī)模。看到 Claude Code 成為如此多工程師的核心開發(fā)工具，看到社區(qū)所展現(xiàn)出的巨大熱情，以及人們將它用于從編程、運(yùn)維、科研到非技術(shù)場(chǎng)景的各種用途，這讓我感到既謙卑又震撼。這項(xiàng)技術(shù)既陌生又充滿魔力，它極大地降低了人們構(gòu)建和創(chuàng)造的門檻。越來(lái)越多的情況下，代碼本身已經(jīng)不再是瓶頸。

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

而近日就在 Jaana 發(fā)帖差不多同一時(shí)間，Boris Cherny 也公開了自己的使用經(jīng)驗(yàn)，希望給正在使用 Claude Code 的開發(fā)者帶來(lái)參考：

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

那我直接說(shuō)說(shuō)我的做法吧：

1. 我在終端里同時(shí)運(yùn)行 5 個(gè) Claude。我給標(biāo)簽頁(yè)編號(hào) 1–5，并用系統(tǒng)通知來(lái)知道哪個(gè) Claude 需要輸入。https://code.claude.com/docs/en/terminal-config-2-system-notifications

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

3. 我用 Opus 4.5 并開啟思考模式處理所有事情。這是我用過(guò)的最強(qiáng)大的編程模型。雖然它比 Sonnet 更大、更慢，但因?yàn)樾枰深A(yù)更少、工具使用能力更強(qiáng)，最終效率通常比用小模型更高。

4. 我們團(tuán)隊(duì)共享一個(gè) Claude Code 倉(cāng)庫(kù)的 http://CLAUDE.md。我們會(huì)將它提交到 git，團(tuán)隊(duì)每周多次貢獻(xiàn)內(nèi)容。每當(dāng)發(fā)現(xiàn) Claude 做錯(cuò)事情，我們就記錄到 http://CLAUDE.md，這樣 Claude 下次就不會(huì)再犯同樣錯(cuò)誤。其他團(tuán)隊(duì)會(huì)維護(hù)自己的 http://CLAUDE.md，每個(gè)團(tuán)隊(duì)都有責(zé)任保持文件更新。

5. 代碼審查時(shí)，我經(jīng)常在同事的 PR 上標(biāo)記 @.claude，把需要記錄的內(nèi)容加入 http://CLAUDE.md。我們使用 Claude Code 的 Github Action（/install-github-action）來(lái)操作。這是我們對(duì) @danshipper 的 Compounding Engineering 的一種實(shí)現(xiàn)方式。

6. 大多數(shù)會(huì)話從 Plan 模式開始（shift+tab 兩次）。如果我的目標(biāo)是寫一個(gè) Pull Request，我會(huì)先用 Plan 模式，并和 Claude 反復(fù)確認(rèn)計(jì)劃直到滿意。然后我切換到自動(dòng)接受修改模式，Claude 通?？梢砸淮涡酝瓿?。一個(gè)好的計(jì)劃非常重要！

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

8. 我還經(jīng)常使用一些子智能體：code-simplifier 會(huì)在 Claude 完成工作后簡(jiǎn)化代碼，verify-app 有詳細(xì)說(shuō)明用于端到端測(cè)試 Claude Code，等等。和斜杠命令類似，我把子智能體看作是自動(dòng)化我大多數(shù) PR 中最常用的工作流。

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

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

11. Claude Code 會(huì)替我使用所有工具。它經(jīng)常會(huì)在 Slack 上搜索和發(fā)消息（通過(guò) MCP 服務(wù)器）、運(yùn)行 BigQuery 查詢以回答分析問(wèn)題（使用 bq CLI）、從 Sentry 獲取錯(cuò)誤日志等。Slack MCP 配置提交在 .mcp.json，團(tuán)隊(duì)共享。

12. 對(duì)于耗時(shí)很長(zhǎng)的任務(wù)，我會(huì)采取以下做法：

    (a) 任務(wù)完成后，用后臺(tái)智能體提示 Claude 驗(yàn)證其工作；

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

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

    我還會(huì)在沙箱環(huán)境中使用 --permission-mode=dontAsk 或 --dangerously-skip-permissions 來(lái)避免權(quán)限提示，讓 Claude 可以自由運(yùn)行而不被我阻擋。

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

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

不同領(lǐng)域的驗(yàn)證方式會(huì)有所不同?？赡苤皇沁\(yùn)行一個(gè) bash 命令，或者運(yùn)行測(cè)試套件，或者在瀏覽器或手機(jī)模擬器中測(cè)試應(yīng)用。務(wù)必投入精力，確保這個(gè)驗(yàn)證過(guò)程非常可靠。

來(lái)源：https://x.com/bcherny/status/2007179861115511237

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

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/