日前，Anthropic 基于對自己公司的工程師和研究人員的調研，生成了一份 AI 對工程師工作方式影響的報告。

報告顯示， AI 正在徹底改變程序員的工作方式，讓大家效率翻倍，但也帶來了新的焦慮和挑戰(zhàn)。

正向影響是——
1、效率暴增：Anthropic的工程師使用AI后，生產(chǎn)力平均提升50%，近六成工作都靠AI幫忙
2、能力變廣：工程師能輕松搞定不擅長的領域（如后端工程師做前端），成了"全能選手"
3、質量提高：以前懶得修的小毛病、沒時間做的工具，現(xiàn)在都能快速完成。

但也存在一些擔憂：
1、技能退化：長期依賴AI，自己寫代碼、Debug的真功夫可能生銹
2、人情變淡：有問題先問AI，同事間交流變少， mentorship（師徒指導）也受影響
3、前途迷茫：有人擔心自己正在"培訓替代自己的AI"，長期看工作可能被AI完全接手

報告認為，AI不是簡單替代工程師，而是會把他們變成"AI指揮官"——更多是監(jiān)督、驗證和規(guī)劃設計。

以下為報告全文

我們之前關于AI經(jīng)濟影響的研究考察了整體勞動力市場，涵蓋了各種不同類型的工作。但如果我們更詳細地研究最早采用AI技術的人群——也就是我們自身——會怎樣？

為此，我們將目光轉向內部。2025年8月，我們調查了132名Anthropic的工程師和研究人員，進行了53次深入定性訪談，并研究了內部Claude Code使用數(shù)據(jù)，以了解AI使用如何在Anthropic內部帶來改變。我們發(fā)現(xiàn)，AI使用正在從根本上改變軟件開發(fā)人員的工作性質，既帶來了希望，也引發(fā)了擔憂。

我們的研究揭示了一個正面臨重大變革的工作場所：工程師們完成了更多工作，變得更“全?！保軌蛟诔鲎陨韺I(yè)領域的任務中取得成功），加快了學習和迭代速度，并著手處理以往被忽視的任務。

這種工作廣度的擴展也讓人們開始思考其中的權衡——一些人擔心這可能意味著失去更深層次的技術能力，或變得不那么能夠有效監(jiān)督Claude的輸出，而另一些人則擁抱這個機會，以更開闊、更高層次的思維來思考。

一些人發(fā)現(xiàn)，更多地與AI協(xié)作意味著與同事協(xié)作減少；一些人則懷疑自己最終可能會把自己自動化到失業(yè)。

我們認識到，在一家構建AI的公司研究AI的影響意味著我們處于特權地位——我們的工程師能夠率先使用尖端工具，工作在一個相對穩(wěn)定的領域，并且他們自身也在推動影響著其他行業(yè)的AI變革。

盡管如此，我們認為總體上研究和發(fā)表這些發(fā)現(xiàn)仍然是有價值的，因為在Anthropic內部工程師身上發(fā)生的事情，仍可能預示著更廣泛社會變革的前兆。

我們的發(fā)現(xiàn)提出了一些挑戰(zhàn)和考量，可能值得各個部門及早關注（盡管附錄中的局限性部分有注意事項）。在收集這些數(shù)據(jù)時，Claude Sonnet 4和Claude Opus 4是最先進的模型，而能力還在持續(xù)提升。

更強大的AI帶來了生產(chǎn)力的提升，但也引發(fā)了關于如何保持技術專長、維持有意義的協(xié)作，以及為不確定的未來做準備的問題——這可能需要AI增強型工作場所采用新的學習、指導和職業(yè)發(fā)展方法。

我們將在下文"展望未來"部分討論我們正在采取的一些初步措施。我們也在最近關于AI相關經(jīng)濟政策構想的博客文章中探討了潛在的政策回應。

主要發(fā)現(xiàn)
在本節(jié)中，我們簡要總結了來自調查、訪談和Claude Code數(shù)據(jù)的主要發(fā)現(xiàn)。我們在以下各節(jié)中提供了詳細的發(fā)現(xiàn)、方法和注意事項。

調查數(shù)據(jù)
? Anthropic工程師和研究人員最常使用Claude修復代碼錯誤和學習代碼庫。 調試和理解代碼是最常見的用途（圖1）。

? 人們報告Claude使用量增加和生產(chǎn)力提升。 員工自我報告在60%的工作中使用Claude，并獲得50%的生產(chǎn)力提升，比去年這個時候增長了2-3倍。生產(chǎn)力的提升表現(xiàn)為每個任務類別花費的時間略有減少，但產(chǎn)出量顯著增加（圖2）。

? 27%的Claude輔助工作屬于原本不會完成的任務，例如擴展項目、制作"錦上添花"的工具（如交互式數(shù)據(jù)儀表板），以及手動完成不具成本效益的探索性工作。

? 大多數(shù)員工頻繁使用Claude，同時報告可以"完全委托"0-20%的工作給它。 Claude是一個持續(xù)的協(xié)作者，但使用它通常需要積極的監(jiān)督和驗證，特別是在高風險工作中——而不是完全無需驗證地移交任務。

