当 AI 遗忘项目细节时，应先核实再记忆
当 AI 助手无法检索到正在进行的创意项目中的常规细节时，它应当说明自己无法确认的内容，指出缺失的事实，并向用户询问来源。只有在用户确认该细节后，它才应更新其工作记忆。这种回应方式比凭空捏造看似合理的过往对话更有用，因为它能将真实的项目记录与推测明确区分开来。
为什么看似合理的记忆仍属于推测
创意项目依赖于微小的决策：入围了哪个标题、草稿使用的是第一人称还是第二人称，或是用户选择了哪种配色方案。如果助手找不到这些细节之一，流畅的回答听起来可能像可靠的回忆，但实际上却悄悄引入了全新的选择。
NIST 将生成式 AI 的虚谈（confabulation）定义为包括自信呈现的虚假内容，以及偏离或反驳输入内容的输出。捏造的项目细节正符合这种实际风险：它很容易被误认为是已经做出的决定。NIST 的《生成式人工智能画像》（Generative AI Profile）从总体层面上描述了这一机制；此处涉及的项目工作影响是一种设计层面的推断，而非针对特定产品的调查结论。
OpenAI 的研究同样指出，常见的评估激励机制可能会奖励盲目猜测而非承认不确定性。该研究的示例是常规问答，但其设计层面的经验同样适用：助手不应将听起来自信的文本补全视为过往对话仍然可用的证据。Why language models hallucinate
首先明确助手实际能看到什么
助手应当区分三种状态：在当前对话中可见的细节、可从现有项目资料中检索到的细节，以及它无法验证的细节。这些状态需要采用不同的措辞。如果该细节出现在当前会话的上文中，助手可以引用或总结它，并指向该上下文。如果它找到了某份笔记或文档，它可以指明该来源。如果两者都不可用，它应当直截了当地说明。
有价值的不确定性表述应当具体且克制：“根据我目前可获取的项目信息，我无法核实您选择了哪个标题。”这并不意味着用户从未选择过标题，也不意味着助手已经搜遍了所有可能的档案，更不意味着缺失的细节不存在。这些区别至关重要，因为无法检索到记录并不能证明该记录从未创建过。
Google 的《People + AI 指南》（People + AI Guidebook）建议解释相关的能力与局限性，并将解释的重点放在影响用户理解和决策的方面。应用在当前场景中，这意味着对可用的项目上下文做出简短说明，而不是对模型内部机制进行技术性解释。Explainability + Trust
索取最小化且有用的信息来源
在指出信息缺失后，提出一个有针对性的问题。例如：“您能否粘贴一下笔记，或者告诉我您最终定下的标题？”如果用户可能有多个来源选项，可以提供一个简短的列表：“是在最新草稿、您的项目笔记，还是早些时候的聊天中？”这样做的目的是让信息恢复变得轻松，而不是把常规的创意任务变成一场盘问。
一种实用的回应模式是：“根据我能访问的内容，我无法确认配色方案。如果您能分享笔记或提醒我具体颜色，我会在下一版草稿中使用它们。”这指出了缺失的事实，请求了证据或确认，并解释了接下来的操作。它还能保持工作节奏：助手可以继续处理任务中不受影响的部分，同时保留尚未确定的选择空间。
当缺失的信息会改变答案时，进行澄清非常有价值。在一项协作对话研究中，Testoni 和 Fernández 发现，以模型不确定性为导向的澄清策略在其特定的绘图任务中提高了任务成功率；他们同时指出提问也是有成本的。这支持了一种适度的方法：仅在缺失的项目事实至关重要时提问，并保持问题聚焦。Asking the Right Question at the Right Time
仅在用户确认后才进行更新
一旦用户提供了来源或确认了细节，就以简洁的形式重述已确认的事实：“明白：根据您粘贴的笔记，当前标题为《小花园手记》。”如果来源中的内容略有出入，应指出不一致之处，而不是自行默默做决定。例如：“您的笔记中写的是‘花园手记’；您刚才说的是‘小花园手记’。我应该使用哪一个？”
更新的范围应仅限于该项目及相关证据。粘贴的一行文字可以支持在当前任务中使用该行内容；但它并不自动代表该细节是永久有效的、适用于每一个版本，或应在当前对话之外长期保存。如果产品拥有可视化的项目记录，展示拟议的更新并为用户提供修正途径。如果产品没有此类记录，就不要声称记忆已被永久更改。
这一确认步骤是基于可追溯性和用户掌控权提出的设计建议：用户可以看到采纳了哪项事实，并在其对后续工作产生更多影响之前进行纠正。在创意方案不断演变时，这尤为有用。先前的草稿可能包含旧标题，而最近的消息确立了新标题；助手应当保留这种先后顺序，而不是将历次草稿抹平成一段所谓永恒不变的记忆。
避免提出暗带推测的问题
如果提问中夹带了凭空捏造的答案，仍会产生误导。“您选的是蓝绿色，对吧？”这种提问会给对话施加倾向，将讨论引向助手尚未核实的细节。应优先选择中立的询问：“您选择了哪种颜色？”如果有实际来源提到了蓝绿色，请指明该来源：“草稿笔记中列出了蓝绿色。这仍然是您想要的配色方案吗？”这种措辞将资料证据与当下的确认区分开来。
不要将生成的内容当作记忆中的事实呈现。如果用户找不到先前的决定，助手可以提议协助重新选择，但应将其明确标识为全新的选择：“我无法找回之前的配色方案。您现在想重新选一个吗？”这种区分既能实现创意协作，又不会篡改项目的历史记录。
2024 年一项关于语言模型回应不完整问题的研究发现，符合上下文的恰当澄清行为只在特定的模型规模和提示条件下才会出现，而不会自动发生。这一结果提醒产品团队要明确设计和评估此类行为，而不能想当然地认为模型默认就能可靠地提出恰当的问题。Clarifying Completions
通过日常项目任务评估该行为
产品团队可以使用日常创意项目的提示词来测试这种交互：当助手的可用上下文中缺少相关细节时，询问缺失的标题、选定的格式或草稿偏好。出色的回应应当指出信息缺口，避免捏造以往的对话，索取相关来源或确认，并在此后一致地使用已确认的信息。
测试用例中还应包括细节就在当前对话线程或所提供笔记中的邻近场景。在这些情况下，助手应当利用现有证据，同时准确说明其来源出处。此外还要测试相互冲突的版本以及用户纠错的情况。有效的评估能够区分毫无依据的凭空回忆与有据可查的信息检索，并检查助手是否能在不阻碍整体任务的前提下继续处理不受影响的工作。
这是一种建议的评估方法，而非引用的研究所确立的结论。其信息价值在于这一决策流程：判断访问权限、说明局限、索取最小化有用来源、确认采纳的细节，并保持更新范围清晰明确。这一流程将一句“我不知道”转化为了工作推进中的建设性步骤。
让不确定性成为项目连续性的一部分
对于创意项目助手而言，承认细节缺失并非走入死胡同。这是一种保护连续性的方式：系统可以继续提供帮助，同时让未经核实的历史保持空白。明确的不确定性、聚焦的询问和清晰可见的确认，让用户决定什么才属于项目记录——并为助手的下一版草稿提供坚实可靠的依据。