Airbnb 表示，接近 60% 的工程代码已有 AI 参与。
这个数字很适合做标题，却不适合直接拿来管理产品团队。真正值得管理者追的，是更上一层的结果：一些关键项目从概念到交付最多缩短 60%；2026 年上半年发布的功能和改进同比接近增加 80%；从 AI Assistant 开始的客服问题中，近 45% 无需人工解决；每笔预订的客服相关成本同比下降约 16%。
这些数字并不能证明 AI 自动做对了所有产品判断。它们说明了一件更实际的事：当 Agent 被放进一套可管理的交付系统，执行可以变得更快、更便宜。
站在 Buda 的官方产品视角，AI-native 团队不是把所有决定交给模型。人负责目标、边界和验收，Agent 负责持续执行；上下文、过程文件和结果都必须可见、可复查。
三种 AI 场景，三种证据成熟度
Airbnb 同时披露了产品研发、客户支持和 AI 搜索的进展。它们都用了 AI，但不能写成同一种“成功”。
产品研发已经有交付证据。 Airbnb 表示，一些关键项目从概念到交付最多提速 60%，上半年发布的功能和改进接近增加 80%。公司把这个变化归因于 AI、团队能力和更好的执行共同作用，并没有全部算到模型头上。
客户支持已经有运营证据。 近 45% 只适用于“从 AI Assistant 开始”的问题。Airbnb 没有披露全部客服问题中有多少首先进入这个入口。客服相关成本每笔预订下降约 16%，官方原文也只说其中一部分来自 AI Assistant 的改进。
AI 搜索只有测试证据。 Airbnb 准备保留传统搜索作为默认入口，只让少量用户通过开关主动进入自然语言搜索。目前没有公布转化率、预订增量或留存结果。
这三个阶段分别是交付效率、运营结果和早期实验。把它们放在同一张图里比较，比笼统地说“Airbnb 全面用上 AI”更有价值。
代码更多，不等于产品更快
如果 AI 写出了更多代码，但需求依旧模糊、测试依旧薄弱、上线还堵在原来的审批队列里，团队只是增加了产出，没有改善系统。
产品速度应该从一个决定开始，直到拿到可靠证据为止。它包括调研、需求、实现、测试、发布、指标观察和修正。AI 可以降低每一步的执行成本，却不能替产品负责人决定哪个用户问题值得做、失败到什么程度必须停止。
所以 Airbnb 更有意义的数字，不是“60% 的代码”，而是部分项目从概念到交付更快，更多改进真正到了用户手里。它们仍需质量、采用率和业务结果继续验证，但已经更接近产品负责人真正承担的结果。
交付变快，应该换来更多有效试错
缩短交付周期的价值，不只是多发几个版本，而是能用更多次数把判断放到真实世界里验证。
一套可管理的 Agent 产品流程可以这样运行：
- 人定义用户问题、成功指标、约束条件和发布边界。
- Agent 搜集证据、整理需求、执行实现、运行检查并准备交付文件。
- 人审核证据，决定继续、修改还是停止。
- 团队观察线上结果，再把失败和新信息带回下一轮。
执行越快，人的判断越重要。一个错误需求，现在可能很快生成一整套看起来专业的研究、代码、文案和客服回复。如果验收条件不清楚，同一个错误也会更快穿过所有环节。
速度需要更明确的审核点，而不是更少的责任。
AI 搜索的开关，是一个好的发布边界
Airbnb 没有立刻让 AI 搜索替代所有用户熟悉的地点、日期和筛选器，而是先做小流量、可切换测试。
这让旧流程继续可用，也让新体验可以被比较。愿意尝试的用户主动进入，产品团队先观察自然语言搜索能否改善发现效率，再决定是否扩大。
这个方法不只适用于搜索。Agent 一旦要改变客户可见的流程，就应该先限定任务、保留可逆入口，并提前定义结果指标。内部演示跑通，不等于可以直接成为默认产品行为。
客服案例说明：升级给人也是产品的一部分
Airbnb 的数据不是“AI 替代了 45% 的客服”。它的分母更窄：从 AI Assistant 开始的问题。
因此，真正的产品不只是回答问题的模型，还包括周围的分流系统。标准问题应该被快速解决，争议、异常和高风险情况则要带着完整上下文交给人。
客服 Agent 至少要同时观察：
- 自主解决率
- 错误升级与错误拦截
- 解决时长
- 每次咨询或每笔业务的成本
- 重开工单、投诉和满意度
成本下降只有在服务质量没有同步下降时才有意义。
Buda 如何把 Agent 产出变成交付系统
Buda 围绕持续存在的 Agent Workspace 组织工作，而不是一次性聊天。团队可以把来源材料、需求、历史决定、生成文件和失败记录放在同一个项目里。Agent 用可复用的 Skills 按固定方法执行，在沙箱中操作文件和工具，并留下完整过程供人审核。
这套分工很清楚：
- 人设定意图： 选择问题、指标、约束和审批边界。
- Agent 执行： 调研、整理文件、起草、测试、比较和准备交付物。
- Workspace 保存上下文： 输入、中间文件和结果不再散落在不同工具里。
- 审核决定流转： 高影响结果只有在人看过证据后才能进入下一步。
- Skills 和 Automations 固化方法： 跑通的流程可以重复执行，而不是每次重写一段提示词。
Buda 不会替产品负责人决定一个功能该不该上线。它减少的是从决定到证据之间的执行损耗。
查看 Buda Agent Workspace，或在 Buda 中开始搭建一套可管理的 Agent 工作流。
最值得保留的管理指标
Airbnb 这次披露最有价值的，不是某个代码占比，而是管理单位发生了变化。
不要只问 AI 产出了多少。要问团队多久拿到一个可审核结果，人在哪一步发现了错误，客户行为发生了什么，以及成本下降时质量是否也被守住。
Agent 会让执行越来越充足。稀缺的仍然是人的产品判断。