3年、1萬人，快手技術團隊首次系統披露AI研發范式升級歷程

作者｜快手技術團隊

審校 | 陳姚戈

編者按

以 ChatGPT 問世的 2022 年為起點，大模型技術進入公眾視野已經超過三年。人們普遍見證了 AI 作為新型生產工具對生產力的重塑，但對科技企業而言，這遠不止是多了新技術或新產品那么簡單。

作為前沿技術的掌握者與實踐者，科技公司必須率先完成自身的轉型：以極快的速度，不惜試錯和陣痛，找到大規模、穩定、高效使用 AI 的組織路徑。過去十年，“數智化”浪潮主要聚焦于傳統企業如何借助外部工具實現數字化；而如今，AI 正在倒逼科技公司自身成為變革對象。它們必須在人才結構、工具體系、協作流程乃至組織文化上同步革新，否則將難以在 AI 時代維持競爭力。

正是在此背景下，快手首次系統性披露其自 2023 年以來的 AI 研發范式升級歷程。

今天，快手發布了名為《快手萬人組織 AI 研發范式 躍遷之路：從平臺化、數字化、精益化到智能化》的 1.6 萬字長文。文章由快手研發效能委員會審稿、經內部深度復盤整理，罕見地呈現了一家超大型科技企業在 AI 時代推進組織級提效的完整圖景。

你會在這篇文章中看到快手研發范式的三階段演進路徑，以及快手技術團隊對 AI 賦能組織提效的思考：

• 三階段演進路徑：

• • 平臺化、數字化、精益化（2023-2024 年）：

  • 建設一站式研發平臺，并標準化需求和工程流程，工具滲透率>95%，流程自動化>94%
    

  • 通過建立效能模型，識別交付瓶頸，提升需求交付效率，人均需求吞吐量提升 41.57%

  • 智能化 1.0（2024 年 6 月 -2025 年 6 月）：聚焦用 AI 提升個人開發效率

  • 建設并推廣 AI 編碼 / 測試 /CR 等能力，AI 代碼生成率超過 30%

  • 但發現矛盾——個人主觀編碼效率提升顯著，但組織需求交付效率卻基本不變

• 智能化 2.0（2025 年 7 月以后）：聚焦用 AI 提升組織整體效能

• • 找到了 AI 研發范式升級路線：L1 AI 輔助（Copilot）→ L2 AI 協同（Agent）→ L3 AI 自主（Agentic）

  • 探索出了支撐路線達成的系統性實踐：AI x 效能實踐、AI x 研發平臺、AI x 效能度量
    

• 關鍵洞察與經驗：

• AI 研發提效陷阱： 用 AI 開發工具 ≠ 個人提效 ≠ 組織提效

• 本質問題：如何將個人提效傳導到組織提效
  

在全球范圍內，如此系統、坦誠且具備工程細節的 AI 提效實踐總結仍非常稀缺。對于所有正在探索 AI 落地路徑的企業而言，這份來自一線的復盤值得細讀。

這也預示著一個新的節點正在到來。當像快手這樣的頭部公司開始對外輸出其 AI 落地的方法論與效能成果，整個行業將面臨一種隱形的壓力——組織能否高效駕馭 AI，將成為其在 AI 時代競爭力的重要衡量方式。

可以預見，2026 年將成為一批先行者集中展示階段性成果的窗口期。這些成果首先會以研發效率、工程體系和組織方法論的形式呈現；再過幾年，更會傳導到公司的財務表現與人才吸引力上。

到那時，所有公司都將不得不回答同一個問題： AI 時代，我們如何重構自己？

快手報告標題：《

快手萬人組織 AI 研發范式 躍遷之路：從平臺化、數字化、精益化到智能化

AI 研發提效陷阱

用 AI 開發工具 ≠ 個人提效 ≠ 組織提效

早在 2024 年，快手就建設了 AI 編程工具 Kwaipilot，并發布給公司內 10000+ 研發人員使用。經過持續的深度優化和推廣，快手整體的 AI 代碼生成率，在嚴格度量口徑下（AI 生成并入庫的代碼行 / 新增代碼行）從 1% 達到了 30%+，甚至部分業務線達到了 40%+。同時，在非編碼環節，也衍生出了很多 AI 提效工具，比如智能 CR（CodeReview）、智能測試用例生成、智能單元測試等等，但經過大量的調研和數據分析，我們發現了這個不等式：

“用 AI 開發工具 ≠ 個人提效 ≠ 組織提效”

如果以企業的研發效能提升為目標，我們發現：

• 對研發工程師而言：深度使用 AI 開發工具，代碼生成率很高，個人主觀體感上編碼效率提升了 20-40%，但并不代表真正的“個人提效”，因為在現實中，大部分工程師并沒有接納更多的需求，個人需求的交付數沒有顯著提升。

• 對大型組織而言：我們發現部分 AI 用的好的工程師，確實可以更快更多的完成開發任務，但組織整體的需求吞吐量沒有明顯提升，需求交付周期也沒有明顯縮短。

從《2025 年 DORA 報告：人工智能輔助軟件開發現狀調查報告》中能看到，這也是業界普遍存在的問題。如報告中所述（如下圖所示），在對 AI 提效的結果的預估上，各企業普遍對個人效能的提升有信心，而對團隊效能的提升預估非常小。

在快手，我們發現僅推廣研發各階段的 AI 提效工具，已經偏離了企業研發效能提升的核心目標，最終必然會導致 2 個問題：

