口径说明：以上数量为项目记录口径。94 条目的地与 139 条活动的核验范围不同——前者 100% 实地核验，后者只记录数量、未逐条实地核验。数据覆盖范围为南京栖霞区部分街道，不代表全市或更大范围。其余数量（71 条不推荐黑榜、93 条双源坐标核验、22 篇研发文档）见 Part 3，均不公开条目明细。

Part 1诉求定位：家长要的不是地点清单，而是方案

结论：传统产品把筛选任务留给用户；我们尝试直接给出当下情境下的活动方案。

首版的取舍

核心交互：地点列表 vs 方案引擎

同一个需求，两种产品形态下用户要走的路径。

说明：这里只说明两种形态下用户动作的差别，不声称已验证用户效率提升——0.1 没有推广，没有可用的行为数据。

产品截图

Part 2关键决策：规则决定推荐结果，AI 负责把理由说清楚

结论：不让模型直接决定事实性结果。事实由规则算，语言交给模型。

两条路径分开看：离线建标签，在线出结果

点击节点，看每一层负责什么、不负责什么

节点上的小字是这一层的一句话职责；点开是三行边界说明。

被否决的方案

否决为什么不让模型直接生成地点和结果？

问题

模型生成的地点可能不存在、营业时间可能是编的、距离可能是拍的。用户按这个结果出门，错一次就不再用了。

判断

这类事实错误没法靠 prompt 约束住，也没法验收——你没法为“模型今天没说错”写一条断言。

否决为什么不用纯规则模板覆盖所有推荐文案？

问题

模板写死了句式，推荐理由读起来像表单回填：“距离 3.2 公里，适龄 5–8 岁。”信息都对，但不像人在解释。

判断

推荐理由的作用是帮用户下决心。表达僵硬，等于把这个作用丢掉了。

取舍当前方案：规则保事实，AI 改表达

边界

这套分工降低的是“事实出错”的风险，提高的是可控性。它不等于彻底消除模型出错的可能——文案仍然可能说得不准确、不通顺，所以仍然需要人工复核口径和降级路径。

工程补充

待核模型、成本与降级机制

模型

GLM-4-Flash（是否对外披露模型名待确认）。

成本

项目记录约 ¥0.1 / 百万 tokens，云端响应约 3.5 秒。这不是用户价值指标，只作为工程成本参考。

机制

Prompt 做版本化管理；降级为三级路径。

Part 3数据质量：推荐质量取决于数据真实、覆盖完整、字段能支撑决策

结论：推荐质量不仅靠算法，更靠数据底座。规则再准，喂进去的数据错了，结果就是错得很有条理。

四个检查项：数据要在哪几个方向上过关

点击查看对应的设计办法与真实问题案例。

三个真实问题与修正

这三个都是实际踩到的坑，不是设想。

案例 01系统性漏采：不是抓错了，是整类没抓到

发现

某类运动健身数据在地点库里系统性缺失，不是零星几条，是整类没有。

原因

采集接口按名称模糊匹配，搜索词用的是类型词。类型词选窄了，整类数据就永远进不来。

收获

数据覆盖度必须作为独立检查维度。只校验“已经抓到的条目对不对”，永远发现不了“该有的没抓到”。

案例 02坐标错挂：同一个地方，两条坐标差 1.7 公里

发现

同一地点在地图数据源中出现重复记录，其中一条坐标偏差约 1.7 公里。

原因

单一来源自校验不足。重复记录之间不互相校验，偏差就这么留下了。

收获

改为双源交叉验证，单源不采信。1.7 公里在城市里足以把用户导到一个完全不相干的地方。

说明

本页不展示具体地点与坐标。

案例 03静默降级：系统挂了，看起来像算法错了

发现

云函数不可用时，系统没有报错，而是悄悄回退到模拟数据。表面看就是“推荐结果变怪了”。

原因

降级逻辑只保证“页面上有结果”，没区分“这个结果是不是真的”。

收获

系统不可用必须明确暴露，不能以假结果伪装成功。否则排查方向从一开始就是错的——你会去查算法，而问题在服务。

Part 4交付与复盘

结论：产品判断不能停留在文档里，要变成可实现、可检查、可回归的规则。

本人职责

• 产品定义、用户场景研究与竞品分析；
• 决策数据结构与字段口径（目的地 / 活动 / 不推荐黑榜）；
• 推荐规则设计：硬条件、候选收敛、距离计算、排序权重；
• AI 能力边界设计：离线打标口径、在线表达约束、降级策略；
• 交互与视觉设计；
• 验收与发布交付：回归断言、真机走查、平台准入。

技术实现由 AI 协作完成；本人负责把需求与产品判断写成明确的数据口径、规则和验收条件，并判断交付结果是否符合预期。

交付链路：从判断到发布检查

点击节点查看脱敏示例。不展示源代码、密钥或可定位真实地点的数据。