你没法用单元测试来测品味

原文来源：Karl Tryggvason Blog — 一位独立开发者用 LLM 为跑步 App 处理 72 万个兴趣点后对 AI 能力的思考。

Karl Tryggvason 在做一个叫 In the Long Run 的跑步 App——用户在虚拟路线上跑步，在知名路线上累积里程。他想在地图上沿途标注兴趣点（POI）：历史遗迹、自然景观、城堡……问题是他对冰岛以外的路线完全不熟。

他的直觉反应和很多人一样：让 AI 来做。但最终的故事远没有"AI 一键解决"那么简单。

从 1300 万数据到 72 万 POI

他用了 GeoNames 开源地理数据库（Creative Commons 许可），初始数据量是 1300 万条记录。经过筛选——排除行政区域、只保留特定特征码（公园、城堡、纪念碑、山脉等）、通过人口和海拔过滤——最终得到 72.5 万个高质量兴趣点。

技术栈很简单：Python + Apache Parquet + DuckDB。用 Claude Code 来辅助编写数据处理代码。

匹配冰岛环岛路线的结果很满意：1321 公里路线产生 511 个 POI。但处理美国 66 号公路时暴露了一个严重问题——英语 Wikipedia 偏见。3787 公里的路线匹配到 14181 个 POI，因为美国每个小镇在 Wikipedia 上都有一条记录，导致兴趣点过于密集。

这个问题没有简单的算法解法。你要的不是"中立"的 POI 覆盖——你要的是有品味的筛选：知道什么值得看，什么可以跳过。而这正好是单元测试无法表达的东西。

—— 广告 ——

Karl 尝试让 LLM（Anthropic Haiku）为 POI 写增强描述。结果出现了典型幻觉：

他尝试在提示词中加入位置元数据来约束，效果有所改善，但始终无法彻底解决。最终他做了一个务实的选择：用 Wikipedia 原文，而不是 LLM 生成的文本。正确性比文采更重要。

但 Karl 发现 LLM 在另一个角色上非常出色——为 POI 打重要性分数。结合特征码、Wikipedia 语言计数（多语言维基条目数作为流行度信号），LLM 能有效区分"值得看的"和"不太值得停的"。

The LLM lies but it does have taste.

这是一个深刻的观察。LLM 生成事实内容时不可靠，但在做主观判断（"这个比那个更有意思"）时却表现出色。

整篇文章的标题点出了最根本的问题：你没法为品味写单元测试。

每条路线差异太大——文化型、自然型、历史型路线各自有不同的评判标准。城市密集的路线会退化成人口密度图——POI 集中在城市聚集区。

解决方案是每条路线单独调参：人口过滤阈值、特征码权重、LLM 评分权重、地理分布滤波……但这一切都没有一个"对"的答案。没有 ground truth。没有红/绿测试来验证品味。

Karl 的应对方式是构建 Leaflet 可视化工具 + DuckDB SQL 查询来人工抽查。这是一种"视觉健全性检查"——你只能用眼睛来判断结果好不好。

I initially thought AI would be the feature, but it ended up merely in a supporting role alongside other signals and data processing mainstays.

这是整篇文章最值得反复读的一句话。当 Karl 开始做这个项目时，他以为 AI 会是核心特性。但最终 AI 只是众多信号之一，和其他传统数据处理方式并肩作战。

具体来说：GeoNames 特征码做第一层粗筛 → Wikipedia 链接做流行度信号 → 语言计数消除语言偏见 → LLM 评分做最后一层提亮。没有哪个环节是独当一面的，但加在一起效果很好。

对独立开发者来说，这个案例的启示是：别把 AI 当银弹。它在你最熟悉、对你最不需要它的领域表现最好。它适合当你对问题有直觉判断力、只是需要加速完成时作为辅助工具。当你自己对结果都没有把握时，AI 也不会给你正确答案。

Karl 在文章中通篇使用"我们"（we），因为 Claude Code 在项目中确实像一个协作者。但他强调责任完全在自己：当代码出错时，是他没有审查到位。

他将其称为"新型代词争论"——在 AI 协作时代，"我们"到底指谁？这是个值得每个开发者思考的问题。