企业官网建设流程全解析

接触过这个项目的人应该都有同感：地图类应用的痛点从来都不在地图本身，而是把自然语言里的地点描述变成能直接落地的坐标。lingbot-map这个项目，最开始就是为了解决这个别扭的转换问题而做的。简单说，它是一个“语言机器人到地图”的映射模块，把用户说的“小区东门右拐第二个路口那家面馆”这类口语化地点，解析成结构化地址，再通过地理编码转成经纬度，最终渲染到地图上。和传统的地名搜索不一样，它面向的是聊天场景中的模糊表达、上下文指代和自由文本。这篇文章我想完整讲一讲这个项目的需求背景、技术选型、核心实现和落地过程中踩过的坑，适合正在做地图助手、问答机器人或任何需要把自然语言和空间位置打通的朋友参考。

1. 项目到底在解决什么问题

1.1 口述地点的“最后一公里”痛点

我们平时找地方，最常见的动作不是拿地图搜索，而是在聊天里问别人。朋友发来一句“就在上次看电影那商场楼下，卖奶茶旁边”，或者“从地铁C口出来穿过天桥往左走到第二个路口”。这句话里有明确的地点线索，但对地图系统来说完全不可用。传统地图搜索框需要结构化关键词，比如“XX市XX区XX路XX号”，而聊天文本里的地点信息往往是省略了主干道、只有相对方位和参照物。

lingbot-map要处理的，正是这个“最后一公里”的翻译问题。它把聊天文本作为输入，通过大模型先做语义解析，抽取出地点主体、限定条件、相对位置和动作意图，再组合成完整地址描述，最后调地理编码服务拿到坐标。这一步做完，后面无论是展示地图、规划路线还是做推荐，都变得顺理成章。

这个项目名称里的“ling”代表语言，“bot”强调它是一个服务化模块，“map”则点明输出端是空间数据。整个链路并不复杂，但每一个环节都有很多细节，比如同一个地点的不同叫法、周边参照物的权重、模糊意图的取舍，这些都会直接影响最终坐标准不准。

1.2 这个项目适合谁来用、用在哪儿

我实际测下来，lingbot-map能发挥价值的地方主要集中在三类场景。第一类是聊天机器人内置“位置问答”能力，用户问“附近哪家川菜馆评分高”，机器人能返回地图卡片而不是一串文字；第二类是社区团购、活动报名这类需要收集地址的场景，用户发一句“我在老图书馆后面的停车场”，系统自动转成地图打点，省去手动填写；第三类是内容编辑工具，比如写旅游攻略时，把文字描述的地标批量转换成可交互地图，方便读者直接导航。

适合读这篇文章的人，我觉得至少有一类共同点：手头有一个依赖自然语言输入的“文字转位置”需求，但不想直接用传统NLP那套复杂流程，想借助大模型能力快速跑通。如果你从来没接触过地图API，只要有点Python基础也能跟下来，因为核心代码不算长，真正难的是怎么把边界情况处理好。

2. 整体设计与技术选型

2.1 为什么不走传统NER路线

第一次做这个需求时，很容易想到传统命名实体识别（NER）方案。先训练一个模型识别文本里的地点名词，再抽取“旁边”“对面”“朝东”等方位词，组合成结构化地址。这个思路看起来直接，但实操后会发现几个棘手问题。

首先是标注数据不好搞。聊天文本的地名表达自由度太高，训练一个人名、地名、机构名的通用NER模型不难，但让它精确识别出口语化的“上次看电影那商场楼下”很难。其次是组合逻辑复杂。即使识别出“商场”和“楼下”，还要判断这两个碎片之间的关系；如果再加上“穿过天桥左转”这种移动描述，传统的规则引擎会写出大量条件分支，几乎相当于手工维护一份城市路况说明书。

lingbot-map改用大模型函数调用作为解析核心。思路很清晰：把“解析用户意图”和“获得结构化字段”压缩成一次大模型调用，模型输出符合约定Schema的JSON，应用层直接消费。这样做的好处是省掉了大量特征工程，同时天然支持上下文理解，比如用户说“换一家超市吧”，模型可以根据上一轮的地点自动补全成“在地标附近的另一家超市”。

2.2 整体架构与数据流

整个模块的核心链路可以拆成四段：输入文本清洗、语义结构化、地理编码、结果封装。