定性訪談
? 員工正在形成AI委托的直覺。 工程師傾向于委托那些容易驗證的任務，"可以相對輕松地快速檢查正確性"的任務、低風險的（如"一次性調試或研究代碼"）或無聊的任務（"我對任務越感興趣，就越不可能使用Claude"）。

許多人描述了信任遞進的過程，從簡單任務開始，逐漸委托更復雜的工作——雖然目前他們仍然保留大多數(shù)設計或"品味"類任務，但隨著模型改進，這個邊界正在被重新協(xié)商。

? 技能組合正在向更多領域擴展，但一些人實踐減少。 Claude使人們能夠將技能擴展到更多軟件工程領域（"我可以非常有能力地處理前端、事務數(shù)據(jù)庫……以前我都不敢碰這些東西"），但一些員工也矛盾地擔心，編寫和審查代碼所需的深層技能會萎縮——"當產(chǎn)出變得如此容易和快速時，越來越難真正花時間去學習一些東西。"

? 與編程工藝的關系正在改變。 一些工程師擁抱AI輔助并專注于結果（"我曾以為我真的很喜歡寫代碼，現(xiàn)在發(fā)現(xiàn)我其實只是喜歡寫代碼帶來的成果"）；另一些則表示"寫代碼的某些部分我確實會想念。"

? 工作場所社交動態(tài)可能正在改變。 Claude現(xiàn)在成了過去會去找同事提問時的首選——一些人因此報告指導和協(xié)作機會減少。（"我喜歡與人一起工作，現(xiàn)在我'不那么需要'他們了，這很令人難過……初級員工不再經(jīng)常帶著問題來找我了。"）
? 職業(yè)演變與不確定性。 工程師報告轉向管理AI系統(tǒng)的更高級別工作，并報告生產(chǎn)力顯著提升。

然而，這些變化也引發(fā)了關于軟件工程職業(yè)長期軌跡的問題。一些人對未來感到矛盾："短期內我感到樂觀，但長期看我認為AI最終會做所有事情，讓我和許多其他人變得無關緊要。"其他人強調真正的不確定性，只說"很難預測"幾年后他們的角色會是什么樣子。

Claude Code使用趨勢
? Claude正在以更自主的方式處理越來越復雜的任務。

六個月前，Claude Code在需要人工輸入前大約能完成10個操作?，F(xiàn)在通常能處理約20個操作，需要的人工引導更少，就能完成更復雜的工作流（圖3）。工程師越來越多地將Claude用于復雜任務，如代碼設計/規(guī)劃（從1%增加到10%的使用量）和實現(xiàn)新功能（從14%增加到37%）（圖4）。

? Claude修復了很多"小麻煩"。 8.6%的Claude Code任務涉及修復改善生活質量的小問題，如重構代碼以提高可維護性（即"修復小麻煩"），人們說這些通常會被降級處理。這些小改進可能累積成更大的生產(chǎn)力和效率提升。

? 每個人都變得更"全棧"。 不同團隊以不同方式使用Claude，通常是為了增強他們的核心專長——安全團隊用它分析不熟悉的代碼，對齊與安全團隊用它構建數(shù)據(jù)的前端可視化等（圖5）。

調查數(shù)據(jù)
我們調查了來自全組織的132名Anthropic工程師和研究人員關于他們使用Claude的情況，以更好地了解他們日常究竟如何使用它。我們通過內部溝通渠道和直接聯(lián)系，向代表研究和產(chǎn)品職能的多元化團隊中的員工分發(fā)調查。

我們在附錄中包含了局限性部分，提供了更多方法論細節(jié)，并分享我們的調查問題，以便他人可以評估我們的方法并用于自己的研究。

人們使用Claude進行哪些編碼任務？
我們要求受訪工程師和研究人員評估他們使用Claude進行各類編碼任務的頻率，例如"調試"（使用Claude幫助修復代碼中的錯誤）、"代碼理解"（讓Claude解釋現(xiàn)有代碼以幫助用戶理解代碼庫）、"重構"（使用Claude幫助重構現(xiàn)有代碼）和"數(shù)據(jù)科學"（例如讓Claude分析數(shù)據(jù)集并制作條形圖）。

以下是最常見的日常任務。大多數(shù)員工（55%）每天使用Claude進行調試。42%每天使用Claude理解代碼，37%每天使用Claude實現(xiàn)新功能。頻率較低的任務是高層設計/規(guī)劃（可能是因為這些是人們傾向于保留在人手中的任務），以及數(shù)據(jù)科學和前端開發(fā)（可能是因為總體上傳得較少）。這與"Claude Code使用趨勢"部分報告的使用數(shù)據(jù)分布大致相符。

圖一（x軸：日常用戶比例；y軸：各種編碼任務）

