之前想做的"嵌入外卖平台导航""实时电梯数据"等，评估后发现目前不可行。核心原因是：
1.骑手用平台内置导航 → 导航出错时手动切高德腾讯百度 → 整个过程买家信任的是平台，不是第三方。2.隐私保护。
暖行者AI不碰买家数据，不碰订单数据：
暖行者AI真正需要的：
├── "我要去阳光花园7号楼" → 骑手说一句话就行
├── 7号楼怎么走 → 暖行者AI自己有路径数据
└── 骑手上次来过 → 记住骑手自己的历史
不需要知道：
├── 买家是谁、电话、买了什么、订单号、精确门牌号 ✗
骑手说"去7号楼"和买家隐私完全无关。暖行者AI就是一个引路工具，跟问路人一样。
继续和TRAE讨论产品定位问题，评估自建小区路径数据是否有难度，并参考高德功能上线以来的情况。如果做成独立App，较为繁琐，需要推广 — 为了问一句话装一个App，跟高德评论区一样，知道有用但覆盖率有限。高德评论区和弹幕区能火是因为堵车时司机有强烈动力上报（利己+利他，即时反馈），但小区路径数据是静态的、低频的，对于三方平台，骑手上报的动力远不如上报路况。
此番改进：
1. 调研了高德/腾讯/百度/美团等平台的开放能力
结论：
-
高德MCP Server和Skill市场主要面向AI IDE开发者，不是骑手端自动触发机制
-
高德Android LLM Agent SDK支持语音交互+导航控制+跨应用通信，技术上可行
-
美团/饿了么骑手端数据封闭，第三方无法直接接入订单流
-
腾讯地图2026年5月上线骑手模式（楼栋级导航、门禁提示），百度也已推出
2. 发现了真正的差异化缺口
| 大平台正在改进的（不重复做） |
暖行者AI专注的 |
| 楼栋级导航 |
AI对话式引路 |
| 门禁信息 |
骑手记忆 |
| 道路导航 |
暖心关怀 |
| — |
暖接听（概念展示） |
腾讯/百度已在楼栋级导航上建立数据壁垒（海量轨迹+骑手众包），我们不与其重复写产品。暖行者AI专注于目前没有做的：
-
AI对话式引路（不是冷冰冰的导航指令，而是"走北门第二个单元，30秒到电梯口"）
-
骑手记忆（“你上次来过，这次推荐走东门更近”）
-
暖心关怀（天气提醒、安全提醒、鼓励语句）
-
暖接听（骑手到楼下了联系不上买家（可能漏接），AI代接听导航并提示放哪里，既往如何确认告知买家；买家端可开启循环提醒音闹铃，直到确认收到送达）
-
一键预约餐（“骑手顺手取餐吃饭，如骑手到达时，取一个送餐的餐和一个自己的餐，送完A地点，骑手自己也可以休息吃饭”）——感谢社区贡献者@深圳大云
3. 确定了产品形态路线
| 阶段 |
形态 |
说明 |
| 现在（初赛） |
TRAE Skill + HTML拟态Demo |
不需要独立App，零隐私风险 |
| 复赛 |
开源方案 |
引路AI设计、数据模型、交互逻辑 |
| 远景 |
平台合作 |
平台将引路能力内置骑手导航，暖行者AI贡献方案 |
核心定位：暖行者AI不是要跟平台竞争，而是帮平台看到骑手最后一公里导航的盲区，并验证AI引路方案。作为社会公益项目，开放概念Demo供京东/美团/饿了么等平台参考。
-
比赛是社会公益赛道 — 是在提社会方案
-
概念开源是公益姿态 — “我们验证了引路AI的可行性和价值，开放给平台参考”
-
平台有动机做这件事 — 骑手效率提升，京东/美团有充足理由参考概念完善他们的骑手端
数据支撑：全国1400万活跃骑手，75%受"最后一百米"困扰，日均骑行50-80km，骑手找楼平均多耗3-10分钟。
总结
收窄到"引路助手"后，暂不做独立App。
嵌入后类比高德弹幕功能，堵车时司机有强烈动力上报（利己+利他，即时反馈），但小区路径数据是静态的、低频的，骑手上报的动力远不如上报路况。高德评论区能活是因为它长在用户每天必用的App里（高德地图），用户上报路况是顺手的事。如果高德评论区是一个独立的App，下载和推广不太实际。
暖行者AI同理。它必须长在用户已经在用的东西里面，才有使用价值。
外卖场景下UGC还有一个额外风险：
高德评论区：车主说"前方施工绕行" → 安全，无隐私问题
暖行者评论区：
"3号楼502经常点外卖，门口有狗" → 隐私泄露
"这个保安态度差不让进" → 恶意评论
"某户独居女性" → 安全隐患
那暖行者AI长在哪里？
现在能长的地方：Skill（AI对话中触发）
└── 用户问"阳光花园7号楼怎么走" → 暖行者Skill自动回复
└── 不需要骑手下载任何东西，随着平台开放AI功能，平台里直接能用，暖行者收集信息完善注入产品
未来能长的地方：平台的骑手导航里
└── 但这个现在做不到，所以是远景
中间态：HTML Demo（比赛展示用）
└── 证明"AI对话引路"这个概念可行，让大家初步了解暖行者AI
└── 根据时间和精力衍生其他关联产品
数据从哪来？
比赛阶段：自建1-2个模拟小区
└── 不需要真实数据，JSON写几个小区的路径数据用来演示
开源方案阶段：公开数据模型和采集方法论
└── 平台自己有海量骑手轨迹（百度/腾讯已经这么做了）
└── 暖行者AI贡献的是"AI对话引路"的交互设计，不是数据本身
暖行者AI不需要自己建30万个小区的数据，那不是一个人能做的事。暖行者AI做的是：用1-2个小区的数据，证明"AI对话引路"比传统导航指令更好的产品体验，然后把方案开放给有数据的平台去实现。
现在的切入点
我们现在从最轻量的TRAE Skill开始，多平台是时间和技术允许后的扩展方向，不是一口吃成大胖子。
多平台是完整战略（如初赛Demo中展示的6端设想），但现阶段从TRAE Skill切入，后续根据时间、技术和B端合作情况，逐步扩展到独立App和多端融合，吸引更多行业B端。
现在的切入点：TRAE Skill（AI对话引路，验证核心价值）
↓
看时间和资源：
├── 有时间 → 做HTML拟态Demo → 复赛展示多平台概念
├── 有技术 → 探索高德Android LLM Agent SDK → 做骑手端原型
└── 有B端对接 → 平台合作 → 融入更多行业（快递、生鲜、医药配送）
↓
远景：全平台覆盖（iOS/Android/Windows/小程序/地图嵌入/AI Agent）
作为经常在机房、基站之间跑的网络工程师，我太懂这种"最后100米"的无力感了。社区大屏的数据可视化做得不错，和我做的运维指挥大屏思路类似——把复杂信息压缩成直觉可读的态势图。感兴趣可以看看我的运维中台：