• 投入很大，但企業整體的研發效率提升不明顯：雖然通過調研很容易能收到大量的個人效率提升反饋，但個人提效無法傳導到組織提效。

• 效能平臺開始割裂：傳統 DevOps 平臺仍承擔研發主流程，每天被高頻的使用，卻無法演進到下一代 AI 研發平臺（頂多擴展一些單點的 AI 功能）。新生的 AI 編程工具，只取代了傳統 IDE，又無法與老平臺協同演進。

為了解決上述 2 個問題，我們從 2025 年開始進行了更激進的探索和變革，我們稱之為“AI 研發范式升級”，最終，通過一系列的實踐，找到了一條能借助 AI 能力平滑通往研發智能化的路徑。

正逢 2025 年年末，我們把鏡頭拉遠，將時間回溯到 3 年前，對快手研發效能的演進做一個系統性總結，有踩過的坑，也有做出的突破，希望為更多企業提供經驗和參考。

總覽：快手 研發效能 演進路線

快手有 10000+ 研發、8+ 業務線，研發效能的演進可以分為 3 個大階段，如上圖所示：

• 階段 1：平臺化、數字化、精益化（2023-2024 年）：通過建設三端一站式研發平臺、需求流 & 工程流標準化，解決了研發交付流程散亂，既無標準也無數據的問題。再通過建立效能模型，識別交付瓶頸，提升需求交付效率。

• 階段 2：智能化 1.0（2024 年 6 月 -2025 年 6 月）：在研發全流程中開始建設 AI 能力，包括 AI 編碼、AI 單元測試、AI CR、AI 手工用例生成、AI OnCall 等等，并進行全員推廣。經過 1 年多的實踐，基本上完成了全員普及，在主觀調研中，開發人員主觀體感上效率提升 20-40%，在客觀數據上，AI 代碼生成率也在持續增長。但同時也發現了矛盾點：需求交付效率基本不變，即個人效率提升未能有效傳導到組織效率提升。

• 階段 3：智能化 2.0（2025 年 7 月 +）：從“推廣 AI 工具，讓開發者使用”回歸到了更本質的元問題：如何用 AI 提升需求端到端交付效率？經過半年多的探索，終于找到了新的路徑，并得到了充分的數據驗證。我們稱這套解決方案為“AI 研發范式”，主要解決了 3 個問題：

• AI x 效能實踐：如何用 AI 提升工程師的生產力，并將個人提效傳導到組織提效。

• AI x 研發平臺：支撐需求交付全流程（從分析到編碼再到發布）的研發工具鏈，如何整體演進到智能化？即下一代的智能研發平臺，應該是什么樣的？而不僅僅是只推廣 AI 編程工具或在原有工具鏈上增加一些散點的 AI 提效功能。

• AI x 效能度量：如何在效能度量指標的基礎上，構建 AI 提效的指標體系，能清晰的量化過程和結果，為組織級的 AI 研發范式升級提供有效指引。

階段 1：平臺化、數字化、精益化
（2023-2024 年）

這個階段的解決方案，業界相關的分享已經非常多了，但從實際情況看，在千人規模的技術團隊中，能做好、做深、做透的實踐非常稀有。

因此，我們直接分享 1 個具體的案例，以便能更好的看清快手的研發效能從基礎建設到效能提升的全過程，這也是我們之所以能更快躍遷到 AI 研發范式的重要基石。案例來源是快手最核心的技術團隊之一——主站技術部，是快手 APP 的研發團隊，開發人員規模千人以上。

背景：了解快手的研發效能基建

首先，主站技術部的實踐依托一套公司級的研發效能基建，由橫向團隊「研發效能中心」提供，如下圖所示，這是在 2023 年快手當時的研效基建，主要分為：

效能平臺：項目管理平臺（Team）、三端一站式研發平臺（KDev（服務端）、KFC（前端）、Keep（客戶端））、瑯琊閣（效能度量）、質量平臺（KTest 等）

效能實施：效能 BP 專家（Business Partner），負責深入各業務線，提供專業支持。

了解快手的研效基建后，下面開始重點介紹主站技術部的實踐過程。

Step1：依托工具推廣，實現流程標準化

解決的問題

需求流和工程流均不標準，開發人員的工作分散在各處，日常開發體驗差、學習成本高，又無法實施有效的質量防護措施，還不能沉淀準確的研發過程數據持續度量與改進。

達成的效果

通過推廣三端一站式研發平臺，定義需求、研發的標準流程，將研發全流程標準化。核心度量指標與結果如下：

實踐過程

主要難點

• 用一套產品設計盡量滿足多樣化的研發場景：工具一邊建設一邊落地，且需兼容之前散亂各種不同的研發模式和習慣。

• • 服務端（KDev 平臺）：需要支持一些特殊的研發模式（比如 Master 模式、窗口模式）。

  • 客戶端（Keep 平臺）：移動端研發場景多樣化，包括 APP、動態化、 SDK。

  • 前端（KFC 平臺）：前端應用類型多（Web、Node、低碼、KRN（動態化）、小程序），研發流程和習慣散亂。

  • 研發流程規范差異大：不同團隊間，不同的技術棧的研發流程上存在一定差異，包括研發流程配置、流程各階段信息字段、單點環節所需的工具能力不同等。

• 用戶遷移成本大：遷移過程中，需持續關注和解決用戶問題，包括用戶體驗變化、用戶學習成本、用戶情緒。

• 落地時間緊迫：一般互聯網大廠類似的工作基本會持續 6 個月以上，快手主站只用了 1 個多月。