使用情況和生產(chǎn)力
員工自我報告12個月前，他們在28%的日常工作中使用Claude，并從中獲得+20%的生產(chǎn)力提升。而現(xiàn)在，他們在59%的工作中使用Claude，平均實現(xiàn)+50%的生產(chǎn)力提升。（這大致證實了我們在整個工程部門采用Claude Code時看到的每個工程師每天合并拉取請求（即成功合并代碼更改）數(shù)量增加67%的情況。）

同比比較相當顯著——這表明兩項指標在一年內增長了兩倍多。使用量和生產(chǎn)力也高度相關，在分布的極端端，14%的受訪者通過使用Claude將生產(chǎn)力提升了100%以上——這些是我們內部的"超級用戶"。

需要為這一發(fā)現(xiàn)（以及下文其他自我報告的生產(chǎn)力發(fā)現(xiàn)）補充說明的是，生產(chǎn)力很難精確衡量（更多局限性見附錄）。來自AI研究非營利組織METR的近期研究表明，在高度熟悉的代碼庫上與AI合作的資深開發(fā)者高估了AI帶來的生產(chǎn)力提升。話雖如此，METR確定的導致生產(chǎn)力低于預期的因素（例如AI在大型復雜環(huán)境中表現(xiàn)較差，或需要大量隱性知識/上下文）與我們的員工表示不會委托給Claude的任務類型（見下文AI委托方法）高度吻合。

我們的生產(chǎn)力提升數(shù)據(jù)（跨任務自我報告）可能反映了員工正在發(fā)展戰(zhàn)略性AI委托技能——這是METR研究中未考慮的因素。

當我們詢問員工在目前的Claude使用類別中，它如何影響他們在該任務類別中花費的總時間和工作量時，出現(xiàn)了一個有趣的生產(chǎn)力模式。幾乎所有任務類別中，我們看到凈耗時減少，而產(chǎn)出量的凈增長更大：

按任務（y軸）劃分的耗時影響（左圖）和產(chǎn)出量影響（右圖）。每個圖的x軸對應于與不使用Claude相比，在Claude輔助任務類別中自我報告的耗時或產(chǎn)出量的減少（負值）、增加（正值）或無變化（垂直虛線）。誤差條顯示95%置信區(qū)間。圓圈面積與每個評分點的響應數(shù)量成正比。僅包括報告在每項任務類別中使用Claude的受訪者。

然而，當我們深入原始數(shù)據(jù)時，我們發(fā)現(xiàn)節(jié)省時間的響應集中在兩端——一些人在Claude輔助的任務上花費的時間顯著增加。

為什么會這樣？人們普遍解釋說，他們不得不做更多調試和清理Claude代碼的工作（例如"當我自己用氛圍編碼陷入困境時"），并承擔更多理解Claude代碼的認知開銷，因為他們自己沒有編寫這些代碼。

一些人提到在賦能意義上花費更多時間——有人說使用Claude幫助他們"堅持處理以前會立即放棄的任務"；另一個人說，它幫助他們在新代碼庫中進行更徹底的測試以及更多的學習和探索。

似乎總體而言，體驗到時間節(jié)省的工程師可能是那些為Claude快速設定可驗證任務的人，而花費更多時間的人可能是在調試AI生成的代碼或在Claude需要更多指導的領域工作。

從我們的數(shù)據(jù)中也不清楚，報告的時間節(jié)省被重新投資到了哪里——是投入到額外的工程任務、非工程任務、與Claude互動或審查其輸出，還是工作之外的活動。我們的任務分類框架未能涵蓋工程師分配時間的所有方式。此外，節(jié)省時間可能反映了自我報告中的感知偏差。需要進一步研究來厘清這些影響。

產(chǎn)出量的增加更直接且更顯著；所有任務類別都有更大的凈增長。當我們考慮到人們報告的是任務類別（如"調試"整體）而非單個任務時，這種模式是合理的——即人們可以在調試這一類別上花費略少的時間，同時總體產(chǎn)生更多的調試產(chǎn)出。生產(chǎn)力很難直接衡量，但這些自我報告的數(shù)據(jù)表明，AI主要通過更大的產(chǎn)出量提高了Anthropic的生產(chǎn)力。

Claude使新工作成為可能
我們好奇的一點是：Claude是否使全新類型的工作成為可能，或者Claude輔助的工作最終也會被員工完成（盡管可能速度較慢）？

員工估計，27%的Claude輔助工作如果沒有它就不會完成。工程師提到使用AI來擴展項目、實現(xiàn)"錦上添花"的功能（如交互式數(shù)據(jù)儀表板）、處理有用但繁瑣的工作（如文檔和測試），以及手動完成不具成本效益的探索性工作。正如一個人解釋的，他們現(xiàn)在可以修復更多以前損害生活質量的"小麻煩"，例如重構結構糟糕的代碼，或構建"幫助更快完成另一任務的小工具"。我們也在使用數(shù)據(jù)分析中尋找這一點，發(fā)現(xiàn)8.6%的Claude Code任務涉及"修復小麻煩"。

另一位研究人員解釋說，他們同時運行多個Claude實例，各自探索問題的不同方法：

