德國媒體巨頭 Axel Springer 利用 Rovo Dev 助力工程團隊聚焦高價值工作
每個工程組織都面臨著提高交付速度的壓力，但僅僅提高速度本身其實並不是最有價值的目標。Axel Springer 的產品卓越負責人（Lead Product Excellence）Martin Bilt 對這一挑戰有著不同的理解。在 Bilt 看來，更核心的問題在於：工程師們是將最黃金的時間投入到了推動產品前進的核心工作上，還是耗費在了圍繞產品的大量重複性基礎搭建上。
Axel Springer 是一家全球性的媒體與技術公司，旗下擁有 Business Insider、Politico、BILD 和 idealo 等知名品牌。公司總部位於柏林，業務遍及 25 多個國家。在過去 70 多年的發展歷程中，該公司屢次在技術尚未全面普及或尚未帶來絕對安全感時就果斷押注，成功從一家傳統出版商蛻變為一家技術驅動型媒體公司。
這種技術驅動的文化深刻影響了該公司在軟體開發中應用 AI 的策略。對於 Axel Springer 而言，引入 AI 從來不是一個選擇題，他們真正關心的是：“我們該從哪裡切入？以及我們能多快跟上節奏？”
Axel Springer 將 Rovo Dev 嵌到了多個工程團隊建構軟體的核心流程之中。這項試點計畫緊扣真實的協作流、可衡量的最終成果，以及那些阻礙工程師將更多精力投入到有價值問題解決中的日常內耗。
速度只是副產品，專注才是終極目標
Axel Springer 發現，相比於單純的速度提升，一個更重要的成果是員工注意力的重新聚焦。Rovo Dev 協助資深工程師從重複性的環境搭建工作中抽身，將精力釋放給那些最關鍵的核心難題。
該公司使用了一個簡單的框架來思考 AI 可以在哪些地方提供協助。他們將工作劃分為四個像限：快速獲益（Quick Wins）、戰略押注（Strategic Bets）、時間黑洞（Time Sinks）和瑣碎填補（Fillers）。AI 在應對高頻、低複雜度的工作時展現出極高的價值，而這類工作恰恰是造成積壓工單（Backlog）噪音的元兇。這一洞察引出了一個更尖銳的問題：“如果一個 AI 智能體（Agent）能在幾秒鐘內搞定某件事，那麼它最初為什麼會被指派給一位資深工程師？”
“核心問題不在於如何更快地交付，而在於我們是否在做正確的事情。以更快的速度交付錯誤的工作毫無意義；相反，它上線得越快，造成的浪費往往就越大。”
—— Martin Bilt，Axel Springer 產品卓越負責人
引入 Rovo Dev 的意義不僅在於實現了任務的自動化，它更像一面鏡子，清晰地暴露了團隊過往在排列工作優先順序時的盲區，以及時間究竟流向了何處。
最大的紅利源於上下文，而非編碼本身
試點計畫中最核心的發現是：最顯著的時間節省並非來自程式碼生成，而是來自規劃、文件編寫、理解陌生程式碼以及偵錯。
對於每一個新的需求（Story），工程師通常需要經歷以下流程：閱讀 Jira 工單、尋找相關的 Confluence 頁面、理解現有的實現方案、確認需要修改哪些檔案，並在大腦中完整載入所有這些背景資訊——然後才能寫下第一行程式碼。這種“上下文載入”階段在 Sprint（衝刺）工效估算中通常是隱形的，但每個需求卻要實打實地耗費 30 到 45 分鐘。
當 AI 已經內嵌了這些上下文時，工程師和 AI 就可以在打開第一個檔案之前，基於一份務實的方案展開協作。程式碼的編寫速度固然變快了，但更大的紅利在於：團隊能夠以更低的沉沒成本把正確的事情做對。
當上下文的載入速度大幅提升時，企業獲得的收益也最明顯——工程師得以減少在重構還原工作背景上耗費的精力，將更多的心智留給解決核心難題。
始於小步快跑：4 個團隊與 3 個前置假設
試點伊始，只有 4 個處於不同 AI 成熟度階段的團隊參與其中。每個團隊都有自己獨特的協作流、習慣以及不同程度的審慎懷疑態度。Axel Springer 當時盤點出了 30 多個潛在的應用場景，但拉出一張長清單並不等於擁有了戰略。團隊最終將焦點收窄到幾個摩擦力最高、且能快速驗證反饋的具象領域。
他們啟動時並沒有制定一份長達半年的路線圖，也沒有撰寫冗長的評估檔案或戰略報告。其核心思路是：直接行動，觀察哪裡帶來了真實的效能提升，然後快速調整。
整個試點基於以下三個核心假設：
只要 AI 在工作流中確實有用，工程師就會主動接納它。
文件編寫是風險最低、最穩妥的切入點。
程式碼理解能夠幫助工程師跑得更快，尤其是在面對陌生系統或遺留（Legacy）系統時。
這三個假設最終全部得到了驗證。每個團隊都接納了 Rovo Dev，儘管接納的深度因團隊和個人而異。一些工程師將其作為現有工具鏈的輔助補充進行探索；另一些人則從第一週起就將其深度融入日常。這兩種行為都是非常有價值的反饋訊號。
事實證明，文件編寫不僅是一個低風險的切入點，它更成為了價值最高的應用場景之一，工程師們一致將其列為最省時間的領域之一。同時，在面對遺留系統和陌生領域時，程式碼理解功能同樣展現出巨大價值——過去，工程師在能夠動手修改之前，往往需要花費數小時去梳理其他團隊建構的業務邏輯，而現在這一痛點迎刃而解。
此外，團隊的實踐還遠遠超出了最初的假設。他們自發建立了未曾預設的工作流，並挖掘出了意料之外的應用場景。假設僅僅是試點的起點，而團隊將它帶到了更高的維度。
能夠自我複利的文件系統
第一個核心突破來自文件。Axel Springer 希望打造一套能同時服務於工程師、產品經理和業務線干系人的文件體系。它必須保持高度的時效性、可靠性、易得性且開箱即用。
團隊建構了一套在每次程式碼合併（Merge）時自動觸發的 GitHub Action。Rovo Dev 會讀取程式碼差異（Diff）並自動生成兩份產物：一份是供工程師和 AI 智能體閱讀的技術類 Markdown 檔案，另一份則是供更廣泛團隊查閱的、層面更高的 Confluence 頁面。同時，該 Confluence 頁面也會直接轉化為 Rovo 智能體的知識庫來源。
這裡沒有任何手動干預的步驟，也不會再出現“以後抽空再補文件”的空頭支票。從工單被領取的那一刻到程式碼最終合併，文件始終處於自動更新狀態。文件編寫不再是技術債，而是成為了工作本身自然衍生出的副產品。
隨後，Axel Springer 進一步放大了這一構想，將 Rovo Dev 的提示詞（Prompts）直接嵌入到了 Confluence 文件頁面中。例如，工程師可以加入一個提示詞，讓其自動檢索程式碼庫並生成一張包含螢幕互動流的 Mermaid 架構圖。在這張圖表下方，第二個提示詞可以直接根據底層程式碼，建立或更新該互動流中每個螢幕的詳細說明文字。
由於提示詞與最終的輸出產物比鄰而居，文件頁面真正實現了“自我維護”。產品經理或工程師不再需要擁有 GitHub 帳號、打開終端或組態 IDE，即可完成文件的更新。他們可以直接在 Confluence 頁面上進行迭代，直到輸出的圖文完全符合預期。
我們的目標是讓文件實現自我複利（Compound），而不是隨著時間逐漸老化腐爛。如果一件事情沒有沉澱為文件，它就會被遺忘；如果文件能夠隨著系統的演進同步進化，它就會在每一次迭代中變得越來越有價值。
在工程師察覺前，漏洞已被修復
第二個核心的閉環流程圍繞安全展開。Axel Springer 採用 Snyk 和 Wiz 進行持續的安全漏洞掃描。一旦檢測到風險，這些工具就會自動在 Jira 中觸發一個工作項。
Rovo Dev 會自動調取相關的上下文資訊，包括涉及的服務、依賴關係、CVE 詳細資訊以及權屬團隊資訊。隨後，它會評估影響面、起草修複方案並直接自動發起一個 Pull Request（PR）。在很多情況下，工程師只有在收到通知去審批這個修復 PR 時，才第一次意識到這個漏洞的存在。
這直接免去了繁瑣的漏洞會審排期，避免了安全債務積壓，資深工程師也不再需要從核心業務功能的開發中被抽離出來去排查問題。整個系統在隱形內耗形成之前，就已經在底層將問題消化了。修復程式碼合併後，系統會自動確認掃描結果、關閉 Jira 工單，並自動開啟下一個掃描週期。
“如果一個 AI 智能體能在幾秒鐘內搞定某件事，那麼它最初為什麼會被指派給資深工程師？AI 不僅僅是幫你幹活，它更像是一面鏡子，清晰地暴露了我們過往在排列工作優先順序時的盲區。”
—— Martin Bilt，Axel Springer 產品卓越負責人
團隊引入日常協作的其他實用工作流
除了文件自動化和漏洞修復之外，參與試點的成員還探索出了更多將 Rovo Dev 融入日常協作的方法。
其中一個工作流直接原生運行在程式碼倉庫中。通過簡單的指令，Rovo Dev 就能自動抓取 Jira 工單、規範化分支命名、檢查 Git 狀態、建立新分支、審查現有程式碼庫，並輸出一份務實的實現方案與執行清單。Jira 工單、Confluence 頁面、Compass 中的服務權屬等所有背景資訊，在工程師編寫程式碼的地方皆可隨手調取。
通過在終端命令列（CLI）和 CI 流水線中引入這一能力，工程師在啟動一個新需求時，不再需要孤軍奮戰去揣摩工單的字面意思並寄希望於自己沒有理解錯範圍。他們從一開始，就擁有了一份基於實際程式碼庫動態生成的篤定規劃。
另一個典型場景是 Sprint（衝刺）週報匯報。過去，團隊負責人可能需要在週五下午空出 30 分鐘，憑記憶拼湊總結、逐條閱讀 Jira 評論，為 Sprint 評審會做準備。而現在，只需一行指令即可自動生成摘要。Rovo Dev 會通盤讀取工單和 PR 上下文（甚至包括一些沒來得及建工單的實際工作），精準捕捉整個 Sprint 的交付全貌，並針對不同的匯報對象和發佈管道定製專屬的文字風格。
單看某一次週報所節省的時間可能並不驚人，但如果把範圍放大到每一個 Sprint、每一個團隊、每一個季度，這種在開發全鏈路中積少成多的時間回報，對於降低整體時間損耗具有不可忽視的意義。
此外，Rovo Dev 還強力支撐了 PR 描述自動生成 工作流。該流程會自動讀取當前分支與主分支（Main Branch）之間的差異，理解技術變更，對照開發人員核對清單，並最終生成一份完全符合團隊或公司規範的完整 PR 描述。它可以包含通俗易懂的業務摘要、測試要點，以及一份預先填妥的核對表（在可以自動確認的地方預填，在需要人類判斷的地方留空）。
過去那些完全取決於評審人個人風格的程式碼規範，如今由於工作流檔案直接存在於程式碼倉庫中，已經在每一次 PR 提交時實現了百分之百的標準化落地。
“正確的切入點不是去研究 AI 究竟能做什麼，而是去找出眼下最值得被消除的、槓桿率最高的阻力點在哪裡。請把目光聚焦在具象的應用場景上，而不是宏大的戰略框架上。”
—— Martin Bilt，Axel Springer 產品卓越負責人
Compass 與上下文能力層
Axel Springer 將 Compass 作為其核心的服務目錄（Service Catalog）。團隊利用 Forge 和 MCP（模型上下文協議）對其進行了深度擴展，從而讓元件、負責人和依賴關係能夠隨著程式碼的變更保持即時同步。現在，服務拓撲圖可以直接通過程式碼合併來驅動更新，而不需要指望有人在事後去進行痛苦的手動維護。
這套服務圖譜是由一位非工程師背景的員工在短短幾小時內搭建完成的，期間甚至利用了在火車通勤上的碎片時間。這帶來的直接好處是，任何新接手某項服務的工程師都能通過系統始終最新的上下文，一眼看清自己繼承的究竟是什麼。
正是這種更廣闊的上下文能力層（Context Layer），讓所有這些自動化協作流真正運轉了起來。AI 模型固然強大，但正如 Bilt 所言，缺乏上下文的 AI，充其量只是一個具備開發能力的聊天機器人。Rovo Dev 扮演的核心角色是將團隊已經深度依賴的各個系統串聯在一起：Jira 記錄任務工單、Confluence 沉澱知識文件、Compass 明確服務權屬與依賴、Jira Service Management 沉澱故障歷史、Jira Product Discovery 承載靈感孵化、GitHub 執行程式碼檢索與倉庫動作、Figma 規範設計系統與互動稿，還有 Snyk 和 Wiz 捕捉安全訊號。
有了這層底座，AI 不僅知道團隊正在建構什麼，更能理解這項工作的業務價值、責任人是誰，以及有哪些上下游依賴。越深厚的上下文，才能催生出越強大的 AI。
來自 Axel Springer 工程師的真實反饋
底層的技術架構之所以至關重要，是因為它切切實實地改變了人們的日常工作方式。試點計畫中的一位首席工程師對這種轉變做出了概括：“程式碼、文件和戰略方向終於打通了隔閡，能夠彼此對話並提供清晰的背景資訊。”
一位前端開發人員則描繪了他們如今面對新任務時的思考起點：“現在我們不再去糾結‘AI 能不能幫上忙’，而是從一開始就會去思考，如何利用 Rovo Dev 來啟動這項任務，以及如何寫出對路子的提示詞。”
這是一種全然不同的認知模式。一旦工程師開啟了這種思維方式，全新的協作流就會自然而然地成為他們開展工作時的肌肉記憶。
策略是如何落地的？
整個推廣過程中的每一步都經過了深思熟慮。Axel Springer 的落地策略緊扣以下五個精準動作：
通過啟動會凝聚共識：舉行宣講啟動會，正式引入工具並瞬間激發團隊的探索興趣。
開展小範圍短平快的實操體驗：將工具帶入各個團隊中進行短小精悍的面對面演示，不搞大而無當、堆砌理論的 PPT 匯報。
發展核心意見領袖：將團隊負責人和首席工程師培養為內部堅實的盟友，由他們親自牽頭真實的場景落地，自內而外地形成帶動力。
融入已有習慣：通過細緻觀察團隊現有的工程習慣來尋找最契合的互動介面，從大家早已熟悉的工作流切入，而不是生硬地增加一套全新的學習成本。
啟動內生動力：當工具的價值真正顯現時，需求便開始自髮式增長，最強烈的高採用率訊號莫過於“大家不再需要管理層在後面推著走了”。
同時，推廣方案也充分照顧到了不同團隊成員對於新技術的接受度差異。Axel Springer 將人群理性地劃分為四類：觀望者（Watchers）、嘗試者（Experimenters）、融合者（Integrators）和原生代（Natives）。整個推廣過程並沒有把精力浪費在那些“原生代”身上，因為無論如何他們都會自己找到出路；真正的槓桿在於協助“觀望者”邁出嘗試的第一步，並向“嘗試者”展示如何將工具進階融合到日常的深度協作中。
其核心原則是：從人們現有的認知錨點出發，而不是強求他們一步登天。
可衡量的量化成果
試點結束後的調研給出了直觀的量化反饋：
50% 的程式碼評審（Code Review）建議被開發者真正採納落地，而非僅僅停留在“被看到”層面。
每次 PR 的實際核心開發耗時顯著縮短了 30%。
工程師每週平均可省出約 2.5 小時 的精力。
87% 的工程師明確反饋，自己在重複性、事務性工作上耗費的時間減少了。
這些資料來自於真實的業務試點，而非刻意營造的理想化受控實驗。每一個指標的提升，背後都凝聚著團隊選擇改變傳統工作方式的決心。
模型選擇必須納入治理框架
本次試點帶來的一個核心教訓是：AI 模型的選擇絕不能任由其野蠻生長。 如果缺乏清晰的治理引導，工程師出於求穩心態，往往傾向於在任何場景下都直接呼叫最頂級的性能模型。這會導致成本迅速飆升，且從投入產出比來看並不總是最優解。
Axel Springer 將模型的選擇上升到了組織治理（Governance）的高度。團隊必須能夠清晰掌握模型的實際消耗分佈，並輔以必要的內部宣導，讓大家明白什麼量級的任務應該匹配什麼規格的模型。我們的目標是在確保產出質量的同時，實現成本的精準可控。
無需增加人員編制，效能天花板已然抬升
這種變革的漣漪效應已經超越了工程團隊本身。產品經理如今能夠直接交付與程式碼動態同步的活體產品文件，而不再只是靜態的需求說明書；設計師能夠為 AI 建構結構化的元件系統與規範化交接物，而不僅是交付靜態的設計稿；工程師則得以將核心智力傾注在系統架構設計與跨技術堆疊的複雜偵錯上，告別了無休止的日常缺陷修補。
在不增加人員編制的前提下，整個組織的交付效能天花板實現了跨越式抬升。
持續賦能是一場長跑
想要讓這種轉變行穩致遠，僅僅依靠一次驚豔的亮相是遠遠不夠的。賦能（Enablement）絕不可能通過搞一次一勞永逸的培訓班來解決。Axel Springer 將其視為一項需要長期踐行的日常機制，並建構了三個閉環螺旋：
學習（Learn）：知識需要有落腳的家園。Axel Springer 設立了專門的 AI 實踐中心（AI Center of Practice），用來統一沉澱最佳實踐、安全護欄（Guardrails）以及模型更新資訊，避免每個團隊都從零開始重複造輪子。同時，通過 Slack 專屬頻道、共享提示詞庫和常態化學習機制建立起活躍的社區生態。工程師可以隨時訪問統一的 GitHub 倉儲，獲取所有配套工具與指南。
傳遞（Carry）：鎖在中心的知識是無法自發觸達一線的。每個團隊中培育出的 “布道者（Champions）” 負責將先進經驗帶回各自的小隊。通過定製技能檔案和可復用的提示詞範式，讓知識在不同的團隊與業務領域之間實現無縫平移。過去那些消散在 Slack 聊天記錄裡的零散經驗，如今變成了一個新員工在入職第一天就能直接打開閱讀的結構化資產。
規模化（Scale）：系統必須具備不依賴持續人工干預也能實現自我迭代的機制。保存在程式碼庫中的智能體 Markdown 檔案能夠精準鎖定當前技術堆疊的團隊規範與設計模式，從而讓所有的提示詞、智能體和程式碼生成動作在啟動之初就自帶團隊的背景基因。同時，隨著新模型的快速迭代，團隊在實際生產中提煉出的新知會持續反哺給實踐中心，再由布道者將真實的一線實戰經驗帶回社區。
這個螺旋閉環永不停歇，它只會不斷奔向下一個最佳化節點。
從哪裡邁出第一步？
在積壓工單的堆積、頻繁的上下文切換以及大量重複性的基礎搭建工作面前，工程團隊的精力永遠處於超載狀態。此時，最具有建設性的提問絕不是“我們該如何寬泛地應用 AI”，而是：眼下，我們到底能去哪裡消除那個槓桿率最高、讓團隊最痛苦的阻力點？
Axel Springer 當初也僅僅始於 4 個團隊和 3 個簡單的假設。幾個月後，工程師們已經開始主動申請引入 Rovo Dev。這便是最篤定的訊號，證明這項技術已經在真實的實踐中沉澱出了無法被忽視的階梯價值。
您可以從尋找一個具體的團隊、鎖定一項高頻重複的瑣碎任務開始，給自己兩週的時間，去看看效能的飛躍是否真實發生。
交付速度固然重要，但專注帶來的深度才更具決定性。
留言