一个拒绝给答案的礼仪地图，凭什么让人信？

在日本该不该给小费？意大利人午饭后点卡布奇诺会不会被白眼？挪威的公交上，挨着陌生人坐下算不算冒犯？

每一个旅行指南都会给你一个答案，而且通常只来自一个作者的个人判断。有一个项目偏不这么干——它的数据库里，压根没有"结论"这个字段。

它叫 Faux Pas Atlas，一个礼仪地图。它回答的问题只有一个：在这里，这样做算失礼吗？但它自己不回答，它让当地人投票。

一条主张，三种态度

在这个系统里，一条"主张"由三个要素构成：一个行为、一个地点、一个具体场景。任何人都能一键表态——失礼、没问题、看情况，同时说明自己对这个地方的了解程度。

权重规则很直接：本地人算双倍，游客算一半。

一条主张要被判定为"已定论"，需要满足三个条件：至少五个人作答，其中三人是本地人，且加权后的声音里有 70% 达成一致。如果本地人之间本身就吵不出结果，网站不会替他们选边，而是把这个分歧原样展示出来。

已定论的主张也不是终点。任何人都可以书面提出异议，由管理员裁决，结果只有三种：维持、拆分成更窄的主张、或者作废。

场景不同，答案就是两条主张

数据结构里有七种文档类型：地点、场景、主张、证言、异议、裁决、证明人。其中有两处是刻意留白的。

第一处是场景拆分被当成一等公民处理。"见面亲吻在社交场合没问题、在商务场合失礼"，这不是一条主张加一句备注，而是两条共享同一个父级的主张。作废的主张也不会被删除，连同它的完整历史一起留在数据集里。

第二处就是那个缺席的结论字段。整个数据库里没有任何地方可以让人直接填"正确答案"。

对访客来说，最上手的入口是一个测验：你能在葡萄牙的饭局上活下来吗？十道题，全部由当地人已经定论的主张生成，复盘页面会告诉你每个答案是谁说的、有多少人这么说。

正方：没有结论字段，才是唯一诚实的做法

这个项目的作者给出的理由很干脆。挑战赛的命题是"一个它承担不起答错的答案"，而他的理解是：唯一诚实的确保方式，就是永远不自己敲下那个答案。

礼仪这件事的麻烦在于，它天然是地方性的、分层的、会变的。一个外地作者写下的判断，无论多用心，都是把复杂现实压成一句话。而把判断权交给足够多的当地人，并且把"本地人算双倍"写进权重里，至少让结论有了可追溯的来源。

更关键的是，当本地人自己都不同意时，系统选择展示分裂而不是掩盖分裂。这比一个斩钉截铁的答案更接近真实。

反方：投票出来的共识，也可能只是多数人的习惯

但加权投票本身也有它的问题。70% 这个阈值、本地人双倍游客一半的权重，都是人为设定的规则，不是从现实里推导出来的真理。

而且"本地人"这个身份本身怎么界定？系统里靠的是作答者自述自己对这个地方的了解程度。这意味着权重的基础是自我声明，而不是可验证的事实。

还有一层：五个人、三个本地人就能让一条主张"定论"。对于一个人口千万的城市来说，这个样本量说明不了太多。系统用异议机制和裁决流程来兜底，但兜底的前提是有人愿意去提异议。

我的判断

这个项目的价值不在于它给出了多少正确答案，而在于它把"谁有资格下判断"这件事变成了产品结构本身。

结论字段的缺席不是偷懒，是一个明确的设计立场：判断权归当地人，平台只负责记录、加权、展示分歧、处理争议。这个立场能不能站得住，取决于参与的人够不够多、够不够分散——而这恰恰是它目前最不确定的地方。

对做产品的人来说，更值得看的是它的实现路径。整个项目跑在免费套餐上，用 Claude Code 在 VS Code 里配合 Fable 5.1 模型完成，核心开发时间是 9 月 20 日和 21 日两天，之后是打磨。

第一天完全没有写代码。作者先做了两个决定：一是要一个"没人被允许输入答案"的应用，二是要用上 App SDK 和 Workflows 两个加分功能——因为一个面向管理员的定制审核应用，本来就是这类想法的自然形态。定完方向之后，才让模型去读挑战页面、已有参赛作品、Sanity 文档索引、定价页和工作流插件的 README，把这些写进 CLAUDE.md。

有个细节值得一提：作者没有在 Studio 界面里配置工作流，而是让模型直接读工作流插件打包后的 schema 和 workflow-kit 的查询语句，搞清楚文档的确切结构，然后用脚本种下两条工作流定义。这样做的结果是，后来自动函数和管理员应用能写进同一条审计轨迹。

还有一个失败的检查点。第四阶段的验收标准是"在面板里裁决一条异议，看着线上站点更新"。模型把它变成了一个脚本：用面板完全相同的操作提交裁决，然后轮询线上页面。它失败了——主张已经作废，Sanity 的 CDN 也确认了，但站点还在继续提供那个页面，持续了好几分钟。

作者对这个失败的评价是：一个失败的检查点，比一个通过的检查点更有价值。