人們傾向于將超級強大的模型視為單個實例，就像獲得一輛更快的汽車。但擁有一百萬匹馬……讓你能夠測試大量不同的想法……當你有那種額外的廣度來探索時，會更令人興奮和更有創(chuàng)意。

正如我們在以下章節(jié)中看到的，這項新工作通常涉及工程師處理超出其核心專業(yè)領域的任務。

有多少工作可以完全委托給Claude？
盡管工程師頻繁使用Claude，但超過一半的人表示他們只能將0-20%的工作"完全委托"給Claude。（值得注意的是，受訪者對"完全委托"的理解存在差異——從完全不需要驗證的任務到足夠可靠只需輕量監(jiān)督的任務。）

在解釋原因時，工程師描述了他們與Claude積極互動和迭代的過程，并驗證了它的輸出——特別是在代碼質量標準至關重要的復雜任務或高風險領域。這表明工程師傾向于與Claude密切合作并檢查其工作，而不是不經(jīng)驗證就移交任務，并且他們對"完全委托"的標準要求很高。

定性訪談
雖然這些調查發(fā)現(xiàn)揭示了顯著的生產(chǎn)力提升和工作模式變化，但它們也提出了工程師日常如何實際經(jīng)歷這些變化的問題。為了理解這些指標背后的人性維度，我們對調查中作出回應的53名Anthropic工程師和研究人員進行了深度訪談，以更深入地了解他們對工作場所這些變化的想法和感受。

AI委托方法
工程師和研究人員正在開發(fā)各種策略，以在其工作流程中高效利用Claude。人們通常委托以下類型的任務：

在用戶上下文之外且復雜度低：
"我將Claude用于那些我了解甚少，但認為整體復雜度也低的事情。"
"我遇到的大多數(shù)基礎設施問題都不難，可以由Claude處理……我不太懂Git或Linux……Claude很好地彌補了我這些領域經(jīng)驗的不足。"
易于驗證：
"對于驗證工作量與創(chuàng)建工作量相比不大的所有事情，它都非常出色。"

定義明確或自成一體的：
"如果項目的某個子組件與其余部分充分解耦，我會讓Claude嘗試一下。"

代碼質量不關鍵：
"如果是一次性調試或研究代碼，我會直接交給Claude。如果是概念上困難的或需要某種非常特定類型的調試注入，或設計問題，我自己來做。"

重復性或無聊的：
"我對任務越感興趣，越不可能使用Claude。而如果我感到很大阻力……我經(jīng)常發(fā)現(xiàn)與Claude開啟關于任務的對話更容易。"

在我們的調查中，人們平均表示44%的Claude輔助工作由他們自己不會喜歡做的任務組成。

提示比執(zhí)行更快：
"對于一項我預計花費不到10分鐘的任務……我可能不會去麻煩使用Claude。"
"冷啟動問題可能是當前最大的障礙。所謂冷啟動，是指我擁有大量關于我的團隊代碼庫如何工作的內在信息，而Claude默認情況下不會擁有這些信息……我可以花時間迭代完美的提示[但]我還是會自己去做。"

員工在委托決策中提到的這些因素與METR外部研究中發(fā)現(xiàn)的可解釋AI生產(chǎn)力放緩的因素（如開發(fā)者對代碼庫高度熟悉、大型復雜倉庫）相似。我們的訪談中這些委托標準的一致性表明，適當?shù)娜蝿者x擇是AI生產(chǎn)力提升的重要因素（這應在未來的生產(chǎn)力研究中仔細控制）。

信任但需驗證
許多用戶描述了他們在Claude使用上的進展，涉及隨時間推移委托越來越復雜的任務："起初我只用AI工具問關于Rust編程語言的基本問題……最近，我用Claude Code處理我所有的編碼工作。"

一位工程師將這種信任遞進比作采用其他技術，如谷歌地圖：
最初我只在不知道的路線上使用[谷歌地圖]……這像我讓Claude寫我不知道的SQL，但不讓它寫我熟悉的Python。然后我開始在我基本知道但可能不知道最后一英里的路線上使用谷歌地圖……現(xiàn)在我一直在使用谷歌地圖，即使是日常通勤。如果它說采取不同路線，我就照做，只是相信它考慮了所有選項……今天我以類似的方式使用Claude Code。

工程師們在是否在專業(yè)領域內使用Claude存在分歧。一些人將其用于"外圍"領域以節(jié)省實施時間；另一些人則更喜歡在自己熟悉的領域使用，以便驗證輸出（"我以這種方式使用Claude，使我對它在做什么仍有完全的理解"）。

一位安全工程師強調經(jīng)驗的重要性，當時Claude提出了一個"在危險意義上非常聰明的解決方案，是那種只有非常有才華的初級工程師才會提出的東西"。也就是說，只有具備判斷力和經(jīng)驗的用戶才能識別出其中的問題。

其他工程師將Claude用于這兩種類型的任務，要么以實驗方式（"我基本上總是用Claude先嘗試任何編碼問題"），要么根據(jù)自己在任務中的專業(yè)水平調整方法：

