高德开放平台Skill实战：用 AI Agent 角色系统实现旅行路线自动评价

qhvssonic

227人浏览 · 2026-06-23 10:54:57

qhvssonic · 2026-06-23 10:54:57 发布

本文分享我在高德开放平台Skill创意征集赛中的参赛作品「路线先遣队 Route Scouts」的设计思路和技术实现。这个Skill的核心玩法是：派出4个性格完全不同的AI体验官，基于高德真实数据帮你"先走一遍"路线方案，给出性格化评价，解决选择困难症。

一、为什么做这个Skill

旅行规划最痛苦的不是没有方案，而是方案太多不知道选哪个。

飞机还是高铁？
热门景点还是小众路线？
下雨了自驾还去不去？

现有的规划工具给你一堆路线数据——距离、耗时、费用——但冰冷的数字很难帮你做决策。你需要的不是更多数据，而是有人帮你解读这些数据。

所以我的思路是：让AI用不同性格视角来解读同一组高德路线数据，把"数据比较"变成"体验评价"。

二、产品设计：四个角色 + 两种模式

2.1 四位体验官

角色	性格定位	价值
🔥 热血小高	什么都觉得好，疯狂鼓励	适合需要被推一把的犹豫用户
👵 碎碎念德仔	像唠叨的长辈，事无巨细	帮你想到所有你没想到的细节
🤡 毒舌里子	阴阳怪气，但句句有数据支撑	最有信息量，用吐槽传递真实评价
🧊 高冷阿巴	纯数据评分，不带任何情感	给需要客观对比的理性用户

设计四个角色而不是一个的原因：同样的数据，不同视角的解读差异巨大。

下雨天骑行10km：

热血小高：“雨中骑行也太浪漫了吧！！”
碎碎念德仔：“带雨衣了吗？路滑别骑太快”
毒舌里子：“下雨天让我骑行，你真是个天才”
高冷阿巴：“降水概率87%，滑倒风险+40%，评分2/10”

用户可以为每条路线自由分配不同体验官——想看乐子派毒舌，想要客观数据派高冷，想听注意事项派碎碎念。

2.2 两种评价模式

速评模式：每个角色给一段总评，快速出结果。适合赶时间做决策。

实况模式：角色模拟实时行进，按路线节点逐段"发消息"，像朋友在路上给你发实时动态。更有代入感，更有趣。

实况模式示例（毒舌里子走自驾环线）：

🤡 [08:00 出发]："外面飘着小雨。你确定不是在拍公路灾难片？"
🤡 [09:30 都江堰]："到了。门票80，停车20。2000年前李冰治水的时候肯定没想到，有人会在下雨天专程来看水。"
🤡 [17:00 返程]："全程280km，油费180，过路费90。花了一天钱看了一天雨。下次派我出门前，麻烦先看天气预报。"

三、技术架构

3.1 整体设计

用户需求
  ↓
调度层（理解需求 + 方案生成）
  ↓
高德 amap-lbs-skill（路径规划 / POI搜索 / 天气查询）
  ↓
数据整合层（组合方案 + 结构化数据）
  ↓
角色评价层（数据 → 性格化文本）
  ↓
格式化输出（群聊风格）

3.2 核心设计决策

决策1：基于 Skill 调用而非直接API

我没有直接封装高德 REST API，而是依赖高德官方的 amap-lbs-skill。原因：

官方 Skill 已经做好了 API 参数处理和错误兜底
保持解耦——我的 Skill 只关注"评价逻辑"，数据获取交给专业层
方便其他平台复用（任何安装了 amap-lbs-skill 的平台都能跑）

决策2：Skill 文件即全部——纯 Prompt Engineering

整个「路线先遣队」的实现是一个 SKILL.md 文件，不需要后端服务。核心技术是结构化Prompt设计：

角色系统定义（性格、说话风格、典型反应）
工作流程编排（Phase 1方案生成 → Phase 2用户分配 → Phase 3评价输出）
数据→性格映射规则（触发条件表）

为什么这个方案能work？因为当前 LLM 对角色扮演和风格化输出的能力已经足够强，关键不是模型能力而是Prompt的结构化设计。

决策3：数据→性格反应的映射表

这是整个Skill最核心的设计——我定义了一张"触发规则表"，明确什么数据条件触发什么性格反应：

