德国媒体巨头 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 多个潜在的应用场景，但拉出一张长清单并不等于拥有了战略。团队最终将焦点收窄到几个摩擦力最高、且能快速验证反馈的具象领域。

他们启动时并没有制定一份长达半年的路线图，也没有撰写冗长的评估文件或战略报告。其核心思路是：直接行动，观察哪里带来了真实的效能提升，然后快速调整。

整个试点基于以下三个核心假设：

1. 只要 AI 在工作流中确实有用，工程师就会主动接纳它。

2. 文档编写是风险最低、最稳妥的切入点。

3. 代码理解能够帮助工程师跑得更快，尤其是在面对陌生系统或遗留（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 的落地策略紧扣以下五个精准动作：

1. 通过启动会凝聚共识：举行宣讲启动会，正式引入工具并瞬间激发团队的探索兴趣。

2. 开展小范围短平快的实操体验：将工具带入各个团队中进行短小精悍的面对面演示，不搞大而无当、堆砌理论的 PPT 汇报。

3. 发展核心意见领袖：将团队负责人和首席工程师培养为内部坚实的盟友，由他们亲自牵头真实的场景落地，自内而外地形成带动力。

4. 融入已有习惯：通过细致观察团队现有的工程习惯来寻找最契合的交互界面，从大家早已熟悉的工作流切入，而不是生硬地增加一套全新的学习成本。

5. 激活内生动力：当工具的价值真正显现时，需求便开始自发式增长，最强烈的高采用率信号莫过于“大家不再需要管理层在后面推着走了”。

同时，推广方案也充分照顾到了不同团队成员对于新技术的接受度差异。Axel Springer 将人群理性地划分为四类：观望者（Watchers）、尝试者（Experimenters）、融合者（Integrators）和原生代（Natives）。整个推广过程并没有把精力浪费在那些“原生代”身上，因为无论如何他们都会自己找到出路；真正的杠杆在于协助“观望者”迈出尝试的第一步，并向“尝试者”展示如何将工具进阶融合到日常的深度协作中。

其核心原则是：从人们现有的认知锚点出发，而不是强求他们一步登天。

可衡量的量化成果

试点结束后的调研给出了直观的量化反馈：

• 50% 的代码评审（Code Review）建议被开发者真正采纳落地，而非仅仅停留在“被看到”层面。

• 每次 PR 的实际核心开发耗时显著缩短了 30%。

• 工程师每周平均可省出约 2.5 小时 的精力。

• 87% 的工程师明确反馈，自己在重复性、事务性工作上耗费的时间减少了。

这些数据来自于真实的业务试点，而非刻意营造的理想化受控实验。每一个指标的提升，背后都凝聚着团队选择改变传统工作方式的决心。

模型选择必须纳入治理框架

本次试点带来的一个核心教训是：AI 模型的选择绝不能任由其野蛮生长。 如果缺乏清晰的治理引导，工程师出于求稳心态，往往倾向于在任何场景下都直接调用最顶级的性能模型。这会导致成本迅速飙升，且从投入产出比来看并不总是最优解。

Axel Springer 将模型的选择上升到了组织治理（Governance）的高度。团队必须能够清晰掌握模型的实际消耗分布，并辅以必要的内部宣导，让大家明白什么量级的任务应该匹配什么规格的模型。我们的目标是在确保产出质量的同时，实现成本的精准可控。

无需增加人员编制，效能天花板已然抬升

这种变革的涟漪效应已经超越了工程团队本身。产品经理如今能够直接交付与代码动态同步的活体产品文档，而不再只是静态的需求说明书；设计师能够为 AI 构建结构化的组件系统与规范化交接物，而不仅是交付静态的设计稿；工程师则得以将核心智力倾注在系统架构设计与跨技术栈的复杂调试上，告别了无休止的日常缺陷修补。

在不增加人员编制的前提下，整个组织的交付效能天花板实现了跨越式抬升。

持续赋能是一场长跑

想要让这种转变行稳致远，仅仅依靠一次惊艳的亮相是远远不够的。赋能（Enablement）绝不可能通过搞一次一劳永逸的培训班来解决。Axel Springer 将其视为一项需要长期践行的日常机制，并构建了三个闭环螺旋：

 【学习 loop】 —— 沉淀沉淀到 AI 实践中心（Guardrails、Prompt库）
       ↓
 【传递 loop】 —— 依靠各团队的 Champion，将知识转化为 portable 的文件资产
       ↓
 【规模化 loop】—— 在 repo 中部署 markdown 规范，新模型学习流持续反馈回中心

• 学习（Learn）：知识需要有落脚的家园。Axel Springer 设立了专门的 AI 实践中心（AI Center of Practice），用来统一沉淀最佳实践、安全护栏（Guardrails）以及模型更新资讯，避免每个团队都从零开始重复造轮子。同时，通过 Slack 专属频道、共享提示词库和常态化学习机制建立起活跃的社区生态。工程师可以随时访问统一的 GitHub 仓储，获取所有配套工具与指南。

• 传递（Carry）：锁在中心的知识是无法自发触达一线的。每个团队中培育出的 “布道者（Champions）” 负责将先进经验带回各自的小队。通过定制技能文件和可复用的提示词范式，让知识在不同的团队与业务领域之间实现无缝平移。过去那些消散在 Slack 聊天记录里的零散经验，如今变成了一个新员工在入职第一天就能直接打开阅读的结构化资产。

• 规模化（Scale）：系统必须具备不依赖持续人工干预也能实现自我迭代的机制。保存在代码库中的智能体 Markdown 文件能够精准锁定当前技术栈的团队规范与设计模式，从而让所有的提示词、智能体和代码生成动作在启动之初就自带团队的背景基因。同时，随着新模型的快速迭代，团队在实际生产中提炼出的新知会持续反哺给实践中心，再由布道者将真实的一线实战经验带回社区。

这个螺旋闭环永不停歇，它只会不断奔向下一个优化节点。

从哪里迈出第一步？

在积压工单的堆积、频繁的上下文切换以及大量重复性的基础搭建工作面前，工程团队的精力永远处于超载状态。此时，最具有建设性的提问绝不是“我们该如何宽泛地应用 AI”，而是：眼下，我们到底能去哪里消除那个杠杆率最高、让团队最痛苦的阻力点？

Axel Springer 当初也仅仅始于 4 个团队和 3 个简单的假设。几个月后，工程师们已经开始主动申请引入 Rovo Dev。这便是最笃定的信号，证明这项技术已经在真实的实践中沉淀出了无法被忽视的阶梯价值。

您可以从寻找一个具体的团队、锁定一项高频重复的琐碎任务开始，给自己两周的时间，去看看效能的飞跃是否真实发生。

交付速度固然重要，但专注带来的深度才更具决定性。