我將這些工具既用于我的核心專業(yè)領域（作為加速器，我知道該期待什么并能有效引導智能體），也用于略微超出我專業(yè)領域的領域，我大致知道該期待什么，但Claude能夠填補我記憶中的空白或對特定定義的不熟悉。

如果是我特別精通的事情，我會更主動地告訴Claude它需要追蹤什么。如果是我不太確定的事情，我經(jīng)常讓它成為專家，給我提供選項和關于我應該考慮和研究的事情的見解。

人們?yōu)樽约罕Ａ裟男┤蝿眨?br/>人們一貫表示，他們不會將涉及高層或戰(zhàn)略性思維的任務，或需要組織上下文或"品味"的設計決策交給Claude。

一位工程師解釋說："我通常保留高層思維和設計。我會從開發(fā)新功能到調試等任何可以委托的事情中委托。"這反映在我們的調查數(shù)據(jù)中，該數(shù)據(jù)顯示設計和規(guī)劃任務的生產(chǎn)力提升最?。▓D2）。許多人將委托邊界描述為"移動目標"，不過隨著模型改進而定期重新協(xié)商（下文Claude Code使用數(shù)據(jù)顯示，現(xiàn)在的代碼設計/規(guī)劃使用量比六個月前相對更多）。

技能轉變

新能力……
調查發(fā)現(xiàn)27%的Claude輔助工作否則不會完成，這反映了一個更廣泛的模式：工程師使用AI在其核心專業(yè)領域之外工作。

許多員工報告稱完成了以前超出其專業(yè)領域的工作——后端工程師構建UI；研究人員創(chuàng)建可視化。一位后端工程師描述通過迭代Claude構建復雜UI："它做得比我好得多。我自己根本做不到，肯定無法按時完成……[設計師們]說'等等，你做的這個？'我說'不，Claude做的這個——我只是提示它。'"

工程師報告"變得更全?！铱梢苑浅Ｓ心芰Φ靥幚砬岸?、事務數(shù)據(jù)庫、API代碼，而以前我會害怕碰那些我不太精通的東西。"這種能力擴展實現(xiàn)了更緊密的反饋循環(huán)和更快的學習——一位工程師說，與同事一起進行構建、安排會議和迭代的"幾周流程"可以變成"幾小時工作會"，同事可實時提供反饋。

總體而言，人們對快速原型設計、并行處理工作、減少重復勞動以及普遍提升抱負水平的新能力感到興奮。

一位高級工程師告訴我們："這些工具肯定讓初級工程師更有生產(chǎn)力，也更有膽量承擔各種類型的項目。"一些人還表示，使用Claude降低了"啟動能量"，使他們更容易克服拖延，"極大地減少了我想要開始解決問題的能量需求，因此我愿意解決更多額外的事情。"

……以及更少的實踐
與此同時，一些人擔心"隨著委托更多，技能會萎縮"，并在手動問題解決過程中失去偶然（或"附帶"）的學習：

如果你自己去調試一個難題，你會花時間閱讀與你解決問題不直接相關的文檔和代碼——但整個過程中你都在建立系統(tǒng)如何運作的模型。這種情況現(xiàn)在少多了，因為Claude可以直接幫你找到問題。

我以前會探索每個配置以了解工具能做什么，但現(xiàn)在我依賴AI告訴我如何使用新工具，所以我缺乏專業(yè)知識。在與隊友交談時，以前我能瞬間回憶事情，現(xiàn)在則必須問AI。

使用Claude可能會跳過通過解決簡單實例來學習如何執(zhí)行任務的部分，然后之后難以解決更復雜的實例。

一位高級工程師表示，如果他們更初級，他們會更擔心自己的技能：

我主要在那些我知道答案應該是什么或應該是什么樣子的案例中使用AI。我通過以"困難方式"做軟件工程開發(fā)了這種能力……但如果我[處于職業(yè)生涯早期]，我會認為需要付出大量刻意努力才能繼續(xù)提升自己的能力，而不是盲目接受模型輸出。

編碼技能萎縮令人擔憂的一個原因是上文提到的"監(jiān)督悖論"——有效使用Claude需要監(jiān)督，而監(jiān)督Claude需要的可能正是因過度使用AI而萎縮的編碼技能。

一個人說：
老實說，我比起擔心我自己的技能組合，更擔心監(jiān)督和監(jiān)督問題……我的技能萎縮或未能發(fā)展，主要會在我安全使用AI處理我關心的任務的能力方面造成問題，而不是在我獨立執(zhí)行這些任務的能力方面。

為了應對這一點，一些工程師刻意在沒有AI的情況下練習："每隔一段時間，即使我知道Claude能完美解決問題，我也不會要求它這樣做。這幫助我保持敏銳。"

我們是否仍然需要那些實踐編碼技能？
也許軟件工程正在向更高層次的抽象發(fā)展，就像過去一樣。早期程序員更接近機器——手動管理內存、用匯編語言編寫，甚至撥動物理開關輸入指令。

