【腾讯位置服务开发者征文大赛】AI+地图赛道来了,带你读懂选题方向、投稿要求与拿分思路

【腾讯位置服务开发者征文大赛】AI+地图赛道来了,带你读懂选题方向、投稿要求与拿分思路
avatar

🔥 个人主页:杨利杰YJlio❄️ 个人专栏:《Sysinternals实战教程》《Windows PowerShell 实战》《WINDOWS教程》《IOS教程》《微信助手》《锤子助手》《Python》《Kali Linux》《那些年未解决的Windows疑难杂症》🌟 让复杂的事情更简单,让重复的工作自动化

在这里插入图片描述


文章目录

在这里插入图片描述

1. 【腾讯位置服务开发者征文大赛】AI+地图赛道来了,一文读懂选题方向、投稿要求与拿分思路

最近我认真看了一遍 腾讯位置服务开发者征文大赛——AI赋能,重塑地图智能新体验 的活动规则,最大的感受只有一句话:这不是一场普通的征文活动,而是一次把 AI、地图、智能体、MCP、时空数据真正串起来的实战型比赛。

这次活动的主题非常明确,就是围绕 AI+地图 展开。它不只是让开发者写一篇“活动介绍文”,而是更鼓励大家围绕 腾讯位置服务的地图、导航、定位等能力,结合 Agent、Tool Calling、MCP、时空数据、多轮对话、自然语言交互 等热门方向,真正做出一个有场景、有思路、有实现过程的作品。

在我看来,这次活动最有价值的地方,不是奖品多,而是它给了开发者一个非常清晰的落地方向:把“AI会说话”进一步变成“AI会理解地图、会调用工具、会输出结果、会服务真实场景”。


在这里插入图片描述

2. 为什么我觉得这场比赛值得认真参加

从活动规则来看,这次比赛面向的并不只是某一类开发者。
无论你是做 Web 前端、小程序、数据分析、商业智能,还是刚开始接触 AI 与地图场景的新手开发者,都能在这里找到切入点。活动方明确提到,全体开发者均可参加,即使不写技术文章,只参与传播与分享,也有积分玩法可以参与。

我之所以觉得它值得认真参加,主要有三个原因:

第一,它的方向足够新。
现在很多人都在讲 AI,但真正把 AI 和地图能力结合起来的内容并不算多。地图不只是“展示位置”的工具,它背后还关联着 POI 检索、路线规划、区域洞察、轨迹分析、商业选址、多人出行协同等更丰富的能力。
当这些能力和 AI 结合后,地图就不再只是“看得见”,而是开始向“能理解、会推荐、会规划”演进。

第二,它的要求足够实战。
活动方鼓励围绕腾讯地图 Map Skills 体系来展开,比如 tencentmap-jsapi-gl-skilltencentmap-miniprogram-skilltencentmap-lbs-skilltencentmap-webservice-skill 等,同时也鼓励叠加 Agent、MCP、Tool Calling、时空数据 等能力。换句话说,评审更看重的不是空谈概念,而是你有没有把技术能力真正落到一个具体场景里。

第三,它的评审标准非常清晰。
创意性和技术深度各占 30%,能力丰富度占 20%,工具结合度和排版可读性各占 10%。这意味着文章想拿高分,不能只靠“写得热闹”,而要在 场景创新、技术实现、能力组合、文章呈现 四个层面同时发力。

说白了,这次比赛比的不是谁会堆关键词,而是谁能把 AI+地图这件事讲明白、做出来、写完整。


在这里插入图片描述

3. 这次征文,最值得写的方向有哪些

我看完活动给出的赛道说明和灵感参考后,觉得真正容易写出亮点的方向,大致可以归纳成下面几类。

3.1 对话式地图交互

这是最容易理解、也最容易吸引读者的一类场景。
比如我输入一句自然语言:

  • 附近人少、有插座、适合办公的咖啡馆
  • 帮我规划一个周末一日游行程
  • 几个人从不同地点出发,推荐一个汇合点

