AI 每月生成 10 億行程式碼——增長 76%——開發者熱議：為什麼程式碼行數不等於生產力

Greptile——一款被 2000 多家公司採用的 AI 程式碼審查智慧體——釋出了其 AI 輔助程式設計年度報告。該報告基於 每月由 AI 稽核的 10 億行程式碼 資料，描繪了一幅生產力顯著提升的圖景。然而，在開發者社群的討論中——尤其是在 Y Combinator 論壇——不少工程師卻表示，真實體驗遠沒有報告所呈現的那樣簡單。

有一個核心結論幾乎無法忽視：在 AI 的支援下，工程師正在提交更多程式碼。

根據 Greptile 的資料，開發者 每月提交的程式碼行數 從 4450 行 提升至 7839 行，增長幅度達到 76%。對於 6–15 人的中型團隊，增幅更為誇張——人均提交量幾乎翻倍，提升 89%。換句話說，AI 程式設計工具正越來越多地扮演著 “效率放大器” 的角色。

報告還指出，程式碼變化不僅更快，而且 單次迭代的規模也更大。

在一次提交中，每個檔案的程式碼變更行數中位數 提升了 20%，從 18 行增加到 22 行。這一變化意味著，開發者在每次修改中覆蓋的範圍更廣，也可能表明 AI 工具正在被用於更復雜的改動和不斷演進的需求，而不再只是簡單的自動補全。

儘管如此，許多程式設計師的反應依然謹慎，甚至帶著懷疑。

在 Y Combinator 論壇上，一個常見的觀點是：AI 生成的程式碼往往需要花大量時間進行除錯、修改和清理，而這些真實投入並未被“提交行數”這樣的指標捕捉到。邊界情況、系統整合問題、隱蔽的 Bug——這些摩擦成本幾乎不會出現在宏觀統計圖表中。

最核心的質疑其實很直接：程式碼行數增加，並不必然等於生產力提升。

一個初級開發者可能需要幾十行程式碼才能實現的功能，資深工程師用幾行就能完成。與此同時，如果 AI 讓程式碼總量變多了，那麼 後續被刪除、重寫或重構掉的程式碼 又該如何計算？這些資料並不容易統計，但往往正是生產力真正提升或下降最明顯的地方。

還有一種觀點，直接挑戰了“用行數衡量效率”的前提假設。

如果所有工程師能力相同、任務複雜度也一致，那麼產出更多程式碼或許能代表效率更高。但現實中的工程工作並不均質。有些任務非常困難，需要深厚經驗，卻只產生很少的程式碼；有些任務很簡單，卻天生冗長。只看提交量，本質上是把所有任務都當成“中等難度”來衡量，必然失真。

程式碼質量，是另一個被忽略的關鍵維度。

這份報告強調數量，卻並未直接評估新增程式碼是否 更好、更安全、更易維護。從另一個角度看，每一行額外的程式碼都是一種負擔，而不是資產——它需要被測試、審查、維護，並在未來被除錯。最終，團隊仍然需要領域專家來判斷：到底應該存在多少程式碼。

一位評論者用一個生動的比喻點出了問題的本質。

你可以通過“每小時搬運多少件物品”來衡量倉庫員工的效率。但如果有人開始 隨意扔箱子，或者搬運本來不需要移動的貨物，他們就能最大化這個指標，卻反而損害了整體運營。

AI 的確能幫助開發者生成更多程式碼，但真正的問題在於：這些程式碼是否真的有必要，才能完成目標？

如果組織只獎勵更高的提交量，可能會無意中鼓勵重複勞動、過度設計和程式碼膨脹。僅僅衡量“提交的行數”，很容易從結果指標變成被刻意最佳化的目標。

從這個角度看，也許 “編輯的程式碼行數” 比 “新增的程式碼行數” 更合理。

這樣一來，通過重構來縮小程式碼庫規模，仍然可以被視為高生產力行為。一個簡單的思路是：刪除一行程式碼得 1 分，新增一行程式碼也得 1 分——鼓勵有意義的改變，而不是單純的擴張。