實施要點

• 精準的解決方案設計：

• • 服務端（KDev 平臺）：精準的打造了 4 套標準研發模式，適配了主站實際研發情況。

  • 客戶端（Keep 平臺）：一套平臺底層能力，支撐 3 種移動研發場景；通過可配置與定制化能力，滿足不同團隊流程規范與管理訴求（自動翻轉配置、流程與質量卡點配置、團隊定制化模板）。

  • 前端（KFC 平臺）：支持 80% 以上前端應用類型，并通過 8 個流程模板、適配 5 個內部自建的插件，兼顧了前端差異化研發流程和用戶習慣。

• 以用戶滿意為導向：提供完整的遷移配套服務，降低用戶遷移成本。主要包括：

• • 產品質量專項：用戶 BUG 日結。

  • 用戶體驗專項：持續深度用戶訪談，識別體驗問題，并優化。5 周內，交付了 73 個功能 & 體驗需求。

  • 用戶培訓與激勵：通過 12 次培訓，50+ 線下訪談，7x24 小時 OnCall、200+ 人次的用戶激勵，提升用戶對產品的接受度。

• 數據驅動團隊級推廣：每周度量進度，驅動各部門接口人推廣。

經驗總結

可能大家會有疑惑，為什么三端分別是 3 個平臺，而不是一套平臺。因為從實際情況看，服務端、前端、客戶端的底層模式、流程都有比較大的差異，強行整合，不僅對產品用戶收益不大，反而犧牲了要兼容不同端的流程、習慣差異化的靈活性，給標準化的推進增加難度。因此，我們在用戶層面上，還是三套平臺，分別解決各自領域的問題，但在底層的基礎能力用的是一套，比如流水線、權限等。

Step2：建設效能度量體系

主站的研發效能早在 2022 年就開始啟動了，當時在探索北極星指標階段，缺少度量體系，更多是根據一線開發者的開發痛點反饋，進行偏工具流程等的優化，沒有核心指標的牽引，項目都無法推進，更談不上論證給業務帶來的價值。在 2023 年 3 月再次重啟效能項目時，北極星指標初步定義為 “有效需求吞吐量”，但是當時需求有效性的衡量難度太大，內部無法達成共識，項目推進困難，而且也無法看清業務堆積和開發人效情況。

隨著流程標準化的落地，研發數據的置信度大幅提升，為效能度量提供了土壤。因此，我們定義了以“人均交付產品需求數” 為北極星目標來看清業務開發交付能力，同時觀測需求顆粒度（避免單一指標跑偏：度量什么得到什么，種瓜得瓜種豆得豆）來保障交付提升的良性發展，逐步建立了一套更全面的指標體系（多指標互相佐證約束，hack 成本極高）來體現業務交付產能和交付效率，以及組織和個人效率情況。

快手的效能度量體系如下圖所示：

注明：SP：Story Point，快手用于度量需求工作量的單位。

借助這套全面完備的指標體系，我們不僅避免了依賴單一指標可能導致的偏差，還有效防范了效能數據被 hack 的風險，確保了效能數據的準確性和可靠性。

Step3：效能問題分析與改進

有效能度量體系，首先我們可以為任何一個業務線做系統性的體檢，如下圖所示，依托數據和經驗，可以逐一拆解出核心的優化專項，并以效能項目的形式實施。

其次，在研發流程和管理上，也能洞察出更多平時看不見的 Case，深入改進，下面是 2 個具體的洞察與改進案例：

Case1：通過「研發活動在線化率」分析，深挖出架構不合理問題

上圖是主站技術部下級各團隊的研發活動在線化率，其中有一個團隊出現了數據異常，分析之后可以發現存在不少問題：

• 橫向來看，這個團隊的研發活動在線化率處于中上水平，但產品需求投入占比只有 59%，處于末尾水平。而且產品需求中體驗優化占比 11.44%，又是各團隊中最高的。那么問題來了，“時間都去哪兒了？”

• 再下鉆一層，這個團隊的缺陷占比 14%，也是各團隊中最高的，且 Oncall& 排障占比 6% 也不低。

因此，數據表明，此團隊可能存在的問題：在缺陷問題、體驗問題、Oncall& 排障消耗了團隊大量的投入，以至于無法消化更多產品需求。所以，通過對團隊核心成員的調研和訪談，基本可以找到根因：和客戶端的架構劣化有關，比如：

• 反饋 1：新需求開發時，上手門檻特別高，很多需求會涉及到多個模塊開發，這會涉及到自己不熟悉的模塊，因為架構分層結構不合理，模塊耦合度太高，往往需要花大量的時間去熟悉其他模塊的代碼，最近做了一個新需求，評估是 3 天的工作量，2 天都在看代碼，實際的開發聯調只有 1 天。

• 反饋 2：模塊邊界不清晰，代碼雜糅一起，新需求的代碼，可能會影響到已有功能，導致舊功能的 BUG，而且這些 BUG 在回測時，不容易被發現，導致問題漏測逃逸到線上。

通過效能的客觀數據再結合主觀調研，就可以看清“架構劣化”這種深層次問題，也可以對癥下藥了。解法是這個團隊實施了 2 個技術專項：

• 客戶端的架構升級：從根本上解決因為架構問題帶來的交付效率低和交付質量差的問題。

• 體驗優化：集中優化重點場景的體驗問題。

隨著這兩個專項的落地上線，這個團隊的效能數據已經有所改善，產品需求投入占比已經提升到 64%，體驗優化占比下降到 6%。

