你问”这个项目用什么数据库最好？“，得到一个听着挺自信的选择。同一个 prompt 跑三次，得到三个不同的”最好”。每个都有合理理由，但理由全都跟你的真实项目无关。
最快的修法： 别再问”最好”。改成”在某个指定维度上、给定一个阈值下最好”。把 "哪个数据库最好？" 换成 "哪个数据库最便宜，同时能撑住 1 万写/分钟、p99 读延迟低于 100ms，负载是 90/10 读写、共 100GB？"。维度（最便宜）、约束（p99 < 100ms）和负载，把那个让你每次得到不同答案的模糊性直接消掉。
模型并没有出故障。“最好”没有维度、没有权重、没有 tie-breaker，就会塌缩到训练数据里”最好的 X”这个短语正向关联最强的那个选项，而它往往偏向模型训练时正流行的东西。更麻烦的是，托管 LLM 推理即使在 temperature 0 下也不是逐字节可复现的：概率采样加上浮点 batch 效应，会让同一个 prompt 在不同 run 之间漂移（参见 Thinking Machines：Defeating Nondeterminism in LLM Inference）。所以一个模糊的”最好” prompt 是双重不稳定。修法是去掉模型被迫去猜的那部分模糊性，而不是去追一个 API 根本给不了的确定性。
你属于哪一类？
| 症状 | 大概原因 | 看哪步 |
|---|---|---|
| Prompt 里没有”最便宜 / 最快 / 最稳”这类词 | 没指定维度 | Step 1 |
| 你列了 2 个以上目标（“又快又便宜又好维护”）但没排序 | 多标准、无权重 | Step 2 |
| 模型选了 AWS / OpenAI / Stripe，但你的数据并不支持 | 没说要忽略什么 | Step 3 |
| 重跑时赢家在 top 2-3 里来回换 | 没有 tie-breaker | Step 4 |
| 同一个 prompt 在新对话里选不同 | 前面轮次带进来的隐性标准 | Step 5 |
常见原因
1. 没指定维度
“最好”是沿哪个维度？成本、延迟、可扩展性、团队熟悉度？你没说。模型就自己挑一个它”喜欢”的，通常是训练数据里情感最强的那个。
如何判断： 你的 prompt 里没有维度词（最便宜、最快、最稳）。
2. 多标准、无权重
你列了多个标准——“要又快又便宜又好维护”——但没说哪个最重要。模型就选先验里情感最强的那条。
如何判断： 列了 2 个以上标准，但没有顺序、没有权重。
3. 没说要忽略什么
如果你不写”忽略厂商品牌口碑”或”忽略热度”，这些因素就会悄悄主导。品牌识别度是一个很大的隐性权重。
如何判断： 模型选了一个”通用最受欢迎”的选项（AWS、OpenAI、Stripe、Postgres），但你的输入数据并不支持。
4. 没有 tie-breaker
当两个选项分数接近时，模型会挑先被提到的那个，或训练数据里出现更多的那个。这基本上是随机的，而且因为托管推理即使在低温下也不确定，所以每次 run 还会变。
如何判断： 重跑这个 prompt，赢家在 top 2-3 里换来换去。
5. 前面轮次带进来的隐性标准
在长对话里，前面某一轮立了一个框架（“我们看重成本”），你忘了。模型在判断”最好”时还在按它锚定。
如何判断： 同一个 prompt 放到新对话里，选出的结果不一样。
动手前先确认
- 写下你真正关心的那一个维度。
- 如果是多个，给它们排序并分配粗略权重，加起来等于 100%。
- 想清楚你要让模型忽略哪些因素。
- 决定你的 tie-breaker 规则。
- 经常做的决策，把这些存成一份可复用的 rubric。
需要收集的信息
- 带”最好”的当前 prompt。
- 3 次独立 run 的输出（用新对话，避免前面轮次串进来）。
- 你真实的项目上下文（负载、约束、团队）。
- 你认为”对”的历史决策，以及为什么对。
- 用的模型，以及在生效的任何 system prompt。
最短修复路径
Step 1：把”最好”换成”在[维度]上最好”
差： "这个项目用什么数据库最好？"
好： "哪个数据库最便宜，同时能撑住 1 万写/分钟、
p99 读延迟低于 100ms？负载：90% 读、10% 写，
平均 3kb 行，共 100GB。"维度（最便宜）、阈值（1 万写/分钟、p99 < 100ms）和负载规格，把那个导致 run 与 run 之间漂移的模糊性消掉。
Step 2：用带权重的 rubric
针对多标准决策。好的 rubric 标准应该具体、可度量、彼此独立（不要有两条在量同一个东西），权重加起来等于 100%：
带权重的标准：
- 成本：40%（越低越好；硬上限 300 美元/月）
- p99 读延迟：30%（越低越好；硬上限 100ms）
- 团队熟悉度：20%（1=从没用过，5=每天用）
- 维护负担：10%（1=托管服务，5=自托管）
对每个选项：
1. 每条标准打 1-5 分。
2. 每个分数乘以它的权重。
3. 求和得到总分。
4. 选总分最高的。
5. 把完整打分表展示出来，让我能自己复算。这逼出显式推理，模型没法躲在一句自信的话后面。这跟团队做 rubric-based LLM 评测是同一套结构：列出正交维度、给权重、逐条打分。
Step 3：声明要忽略什么
评估时忽略：
- 厂商品牌口碑和整体热度。
- 这个选项在 HN/Reddit 帖子里有没有被提到。
- 训练数据时效偏好（别默认偏向最新的那个）。
- 营销话术；只用文档化的限额和公开定价。显式声明要忽略的因素，防止它们作为隐性权重溜进来。
Step 4：声明 tie-breaker
Tie-breaker（当 top 2 总分相差 ≤ 0.3 时启用）：
1. 优先团队里有最资深贡献者的那个。
2. 还平就优先 track record 更长的那个。
3. 还平就两个都返回，并各加一行说明取舍。写下来的 tie-breaker，正是让一个接近的判断变得可复现、而不是抛硬币的关键。
Step 5：把 trade-off 当成答案的一部分
对选出的选项列出：
- 2 件这个选择比 runner-up 更差的事
- 1 件以后被迫切换时会失去的东西
- 1 个可能改变答案的未知数Trade-off 把”最好”和”在我们约束下最好”区分开。
Step 6：建一份可复用的 rubric 文件
经常做的决策（选厂商、选库、选架构模式），把 rubric 存成文件。每个新决策复用同一份 rubric、只换选项，这样标准和权重在不同决策之间、不同同事之间都保持稳定。
怎么确认已经修好
- 打分表可复现：你能手算总分，得到同一个赢家。
- 同一个 prompt 跑 3 次选出同一个结果（rubric 把数学固定下来后，run 之间的细微措辞漂移不再改变赢家）。
- Trade-off 列表里是具体弱点，不是 vibe。
- 同事用同一份 rubric 得到同一个结论。
- 决策可以书面辩护，不用再去问模型。
注意：如果你需要的是 run 之间逐字节相同的模型输出，rubric 依然是赢的，因为它锁的是决策、不是文字。托管 API 即使固定 seed 和 temperature 0 也保证不了输出文字一致——OpenAI 的 seed 是 best-effort 的，而且绑定一个会在他们更新基础设施时变化的 system_fingerprint（参见 OpenAI Cookbook：reproducible outputs），而 Anthropic 的 API 根本没有 seed 参数，所以 Claude 的输出即使在 temperature 0 下也不确定。
如果还是没修好
- 标准可能还是太虚——给每条加上单位和上限，尽量量化。
- 加 1-2 个过往决策的工作示例，连同它们的打分，把分数刻度锚住。
- 涉及敏感或私有上下文的决策，模型可能根本没有这份数据——直接内联给它。
- 有些决策确实没有唯一”最好”。正确答案是”top 3 里任选一个都行，取舍如下”，而一份好的 rubric 会把它呈现成一个接近的平局，而不是造一个假赢家。
FAQ
为什么同一个 prompt 我每次跑都得到不同的”最好”？
两个原因叠在一起。第一，“最好”没有维度，模型只能猜你在乎哪条标准，而它每次猜的不一样。第二，托管 LLM 推理即使在 temperature 0 下也不确定，因为有概率采样和浮点 batch 效应，所以答案会 run 与 run 之间漂移。带权重的 rubric 修掉第一个原因，并让第二个原因不再影响最终选择。
把 temperature 设成 0 能让答案可复现吗？
不能。temperature 0 减少但不消除波动。同一个 prompt 仍然可能在不同 run、不同 GPU 类型上产出不同 token。用 rubric 去锁决策，而不是去锁文字。
一份 rubric 该有几条标准？ 通常 3 到 5 条。少于 3 条，“最好”几乎没比之前更明确；多于 6 条，权重就变得很噪、标准之间开始互相重复计数。保持每条标准独立、可度量，权重加起来等于 100%。
如果我还不知道权重该怎么定？ 先让模型提一份 rubric（“为这个负载下选数据库，提 4 条带权重的标准”），然后在问选择之前，把权重改成你真正看重的那样。rubric 由你审、由你拍板；模型只是起草。
直接让模型”客观一点”行不行？ 不行。“客观一点”又是一条没定义的指令。决策里的客观性来自一份带权重和 tie-breaker 的书面 rubric，而不是一句模型可以无视的客套话。
预防建议
- 默认：发出去之前，把每个”最好” prompt 都翻成带权重的 rubric。
- 每类决策建一份 rubric 文件（厂商、架构、库、工具）。
- 团队决策，先商定 rubric 再跑 prompt。
- 每月审一遍”最好”决策：是否可复现？不能就说明 rubric 缺一条标准或一个 tie-breaker。
- 写作反射：把”最好 / 最 / top”全换成维度具体的语言。
- 不确定时，先让模型提案一份 rubric，审过、采纳之后再问选择。