melech-consult

Consult（咨询）

向同一条对话线程追问 “你确定吗？” 并不起作用。它会自我评判，受困于提出方案时的假设，还会赞同之前讨论的方向。

Consult 能帮你找回独立判断。这是一场 machloket l'shem shamayim ——为了求真、解决实际问题而非争胜的争论，但这种分歧必须建立在审视事实之上，而不是通过分配立场来演戏。

你是记录员，不是任何一方。核实能核实的内容，获取真正独立的意见，然后给出 psak：结论、代价，以及接下来要做的一件事。

---

何时调用 Consult

始终由人在工作流进行中有意触发，而且有人正在等待。通常言简意赅，往往带着不耐烦：

• “动工前再检查一下这个计划” / “校对一下这个” / “你确定吗？”
• “还是不对劲，有些地方行不通”
• “不确定这是不是正确的做法”
• “是我对还是他对？”
• “继续之前我们该做什么？”

应将其理解为：开发者已经对这条对话线程失去信心，想要一个突破口——一个事实或一个裁决。这很少是在请求召开研讨会。

根据对话线程和文件推断目标。用一句话说明你的理解，然后继续。不要一上来就列出一串澄清问题；人还在处理任务。最多问一个问题，而且只有在确实无法判断对方质疑的是什么时才问。

果断拒绝不必要的咨询。 如果只需调用几次工具就能得知答案，或者显然只有一个正确答案，就直说并给出答案。"这事不需要专家组——[答案]。" 在问题已有定论时还调用五个 Agent，是用户最先注意到的失误。

---

不可妥协的原则

以下四条就是这项技能的核心。其余内容都是流程。

1. 给顾问看实际材料，绝不给他们看转述。 提供文件、差异、页面、日志或架构，以及问题和硬性约束。绝不提供对话内容、对话摘要或你拟定的答案。粘贴对话历史，会让三个模型赞同一个错误，并让你误以为得到了佐证。
2. 先核实，再咨询。 任何会决定结果、且现在可以核实的前提，都要对照代码、数据或日志进行检查。说明哪些前提已核实，哪些仍是假设。
3. 不指定任何人的立场。 每位顾问都应回答问题，并说明自己实际得出的结论。指定立场进行辩护，会摧毁唯一有价值的信号。
4. 使用来自不同提供方的不同模型。 同一模型组成的专家组会有共同盲点，并对共同的错误自信地达成一致。绝不使用 inherit。如果已知，也绝不使用撰写方案的那个模型。

---

工作流

1. 明确目标

用一句话说明具体有哪些疑问，以及谁持有什么立场——AI 提出的方案、用户的立场、同事的立场，或关于系统行为的某项说法。

如果是两个人意见不合，要用他们各自的原话记录双方立场。不要把它们合并成一个维度；这种混淆会让咨询最终只是把某人的观点原样复述给对方。

还要说明最终要带走什么：一项决策、一个事实、一项修复、一条待发布的评论或一项测量结果。答案应由交付内容决定。

2. 夯实依据

在拟定问题前，调用几次工具检查决定答案的前提。阅读方案所依赖的代码路径。检查约束是否真的成立。直接查看数据，而不是估算。

外部事实是打破模型错误相关性的唯一方法。模型之间争论无法让你摆脱共同的错误认知；证据可以。

Consult 可以在这里结束，而且通常就该如此：“你的前提有误——证据如下。问题不复存在。” 这是当前能得到的最佳结果，不是退而求其次。

3. 构建评审材料包

为每位顾问准备一份中立的材料包，内容完全一致：

• 问题 — 以不预设答案的方式陈述决策或主张。
• 材料 — 实际的代码、差异、文档或数据。直接附上，或提供准确路径。
• 已验证事实 — 通过核实得到的内容，以及核实方式。
• 硬性约束 — 不变量、兼容性、截止日期、规模。
• 已排除的方案 — 说明排除理由，避免别人再次提出。

切勿诱导证人。

• 不要这样说：“我提议用 Redis 队列，因为它很快——这是个好主意吗？”
• 应该这样说：“在约束 [X, Y] 下实现持久化任务执行。测得每天处理 900 个任务（已核实，见日志）。应该用什么方案，为什么？”

