当您是唯一做出决定的人时，获取第二意见

询问您可以更改的选择

选择具体的业务问题：建立入门捷径、修改服务包或推迟功能直至客户确认需求。说明替代方案、截止日期以及您愿意承诺的内容。如果可行的话，包括暂时不采取任何行动作为一个真正的选择。

在询问模型之前写下您当前的偏好，但在不需要时将其从他们的第一份简报中删除。在你的私人日记中记录下你喜欢它的原因。稍后您可以看到讨论是否改变了您的推理，或者只是为您已经做出的决定提供了更好的语言。

为每个观点分配一份工作

这些是所请求的推理视角，不是认证顾问，也不是统计上独立的证据来源。选择可用智能体，用相同事实通过 Ask separately 分别获取答案。在交给 Consensus 综合之前保留原始输出。如需八个版本，请明确指定八个视角，但不要把数量当作可靠性指标。

询问鼓励和反对背后的证据。捏造的风险并不比捏造的机会更有用。模型之间的一致应该引导您回到支持事实，而不是直接做出更大的承诺。

• 客户视角：什么证据表明该问题值得解决？
• 交付视角：哪种依赖关系可能会妨碍建议的结果？
• 机会成本视角：这种选择会取代哪些工作？
• 持怀疑态度：什么样的观察会导致建议错误？

示例：构建集成还是先测试需求？

虚构场景：一位独立创始人收到两位客户的集成请求，估计开发原型需要一周。请求没有说明客户是否会经常使用这项集成。同时，产品的新用户引导还有一个未解决的问题。这些只是说明方法的输入，不是客户案例或经过实测的开发工期。

讨论可能指出一个更小的下一步：先向提出请求的客户展示模拟流程，询问他们会怎样使用，再安排开发。如果现有证据已经明确支持需求，直接开发也可能合理。价值在于识别区分这些选择的条件，而不是给其中一个选项投出自信的一票。

提示有用的第二意见

阅读答案后，向Consensus提供相关摘录和原始摘要。要求它保留最强烈的未解决的反对意见，并将您今天可以做出的决定与需要更多信息的决定分开。您仍然是该操作和日志的所有者。

决定：[选择和截止日期]。选项：[选项，包括在可行的情况下推迟]。既定事实：[事实和来源]。假设：[假设]。限制：[时间、资源、承诺]。对于每个选项，请陈述其最有力的理由、最强烈的反对意见以及会改变您的建议的证据。提出最小的实际下一步检查。不要发明客户需求或数字概率。最后写一个决策日志条目，让未知的事情保持可见。

通过观察关闭循环

设置检查后重新访问条目的日期。记录发生了什么、哪个假设发生了变化以及下一步行动是否仍然合理。这将对话变成了学习记录，而不是不断增长的有说服力的建议。

如果遗漏的条件可能会改变决定，请使用其他意见。简单的重写可能只需要一个模型。 Colay 使用积分和限制，因此请将额外的讨论与其帮助解决的具体不确定性进行比较。对于需要专业知识或第一手客户证据的决策，请直接寻求证据；额外生成的意见不提供它。

问题及解答