Case2：通過「需求積壓率」分析，驅動業務優化需求評審流程和節奏

上圖是主站技術部下級各團隊的需求積壓率數據，有些團隊的需求積壓率持續保持在 80% 以上，意味著需要近一個月的時間才能消化這些積壓的需求。這種情況可能存在的問題：

• 這些被積壓的需求，一個月之后，會不會進入排期開發？如果之后會排期開發，說明需求本身的價值還可以，當下是否可以協調資源加快交付？能否可以停掉某些技術需求優先業務交付？是否可以短期加班臨時突擊？

• 如果后面不會進入排期，是不是這些需求本身的重要性沒那么高？在預評審的時候，是不是可以控制需求的優先級？當前的需求評審流程是否可以優化？

結果

經過一年時間的系統化提效，主站提效方面進展顯著，人均交付產品需求數24 年 7 月份同比增長超過 80%。總結下來，主要有效的措施有：

• 升級研發模式：通過動態化、配置化等研發模式，讓部分需求可以更快速交付。

• 研發過程提效：通過 API 在線化管理，測試環境穩定性治理、流水線優化、發布優化等措施，降低研發協作成本以及低價值工作占比。

• 管理與協同提效：通過效能洞察，持續識別團隊協作瓶頸，并通過排期優化、測試無人值守、人力調配等措施，支撐需求可順暢流動。

階段 2：智能化 1.0
（2024 年 6 月 -2025 年 6 月）

從 2023 年 6 月開始，我們開始探索大模型在研效領域的應用，主要有 2 個方向：

• 編碼場景：如何用 AI 輔助編碼，提升代碼生成效率。

• 非編碼場景：在研發全流程里，哪些環節可以通過 AI 能力提升單點工作的效率。

其中，最重要的決策是我們決定自己研發一款 AI Coding 工具：Kwaipilot。它包含了大家見過的所有產品形態：

• IDE 插件 / AI IDE / CLI：最符合開發人員習慣的幾種形態，插件、IDE 可以做續寫、問答、智能體代碼生成，CLI 則可更靈活的開啟代碼生成任務。

• 智能問答引擎：有獨立的 Web 頁面，也會嵌入到上面的產品形態里，為開發人員提供靈活的問答能力。

業界有很多優秀的 AI Coding 產品，比如 Cursor、Claude Code、Krio、Windsurf、Antigravity，快手為什么不選擇采購，而是自建呢？其實一年來，我們也一直帶著這個疑問在探索，相當于一場大型的公司內部 AB 實驗：

從用戶體驗的角度，我們希望大家“用腳投票”，選擇好用的工具：

• 一方面，我們允許開發同學使用任何 AI Coding 產品，可以團隊級采購也可以個人購買。

• 另一方面，我們研發了 Kwaipilot，對內推廣。

從實際效果的角度，我們以“AI 代碼生成率”為核心觀測指標，持續收集用戶 / 團隊的反饋，識別不符合預期的代碼生成 Case，研究解決方案，再投放實驗。最終，經過 1 年的探索，實踐結果讓我們堅定了繼續走自研 Kwaipilot 的路線。

注明：2025 年 12 月開始，在 Kwaipilot 已規模應用后，由于安全原因，探索按代碼分級封禁三方 AI Coding 工具，僅涉及到部分開發人員。

下面簡單分享一下我們的實踐過程，相信大家會更容易理解我們的選擇。整個 AI Coding 的推廣過程分為 3 個階段：導入、優化、固化

Step1，導入：推廣工具，讓開發人員用起來

這個階段很好理解，我們鼓勵開發人員在日常工作中默認使用 AI 編程工具，主要目的是讓大家擁抱 AI，在意識和行為上先有一個轉變。

當然，各種各樣奇怪的使用姿勢也會出現：

• 一些同學，尤其是校招入職的同學，在我們的培訓和引導下，會深度使用 Kwaipilot。

• 一些同學會多種 IDE 混開配合使用。其中，有“團購客”，哪家這個月免費就用誰，也有“付費用戶”，主要以個人購買 Cursor 為主。

這里最大的副作用，就是個人編碼效率不一定全員獲得了提升，通過調研看，出現了明顯的兩級分化的情況。騰訊研究院出品的《AICoding?共識報告》中也揭示了類似的情況：

Step2，優化：推廣實踐，提升編碼效率

我們通過用戶數據和技術 Leader 推薦找到了一批公司里的“AI 開發高手”，那些用 AI 輔助編碼切實提升了效率的開發人員。

一邊重點收集他們在使用過程中的問題，集中想辦法解決，一邊把他們的優秀開發技巧淬煉出來，提煉共性，形成最佳實踐。

這個階段，我們發現，有別于那些網上隨處可見的所謂的 Vibe 編程場景（用對話的形式直接做一些獨立應用或小游戲等），在真實的業務需求開發場景里，想用好 AI 編程工具提升效率，有 2 個非常大的門檻：

• AI 編程工具不“懂”業務和系統：我們發現一個規律，無論用多好的代碼大模型和 AI 編程工具，“通用的工具只能達到通用的效果”。因為它們不理解公司內大量的業務概念、存量系統、編程規范等這些知識，所以，只能做一些普通的代碼續寫、函數級的代碼生成，但很快就會到瓶頸。如果想進一步提升 AI 代碼生成的效果，必須想辦法讓 AI 編程工具從一個“擅長編程但不懂快手開發場景的臨時工”進化為一個“熟悉快手業務的開發工程師”。

