一个跑步 app 写不下去的 bug
Karl Tryggvason 写了一个叫 In the Long Run 的 app，让跑者把 Strava 上的累计里程投射到虚拟世界地图上。他想把地图变得有意思：路过的城市、景点、历史遗址，能讲出一段小故事。
问题来了。这些 POI（兴趣点）他一个都不熟。一条横穿欧洲的路线，几千公里、上百个点，他没去过绝大多数地方。
他想找数据源，找了一圈，没找到合适的。于是让 AI 来填。结果列出来的第一个版本是一堆博物馆，每个城市挑一座博物馆写一段简介。
他看了一遍，发现一个他写不出测试的 bug：
这些博物馆里有一些是真无聊。
不是错，不是 hallucination，不是拼写错误，也不是"中国城市的博物馆被列成了法国"。每一条都"对的"。但"哪条 POI 值得停在地图上多看一眼"这个判断，他没法用任何脚本验证。
“对不对"和"好不好”，不是一回事
程序员习惯的事：写函数、写测试、跑 CI。代码好不好，至少在大部分公司里是有客观信号的——编译过不过、测试通不通、覆盖率到没到、性能预算超没超。
Karl 这件事特别的地方是：AI 给的结果在所有可观测信号上都是绿的。语法对、信息对、长度对、调性对。但它就是无聊。
他想给"无聊"写一个测试。在脑海里试了几种角度：
- 检查 POI 描述里有没有出现"值得一去"、“不可错过"这种短语 → AI 学会绕过关键词
- 检查句子长度是否方差够大 → 写个规则让模型轮换句式，分分钟被绕过
- 让另一个 LLM 当评委打分 → 评委的品味也只是训练分布的均值，评不出这个项目需要的"判断”
每一种"自动测品味"的尝试，最后都是另一个 LLM 在模仿品味。模仿不是品味。
为什么 GitHub 月榜同时在涨两个 skill
雷达里另一条线几乎同时在发生：
Leonxlnx/taste-skill在 GitHub 月榜第 11，月增 31,799 stars（仓库总星 51,053）。它的描述是「gives your AI good taste. stops the AI from generating boring, generic slop」。hardikpandya/stop-slop月榜第 18，月增 8,227 stars（总星 12,462）。它做的是「a skill file for removing AI tells from prose」。
两个工具加起来 63k+ stars，做的是同一件事：把品味打包成可调用的资源，让 prompt 不再裸奔。
这两件事和 Karl 的故事不矛盾，反而互相印证：
- 工具层在做的是「让 AI 不那么平均」——给它样式、给它禁词、给它偏好。
- 文章层承认的是「有些事只能人来」，当工具用尽，剩下的判断权还是得回到人手里。
stop-slop 解决了"AI 风的句子太像"的问题，但它解决不了"这个 POI 是不是有意思"的问题。后者是领域知识 + 个人偏好 + 项目调性的组合，没有训练样本能直接覆盖。
三件没法自动测的事
把 Karl 的故事外推一层，今天的开发者社区其实在同时面对三种"测不了"的判断：
1. 品味判断：这个东西好不好、值不值得、跟其他候选比有什么不同。taste-skill 月增 31k 说明需求量极大，但仓库本身也承认它"stops the AI from generating boring, generic slop"，挡住的是"无聊"，挡不住"恰好适合这个项目"。
2. 价值判断：这条信息要不要给用户看、这个按钮该不该放这个位置、这个流程是不是把人当成工具。这些没有 ground truth，只有"在这个产品里、给这群用户、在这个上下文里"才成立的判断。
3. 责任判断：这个改动上线会不会有人受伤、这段代码十年后谁来维护、这个决定做下去团队是否还能回头。前两类靠判断力，第三类靠"愿意为后果负责的人"。
CI 跑不了这三类。code review 跑不了这三类。LLM-as-judge 也跑不了这三类，因为裁判员也是模型。
工具用尽以后，剩下的是人
回到 Karl 的故事。他最后怎么解决的？
他没有再找新工具，没有再调 prompt 模板，也没有换更大的模型。他找了几个真跑过这些路线的人，请他们手动挑 POI。他要的是"有人愿意为自己挑的东西负责"，不是"有一套规则能筛出好东西"。
AI 在这件事里的角色是：替他不熟的领域起草、聚合、初筛。但最后一关必须是个人，一个愿意说"这条不感兴趣，换一条"的人。
这就是「You can’t unit test for taste」真正想说的：AI 时代不缺能力，缺愿意承担判断责任的人。
工具可以帮你列一万个选项。选哪一个、为什么选、不选的那九千九百九十九个怎么处理，这些测试覆盖不到。
给写代码的人和用 AI 的人各一句话
给工程师：当你说"这个 PR 我要 review"的时候，你 review 的不是 bug 数量，是「这个改动是不是有人在乎」。如果审完之后 PR 跟 AI 自己 merge 没区别，那 review 环节形同虚设。
给产品 / 内容 / 任何用 AI 的人：当 AI 给出"对"的结果，记得追一句"为什么是这个而不是另一个"。能回答清楚的判断，是品味；回答不清楚的，要么是工具该升级，要么是该换个负责判断的人。
Karl 的故事之所以在 HN 拿到 254 分、117 条评论（截至 6/26 11:00），是因为它戳中了一件事：大家都在拼命让 AI 像人，但没人愿意承认，最像人的那部分，愿意为"这个不好玩"负责，目前还是 AI 给不了的。
stop-slop 月增 8k，taste-skill 月增 31k，这两个数加在一起，说明大家不只是在抱怨 AI 写得像 AI。大家在想办法。但工具能补的部分有上限，剩下的部分，会一直是稀缺品。