【补能雷达 Skill｜07】AI 补能智能体：一句话解析起点、终点、续航和偏好

应用名称：补能雷达 Skill
合集名称：补能雷达 Skill：AI + 高德地图补能规划实战
本文序号：第 7/20 篇
统一标签：高德开放平台、高德Skill、HarmonyOS、新能源汽车、AI智能体

这一篇是“补能雷达 Skill”系列的第 07 篇。整个系列围绕一个参赛项目展开：用户输入出发地、目的地、当前剩余续航、安全余量和补能偏好后，系统自动判断是否需要补电，推荐顺路充电站，解释为什么推荐，并生成高德导航入口。本文聚焦 自然语言解析和智能体入口，希望把项目里的设计选择、实现方式和参赛表达都讲清楚。

如果只把它看成一个普通网页，项目好像只是“表单 + 地图 + 卡片”；但从用户任务看，它解决的是一个更具体的问题：表单虽然稳定，但比赛演示时一句话输入更有吸引力，也更符合 Skill 的表达方式。 这也是我把作品命名为“补能雷达 Skill”的原因，重点不是查找，而是判断、推荐、解释和执行。

一、这一章要解决什么问题

表单虽然稳定，但比赛演示时一句话输入更有吸引力，也更符合 Skill 的表达方式。

面向的读者主要是希望给前端项目加 AI 交互入口的开发者。我不会只罗列页面组件，而是尽量从真实使用场景出发：用户在出发前并不愿意研究很多参数，他只想知道这条路线能不能安全到达、如果要补电应该在哪里停、这个站是否会排队、绕路成本是否可以接受、到站后有没有休息配套。比赛作品如果能围绕这个问题组织，就比单纯展示接口调用更容易被理解。

本章的关键价值可以概括为：项目内置轻量智能体，不依赖额外大模型 Key，也能从自然语言中解析路线、续航、偏好和场景标签。 这也是后续每一篇文章会反复强调的主线：高德地图能力不是页面装饰，而是补能决策链路的一部分。

二、项目中的高德能力位置

本章相关的高德能力包括：

• 地理编码 API：在本篇对应到「自然语言解析和智能体入口」这个环节，不是孤立调用，而是服务于补能决策。
• 驾车路径规划 API：在本篇对应到「自然语言解析和智能体入口」这个环节，不是孤立调用，而是服务于补能决策。

这些接口如果单独演示，用户感知会比较弱。例如地理编码只是把地址变成坐标，静态地图只是展示图片，URI 导航只是打开地图 App。真正能打动评委的是把它们串起来：用户一句话或者一组表单字段进入系统，系统经过地图能力计算后给出可以执行的补能方案。

三、实现流程图

下面这张图是本章涉及的主流程。它不是为了显得复杂，而是为了帮助读者理解：每个环节都应该回答一个用户问题。

步骤	关键环节	用户价值
1	用户一句话	让用户从“看见信息”走到“完成决策”
2	字段解析	让用户从“看见信息”走到“完成决策”
3	表单回填	让用户从“看见信息”走到“完成决策”
4	调用规划	让用户从“看见信息”走到“完成决策”
5	生成回答	让用户从“看见信息”走到“完成决策”

这条链路的设计原则是“先判断，再推荐，最后执行”。如果直接展示站点列表，用户还要自己判断是否需要充电；如果只给一个推荐站，用户会追问为什么；如果没有导航入口，推荐又无法落地。所以项目把判断、推荐、解释和导航放在同一条体验链路上。

四、页面和交互如何体现

在前端页面上，我把本章相关能力放到用户最容易理解的位置。左侧是出行输入和 AI 补能助手，右侧是规划结果、地图、方案对比和风险解释。这个布局的好处是：用户从左到右阅读时，顺序刚好对应“输入需求 -> 生成方案 -> 查看地图 -> 理解原因 -> 执行导航”。

