先看证据
把机制串起来
这里的“AI-native”不只是给员工配一个聊天机器人，而是让模型进入研发、运营和用户服务的主流程。核心前提是：模型负责生成代码、原型或客服回复，人和测试系统负责验证、审批与兜底。所谓“inside-out AI”，就是先用AI改造公司内部生产方式，再把同样的能力转化为用户可见的产品体验。
Airbnb把产品、设计和工程团队提前拉到原型阶段，用可运行原型和代码替代部分需求文档等中间产物，以减少跨团队交接损耗。AI参与代码生成后，代码本身成为团队共同推理和迭代的对象，研发循环因此被压缩。客服是首个面向用户的AI场景，因为错误会直接影响客户、订单和信任，部署风险高于内部编码。其关键做法是先构建模型和客服代理，再用合成数据进行充分测试，之后才进入生产。代价是需要额外建设评测、监控和人工兜底体系；代码产出增加也不等于质量、可靠性和商业价值必然同步提升。
['先从内部研发或客服等高频流程试点', '高风险客服必须先做合成数据测试', '把代码审查、线上监控和人工兜底保留', '不要仅凭AI代码占比判断研发质量']
从训练模型转向部署系统
Ahmad Al-Dahle 于今年1月加入 Airbnb 担任首席技术官，此前他在 Meta 负责生成式 AI，并参与了 2023 至 2025 年间 Llama 开源模型的发布。现在，他要推动的不是另一个基础模型，而是把 Airbnb 变成一家“AI-native company”，先改变内部产品开发方式，再把这些能力带到客户体验中。Airbnb 将这种路径称为“inside-out AI”，也就是从组织内部向外部服务扩散的 AI 转型。
这次转向的关键，不只是职位变化，而是技术前沿的判断发生了变化。Al-Dahle 认为，在 Meta 这样的模型公司，模型能力如何逐代提升、训练和迭代的飞轮已经相对清晰，下一道难题是把模型大规模部署到真实业务中。对 Airbnb 这样的公司来说，挑战不再是证明模型能生成什么，而是让模型进入产品、工程和服务流程后，能够持续产生可衡量的业务结果。
把代码和原型变成共同工作面
Airbnb 给出的第一个证据，来自软件开发本身。Al-Dahle 表示，公司目前约 60% 的代码由 AI 编写，发布的功能和改进同比增加近 80%，平均每位工程师的 pull request 吞吐量约提升至原来的 1.6 倍。这些数字不能单独证明 AI 已经改善了产品质量，但它们说明 AI 被放进了组织的生产流程，而不是停留在个人试用层面。
更重要的变化发生在团队协作顺序上。传统流程通常是产品需求、设计稿、工程实现和生产测试依次交接，各团队围绕文档和设计等中间产物沟通。Airbnb 现在让产品、设计和工程团队更早直接围绕原型工作，并把代码和原型作为主要的推理对象，减少过度生成文档和跨团队等待。这里的效率并非来自某个单独的代码生成器，而来自缩短交接链条，让一个可运行的东西更早成为团队共同讨论的对象。
客服自动化最能检验真实代价
Airbnb 将客户支持作为第一个面向用户部署 AI 的领域，但 Al-Dahle 同时把它称为“最难部署的问题”。原因很具体：客服回答直接影响用户，错误的后果也比内部代码建议更高。公司目前表示，大约一半客服工单已经可以完全由 AI 解决，第二季度披露的口径则接近 45%。
这套系统的核心并不是让 Agent 尽可能多地接管工单，而是在上线前先用合成数据建立一套大规模测试电池。流程是先构建模型和 Agent，再生成大量合成场景，之后才进入生产环境。与此同时，Airbnb 明确保留人工介入，尤其是安全问题等高风险事项。换句话说，“解决了 50%”并不是唯一指标，哪些工单被刻意排除在自动化范围之外，同样是系统设计的一部分。
Everest说明内部知识如何走向新服务
这种“由内向外”的路径还体现在 Airbnb 的新服务上。公司今年推出了杂货配送和机场接送两项 Airbnb Services 项目，其中杂货配送后来扩展到了更多城市。材料提到，一个名为 Everest 的内部组织上下文图谱工具帮助了这些服务的推出，也曾被用于加速一项新的外部服务发布。
Everest 的价值，至少从现有材料看，不在于它是一个面向用户的独立 AI 功能，而在于它把组织内部的上下文作为产品交付的一部分。产品团队、工程团队以及已有业务能力之间如果能更快建立关联，内部工具就可能缩短从构想到服务上线的路径。不过，材料没有进一步说明 Everest 的具体数据来源、推理方式、权限模型或它在两项服务中承担了哪些明确任务，因此不能把它简单描述成一个已经验证的通用“组织大脑”。
AI-native的边界在于主动保留人
Airbnb 的案例对技术负责人最有用的地方，是它把“AI 转型”拆成了几种不同的系统问题。工程侧要解决的是人如何围绕原型和代码协作，客服侧要解决的是 Agent 如何在高风险场景中被测试、限制和升级，内部工具侧要解决的是组织知识如何连接到新产品。三者都使用 AI，但成功条件并不相同，也不能用单一的自动化比例概括。
因此，Airbnb 的做法更像一套交付架构，而不是一次模型采购。可以明确借鉴的是：先把 AI 放进内部生产循环，用可运行原型缩短交接，再用合成数据和人工升级机制处理高风险外部场景。不能直接复制的是那些尚未公开的实现细节，以及把当前的吞吐量和客服解决率外推成长期质量结论。对任何准备推进类似计划的团队，最实际的判断标准不是“有多少工作由 AI 完成”，而是能否清楚说明哪些工作由 AI 完成、哪些必须由人接手，以及每一次接手是否有可追踪的理由。