隨著時間的推移，出現(xiàn)了更高級、更易讀的語言來自動處理復雜的底層操作。也許，特別是隨著"氛圍編碼"的興起，我們現(xiàn)在正在將英語作為一種編程語言。

我們的一位員工建議，有抱負的工程師應該"擅長讓AI[寫代碼]，并專注于學習更高層次的概念和模式"。

一些員工表示，這種轉變讓他們能夠更高層次地思考——"關注最終產(chǎn)品和最終用戶"而不僅僅是代碼。一個人通過對比之前學習計算機科學中的鏈表（現(xiàn)在高級編程語言自動處理的基本結構）來描述當前的轉變。

"我很高興我知道怎么做那個……[但]執(zhí)行那些底層操作在情感上并不是特別重要。我更關心代碼能讓我做什么。"另一位工程師做了類似的比較，但指出抽象是有代價的——隨著轉向高級語言，大多數(shù)工程師失去了對內存處理的深入理解。

繼續(xù)在某個領域發(fā)展技能可以帶來更好的Claude監(jiān)督和更高效的工作（"我注意到當是我熟悉的事情時，我自己做往往更快"）。但工程師們對此是否重要存在分歧。

一些人保持樂觀：
我不太擔心技能退化。AI仍然讓我仔細思考問題，并幫助我學習新方法。如果有的話，能夠更快地探索和測試想法在一些領域加速了我的學習。

另一位更務實："我作為軟件工程師的技能肯定在萎縮……但如果需要，這些技能可以恢復，而且我不再需要它們了！"一位指出他們只失去了不太重要的技能，如制作圖表，"而關鍵的那種代碼我仍然能寫得很好。"

也許最有趣的是，一位工程師質疑了這個前提："‘變得生疏’的框架依賴于一個假設，即編碼總有一天會回到Claude 3.5之前的方式。而我認為不會。"

軟件工程的工藝與意義

工程師們對于是否想念實踐編碼存在尖銳分歧。一些人感到真正的失落——"這對我來說是一個時代的結束——我已經(jīng)編程25年了，在這個技能組合上感到勝任是我職業(yè)滿意度的核心部分。"

另一些人則擔心不喜歡新工作性質："整天提示Claude不是很有趣或充實。戴上音樂，進入狀態(tài)，自己實現(xiàn)一些東西要有趣和充實得多。"

一些人直接面對這種權衡并接受它："寫代碼的某些部分我肯定會想念——重構代碼時進入禪意流狀態(tài)，但總體上我現(xiàn)在生產(chǎn)力高得多，我很樂意放棄那個。"

一個人說，與Claude迭代更有趣，因為他們可以比對人更挑剔地提出反饋。另一些人更關注結果。

一位工程師說：
我曾預計到這個階段會感到害怕或無聊……然而我實際上沒有感到這些。相反，我對能做更多事情感到非常興奮。我曾以為我真的很喜歡寫代碼，現(xiàn)在發(fā)現(xiàn)我其實只是喜歡寫代碼帶來的成果。

人們是否擁抱AI輔助或悲嘆失去實踐編碼，似乎取決于他們覺得軟件工程的哪些方面最有意義。

工作場所社交動態(tài)的變化
一個更突出的主題是，Claude已成為過去會去找同事提問的首選。"我現(xiàn)在總體上問的問題多得多，但大約80-90%都問Claude了，"一位員工指出。這創(chuàng)造了一種過濾機制，Claude處理常規(guī)查詢，留下同事處理更復雜、戰(zhàn)略性或需要上下文的超出AI能力的問題（"它使我對[我的團隊]的依賴減少了80%，[但]最后的20%至關重要，我會去找他們談"）。人們也會"與Claude討論想法"，類似于與人工協(xié)作者的互動。

約一半的人報告團隊協(xié)作模式?jīng)]有變化。一位工程師說他仍然與人會面、分享上下文、選擇方向，并認為在不久的將來仍會有很多協(xié)作，但"你不會再做標準的專注工作，而是會與很多Claude對話。"

然而，其他人描述與同事互動減少（"我與Claude協(xié)作遠多于與任何同事協(xié)作。"）一些人欣賞減少的社交摩擦（"我不再為占用同事時間感到難過"）。

另一些人抵制這種變化（"我不太喜歡常見的回應是‘你問過Claude了嗎？’我真的很喜歡面對面與人合作，非常珍視這一點"）或想念舊的工作方式："我喜歡與人一起工作，現(xiàn)在我‘不那么需要’他們了，這很令人難過。"幾個人指出了對傳統(tǒng)指導動態(tài)的影響，因為"Claude可以為初級員工提供大量輔導"，而不是高級工程師。

一位高級工程師說：
更初級的人不再經(jīng)常帶著問題來找我，這很令人難過，盡管他們的問題肯定得到了更有效的解答，學得也更快。

職業(yè)不確定性與適應
許多工程師描述他們的角色從寫代碼轉變?yōu)楣芾鞟I。工程師越來越多地將自己視為"AI智能體的管理者"——一些人已經(jīng)" constantly至少有幾[Claude]實例在運行"。