文本输入先经过一个轻量清洗层，去除语气词和无关表情符号，把“我想要去”这类短语归一成“去”。清洗层不做深度理解，只保证后面喂给模型的内容更干净。然后是语义结构化，这里用到大模型函数调用，定义好一个locate_place函数，参数包括address_text、landmark_ref、relative_position、time_context等字段。模型根据用户消息决定要不要调用这个函数，并填好参数。

拿到结构化字段后，进入地理编码环节。这个模块会根据字段生成若干候选完整地址，比如address_text是“小面馆”，landmark_ref是“人民公园西门”，relative_position是“对面”，最后拼成“某市人民公园西门对面小面馆”。然后调用地图服务商的地理编码接口，转出经纬度。

结果封装也不只是返回坐标。我还会带上原始文本、解析出的结构化字段、置信度、候选列表等信息。这样上游业务可以自己做兜底和展示，而不是面对一个孤零零的经纬度值。

2.3 关键技术选型：函数调用、地理编码与坐标纠偏

这里我特别想聊三个具体选型。

第一个是大模型函数调用。比起让模型直接输出JSON，函数调用更规范，因为它有明确的Schema约束，模型会把缺失字段设为null，而不是强行编造。这个对后续容错非常关键。另外，函数调用天然支持多轮对话，模型可以根据历史消息补全缺失信息，这一点是传统规则引擎做不到的。

第二个是地理编码服务商。建议把地理编码封装成独立接口，不要写死在业务代码里。一来不同服务商的地址解析能力差异很大，同样的“人民公园西门对面”，有的服务商能直接命中，有的只能返回人民公园坐标；二来可以随时切换或同时查询多家做交叉验证。我实际项目中是配置了两家服务商，优先用主服务商，如果置信度低于阈值再调备用服务商，用结果互相校验。

第三个是坐标系纠偏。不同地图服务商会使用不同坐标系，有的用国际通用的标准坐标，有的用加密后的坐标。坐标转换这件事看起来简单，实际很容易被忽略。我踩过的坑是：开发环境下用的测试坐标没问题，一上生产，用户上报的偏移量肉眼可见。后来统一在模块出口做了一次坐标转换，并且把坐标系标识一起写进返回结构。后面遇到了再展开说。

3. 核心模块与实现细节

3.1 提示词工程：让模型输出结构化地点描述

函数调用能不能生效，很大程度取决于提示词里的“函数描述”写得是否清楚。很多人以为只要把Schema丢给模型就行，其实不是。模型要准确填参，需要知道每个字段的用途和取值偏好。

我设计的函数描述大致长这样：

{ "name": "locate_place", "description": "从用户的自然语言中提取地点信息，用于后续地图定位。注意保留相对描述，不要丢失参照物。", "parameters": { "type": "object", "properties": { "address_text": { "type": "string", "description": "用户文本中直接出现的地点主体，如“小面馆”“人民公园”“停车场”。如果没有明确地点，则输出空字符串。" }, "landmark_ref": { "type": "string", "description": "用户提到的参照地标，如“上次看电影那商场”“地铁C口”。可与address_text相同，但要让模型尽量区分主体和参照物。" }, "relative_position": { "type": "string", "description": "地点相对参照物的方向或距离，如“对面”“楼下”“东侧300米”。没有则输出空字符串。" }, "motion_text": { "type": "string", "description": "到达该地点的移动路径描述，如“穿过天桥左转”“出了西门右拐”。用于辅助生成更准确的地址候选。" }, "intent": { "type": "string", "enum": ["search", "route", "share", "other"], "description": "用户的意图，search表示想找地点，route表示想问路线，share表示想分享位置。" } }, "required": ["address_text", "intent"] } }

这段描述里有几个细节。首先是landmark_ref和address_text分开，这能有效避免模型把参照物当成目标地点。比如“人民公园对面那个面馆”，如果只抽一个字段，模型可能输出“人民公园”，也可能输出“面馆”，拆成两个字段后，目标地点被强制落到address_text，参照物落到landmark_ref，后面拼接时就有据可循。

其次是relative_position单独成字段，方便后续处理“对面”“旁边”“前进50米”这类方位修饰。如果把它混在address_text里，地理编码时地址会变得很臃肿，比如“某市人民公园对面那个面馆”，很多地图服务商解析起来反而更差。