数据条件	🔥热血	👵碎碎念	🤡毒舌	🧊高冷
天气雨天+户外	浪漫	带伞/会感冒	天才决策	滑倒风险%
堵车>2h	听歌时间	带水/别憋尿	免费冥想	拥堵占比%
费用超预算	花钱买体验	能省则省	家里有矿	费用/km
步行>3km无遮荫	晒太阳补钙	防晒/带水	免费桑拿	紫外线指数
景点人流量大	热闹有氛围	看好手机	跟8000万人挤	日均客流量

这张表确保了角色行为的一致性和可控性——不是让LLM随机发挥，而是用规则约束发挥方向。与我之前做设备故障诊断系统的理念一致：关键场景下，预设计的规则 > 模型自由发挥。

3.3 高德数据的深度利用

为了让角色评价不流于表面，我尽可能挖掘高德API返回的细粒度数据：

数据字段	来源	角色利用方式
POI评分（rating）	POI搜索结果	低分景点被毒舌重点关照
营业时间（opentime）	POI详情	到达时间在营业时间外触发提醒/吐槽
红绿灯数（traffic_lights）	驾车规划	过多时触发"停车起步大师训练营"
收费路段（tolls/toll_distance）	驾车规划	费用计算+吐槽素材
换乘次数+步行距离	公交规划	换乘多是碎碎念的发挥空间
天气详情（温度/风力/湿度）	天气查询	高温+步行、大风+骑行触发评价
沿途设施密度	途经点周边搜索	无厕所/便利店区段触发反应

数据越细，角色评价就越有"真实感"——用户会觉得这个AI是真的帮他走了一遍，而不是在编故事。

四、Prompt设计要点

4.1 角色系统的层次化定义

每个角色的定义包含三层：

性格内核（一句话）：决定看问题的角度
说话风格（语言特征）：感叹号多少、句式长短、用词倾向
典型反应库（示例）：给 LLM 足够的"锚点"来保持人设

只定义"毒舌"是不够的，需要用具体例子告诉模型"毒舌成什么样"：

堵车2小时 → "恭喜你解锁了三环冥想体验，2小时不用动，真养生"
下雨骑行 → "下雨天让我骑行，你真是个天才。建议顺便买份保险"

4.2 工作流程的显式编排

Skill文件中明确定义了三个Phase的工作流：

Phase 1：方案生成（调用高德API、组合数据）
Phase 2：展示方案 & 等待用户分配（交互节点）
Phase 3：按分配结果输出评价（性格化文本生成）

显式编排的好处：LLM 不会跳步骤、不会遗漏环节、不会在不该输出评价时就开始角色扮演。

4.3 输出格式的约束

定义了"群聊风格"的输出模板：

━━━━━━━━ 🎭 体验官群聊 ━━━━━━━━
── 🅰️ 方案名称 ──
（派出：🤡毒舌里子 🧊高冷阿巴）
🤡 毒舌里子："..."
🧊 高冷阿巴："..."
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

固定格式确保输出的可读性和一致性，不会每次生成出不同的排版。

五、效果展示

场景：常州出发去成都3天

输入：我在常州，想去成都玩3天，帮我规划

系统生成3个方案：

A「经典热门」—— 飞机 + 宽窄巷子/锦里/熊猫基地
B「小众深度」—— 高铁 + 玉林路/建设巷/人民公园
C「自驾环线」—— 成都→都江堰→青城山（有雨）

用户分配：C派毒舌里子，实况模式

毒舌里子的实况评价：

[08:00 出发] “早上8点出发自驾，外面飘着小雨。你确定不是在拍公路灾难片？”

[09:30 到达都江堰] “到了。门票80，停车费20。雨越下越大。2000年前李冰治水的时候肯定没想到，有人会在下雨天专程来看水。”

[12:00 青城山脚] “山路湿滑，台阶上全是水。你这是登山还是滑水？建议买双防滑鞋，或者买份意外险。”

[17:00 返程] “全程280km，油费180，过路费90，门票160，雨衣20。花了一天钱看了一天雨。下次派我出门前，麻烦先看天气预报，谢谢。”

每一句吐槽都基于高德返回的真实数据（距离、费用、天气），只是用毒舌的方式表达出来。