在做出重要决定之前获取 AI 的第二意见

从您需要做出的决定开始

“评估我的想法”为令人愉快的概述留下了太多空间，但没有任何改变。说明选择、截止日期和标准：立即开始试点或检查数据后开始试点；购买服务或扩展现有系统；接受完整范围或将工作分为几个阶段。

包含可靠的替代方案，例如保留当前流程。然后讨论可以检查是否有必要采取行动。在阅读答案之前定义标准：可用的人员、所需的能力、支出限制以及会停止工作的条件。

工作场景：你们能承诺一个月内交货吗？

设想一家服务机构正在考虑在四周内实施 CRM，用于处理收到的客户请求。负责人想接下项目：团队熟悉这个系统，需要搭建的界面也不多。然而，需求说明没有明确现有数据的质量、集成访问权限，以及客户能否及时参与审批。这是假设示例，不是客户实测结果。

另一种观点可能表明这些依赖关系比屏幕设计更重要。要求测试的是团队是否可以使用未准备好的数据进行交付。一个有用的结果可能是一个发现阶段，其中包含确认交付日期所需的证据列表。该团队仍然对实际的时间表和范围负责。

如果所有智能体都认可最初的期限，请要求它们给出支持这一判断的事实。一致意见无法消除未知的依赖条件。如果某项反对意见依赖于编造的复杂情况，请索取证据，或将其保留为假设。

向参与者提供相同的需求说明

在每个重要事实旁边放置一个来源：文档标题、电子邮件日期或电子表格行。这使得最终的检查更容易。使用您有权与相关服务共享的信息；匿名条件通常足以进行初步审查。

• 决策：您需要从哪些选项中作出选择，以及决定的截止时间。
• 既定事实：要求、商定的条款和可用文件。
• 假设：尚未通过观察确认、也尚未达成一致的预期。
• 限制：人员、预算、依赖性和强制性条件。
• 停止条件：什么会使选项不可接受。

提示有用的第二意见

“帮助审查此决定：[选项和截止日期]。既定事实：[事实和来源]。假设：[列表]。约束：[条件]。考虑每个选项的最有力论据、最强烈的反对意见以及不进行任何更改的选项。不要将我的偏好视为证据。找出最有可能改变结论的缺失事实。以有条件的建议结束，保留重大分歧，并列出一个人必须完成的检查。不要编造数字或支持证据。”

将字段替换为您自己的需求说明。在Colay中，选择Consensus进行讨论和共享结论。如果您想要单独的初始答案，请使用Ask separately。对于后续的综合请求，请提供相关摘录和原始需求说明；不要假设单独的聊天会自动成为其上下文。

有用的结果应包含哪些内容

对于 CRM 示例，确认访问和检查数据将支持下一步决策。 “所有模型都认为可行”不足以承诺一个日期。将原始需求说明与备忘录一起保留，以便您可以确定哪些条件稍后会发生变化。

当一个答案就足够了

编辑电子邮件或总结您自己的文本可能只需要一个模型和正常审核。当存在真正的替代方案并且被忽视的条件可能会改变决定时，讨论更值得测试。 Colay 订阅使用积分和限制：将使用情况与额外审阅实际阐明的内容进行比较。

通过可观察的结果来判断您的第一次尝试。您是否发现了缺乏依据的假设、修改了计划或确定了客户必须回答的问题？更多页的散文并不能创造价值。从一个您有文件和验证结论的方法的决定开始。