motion_text字段是我后来加的。因为完整地址生成时，如果只有“面馆”和“对面”，地理编码还是找不到具体位置；但如果加入“从人民公园西门出发，出门右转，走过两个路口”，至少能帮系统在候选结果里判断哪个坐标更合理。这个字段不直接用于编码，而是作为候选地址的评分依据。

3.2 多轮会话和上下文补全的处理

模板里还有一个没有体现在函数描述中的关键能力：多轮会话。用户第一句说“帮我找一下人民公园附近的面馆”，模型会触发locate_place，返回address_text=面馆、landmark_ref=人民公园。但用户紧接着说“换一家评分高的”，这句话本身没有任何地点信息。如果每次都孤立调用函数，肯定拿不到有效输出。

解决方案是把历史对话一起传给模型，并在系统提示词里写明“如果当前消息缺少地点信息，请参考最近一轮包含地点的历史消息补全”。这里有个小陷阱：不能简单地让模型“从历史里抄地址”，因为它可能把距今很多轮的地名错误地带进来。我的做法是只保留最近两轮对话作为上下文窗口，同时给locate_place增加一个inherit_from_history的布尔参数，模型只有确认当前文本是对上轮地点的追问或补充时，才把这个参数设为true，然后在address_text里输出补全后的完整结果。

补全也不是无脑拼接。比如上轮地点是“人民公园西门对面小面馆”，这轮说“换一家评分高的”，模型会输出“人民公园西门对面 其他面馆”。这个逻辑用规则不太好写，但大模型配合函数约束能在大部分情况下给出合理结果。实测下来，多轮补全的准确率基本能达到八成以上，剩余两成多半是用户使用了非常个人的表述，比如“上次下雨躲雨那家店”，这种信息缺失太严重，模型也会老实返回空字段，不强行猜测。

3.3 地理编码与坐标映射的容错设计

地理编码是整条链路中最依赖外部服务的部分，也是最容易翻车的一环。我第一版直接把函数解析出的address_text拼成完整地址交给地图服务商，后来发现很多口语化表达根本没法编码。比如“小区东门出去右拐第二个路口那家面馆”，地图服务商收到这串文字大概率返回空结果或城市级坐标。

后来我调整了整个容错策略。第一步是生成多个候选地址，不只按“完整拼接”一个方式。规则可以概括成几档：完整地址、主体+参照物、仅主体、仅参照物、参照物+区域名。对“人民公园西门对面小面馆”，生成的候选包括“某市人民公园西门对面小面馆”“某市人民公园西门”“某市人民公园”。分别去调地理编码，拿到结果后按优先级和返回置信度打分。

第二步是引入结果过滤。如果某个候选地址返回了坐标，但坐标落在明显奇怪的位置，比如距离参照物几百公里，这种结果要果断丢弃。我这里的做法是，如果同时有“参照物坐标”和“目标地点坐标”，就计算两者距离，设定一个最大距离阈值，超出阈值则放弃该候选，退而求其次使用下一档候选。

第三步是结果降级。如果所有候选都失败，我不会直接返回空，而是返回文本所在的市级中心点坐标，同时把confidence置为low，把解析出的字段原样带上。这样上层业务可以选择展示“大概在这个城市”而不是彻底没反应。这一步虽然看起来像“和稀泥”，但在真实产品里体验差距非常大。

4. 动手实现一个最小可跑版本

4.1 项目结构与依赖准备

实现lingbot-map的最小闭环，我用的是Python，依赖并不多。核心只需要两个：一个能调用大模型接口的SDK，一个能发起HTTP请求的库。地图服务商的SDK看情况，我这里直接写一个简单的requests封装，方便你替换成自己的服务商密钥。

项目结构大致如下：

lingbot-map/ ├── main.py ├── geo.py ├── prompt.py ├── config.py └── requirements.txt

prompt.py里存放函数调用的Schema定义和系统提示词；geo.py封装地理编码服务的调用和坐标转换；main.py负责把整个链路串起来；config.py放各类密钥和参数。这样拆分的好处是，你想换模型服务商或地图服务商时，只改一个文件就行。

requirements.txt 内容比较简单：

requests>=2.25.1

如果你的大模型服务商提供了Python包，建议直接用它自己的SDK，省去签名字段等麻烦事。这里为了通用性，我用最朴素的HTTP请求做示例。

4.2 核心代码：从文本到坐标

先定义函数调用的Schema，这部分和之前的JSON结构对应。为了代码可读，我把它放成一个Python字典，脚本启动时会加载给模型服务商。