为了避免页面看起来像堆组件，我给每个区域都设置了明确角色。输入区负责收集起点、终点、续航和偏好；结论区负责告诉用户是否需要补电；地图区负责展示路线和推荐站的空间关系；决策解释区负责说明推荐原因；方案对比区负责让用户看到不同策略；风险雷达负责提醒低电量、排队、绕行和夜间安全问题。

五、核心实现片段

本章相关的核心逻辑可以抽象成下面这段伪代码。实际项目中代码被拆分在前端交互和本地 Node 服务中，但业务含义是一致的。

query.match(/(?:从|起点是|出发地是)(.+?)(?:到|去|前往|开到|目的地是)/)
query.match(/(?:剩余|当前|还有)(\d+)\s*(?:公里|km)/i)

代码不是文章的唯一重点。对比赛作品来说，更重要的是解释这段逻辑为什么存在：它让用户少做判断，把多个高德能力转换成一次具体的出行建议。写 CSDN 文章时，也不要只贴代码，要把输入、输出和用户场景讲清楚。

六、参赛表达怎么讲

如果要在高德 Skill 创意征集中介绍这一部分，我会避免说“我调用了某某 API”这种过于平铺的表述，而是讲“我用这些能力解决了新能源车主长途补能焦虑”。评委更容易记住一个用户问题，也更容易判断作品是否有实际价值。

可以这样组织语言：第一句讲场景，第二句讲高德能力，第三句讲创新点，第四句讲可执行结果。比如：新能源车主跨城出行时，最怕剩余续航和充电站选择不确定；补能雷达 Skill 结合高德路线规划、周边搜索、静态地图和导航 URI，自动推荐顺路充电站，并给出绕行、功率、排队和安全解释；用户最后可以一键打开高德导航，把建议转成真实路线。

七、这一章的落地检查清单

• 1. 为什么先做轻量智能体。
• 2. 自然语言字段提取规则。
• 3. 多轮追问如何处理。
• 4. 和真实大模型结合的升级方向。

如果这几个点都能在页面、文档和演示视频里被看见，本章对应的能力就不会停留在概念层面。比赛作品最怕“功能有，但评委没看出来”，所以每一个亮点都应该有页面证据、代码证据和文字证据。

八、深度复盘：把「AI 补能智能体解析」写成可复查的工程证据

这一篇最需要补强的不是字数，而是证据密度。补能雷达 Skill 是面向新能源出行的决策工具，文章必须让读者看到：用户输入从哪里来，高德能力在链路中承担什么角色，页面为什么这样展示，失败时系统怎么兜底。只写“实现了某个功能”不够，必须把功能落到一次可复现的出行任务里。

本篇对应的核心能力是 AI 补能智能体解析，关联的工程点包括：自然语言字段抽取、追问、表单回填。它在项目里的位置不是孤立模块，而是“输入行程 - 判断补能 - 推荐站点 - 解释原因 - 打开导航”这条链路中的关键节点。评审或读者只要沿着这条链路检查，就能判断项目是不是可运行、可解释、可继续扩展。

1. 输入、处理、输出要写成闭环

环节	本篇应该说明的证据	验收方式
输入	起点、终点、剩余续航、安全余量、补能偏好	页面表单或语音助手能回填到同一套参数
处理	自然语言字段抽取、追问、表单回填	可以在代码片段、接口返回或流程图里找到对应关系
输出	推荐补能站、推荐理由、风险提示、导航入口	用户不用读原始坐标，也能知道下一步怎么走
兜底	Key 缺失、接口失败、语音不可用或地图加载失败时仍可演示	页面给出明确提示，并切换到示例数据或手动输入

2. 关键代码要解释工程意图

下面这段不是完整源码，而是本篇最应该保留的核心逻辑摘要。文章里放代码的目的不是炫技，而是让读者确认：这个能力确实有清晰的输入、计算规则和输出边界。