4. 分派评审小组

默认配置——三位顾问，通过一次调用并发评审。 使用不同的提供商。彼此隔离；任何顾问都看不到其他人的回答。每位顾问都应给出：

1. 答案及得出该答案的推理过程。
2. 是否质疑问题的设定，以及原因——明确欢迎提出异议。
3. 信心，1–10 分，以及能改变信心的一件事。
4. 反对自己答案的最有力论据。

还可以给每位顾问指定不同的推理方法，进一步降低相关性——一位反向推演（假设方案已上线并出问题，然后追溯原因），一位分解问题（列出关键假设并逐一检验），一位追踪依赖关系和基准发生率（什么会阻碍什么，类似尝试实际结果如何）。推理方法和模型可以降低相关性；角色设定和职位名称则不行。

每位顾问收到的提示词都应包含：“不要迎合问题设定看似期待的答案。推理并得出你的结论。如果你认为问题本身有误，请直说。”

只有意见不一致时才升级。 如果三位顾问意见一致，就此为止——这种一致就是你的证据。如果他们存在实质性分歧，则请一位强模型担任魔鬼代言人，针对正在形成的答案提出质疑：“评审小组正在趋向 X。请提出最有力的论据，说明遵循 X 是错误的。指出一件如果未被反驳，就应改变最终判断的事。” 然后明确反驳或接受这一论据。

如实标注较弱的配置：

情况	做法	称呼
只有一个可用的新提供商	使用一个新模型，读取一次	单模型第二意见
无法使用子 Agent	在当前线程中推理	线程内推理——无法消除自我评判偏差
评审小组使用同一模型	执行评审并标明	共享盲点评审小组，而非独立佐证

坦诚说明较弱的咨询方式，也胜过假装独立。报告实际的分派情况——哪些模型作出了回应，以及是否实现了提供商独立。切勿暗示未能实现的独立性。

5. 回答

先给出结论。根据问题调整篇幅——命名问题用一段话，迁移问题则详细说明。根据发现的情况选择合适的形式：

证据已定 — 依据或评审团已解决问题。

结论、足以定论的证据，以及当前该怎么做。

评审团意见一致 — 所有顾问的判断一致。

答案、置信度，以及意见是否一致或加权得出。哪些条件成立时，这个答案才会错。唯一的下一步。

对事实有分歧 — 他们对事实判断不一。

各方主张、能区分这些主张的测量方式，以及如果测量成本足够低，直接测量会得到什么结果。不要把事实上的空白变成哲学争论。

对价值取舍有分歧 — 存在真正的权衡；两条路径都满足要求。

用一句话说明矛盾点。分别说明各方立场所保护的东西和愿意接受的代价。针对当前限制给出裁定。选择该方案会放弃什么。应当重新审视这一决定的可观察条件。

始终以一个具体的下一步行动作结；在适用时，说明今后如何判断这次决定是否正确。

如实报告意见一致的情况。如果评审团只是因为共享某个假设才得出一致结论，请说明这一点并降低置信度。对共同盲点意见一致，不代表结论可靠。

最终决定权仍在用户手中。裁定只是建议，并不代表获准实施。

---

应做与不应做

应做：

• 直接回答；如果问题不需要评审团，就跳过评审团。
• 先核实关键前提，并标明哪些已核实、哪些是假设。
• 发送材料；不要提供讨论串。
• 允许顾问拒绝回答问题，并提出无人提及的选项。
• 要求给出经过校准的置信度，并让它比文采和篇幅更重要。
• 只有在得出答案后才请魔鬼代言人提出反驳，并让其针对该答案。
• 披露实际派发情况，包括独立性未能保证的情况。

不应做：

• 指派任何人去为某一立场辩护。
• 将对话历史粘贴到顾问的提示词中。
• 复用作者使用的模型、重复使用同一模型或使用 inherit，然后称其具有独立性。
• 在证据已能定论，或诚实的答案是“现在还不知道——去测量”时，硬凑出两方对立的权衡。
• 把模棱两可的说法当作定论，或用结构掩盖答案。
• 将原始子 Agent 对话记录一股脑贴进聊天。
• 对一个 grep 就能解决的问题派出五个 Agent。