# prompt.py FUNCTION_SCHEMA = { "name": "locate_place", "description": "从用户的自然语言中提取地点信息，用于后续地图定位。注意保留相对描述，不要丢失参照物。", "parameters": { "type": "object", "properties": { "address_text": { "type": "string", "description": "用户文本中直接出现的地点主体，如‘小面馆’‘人民公园’‘停车场’。如果没有明确地点，则输出空字符串。" }, "landmark_ref": { "type": "string", "description": "用户提到的参照地标，如‘上次看电影那商场’‘地铁C口’。可与address_text相同，但尽量区分主体和参照物。" }, "relative_position": { "type": "string", "description": "地点相对参照物的方向或距离，如‘对面’‘楼下’‘东侧300米’。没有则输出空字符串。" }, "motion_text": { "type": "string", "description": "到达该地点的移动路径描述，如‘穿过天桥左转’‘出了西门右拐’。用于辅助生成更准确的地址候选。" }, "intent": { "type": "string", "enum": ["search", "route", "share", "other"], "description": "用户的意图。search表示想找地点，route表示想问路线，share表示想分享位置。" } }, "required": ["address_text", "intent"] } } SYSTEM_PROMPT = """你是一个位置解析助手。用户会给你自然语言描述，你需要调用locate_place函数。 规则： 1. 如果用户消息中没有明确地点，但前一轮消息里出现过地点，可以补全到address_text中，并设置inherit_from_history为true。 2. 如果用户描述中包含参照物，一定要把参照物单独放进landmark_ref，不要把参照物和目标地点混在一起。 3. relative_position只放方位或距离描述，不要把整句话都堆进去。 4. 如果用户意图是问路线，请设置intent为route；如果只是找地点，设置intent为search。 """

接下来是geo.py。我这里用了一个最简单的本地模拟表，实际使用时替换成线上地图服务商的地理编码接口即可。重点是想展示“多候选地址”和“坐标纠偏”这两个逻辑。

# geo.py import requests # 本地模拟的地理编码函数，正式使用时替换为地图服务商接口 def geo_code(address): # 这里只做演示，实际需要换成地图服务商的地理编码API mock_db = { "某市人民公园": (35.12345, 116.67890), "某市人民公园西门": (35.12340, 116.67880), "某市人民公园西门对面小面馆": (35.12350, 116.67870), } return mock_db.get(address, (None, None)) def build_candidate_addresses(parsed): addr = parsed.get("address_text", "") landmark = parsed.get("landmark_ref", "") rel = parsed.get("relative_position", "") motion = parsed.get("motion_text", "") candidates = [] if addr and landmark and rel: candidates.append(f"某市{landmark}{rel}{addr}") candidates.append(f"某市{landmark}{addr}") if addr and landmark: candidates.append(f"某市{landmark}{addr}") if addr: candidates.append(f"某市{addr}") if landmark: candidates.append(f"某市{landmark}") # 去重并保持顺序 seen = set() return [c for c in candidates if not (c in seen or seen.add(c))] def normalize_coords(lat, lng): # 演示用的坐标纠偏，实际应根据地图服务商坐标系做转换 return lat, lng

geo_code里的模拟数据只是一个演示，真实场景需要对接地图服务商，并且返回的是城市里的真实坐标。build_candidate_addresses函数会生成多个候选地址，从完整到简化依次尝试。

然后是主流程main.py，负责调用大模型、解析函数参数、调地理编码并组装结果。

