如果有一天，你走進公司，發現寫代碼、查 bug、跑實驗的大部分體力活，都已經由一位看不見的 AI 搭檔在後台悄悄完成了——而你更多是在提問題、定方向、做決策，而不是一行行敲代碼，這會是什麼感覺？是興奮，因為產出翻倍、想法終於可以快速落地；還是隱隱不安，因為自己賴以安身立命的“手藝”似乎正在慢慢被接管？
對於正在建設 AI 的公司來説，這個問題來得比想象中更早、更猛。
Anthropic 在 2025 年做了一次有意思的“自我實驗”：他們把鏡頭轉向公司內部，系統性地調查工程師和研究人員是如何使用 Claude 的，以及這些變化正在如何重塑工作的內容、節奏、協作方式，甚至職業身份。下面內容翻譯自 Anthropic 官方的長文《How AI Is Transforming Work at Anthropic》，基於問卷調查、深入訪談以及 Claude Code 使用數據，試圖回答這樣幾個問題：
- AI 到底把工程師的時間花在了哪裏？
- 它真的提升了生產力嗎？
- 我們會因此變得更“全棧”，還是逐漸失去底層能力？
- 在這場轉型裏，個體應該如何重新定位自己的角色？
人工智能正在如何改變我們的工作方式？我們此前一項關於 AI 經濟影響的研究，主要從整體勞動力市場的角度出發，考察了各種不同的工作。但如果我們把鏡頭拉近，去細看那些最早使用 AI 技術的一羣人——也就是我們自己，會看到什麼？
把視角轉向公司內部，在 2025 年 8 月，我們對 132 名 Anthropic 的工程師和研究人員發放了問卷，進行了 53 次深入的定性訪談，並分析了內部的 Claude Code 使用數據，來理解 AI 使用方式正在如何改變 Anthropic 的日常工作。我們的發現是：AI 的使用正在從根本上改變軟件開發者的工作性質，這既帶來了希望，也帶來了擔憂。
我們的研究呈現出一個處在劇烈變革中的工作場所：工程師的產出顯著提升，變得更加“全棧”（能夠勝任原本超出自己專業範圍的任務），學習和迭代的速度加快，也開始着手處理過去長期被擱置的任務。這種能力邊界的外擴，也讓大家開始思考代價：有人擔心這會犧牲更深層次的技術功底，或者削弱自己有效監督 Claude 產出的能力；也有人則樂於擁抱這種變化，把它看作是思考方式從細節轉向更高層次抽象的機會。有的人發現，與 AI 合作得越多，反而與同事合作得越少；還有人開始擔心，自己會不會有一天真的把自己“自動化下崗”。
我們也意識到，在一家構建 AI 的公司內部研究 AI 的影響，本身就是一種帶有“特權視角”的觀察——我們的工程師有機會更早接觸前沿工具，工作領域相對穩定，並且他們本身也是這輪 AI 變革在其他行業中發生的推動者。即便如此，我們仍然認為這些發現值得研究與公開分享，因為對工程師而言，在 Anthropic 內部正在發生的事情，很可能是更廣泛社會轉型的某種“預演”。這些發現提示了一些值得各個行業提前思考的挑戰與問題（具體的研究限制可以參見文末附錄中的“侷限性”部分）。在這批數據採集時，Claude Sonnet 4 和 Claude Opus 4 是當時最強的模型，而模型能力此後仍在不斷提升。
更強大的 AI 帶來了生產力的提升，但同時也拋出了新的問題：如何保持技術能力不過度流失？如何在 AI 協作下維持有意義的人與人協作？如何為一個充滿不確定性的未來做準備——那可能需要截然不同的學習方式、指導機制和職業發展路徑？在文末“展望未來”部分，我們討論了一些 Anthropic 正在內部嘗試的初步探索。在另一篇關於經濟政策的博客文章中，我們也提出了一些圍繞 AI 的經濟政策設想。
關鍵發現
在本節中，我們會簡要總結問卷、訪談和 Claude Code 數據給出的主要結論。更詳細的結果、方法和注意事項，會在後面的章節中展開。
問卷數據
- Anthropic 的工程師和研究人員最常用 Claude 來修復代碼錯誤和理解代碼庫。 調試和代碼理解是最常見的使用場景（對應圖 1）。
- 大家報告 Claude 使用頻率與生產力提升都在持續上升。 員工自報目前有約 60% 的工作會使用 Claude，平均帶來約 50% 的生產力提升——相比一年前，這是 2～3 倍的增長。生產力提升的表現形式，是各類任務上單個任務花費的時間略有下降，但整體產出量明顯增加（對應圖 2）。
- 約 27% 的 Claude 輔助工作，是本來不會發生的。 比如擴展項目規模、做各種“錦上添花”的工具（如交互式數據看板），以及一些如果完全人工完成就不划算的探索性工作。
- 多數員工頻繁使用 Claude，但認為“可以完全交給 Claude 不用自己驗證”的工作只佔 0–20%。 Claude 更像是一個始終在線的協作者；使用它通常仍然需要主動監督和驗證，尤其是在高風險場景下，而不是完全不用檢查就把任務直接“甩手”出去。
定性訪談
- 員工正在逐漸形成關於“什麼任務適合交給 AI”的直覺。 工程師傾向於把那些易於驗證、自己“可以比較輕鬆地嗅一嗅就知道對不對”的任務、低風險任務（例如“一次性的調試腳本或研究代碼”），或者枯燥無聊的事情交給 Claude（“我越是對一件事感到興奮，就越不太會用 Claude；反之，如果對這件事本身有很多心理阻力，我往往會先和 Claude 開個頭”）。許多人會從簡單任務開始試探性地交給 Claude，然後逐步擴大到更復雜的工作——目前大家仍傾向於把大部分設計或“品味”相關的工作留在自己手中，不過隨着模型能力提升，這條邊界也在不斷被重新談判。
- 技能在更多方向上被拓展，但動手練習的機會變少了。 Claude 讓大家可以在更多領域“伸出觸角”（比如軟件工程的不同層面：“我現在可以很熟練地做前端、事務型數據庫、API 代碼這些東西——這些以前是我不太敢碰的部分”），但也有人擔憂，深層次的技能在寫代碼和審代碼上的積累會因此萎縮——“當產出某個結果變得這麼容易、這麼快時，你就更難逼自己停下來，花時間真正去學一個東西。”
- 人與“編程手藝”的關係在改變。 有人擁抱 AI 助手，把重點放在結果上（“我以前以為自己喜歡的是寫代碼，現在發現我喜歡的其實是寫完代碼之後得到的那些東西”）；也有人坦言“對寫代碼這件事本身有些懷念”。
- 工作場所的社交動態也在變化。 Claude 已經成為很多工程師提問時的“第一站”，那些過去會去問同事的問題，現在都先問 Claude——結果是，部分人感覺到自己獲得的指導和協作機會減少了。（“我很喜歡和人一起工作，現在有點難過的是，我‘需要’他們的頻率變低了……更初級的同事也不太像以前那樣來問我問題。”）
- 職業路徑在演化，未來也充滿不確定。 工程師正在轉向更高層級的工作——管理 AI 系統，同時報告了顯著的生產力提升。但這些變化也讓人對軟件工程這一職業的長期前景產生疑問。有人態度複雜：“短期我很樂觀，但長期我覺得 AI 最終會把所有事情都做掉，讓我和很多人變得不再重要。”也有人坦承，對未來自己的角色會變成什麼樣，“很難説”。
Claude Code 使用趨勢數據
- Claude 正在以更高的自主性處理越來越複雜的任務。 六個月前，Claude Code 大概可以連續自主完成 10 個動作，之後就需要人來介入。現在，它通常可以連續完成大約 20 個動作，在更復雜的工作流中對人類“指揮”的頻率明顯降低（對應圖 3）。工程師也越來越多地用 Claude 來做複雜任務，比如代碼設計/規劃（在所有使用中的佔比從 1% 提升到 10%），以及實現新功能（從 14% 提升到 37%，對應圖 4）。
- Claude 修掉了很多“紙割傷（papercuts）”。 大約 8.6% 的 Claude Code 任務是對那些提升工作體驗但容易被忽視的小問題的修復，例如為了可維護性而做的重構，也就是人們口中的“修紙割傷”，這些事情在過去通常會被一直往後排。這些小改動積少成多，有望帶來更大的效率和體驗提升。
- 每個人都在變得更“全棧”。 不同團隊以不同方式使用 Claude，往往是用來增強各自的核心專長——比如安全團隊用它來分析陌生代碼，Alignment & Safety 團隊用它來構建數據可視化前端，等等（對應圖 5）。
問卷數據
我們向 Anthropic 各個團隊的 132 名工程師和研究人員發放了問卷，希望更好地理解他們在日常工作中到底是如何使用 Claude 的。問卷通過內部溝通渠道和直接私信的方式分發，覆蓋了來自不同研究和產品團隊的成員。附錄中有更詳細的方法説明，我們也公開了問卷題目，方便其他人評估我們的方法並在自己的研究中借鑑。
人們在什麼編碼任務上使用 Claude？
我們請受訪的工程師和研究人員，評估自己在不同類型編碼任務中使用 Claude 的頻率，比如“調試”（用 Claude 幫助修復代碼錯誤）、“代碼理解”（讓 Claude 解釋既有代碼，幫助自己理解代碼庫）、“重構”（用 Claude 幫助重組已有代碼）、“數據科學”（例如讓 Claude 分析數據集、畫柱狀圖）。
下面是最常見的一些日常任務。多數員工（55%）表示自己每天都會用 Claude 做調試；42% 的人每天會用 Claude 做代碼理解；37% 的人每天會用 Claude 來實現新功能。使用相對較少的，是高層設計/規劃（很可能是因為大家普遍傾向把這類任務保留在“人手裏”），以及數據科學和前端開發（因為這些任務本身在整體工作中的比例就較低）。這和 Claude Code 使用數據中不同任務類型的分佈大致相符（見前文提到的“Claude Code 使用趨勢”部分）。
圖 1：不同編碼任務（縱軸）對應的日常使用者比例（橫軸）。
使用頻率與生產力
員工自報的數據顯示，12 個月前，他們在日常工作中約有 28% 的時間會用到 Claude，當時平均感受到的生產力提升是 +20%；而現在，他們在約 59% 的工作中使用 Claude，平均生產力提升達到了 +50%。（這一點和工程團隊在全面採用 Claude Code 後，人均每天合併的 Pull Request 數量增加 67% 的數據大致相互印證。）按年對比來看，這個變化相當劇烈——一年時間裏，這兩個指標都實現了超過 2 倍的提升。使用頻率與生產力提升高度相關，在分佈的極端一端，有 14% 的受訪者通過使用 Claude 報告了超過 100% 的生產力提升——可以看作內部的“超級用户”。
需要強調的是，包括這一條在內的所有“生產力自評”都有不少不確定性，生產力本身很難被精確測量。外部研究機構 METR 有一項近期研究指出，在一個高度熟悉的代碼庫上，使用 AI 的經驗豐富開發者其實高估了 AI 帶來的生產力提升。值得注意的是，那項研究中導致生產力沒有預期那麼高的因素（例如在大型複雜環境中 AI 表現變差，或任務中包含大量隱性知識和上下文）與我們員工所描述的“不適合交給 Claude 的任務類型”高度一致。我們的生產力提升數據是跨任務的自報，很可能反映了員工在“適合交給 AI 的任務選擇”上逐漸形成策略化的判斷——而這在 METR 的那項研究中並沒有被納入考量。
當我們進一步追問，在那些已經使用 Claude 的任務類別中，它會如何影響該類別總體花費的時間和產出量時，一個有趣的模式出現了：幾乎在所有任務類別上，員工都報告了總體時間投入略有下降，而產出數量的增加更加明顯。
圖 2：在不同任務類別（縱軸）中，Claude 使用對“時間投入”（左圖）和“產出數量”（右圖）的影響。橫軸為自報的時間/產出增減（負值代表減少，正值代表增加，虛線為“無變化”），誤差條為 95% 置信區間，圓點面積與該評價點的回答數量成正比。只統計在該任務類別中使用過 Claude 的受訪者。
不過，進一步觀察原始數據會發現，時間節省的回答在分佈上呈現兩極——有些人在 Claude 輔助的任務上反而花了明顯更多的時間。
為什麼會這樣？人們普遍解釋説，他們需要花更多時間調試和清理 Claude 寫出的代碼（例如“當我自己隨手寫着寫着把自己寫進死衚衕時”），也要承擔理解 Claude 代碼的額外認知負擔，因為那不是自己一行行寫出來的。有些人則表示，花更多時間是“賦能意義上的多投入”——有人説，Claude 讓他們能“在以前馬上就會放棄的問題上堅持下去”；也有人説，它讓自己能做更全面的測試，並在新的代碼庫中投入更多學習和探索。從整體看，那些體驗到時間節省的人，很可能正是善於把“易驗證任務”打包交給 Claude 的人；而那些花了更多時間的人，則往往要為 AI 生成的代碼做更多調試，或者在模型需要大量引導的領域中工作。
從數據中也看不出，這些被節省出來的時間最終流向了哪裏——是投入到額外的工程任務、非工程任務、與 Claude 互動或審查其輸出，還是工作之外的活動？我們的任務分類框架無法覆蓋工程師時間分配的全部維度。此外，時間節省本身也可能受到自報偏差的影響。這些問題都需要進一步研究來拆解。
相比之下，產出數量的提升要更直接、更顯著：幾乎所有任務類別上，淨產出增加都更大。這一模式也很合理——受訪者報告的是“調試”這一類任務，而不是某一條具體的 bug。也就是説，即使在“調試”這個類別上花的總時間略有減少，人們依然可以完成更多的調試任務。從嚴格意義上講，生產力很難被直接測量，但這些自報數據至少表明：在 Anthropic，AI 主要是通過增加產出來提升生產力的。
Claude 讓哪些“新工作”得以發生？
我們很好奇的一點是：Claude 是否真的讓一些“以前不會做的事情”得以發生，還是説，它只是讓原本遲早會完成的工作變快了一些？
員工估算，在他們當前使用 Claude 完成的工作中，有約 27% 如果沒有 Claude 根本不會去做。工程師提到，會用 AI 來做項目擴展、各種“錦上添花”的事情（比如交互式數據儀表盤）、一些本身很有價值但很枯燥的工作，如寫文檔、補測試，以及那些如果完全人工來做就不划算的探索性嘗試。正如一位受訪者所説，他們現在可以修掉更多以前影響體驗、但一直沒有人騰出手去“收拾”的小問題，比如重構結構很差的代碼，或者寫一些“小工具”來加速其他任務。我們在 Claude Code 使用數據中也看到了類似現象：約有 8.6% 的任務可以歸類為“papercut 修復”。
另一位研究人員舉例説，他們會同時開啓很多個 Claude 實例，讓它們並行探索解決同一個問題的不同路徑：
人們往往把“超級強大”的模型想象成一個單一實例，就像換了一輛更快的汽車。但如果你有“一百萬匹馬”……你就可以同時嘗試很多不同的想法……當你有這麼大的探索廣度時，這件事會變得非常令人興奮、也更具創造性。
正如我們會在後面的章節裏看到的，這類“新工作”往往涉及工程師走出自己原有的專業舒適區。
到底有多少工作可以完全交給 Claude？
儘管工程師們非常頻繁地使用 Claude，但超過一半的人認為，真正“可以完全交給 Claude、不需要自己再驗證”的工作只佔自己總工作量的 0–20%。（值得一提的是，不同受訪者對“完全交給”這一説法的理解並不完全一樣——有的人指的是完全無需驗證，有的人則是指只需很輕量的檢查。）在解釋“為什麼不能更多完全交給 Claude”時，工程師描述的是一種高度主動、迭代式的工作方式：他們會和 Claude 來回對話、一起推進任務，並在過程中不斷驗證 Claude 的輸出——尤其是那些複雜任務或代碼質量要求極高的高風險領域。這説明，工程師們傾向於把 Claude 當作一個緊密協作的夥伴，而不是“黑箱外包方”，並且他們對“什麼算是可以完全交出去”設定了非常高的標準。
定性訪談
雖然問卷結果顯示了顯著的生產力提升和工作模式變化，但它們並不能回答一個關鍵問題：工程師在日常工作中，具體是如何體驗這些變化的？為此，我們對參與問卷的 Anthropic 工程師和研究人員中的 53 人進行了深入訪談，以理解他們在這場變革中的真實感受和思考。
AI 委託方式
工程師和研究人員正在發展出一系列策略，以更高效地在工作流中使用 Claude。總體而言，人們傾向於把下面幾類任務委託給 Claude：
|| 超出自己的熟悉上下文、但整體複雜度較低的任務：例如“我會把那些我自己上下文不太熟，但整體難度不高的問題交給 Claude。”又如“我遇到的大多數基礎設施問題並不算難，Claude 就能搞定……我對 Git 或 Linux 其實不太熟，但 Claude 在這些方面很好地幫我補上了經驗上的短板。” |
|| 容易驗證的任務：例如“對於那些驗證成本相對創建成本不高的事情，它簡直太好用了。” |
|| 邊界清晰、相對自洽的子問題：例如“如果一個子模塊和系統其他部分足夠解耦，我通常會先讓 Claude 試一把。” |
|| 代碼質量要求不那麼高的場景：例如“如果是一次性的調試或研究代碼，我通常會直接讓 Claude 寫。如果是概念上很難、或者需要非常特殊的調試注入，或者是設計問題，那我還是會自己來。” |
|| 重複、枯燥的事情：例如“我越興奮的一件事，就越不太會用 Claude；相反，如果我對一件事產生很大心理阻力，那通常我會先和 Claude 開個頭。”在問卷中，大家平均認為，自己用 Claude 完成的工作有 44% 是本來就不太想親自做的那種。 |
|| 寫提示比自己動手更省時間的任務：例如“如果我預估某件事我自己十分鐘以內能搞定，那我通常不會麻煩 Claude。”又比如“現在最大的問題其實是‘冷啓動’。所謂冷啓動，就是我腦子裏有很多關於我們團隊代碼庫的隱性信息，而 Claude 默認並不知道這些……我可以花很多時間去打磨一個完美的提示詞，但很多時候不如自己動手來得快。” |
這些員工提到的委託考量，與一項外部研究中發現的“AI 反而拖慢生產力”的情境高度一致（例如開發者對代碼庫非常熟悉、代碼倉庫規模巨大且複雜等）。這種內外研究在“什麼任務適合交給 AI”上的收斂表明，任務選擇本身很可能是影響 AI 生產力收益的關鍵因素——未來的生產力研究需要對這一點進行更精細的控制。
信任，但要驗證（Trust but verify）
很多用户描述了自己使用 Claude 的“信任演化過程”：一開始只是用它來問一些 Rust 之類語言的基礎問題……而最近，自己幾乎所有編碼工作都會用上 Claude Code。
有一位工程師把這種信任演化，比作自己使用 Google 地圖的過程：
一開始，我只會在不熟悉的路線用 Google Maps……這就像一開始我只用 Claude 來寫自己不太熟的 SQL，但不會讓它寫我很熟的 Python。後來，我會在大致熟悉的路線上也開着地圖，也許只是最後一段路不太確定……就像逐漸讓 Claude 參與我部分熟悉的任務。現在，即便是每天通勤的路線，我也一直開着 Google Maps。如果它建議我走一條不同的路，我通常會直接照做，相信它已經綜合考慮了各種因素……我今天用 Claude Code 的方式，其實很像這樣。
在“用 Claude 處理自己熟悉領域的任務，還是陌生領域的任務”這件事上，工程師們也出現了分化。有的人更傾向把 Claude 用在“邊緣領域”，以節省實現時間；有的人則更喜歡在熟悉的領域使用它，因為那樣自己更有能力驗證結果（“我用 Claude 的方式，是我始終對它在做什麼保持完整理解”）。一位安全工程師就強調了經驗的重要性：有一次 Claude 提出一個“非常聰明、但也非常危險”的方案，這種方案就像是一個很有才華但缺乏經驗的初級工程師會想出來的東西——只有具備判斷力和經驗的人，才能意識到這裏潛藏的問題。
還有一些工程師則兩種情況都會用 Claude，要麼是以一種“實驗”心態（“基本上遇到任何編碼問題，我都會先讓 Claude 打個樣”），要麼是根據自己在某個領域的熟悉程度，調整與 Claude 的分工方式：
如果是我非常熟悉的領域，我會更強勢一點，告訴 Claude 具體要去查什麼、怎麼做。如果是我不太熟的東西，我通常會讓 Claude 去當專家，讓它給我提供選項，指出我應該考慮和研究的方向。
人們會把什麼任務留給自己？
幾乎所有人都表示，他們不會用 Claude 來做那些涉及高層次或戰略性思考的任務，也不會把需要組織語境或“品味判斷”的設計決策交給 Claude。一位工程師説得很直接：“我通常會把高層思考和設計留在自己手裏，只要能交出去的事情，從新功能開發到調試，我都會盡量交出去。”這一點也在問卷數據中得到了印證——在設計和規劃類任務上，生產力提升是最有限的（見圖 2）。許多人也把這種“委託邊界”描述為一個“不斷移動的目標”，會隨着模型能力的演進而持續被重新劃線（Claude Code 使用數據也顯示，相比六個月前，現在用於代碼設計/規劃的使用佔比已經明顯提升）。
技能的變化
新的能力……
問卷中“有 27% 的 Claude 輔助工作本來不會被完成”這一發現，也映射出一個更宏觀的模式：工程師們正在用 AI 去做原本屬於自己核心技能範圍之外的事情。許多員工表示，他們完成了很多以前自己不太會做的工作——後端工程師開始搭前端界面，研究人員自己做可視化。有一位後端工程師回憶説，他通過和 Claude 反覆迭代，搭出了一個複雜的前端界面：“效果比我自己做的好太多了。按原來的節奏，我根本不可能在要求的時間內做完……設計師看到之後都驚訝地問：‘等等，這是你做的？’我説：‘不，這是 Claude 做的——我只是負責提需求。’”
工程師們普遍覺得，自己正在“變得更全棧”：“我現在非常有信心能做前端、事務型數據庫、API 代碼這些活兒，而以前我會有點怕碰這些不擅長的部分。”這種能力的擴展讓反饋循環變得更緊湊，也加快了學習速度——有人形容，以前需要“幾周時間、不斷開會、反覆迭代”的過程，現在可以在“幾個小時的工作會”裏完成，相關同事也可以在現場實時給反饋。
總體而言，大家對自己更快原型化、並行推進工作、減少重複勞動、提升目標雄心這一系列新能力都感到振奮。一位高級工程師説：“這些工具確實讓初級工程師更高效、更敢接大項目。”也有人提到，使用 Claude 讓自己更容易跨過“啓動門檻”，戰勝拖延症——“它大幅降低了我願意開始解決一個問題所需要的心理能量，因此我願意多接很多以前會一拖再拖的事情。”
……以及更少的“親手練習”
同時，也有不少人擔心，在越來越多事情交給 Claude 之後，自己的技能會“慢慢生鏽”，尤其是那些在手動解決問題過程中積累的“順帶收穫”的理解：
如果你完全自己去排查一個棘手的問題，你會花很多時間看文檔、看和問題不那麼直接相關的代碼——雖然這些內容對眼前這一個問題未必有用，但在整個過程中，你會慢慢構建起對系統的整體心智模型。現在，因為 Claude 能直接把你帶到問題所在，這樣的學習過程就少了很多。
我以前會自己把一個工具的所有配置項都翻一遍，以便真正理解它能做什麼；現在我更多是問 AI 該怎麼用，所以很多時候我缺少對工具的那種“肌肉記憶式理解”。以前和同事討論問題時，我可以很快地從記憶裏調出很多細節；現在則經常需要再去問 AI。
使用 Claude 的一個風險，是它可能會讓你跳過那種通過解決“簡單版問題”來練習的階段，然後在遇到“複雜版問題”時，反而因為缺乏底層經驗而很吃力。
一位高級工程師説，如果自己處在更初級的階段，他會更擔心這一點：
我現在主要是在自己知道答案是什麼、或者大致知道答案長什麼樣的情況下用 AI。我是通過“按傳統方式”做了很多年軟件工程積累出這種判斷能力的……但如果我還在職業早期，我會認為，想要在這種環境裏持續提升自己的能力，需要付出很多刻意練習，而不能只是盲目接受模型的輸出。
技能萎縮之所以讓人擔心，很大一部分原因在於“監督悖論”：如前面所説，高效使用 Claude 需要監督，而要監督 Claude，你又需要那些可能因為過度依賴 AI 而萎縮的編碼技能。正如一位受訪者所説：
説實話，我比起自己的技能，更擔心的是監督和管控的問題……我的技能如果萎縮或停滯，真正的問題在於，我對自己使用 AI 完成重要任務是否足夠安全、是否有能力發現它的漏洞，而不是在於我究竟還能不能自己一個人把這件事從頭做到尾。
為此，有些工程師會刻意“斷網練功”——在明知道 Claude 可以很好解決問題的情況下，刻意選擇不用：
偶爾，我明明知道 Claude 能十拿九穩解決一個問題，也會刻意不去問它。這算是給自己的一個“小訓練”，讓自己保持敏鋭。
這些動手編碼能力，將來還重要嗎？
也許軟件工程正在進入一個新的抽象層級，這在歷史上已經發生過很多次。最早的程序員工作在非常貼近機器的層面——手動管理內存，用匯編語言寫程序，甚至通過撥動物理開關來輸入指令。後來，更高級、更易讀的編程語言出現，它們自動處理了很多底層複雜操作。也許，隨着所謂“vibe coding”的興起，我們正走向一個“英語就是編程語言”的時代。有人建議，未來想做工程師的人應該“先學會如何讓 AI 寫代碼，把更多精力放在學習高層概念和模式上”。
有些員工覺得，這種轉變讓他們能在更高的層面上思考——“更多去想最終產品和最終用户，而不僅僅是代碼本身”。有人把當前的變化類比為以前必須在計算機課程裏學鏈表這類底層數據結構——這些結構現在早已被高級語言封裝好了。“我很高興自己曾經學過這些……但從情感上講，一遍遍做這些底層操作對我來説並不重要。我更在意的是，代碼能讓我真正做成什麼。”也有人做了類似的比較，但同時指出，抽象的提升也意味着代價——隨着大家對高級語言的依賴，絕大多數工程師對內存管理失去了深入理解。
在某個領域持續打磨技能，確實可以讓你更好地監督 Claude，也更高效地與之合作（“我發現，在我熟悉的領域裏，很多時候自己做反而更快”）。但工程師們在“這是否重要”這個問題上並不一致。有的人相對樂觀：
我對技能退化並沒那麼擔心。AI 仍然會迫使我認真思考問題，也幫助我學習新的解法。在某些領域，能夠更快地探索和測試想法，反而加速了我的學習。
也有人更務實：
作為一名軟件工程師，我的技能肯定是在退化的……但如果哪天真的需要，我相信這些技能還是能練回來，而且現在我也確實不再那麼需要它們了！
還有人提到，自己失去的更多是畫圖之類的次要技能，“真正關鍵的那部分代碼，我仍然能寫得很好”。
也許最有意思的是，有工程師直接質疑了“會不會變生鏽”這一前提：
把這件事叫做“變生鏽”，是假定有一天世界會回到 Claude 3.5 之前的那個樣子。我並不認為那樣的日子會再回來。
軟件工程的“手藝感”和意義
工程師們在“是否懷念親手寫代碼”這一點上出現了明顯分歧。有的人有真切的失落感——“對我來説，這真的是一個時代的結束。我寫代碼寫了 25 年，對自己在這方面的熟練掌握，一直是我職業滿足感的重要來源。”也有人擔心，自己可能並不會喜歡未來這種新的工作形態：“整天在那兒給 Claude 寫提示詞，其實並沒有那麼有趣或有成就感。相比之下，戴上耳機放點音樂，自己進入心流狀態、從頭到尾實現一個東西，要好玩得多。”
也有人正面承認了這種取捨並表示接受：“寫代碼這件事，確實有一些部分是我會懷念的——比如在重構時進入那種‘禪意流’的狀態。但總的來説，我現在的生產力提升太大了，為了這個結果，我願意把那種體驗放下。”
還有人覺得和 Claude 一起迭代反而更好玩，因為“我可以比對人更挑剔”，不用顧及對方的情緒。也有人更在意結果而不是過程。有一位工程師説：
我原本以為，到這個階段我會感到害怕或無聊……但事實上，我並沒有這些感覺。相反，我很興奮，因為我現在能做的事情多太多了。我曾以為自己喜歡的是寫代碼這件事本身，但現在我發現，我真正喜歡的，是寫完代碼之後能得到的那些東西。
從整體來看，人們是否擁抱 AI，還是更懷念“親手寫代碼”的時代，很大程度上取決於他們覺得軟件工程這份工作中，哪一部分對自己最有意義。
工作場所的社交動態在改變
訪談中一個很突出的話題，是 Claude 已經取代了很多過去會直接問同事的問題，成為第一諮詢對象。“我現在問問題的頻率比以前高多了，但差不多 80–90% 的問題我都是先問 Claude。”有員工這樣總結。這在一定程度上起到了“信息過濾器”的作用——Claude 會先處理那些日常、重複的問題，而同事們則更多被用來討論複雜的、戰略性的，或高度依賴組織上下文的問題（“它讓我的團隊對我來説‘不那麼必要’了 80%，但剩下那 20% 非常關鍵，我仍然會去找他們。”）。人們也會把 Claude 當成“頭腦風暴搭檔”，像和人一樣用它來對撞想法。
大約有一半的受訪者表示，團隊的合作模式並沒有發生太大變化。有一位工程師説，他仍然會和同事開會、共享上下文、一起做方向選擇，他認為在可見的未來，依然會有大量的人與人協作，“只不過，平時專注做事的那段時間裏，你會更多地在和各種 Claude 對話”。
但也有人切實感受到，和同事的互動變少了（“我現在和 Claude 的互動遠比和任何一個同事都多。”）。有些人對這種變化感到滿意，因為這樣可以減少社交摩擦（“我不再需要擔心打擾同事佔用他們的時間。”）。但也有人不太喜歡這個趨勢（“我其實不太喜歡大家動不動就説‘你問問 Claude’，我真的很享受和人面對面一起工作的感覺，也非常看重這種體驗。”），或者懷念過去的工作方式：“我很喜歡和人一起工作，現在有點難過的是，我似乎‘不再那麼需要他們’了。”不少人也指出，這對傳統的“師徒式指導關係”有明顯影響——因為許多過去會由高級工程師承擔的指導，現在可以由 Claude 提供。“Claude 可以給初級同事提供很多指導和教練式幫助。”一位高級工程師説：
讓我有點難過的是，初級同事不再像以前那樣經常來問我問題了，雖然實話實説，他們現在確實更快地得到答案，也學得更快。
職業不確定性與適應
許多工程師覺得自己的角色，正在從“寫代碼的人”變成“管理 AI 的人”。越來越多人把自己看作是“AI 代理的管理者”——有人表示，自己幾乎總是同時開着好幾個 Claude 實例。有人估計，自己的工作內容中，已經有“70% 以上是做代碼評審/修改，而不是從零寫新代碼”；也有人認為，將來“對 1 個、5 個甚至 100 個 Claude 的工作負責”，會成為自己角色的一部分。
從長期來看，職業上的不確定性非常普遍。工程師們普遍認為，這些變化是整個行業更大轉型的前兆，很多人都説“很難判斷”幾年之後，自己的職業會變成什麼樣。有些人對短期和長期的態度是矛盾的——“短期我很樂觀，但長期我覺得 AI 最終會把所有事情都做掉，讓我和很多人變得不再重要。”還有人説得更直接：“有時候感覺，每天上班都像是在把自己一步步‘做沒’。”
也有工程師更為樂觀。有一位説：“我確實替初級開發者有點擔心，但也知道他們往往是對新技術最有熱情的那羣人。整體來説，我對這個職業的未來還是非常樂觀的。”他認為，儘管確實存在那些經驗不足的人用 AI 寫出問題代碼的風險，但隨着 AI 安全措施的完善、教育資源的不斷嵌入，以及人們在實踐中從錯誤中學習，這個行業會逐漸適應並找到新的平衡。
當我們問工程師們如何設想自己的未來角色，以及是否有應對策略時，有人提到，會進一步向某些方向深度專精（“真正具備對 AI 工作做有意義 review 的能力，會需要更長時間的積累和更高程度的專門化”）；有人預計未來會更多投入到“人與人”的工作和戰略性事務上（“我們會把更多時間花在達成共識上，讓 AI 花更多時間在具體實現上”）。也有人已經開始有意識地用 Claude 做職業發展——向它尋求關於工作方法、領導力等方面的反饋：“我能學習和發揮的速度完全變了感覺，就像頭頂的天花板一下子碎掉了。”
總體來看，很多人都坦言，自己對“未來哪些技能會有用”幾乎沒有什麼把握。一位團隊負責人總結説：“其實沒人真正知道會發生什麼……真正重要的是你是否足夠有適應能力。”
Claude Code 使用趨勢
問卷和訪談數據顯示，越來越多的 Claude 使用，正在幫助人們更快推進工作、承擔更多以前不會做的任務，但同時也帶來了圍繞“任務委託”和“技能發展”的各種緊張和矛盾。當然，自報數據只講了故事的一部分。為了補全這一點，我們還分析了 Anthropic 團隊內部真實的 Claude Code 使用記錄。因為受訪者表示，他們的大部分 Claude 使用都是在 Claude Code 中完成的，我們利用一個隱私保護的分析工具，對 2025 年 2 月和 8 月的 20 萬條內部 Claude Code 對話記錄進行了分析。
在更少監督下解決更難的問題
在過去六個月中，Claude Code 的使用正在向更困難、更自主的編碼任務遷移（見圖 3）：
- 員工正在用 Claude Code 解決越來越複雜的任務。 我們為每條記錄估計了一個 1–5 的任務複雜度評分，其中 1 代表“非常基礎的編輯”，5 代表“需要人類專家投入數週或數月的工作”。平均而言，任務複雜度從 3.2 提升到了 3.8。為了更直觀地感受差異，3.2 左右的任務通常是“排查 Python 模塊導入錯誤”之類，而 3.8 左右的任務則會是“實現並優化緩存系統”。
- Claude Code 在單次任務中連續調用工具的最大次數增加了 116%。 這裏的“工具調用”指的是 Claude 使用外部工具做出的動作，例如修改文件或運行命令。現在，Claude 在無需人類干預的情況下，可以連續串聯平均 21.2 次工具調用，而六個月前這個數字只有 9.8。
- 每條對話中人類發言輪次減少了 33%。 平均人類發言輪次從 6.2 降到 4.1，這説明現在完成同樣複雜的任務，所需的人類輸入比六個月前更少了。
圖 3：2025 年 2 月與 8 月之間 Claude Code 使用情況的變化。左圖為平均任務複雜度，中圖為每條記錄中連續工具調用的最大次數，右圖為人類發言輪次。誤差條為 95% 置信區間，整體上看，人們正在把更多自主性委託給 Claude。
這些使用數據與問卷的定性結論相互印證：工程師正在持續把更復雜的工作交給 Claude，且 Claude 所需的人類監督也在減少。這很可能是我們觀察到的生產力提升背後的重要驅動力之一。
任務分佈
我們把 Claude Code 的記錄按任務類型進行了分類，並對比了過去六個月中，不同任務類型在整體使用中的佔比變化：
圖 4：不同編碼任務（縱軸）在所有記錄中所佔比例（橫軸）。粉色為 6 個月前的分佈，紫色為當前分佈，按 2025 年 2 月的頻率排序。
整體任務頻率分佈與自報數據大致一致。最顯著的變化，是現在用於實現新功能的記錄佔比明顯提高（從 14.3% 到 36.9%），用於代碼設計或規劃的佔比也有明顯提升（從 1.0% 到 9.9%）。這種相對分佈的變化，可能説明 Claude 在這些更復雜任務上的表現變好了；當然，也可能僅僅反映了團隊在不同工作流中採用 Claude Code 的方式發生了變化，而不一定意味着絕對工作量的增加（更多限制與説明見附錄）。
修補“紙割傷”
我們從問卷中瞭解到，工程師現在花更多時間做那些“改善日常體驗的小修小補”；與此相呼應的是，大約 8.6% 的 Claude Code 任務被歸類為“papercut 修復”。這些任務既包括構建性能可視化工具、為可維護性而做的大規模重構等較大工作，也包括創建終端快捷方式這樣的小改動。這些工作可能一方面提升了自報的生產力（長期來看，修復那些一直積累的“小摩擦點”會讓整體效率提高），另一方面也減少了日常工作的挫敗感和阻力。
不同團隊的任務差異
為了研究不同團隊之間任務類型的差異，我們進一步細化了任務分類方法，為 8 月的每條記錄分配了一個主要任務類型，並按內部團隊進行拆分。下圖中的堆疊柱狀條展示了各團隊中不同任務類型的比例：
圖 5：每一條橫向柱代表一個團隊（縱軸），不同顏色的片段代表該團隊中 Claude Code 使用在不同任務類型上的佔比（橫軸）。頂部的“All Teams”條代表整體分佈。
“All Teams” 這一條給出了整體的分佈基線，其中最常見的任務是新功能構建、調試和代碼理解，在此基礎上，其他團隊的分佈可以對照比較。
一些值得注意的團隊特徵包括：
- 預訓練（Pre-training）團隊（負責訓練 Claude）非常頻繁地用 Claude Code 來構建新功能（佔比 54.6%），其中很多是用來跑額外實驗。
- Alignment & Safety 團隊和 後訓練（Post-training） 團隊在前端開發上的使用佔比最高（分別為 7.5% 和 7.4%），通常是為了構建數據可視化界面。
- 安全（Security） 團隊經常使用 Claude Code 來做代碼理解（佔比 48.9%），尤其是用於分析和理解代碼庫中不同部分的安全影響。
- 非技術背景員工 通常用 Claude Code 做調試（佔比 51.5%），例如排查網絡問題或 Git 操作問題，同時也會用於數據科學任務（佔比 12.7%）；Claude 在這裏起到了幫助他們跨越技術門檻的作用。
這些團隊特定的模式，和我們在問卷和訪談中看到的“能力擴展”現象相呼應：許多團隊正在利用 Claude 來完成那些原本沒有時間或能力去做的工作。例如，預訓練團隊可以跑更多實驗，非技術員工能夠自己修復代碼錯誤。而從數據看，團隊確實會用 Claude 做各自的核心任務（例如基礎設施團隊最常用 Claude Code 做基礎設施和 DevOps 相關工作），但 Claude 同時也在拓展他們的核心任務邊界（例如研究人員通過 Claude 來做前端開發，以便更好地可視化自己的數據）。整體來看，Claude 正在幫助每一個人變得更加“全棧”。
展望未來
過去一年裏，Anthropic 員工對 Claude 的使用大幅增加，他們不僅用它來加速原本就會做的工作，還用它來熟悉新的代碼庫、減少重複勞動、拓展自己的技能邊界，並處理那些長期被忽視的改進事項。隨着 Claude 變得更加自主和強大，工程師們也在不斷摸索新的任務委託方式，同時思考，在這種環境下未來需要什麼樣的技能。這些變化帶來了非常實在的生產力和學習收益，但也伴隨着對軟件工程長期走向的真切憂慮：這次的變化，會像過去從低級語言到高級語言的過渡那樣，僅僅是一個新的抽象層？還是會走得更遠，把我們對“工程師”的定義也重新寫一遍？
眼下仍然是這場轉型的早期階段——Anthropic 內部擁有大量早期採用者，外部環境變化也極其迅速，我們的發現未必能直接推廣到其他組織或場景（更多侷限見附錄）。這些研究結果某種程度上也反映了這種不確定性：結論往往是多面的，並沒有一個統一的“正確答案”或明確的行動指令。但它確實提出了一個問題：我們要如何在這樣的變革中，更加審慎而有效地前行？
作為這項工作的後續，我們正在做幾件事：與 Anthropic 的工程師、研究人員和管理層持續對話，討論如何迴應這次轉型帶來的機會與挑戰；重新審視我們如何讓團隊之間更好地協作與共享上下文，如何支持員工的職業發展，以及如何建立適合 AI 協作時代的工作實踐指南（例如藉助我們提出的 AI 素養框架）。我們也準備將視角擴展到工程師以外的角色，去理解 AI 轉型在整個組織範圍內的影響，並支持像 CodePath 這樣的外部機構，在 AI 輔助已成常態的未來，重新設計計算機科學教育。向前看，我們也在思考，在 AI 能力持續提升的背景下，可能需要怎樣的組織結構變革——比如為角色演化和再培訓設計新的路徑。
我們預計會在 2026 年分享更具體的計劃。Anthropic 希望在“負責任的職場轉型”上，既是研究對象，也是實踐場——我們不僅想研究 AI 如何改變工作，更希望從自身出發，探索如何更好地面對這場變化。
原文：How AI Is Transforming Work at Anthropic
作者：Saffron Huang, Bryan Seethor, Esin Durmus, Kunal Handa, Miles McCain, Michael Stern, Deep Ganguli
原文鏈接：https://anthropic.com/research/how-ai-is-transforming-work-at...
