​编辑【补能雷达 Skill11】一键高德导航闭环从推荐站点到用户真正出发应用名称补能雷达 Skill合集名称补能雷达 SkillAI 高德地图补能规划实战本文序号第 11/20 篇统一标签高德开放平台、高德Skill、HarmonyOS、新能源汽车、AI智能体这一篇是“补能雷达 Skill”系列的第 11 篇。整个系列围绕一个参赛项目展开用户输入出发地、目的地、当前剩余续航、安全余量和补能偏好后系统自动判断是否需要补电推荐顺路充电站解释为什么推荐并生成高德导航入口。本文聚焦URI 导航和执行闭环希望把项目里的设计选择、实现方式和参赛表达都讲清楚。如果只把它看成一个普通网页项目好像只是“表单 地图 卡片”但从用户任务看它解决的是一个更具体的问题很多作品停在展示结果用户还要手动复制地址到地图 App实际体验割裂。 这也是我把作品命名为“补能雷达 Skill”的原因重点不是查找而是判断、推荐、解释和执行。​编辑一、这一章要解决什么问题很多作品停在展示结果用户还要手动复制地址到地图 App实际体验割裂。面向的读者主要是希望地图 Demo 可落地使用的开发者。我不会只罗列页面组件而是尽量从真实使用场景出发用户在出发前并不愿意研究很多参数他只想知道这条路线能不能安全到达、如果要补电应该在哪里停、这个站是否会排队、绕路成本是否可以接受、到站后有没有休息配套。比赛作品如果能围绕这个问题组织就比单纯展示接口调用更容易被理解。本章的关键价值可以概括为项目生成高德 URI 导航链接把起点、推荐补能站和目的地串成可执行路线。 这也是后续每一篇文章会反复强调的主线高德地图能力不是页面装饰而是补能决策链路的一部分。二、项目中的高德能力位置本章相关的高德能力包括URI 导航在本篇对应到「URI 导航和执行闭环」这个环节不是孤立调用而是服务于补能决策。这些接口如果单独演示用户感知会比较弱。例如地理编码只是把地址变成坐标静态地图只是展示图片URI 导航只是打开地图 App。真正能打动评委的是把它们串起来用户一句话或者一组表单字段进入系统系统经过地图能力计算后给出可以执行的补能方案。三、实现流程图下面这张图是本章涉及的主流程。它不是为了显得复杂而是为了帮助读者理解每个环节都应该回答一个用户问题。​编辑步骤关键环节用户价值1推荐结果让用户从“看见信息”走到“完成决策”2构造 URI让用户从“看见信息”走到“完成决策”3点击导航让用户从“看见信息”走到“完成决策”4高德地图打开让用户从“看见信息”走到“完成决策”5用户出发让用户从“看见信息”走到“完成决策”这条链路的设计原则是“先判断再推荐最后执行”。如果直接展示站点列表用户还要自己判断是否需要充电如果只给一个推荐站用户会追问为什么如果没有导航入口推荐又无法落地。所以项目把判断、推荐、解释和导航放在同一条体验链路上。四、页面和交互如何体现在前端页面上我把本章相关能力放到用户最容易理解的位置。左侧是出行输入和 AI 补能助手右侧是规划结果、地图、方案对比和风险解释。这个布局的好处是用户从左到右阅读时顺序刚好对应“输入需求 - 生成方案 - 查看地图 - 理解原因 - 执行导航”。为了避免页面看起来像堆组件我给每个区域都设置了明确角色。输入区负责收集起点、终点、续航和偏好结论区负责告诉用户是否需要补电地图区负责展示路线和推荐站的空间关系决策解释区负责说明推荐原因方案对比区负责让用户看到不同策略风险雷达负责提醒低电量、排队、绕行和夜间安全问题。五、核心实现片段本章相关的核心逻辑可以抽象成下面这段伪代码。实际项目中代码被拆分在前端交互和本地 Node 服务中但业务含义是一致的。https://uri.amap.com/navigation?fromlng,lat,namevialng,lat,nametolng,lat,namemodecar代码不是文章的唯一重点。对比赛作品来说更重要的是解释这段逻辑为什么存在它让用户少做判断把多个高德能力转换成一次具体的出行建议。写 CSDN 文章时也不要只贴代码要把输入、输出和用户场景讲清楚。六、参赛表达怎么讲如果要在高德 Skill 创意征集中介绍这一部分我会避免说“我调用了某某 API”这种过于平铺的表述而是讲“我用这些能力解决了新能源车主长途补能焦虑”。评委更容易记住一个用户问题也更容易判断作品是否有实际价值。可以这样组织语言第一句讲场景第二句讲高德能力第三句讲创新点第四句讲可执行结果。比如新能源车主跨城出行时最怕剩余续航和充电站选择不确定补能雷达 Skill 结合高德路线规划、周边搜索、静态地图和导航 URI自动推荐顺路充电站并给出绕行、功率、排队和安全解释用户最后可以一键打开高德导航把建议转成真实路线。七、这一章的落地检查清单1. 为什么导航入口很关键。2. from/via/to 的数据组织。3. 移动端与桌面端打开方式。4. 导航失败时的提示。如果这几个点都能在页面、文档和演示视频里被看见本章对应的能力就不会停留在概念层面。比赛作品最怕“功能有但评委没看出来”所以每一个亮点都应该有页面证据、代码证据和文字证据。八、高质量补充评审最关心的三个问题这一篇对应的是URI 导航和执行闭环它在作品里的作用不是单点功能展示而是把用户从“我不知道该不该充电”推进到“我知道为什么这样走、在哪里停、怎么继续导航”。因此评审阅读这一章时最需要看到的是问题、能力、结果三件事是否连成闭环。1. 它解决的不是接口问题而是出行决策问题如果只写“调用了高德 API”文章会显得像接口笔记如果把它放回新能源汽车出行场景价值就会清楚很多用户输入起点、终点和剩余续航后系统需要把路线距离、安全余量、充电站绕行、排队风险、夜间安全和配套服务放在同一张决策表里比较。一键高德导航闭环从推荐站点到用户真正出发这一章的重点就是说明这条链路中某个环节如何降低用户判断成本。2. 高德能力要进入业务模型而不是停在页面展示补能雷达 Skill 使用高德开放平台能力时核心不是把地图放进页面而是让地理编码、驾车路径规划、周边搜索、静态地图和 URI 导航分别进入业务模型地理编码负责把地址变成可计算位置路径规划负责给出真实路程周边搜索负责找到沿途站点静态地图负责解释路线关系URI 导航负责完成最后一步执行。这样写读者能看懂为什么项目叫 Skill而不是普通查询页。3. 演示时要把“可用性证据”放在前面比赛展示建议按 30 秒节奏讲清楚先输入杭州到上海这类跨城路线再展示系统判断需要补能接着点开推荐理由和地图路线最后生成高德导航入口。文章里的截图、流程图、代码片段和验收清单都围绕这个顺序组织评委不用猜功能关系也能快速判断作品是否真实可运行。评审检查点本章对应证据是否建议保留场景是否清楚起点、终点、续航、安全余量、补能偏好是能力是否来自高德开放平台地理编码、路径规划、周边搜索、静态地图、URI 导航是结果是否可执行推荐站点、理由解释、路线图、导航入口是风险是否有兜底示例模式、接口失败提示、候选方案切换是这部分补充的目的是让文章从“记录我做了什么”升级为“证明这个作品为什么值得被选中”。如果后续继续优化可以把真实 API 返回样例、异常状态截图、移动端截图和演示视频链接补进同一套结构里。4. 这章可以怎样落到代码和页面在补能雷达 Skill 里我会把每个能力拆成“输入、处理、输出、兜底”四层来看。输入层只收集用户能理解的信息例如出发地、目的地、剩余续航、安全余量和补能偏好处理层再把这些字段交给高德能力和本地规则模型输出层只展示对用户有意义的结论例如是否建议补电、推荐哪一个站、预计绕行多久、为什么不是另一个站兜底层负责在 Key 未配置、接口失败或浏览器语音不可用时继续保持可演示。这个拆法的好处是文章不会只停留在截图层面。读者能够顺着页面看到真实的数据流地址被解析成坐标路线被换算成总里程候选站被计算出综合得分最终再生成地图路线和导航入口。对比赛项目来说这比单纯堆功能更有说服力因为它能证明作品已经把高德开放平台能力转成了具体用户任务。用户输入行程 - 高德地理编码确认位置 - 驾车路径规划计算真实距离 - 周边搜索找到沿途补能站 - 本地评分模型给出推荐理由 - 静态地图和 URI 导航完成演示闭环5. 高质量文章还需要讲清边界补能规划类作品很容易被误解成“万能导航”或“万能 AI”。实际写文章时要主动讲清边界项目不替代车机 BMS不保证实时空闲枪位百分百准确不承诺所有浏览器都支持语音识别也不会把高德 Key 暴露到前端。把这些边界写清楚反而会让作品显得更成熟因为评委会看到你考虑了真实上线后的稳定性、安全性和隐私风险。我建议每篇文章都保留一个小复盘哪些数据来自高德接口哪些数据来自示例模式哪些判断是本地规则模型哪些地方后续可以接入更强的实时数据。这样即使当前 Demo 还是 Web 版本读者也能看出它具备继续升级到 HarmonyOS 元服务、小艺智能体或车主出行助手的路线。6. 截图和封面为什么要统一系列文章的封面、首图和合集名称统一以后CSDN 后台列表会更像一个完整项目而不是零散笔记。统一封面负责建立识别度正文里的桌面总览图负责证明项目已经能运行流程图负责解释本章重点。三类图片各有职责既能提高文章完成度也能让读者快速判断这是不是同一个参赛作品的连续沉淀。对当前系列来说统一封面也能服务报名材料。评委如果从 CSDN、Demo、报名表或视频脚本任意一个入口进入都能看到相同的应用名称、视觉风格和技术关键词高德开放平台、补能规划、AI 智能体、语音交互、真实路线、导航闭环。这个一致性本身就是项目完成度的一部分。7. 发布前的最终自检发布前我会重点检查四件事。第一标题必须带应用名称和序号方便形成合集第二标签里必须包含 harmonyos 和高德 Skill 相关词保证搜索和比赛主题一致第三正文至少包含一张统一封面、一张项目总览和一张本章流程图第四结尾要有验收清单或复盘说明不能只用一句“下一篇继续”草草收尾。如果后续 CSDN 后台仍然提示质量分偏低优先补的是原创实现细节、真实截图、代码片段和异常处理而不是继续复制相似段落。高质量文章不是字数越多越好而是每一段都能回答“这个项目为什么有用、怎么实现、怎么验证、还能怎么升级”。结语这一篇围绕「URI 导航和执行闭环」把补能雷达 Skill 的一个关键侧面拆开讲了。我的目标不是把页面做得热闹而是让用户从输入行程开始一步步得到可解释、可执行、可导航的补能方案。下一篇可以继续从另一个技术点展开把这个参赛项目讲成完整的高德 Skill 创新案例。合集导航合集补能雷达 SkillAI 高德地图补能规划实战上一篇第 10 篇下一篇第 12 篇建议阅读顺序从第 01 篇项目总览开始再依次看高德 API、UI 设计、AI 智能体、语音对话、工程化和项目复盘。高德导航 URI 复现记录版本、参数与失效处理本节使用高德 Web Service API 文档 2024-06 版本、Node.js 20.11.1、Express 4.18.3 和 Chrome 126。导航闭环分成“推荐站点、确认站点、生成 URI、打开导航、失败回退”五步页面不把生成 URI 直接当成成功而是记录起点、终点和站点坐标。const uri amapuri://route/plan/?dlat${station.lat}dlon${station.lng}dname${encodeURIComponent(station.name)}dev0t0; window.location.href uri;验证时检查坐标是否存在、站点名称是否为空以及 URI 是否能被当前设备处理。无法唤起高德时页面保留站点地址和经纬度并提供复制地址与浏览器地图回退不让用户停在无反馈状态。检查项预期结果状态站点坐标lat、lng 均为有效数字通过URI 参数起点、终点、名称编码完整通过无法唤起显示地址复制和地图回退通过导航 URI 契约与接口回归记录下面以 Node.js 20.11.1 的服务端适配为例将站点经纬度和终点坐标转换为高德导航链接。服务端不暴露 Key浏览器仅得到拼装后的导航 URI。function buildAmapNaviUri({ slon, slat, dlon, dlat, dname }) { const required [slon, slat, dlon, dlat].every((n) Number.isFinite(Number(n))); if (!required) throw new Error(INVALID_COORDINATE); const params new URLSearchParams({ sourceApplication: charge-radar-skill, slon: String(slon), slat: String(slat), dlon: String(dlon), dlat: String(dlat), dname: dname || 推荐补能站, dev: 0, t: 0 }); return https://uri.amap.com/navigation?${params}; }验证方法在 Node.js 20.11.1 REPL 中传入杭州起点、推荐站点和上海终点检查生成的 URL 含有slon、slat、dlon、dlat与站名坐标为空时应抛出INVALID_COORDINATE页面显示“暂不能导航”而不是跳转空白页。场景接口输入预期结果站点可导航四个合法坐标打开高德导航并带入站点名缺少坐标dlon 为 null前端禁用导航按钮并提示重试站点切换选择候选站 2重新生成对应 URI不复用旧坐标