# main.py import json import requests from prompt import SYSTEM_PROMPT, FUNCTION_SCHEMA from geo import build_candidate_addresses, geo_code, normalize_coords # 这里替换成你的大模型服务商接口地址与密钥 LLM_API_URL = "https://your-llm-api.example.com/v1/chat/completions" LLM_API_KEY = "YOUR_API_KEY" def call_llm(messages): payload = { "model": "your-model-name", "messages": messages, "tools": [ { "type": "function", "function": FUNCTION_SCHEMA } ], "tool_choice": "auto", } headers = { "Content-Type": "application/json", "Authorization": f"Bearer {LLM_API_KEY}" } resp = requests.post(LLM_API_URL, headers=headers, json=payload, timeout=30) resp.raise_for_status() data = resp.json() return data["choices"][0]["message"] def parse_tool_call(message): # 大模型返回的tool_calls不是标准格式，这里做兼容处理 if not message.get("tool_calls"): return None tool_call = message["tool_calls"][0] if tool_call.get("type") != "function": return None func = tool_call.get("function") if func.get("name") != "locate_place": return None return json.loads(func.get("arguments", "{}")) def locate_by_text(text, history=None): messages = [] if history: messages.extend(history) messages.append({"role": "user", "content": text}) message = call_llm(messages) parsed = parse_tool_call(message) if not parsed: return { "success": False, "reason": "no_location_found", "raw_text": text } # 生成候选地址 candidates = build_candidate_addresses(parsed) best = None for candidate in candidates: lat, lng = geo_code(candidate) if lat and lng: best = { "candidate_address": candidate, "lat": lat, "lng": lng, "confidence": "high" if len(candidates) < 3 else "medium" } break if not best: # 如果所有候选地址都失败，降级返回城市中心坐标 city_lat, city_lng = geo_code("某市") best = { "candidate_address": None, "lat": city_lat, "lng": city_lng, "confidence": "low" } lat, lng = normalize_coords(best["lat"], best["lng"]) return { "success": True, "parsed": parsed, "best_result": best, "final_coords": {"lat": lat, "lng": lng} } if __name__ == "__main__": result = locate_by_text("我想去人民公园西门对面那家小面馆") print(json.dumps(result, ensure_ascii=False, indent=2))

这段代码第一步先调用大模型，拿到工具调用参数；第二步生成候选地址；第三步逐个地理编码；第四步兜底。整个流程不到一百行，但已经能处理不少常见场景。

4.3 跑通一次完整调用

拿“我想去人民公园西门对面那家小面馆”这句话测一下。理想情况下，大模型返回的arguments大致是：

{ "address_text": "小面馆", "landmark_ref": "人民公园西门", "relative_position": "对面", "motion_text": "", "intent": "route" }

然后build_candidate_addresses会生成：

某市人民公园西门对面小面馆 某市人民公园西门小面馆 某市小面馆 某市人民公园西门 某市人民公园

如果地图服务商能直接命中第一档，就直接返回坐标。如果第一档失败，会落到后面的候选。这里有个细节，某市小面馆这种候选太模糊，很多服务商返回的是“小面馆”附近的商圈中心坐标，而不是真实门店坐标。所以我会在评分时对候选顺序加一点业务权重，比如landmark_ref越具体权重越高，而不是机械地从前往后试。

我实际跑通后，最终返回的坐标基本能落在人民公园西门附近几百米范围内，对导航场景来说已经足够。如果对精度要求更高，下一步可以结合POI搜索接口，把address_text作为关键词，在参照物附近一定半径内做一次独立POI检索，这种方式对“小面馆”“奶茶店”这类泛行业词特别有效。

5. 常见问题与排查技巧

5.1 地点别名与简称的解析失败

口语化地名第一个大坑就是别名和简称。用户不会每次都说“人民公园”，他可能说“人民公园儿”“市公园”“老公园”。对于这种表达，模型虽然能理解它指的是同一个地方，但地理编码服务商不一定认识。

我在项目里加了一个“别名归一化”的前置步骤。做法是维护一张别名表，把常见口语别名映射到标准地址。比如“老公园”映射为“某市人民公园”，然后把映射后的标准名拼进候选地址。另外，这个别名表不是固定死的，我在上线后每隔一段时间会从用户的错误反馈里挖掘高频别名，人工确认后补进去。用大模型拆解文本时，我也会在系统提示词里加一条“如果用户使用了非正式地名，请在landmark_ref输出标准名，并把原始说法放在一个source_term字段里”。这样即使模型不认识别名，也能把原始说法传回去，方便下游搜索。

要注意的是，别名的地域性很强。同一个“公园”在不同城市可能指代完全不同，所以别名归一化一定要加上城市限定。我的做法是先由意图识别模块判断对话所在的城市上下文，再拉取对应城市的别名表。这个处理对多城市应用特别重要，否则很容易把A城市的“老公园”映射成B城市的地点。

5.2 多个同名地点怎么取舍

地理编码返回结果经常不是唯一的，比如“人民公园”在好几个区都有。如果用户在市级维度上搜索，代码返回的城市级坐标会直接定位到某一个特定公园，但对于用户来说可能是另外一个。

