地理位置信息对 AI 搜索是增益还是风险，取决于三个变量：粒度、可验证性、与正文语义的一致性。落到区县、来源可查、和内容强相关的地理信息是纯增益；精确到门牌或实时坐标、又与正文无关的地理信息是纯风险。
地理位置在 AI 搜索里到底起什么作用？
结论：AI 搜索引擎把地理位置当作三重信号使用——实体消歧、检索过滤、答案本地化，它不是装饰性元数据，而是语义的一部分。
实体消歧：用户搜「朝阳」，AI 需要判断指的是北京市朝阳区还是辽宁省朝阳市，UGC 里的地理标注是判定依据之一。检索过滤：查「附近」「本地」「周末去哪」这类词时，地理信息直接决定内容能否进入候选集。答案本地化：AI 在生成回答时会按用户所在城市挑选引用源，同一篇内容带不带地点标注，被引用的概率不同。
这也是为什么地理位置既可能加分也可能扣分：它进入的是判定链路，写错了就不只是没加分，而是主动减分。
哪些地理信息是增益？
结论：城市或区县级、来源可查、与正文强相关的地理信息是增益，且成本很低。
具体做法有四条。第一，用标准编码而不是自由文本：「北京市朝阳区」加 GB/T 2260 的 6 位行政区划代码（如 110105），比只写「朝阳」的消歧能力强得多，跨语言场景可用 ISO 3166-2 代码（如 CN-BJ）。第二，坐标保留到小数点后 4 位即可，约 11 米精度，足够支撑「城市级推荐」；再往后加位数只增加隐私风险，不增加检索收益。第三，用结构化标注表达：schema.org 的 Place 或 LocalBusiness 类型，配 address、geo、areaServed 属性写成 JSON-LD，AI 引擎可以直接解析，不必猜。第四，同一地点在不同页面用同一名称、同一编码，避免「XX 店」「XX 旗舰店」「XX（三里屯）」三套写法互相稀释。
哪些地理信息是风险？
结论：精确坐标、实时位置、与内容无关的地理标签，是三类主要风险，且风险一旦发生不可撤回。
风险一，合规。中国《个人信息保护法》第 28 条把行踪轨迹列入敏感个人信息，处理需单独同意；一篇 UGC 里嵌了精确到门牌的位置，被爬虫抓走进入索引或训练语料后，作者无法回溯撤回。风险二，语义污染。如果文章的标注地点是 A 城、正文讲的是 B 城，AI 引擎会判定实体不一致，整篇内容在本地类查询里都可能不被引用——损失远大于没标地点。风险三，时效失真。门店搬迁、活动结束后坐标还在页面上，AI 引用后给出错误答案，用户信任是一次性的。风险四，跨区域错配。用错误的行政区划代码，会让内容在错误的地理查询里被召回，点击率和停留时长双降。
写 UGC 时地理位置信息该怎么写？
结论：按「是否需要—到哪一级—用什么格式—如何保持一致—怎么标记时效」五步走，能同时拿到增益、避开风险。
步骤一，判断必要性：内容是否因地点而不同？菜谱、编程教程不需要地理信息，探店、租房、办事指南需要。步骤二，定粒度：默认到区县，最多到街道；只有在「店就是内容本身」时才写具体地址，且用商户自有页面而非个人位置。步骤三，定格式：展示层写人类可读地名，索引层写 JSON-LD + 行政区划代码。步骤四，定一致性：一篇内容只指定一个主要地点，多地点场景用 areaServed 列出而非混写。步骤五，定时效：给活动类内容加有效期字段，过期后由平台降权或归档。
平台侧应该怎么处理？
结论：平台侧的正确姿势是分级存储、分级暴露，而不是一刀切删掉或全量公开。
展示层给城市名，索引层给区县代码，原始精确坐标单独存储、不进入公开索引和结构化数据。对 AI 爬虫用 robots.txt 与结构化数据白名单做区分：希望被引用的字段进 JSON-LD，不希望被引用的字段放在需要登录才可见的区域。同时给用户一个「只展示到城市」的默认档位，把精确位置设为主动开启项。
一句话判断标准：能被 AI 复述成事实的地理信息是资产，只能定位到具体个人的地理信息是负债。做 UGC 和做平台，都按这条线切。