• 人和 AI 協同需要掌握新的開發方法：相比傳統編程方法，目前已經發展出了一套 AI 輔助編程的新方法。如果開發工程師僅使用 AI 編程工具，卻未掌握對應的技巧，不僅不能提效，還可能會降效，比如出現很多“AI 亂改業務代碼”、“AI 生成后還要自己刪除”等各種不符合預期的情況。

為了降低門檻，在這個階段我們做了 2 項工作：

升級 AI 編程工具

上圖是優化后的 Kwaipilot 的產品矩陣，都解決了哪些問題呢？一張表可以概覽出來：

沉淀并推廣「AI 輔助編碼」最佳實踐

我們將大量“AI 開發標桿”個人的共性實踐沉淀成了一份標準的指南和實戰課程，讓所有開發工程師，通過學習指南和課程，可以完整的掌握所有關鍵技巧。

Step3，固化：將 AI 編碼能力變為組織機制

既然已經驗證了 AI 編碼對效率提升的有效性，且已經有了固定的工具、方法、實戰課程，接下來就是如何把這些習慣固化在組織的日常工作中，讓所有研發人員大范圍的升級開發技能。我們主要用了 3 個措施：

• 增量人員：強化入職培訓，從源頭培養 AI-Native 開發者。

• 存量人員：牽引 AI 在團隊、研發流程、個人工作中滲透。

• 文化影響：通過活動運營、獎勵機制激發更多同學擁抱 AI。主要是一些自下而上能讓更多一線研發被看見。

結果

持續的推廣，在編碼場景上，80%+ 的開發人員都開始用 AI 輔助編碼，如下圖所示，可以看到 AI 代碼生成率每月線上增長。

同時，在非編碼場景中，我們在研發流程中建設的單點 Agent 能力也開始在研發平臺中陸續透出，用 AI 能力輔助部分研發活動提效。

最終，我們對研發各階段的 AI 提效情況，做個一個完整的評估：

最后順便提一下，眾所周知，目前大家在業界看到的“代碼生成率”指標，包括各大廠披露的、AI 編程工具自己度量，基本都是不置信的，要么只統計了編程工具里的生成的代碼和提交的代碼作為分子分母，要么是在分母上做了一些限定（比如某些場景下不納入分母統計）。但因為我們會用這個指標作為公司級 AI 編碼推廣的目標，因此對度量的精度和置信度要求非常高，一路“踩坑”過來后，最終使用了最嚴格的度量方法：

• 分母：新增代碼行，統計公司內所有最終入庫的 Commit 中的代碼行。

• 分子：將分母的每一行代碼，和 AI 生成的代碼進行比對，如果編輯距離<50%（相似度高），則納入統計。

這套實現無法在 AI 編程工具端實現，需要由公司內部的代碼平臺、AI 編程工具一起提供數據，并在離線數據層進行精確的計算，計算分母中每一行新增的代碼和分子中 AI 生成代碼的編輯距離，符合要求才能被統計為分子。

問 題

經過 1 年多的努力，從數據上看，研發各環節效率都在提升，尤其是編碼環節提升很大。在 AI 熱潮下，我們也看到很多開發人員、團隊 Leader 都在分享自己效率提升數據和案例，按道理來說，公司整體的研發效能應該提升了吧？我們從全局視角，分析了一個核心業務線的客觀研發數據，結果發現了非常反直覺、令人困惑的情況：AI 代碼生成率持續在增長，但需求交付效率基本不變。

為什么呢？我們做了深入的調研，排除了少量個例，觀察總結了大多數普遍使用“AI 輔助編碼”的開發人員的用法和客觀研發數據，發現在真實業務交付場景中，只用“AI 輔助編碼”這種開發方法，對需求的開發周期影響非常有限。主要原因如下：

洞察

不過調研中也有額外收獲，我們發現在真實的業務需求開發中，已經存在著 3 種不同的開發方法，對效率提升的程度有著根本性的差異。如上圖所示。我們把三種開發方法總結出來做了一個定義：

• AI 輔助編碼：在標準開發流程的基礎上，在編碼環節，依托 AI 編碼工具，使用各種 AI 生成代碼的技巧，提升編碼效率。如果熟練掌握，可以縮短一部分編碼時間，但如上文中的調研歸因，由于只是節省了碎片化的編碼時間，聯通、測試、需求評估等不變，因此對整體的開發任務縮短幫助不大。

• AI 輔助開發：在研發全流程的各環節均使用 AI 輔助的方式，提升整體開發效率。需要由人把需求拆分為多個開發任務，不同開發任務調用不能的 AI 能力來完成，再由人來審核和優化產出物。由于從技術設計到編碼到測試等各環節都可以節省時間，因此加總起來后，可以將研發任務的開發周期縮短 30% 左右。

• AI 協同開發：在某些需求開發中，通過完全用自然語言和 AI 交互的方式（類似業界比較流程的說法 Spec/Vibe 開發）完成需求交付，提升需求端到端交付效率，需求整體的開發周期可以縮短 40% 左右。

舉個例子說明，會更容易理解三種開發方法對效能提升程度的影響。例如 1 個需求分解出 2 個開發任務，1 個前端、1 個后端，其中前端工程師接到開發任務，正常評估從設計、開發、測試、合入主干需要 5 天，其中編碼 1 天：

• 如果用「AI 輔助編碼」，他自己的評估還是 5 天，只不過相比以前，可以節約一部分時間做一些雜事，但到不了可以接更多開發任務的程度。