背后其实涉及的是 自然语言理解 + 地图检索 + 路线规划 + 结果展示
这种方向的优势在于,读者一眼就能看懂价值,文章也容易通过截图和流程图把效果展示出来。

3.2 智能行程与多人出行规划

这一类非常适合结合 Agent + Tool Calling + 地图服务 来写。
比如让智能体根据多人出发地点、时间安排、交通方式和偏好,自动生成一个合理的出行计划,再把路线与推荐点位展示在地图上。
这种文章只要结构写清楚,往往兼具创意和实用性。

3.3 商业选址与区域潜力分析

如果你更偏数据分析、BI 或商业场景,那就可以从 时空数据、热力图、POI 分布、区域潜力 等方向切入。
例如:

  • 某区域是否适合开咖啡店
  • 某商圈周边客流与竞争情况如何
  • 某业务轨迹数据如何在地图中可视化分析

这类文章的优势在于,很容易体现“地图不是工具,而是决策大脑”的主题

3.4 AI 辅助地图开发

活动中也明确提到,可以结合各类 AI 工具、大模型、智能体、AI 助手等能力来完成场景设计与实践,但前提是要体现 AI 与地图场景的真实结合,而不是空泛堆砌概念。
所以,写这类文章时,重点不是“我用了某个大模型”,而是:

我用了它做什么,它如何帮助地图场景更智能,它最终提升了什么。

我的建议是:选题一定要小切口、真问题、能落地。不要上来就写一个特别大的系统,反而容易把文章写散。


在这里插入图片描述

4. 想拿高分,文章一定要这么写

很多人一看到“征文比赛”,第一反应是赶紧开写。
但我更建议,先把评审逻辑看透,再决定文章结构。

活动方已经把要求说得比较清楚了:
标题必须带 【腾讯位置服务开发者征文大赛】,文章需要基于真实体验使用腾讯位置服务能力进行书写,正文不少于 2000 字,最好包含 作品背景、创意来源、技术架构与实现思路、关键代码片段、运行效果截图或动图;如果能提供 可运行 Demo 或演示视频,会在评审中获得额外加分。

所以,从高分文章的角度看,我建议正文尽量按下面这个结构写:

4.1 问题背景

先把你为什么要做这个场景说清楚。
不是简单说“我想做一个地图项目”,而是要说明:

  • 这个问题在现实中为什么存在
  • 传统方案为什么不够好
  • AI 和地图结合后,可能解决什么痛点

4.2 技术方案

这一部分要讲清楚系统是怎么跑起来的。
比如:

  • 前端用什么展示地图
  • 后端如何调用腾讯位置服务能力
  • Agent 或 MCP 在整个链路中扮演什么角色
  • 多轮对话或自然语言理解是怎么接入的

4.3 关键实现

这一段一定要放出 核心代码片段,但不要一股脑把所有源码都贴上来。
真正有效的写法是:
挑关键逻辑讲思路,挑核心代码讲原理。

4.4 效果验证

这一部分非常重要。
一定要让评委看到结果,而不是只看到代码。
你可以放:

  • 页面截图
  • 地图交互图
  • 路线规划结果
  • 对话前后效果对比
  • Demo 视频链接

4.5 经验总结

最后别只写“本文到此结束”。
而要写清楚:

  • 这个方案最难的点是什么
  • 你踩过哪些坑
  • 还有哪些优化空间
  • 这个方向未来还能怎么做

高质量比赛文章的核心,不是“写完”,而是“写得让评委相信你真的做过、真的想明白了”。


在这里插入图片描述

5. 一张图看懂参赛路径

阅读活动规则

确定一个真实场景

选择腾讯位置服务能力

叠加AI能力

Agent

MCP

Tool Calling

时空数据

完成Demo或原型

整理背景 架构 代码 效果

撰写ZEEKLOG征文

提交报名表

站内外传播与积分累积