一個人估計他們的工作已轉變?yōu)?70%以上成為代碼審查者/修改者，而非凈新增代碼編寫者"，另一個人將"為1個、5個或100個Claude的工作承擔責任"視為他們未來角色的一部分。

從長遠來看，職業(yè)不確定性普遍存在。工程師們將這些變化視為更廣泛行業(yè)變革的前兆，許多人表示"很難說"幾年后他們的職業(yè)會是什么樣子。一些人在短期樂觀和長期不確定性之間表達了沖突。"短期內我感到樂觀，但長期看我認為AI最終會做所有事情，讓我和許多其他人變得無關緊要，"一位工程師說。其他人更尖銳地指出："每天來上班感覺有點像是給自己制造失業(yè)。"

一些工程師更樂觀。一位說："我為初級開發(fā)者擔心，但我也欣賞初級開發(fā)者可能是最渴望新技術的人。我對職業(yè)軌跡總體上非常樂觀。"他們認為，雖然存在經(jīng)驗不足工程師發(fā)布問題代碼的潛在風險，但更好的AI防護欄、更多內置教育資源以及從錯誤中自然學習將幫助該領域隨著時間適應。

我們詢問人們如何設想他們未來的角色以及是否有任何適應策略。一些人提到計劃進一步專業(yè)化（"有意義地審查AI工作的技能將需要更長時間和更多專業(yè)化"），一些人預計未來專注于更多人際和戰(zhàn)略性工作（"我們將花更多時間達成共識，讓AI花更多時間在實施上"）。一位說他們有針對性地將Claude用于職業(yè)發(fā)展，從它那里獲得關于工作和領導技能的反饋（"我學習事物或甚至在不完全學習事物的情況下變得高效的速度完全改變了。我?guī)缀醺杏X天花板剛剛為我破碎了"）。

總體而言，許多人承認存在深度不確定性："我對未來具體哪些技能會有用信心很低。"一位團隊負責人說："沒有人知道會發(fā)生什么……重要的是要非常適應。"

Claude Code使用趨勢
調查和訪談數(shù)據(jù)顯示，Claude使用量的增加幫助人們更快地工作并承擔新類型的工作，盡管這伴隨著AI委托和技能發(fā)展的張力。然而，自我報告的數(shù)據(jù)只講述了部分故事。

為了補充這一點，我們還分析了Anthropic各團隊的實際Claude使用數(shù)據(jù)。由于調查受訪者報告Claude Code是他們使用的主要部分，我們使用隱私保護分析工具分析了2025年2月和8月的20萬條內部Claude Code對話記錄。

以更少監(jiān)督解決更難的問題
在過去六個月中，Claude Code使用已轉向更困難且更自主的編碼任務（圖3）：

? 員工正在使用Claude Code處理越來越復雜的任務。 我們將每個對話記錄的任務復雜度按1-5分制估算，1對應"基本編輯"，5對應"需要數(shù)周/數(shù)月人類專家工作的專家級任務"。平均任務復雜度從3.2增加到3.8。為了說明分數(shù)差異：平均3.2的任務包括"排查Python模塊導入錯誤"，而平均3.8的任務包括"實現(xiàn)和優(yōu)化緩存系統(tǒng)"。

? Claude Code每段對話連續(xù)執(zhí)行的最大工具調用次數(shù)增加了116%。 工具調用對應于Claude使用外部工具執(zhí)行的操作，如編輯文件或運行命令。Claude現(xiàn)在能在無需人工干預的情況下串聯(lián)21.2個獨立工具調用，而六個月前為9.8個。

? 人工干預次數(shù)減少了33%。 每段對話的平均人工干預次數(shù)從6.2次減少到4.1次，表明現(xiàn)在與六個月前相比，完成特定任務所需的人工輸入更少。

圖3. 2025年8月與2025年2月Claude Code使用的變化（x軸）。平均任務復雜度隨時間增加（左圖），每段對話的平均最大連續(xù)工具調用次數(shù)隨時間增加（中圖），人工干預次數(shù)隨時間減少（右圖）。誤差條顯示95%置信區(qū)間。數(shù)據(jù)表明人們正越來越多地將更多自主權委托給Claude。

這些使用數(shù)據(jù)證實了調查數(shù)據(jù)：工程師將越來越復雜的工作委托給Claude，而Claude需要的監(jiān)督更少。這似乎可能推動了觀察到的生產(chǎn)力提升。

任務分布
我們將Claude Code對話記錄分類為一種或多種編碼任務類型，研究了不同任務用途在過去六個月中的演變：

圖4. 各種編碼任務（y軸）占總體記錄數(shù)量百分比（x軸）的分布。我們比較了6個月前（粉色）和現(xiàn)在的分布（紫色）。y軸按2025年2月的頻率排序。

從使用數(shù)據(jù)估算的總體任務頻率分布大致與自我報告的任務頻率分布一致。

2025年2月到8月之間最顯著的變化是，現(xiàn)在有更多比例的對話記錄使用Claude實現(xiàn)新功能（14.3% → 36.9%）和進行代碼設計或規(guī)劃（1.0% → 9.9%）。