• 如果用「AI 輔助開發」，他可以整體節約 1.5 天，只用 3.5 天就可以完成。但需求整體能不能快，還需要看另一個接任務的同學，以及對應的聯調、集成測試、發布的周期。

• 如果用「AI 協同開發」，首先必須改變協同模式，比如 2 個人均使用這種模式開發或者 1 個人全棧的做，假設 1 個人全棧獨立做要 10 天，且不需要和別人集成 & 驗證，開發周期可以縮短到 6 天左右。

有了 3 種開發方法的定義，我們就能很容易的評估出理想和現實間的差距，我們取了 1 個業務線 3 個月所有已交付的需求進行分析，發現 50%-70% 的需求，在不改變原有開發流程、規范、人員協同模式的情況下，可以使用提效幅度更大的「AI 輔助開發」模式。此外，還有 2%-10% 的需求，可以更激進的使用「AI 協同開發」。但實際情況上，團隊里只有不到 10% 的人在使用「AI 輔助開發」或「AI 協同開發」開發方法，有對 AI 開發特別感興趣的校招生，也有積極擁抱 AI 喜歡自己探索的資深開發者，但由于人數過少，對團隊整體研發模式的變化無法起到帶動的作用。

階段 3：智能化 2.0（2025 年 7 月至今）

上面一個階段，我們稱之為“智能化 1.0”階段，即以編碼場景的 AICoding 為中心提效，并逐步輻射非編碼場景的 AI 提效。但主要瓶頸就在于開篇提到的 AI 研發提效陷阱：用 AI 開發工具 ≠ 個人提效 ≠ 組織提效。

在智能化 1.0 階段最大的收益是什么呢？大部分研發人員都開始主動使用 AI 開發工具了，同時，找到了個人提效的最佳實踐。但接下來才是深水區，我們需要回歸效能提升的元問題：“如何用 AI 提升需求端到端交付效率？”。

經過充分的復盤、洞察和驗證，我們找到了新的可行的路徑，并重新設計了解決方案，我們稱之為“AI 研發范式”，它的實踐體系框架，如下圖所示：

我們根據需求交付中 AI 的參與程度，定義了“需求 AI 研發成熟度”，將需求劃分為 3 個等級 L1、L2、L3，不同等級的需求，需要使用對應的開發方法。不同開發方法，對底層研發工具的 AI 能力也有不同程度的依賴。用一張表對上圖做一下解讀：

注明：當前快手整體所處階段為 L2，2026 年年度目標為 L2&L3 需求占比達到 80% 以上。其中，依賴研發平臺在研發流程中各環節提供 AI 能力，AI 能力根據不同的應用成熟度分為 M1-M4，當前圖中為 2025 年 12 月現狀，2026 年會將 M2 級（已在一定范圍內驗證成功）能力全部達到 M3，從而支撐總目標的達成。

具體實施上整體有 3 步：

Step1，AI x 效能平臺：建設能同時支持多種研發模式、可自進化的智能研發平臺

解決的問題：

• 能支持多種研發模式：不同 AI 研發成熟度的需求，它們的交付流程都是一樣的，差異點在于開發方法。因此我們無法為不同的需求、不同的開發方法匹配不同的平臺，而是要思考如何用一套平臺，來支撐多種開發方法：完全不使用 AI 的標準開發流程、只用 AI 輔助編碼的開發流程、更激進的使用 AI 輔助開發或協同開發的開發流程，都應該在同一個平臺上完成。這樣，我們的需求交付效率，才可以隨著人的能力的提升、AI 能力的提升，持續變快。

• 產品形態可進化：產品形態隨主要研發模式的變化持續演化，從人主導最終變為由 AI 主導；能與傳統平臺協同進化。

• AI 效果可進化：能隨大模型的升級、Agent 技術的升級、企業 / 個人知識的豐富，持續提升 AI 效果。

解決方案：建設下一代智能研發平臺

如上圖所示，有 4 個關鍵點：

下面重點介紹下為了支撐組織級研發范式躍遷，Flow 這種子產品形態的獨特優勢。

• 從需求交付視角看：同一個需求，開發者可以結合自身對 AI 的理解和開發技能的掌握，在同一種產品形態上選擇不同開發方法。

• • 標準開發 / AI 輔助編碼：工作流中所有節點，完全由人工來完成和推進。其中“編碼”節點會跳轉到 IDE 中，可以用 AI 輔助編碼。對用戶而言，收益相對來說最小，和原來相比，由于 Flow 的每個節點內嵌或自動兼容了各工具平臺的功能，因此僅節約了用戶平臺跳轉的切換與學習成本。用這種模式交付的需求，會被度量為 L0/L1 級需求（AI 輔助（Copilot））。

  • AI 輔助開發 /AI 協同開發：工作流中多個關鍵節點均有 AI 完成，人進行結果審查。多個節點之間的上下文可以有效傳遞，比如 AI 完成需求分析、技術設計后，產出的 AI 友好結構化文檔可以自動傳遞到 AI 編碼節點，以提升代碼生成的準確性。有些節點暫時無法由 AI 完成的，比如“提測”節點，仍然由人來操作。用這種模式交付的需求，會被度量為 L2 級需求（AI 協同（Agent））。

  • AI 自主開發：部分需求可以實現全流程 AI 完成，人只需要在需求上線前或上線后進行審核。這種模式下，整個 Flow 是全自動運行的不需要人工參與。用這種模式交付的需求，會被度量為 L3 級需求（AI 自主（Agentic））。

