Booking.com 在 AI 落地方面的探索
https://www.bilibili.com/video/BV1dcPKe3ENe/#reply256064109568
这是Booking.com和Sourcegraph的技术负责人在昨天 AI Engineer Summit 2025 上的一场主题为“在企业 SDLC 中构建真正带来投资回报的 AI 智能体”的演讲，他们分享了自己如何开发与使用 AI 工具，来替公司里的开发者节约时间、减少重复劳动，还能保证产品质量。在某种程度上，这就和我们在日常生活里寻找各种“捷径”或“自动化工具”有异曲同工之妙。
这场演讲围绕一个大主题：如何在企业中使用 AI（人工智能）来真正节省时间、提高效率并获得实实在在的回报。可能你不是专业的程序员，但在工作和生活里，你也常常会遇到那些繁琐、重复的事情。如果我们有办法用更聪明的 AI 系统来分担琐碎、让自己有更多时间去做更有创造力或更有意义的工作，那也是挺不错的。
AI 解决了 Booking.com 中的哪些“痛点”？
- 代码库太大、太旧就好比我们的电脑里堆了很多文档、照片、软件，到底该删哪儿、该留哪儿？最后找个东西怎么都翻不出来。Booking.com里有几千名开发人员、海量代码，各种“过时的功能开关”、“没用的旧功能”就像老旧文件一样堆积成山，找和改都很费时。这些“旧东西”不但让系统臃肿，也拖慢了后续新功能的上线速度。
- 日常工作重复度高想象一下，你每天可能要应对相同的邮件模板、相同的表格操作，甚至相同的对话。时间一久，就失去了激情和创造力。对他们来说，是在同一个庞大系统上修改、审查代码，可能 80% 都是重复操作。“小问题”却要手动翻大量文档或代码才能找到答案，极其浪费时间。
- 团队合作成本高同事之间得相互审阅彼此的修改，还要确保所有人遵守项目的统一规则或合规要求。设想一下，如果每次你都要仔细对照一份几十页的“规范手册”，然后挨个校对，很繁琐也容易出错。
他们怎么用 AI 来解决？
- 智能搜索与自动化提示就像给你的文档库装了一个“超级搜索引擎”，能理解关键词甚至上下文，立刻帮你在海量资料里找到精确的内容。在Booking.com，他们用 Sourcegraph 的“智能搜索”功能快速定位旧代码或特性开关，然后再用 AI 模型（Cody）判断哪些能删，哪些需要保留，就像一个自动化的“断舍离”助手。
- 让 AI 帮你码字、审阅和修正你可能已经见过一些自动写作或自动补全工具，AI 能在编辑器里推荐或帮你改错，还能根据公司内部的规则给出修改建议。在Booking.com的场景下，AI 不只写代码，还会根据预先定义的“企业规范”和“审核规则”，在审阅过程中自动指出问题，并给出修正建议。这样人类的审查者就不必再“重头到尾”一遍遍去对照那些复杂规范。
- 长期目标：自动化地清理旧系统、升级基础架构我们平时也会有电脑系统定期清理的需求，把冗余的文件删掉，让系统更快、更稳定。他们希望在几个月内，通过 AI 辅助大规模迁移，让老旧代码变得更现代、更易维护，而不是拖个几年还没动工。
这些工具带来的价值与启示
- 节省时间，减轻负担在演讲中提到，Booking.com 的一些开发者如果持续使用 AI 工具，效率能提升30% 以上。一天 8 小时的工作量，只需花 5~6 小时就可完成。这让他们能拿出更多精力去做更有创造力或价值更高的事情。这一点放在我们日常生活里，你也可以想想：如果有一个智能工具帮你做重复、琐碎、机械的事，能帮你省多少功夫？
- 提升质量并保持一致AI 可以帮助自动检查并修复那些人工容易忽视的规范性问题，减少人为失误。在公司或团队里，也更好维持统一标准，就像一个耐心又不会犯困的“质量管理员”。
- 教育与学习他们反复提到，“培训团队”非常关键。再好的工具，如果不了解使用方法和思路，也感受不到真正的价值。对我们普通人而言，想用好一款新软件或新 AI 工具，也要学会“怎么问”、“怎么给它提示”。通过合适的提问，AI 才能真正解决你的具体问题。
- 不是“包治百病”，但有无限潜力演讲嘉宾也坦言，他们还在不断摸索和试验，AI 既有机会也有局限。目前最常见的风险就是“幻觉”（AI 胡乱编造答案）、“隐私问题”（公司机密数据的安全），以及如何更好地落地（比如整合进现有工具、培训员工）。但对于“重复琐碎”的场景，AI 的潜力是巨大的。
这次演讲的核心，其实不只适用于软件开发者。它给我们的启示是：面对日益繁琐的数字化世界，我们可以借助“智能体”来减少重复劳作、提升工作效果。
- 你可能在文档编辑、报表制作、邮件回复等环节，都能找到“AI 小助手”的用武之地；
- 你可能也需要培训自己或培训团队，学会正确和 AI 工具“对话”，才能最大化地获得收益；
- 你还需要考虑企业规范、团队文化、安全等多种因素，这些都需要一个循序渐进的过程。
一句话总结：
当“自动化”不再只停留于机械流程，而是能读懂复杂环境、给出直接改进建议的时候，我们就离真正的“降本增效”更近一步了。不断学习、不断试错，才能让 AI 与我们的实际工作完美结合。 希望这篇简单介绍能帮你了解这场演讲的实质。如果有机会，不妨进一步关注Booking.com、Sourcegraph以及更多企业在 AI 落地方面的探索，也许下一步，你就能把这些方法带入自己的工作流程，真正让“AI 智能体”成为你可靠的帮手。
完
演讲文稿：在企业 SDLC 中构建真正带来 ROI（投资回报）的 AI 智能体
演讲嘉宾：
- Bruno Passos（来自 Booking.com）
- Beyang Liu（来自 Sourcegraph）
Beyang Liu 00:00:13：大家好，最近过得怎么样？今天上午的内容很有趣，也看到台下有各种规模的软件开发者们。我叫 Beyang，是一家公司 Sourcegraph 的 CTO 和联合创始人。
Bruno Passos 00:00:30：大家好，我是 Bruno Passos。我在 Booking.com 负责开发者体验（Developer Experience）的产品工作。过去一年中，我也在负责 Booking.com 里关于 AI 创新相关的部分。
Beyang Liu 00:00:34：很好。今天我们想和大家聊一聊，我们是如何通过合作来构建软件开发的 AI 智能体，自动化处理 Booking.com 内部大量的重复性工作，从而真正带来 ROI（投资回报）和实际影响的。
Bruno Passos 00:01:00：先问一下，在座的各位，有多少人听到过类似的情景：你在一家大公司工作，CEO 进来对你说，“我们必须采用 AI！”然后大家就会想，“好啊，那具体怎么做？怎么衡量成效？” 可能公司就买了个 Copilot，或者做了点其他 AI 工具方面的尝试。结果过了六个月，CFO 或者某个领导会问，“我们买的 AI 工具 ROI 怎么样？我们构建的那些 AI 智能体，产生了什么可衡量的影响吗？”事实上，很多人对于如何回答这类问题都没太大把握。然而，Bruno 和 Booking.com 在这些方面走在了前面。他们不仅非常积极地引进并构建优秀的工具，而且也能真正去跟踪并展示这些工具和 AI 智能体在组织里的实际影响。
Beyang Liu 00:01:51：你过奖了，其实我们也还在摸索中，感觉还远远谈不上“前沿”。不过我先简单介绍一下 Booking.com。绝大多数人都听说过我们公司，我们的目标是让所有人更轻松地体验世界。而我所在团队的目标，则是让我们公司的开发者能畅通无阻地干好他们的工作。但实际情况是：在某些业务领域，我们确实开发得不错；可在另一些方面，我们离理想状态还很远。
Bruno Passos 00:02:25：为了让大家有点背景：Booking.com 是全球最大的在线旅行平台之一，每天能处理大约 150 万间夜的预订量，公司内部有 3000 多名开发者。请问在场有多少人所在的公司开发者数量超过 1000 人？（示意很多人举手）好，的确有不少朋友。从更偏技术的数据看，我们每年会有大约 25 万个 Merge Request（合并请求），每年要运行 250 万次 CI（持续集成）任务。而且我们是一家极度依赖数据驱动的公司，会通过大量的实验来做产品决策，这些主要是 A/B 测试。因为我们对实验和数据如此上心，导致我们会在代码里留下大量实验相关的特性开关（feature flags）和死代码（dead code）。随着时间推移，这些没被清理的开关和测试代码越积越多，使得我们的代码库愈发臃肿。
有个小插曲：我在给幻灯片做最后调整时，我孩子看到 “feature flags” 这个词，就问我：“什么是 feature flags？” 我解释说其实它们会一直残留在代码里，慢慢污染代码库。然后他们说，“那这些是不是就像代码放屁（code farts）？” 我就赶紧跟他们解释，其实这更像代码异味（code smells），不过这里就不多展开了（笑）。
总之，随着代码库日益臃肿，开发周期也被拉长了，开发者为了调试和理解代码，可能 90% 的时间都在做重复性工作。请问有谁感同身受？（很多人举手）我们每个季度都会向开发者做调查，了解他们对代码库的感受，显然维护庞大而老旧的代码库是个难题。所以我们觉得必须要做点什么。
Beyang Liu 00:05:16：我见过太多杰出的开发者，因为要处理那些持续十年的陈旧特性迁移（dead feature flag migrations）而精疲力竭。真是让人唏嘘。
Bruno Passos 00:05:30：是啊，真的有不少“天才”开发者，都被压在这种工作上。举个例子——
Beyang Liu 00:05:30（插话）：我前阵子和 PwC（普华永道）的一个人聊过，他们花了大量心力做一个专门更新旧代码的系统。那个人非常聪明，而且用的技术也很有趣。但想想看，如果这些人可以把心力放在新功能或真正解决用户需求上，而不是整天去应对陈旧代码和遗留问题，是不是更好？这也就是为什么我们 Sourcegraph 公司的存在意义：我们的使命是让大规模软件开发变得可行、有条理。你可能听说过我们过去几年的一些产品，比如：
- Code Search（代码搜索），就像你自己的代码谷歌一样，帮助开发者快速找到并理解代码。
- 大规模重构与代码迁移工具，便于对大型代码库进行结构化修改。
- AI 编码助手 Cody，它具备上下文感知功能，针对大型、复杂的代码库做了优化。
- 以及我们今天要谈的重点：用于自动化繁琐开发流程的“AI 智能体”。这些工具有一个核心目标：让开发者在“内部循环”（inner loop）里工作更快、更高效，同时在“外部循环”（outer loop）中尽可能自动化那些重复、繁琐的工作。
Bruno Passos 00:07:13：我们大约在两年多前开始使用 Sourcegraph 的代码搜索。效果非常好，大家能非常迅速地在那庞大的代码库里找到小段上下文。这个工具确实很棒，值得大家去试试。然后在大约一年前，也就是去年一月份的时候，我们开始尝试使用 Sourcegraph 的 AI 编码助手 Cody。为什么选它呢？因为 Cody 会结合 Sourcegraph 的搜索功能，这就让它能针对我们那庞大的代码库提供相对准确的上下文。之后，我们的目标就变成了：利用 Cody 和 Sourcegraph 搜索，进一步构建 AI 智能体，以自动化我们内部更多的重复性工作。
Bruno Passos 00:07:58：下面给大家大致回顾一下我们在过去这一年是如何一步步走过来的，主要想说明进展速度有多快。
- 1 月（去年）：我们让公司 3000 名开发者都可以用 Cody。有些人用过后觉得挺好，就继续使用；也有人试了一下感觉没啥价值，就停用了。我们很纳闷为什么会这样。那时候公司只允许使用一种特定的 LLM（大型语言模型），而且有一些令牌（token）的限制。
- 当我们想要真正放手尝试时，就得去掉这些限制。所以跟 Sourcegraph 商量后，他们很快就给我们提供了一个能为每个开发者灵活选择多种 LLM 的能力。这样一来，不同场景下我们可以选不同的 LLM——比如，要做大规模清理老代码，就选某个在此方面更擅长的模型；要写新服务或新功能，就选另一个更合适的模型。
- 7 月：我们开始正式培训开发者如何使用 Cody。事实证明培训非常重要。一些原本没感受到价值的开发者，在正确学习怎么用之后，就爱上了 Cody，变成我们说的“日常活跃用户”（daily users），下面会讲为什么这点很关键。
- 当时我们最关注的指标是“节省了多少开发时间”（hours saved），但因为我们是一家数据驱动公司，这种指标的统计口径并不太严谨，只是对少量开发者的主观调查，并不算非常科学。可能大家也在外面看到有人说，“我们用了 AI，一年省了几十万小时”之类的夸张数字。那其实挺玄乎的，我管那种叫“半真半假的吹捧”。
- 10 月：我们决定要用更多“硬指标”来衡量 AI 的价值，我们重新制定了 KPIs（关键绩效指标）和各项度量指标，并展开了比较深入的研究。
- 11 月：根据这些新指标，我们发现，如果某位开发者在一个月里有 12 天以上经常用 Cody，那么他们的开发效率平均能提升 30% 以上——相当于同样的周期里可以多出来大约三分之一的生产力。最重要的是，我们还与 Sourcegraph 联手，通过在 Cody 前面加一层 API，把它在 Slack、Jira 等常用工具里的使用场景也打通了，而不再局限于 IDE。
Bruno Passos 00:10:09：刚才提到我们在 10 月份重新确定了一些 KPI，它们必须是我们能在一年内度量得到的。因为 AI 发展太快，如果我们目标定得太远，等不到结果就过时了。我们最后确定了四大 KPI：
- Lead Time for Change（变更上线的周期）
- 质量
- 代码库洞察（Codebase Insights）
- 最终是否能加速重构（Re-platform）
我们把指标分成短期、中期、长期三类。短期能快速看到结果的，比如我们观察了MR（Merge Request）的审核时间（Time to Review）。结果发现：每天都用 Cody 的开发者，比不用或很少用的开发者，合并请求数量能多 30% 左右，并且 MR 里提交的代码量更少、粒度更精细。虽然我们还没完全搞清楚为什么更少的代码量能实现更多的合并请求，但我们在继续分析。
在质量方面，我们想利用 AI 来发现潜在的安全漏洞。例如，把过去的安全问题上下文交给 Cody，让它帮我们预测哪些地方还可能存在相似的漏洞，或找到尚未被修复的隐患；以及提高测试覆盖率，让那些遗留或重构的代码也有足够的测试保障。
在代码库洞察方面，我们想让 AI 帮忙追踪哪些特性开关或代码片段早就没用了，应该被移除，或者哪些代码性能不佳，需要优化。
最终，我们希望通过这些努力，让我们可以把重构（Re-platform）的时间从可能几年缩短到几个月。
Beyang Liu 00:13:01：在我们不断迭代 Cody 时，我们也注意到：开发者在使用 AI 写代码的同时，也会去调用底层的 API，进行更多样化的“多轮对话”和“长链式”自动化，就形成了我们现在所说的“AI 智能体”。在这过程中也踩了很多坑，比如如何让人们知道 AI 智能体能做什么、不能做什么；以及怎么避免出现荒诞不可信的幻觉（hallucination）等。不过我们最后索性说：不如大家一起头脑风暴，干脆我直接飞到阿姆斯特丹，跟 Booking.com 的团队搞个为期一周的黑客松，一起做点原型出来！这个黑客松的第一个产物，就是用 AI 智能体自动生成 GraphQL 查询的工具。Booking.com 有一个超大的 GraphQL Schema，本身就有上百万 token，那可是任何现有 LLM 都放不下的上下文，就算放得下也会有各种幻觉、答非所问。我们做的这个 AI 智能体，会先用 Sourcegraph 搜索在庞大的 schema 中定位所需字段，然后智能地筛选、递归搜索相关节点及其父节点，用一种带“思考链”（chain-of-thought）形式逐步构造出一个有效的 GraphQL 查询。如果你不做这层智能检索，单纯让一个语言模型“硬想”，它给出来的结果往往就是废话或错误。我们在黑客松上专门打磨了提示词（prompt）和逻辑，这才得到一个可行的解决方案。
Bruno Passos 00:14:37：另一个非常有趣的 AI 智能体，是自动化的代码迁移。我们的老代码里有一些函数就长达一万多行。我们想看看：能不能借助这些工具来加速重构或者把老代码迁移到新平台。核心思路是把 Sourcegraph 的代码搜索和结构化提示（structured prompt）结合起来，把臃肿的大块代码分割成可处理的小块，然后逐个搞定。在这个过程中，我非常建议大家在类似场景里，多和对方的专家“结对编程”或共同设计，把他们的专业知识直接带到现场。对我们来说，这非常宝贵。还有就是开发者的教育和培训。当初有些人一上来就说“Cody 没啥用”，那是他们根本没学会怎么给 LLM 合理地提供上下文和提示词。真正学会之后，他们就发现价值很大。这个 AI 智能体能让我们从“要摸索几个月才能弄清代码到底要怎么迁移”这样一个漫长过程，缩短到在黑客松里花两天，就弄出一个可行的拆解方案，然后立刻动手做一些“低垂的果实”（low-hanging fruits）。当然现在还在实验阶段，但已经看到非常可观的潜力。
Beyang Liu 00:17:26：还有一个非常通用的场景就是“代码审查”（Code Review）。几乎所有公司都会做 Code Review，对吧？有谁从来不做 Code Review？（如果有人举手）那我倒想和你详细聊聊。我们起初觉得代码审查可能没啥新鲜，因为市场上已经出现了好些专门做 AI Code Review 的初创公司。但在跟 Booking.com 以及其他企业深入交流后，我们发现，每家公司在 Code Review 这件事上都有一大堆自己独特的规则、规范，甚至强制要求，有些是产品质量要求，有些是合规或安全要求。市面上的现成工具大多不够灵活，无法完全适应企业内的各种自定义规则。因此我们做了一个界面化的配置，让团队能定义自己想要检查的规则，比如“哪些地方必须加日志”，或者“在 Booking.com 我们不允许出现某种写法”之类的，然后让 AI 智能体去对照这些规则，检查 Pull Request 或 Merge Request 中每个修改的文件，尽量只对真正违反规则的地方做提示和评论。这样既不会很吵（噪音少），也能真正落实各自团队的标准。
Bruno Passos 00:18:36：了解了这些之后，我们也在思考下一步怎么走。我们非常看好的一种模式叫做“声明式编程规范”（Declarative Coding）。想想你现在的 CI/CD 流水线，它会在构建或合并时告诉你“错误”，但如果我们能把这些规范前置到编辑器或 IDE 里，能让服务在你写代码时就告诉你“这里错了，应该怎么改”，那简直就像“自愈”一样，这才真正厉害。把所有合规、标准、最佳实践都声明到系统里，让 AI 智能体来审查、修正，或者在 PR 阶段就自动指出问题并给出修复建议。我们相信这会是我们今年在 AI 智能体方向上的重要目标，当然还要做很多实验和验证。
Beyang Liu 00:19:47：对，我多说一句。从软件开发诞生以来，就有一个顽疾：任何成功的软件，最终都会被它自己的成功所拖累。为什么呢？因为有用户、有收入，就会有新需求和新特性，企业为了竞争，就会不断在老代码上“打补丁”，也会引入各种技术债务。随着项目越做越大、开发者越多，起初统一的理念和标准渐渐失去约束力，项目就会越来越臃肿。如果我们用“声明式编码规范”，让高级工程师或架构师把各种必须满足的规则先写好，然后在项目中自动检查，不管是人写的还是 AI 智能体生成的代码，都能被统一的规则体系约束，就能避免大量后来才发现的技术债和代码混乱。这样能解决软件规模增长带来的管理难题。
Bruno Passos 00:20:00：是的，对于大公司，还有各种合规要求之类，也完全可以这样做。在过去一年里，我们和 Sourcegraph 一起努力探索这一切，也得出一个最重要的经验：一定要给开发者足够的教育和培训。所有的技术落地都离不开人本身，只有当他们真正了解如何用这些工具，才能领悟到它的价值。从而像我们一样，把最初只会用几天就搁置的用户，培养成那种几乎每天都离不开 AI 工具的核心用户。这样才能真正发挥出我们数据里统计到的“30% 以上”的效率提升。
Beyang Liu 00:20:32：如果大家想更深入地讨论这些内容，可以到楼下的 Sourcegraph 展位来找我们交流。我明天也有一场相关主题的演讲，会更细致地讲讲我们构建这些 AI 智能体的技术细节。欢迎大家前来。非常感谢！
Bruno Passos 00:20:47：也谢谢大家的聆听，希望能对你们有所启发。