当一笔交易需要十几通电话，AI 必须学会"接着聊"

一辆二手车的交易，为什么会变成一场马拉松式的对话

Cars24 官方将自身定位为"全球最大的 AI 原生汽车交易生态系统之一"（原文：one of the world's largest AI native automotive ecosystems for buying and selling cars in India），业务运营地点在印度，并延伸至阿联酋和澳大利亚。它覆盖二手车买卖的完整链条：从发现、融资、检测到售后和再流通。在印度市场，绝大多数汽车交易仍然依赖线下流程、纸质文件和人工协调——这不是一个"点击下单"就能完成的品类。

一位买家的典型旅程可能是这样的：先打电话咨询预算范围内有哪些车型，再预约到店试驾，试驾后需要准备融资文件，融资审批期间可能改变偏好，改变偏好后需要重新推荐和预约，最终成交后还有保修、退换和售后问题。整个过程跨越电话、文件检查和多轮跟进，可能持续数天乃至数周。卖家的流程同样冗长：收集车辆信息、安排检测、发送提醒、处理爽约、了解竞品报价。

这意味着 Cars24 面对的不是"如何用 AI 回答一个问题"，而是"如何在一段持续数天的旅程中，让 AI 记住上下文、主动跟进、并在每个环节做出恰当的下一步判断"。随着交易量增长，依靠不断扩张运营团队来维持体验一致性，在成本和管理复杂度上都不可持续。

Vikram Chopra 的这段话点出了 Cars24 面对的核心矛盾：体验质量过去取决于"谁接了电话"——这是一个不可规模化的变量。Cars24 的选择是用 OpenAI API 构建覆盖买车、卖车、融资、跟进和售后的语音与聊天智能体，同时将 ChatGPT Enterprise 和 Codex 推广到工程、财务、法务、营销和运营团队。

但这个选择本身也带来了新的问题：一个能"接着聊"的 AI 系统，需要什么样的任务结构和人机分工？

智能体不是在入口等着客户，而是沿着旅程主动推进

官方案例描述了一个关键的设计决策：Cars24 没有从最容易的环节（比如常见问题自动回复）开始，而是从销售漏斗的中段和底部切入——官方原文将其描述为"业务中限制最多的部分"（one of the most constrained parts of the business），即"对话驱动转化"的环节。

买方场景：从需求理解到售后闭环

当买家拨打 Cars24 电话时，AI 语音智能体会询问预算、家庭规模、通勤需求和偏好车型，从 Cars24 目录中推荐匹配车辆，预约试驾，并帮助客户了解融资选项。试驾前，智能体会主动跟进确认到访、在偏好变化时推荐替代车辆，并补充融资所需信息。试驾后，智能体会确认客户是否继续购买、需要再次预约还是查看其他选择。购买完成后，支持范围延伸到反馈收集、保修问题、退换和售后服务。

卖方场景

卖方流程同样包含连续跟进：收集车辆信息、安排检测、发送提醒、协助改期，以及在客户已向其他渠道售车时收集竞品信息。

线索重新激活

官方案例还特别提到了一个与卖方流程并列的场景：对于过去在 10 天后流失的线索，AI 智能体现在会重新联系客户、判断是否仍有意向，并在 Cars24 能够匹配客户期望价格时将其重新引入漏斗。

每月超过一百万分钟的 AI 对话处理量，说明这个系统已经在生产环境中承担了大规模的客户交互。但这个数字衡量的是"处理规模"，而不是"处理质量"或"业务结果"。一百万分钟的对话中，有多少最终转化为预约、多少转化为成交、多少需要人工介入——这些才是判断系统有效性的关键指标，而官方材料没有给出。

从客户对话到内部运营：Codex 如何进入工程和财务的日常任务

Cars24 的 AI 部署不止于客户侧。官方案例记录了 Codex 在产品、工程和财务流程中的参与方式，以及 ChatGPT Enterprise 在更广泛团队中的采用情况。这条线索揭示了一个更深层的组织变化：AI 从"面向客户的工具"扩展为"内部运营层"。

产品与工程：让 Codex 成为任务流的参与者

产品经理使用 Codex 创建和完善 Linear 工单。工程团队在缺陷报告中标记 Codex，让它接手已定义的任务。Codex 还会汇总 GitHub 中的工作进展并向团队发布更新，减少了保持工作同步所需的站会次数。官方案例提到，Cars24 在数周内围绕 Linear 重新组织了项目管理工作流，为 Codex 参与日常工作创造了更清晰的路径。

这里有一个值得注意的设计选择：Cars24 不是让 Codex 独立完成端到端的开发任务，而是让它嵌入已有的任务管理系统（Linear）和代码协作系统（GitHub），在"工单创建、任务梳理、实现、缺陷解决和进度更新"这条链路上逐步参与。这意味着 Codex 的工作边界由现有系统中的任务定义来约束，而不是由 Codex 自己决定做什么。

财务与采购：从数据汇集到异常检查