• 從開發者視角看：整個過程依然非常絲滑和簡潔，下圖是一個需求交付中 Flow 的整個工作過程，大家可以感受一下：

Step2，AI x 效能實踐：以需求為中心，導入「AI 研發模式」，實現需求端到端提效

支撐「AI 研發模式」的方法和平臺都有了，這個階段的關鍵是如何把這些作用在團隊日常交付的需求上。我們分 3 個層面落地：

個人級實踐：導入「AI 輔助開發 / AI 協同開發」開發方法，并樹立標桿

首先人的開發方法要變化。我們重復了第一階段“優化”與“固化”的實踐，讓大部分研發人員從“AI 輔助編碼”的方法升級成“AI 輔助開發”，讓小部分專業能力更強的人員，選修“AI 協同開發”方法。我們同樣通過實戰課程、典型案例、人員培訓等手段，對人的開發方法進行升級。

當然，即使這樣，從數據上看，個人用 AI 提效的效果還是存在兩極分化的情況。我們對 2025 年 6 月 -12 月的數據進行了分析得到如下結論：

團隊級實踐：導入「AI 研發模式」，重塑流程、分工，提升所有需求的交付效率

通過管理導向、各種活動的形式，鼓勵團隊 Leader 主動帶領團隊進行探索，最終沉淀出了一套適合團隊的核心實踐：

經過大量的驗證，我們的標桿團隊（<50 人規模）無論在 AI 轉型后的業務感知上，還是客觀數據上，均能達到比較優秀的水平，見下表：

業務線級實踐：大規模研發團隊，系統性升級 AI 研發范式，帶來效能提升

以主站技術部為例，從 2023 年到 2025 年，從平臺化到數字化再到精益化，2025 年開始步入深水區，2 個新挑戰浮出水面：

• 傳統的流程、工具優化手段帶來的提效收益，邊際效應持續減小。

• 業務的規模與復雜度持續提升。

因此開始探索能否把握 AI 爆發的機遇，把傳統研發流程升級到“AI 研發范式”，進而打開組織級效能躍升的新空間。核心實踐：

實踐 1：Top-Down，戰略驅動

• 明確戰略導向：主站技術部提出了“AI First”的戰略思想，鼓勵全體員工開展工作之初，優先將 AI 作為核心驅動力，加速技術創新、優化業務流程、深度融合 AI 技術，為產品與服務注入新活力和新可能性。

• 發布白皮書：將戰略導向具象化為思考、方法與規劃，為全員提供明確指引。

• 成立重點項目：在研發領域，成立了 AI DevOps 項目，統一設計解決方案并推廣實施。

實踐 2：AI x 效能實踐

• Step1：將需求分級，按需求 AI 研發成熟度定義：

• • L1 AI 輔助（Copilot）：人主導，AI 主要在編碼環節提供輔助。

  • L2 AI 協同（Agent）：人和 AI 更深度的協同完成需求開發，在研發全過程中，更深度分解任務給 AI 完成，人進行修改、調整、確認。

  • L3 AI 自主（Agentic）：人類似產品經理，把需求澄清清楚并交給 AI 來完成，并進行最后的驗收。

• Step2：分級實施

• • 讓所有需求達到 L1 級（AI 輔助，Copilot）：推廣個人級實踐，依托 Kwaipilot 工具實現全員掌握，最終覆蓋所有需求。

  • 讓大部分需求能持續升級到 L2 級（AI 協同，Agent）：開展團隊級實踐，從試點到推全，重塑流程、分工。

  • 小部分需求探索能達到 L3 級（AI 自主，Agentic）：圈選出顆粒度小且獨立的需求，構建全技術棧 / 職能端到端交付鏈路，通過全棧、跨棧，減少協作節點，進而形成效率躍遷，最終達成 AI 自主交付。

• Step3：項目化推進

• • 成立組織級重點項目，Top-Down 實施。

實踐 3：AI x 效能平臺。基于需求全流程構建 AI 能力，逐一“點亮”能力并規模推廣落地：

• 構建 AIDevOps 能力矩陣與建設路線圖：基于研發效能白盒化，分析交付流程中各原子環節的人力投入比重、AI 能力建設 ROI，形成決策建設哪些 AI 原子能力。

• AI 原子能力建設：與研發線共建交付流程環節內的 AI 原子能力 20+，研發流程環節覆蓋超過 60%，從需求準備到發布運維各環節。

實踐 4：AI x 效能度量：建設 AI 研發成熟度模型，可將需求分級度量（L1、L2、L3 級需求占比），牽引各級實踐落地。

經過 1 年多的項目實施，最終探索出了一條組織級的 AI 研發范式升級路線，從數據上也能看出明顯的變化：

Step3，AI x 效能度量：建設「AI 研發成熟度模型」，接入原有效能度量體系，驅動需求持續轉變為“AI 研發模式”

最后在效能度量上一樣也需要升級，基于效能實踐的探索，我們配套建立了「需求 AI 研發成熟度」模型（如下圖所示），用于度量一個需求在研發過程中的 AI 使用程度，這樣我們就可以按 L2&L3 級需求的比例，來牽引實踐過程，也可以專門度量 L2&L3 級需求的交付周期的變化，來印證提效結果。

結果

再回到全局視角，從數據上看，如果只看“AI 代碼生成率”指標，可以明顯看到 2025 年 6-11 月出現了一個大幅提升。實際上，在智能化 1.0 階段，這個指標達到 24%+ 基本已經是極限了，當我們開始實施智能化 2.0 后，才開始進一步拉升。