我觉得这张流程图特别适合拿来放在博客里,因为它能让读者一眼看懂这次比赛的完整路径。
从活动时间安排来看,比赛分为 启航学习周、作品征集、积分累积、评审阶段、获奖公布、颁奖沙龙 等阶段,其中作品征集时间是 3 月 30 日到 5 月 8 日,Demo 可以额外加分,最终获奖名单在 5 月 15 日 公布。


在这里插入图片描述

6. 不只写文章,传播积分也别浪费

这一点我觉得很多人会忽略。
这次活动不是只有“专家评审奖”这一条线,它还有 传播积分玩法
也就是说,除了文章本身,站外分享、作品传播、互动热度 也是能拿到额外奖励的。

活动规则里提到,分享大赛资讯、作品或参赛体验到小红书、B站、知乎、公众号或其他博客站,并带上指定标签,可以累计积分;分享作品到腾讯云开发者平台也有额外积分;而且 积分奖和专家评审奖是可以叠加领取的

这就意味着,如果我真的准备认真参赛,我不会只做一件事,而是会把整个动作拆成三步:

第一步,写一篇真正能打的主文章。
核心是场景、技术、Demo 和排版。

第二步,把 Demo 或核心亮点做成短内容。
比如录一个简单演示视频,或者拆出一篇“开发复盘”。

第三步,做站内外联动传播。
因为比赛里明确存在传播积分,所以文章写完以后,传播动作不能缺位。

有些比赛,内容强就够了;但这次活动明显是“内容质量 + 传播热度 + Demo 展示”三条线一起发力,效果会更好。


在这里插入图片描述

7. 总结提升:这次比赛真正考验的是什么

看完这次活动规则后,我的判断很明确:

这场比赛表面上是在征集 AI+地图 文章,实际上考验的是开发者把“地图能力、AI能力和真实场景”整合到一起的能力。

它不是单纯考谁懂 AI,也不是单纯考谁会调用地图 API,
而是考你能不能:

  • 找到一个真实场景
  • 用腾讯位置服务把地图能力接起来
  • 用 AI、Agent、MCP、Tool Calling 等能力把体验做深
  • 用一篇结构清晰、图文并茂、逻辑完整的文章把它讲明白

从奖项上看,这次活动的激励确实很有吸引力;
从评分标准上看,比赛也足够专业;
但在我看来,最值得重视的,还是它给了所有开发者一个非常好的信号:

未来地图类应用的竞争,不只是“显示得准不准”,更是“理解得聪不聪明,决策得够不够好,交互得是否自然”。

所以,如果你最近也在关注 AI+地图、Agent、MCP、时空数据、智能交互 这些方向,那这次腾讯位置服务开发者征文大赛,确实是一个非常值得认真投入的机会。


在这里插入图片描述

8. 给想参赛的同学一个实战建议

最后我再给一个非常实用的建议:

别追求做一个“大而全”的项目,先做一个“小而完整”的场景。

比如你只做其中一个功能:

  • 自然语言搜附近咖啡馆
  • 多人出行汇合点推荐
  • 基于 POI 的智能路线规划
  • 商圈热力与选址分析
  • AI 对话式地图导航

只要这个功能 问题明确、流程完整、结果可展示、代码可解释、Demo 可运行,它就比一个做了很多模块但每个都不完整的作品更有竞争力。

这也是这类比赛里最容易被忽略,但最关键的一点。


总结提升

我把这次活动重新梳理之后,最大的感受就是:
腾讯位置服务这次不是在“征文”,而是在筛选真正理解 AI+地图的人。

文章写得好,说明你能表达;
Demo 做得好,说明你能落地;
传播做得好,说明你能把作品放大。

而这三件事叠加起来,才是真正有竞争力的开发者作品。


返回顶部

返回顶部

Read more

WebRTC实现音视频通话全流程