这个问题我一开始想得太简单，觉得让用户选就行。但实际体验中，让用户从列表里挑地点是个很重的交互，尤其在语音场景下更不现实。后来我改用“上下文优先”策略。如果对话历史里提到过某个区或某条路，就把它作为限定词加进候选地址，比如“某市老城区人民公园”。如果历史里没有任何限定，则按该地点的地图热度和坐标范围做排序，优先返回热度更高的那个，同时在返回结果里带上候选列表供必要时展示。

这个策略并不能做到百分百正确，但实际满意度提升很明显。关键点在于不要只返回一个结果，即使你很有把握，也建议把候选列表透出给上层。因为用户看到地图卡片后如果发现不对，至少能通过切换候选快速纠正，而不是重新输入一遍。

5.3 坐标偏移和不同坐标系

不同地图服务商使用的坐标系不完全一致，有的提供商做了加密处理，有的直接用国际标准坐标。我在项目初期没有关注这个问题，导致用户反馈“定位到海里去了”，后来才意识到主地图服务商和备选服务商用的是不同坐标系。

解决方案有两步。第一步是在模块入口统一约定内部坐标系，所有外部坐标进入系统后先转换成统一坐标系，再参与距离计算和存储。第二步是在地理编码接口返回时带上坐标系标识，比如coordinate_system=gcj02或wgs84，上层业务展示时再决定是否要转换。这个字段一定要透传，不要只在内部用一个裸的lat,lng。

坐标转换的算法本身不复杂，但涉及加密坐标的转换细节比较多。我的经验是直接用地图服务商官方提供的坐标转换接口，不要自己写，因为一旦写错很难排查。如果项目里一定要自己转换，建议对照多个已知点位做交叉验证，防止公式用错。

5.4 API配额、缓存与超时设置

大模型接口和地理编码接口都是付费服务，如果每次请求都实时调用，成本会非常可观。我在项目里加了两层缓存。

第一层是解析结果缓存。用户问过“人民公园西门对面小面馆”后，下次再有人问同样或类似的问题，直接查缓存，不再调用大模型。这里要注意，缓存键不能只存原文，因为口语化文本变化很大。我用的是“解析后字段指纹”，把address_text、landmark_ref、relative_position标准化后拼接成一个字符串作为键，这样“人民公园西门对面小面馆”和“人民公园西门对面的小面馆”能命中同一条缓存。

第二层是地理编码结果缓存。同一个候选地址多次编码的结果完全一样，所以在地理编码接口外面再加一层LRU内存缓存，减少对地图服务商的请求量。同时设置合理的TTL，因为POI数据可能会有变动，我设置了7天过期。

超时设置也很重要。大模型函数调用如果耗时太长，地图侧的用户等待体验会很差。我统一把大模型调用超时设为10秒，地理编码设为5秒。并且加了熔断机制，如果地图服务商连续失败5次，就自动切换到备用服务商，避免因为某一个外部服务抖动导致整个接口不可用。

6. 一些踩坑之后的个人体会

做lingbot-map这段时间，我最大的感受是：这类“语言转空间”的模块，真正决定上限的不是模型多聪明，而是工程上怎么用聪明的模型。函数调用给出的结构化结果再漂亮，落到地图坐标时依然要面对地名歧义、坐标偏移、外部依赖不稳定这些老问题。与其追求一次解析百分百准确，不如把容错机制做扎实，让系统在不确定时依然能用降级策略给出“大概方向”。

另外，日志和数据回流真的值得做。我一开始觉得只要接口能返回结果就行，后来遇到一个用户反复报错：他说“老粮库后门”，每次解析出来都是“老粮库”，地理编码全部失败。后来把这类失败样本收集起来分析，才发现他说的“老粮库”其实是城市另一头的一个已经拆掉的旧地标。如果只是看日志里的成功率和平均耗时，这个问题根本不会被发现。所以建议每个定位请求都记录下原始文本、解析字段、候选地址、实际返回坐标、置信度，为后续调优留足素材。

还有一个小技巧：尽量让上游业务把坐标和文本结果一起展示，而不是只给坐标。因为用户对“你理解得对不对”的判断是即时的，把解析出的“小面馆”“人民公园西门”“对面”这些字段回显出来，用户一眼就知道系统有没有听懂，比事后定位错了再反馈要方便得多。这也是我觉得lingbot-map这个模块最值得推荐给所有做地图助手的朋友的一个经验。