在财务与投资者关系工作中，团队使用 Codex 从系统记录中汇集数字、运行分析，并准备投资者报告工作流——不再需要手动向多个业务负责人追要数据。另一个财务流程更值得关注：Codex 被用于检查超过预设阈值的采购申请和采购订单，发现异常时标记，没有发现问题时自动批准。

官方案例还提到，一些团队自行构建了"chief of staff"智能体，连接 Slack、Gmail、WhatsApp 等系统来管理沟通、日程、招聘工作流和跟进。DataHub 判断：这种从集中式部署到员工自发构建的扩散模式，是本案例中值得关注的组织现象——它表明 AI 工具的采用已经超越了自上而下的推广阶段。但需要注意，将其定性为"最值得关注的组织现象之一"是编辑价值判断，官方案例本身只是描述了这一现象，未对其重要性做排序。

实施路径：先覆盖高频客户旅程，再重组内部任务接口

从官方案例的叙事中可以辨识出 Cars24 的实施路径遵循了一个清晰的优先级：先解决客户侧限制最多的环节，再向内部工作流扩展。

第一步：从销售漏斗的中段和底部切入

Cars24 没有从最容易自动化的环节（如 FAQ 回复）开始，而是选择了官方原文所称的"限制最多的部分"（most constrained）——销售漏斗的中段和底部，即对话驱动转化的环节。官方案例明确提到这一选择，但未披露团队评估了哪些替代方案，也未说明早期验证的具体指标和时间线。

第二步：围绕 Linear 重组项目管理工作流

在内部侧，Cars24 在数周内围绕 Linear 重新组织了项目管理工作流。这个步骤的意义在于：它不是让 Codex 适应现有的混乱流程，而是先整理任务结构，再让 Codex 在清晰的任务定义中参与。官方材料未披露重组过程中的具体决策者、参与团队和遇到的阻力。

第三步：从工程扩展到财务和运营

Jayesh Gupta 的引言表明，Codex 向工程之外的扩散速度超出了团队预期。财务团队开始用它汇集数据和准备报告，采购流程引入了自动异常检查，一些团队甚至自建了连接多个通讯系统的"chief of staff"智能体。

采用规模是一个信号，但距离业务结果还有多远

Cars24 目前公开的量化数据集中在两个维度：客户侧的对话处理规模，和内部侧的工具采用率。

约 600 人的部署范围和 85%–90% 的日活使用率说明 AI 工具已经进入了总部组织的日常工作——这不是一个只有少数人使用的边缘工具。但这些数字不能回答以下问题：AI 对话是否提高了预约率和转化率？内部工具的使用是否减少了任务完成时间或提高了产出质量？采购自动批准是否降低了异常率或加快了审批周期？这些才是判断 AI 部署是否产生了真正业务价值的指标，而官方材料没有给出。

可迁移的决策逻辑，以及这个案例还不能告诉你的事

这个案例展示的模式

Cars24 案例最值得其他团队借鉴的不是具体的技术选型，而是两个设计决策。第一，在客户侧，他们没有从最容易自动化的环节开始，而是从官方所称"限制最多的部分"——销售漏斗的中段和底部——切入，这意味着 AI 在该公开场景中必须处理复杂的多轮对话，而不是简单的 FAQ 回复。第二，在内部侧，他们先整理了任务结构（围绕 Linear 重组工作流），再让 AI 参与——这意味着 AI 的工作边界由现有系统中的任务定义来约束，而不是让 AI 自行决定做什么。

DataHub 判断：这两个决策共同指向一个可迁移的原则——AI 的有效性不取决于模型能力的上限，而取决于任务定义的清晰度和系统接口的完备度。这一判断的适用前提是：企业已有结构化的业务系统（如车辆目录、预约系统、工单管理工具）可供 AI 接入；如果企业的业务流程本身尚未数字化，这一原则的适用性会大幅降低。

官方案例提到，Cars24 的语音智能体覆盖了从需求理解到售后支持的完整旅程，背后涉及车辆目录、预约系统、融资方案和售后记录等多个系统。但官方材料未说明这些系统如何为智能体提供上下文连续性，也未披露跨系统数据流转的技术实现机制。因此，"智能体能沿旅程接着聊"是官方描述的功能表现，而非经过技术架构验证的因果解释。

读者需要注意的局限

这是一篇模型厂商（OpenAI）发布的官方客户案例，不存在独立第三方验证。案例的叙事重心在"覆盖了什么"和"采用了多少"，而不是"效果如何"。所有量化数据都是采用规模指标（对话分钟数、部署人数、日活率），没有业务结果指标（转化率、满意度、成本变化、质量提升）。

85%–90% 的日活使用率是一个引人注目的数字，但在"日活"的定义未披露的情况下，它可能意味着"每天至少发送一条消息"，也可能意味着"每天完成至少一个完整任务"——两者的含义差异很大。

此外，采购自动批准流程的治理细节完全缺失，这是本案例中最需要谨慎对待的部分。任何考虑在财务审批流程中引入 AI 自动化的团队，都应该在权限层级、审计追踪和异常回滚机制上做出比本案例披露的更详细的设计。