OpenAI 仍然領先，但差距正在縮小

在生產力提升的敘事背後，是整個 AI 工具棧的重塑。報告還使用 SDK 下載量 作為採用度的代理指標，來觀察生態系統的變化。

在 AI 記憶元件 中，mem0 以 59% 的市佔率 一騎絕塵。而在 向量資料庫 領域，競爭要激烈得多：Weaviate 以 25% 領先，Chroma、Pinecone、Qdrant 等緊隨其後。

在 LLMOps 層，報告強調了基礎設施的高速增長。

LiteLLM 的下載量據稱 增長了 4 倍，達到 4100 萬次；LangSmith 則藉助與 LangChain 生態的深度繫結迅速上位。一個明確的趨勢正在形成：模型排程、監控、降級和可靠性控制，正從“可選項”變成 基礎設施標配，就像當年的 Kubernetes 之於微服務。

報告還對 2022 年 1 月至 2025 年 11 月 期間主要模型廠商的 SDK 下載量進行了比較，重點關注 OpenAI、Anthropic 和 Google GenAI。

OpenAI 依然是絕對領導者，其下載量從 2022 年初幾乎為零，增長到 2025 年 11 月的 約 1.3 億次。Anthropic 的增長則被形容為“火箭式”：自 2023 年下半年開始陡增，到 2025 年 11 月達到 約 4300 萬次，報告稱這是 自 2023 年 4 月以來 1547 倍的增長。相比之下，谷歌的曲線更為平緩，2025 年 11 月約為 1360 萬次。

報告認為，這反映出開發者正在用腳投票，越來越偏好 更可控、更可程式設計、更開放的介面，儘管 OpenAI 依然保持著最大的市場規模。

模型特性決定最適合的程式設計場景

Greptile 還分享了 五種主流模型 作為程式設計智慧體後端的基準測試結果，對比了 首 token 等待時間、吞吐量和成本 等指標。

在 互動式程式設計 場景中，“首 token 時間”尤為關鍵。報告指出，Claude Sonnet 4.5 和 Opus 4.5 在 2.5 秒以內 就能返回首個 token，明顯快於 GPT-5 系列（超過 5 秒）。在實際體驗中，報告認為 約 2 秒 往往是進入心流與被打斷注意力之間的臨界點。

但在 批次生成 場景下，結論則發生了反轉。

報告認為，GPT-5-Codex 和 GPT-5.1 在吞吐量上斷崖式領先，更適合用於 CI/CD 流水線中的大規模程式碼生成或測試用例填充。而 Gemini 3 Pro 的響應明顯更慢，往往需要 10 秒以上 才返回首個 token，每秒輸出的 token 數也較少，因此並不適合互動式程式設計。

研究前沿正在指向哪裡

在最後一部分，報告列出了 2025 年 若干關鍵論文，暗示下一波突破方向。

例如 Self-MoA 表明，通過 單模型多次取樣並聚合，可以超越傳統的多模型混合方案，這意味著關注點可能從“模型多樣性”轉向“推理路徑多樣性”。Search-R1 使用強化學習，讓模型 自主決定何時進行搜尋，將搜尋引擎從靜態工具呼叫，變成可學習的環境動作。RetroLM 則嘗試在 KV 層面直接檢索，繞過原始文本，可能改變大模型組織和呼叫記憶的方式。

即便 AI 無處不在，人工審查仍不可或缺

無論 AI 輔助程式設計多麼先進，程式碼在真正落地之前，人類審查依然不可替代。使用資料和自動化審計，很難完整反映開發者在驗證、修正和做判斷時投入的時間與精力。

如果一種 AI 程式設計工具能夠證明：它幫助團隊 更快、更有信心地交付功能，而不僅僅是讓更多程式碼行通過審查，那麼它的價值，才會真正變得 對工程師和業務方都清晰可證。