一文读懂滴滴OpenClaw专属打车Skill

滴滴正式推出 OpenClaw 专属打车Skill：didi-ride-skill（https://github.com/didi/didi-ride-skill），使用 OpenClaw 即可直接调用滴滴完整出行服务链路。

当你对 AI 说出「帮你叫个车去机场」时，系统会自动完成一整套流程：地址解析、价格预估、用户确认、订单创建，并在数分钟后主动告诉你司机在哪。

整个过程无需打开滴滴App，也无需重复输入手机号或车型偏好，你的历史设置可以被自动继承。

滴滴 MCP 服务已对外提供 13 个工具能力，覆盖地址解析、价格预估、订单创建、状态查询等完整链路。从“能力供给”的角度看，基础设施已经具备。但从“用户可用性”来看，仍存在部分断层：普通用户无法通过手动拼接 JSON-RPC 请求完成一次打车。

打车流程本身具备典型的线性结构（地址解析 → 比价 → 下单 → 状态跟踪），天然适合由 AI 进行编排与执行。所以真正的挑战并不在流程设计，而在于：如何让 AI 在复杂上下文和不确定环境中，稳定地完成整个流程。

因此，我们设计 didi-ride-skill 只有一个目标，在 OpenClaw 中，用户只需说一句「帮我叫车去机场」，后续流程即可全自动化完成！

完成 didi-ride-skill 安装与 Key 配置后，在对话框中输入一句话，即可实现一次完整的出行流程。在这一基础场景下，系统需要在地址解析、价格预估、用户确认、下单执行以及订单状态自动回查等关键环节上保持稳定性。

借助 OpenClaw 的 cron 机制，AI 可以创建定时任务，在指定时间自动触发打车流程。该任务运行于全新的独立 session 自动触发完成打车流程。用户无需持续关注执行过程，到达指定时间后即可收到结果通知。

在复杂场景中，AI 不再只是执行工具调用，而是开始具备一定的推理能力，例如：能够根据“22:20 落地”推算实际用车时间、主动补全你缺失的起点信息，并对整体行程进行合理规划。这类时间推理与意图理解能力，正是我们希望 didi-ride-skill 所具备的能力。

在 OpenClaw 中，Skill 本质上是一套“操作规范”，会在每次对话时注入到模型上下文中。当你说出“帮我叫车”时，OpenClaw 会识别触发条件，并加载 didi-ride-skill 的相关内容，使 AI 能够懂得并调度滴滴的出行能力。

didi-ride-skill 基于滴滴开放的 MCP（Model Context Protocol）服务构建。

MCP 是一种标准化的工具调用协议，使 AI 能够以统一方式调用外部服务。当前滴滴 MCP 提供共计 13 个工具。

Skill 的核心职责在于：以正确的顺序、参数和时机，编排调用这些工具。

下面整理几个我们在开发过程中反复遇到并不断打磨的问题。

初版我们将所有内容直接塞进 SKILL.md 主文件，很快就超过了 500 行。于是我们对结构进行了拆分：主文件仅保留简要描述，将详细内容全部拆分到文件地图中。从结构上看，这种方式更加清晰，但在实际测试中暴露出两个现实

每当 AI 执行到某个节点需要读取子文件时，都会产生一次额外的文件读取。对于打车这种时间敏感场景而言，这种“走走停停”的延迟在体验上非常明显。

AI 实际上会更关注 SKILL.md 主文件以及最近刚读取的文件，而文件地图中的“中间文件”，在多步骤执行过程中很容易被忽略。

这一现象与 LLM 的注意力机制密切相关。研究者 Liu et al. 在 2023 年的论文 "Lost in the Middle" 中指出：

"Performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access and use information located in the middle."

对于 Skill 来说，这意味着：文件地图中的“中间文件”天然处于注意力洼地。最终我们调整为如下方案：

主文件保留全流程的简要描述以及关键节点的详细说明，仅将真正复杂且相对独立的内容拆分到子文件中。这样既避免了主文件臃肿，又减少了多文件读取带来的时延和注意力分散问题。

细心的朋友在阅读 SKILL.md 时，会注意到一个奇怪的现象：某些内容出现了不止一次。例如 MCP KEY 的配置要求在主文件中重复出现，mcporter 命令的参数格式也在多个文件中多次被强调。

Restatement：刻意的重复声明，在关键节点执行前，主动将约束信息再次呈现。其背后的逻辑与上节一致：LLM 在长上下文中的注意力是不稳定的。

Skill 并不具备 System Prompt 那样的高优先级，它本质上只是注入到上下文中的一段内容。

因此，如果希望 AI 在某个特定步骤中稳定遵循某个约束，最可靠的方式是：在该步骤执行前，将约束信息再次显式说明。

多文件交叉验证 + 关键节点前 Restatement，是我们在 Skill 层面对抗 LLM 注意力不稳定性的主要手段。

初版我们设计了两个脚本文件：

• setup.sh（142 行）——用于环境初始化
• create_order.json（439 行）——用于创建订单和开启回查任务

原因主要有几个：OpenClaw 的运行环境差异较大，边界情况远超预期，单靠 439 行脚本仍然无法完全覆盖；脚本输出还需要再交由 AI 进行解析，反而引入了额外的信息噪音；更关键的是，AI 有时会自行“打补丁”修改脚本逻辑，而这些隐性修改一旦遇到环境变化，就会变成难以排查的隐患。

在去掉脚本、改为完整 prompt 引导 + 参数示例之后，执行效果反而更加稳定。AI 能够掌握完整上下文，在出错时也能更准确地定位问题。

但“信任模型”并不意味着“完全放手”。一个典型的例子是：

因此，在流程设计上，适合信任模型整体能力；但在具体存在已知惯性错误的节点，需要通过 Restatement 约束进行纠偏。脚本与信任模型并不是二选一的问题，关键在于哪些环节需要严格控制，哪些环节可以适度放开。

当前 OpenClaw 仍处在高速迭代阶段，下面是我们在平台层面遇到的几个典型问题。

这个问题初看只是一个配置细节，但实际上影响了整个 Skill 的架构设计。我们最初将 MCP KEY 存放在 Skill 目录下。直到测试预约打车时发现：cron 任务到点触发后出现静默失败——既没有成功叫车，也没有任何报错信息。