夜雨聆风这是【用 AI 做个旅行规划工具】系列文章的第15篇。在上一篇文章中，我们把前端的基本框架搭建起来了，本篇介绍一下接入地图组件的过程。
改 Bug 容易，写新功能难
在正式开始之前，想先聊一点最近的感受。我曾看过一篇文章，说让 AI 新写一段程序会相对简单，而让它去改现有程序的 Bug 则会复杂许多。
但我的感觉却恰恰相反。原因在于，如果是让 AI 改 Bug，它面对的是一个完整的、既有的老程序。它可以分析上下文，识别其中的逻辑问题所在。但如果是让它写一个新程序或新功能，就意味着你必须把大量非常具体的细节全都告诉它。而这些细节，要么在当时很难明确地表述清楚，要么是你自己都还没完全想明白。
地图组件选型
我对怎么加地图不太了解，便先用 AI 做了一个简单的调研，看用哪个服务商的方案更方便。
我的需求概括起来比较简单：
1. 能够根据城市名将地图定位到对应区域。 2. 能够自由地移动、缩放地图。 3. 能够在地图上显示区域内的交通站点、旅游景点、酒店民宿等信息。 4. 能够获取用户点击的某个城市或景点的详细信息。
带着这些需求，我问 AI，有哪些地图服务能用，哪家接入起来更省事。AI 给出的回复是，在国内主要就是百度、高德和腾讯地图这三家，其中高德的地点信息反馈比较快，也是开发者用得比较多的一个平台。于是我就申请了高德地图的个人开发者账号，拿到了 API Key（以及配套的密钥配置）。我又顺便找到了官方开发文档，把这些文档直接丢给 AI，让它参考文档把地图组件加到界面上。
集成中意料之中的“坑”
这么一个新功能，AI 很快就搞好了，但麻烦也随之而来。
首先，它没能直接根据已知的地点，把地图定位到对应的区域。其次，我希望点击地图上的点时，能把它所代表的点位信息识别出来，但实际点击后，发现它只能返回一个坐标，而没法告诉我这是哪个景点。这两个问题也只能怪我，谁叫我没告诉它这些细节呢？
对于第一个问题，AI 解决起来很容易。它先调用高德的地点搜索 API，将地名转换为对应的坐标，再以此定位地图即可。对于第二个问题，AI 告诉我这是高德地图的一个“坑”：不能使用普通的点击事件，而要使用一个叫“hotspotclick”的事件才能获取热点信息，并且需要在地图上主动开启热点功能。
改完之后又发现新的问题。它返回的热点信息并不太准确，比如说，你明明看到地图上标注的是一个风景区，但点击之后，它识别并显示出来的，居然是一个商圈。
细节问题层出不穷
前文提到的地点搜索 API，在我频繁测试时突然报错，找不到地点了。起初我以为是代码本身的 Bug，后来才发现是 API 调用超过限额了。我不想花钱提高限额，于是让 AI 给代码加一个缓存层，将查过的地点暂存下来，避免重复请求。
接着还有地图热点。我的初衷是把点位搞得干净一些，只关注酒店、景区和交通站点这类有用的信息，这样也就不会有点击风景区出来一个商圈的问题了。
但现实是，高德地图并没有提供这种对自带热点进行“过滤”的机制。除非把已有的全部热点清掉，自己把所有需要的点一个个手动加上去。可这么一来，肯定会慢很多，而且每一次搜索又会产生新的 API 消耗。这个方案费时费力，效率却不高。
还有一个问题。我们最初的需求是点击景区显示详细信息，但具体信息“显示在哪儿”，这个我原来没有细想。等到真要实现时才发现，还得有一块区域来承载这些详情，用弹框还是浮动层呢？我最终决定放在一个独立的区域。这就是开发新功能时最耗费精力的地方——不断有事先没确认好的细节冒出来，需要你现场做决策。
随时检查代码
最后还有一点体会。比如为了绕开限额，我们给地点转坐标的接口加缓存。AI 很快做完了，但事后我发现它做得不对，它应该把相关接口调用集中到同一个文件里处理，并统一做缓存。但当时我没有这么说，它就不知道这么做。让它重构，它倒是不怕麻烦。
AI 只是个工具，不是个魔法
虽然实现这个功能总共花的时间并不长，比完全自己从零写要省些事，但其实成果并不算理想，而且该操的心，真是一点儿都没少。归根结底，AI 现在帮我们做的事，更多是把你一个相对明晰的想法，快速变成代码。但那些没有想到的部分，想到没有说出来的部分，说出来但没说准确的部分，还是得自己一点点儿去告诉 AI，要不然它做出来的东西就是没法令人满意。
如果是边想边做，指望它能带来“一句话就搞定一个功能”的神奇体验，那是不现实的。效率上的提升当然有，但你仍需抱有合理的心理预期：你依然要投入大量个人精力，去做那些需求澄清、细节决策、监督检查和最终把关的事情。
最后，给大家看一下现在的效果图，这就是接入了地图的界面。
欢迎关注，期待下次见面
