夜雨聆风这是【用 AI 做个旅行规划工具】系列文章的第 18 篇。在前篇文章中，我虽然被 AI 带偏了节奏，但最终还是加上了那个按钮，点击就能把地图的选点添加到目的地列表里。这一次就更高级了，我跟 AI 陷入了一种更奇怪的局面：互相误导。
相关文章：用 AI 做个旅行规划工具：被 AI 带偏节奏是什么体验
奇怪的 Bug
事情还是发生在地图界面上。
我在地图上点了一个“资阳”，把它加到目的地列表里，于是目的地列表里就多出来了一个“资阳市”。（在上篇文章中我提到，地图 API 返回的地名会多带一个「市」字）
因为前面大理、昆明都只有俩字，这个“资阳”多了一个“市”，看着有点别扭，就想把那个“市”字删掉。结果一删掉“市”字，地图上的几个点位标记全没了。把“市”字加回去，点位又全回来了。即使刷新了页面，问题依旧。
去后缀算法
我觉得这可能是个 bug，就把这个现象跟 AI 描述了一下，让它查一查。我感觉可能跟地图的交互有关系，所以让它在页面上加点东西，以方便调试跟第三方接口的交互。
AI 闷头一会儿就改完了。运行也正常了。我其实不清楚具体的原因，就多看了一眼它的输出。它说之前用的是 geocodeAddressToLngLat 这个方法，修复之后换成了 resolveAddressToLngLat 这个方法。
我让它解释一下这两个方法有什么不同，为什么换了新的方法就解决了这个问题。
它说老方法会把地点名称直接丢给地图 API，而在新方法里会先根据地图名称生成几个查询词，再依次调用地图 API。
比如要在地图上标注“资阳市”，它会先生成一个数组 ["资阳市","资阳"]，再依次尝试获取坐标。
我感觉这个思路可能没啥问题，只是不太相信高德地图会这么傻。
破绽
它的输出里有一句话是这么说的：“我们观察到高德 Geocoder 对带「市」的短纯地名常无结果，对不带后缀的短名更容易命中”，我觉得它这个“观察”很奇怪，于是向它确认这个信息是哪来的，根据地名生成多次查询的做法是否是业界通用做法？
AI 说这种操作在业界很常见，还说 XX 省/XX 市的写法 API 不一定认同，用短一点更容易命中。接着它抛出一句原话：“单次请求成功率很难达到 100%（各家文档和 orchestrator 产品都会说）。”
我不知道它说的“orchestrator 产品”是什么，但它既然提了“各家文档”，那我直接问：高德地图的产品文档里有这个说明吗？
到这儿它开始露怯了，它说高德地图并没有相关的文档说明，但也没有保证 100% 能查到。
互相误导
我立刻追问：第一，你把一个地点拆成多个变体去查的思路，到底是从哪儿来的？既然我们用的是高德地图，你为什么考虑用这个方法？有没有相关信息来源？第二，对于“资阳市”查不到、“资阳”能查到的问题，你有没有确认过本质原因？你有没有对比过两个请求返回的响应数据？
AI 坦白：它没有对比过。它只是根据我的说法——“资阳市查不到，资阳能查”——做出的假设，因为这是我已经验证过的用例，所以它就脑补了这个原因，并写了一个方法，把地名中的那些“市”、“省”、“自治区”之类的后缀都去掉，然后才做了这套算法。
看，整个逻辑闭环了：我描述了一个现象，被它误认为是一个规律，它基于这个“规律”造了一套看似专业的解决方案，进而误导了我。
真正的原因
AI 给了我一段脚本，说可以用来验证一下两个请求的返回数据是不是一样。
我执行了这个脚本，结果发现不管是“资阳市”还是“资阳”，都能正确返回结果。说明问题根本不在这里。
于是我让它把代码还原到之前的版本，重新追查问题的真正原因。
最后发现，其实是代码里的一个 bug。AI 说了一个词，叫“竞态”。大意是说页面有多个异步请求，其中一个请求把另一个给取消掉了，导致回调任务取消，进而一直没有在地图上显示点位。总而言之，就是这个页面逻辑挺复杂，有各种异步事件触发的情况。再具体的原因我就没有再细究下去了。
之前的方案为什么有用
既然真正的原因是“竞态”，为什么之前那个基于错误前提的方案，也能把问题解决？
AI 给了三个理由：
1. 误打误撞：多查一次之后，碰巧把那个“竞态条件”给碰掉了。 2. 意外缓存：一旦查询成功，缓存里就有了“资阳”和“资阳市”两个地点的数据，后续更容易查到。 3. 连带修复：在做上层修复的时候，一些代码变更也有助于减少竞态条件。
也就是说，它用一套复杂的理论解释了一个不存在的病，又误打误撞用一张膏药贴对了一个它根本没看见的伤口。这个虚假的成功，反过来又让我误以为它的诊断是正确的。
让 AI 辅助编程，还是省不了心啊。
这次与 AI “斗智斗勇”的经历就分享到这里，咱们下次再见。
欢迎关注，期待下次见面