Claude Code任務相對分布的這種轉變可能表明Claude已變得更擅長這些更復雜的任務，但也可能反映了團隊采用Claude Code進行不同工作流程的變化，而非絕對工作量的增加（更多局限性見附錄）。

修復小麻煩
我們從調查中發(fā)現(xiàn)，工程師現(xiàn)在花更多時間進行小的質量改進；與此一致，8.6%的當前Claude Code任務被歸類為"修復小麻煩"。這些包括創(chuàng)建性能可視化工具和重構代碼以提高可維護性等較大任務，以及創(chuàng)建終端快捷方式等較小任務。

這可能有助于工程師報告的生產(chǎn)力提升（解決以前被忽視的質量改進可能隨著時間推移帶來更多效率），并可能減少日常工作中的摩擦和挫敗感。

跨團隊任務變化
為了研究任務目前在不同團隊間的差異，我們優(yōu)化了分類方法，將每個8月的對話記錄分配到單一主要編碼任務，并按內部團隊（y軸）拆分數(shù)據(jù)。堆疊條形圖顯示了每個團隊不同編碼任務的分解：

圖5. 每個橫條代表一個團隊（y軸），各段顯示該團隊Claude Code用于不同編碼任務的比例（x軸），按編碼任務著色（圖例）。頂部橫條（"所有團隊"）代表總體分布。
"所有團隊"橫條顯示了總體分布，最常見的任務是構建新功能、調試和理解代碼。這為團隊特定比較提供了基準。

值得注意的團隊特定模式：

? 預訓練團隊（幫助訓練Claude的團隊）最常使用Claude Code構建新功能（54.6%），其中很多是運行額外實驗。

? 對齊與安全團隊和后訓練團隊使用Claude Code進行最多的前端開發(fā)（分別為7.5%和7.4%），通常用于創(chuàng)建數(shù)據(jù)可視化。

? 安全團隊最常使用Claude Code理解代碼（48.9%），特別是分析代碼庫不同部分的安全影響。

? 非技術人員最常使用Claude Code進行調試（51.5%），如排查網(wǎng)絡問題或Git操作，以及數(shù)據(jù)科學（12.7%）；Claude似乎對彌補技術知識差距很有價值。

許多這些團隊特定模式展示了我們調查和訪談中觀察到的相同能力擴展：使團隊沒有時間或技能完成的全新工作成為可能。

例如，預訓練團隊運行了大量額外實驗，非技術人員能夠修復代碼錯誤。雖然數(shù)據(jù)表明團隊確實將Claude用于其核心任務（例如，基礎設施團隊最常用Claude Code進行基礎設施和DevOps工作），但Claude也經(jīng)常增強其核心任務（例如，研究人員使用Claude進行前端開發(fā)以更好地可視化其數(shù)據(jù)）。這表明Claude正在使每個人在工作中變得更全棧。

展望未來
過去一年，Anthropic員工大幅增加了Claude的使用，不僅用它來加速現(xiàn)有工作，還用來學習新代碼庫、減少重復勞動、擴展至新領域，以及處理以前被忽視的改進。隨著Claude變得更自主和更有能力，工程師們正在發(fā)現(xiàn)新的AI委托方式，同時也在搞清楚未來需要哪些技能。

這些變化帶來了明確的生產(chǎn)力和學習收益，同時也伴隨著對軟件工程工作長期軌跡的真正不確定性。AI會像過去的軟件工程轉型——從低級到高級編程語言，或從個人貢獻者到管理者，正如幾位工程師所建議的那樣？還是會走得更遠？

現(xiàn)在還處在早期階段——Anthropic內部有很多早期采用者，格局正在迅速變化，我們的發(fā)現(xiàn)目前可能無法推廣到其他組織或情境（更多局限性見附錄）。

這項研究反映了這種不確定性：發(fā)現(xiàn)是微妙的，沒有出現(xiàn)單一的共識或明確的指導方針。但它確實提出了我們如何能夠深思熟慮且有效地駕馭這些變化的問題。

為了跟進這項初步工作，我們正在采取幾項措施。我們正在與Anthropic工程師、研究人員和領導層討論，以解決提出的機遇和挑戰(zhàn)。這包括研究我們如何團結團隊、相互協(xié)作，如何支持職業(yè)發(fā)展，以及如何建立AI增強工作的最佳實踐（例如由我們的AI流暢度框架指導）。

我們還將這項研究擴展到工程師之外，以了解AI轉型如何影響組織各角色，并支持CodePath等外部組織，幫助它們?yōu)锳I輔助的未來調整計算機科學課程。展望未來，我們也在考慮隨著AI能力進步可能變得越來越相關的結構性方法，如組織內角色演變或再培訓的新途徑。

我們預計將在2026年分享更具體的計劃，隨著我們的思考成熟。Anthropic是負責任工作場所轉型的實驗室；我們不僅要研究AI如何改變工作，還要實驗如何深思熟慮地駕馭這種轉型，從我們自己開始。