滴滴正式推出 OpenClaw 专属打车Skill：didi-ride-skill（https://github.com/didi/didi-ride-skill），使用 OpenClaw 即可直接调用滴滴完整出行服务链路。
当你对 AI 说出「帮你叫个车去机场」时，系统会自动完成一整套流程：地址解析、价格预估、用户确认、订单创建，并在数分钟后主动告诉你司机在哪。
整个过程无需打开滴滴App，也无需重复输入手机号或车型偏好，你的历史设置可以被自动继承。
为什么要做一个打车Skill
滴滴 MCP 服务已对外提供 13 个工具能力，覆盖地址解析、价格预估、订单创建、状态查询等完整链路。从“能力供给”的角度看，基础设施已经具备。但从“用户可用性”来看，仍存在部分断层：普通用户无法通过手动拼接 JSON-RPC 请求完成一次打车。
打车流程本身具备典型的线性结构（地址解析 → 比价 → 下单 → 状态跟踪），天然适合由 AI 进行编排与执行。所以真正的挑战并不在流程设计，而在于：如何让 AI 在复杂上下文和不确定环境中，稳定地完成整个流程。
因此，我们设计 didi-ride-skill 只有一个目标，在 OpenClaw 中，用户只需说一句「帮我叫车去机场」，后续流程即可全自动化完成！
didi-ride-skill 能做什么
场景一：从0完成首次打车下单
完成 didi-ride-skill 安装与 Key 配置后，在对话框中输入一句话，即可实现一次完整的出行流程。在这一基础场景下，系统需要在地址解析、价格预估、用户确认、下单执行以及订单状态自动回查等关键环节上保持稳定性。
场景二：预约出行与任务托管
借助 OpenClaw 的 cron 机制，AI 可以创建定时任务，在指定时间自动触发打车流程。该任务运行于全新的独立 session 自动触发完成打车流程。用户无需持续关注执行过程，到达指定时间后即可收到结果通知。
场景三：具备推理能力的行程理解
在复杂场景中，AI 不再只是执行工具调用，而是开始具备一定的推理能力，例如：能够根据“22:20 落地”推算实际用车时间、主动补全你缺失的起点信息，并对整体行程进行合理规划。这类时间推理与意图理解能力，正是我们希望 didi-ride-skill 所具备的能力。
Skill 如何驱动打车
Skill 的本质
在 OpenClaw 中，Skill 本质上是一套“操作规范”，会在每次对话时注入到模型上下文中。当你说出“帮我叫车”时，OpenClaw 会识别触发条件，并加载 didi-ride-skill 的相关内容，使 AI 能够懂得并调度滴滴的出行能力。
底层能力：DiDi MCP
didi-ride-skill 基于滴滴开放的 MCP（Model Context Protocol）服务构建。
MCP 是一种标准化的工具调用协议，使 AI 能够以统一方式调用外部服务。当前滴滴 MCP 提供共计 13 个工具。
类别 | 工具数 | 能力范围 |
打车服务 | 6 | 价格预估、创建订单、订单查询、司机位置等 |
地图服务 | 7 | 地点/附近搜索、驾车/公交/步行/骑行规划等 |
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 来说，这意味着：文件地图中的“中间文件”天然处于注意力洼地。最终我们调整为如下方案：
主文件保留全流程的简要描述以及关键节点的详细说明，仅将真正复杂且相对独立的内容拆分到子文件中。这样既避免了主文件臃肿，又减少了多文件读取带来的时延和注意力分散问题。
Restatement：刻意重复的工程价值
细心的朋友在阅读 SKILL.md 时，会注意到一个奇怪的现象：某些内容出现了不止一次。例如 MCP KEY 的配置要求在主文件中重复出现，mcporter 命令的参数格式也在多个文件中多次被强调。
Restatement：刻意的重复声明，在关键节点执行前，主动将约束信息再次呈现。其背后的逻辑与上节一致：LLM 在长上下文中的注意力是不稳定的。
Skill 并不具备 System Prompt 那样的高优先级，它本质上只是注入到上下文中的一段内容。
因此，如果希望 AI 在某个特定步骤中稳定遵循某个约束，最可靠的方式是：在该步骤执行前，将约束信息再次显式说明。
多文件交叉验证 + 关键节点前 Restatement，是我们在 Skill 层面对抗 LLM 注意力不稳定性的主要手段。
模型能力 VS 确定性脚本
初版我们设计了两个脚本文件：
setup.sh（142 行）——用于环境初始化 create_order.json（439 行）——用于创建订单和开启回查任务
原因主要有几个：OpenClaw 的运行环境差异较大，边界情况远超预期，单靠 439 行脚本仍然无法完全覆盖；脚本输出还需要再交由 AI 进行解析，反而引入了额外的信息噪音；更关键的是，AI 有时会自行“打补丁”修改脚本逻辑，而这些隐性修改一旦遇到环境变化，就会变成难以排查的隐患。
在去掉脚本、改为完整 prompt 引导 + 参数示例之后，执行效果反而更加稳定。AI 能够掌握完整上下文，在出错时也能更准确地定位问题。
但“信任模型”并不意味着“完全放手”。一个典型的例子是：
因此，在流程设计上，适合信任模型整体能力；但在具体存在已知惯性错误的节点，需要通过 Restatement 约束进行纠偏。脚本与信任模型并不是二选一的问题，关键在于哪些环节需要严格控制，哪些环节可以适度放开。
平台边界与工程挑战
当前 OpenClaw 仍处在高速迭代阶段，下面是我们在平台层面遇到的几个典型问题。
cron isolated 模式的启动成本
MCP Key 放在哪里
被 isolated session 逼出来的选择
这个问题初看只是一个配置细节，但实际上影响了整个 Skill 的架构设计。我们最初将 MCP KEY 存放在 Skill 目录下。直到测试预约打车时发现：cron 任务到点触发后出现静默失败——既没有成功叫车，也没有任何报错信息。
openclaw config set 'skills.entries.didi-ride-skill.apiKey' 'YOUR_KEY'
平台迭代带来的权限问题
2026 年 3 月底，OpenClaw 发布了一次版本更新：在所有终端命令执行前新增 pre_hook 权限判断，默认需要用户手动 approve。
从安全角度来看，这是一个完全合理的设计，但对 didi-ride-skill 而言影响却非常直接且严重：Skill 几乎每一步都依赖终端命令，导致整个打车流程在这次更新后被明显阻塞。我们没有任何可以优雅绕过这一机制的方案——既不能要求用户关闭安全保护，也无法在 Skill 层面申请权限豁免。
本质上，这意味着：在一个快速迭代的平台上做 Skill 开发，需要接受一个现实——平台的任何一次更新，都可能让已有能力失效。持续适配不是偶发成本，而是必然成本。
测试方案设计
手工测试已经逐渐跟不上 OpenClaw 平台的迭代速度。更关键的是，因为输入与输出的来源本身就是不稳定的，打车 Skill 本身无法套用“输入 X → 断言输出 Y”的传统测试方式，主要包含以下几方面：
AI 模型本身：不同模型之间，甚至同一模型的不同次调用，输出都可能存在波动
OpenClaw 平台：处于高速迭代阶段，平台行为会随版本持续变化
外部服务：滴滴 MCP API 的真实响应会受到网络状况、服务可用性等多种因素影响
整体方案
测试用例集（Input）
共 24 条测试用例，按场景划分为 6 类：即时打车、预约出行、偏好记忆、Onboarding、地址挑战、复杂推理。每条用例包含：输入 query、期望触发的工具调用序列、关键断言点，以及需要检测的风险标记规则。这部分由人工设计并维护。
执行引擎（Run）
通过可编程方式驱动 OpenClaw Agent 完成一轮对话，并收集 AI 回复文本及完整工具调用记录。该模块仍有优化空间，后文会展开说明。
评估层（Assert & Judge）
分为两类：
可自动化部分：工具调用断言（是否调用正确工具、参数格式是否符合预期）、风险标记检测（是否跳过确认直接下单、是否存在参数幻觉等）
需人工介入部分：回复质量由 LLM-as-Judge 辅助评估，但最终仍需人工确认；同时，cron 定时推送、图片消息等 CLI 无法捕获的场景，也依赖人工验证
报告输出（Output）
系统自动生成测试报告，包括通过率、失败率、风险标记汇总以及工具调用详情，为每一轮迭代提供可量化参考。
该模块当前处于半自动化状态。具备明确规则的部分由测试 agent 自动完成；存在模糊判断空间的 case 以及特殊场景（如 cron 推送、图片消息）仍依赖人工介入。我们当前的目标，是持续收窄“必须人工”的边界。
执行引擎：如何稳定获取测试数据
在解决“如何评估”之前，首先要解决“如何获取数据”——即如何以可编程方式驱动 OpenClaw 完成对话，并稳定获取 AI 回复内容与工具调用记录。
方案一：IM 工具收发消息（初期尝试）
通过 IM 工具发送测试消息并等待 Agent 回复，看起来是最直接的路径。但实际存在两个关键问题：首先，Bot 与 Bot 之间的消息传递受事件机制限制，无法稳定触发 Skill 响应；切换为真实用户后，又遇到富媒体能力问题——打车回复中的价格卡片，通过 API 获取时只能拿到 fallback 文本，核心数据不可见。
根本的问题在于：IM 通道的异步特性本身就引入了额外复杂度，包括轮询等待、消息乱序处理、以及“如何判断回复结束”等工程问题，而这些都与测试框架本身目标无关，但会显著增加维护成本。
方案二：OpenClaw Agent CLI（当前方案）
最终我们绕开消息通道，直接通过openclaw agentCLI 驱动对话。该方式可以同步返回完整纯文本，不受任何消息渠道格式限制；同时，AI 的工具调用记录可从 OpenClaw 的 JSONL transcript 中直接解析，能够精确还原每一次 mcporter 调用的工具名与参数。
当前方案的主要局限在于：无法验证图片消息是否成功发送，以及 cron 定时任务的推送难以自动化验证（isolated session 触发的推送在 CLI 层无法直接捕获）。
写在最后
回头看，这个项目花在 prompt 措辞和文档结构上的时间，甚至超过了“功能代码”本身。传统开发中，写完逻辑就结束了；而在 Skill 开发里，你需要反复验证 AI 是否真的按你写的去执行——而且换一个模型，结果可能又完全不同。
这大概是 AI Skill 工程与传统软件工程最本质的区别：你的“代码”是自然语言，而你的“运行时”是一个概率系统。
目前 didi-ride-skill 仍有不少待完善的地方：
cron isolated session 的启动成本依然存在
OpenClaw 的每一次更新都可能带来新的适配工作
接下来我们计划做：
行程分享与实时位置推送：目前用户在下单后只能等待 5 分钟回查，体验链路存在断层
适配 OpenClaw 以外的 Agent 平台
将测试能力从“半自动”推进到“全自动”，至少覆盖 cron 推送验证