WebRTC (Web Real-Time Communications) 是一项实时通讯技术,它允许网络应用或者站点,在不借助中间媒介的情况下,建立浏览器之间点对点(Peer-to-Peer)的连接,实现视频流和(或)音频流或者其他任意数据的传输。WebRTC 包含的这些标准使用户在无需安装任何插件或者第三方的软件的情况下,创建点对点(Peer-to-Peer)的数据分享和电话会议成为可能。 WebRTC的应用场景 点对点视频聊天:如 微信视频 等实时视频通话应用。 多人视频会议:企业级多人视频会议系统,如飞书、钉钉、腾讯会议等。 在线教育:如腾讯课堂、网易云课堂等。 直播:游戏直播、课程直播等。 WebRTC实现音视频通话过程 * 1.server端新建socket服务(作为信令服务器),当用户进入客户端的时候将用户端与socket建立连接。 * 2.当客户端与server端建立连接后,客户端会向server端发起一个加入房间的事件,并携带房间id。 * 3.server端监听到加入房间的事件后,会将房间id添加到指定房间中,这样,所有加入同一个房间的客户端

Springboot 4.0十字路口:虚拟线程时代,WebFlux与WebMVC的终极选择

Springboot 4.0十字路口:虚拟线程时代,WebFlux与WebMVC的终极选择

🧑 博主简介:ZEEKLOG博客专家,历代文学网(PC端可以访问:https://literature.sinhy.com/#/?__c=1000,移动端可关注公众号 “ 心海云图 ” 微信小程序搜索“历代文学”)总架构师,16年工作经验,精通Java编程,高并发设计,分布式系统架构设计,Springboot和微服务,熟悉Linux,ESXI虚拟化以及云原生Docker和K8s,热衷于探索科技的边界,并将理论知识转化为实际应用。保持对新技术的好奇心,乐于分享所学,希望通过我的实践经历和见解,启发他人的创新思维。在这里,我希望能与志同道合的朋友交流探讨,共同进步,一起在技术的世界里不断学习成长。 🤝商务合作:请搜索或扫码关注微信公众号 “ 心海云图 ” Springboot 4.0十字路口:虚拟线程时代,WebFlux与WebMVC的终极选择 当虚拟线程以革命性的姿态降临Java世界,一场关于并发编程范式的静默变革正在发生。Spring开发者站在了选择的十字路口。 2023年,Java 21将虚拟线程从预览特性转为正式功能,这一变化看似只是JVM内部的优化,实则撼动了整个

三种适用于Web版IM(即时通讯)聊天信息的加密算法实现方案

三种适用于Web版IM(即时通讯)聊天信息的加密算法实现方案

文章目录 * **第一部分:引言与核心密码学概念** * **1.1 为什么IM需要端到端加密(E2EE)?** * **1.2 核心密码学概念与工具** * **第二部分:方案一:静态非对称加密(基础方案)** * **2.1 方案概述与流程** * **2.2 前端Vue实现(使用node-forge)** * **1. 安装依赖** * **2. 核心工具类 `crypto.js`** * **3. Vue组件中使用** * **2.3 后端Java实现(Spring Boot)** * **1. 实体类** * **2. Controller层** * **3. WebSocket配置** * **2.4 密钥管理、注册与登录集成** * **1. 用户注册/登录时生成密钥** * **2. 密钥设置页面** * **2.

前端文件上传方案:别再只用input type=file了

前端文件上传方案:别再只用input type=file了

前端文件上传方案:别再只用input type=file了 毒舌时刻 这代码写得跟网红滤镜似的——仅供参考。 各位前端同行,咱们今天聊聊前端文件上传。别告诉我你还在用原生的input上传大文件,那感觉就像在用小水管灌满游泳池——慢得让人绝望。 为什么你需要文件上传方案 最近看到一个项目,上传100MB的文件直接卡死浏览器,没有任何进度提示,我差点当场去世。我就想问:你是在做上传还是在做浏览器杀手? 反面教材 <!-- 反面教材:原生文件上传 --> <input type="file" onchange="uploadFile(this.files[0])" /> <script> function uploadFile(file) { const formData = new FormData(