當然，我們在內部的數據觀測上，其實已經不再看“AI 代碼生成率”指標了，它只是一個單點的過程指標，片面且孤立。我們現在有了更直接的度量指標。從過程上，我們觀測多少需求被采用全流程 AI 研發模式交付，從結果上，我們直接觀察需求的交付效率變化。

• L1、L2、L3 級需求占比：有多少需求的 AI 研發程度可以達到 L1、L2、L3 的階段。

下圖是最先完成 AI 范式轉型團隊的數據變化，可以看到 L2&L3 級需求占比達到 20.34%，需求交付周期下降 58%，2 個指標呈現明顯的正相關性。

總 結

最后也總結下我們一年來的實踐心得，目前看完全印證了《2025 年 DORA 報告：人工智能輔助軟件開發現狀調查報告》中的洞察：

“從 DevOps 到 AI 輔助開發：AI 是“透視鏡”與“放大器”

• AI 是“透視鏡”

• • 在協同良好的組織中（如流程清晰、數據打通的團隊），AI 能使 DevOps 效能再提升 25%。

  • 在架構松散的組織中，AI 會暴露流程斷點、數據孤島等隱性痛點。

• AI 是 “放大器”

• • 如同亞馬遜通過微服務轉型釋放 DevOps 價值，AI 輔助開發也需重新設計工作流程（如 “AI 提案 — 人類決策” 閉環）、角色分工（如專職提示工程師）與治理機制（如 AI 代碼審查標準），否則無法釋放真正價值。

對于大型組織的研發效能提升，AI 不是“萬能藥”，而是“透視鏡”和“放大器”，它不會自動修復組織問題，而是先把組織歷史積累的長板和短板一并透視出來，再全部放大。幸運的是快手的研發效能實踐一直保持客觀、務實的風格，先把地基打穩（平臺化 / 數字化 / 精益化），再通過在研發各環節建立 AI 提效能力，先一邊落地一邊充分驗證對個體的提效情況，再體系化的推進組織級 AI 研發范式升級。最終發現，AI 在傳統研發效能基建的基礎上，像放大器一樣增幅了每個環節，為組織帶來研發范式級的躍遷。

如下圖所示，我們基于張樂老師的“研發效能黃金三角”框架之上做了升級，能更清晰的表達出快手的實踐框架：

最后，再把鏡頭拉遠，回到宏觀視角看——2025 年我們所做的種種努力，不過是這場 AI 變革的開端。由 AI 驅動的生產力躍升和生產關系重塑，正在重新定義軟件開發的每一個環節。這不是一場短跑，而是一場馬拉松，不是一次技術升級，而是一次范式革命。

快手已經在這條路上積累了寶貴的經驗，但真正的挑戰和機遇還在前方。未來已來，一起共同探索 AI x 研發效能的無限可能吧！

本文作者

• 快手研發效能中心：秦巍（研發效能解決方案 & 智能工具產品負責人）

• 快手主站技術部：胡偉（主站 AIDevOps 項目負責人）、馬坤（主站研發效能項目負責人）

感謝快手研發效能中心與快手主站技術部的授權，使我們有機會系統梳理并總結快手在過去三年中的實踐經驗。

快手向來崇尚“行勝于言”的實干精神，也因此我們往往專注于行動，而疏于對外分享。然而，過去一年間 AI 技術的迅猛發展，正深刻改變著研發效能領域的格局。在與行業同行的交流中，我們既看到層出不窮的創新探索，也注意到在實踐、方法與工具建設方面仍存在不少共性問題。這些問題若不及早重視，很可能導致未來大量返工與資源浪費，甚至偏離客觀規律，影響企業研發效能提升的既定路徑。

為此，我們決定把我們的探索與實踐經驗分享出來——無論是曾經踏過的“坑”，還是有幸跨過的“河”，都希望能為企業與同行們在“AI × 研發效能”的探索中，降低試錯成本，注入更多成功可能。

當然，快手的 AI 研發范式升級仍在沿著這條路徑演進中：L1 AI 輔助（Copilot）→ L2 AI 協同（Agent）→ L3 AI 自主（Agentic）。目前，我們的研發效能體系已經初步完成 AI 化升級，全景圖如下圖所示：

2026 年正在探索 L2 → L3 的躍遷路徑，我們將定期梳理實踐經驗，持續向業界輸出更多有價值的內容，主要包括：

• 實踐與技術：歡迎關注「快手技術」公眾號。我們將持續分享具體實操方法與技術解析，例如：個人、團隊乃至業務線如何借助 AI 提升效能？有哪些落地案例？研發各環節 Agent 的核心技術及調優方法有哪些？等等。

• 平臺與工具：我們將智能化 1.0 階段沉淀的產品 Kwaipilot 進行了全面升級與開放，它在快手內部歷經數千名研發同學的反饋與打磨，已完成三代演進：Code Copilot → Code Agent → Multi-Agent & Agentic Coding，目前已在海外發布，產品名為 CodeFlicker，希望服務全球開發者，也歡迎國內同行下載體驗（https://www.codeflicker.ai/）。后續，我們還會持續把快手在智能化 2.0 階段的探索成果融入 CodeFlicker，希望讓更多企業級開發者受益。

最后的最后，如果你也希望一起探索「AI x 研發效能」最前沿的技術、產品、實踐，一起以業界最高標準做有挑戰的事，點擊【閱讀原文】，歡迎加入我們。