在網頁上查看此文章:https://newsletter.pragmaticengineer.com/p/measuring-ai-dev-tools
目前看來,幾乎每家科技公司都在改變其開發者工具堆疊,這與十八個月前的情況相比是一個巨大轉變——當時對於「用什麼進行AI輔助編碼?」這個問題的答案很簡單:購買GitHub Copilot授權並啟動ChatGPT。在我們2024年的AI工具調查444f8537-f5ff-4977-864f-cb8d81464698中,這兩款工具被提及的次數超過所有其他工具的總和。
但現在不同了。如今,有大量工具在各方面超越了Copilot,例如Cursor、Claude Code、Codex和Gemini CLI,此外還有AI程式碼審查工具如CodeRabbit、Graphite和Greptile,更不用說所有可接入代理工具(agentic tools)的MCP整合。
因此,在這篇深度分析中,我詢問了10家科技公司他們的工程師使用哪些工具,以及關鍵在於他們如何在眾多選項中做出選擇。這些企業的規模從5人的種子期新創公司,到擁有1,500名員工且已公開上市的公司不等。除了Wealthsimple和WeTravel外,其他公司均匿名。WeTravel還慷慨地分享了我迄今為止見過最詳細的衡量框架。
我們涵蓋的內容包括:
**速度、信任與展示分享:小型團隊如何選擇工具**:在工程師少於約60人的地方,工具決策快速且非正式:開發者試用幾週,那些能「留下來」的工具就勝出。
**中大型公司如何選擇:官僚主義、安全性與供應商鎖定**:在擁有約150名工程師的公司,採用過程會因安全審查、合規要求和高層預算考量而顯著放緩。
**衡量難題:需要指標但無一有效**:每個工作場所都難以證明其AI工具有效,而像「AI生成的程式碼行數」這類常見指標不被工程師信任。
**Wealthsimple如何衡量與決策**:這家加拿大旗艦消費金融科技公司進行了為期2個月的選擇流程來挑選AI程式碼審查工具。將Claude Code推廣給所有工程師是技術長(CTO)的決定,基於個人信念並透過Jellyfish的使用數據驗證。
**一家公司如何準確衡量程式碼審查的有用性**:WeTravel建立了一個結構化的-3到+3評分系統,涵蓋五個維度,由五名工程師評估約100條評論。他們發現沒有適合其程式碼庫的AI程式碼審查工具。
**大型金融科技公司的比較衡量**:一個團隊在約50個PR(拉取請求)上同時運行Copilot、Claude和Cursor,評分約450條評論。他們發現Cursor的審查最精確,Claude最平衡,Copilot最注重品質。
**常見模式**:開發者信任比強制命令更能推動採用,Copilot → Cursor → Claude Code的遷移路徑已被廣泛實踐,且目前尚無人破解生產力衡量難題。
本文的目標是展示不同規模的科技公司正在做什麼,並就衡量和比較工具提供一些指引。這很難,但並非不可能,如下面兩個深入的案例研究所說明的。
別忘了,重要的是找到適合你團隊的工具。在這項研究中,我發現有些供應商被某家公司喜愛,卻在其他工作場所被厭惡。沒有一個供應商能在所有情境下被每個團隊普遍好評。
一如既往,我與本文提到的任何供應商均無關聯,也未因提及任何供應商而獲得報酬。我曾是Graphite的投資者ee8db26c-abd1-4ed8-b6c6-e01a06863021,但現在已不是。更多詳情,請參閱我的道德聲明。734efa3a-9638-4c84-99b0-e42aaaa12c32
本文底部在某些電子郵件客戶端中可能被截斷。請在線閱讀完整文章。5808936e-9352-41cb-8bb4-dc68717d23e2
**1. 速度、信任與展示分享:小型團隊如何選擇工具**
在我們調查中規模最小的企業裡,決策是非正式且快速做出的,決定性因素是人們對工具的感受。試用期很短,大約兩週,個別開發者對工具是否被採用或被棄用有著超乎尋常的影響力,決策會自然擴散。以下是兩個例子:
**種子期物流新創公司(20人,5名工程師)**
這家新創公司的工程主管將他們的方法描述為高信任度且由開發者主導:
「我們同意試用新工具兩週,看看大家的感受。我們沒有使用任何硬性的衡量標準。簡而言之:我信任我們的開發者,他們的意見是決策的重要部分。」
開發者在那裡建議試用哪些工具,並決定是繼續使用還是尋找替代方案。對於AI程式碼審查,團隊首先試用了Korbit大約一週,但感覺該工具「不對勁」,於是他們試用了CodeRabbit,後者在幾天內就「留下來了」:
「使用CodeRabbit幾天後,我就能看出開發者們就是喜歡它,並且接受了它的建議,不像對Korbit那樣失去了信任。」
就這樣:決策完成。作為一個小團隊,轉向更好的工具很容易,只需要一名工程師提出建議。
這家新創公司更廣泛的工具堆疊在過去一年中快速演變:
* **Figma** 用於設計,與Linear配合良好。公司有5名開發者和1名UX設計師。 * **Linear** 用於工單管理以及UX和開發之間的協作。UX人員在Figma設計旁邊創建Linear工單。 * **Claude Code** 和 **Cursor** 用於開發,透過MCP連接到Linear。 * **Claude Code** 編寫工單:最近的一個變化與CodeRabbit配合良好,因為有更多上下文傳遞給下游進行AI程式碼審查。 * **「展示分享」**——團隊成員在每週團隊會議和演示中向同事展示他們的工具設置——被這家新創公司用來識別哪些工具有效或無效:
「我們的展示分享過程幫助很大。有太多新工具、技能、IDE等,可能會讓人不知所措。我們都從觀摩團隊其他人在做什麼中學習。」
團隊明確區分了像Claude和CodeRabbit這樣期望所有人都使用的公司級工具,以及開發者的個人環境(IDE選擇、終端機設置),後者個人擁有完全自主權。
到目前為止,幾乎所有人都已遷移到Claude Code,但六個月前,團隊在Cursor和Claude Code之間平分秋色。工程主管說:
「我們曾有一段時間有一位開發者不願意使用Cursor或Claude。我們沒有強迫他,但很明顯其他人似乎交付了更多程式碼,而他的品質卻跟不上。」
**A輪融資新創公司(30人,15名工程師)**
該公司的一位資深工程師表示,團隊在Cursor與Claude Code之間存在分歧,後者勢頭正勁。他還說程式碼審查令人頭痛:
「我們的主要挑戰之一是程式碼審查,因為產生的程式碼量增加了,而品質在Opus 4.5之前曾經下降。」
他們評估了三種程式碼審查工具:Cursor的Bugbot(還可以但不突出)、Graphite(不好)和Greptile(好)。他們現在正在試用Greptile進行PR批准,利用其置信度評分功能。
對這個團隊來說,真正有效的是維護詳盡的`Agents.md`和`Claude.md`文件,這些文件非常方便,因為它們被以下工具使用:
* Claude Code和Cursor用於編碼 * Greptile用於程式碼審查
這兩個文件有助於在整個工具鏈中維護編碼風格指引的單一事實來源。
一位資深工程師讚揚了Cursor與Linear和Slack的整合:
「我個人非常喜歡的另一種流程是Cursor雲端代理,因為它們與Linear/Slack的整合非常好。對於較小的變更,這意味著程式碼甚至不需要簽出,而是直接從Cursor代理,到GitHub,再到部署。」
**D輪融資可觀測性公司(150人,60名工程師)**
該公司的開源總監總結了那裡留下來的東西:
「我們嘗試了很多東西(Graphite等),但真正留下來的是公司的Claude Code訂閱——這是最明確的價值增值。我們經常根據使用量增加將人員升級到更高階層,而其他工具大多閒置。」
這家公司一個有趣的訊號是非工程師也開始使用Claude Code。產品經理、解決方案工程師和技術客戶經理都比一般工程師更頻繁地使用它,他們透過直接開啟Claude Code PR來處理客戶錯誤報告:
「他們可能比一般工程師更常使用Claude Code!他們已經能夠用Claude Code PR處理客戶的『小問題』(痛點)。」
**2. 中大型公司如何選擇**
在擁有150名以上工程師的公司,決策不再取決於工具的「感覺」。相反,現有的供應商關係可能是決定性的,而且通常來自C級(領導團隊)的壓力,以及需要解決的安全和合規問題。
還有一個新的挑戰是如何在幾個部門和可能數百名工程師之間協調工具推廣。這就是果斷的技術長可以突破官僚程序以實現更快採用的地方。我們的第一個案例研究涵蓋了一家金融科技公司是如何做到這一點的。
**總部位於歐盟的軟體公司(500人,150名工程師)**
這家公司的經驗是一個警示故事,說明當領導層在沒有後續計劃的情況下推進AI工具時可能發生的情況。那裡的一位資深工程師說:
「在2025年夏天,我們的領導團隊從一次場外會議回來,宣布我們現在是AI優先,這轉化為每個人都獲得Copilot Business訂閱——如果他們碰巧要求的話。問題解決了,對吧?」
但並非如此,因為Copilot的推廣立即引發了關於替代方案的問題:
「我們公司與微軟的既有關係可能是關鍵:我們已經有了M365,然後他們向所有開發者推出了Copilot。 人們立即對其他工具提出了疑問。我們中一些人在那個夏天使用了Claude Code,而其他人則使用了Cursor或Gemini CLI。 2025年下半年新模型和工具的速度讓領導團隊完全措手不及。他們也沒有為每月19美元以上的Copilot訂閱之外的任何東西編列預算。」
他們被「卡住」了,六個月內無法批准任何新工具。由於法律和IT部門陷入僵局,加上歐盟的《AI法案》引發了擔憂和治理問題,創建正式批准流程的嘗試停滯了:
「由於官僚主義和歐盟法規,我們正面臨採用挑戰。我敢肯定,這個過程導致了開發者自費使用未經批准的工具。」
與此同時,他們預設的Copilot設置使用的是GPT 4.1,一個10個月前的舊模型。那裡許多開發者不知道是否可以更改模型或使用編碼代理。這造成了一個惡性循環:工具感覺不夠好,從而抑制了採用,並使得為更好的選項進一步投資更難證明其合理性。
**雲端基礎設施公司(900人,300名工程師)**
該公司負責AI工具的一位首席工程師描述了開發者熱情與高層審查之間持續的拉鋸戰:
「我們從Copilot開始,因為它易於採購,畢竟我們是微軟M365的客戶。然後轉向Cursor花了很長時間。價格不斷變化。與此同時,高管們讀了一份文件,不斷問『為什麼我們不用Claude Code?』」
這個問題的答案也來自高管團隊:價格。高管們根本不想投資這些工具,價格仍然是持續的頭痛問題。Claude的團隊計劃約每月150美元,Cursor的約每月65美元,而這家公司的C級領導不願意從Copilot的每月40美元轉向Cursor的每月65美元。這位首席工程師還擔心,即使獲准轉向Claude Code的每月150美元,成本也會持續上升:
「Claude Code和Codex現在肯定在承擔成本……我們都知道這不會持續。如果我的高管們在這方面給我壓力,我將不得不說——『好吧,我們的開發者在6個月內速度慢了很多,但現在我們需要支付每月250美元,每個開發者,以獲得更高的限額』。」
**公開上市的旅遊公司(1,500人,800名工程師)**
該公司的一位資深工程師強調供應商鎖定是主要擔憂:
「我們的主要擔憂是避免被單一解決方案鎖定。考慮到這一點,我預計今年將繼續評估AI工具,因為事情仍在快速演變。」
他們去年推出了GitHub Copilot,現在正在評估Claude Code作為替代品。考慮到Claude的每位工程師成本高昂,他們仍然保持謹慎。
**公開上市的科技公司(2,000人,700名工程師,生產力領域)**
該公司負責開發者生產力的工程領導者稱安全性是最大挑戰:
「對我們來說最大的障礙是安全性。我們正在尋找一定程度的合規性,我發現開發工具新創公司在A輪後期/B輪融資之前並未優先考慮這一點。這有助於我們集中精力,確保我們評估的工具在行業中已經通過了一些審查,而不會讓我們感覺落後。」
毫不奇怪,在這個規模的公司,工具選擇過程更加深入,有許多供應商作為選項。以下是他們的做法:
「在知道如何優先考慮供應商時,需要一些直覺。我們的流程是這樣的: 1. 我們從其他公司的朋友和同事那裡聽到的 2. Twitter/Reddit/Hacker News上的討論 3. 知道如何識破炒作」
他說評估更有組織性,且試用很常見:
「每個工具都必須推動一個指標。那些直接影響我們已經關心的指標的工具會更快獲得批准。那些理論上可能影響指標,但沒有直接可衡量影響的工具,需要更多工作。指標故事越弱,敘事就必須越強。 我們喜歡在決定擴展或終止一個工具之前,至少捕捉兩週的試用使用情況。」
**3. 衡量難題:需要指標但無一有效**
如果說有一個主題將本次深度分析中的每家公司——無論規模大小——聯繫在一起,那就是難以衡量AI工具是否真的有效。
高管們想要數據,但工程師不信任現有的數據。與此同時,供應商自己的指標大多無用。
在我們的研究樣本中,總部位於歐盟的軟體公司討論了各種選項,只發現了糟糕或更糟的選擇:
* 使用「AI編寫的程式碼行數」指標會產生不良激勵,公司內的AI愛好者和懷疑論者都認同這一觀點。 * 即使他們堅決要使用程式碼行數,是否有辦法區分出那些創造商業價值的程式碼行? * 還有一點是,AI的一些最有價值的用途不在於編寫程式碼,而在於研究、創意生成、除錯等,這使得衡量AI工具生成的程式碼成為一條死胡同。與此同時,基於感覺編寫的腳本和從未投入生產的工具,可能感覺像是真正的生產力突破。
最終,這家公司選擇了Copilot生成的程式碼行數作為「官方」指標,這引起了可預料的回應:
「你可以想像開發者對此的反應有多差!它甚至沒有考慮到Copilot的這個指標純粹基於特定IDE的遙測數據。所以,即使你使用Copilot CLI編寫程式碼並用盡了你的高級請求額度,也不會被計入。」
那家900人雲端基礎設施公司的首席工程師更為直率:
「我的工程部門正在迷上AI,但高管們想要關於價值增值的指標。我不想為了證明開支合理而推動虛榮的使用指標,但除了虛榮指標,我沒有什麼有價值的東西可以展示!」
這位首席工程師駁斥了開發者生產力供應商自己的衡量方法:
「我與DX和另一家供應商談過,他們只是將DORA+Velocity指標與他們能從Cursor、Claude等的API獲得的任何數據結合起來。當然,這在紙面上看起來不錯:團隊A更快,而且他們使用AI。但AI使用和速度之間真的有相關性嗎?」
這位首席工程師說,一個根本問題仍未得到解答:
「我們如何有效利用我們的AI代理訂閱?到目前為止,根據我的經驗,這個問題沒有答案——甚至連一點線索都沒有。」
**4. Wealthsimple如何衡量與決策**
Wealthsimple是一家加拿大金融科技公司,僱用約1,500人,其中約600人是工程師。我與技術長Diederik van Liereca6d561b-5a5d-45a2-bd30-5a385dbd00ef討論了他們如何選擇AI程式碼審查和AI編碼工具。對於AI程式碼審查工具,他們進行了徹底的衡量流程;對於AI編碼工具,更多是來自Diederik的推動。他分享了關於他們具體衡量流程以及他們如何最終選擇Graphite進行程式碼審查和Claude Code進行編碼的獨家細節:
**透過「比拚」流程選擇AI程式碼審查工具……**