const range = text.match(/(?:剩余|还有)(\d+)\s*(?:km|公里)/i)?.[1]
const prefer = /少排队|快充|有洗手间|夜间/.exec(text)?.[0]

这类代码说明应当紧跟三句话：第一，它接收的是用户可理解的行程参数；第二，它把高德能力或本地规则转成补能决策；第三，它的输出会直接影响页面上的推荐结果、风险解释或导航按钮。这样读者不会把项目误解成普通地图展示页。

3. 接口返回样例要能支撑页面判断

文章里还应该保留一段接近真实业务的返回结构。它不用暴露完整接口，也不需要贴很长的 JSON，但必须能说明页面为什么能展示推荐理由、风险标签和下一步动作。尤其是补能类产品，如果只有“推荐某站”四个字，用户无法判断建议是否可信；如果结果里包含里程、绕行、排队、配套、风险和导航 URI，读者就能看出这是一个可执行方案。

{
  "stationName": "特来电汽车充电站",
  "reason": "绕行少、快充功率高、夜间配套更稳定",
  "routeKm": 205,
  "detourKm": 1.2,
  "riskTags": ["剩余续航不足", "排队中等"],
  "nextAction": "open_amap_navigation"
}

这段样例和 AI 补能智能体解析 的关系是：它把前面的算法、地图能力或交互判断落到了页面可以消费的数据格式。写文章时建议说明每个字段的来源：路线距离来自规划结果，绕行距离来自候选站点比较，风险标签来自本地规则，导航动作来自高德 URI。这样代码、页面和高德能力之间的关系会更清楚。

4. 常见问题要提前写出处理方式

问题	可能原因	处理方式
推荐站点看起来不合理	只按距离排序，没有纳入功率、排队和绕行	在评分模型中拆分多个权重，并在卡片上展示理由
地图路线不清楚	路线颜色太细，站点标记遮挡，或仍使用直线示意	使用高德真实路线点绘制，并加粗主路线、弱化辅助信息
AI 对话识别失败	浏览器语音权限、识别语言或输入句式不稳定	保留手动输入兜底，并把识别结果回填到表单供用户确认
演示环境没有 Key	高德 Web Service Key 未配置或网络不可用	切换示例模式，明确提示当前数据来源，避免页面空白

这些问题不是额外凑内容，而是项目真正会遇到的边界。高分文章通常不是只展示成功路径，还会说明自己怎样处理失败路径。尤其是参赛作品，评委更关心 Demo 是否可稳定演示、是否能解释设计选择、是否能在真实场景继续扩展。

5. 建议增加的验证记录

• 用“杭州西湖文化广场到上海迪士尼，剩余 180 公里，低风险，附近可用餐”跑一次完整流程。
• 截图保留输入区、地图区、推荐站点、方案对比和风险解释，避免只放单张大图。
• 记录接口不可用时的示例模式提示，证明项目不是只在理想网络下可用。
• 检查移动端窄屏时表单、地图、方案卡片是否仍可阅读和操作。

6. 本篇对参赛表达的价值

如果把本篇内容用于比赛材料，可以浓缩成一句话：补能雷达 Skill 不是简单查充电站，而是把高德路线、站点、地图和导航能力组织成一次可解释的补能决策。这个表达比“我调用了高德 API”更具体，也更能体现 Skill 创新点。

结语

这一篇围绕「自然语言解析和智能体入口」把补能雷达 Skill 的一个关键侧面拆开讲了。我的目标不是把页面做得热闹，而是让用户从输入行程开始，一步步得到可解释、可执行、可导航的补能方案。下一篇可以继续从另一个技术点展开，把这个参赛项目讲成完整的高德 Skill 创新案例。

合集导航

• 合集：补能雷达 Skill：AI + 高德地图补能规划实战
• 上一篇：第 06 篇
• 下一篇：第 08 篇
• 建议阅读顺序：从第 01 篇项目总览开始，再依次看高德 API、UI 设计、AI 智能体、语音对话、工程化和项目复盘。